来自 initech 项目的技术文章。
2026年4月1日
在同一个 TUI 里运行 Claude Code、Codex 和 OpenCode
initech 一开始有个简单假设：每个面板里跑的都是 Claude Code。
一旦你在真实工作里混用不同的智能体 CLI，这个假设就不成立了。大范围重构用 Claude Code。边界清晰的小任务用 Codex full-auto。想要另一种交互方式时用 OpenCode。麻烦的不是把它们启动起来，而是把它们放进同一个监督界面里。
现在，initech 可以在同一个 TUI 里并排运行 Claude Code、OpenAI Codex 和 OpenCode。
很多 multi-agent 工具默认所有面板运行的是同一个二进制。这种假设会一路渗透到启动方式、输入方式、提示符检测和真正的提交按键上。
一旦你混用工具，差异马上就会冒出来。一个 CLI 依赖 bracketed paste，另一个会把它当成噪音。一个工具在普通的 > 提示符下就已经就绪，另一个还在启动服务或者卡在 trust 界面。一个权限提示就足以让整条自主执行链停下来。
最直接的变化是 initech.yaml 里的 role_overrides。只有偏离全局默认命令的角色才需要单独写命令数组，而 agent_type 会告诉运行时该用哪套面板驱动逻辑。
project: myproject
root: ~/src/myproject
claude_command: ["claude"]
claude_args: ["--continue"]
roles:
- super
- eng1
- eng2
- qa1
role_overrides:
eng2:
command: ["codex", "resume", "--last", "--full-auto"]
agent_type: codex
qa1:
command: ["opencode", "--continue"]
agent_type: opencode
command 是完整替换，不是追加。所以 Codex 角色不会意外继承 Claude 的参数。agent_type 也不是装饰性元数据，它决定 ready 检查、bracketed paste、submit key，以及 CLI 特有的自动化。
终端复用器里最不起眼但最关键的问题是 submit。这里出错，其他一切都没有意义。
Claude Code 面板继续走 bracketed paste 路径。Codex 类面板则会等到提示符真正回到可输入状态，把消息正文直接写进 PTY，等 paste burst 检测清掉，再发送 submit key。
Codex 在自主运行里还有一个常见卡点：权限确认。一个确认框就可能让整个角色挂在那里等人回来处理。
对于 agent_type: codex，initech 默认开启 auto_approve。它会扫描终端底部的已知权限提示模式，并发送 p 来批准并记住选择。
真正有意思的不是“现在也能跑 Codex 了”，而是 initech 正在朝 agent-agnostic terminal multiplexer 走。
操作界面保持稳定。TUI 还是一个，监督入口还是一个。每个面板下面，按角色选择最合适的智能体即可。
安装：initech.sh/install.sh
源码：github.com/nmelo/initech
2026年3月31日
按角色覆盖命令：并行运行 Codex、Amp 和 Claude Code
initech 不再仅限于 Claude Code。通过 initech.yaml 中的 role_overrides，任何角色都可以运行不同的 CLI。一个智能体用 Codex，另一个用 Amp，其余用 Claude Code。相同的 IPC，相同的活动检测，相同的 TUI。
initech.yaml 中新增的 role_overrides 块允许按角色覆盖默认命令：
# initech.yaml role_overrides: codex-eng: command: ['codex', '--full-auto', '--no-alt-screen'] amp-design: command: ['amp']
每个覆盖将角色名称映射到一个命令数组。角色仍然拥有自己的 PTY、TUI 中自己的面板，以及对 initech send / initech peek 的完全访问。运行时不关心 PTY 内部运行的是什么。
"智能体运行时"这一定位在此之前只是愿景。initech 到处假设使用 Claude Code：活动检测依赖 Claude 的旋转指示器，事件系统解析 Claude 的 JSONL 日志，角色模板是 CLAUDE.md 文件。
通过命令覆盖，核心原语仍然有效。PTY 字节流可以检测活动，无论哪个 CLI 产生输出。IPC 消息传递在终端级别运行，不依赖于 Claude。CLAUDE.md 模板只适用于运行 Claude Code 的角色；其他 CLI 自带配置。
使用非 Claude CLI 时会失去什么：基于 JSONL 的事件解析（bead 完成检测、停滞检测）和基于会话日志的弹窗通知。活动检测和 IPC 仍然有效。对于混合集群，Claude Code 智能体获得完整功能集；其他智能体获得可靠的 PTY 管理和消息传递。
显而易见的场景：你想在同一代码库上比较不同的智能体 CLI。用 Claude Code 运行一个工程师角色，用 Codex 运行一个并行的工程师角色。相同任务，不同智能体，并排可见。
实用的场景：不同任务适合不同工具。Codex 智能体以全自动模式处理简单的重构。Claude Code 处理需要更多指导的复杂多文件变更。两者都可以从一个终端查看和寻址。
$ curl -fsSL https://initech.sh/install.sh | bash
源代码和操作指南：github.com/nmelo/initech
2026年3月30日
跨机器协调：在多台机器上运行你的智能体集群
initech 现已支持跨机器协调。在任意机器上运行 initech serve——工作站、远程 GPU 服务器、云虚拟机——本地 TUI 即可实时流式传输其所有智能体面板。一个终端。所有智能体。任意机器。
在远程机器的 initech.yaml 中添加 mode: headless、peer_name、listen 和 token：
project: myproject root: /home/user/myproject mode: headless peer_name: workbench listen: ":7391" token: "共享密钥" roles: - eng1 - eng2 - eng3
启动守护进程：
$ initech serve
在本地 initech.yaml 中添加 remotes: 块：
project: myproject
root: /Users/you/myproject
token: "共享密钥"
roles:
- super
- pm
- qa1
remotes:
workbench:
addr: "192.168.1.100:7391"
正常启动 TUI：
$ initech
$ initech send workbench:eng1 "开始 API 重构" $ initech peek workbench:eng2 -n 30 $ initech peers
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