一个人怎么让多个 AI 不互相打架

很多人以为，多 AI 协作最难的是能力。

怎么接更多模型，怎么让它们联网，怎么让它们调工具，怎么让它们自己调用自己。

真正跑过一阵之后，我发现这些都只是工具层。

最难的是：当你手里同时有几个 AI，它们到底谁该先接球，谁能改什么，谁说了算，谁只负责执行。

如果这些边界没有先想清楚，多一个 AI，通常不是多一份产能，而是多一份混乱。

聪明已经够用，缺的是调度

一开始我也走过那条很典型的路。

今天让一个 AI 帮我搭页面，明天让另一个 AI 整理知识库，后天再开第三个窗口让它盯日报和自动化。每个单看都挺能打，但一旦开始共享同一批项目、同一批文件和同一条长期任务线，问题就出来了。

有的事情会被做两遍。 有的上下文会只存在于某一个会话里。 有的文件谁都能改，于是谁都可能改乱。 有的任务明明应该先做决策，结果直接被推进了执行层。

从表面看，这是协作问题。

从底层看，这是控制层缺失。

人类团队里，为什么项目一旦复杂起来就会自然长出 PM、负责人、交接文档、权限边界和日报？流程当然会带来成本，但缺少这些控制结构时，每个人都可能做对自己的部分，整个项目却一起失控。

多 AI 协作也一样。

单点入口，是第一条铁律

如果你只有一个规则能先立，我建议立这个：

所有长期任务，必须先有一个单点入口。

也就是说，不要让每个 AI 都直接面对同一堆需求。

必须先有一个入口层，哪怕这个入口层不是最强的执行者，它也要负责一件最重要的事：判断这件事现在应该进入哪条路。

这是控制平面的最小形态。

它至少要回答四个问题：

1. 这件事是“想清楚”，还是“做出来”？
2. 这件事需要读哪些上下文？
3. 这件事会写到哪一层文件？
4. 这件事完成后，结果要回流到哪里？

没有这个入口，多个 AI 其实是在抢同一个驾驶位。

按职责分角色，比按模型排名稳定

很多人给 AI 分工时，喜欢按“谁更聪明”来排。

这个方向不完全错，但不够稳定。

协作效率更依赖职责是否稳定：谁接球，谁执行，谁审阅，谁承担最终判断。

我后来更倾向于按三种角色来分。

1. 调度者

不一定写得最好，但它负责接球、拆球、分派、验收。

它的价值在于维持全局秩序，而不是在局部上跑得最快。它应该知道当前有哪些任务线、哪些共享文件不能随便改、哪些动作需要先过决策层。

2. 执行者

专注把一个明确任务做完。

它可以写代码、做分析、整理文档或生成页面。无论使用哪个模型，它都只完成这条链路分配给自己的动作，不顺手重写别人的规则。

3. 审阅者

负责把完成结果拉回到可合并、可验证、可追责的状态。

它可以是另一个 AI，也可以还是人。但这个角色不能省。否则系统的错误会在多次转手之后变成一种“大家都以为已经检查过”的幻觉。

这三种角色，可以由三个 AI 承担，也可以其中两个甚至三个都还是你自己。

数量并不重要，职责必须被显式写出来。

真正该先固定的是写入分层

多 AI 协作最容易出大事故的地方，通常不在生成内容，而在共享写入。

谁能改哪类文件，如果不提前定死，后面所有协作都会变得脆弱。

我现在更喜欢一种很笨但很好用的分层方式：

• L1：草稿层。实验、临时文件、日志、草图，自由写。
• L2：共享层。团队会反复读的文档、项目状态、交接文件，追加为主。
• L3：高责任层。带决策后果、不能误写、不能自动覆盖的核心产物，默认只读或必须提案后再改。

这个分层谈不上优雅，它首先解决的是一种常见灾难：

执行型 AI 在“顺手帮你优化一下”的过程中，碰到它根本不该碰的主文件。

有了分层之后，很多协作规则都能顺势长出来：

• 草稿先放哪里；
• 正式写入之前，要不要先提案；
• 谁有资格直接改共享主文件；
• 哪些结果只能追加，不能重写。

你不需要一开始就做得特别复杂。

但你必须先回答：如果两个 AI 同时动手，最坏的情况会发生在哪个层级？

我把自己实际使用的字段删去内部名称后，整理成了一份多 AI 任务交接模板。最小版本只要求写清任务、上下文、允许写入的位置、完成条件和下一位接手者。字段不多，但每一个都在阻止上下文重新丢失。

交接文档就是系统的外部记忆

单个 AI 协作时，很多人还能靠会话记忆硬撑。

一旦进入多 AI 场景，这套办法很快就不够用了。

因为上下文开始碎片化：

• 某个任务的背景在 A 里；
• 执行记录在 B 里；
• 失败原因只存在于 C 的对话窗口；
• 最后人已经忘了哪个版本才是最新的。

所以交接文档属于多 AI 协作的基础设施。没有它，所谓协作只是多个会话轮流失忆。

一个可用的 handoff 文档，不需要很长，但至少要有：

• 当前任务是什么；
• 已经做到了哪一步；
• 关键约束是什么；
• 哪些文件改过；
• 下一个 AI 接手时先看什么。

它的作用不是给人看着舒服。

它的作用是避免每次切人、切模型、切窗口时，整条工作线都重新热身。

下面是我现在会放进每张任务单里的最小结构：

task: 这次只完成什么
context: 接手前必须读哪些材料
allowed_writes: 可以修改哪些文件或系统
done_when: 用什么结果判断已经完成
handoff_to: 完成后由谁验收，结果写回哪里

过去最容易遗漏的是 done_when。没有完成条件，AI 很容易把“已经做了一些”误判为“任务完成”。把这一行写清楚以后，验收从感觉变成了可以复查的结果。

控制台的价值，不在炫技，在于看见系统状态

做到这里，很多人会自然问一个问题：

既然已经有多条任务线、多种角色、共享文件和交接状态，是不是该有一个控制台？

我的答案是：应该有，而且越早越好。

但控制台不该先做成一个很重的“AI 指挥中心”。

它最先要做的，只是把几个最容易失真的状态并排摆出来：

• 最近发了什么；
• 哪些文章还在排队；
• 哪些项目最近有实质更新；
• 哪些公开页面该复查；
• 哪些任务卡在“待决策”而不是“待执行”。

控制台首先是一个观察面，不是一个魔法面板。

如果没有前面的单点入口、角色分工、写入分层和交接规则，控制台只会把混乱更漂亮地展示出来。

但如果这些基础已经有了，控制台就会突然变得非常值钱。因为它把“我脑子里隐约记得还有几条线没收口”的状态，变成了一个真正可见、可排序、可复查的系统。

一个最小可行的多 AI 控制层

如果今天就要起一版，我会只做五件事：

1. 入口板 所有新任务先落这里，先分“想清楚 / 执行 / 待决策”。

2. 内容板 文章选题、草稿状态、最近发布时间、下一篇候选。

3. 资产板 哪些项目目录最近有变化，是否已经对应到一篇文章或一个公开页面。

4. 监控板 公开站点、RSS、关键页面是否活着，最近一次检查是什么时候。

5. 交接板 哪个 AI 正在干什么，输出应该回哪儿，谁来验收。

做到这一步，其实已经不是“玩多个 AI”了。

你是在给自己搭一层操作系统。

多 AI 协作最终要减少内耗

最后我越来越觉得，多 AI 协作最吸引人的地方，其实不是“我同时拥有了很多聪明体”。

而是你终于有机会把自己那些长期悬而未决的工作线，放进一个不完全依赖短期记忆的系统里。

一个人要同时管内容、项目、页面、自动化、知识库和公开输出，真正的瓶颈往往是内耗。执行力再强，也会被不断切换和重复判断消耗掉。

哪些该先做，哪些已经做了一半，哪些只是看起来在推进，哪些应该停下来先判断。

多 AI 如果没有控制层，会放大内耗。

多 AI 如果有控制层，才有机会放大产能。

所以问题从来不是“我要不要再接一个 AI”。

而是：

我有没有先搭好那一层，确保它们不会为了帮我，反而把系统弄得更乱。