他们让AI团队连续干活16天：多智能体真正能“交付”的秘密

大多数多智能体系统只能跑Demo，但Luke Alvoeiro讲的“Missions”却让AI连续工作了16天还没崩。更反直觉的是：关键不是模型更强，而是结构更“啰嗦”。这场演讲把多智能体从玩具，拉进了工程现实。

一个让全场安静下来的事实：他们的AI连续工作了16天

Luke在台上抛出的最炸裂一句话，不是模型有多强，而是时间：他们最长的一次 mission，跑了整整16天。不是挂机，不是单一脚本，而是一个由多个AI角色组成的系统，持续接需求、写代码、验证功能、修Bug。

这直接戳中了多智能体系统的痛点。行业里大家都在玩agent，但大多数只能“跑一会儿”：一旦任务复杂、周期拉长，系统就开始发散、遗忘上下文，或者产出质量一路下滑。Luke的核心判断很直白：问题不在于agent不聪明，而在于我们给它们的“工作制度”太糟糕。

于是，Missions这个概念出现了——不是一个新模型，而是一套让多智能体能“像团队一样干活”的工程化结构。

多智能体的五种经典模式，为什么都不够用

Luke先快速拆解了当前主流的多智能体协作方式：
- Delegation（委派）：一个agent把子任务分给其他agent；
- Creator-Verifier（创作-验证）：一个写，一个查；
- Direct Communication（直接对话）；
- Negotiation（协商）；
- Broadcast（广播式协调）。

这些模式你可能都见过，甚至已经在用。但Luke的结论很犀利：它们更像“协作技巧”，而不是“长期交付结构”。它们解决的是一次任务怎么配合，却没解决一个现实问题——当任务跨天、跨版本、跨多个功能里程碑时，系统如何保持纪律？

Missions的设计目标正是这里：把这些零散的协作模式，收敛进一套可以反复运行、持续交付的框架里。

三种角色，把AI变成“有纪律的团队”

Missions的核心，是一个三角色架构：

第一是 Planner（规划者）。它不写代码，负责把人类的模糊需求，拆成一系列有明确边界的功能里程碑。

第二是 Workers（执行者）。真正写代码、实现功能的agent，可以有多个，但他们只对当前里程碑负责。

第三个也是最反直觉的：Validators（验证者）。而且不是一个，是两个。更关键的是——验证者在验证前，从未看过代码。

这点非常“反人性”。在很多系统里，验证只是走形式，或者验证者已经被上下文污染。Missions通过所谓的 validation contract 强制规定：每完成一个里程碑，必须由两个“冷启动”的验证agent独立检查结果。

结果很直接：Bug被提前抓出来，错误不会在系统里层层放大。这也是为什么他们能把mission拉到十几天，而不是十几个小时。

为什么他们坚持“串行执行”，反而跑得更远

另一个和直觉相反的设计是：Missions不追求全局并行，而是功能级别的串行执行。

Luke明确说，他们是 serial execution with targeted internal parallelization（串行功能 + 内部并行）。也就是说：功能一个一个来，但在单个功能内部，允许agent并行探索实现路径。

这解决了多智能体常见的“并行混乱”：多个agent同时推进不同功能，最后合不回去。Missions宁愿慢一点，也要保证每一步都被验证、被锁定。

配合这个流程，他们甚至专门做了一个 Mission Control，而不是用普通聊天界面。原因很简单：聊天窗口根本承载不了一个持续数天、包含多个角色和状态的工程流程。

总结

Luke这场演讲最有价值的地方，不是某个技巧，而是一种判断：多智能体系统的瓶颈，正在从“模型能力”转向“组织能力”。如果你想让AI真正参与长期项目，重点不该是再换一个更大的模型，而是：角色是否清晰？验证是否独立？流程是否允许长期运行而不失控。

对从业者的直接启发是：下次设计agent系统时，别急着堆并行和prompt花活，先问自己三个问题——任务能否被拆成里程碑？每一步有没有冷启动的验证？系统能不能跑三天不需要人盯？

如果答案是否定的，那它大概率只是个Demo，不是生产系统。

关键词： 多智能体系统， AI Agent， Missions， 验证机制， 工程化AI

事实核查备注： 需要核查：1）最长mission运行16天的具体语境；2）三角色架构的正式命名是否为Planner/Worker/Validator；3）validation contract的具体定义；4）Mission Control是否为内部工具名称；5）演讲者Luke Alvoeiro在Factory的职位背景