凌晨三点，你睡了。Claude Code 还在跑，Codex 也在跑，Qwen 排在后面等着。早上醒来一看，第一个干活的 CLI 一小时前就自己退出了——可能是网络抖了一下，也可能它觉得任务"差不多完成了"。更糟的是，子任务交回来的报告还掺了水。
这是很多同时开多个 AI CLI 的人都会遇到的场景。市面上的工具能让你同时看到一堆 CLI 在干什么，但没有一个工具让某个 CLI 对别的 CLI 负责。Polter 想补的就是这个位置。
它到底是个什么东西
Polter 是 Ghostty 的一个分支，加了一层 MCP。任何支持 MCP 的 CLI 都可以当"监工"。这个监工会开标签页、启动其他 CLI、往里面打字、读取它们的屏幕内容。
干活的 CLI 把进度汇报到一个群聊和一份共享任务列表里。如果某个干活 CLI 的屏幕长时间没动静，监工会收到通知。反过来，如果监工自己卡住了，Polter 会去戳它一下。
这套机制解决的是两个具体问题：CLI 中途退出，以及子任务交活时虚报进度。前者靠"屏幕安静就报警"来兜底，后者靠群聊和共享任务列表把汇报摊在明面上。
它和同类工具的差别在哪
按作者的说法，现有工具解决的是"看得见"——让你同时观察多个 CLI。Polter 解决的是"有人负责"——指定一个 CLI 去盯着其他 CLI。这个差别听起来小，但直接决定了通宵任务能不能跑完。
没有监工的时候，一个 CLI 挂掉，整条链路就断了，剩下的时间全浪费。有监工的时候，异常会被上报，监工可以继续推进。
作者自己承认的短板
这部分值得单独拎出来说，因为它决定了你现在能不能用。
- 只有 Claude Code 作为监工经过了端到端测试
- Codex、Qwen、opencode 作为干活 CLI 没问题，但它们当监工的路径没测过
- Windows 上缺了 9 个动作
- 因为是分支项目，上游 Ghostty 的更新合并会有延迟
换句话说，如果你想让 Codex 去管别的 CLI，目前属于没人验证过的状态。作者没有把话说满，这一点比很多项目诚实。
它明确不做什么
Polter 不会替 CLI 回答权限确认弹窗，不会解锁你锁住的标签页，也不会绕过 CLI 自身的权限机制。这几条是硬编码的，不是靠提示词约束。
这个设计选择挺关键。让一个 CLI 去管另一个 CLI，最容易失控的地方就是权限——监工如果能把权限弹窗一路点过去，那它和"自动批准一切"就没区别了。Polter 把这条线划死了。
项目采用 MIT 协议，代码在 GitHub 上公开。
这件事的意义
多 CLI 协作现在缺的不是"能开多少个"，而是"谁对结果负责"。Polter 给出的答案很直接：指定一个 CLI 当监工，让它去开标签、打字、读屏、催进度。
这个思路能不能推广，取决于两件事：一是监工路径能不能覆盖更多 CLI，二是这套"读屏幕"的交互方式在复杂任务下稳不稳定。作者自己列出的短板，恰好就是这两个方向。
对于经常挂着通宵任务的人来说，现在能用的组合是明确的：Claude Code 当监工，Codex、Qwen、opencode 当干活的。其他组合，等测试结果。
热门跟贴