最近很多人问我一个问题：怎么用 Codex 监督 Kimi Code K3 执行？
我没上什么复杂平台，也没写一套宏大的 agent orchestration。
我用的是 tmux。
这也是我最近越来越强烈的感受：AI 越智能，工具越简朴。
听起来很土。但越是让多个 coding agent 并行干活，我越觉得 tmux 是 AI 时代程序员最值得学的工具之一。
AI 时代缺的不是编辑器，是控制台
以前写代码，核心工具是编辑器。你打开文件，改代码，跑测试，提交。
现在不一样了。一个 agent 在改实现，一个 agent 在跑测试，一个 agent 在读日志，你自己还要看 diff、决定要不要打断它们。
这时候问题不再是“哪个编辑器更聪明”，而是：这些正在运行的任务，谁负责调度？谁负责观察？谁卡住了？谁应该停？
AI 时代的工作台，不是一块编辑区，而是一组长期运行的任务现场。
这正是 tmux 的位置。
tmux 是最小的多 Agent 调度器
我的做法很简单：一个 master tmux session，多个 worker tmux session。
master 负责监督，worker 负责执行。比如一个 worker 跑 Kimi Code K3 修 bug，一个 worker 跑测试，一个 worker 看日志，另一个 worker 做代码审查。
调度也不神秘，就几个最直接的命令：
send-keys：把任务发给某个 worker。
capture-pane：把 worker 当前输出抓回来。
attach：必要时直接进去看现场。
kill-session：跑偏了就干掉重来。
这套方法不优雅，但它透明。你不用猜某个黑盒平台内部发生了什么。每个 agent 在哪个 session、执行到哪一步、输出了什么，全都摊在终端里。
tmux 给多 agent 的价值，不是智能调度，而是可见、可控、可恢复。
为什么这很重要
Agent 最麻烦的地方，不是它不会写代码，而是它会一直写。
它可能卡在测试里，可能开始改无关文件，可能把一个小 bug 扩成半个重构。你需要的不是更大的自由度，而是更清晰的边界。
tmux 的好处就是边界感强：一个任务一个 session，一个职责一个窗口。出了问题，最坏也只是杀掉一个 worker，不会把整个工作台掀翻。
而且它天然适合远程机器。网络断了，任务还在；电脑合上，agent 还在；你回来 attach，现场还在。
这比很多华丽的“AI 工作流平台”更接近真实开发。
先别急着造平台
如果你也想让 Codex 监督 Kimi Code K3，或者让多个 agent 并行干活，我建议先别急着写框架。
先用 tmux 跑起来。
因为越智能的东西，越需要简朴的边界。复杂工具容易把系统变成另一个黑盒，tmux 反而把执行现场摊开给你看。
当你真的遇到状态同步、权限隔离、失败恢复、任务队列这些硬问题，再考虑把它产品化。
很多复杂系统，第一版都应该从一块透明的终端面板开始。
当代码开始由一群 agent 接力完成，程序员最重要的能力之一，是管理现场。AI 越智能，工具越简朴。tmux 就是这个现场的最小控制塔。
