Factory 的开发工程师 Luke 分享了他们内部多智能体系统 Missions 的架构设计。架构的技术并不炫，但体现了一个非常朴素的思想，软件工程的瓶颈已经从"模型够不够聪明" 变成了"人的注意力够不够用"。工程师手边堆着 50 个需求，每天只能推几个。模型能力早就不是卡点，人的带宽才是。
五种协作模式，Missions 用了四种
Luke 总结了多智能体协作的五种模式：委派、创建者-验证者、直接通信、协商、广播。Missions 选了其中四种，搭成一个“三角色”架构：
编排者：负责规划，拆任务，决定下一步做什么
工作者：负责写代码，实现功能
验证者：负责检查，确认做到没有
三个角色，各司其职，听起来简单。但魔鬼藏在细节中。
验证契约：写代码之前先定义"完成"
这是我觉得整个设计里最聪明的一环。在写任何代码之前，系统就定义好“完成”意味着什么。不是模糊的“能跑就行”，而是可能包含数百个具体的确认点。为什么这很重要？因为智能体自己写代码自己测试，本质上是在确认自己已经做出的决策，很难抓到自己的 bug。而验证者从不看代码，天然就是对抗性的。就不存在“既当运动员又当裁判”的问题。
串行执行：慢就是快
这个选择挺反直觉。并行跑多个智能体，听起来效率更高对吧？他们试了，结果协调开销把速度提升全吃掉了。智能体之间互相覆盖改动、做重复工作、架构决策打架。所以 Missions 的做法是：功能层面串行，只读操作才并行。表面慢了，但错误率大幅下降。长期任务里，正确性的提高会产生复利，越跑越快。
结构化交接：每个智能体离场必须交班
工作智能体完成功能后，必须填一份交接文档，什么完成了、什么没有、跑了哪些命令、退出码是什么。一旦捕获到错误，系统会自动拉回正轨。他们最长的任务跑了 16 天，比一个完整 sprint 还长。能跑 16 天不崩，靠的就是这种严格的交接纪律。
不同角色用不同模型
这个点也很关键。规划需要慢而审慎的推理，实现需要代码流畅度，验证需要精确的指令遵循。甚至验证者可以用完全不同的模型提供商，避免相同训练数据带来的偏见累积。Luke 他们管这个叫 "机器人耳语术"，理解不同 LLM 怎么交互、在哪里失败、失败如何在连续几天的运行中叠加放大。这不是调参数，这是在对不同模型的性格做编排。
编排逻辑几乎全在提示词里
这意味着每次模型升级，系统都会自动变强，不需要重写代码。通过这种多智能体架构，一个五人团队以前同时处理 10 条工作流，现在能跑 30 条。
