来自 initech 项目的技术文章。
2026 年 3 月 28 日
为什么我们为 AI 智能体构建了一个终端复用器
我们构建了一个 Go TUI，用于管理并行运行的多个 Claude Code 智能体。它替代了 tmux 作为我们的会话运行时。
给每个智能体一个运行 Claude Code 的终端，配有角色专属指令。supervisor 智能体负责协调。工程师智能体负责实现。QA 智能体负责验证。shipper 智能体负责发布。每个智能体都有一个 CLAUDE.md，编码其身份、约束、工作流和通信协议。
在构建 initech 之前，我们在四个项目中运行了这种模式。它交付了真正的软件：并行工程、独立 QA、发布门控、跨会话的组织记忆。
tmux 在三个方面出现问题，且随着智能体增加而恶化。
tmux send-keys 没有送达保证。你向智能体的面板发送消息，然后祈祷它到达。如果没到达，也没有任何错误提示。eng 给 super 的完成报告丢失了，super 不知道 eng 已完成，QA 永远不会被分派，bead 停滞一个小时。
在 tmux 中，挂起的智能体和正在工作的智能体看起来完全一样。已完成和进行中看起来也完全一样。唯一的办法是逐个查看面板。9 个智能体意味着每 10-15 分钟手动检查 9 次。
tmux 不知道有哪些工作存在、谁被分配了什么任务、也不知道某个智能体刚刚将任务标记为待 QA。所有编排都在 supervisor 的上下文窗口中。上下文会压缩。消息会丢失。Supervisor 智能体忘记 eng 已完成。分派链停滞。
tmux 是一个通用终端复用器，却在做需要应用层智能的工作。
每个会话运行一个 Unix 域套接字。initech send 通过模拟器将文本写入智能体的 PTY，然后确认送达。发送方在几秒内收到明确的 OK 或错误。
$ initech send eng1 "fix the auth bug in middleware.go" $ initech peek eng1 -n 20
我们首先尝试了 JSONL 会话日志跟踪。不可靠：Claude 在对话边界写入 JSONL，时间不可预测。在 45 秒的思考暂停期间，零条记录。任何超时值对于某些情况来说都是错的。
有效的方法：追踪 PTY 上次产生输出的时间。Claude Code 的旋转指示器在思考时以 10-30 fps 动画。唯一零输出的状态是在提示符处空闲。2 秒的时效阈值可以实现干净的二元检测。
绿点表示工作中。灰色表示空闲。黄色表示空闲但有任务等待。叠加层无需打开任何面板即可显示每个智能体的状态。
JSONL 用于活动检测失败了，但适用于语义事件。会话日志包含工具使用结果、助手消息和错误序列。事件系统解析这些以获取：
* Bead 完成：智能体运行了 bd update --status ready_for_qa
* 停滞：分配了 bead 后 10 分钟以上无输出
* 错误循环：连续 3 次以上工具失败
* Bead 认领：从 bd 命令自动检测，无需额外 CLI 调用
事件以弹窗通知形式显示。"eng1 completed ini-bhk.3" 在 super 报告之前就以绿色显示出来。
每个智能体的信息条显示其当前 bead。叠加层一目了然地显示每个智能体的状态。当一个持有 bead 的智能体变为空闲时，TUI 会直接告诉 supervisor 智能体："[from initech] eng1 is now idle (bead: ini-bhk.3). Check if work is complete."
以上每个数据都是由工具自身生成的。initech 管理了构建 initech 的智能体。
TUI 是运行时。模板才是智能。一个糟糕的 CLAUDE.md 无论 TUI 多好都会产生糟糕的输出。我们将全部 11 个模板重写了三次，每次都将实际失败中的教训编码进去：工程师智能体跳过 PLAN 注释、QA 智能体走过场、supervisor 智能体自己做工作而不是分派。
在 PTY 字节时效方法奏效之前尝试了三种方法。JSONL 跟踪：太慢。终端输出速率：SIGWINCH 误报。提示检测：对 UI 变化脆弱。旋转指示器方法之所以有效，是因为 Claude Code 工作时始终产生输出。静态的 "thinking..." 显示会使其失效。
Supervisor 智能体的第一大失败：自己做实现而不是分派。分派感觉很慢。但多智能体的核心就是专业化。"不使用智能体"现在是 supervisor 模板中的第一个关键失败模式。
每个智能体最终都会忘记在编码前注释 PLAN，或在标记 ready_for_qa 前推送，或清除其 bead 显示。自动通知的存在就是因为智能体会忘记报告完成。防护机制有帮助但不能完全消除这个问题。流程遵守是一个渐变过程，不是非此即彼。
会话迁移尚未开始。在机器之间移动会话（MacBook 到工作台）需要手动 rsync。PRD 描述了一个尚不存在的 initech migrate 命令。
资源管理在功能开关之后。内存压力下的自动暂停/恢复（该功能可在 36GB 笔记本上将有效智能体容量翻倍）已实现，但因策略在真实会话中测试不足而被 --auto-suspend 开关控制。
新手引导还很粗糙。新用户首次运行 initech 时看到 7 个面板却没有引导。状态栏提示在底部循环，但没有记录完整工作流的操作指南。这个工具是由它自己的用户构建的，这一点很明显。
早期阶段。 initech 已在多个项目中使用，但用户群仍然较小。更多的实际使用将发现自我验证未能发现的不足。
curl -fsSL https://initech.sh/install.sh | bash mkdir myproject && cd myproject initech init initech