跨模型 Agent 协作：tmux 当通信层，持久 session 当基本单位

「强模型规划、便宜模型执行」不新，组队才是问题

最近「强模型规划、便宜模型执行」很火，但 AI Jason 指出这句话一点都不新。真正值得琢磨的是另一个问题：电脑上同时开着 Claude Code、Codex、Gemini CLI、Kimi、Pi 好几个 agent，它们之间没有统一协议，怎么让这一堆凑成一个真会协作的团队？

答案不是再搭一套复杂框架，而是四个更底层的设计——其中一个特别土但特别好使：tmux。

设计一：子 agent 要能长期活着

现在的委派基本是：建一个新 agent → 给任务 → 读代码 → 干完 → 返回结果 → 会话销毁。要改？再建一个新的——它不记得刚才发生过什么，得重新读文件、重新理解项目。

真正费 token 的不是模型贵，是每次协作都在从头失忆一遍。更合理的是给每个 worker 一个长期 session，「改一下」不再等于「从头再做一遍」。

设计二：用 tmux 当通用通信层

tmux 本来只是个终端多路复用工具，但它刚好有编排真正需要的三件事：

开一个 agent → tmux split-window
发反馈 → tmux send-keys
读结果 → tmux capture-pane

不需要所有 agent 都支持同一套 API——只要它们能在终端里跑，就能被同一个 orchestrator 控制。这是「终端即接口」的极致体现。

设计三：真正难的是「完成通知」

启动一个 agent 很简单，真正难的是主 agent 怎么知道 worker 干完了。一直轮询输出浪费 token 和算力；完全不查又不知道啥时候往下走。

tmux 有个信号机制：worker 干完发 tmux wait-for -S task-done，主 agent 那头 tmux wait-for task-done 等着——等于在两个完全不同的 agent 之间接了一个 callback。

设计四：harness 不该决定你用哪个模型

把两件事拆开：orchestrator 负责怎么拆任务，harness 只是 worker 的运行环境。主力模型在 Claude Code 里当协调者，具体活分出去：Codex 写实现、Claude 做代码分析、Gemini 处理超长上下文、便宜模型跑测试和机械修改。

别在对话一开始就定死一个模型——每个任务被建出来那一刻再决定它用谁。这就是 task-level routing：模型跟着任务走。

ADE 在解决什么？

那 Orca、Herdr 这类 ADE（Agent Development Environment）在解决什么？它们真正做的比「能同时开多个 agent」深一层：把底层的编排能力，变成人能看懂的界面——主子 agent 层级一眼看到、随时插手任意子 session、token 烧了多少摆在面上、kanban 管状态。IDE 管的是文件和代码，ADE 管的是 agent、session 和任务。

核心新观点

这篇真正的新观点其实和「谁规划、谁执行」没多大关系，它更底层：

agent 团队的基本单位，是一个持久的 session，不是一次 prompt
不同的 coding agent 不用等一个统一标准，终端本身就能当通信接口
真正关键的原语不只是 spawn，还有 send、resume、signal、callback

tmux 看着土，其实它已经把下一代 agent 基础设施真正需要的那几个原语都摆出来了。往后看，agent 工具会越来越像一个管理长期进程的操作系统——这套思路和 Superset（编排型 IDE）、pi-web（浏览器编排 UI）指向同一个方向，只是层级更底层。

AI Jason（Jason Zhou）已把这套 tmux 委派 + 完成信号开源成 skill「open agent teams」（AI Builder Club），任何 CLI agent（Claude、Codex、aider…）都能接。