Mission 是如何打造Multi-Agent 系统的

📝

/images/Mission-是如何打造Multi-Agent-系统的/46381e0bc694。jpg Luke Alvoeiro 在 AI Engineer 的一场 18 分钟演讲里抛了一个判断，今天做软件工程的瓶颈不再是智能，而是人的注意力

原文链接：https://mp.weixin.qq.com/s/Yxthv6KXRefxqcd_XUvGZg

Luke Alvoeiro 在 AI Engineer 的一场 18 分钟演讲里抛了一个判断，今天做软件工程的瓶颈不再是智能，而是人的注意力。他给这句话附上了具体的场景，一个工程师手头可能积压 50 个 feature，但每天真正能往前推的只有两三件，因为每件事都要他分神、每次 commit 都要他 review。今天的模型已经聪明到足以搞定这 50 件事的方案，真正缺的是监督它们落地所需的人力带宽。

这个判断是 Luke 演讲的起点。他在 Block 时做出了开源 coding agent Goose，这个项目现在在 GitHub 上拿了 43.9k 颗星，几个月前被捐给了 AI Agentic Foundation。Luke 离开 Block 之后去了 Factory，现在负责那里的核心 agent harness。Factory 是一家 2023 年成立、今年 4 月刚完成 Series C 融资的 AI coding 公司，投资人包括 Khosla、Sequoia、Insight Partners 和 Blackstone，估值 15 亿美元，产品叫 Droid。Luke 这次要讲的，是 Droid 背后那套叫 Mission 的多 agent 编排系统。

整场演讲的价值不在产品介绍，而在方法论。Luke 用 18 分钟回答了一个问题，当你想让 agent 团队完成比单个 agent 难上一两个数量级的任务时，应该怎么把它组织起来。这个问题对所有正在尝试做长任务、多 agent 流水线的产品团队都适用，不只限于 coding agent。

Multi-Agent 常见架构

当下 multi-agent 领域的一个共识是，它非常混乱。每家公司都有自己的框架、自己的术语、自己对「什么有用」的判断。Luke 把这些收敛成五种前沿策略。

第一种是 delegation（委派），父 agent 派生子 agent 拿返回值，sub-agent 和 coding tool 的 tool call 是最常见的实现。

第二种是 creator-verifier（创建者与验证者），一个 agent 建、另一个 agent 查，核心逻辑是关注点分离，因为写代码的那个 agent 天然想让自己的代码跑通，新鲜上下文的 agent 更容易挑出问题。

第三种是 direct communication（直接通信），agent 互发私信，没有中央协调者，听起来灵活但很难做对，状态会散落在多条对话里。

第四种是 negotiation（协商），agent 围绕一个共享资源沟通，比如要用同一个 API、要改代码库同一块，最好的场景是有正和交易空间。

第五种是 broadcast（广播），一对多，用来做状态更新、共享约束的下发，对长任务的连贯性至关重要。

Mission 用了其中四种（省掉了 direct communication）加上了一个三角色的架构。

orchestrator 负责规划，它像一块共鸣板，在对话里向你提出战略问题，梳理模糊需求，最后产出一份执行计划，里面有 feature 清单、里程碑，以及一个叫 validation contract 的东西。

worker 负责实现，每个 feature 派一个 worker，worker 拿到的是完全干净的上下文、零包袱、满格的注意力，做完之后通过 Git commit，下一个 worker 接手的是一个干净状态和一个能跑起来的代码库。

validator 负责验证，分成两种，一种是 scrutiny validator，跑 lint、类型检查、测试，外加为每个 feature 派独立的 code review agent；另一种更有意思，叫 user testing validator，它的行为像一个 QA 工程师，把应用真的跑起来，通过 computer use 之类的能力填表单、点按钮、看页面渲染，做端到端的行为验证。两种 validator 都没看过代码，验证从设计上就是对抗性的。

Validation Contract 才是这场演讲真正要讲的东西

Luke 花了最多时间讲的就是 validation contract 这个概念。他讲它是因为他见过太多这样的 agent 行为，写完一个 feature 顺手写点测试，测试跑通、覆盖率漂亮。但这些测试是按实现出来的代码反向捏的，不是按代码本该实现什么写的。他的原话是，写在实现之后的测试抓不到 bug，它们只是在确认已经做出的决定。一旦你的系统依赖这种测试做验证，它早晚要跑偏。

Validation contract 的解法是，在任何代码写下去之前、规划阶段就把正确性定义清楚。复杂项目里可能有几百条断言，每个 feature 被分配一条或多条必须满足的断言，所有 feature 加起来必须覆盖全部断言。这是一个独立于实现的锚点。跟它配合的是结构化的 handoff，worker 做完一个 feature 时填一份详细文档，里面写清楚完成了什么、哪些没做完、跑过哪些命令、这些命令的退出码、发现了什么问题、有没有遵守 orchestrator 给它定的 SOP。错误在里程碑边界被捕获，纠错工作被明确界定，mission 自己把自己拉回正轨。关键机制不依赖 agent 记得发生过什么，它靠的是强制 agent 把这些东西写下来。

这两件事组合在一起，让 Factory 的最长一次 mission 跑了 16 天。Luke 说他们相信这套架构有能力跑到 30 天。验证独立于实现、交接强制结构化，这两件事是 Luke 这场演讲里最值得带走的方法论，适用于任何想让 agent 持续运行好几天的产品，不局限于 coding。

串行比并行好，这个结论违反所有人的第一反应

做 multi-agent 的人第一反应都是并行，10 个 agent 同时跑就是 10 倍吞吐。Factory 试过，结论是软件工程这类任务域并不适合纯并行。agent 会互相踩改动、重复做事、做出互相冲突的架构决定，协调 overhead 吃掉速度收益，token 还在哗哗地烧。

Mission 的做法是 feature 层面串行，同一时刻只有一个 worker 或一个 validator 在跑。允许并行的只有两类场景，一类是 feature 内部的只读操作，比如在代码库里搜索、查 API 文档；另一类是 validator 内部的只读操作，比如多个 code review 同时进行。整体上是串行执行加定点内部并行。纸面上看更慢，但错误率大幅下降，长任务里正确性会不断复利。

这个判断对国内正在做企业流程自动化的团队有直接参考意义。很多团队被 agent swarm、多 agent 协同这些术语带着走，默认选了并行。Factory 的生产数据指向另一条路，在强耦合、共享状态的任务域里，串行加定点并行更便宜、更正确、更可解释。

紧挨着这个串行判断的是模型选择的判断。Luke 给「给每个角色挑合适模型」这件事取了个名字，叫 droid whispering。规划需要慢速、审慎的推理，实现需要快速的代码流畅度和创造力，验证需要精确的指令遵循，没有哪家模型厂商能在三件事上都做到最好。更进一步，如果 validation 用了跟 implementation 不一样的模型厂商，就避免了同一份训练数据带来的同向偏见。你被某一家模型锁定，这个家族最弱的能力就是你系统的天花板。反过来，Mission 的结构还能反向补偿模型，就算用开源权重的模型，只要 validation contract 和里程碑检查点都在，mission 依然能跑成功。

做 multi-agent 系统的人都有一种恐惧，下一版模型一发布，自己的架构一夜过时。Factory 的解法是把几乎所有编排逻辑写在 prompt 和 skill 里，避开硬编码的状态机。整套 feature 拆解和失败处理加起来大约 700 行文本，改四句话就能大幅改变执行策略。worker 的行为由 orchestrator 每个 mission 动态定义的 skill 驱动。真正的确定性代码层非常薄，只做 bookkeeping，比如跑验证、在交接未处理时阻塞进度。Luke 把这件事总结成一句，mission 负责提供纪律，模型负责提供智能。

这个取向值得对照 Anthropic 前段时间的 Skills 方向来看。Anthropic 的口号是不要造 agent、去造 skill，Factory 的口号是纪律放在系统里、智能放在模型里，双方共用的原语是 agents.md 和 skills 这些已经被模型熟悉的东西。两家都在往一个方向收，编排逻辑尽量声明式、尽量用 prompt 写、尽量让模型升级自动带动系统升级。在 2026 年，这正在成为 agent 基础设施层的主流判断。

Luke 用一个用 Mission 克隆 Slack 的案例给出了一些具体数字。60% 的时间花在 implementation，60% 的 token 消耗也在 implementation。验证从来没有一次过，几乎每个里程碑都要追加 follow-up feature 来修。最终代码库里 50% 行数是测试代码，代码覆盖率 90%。prompt cache 被大量用来抵消长任务的成本。一个有意思的观察是，mission 绝大部分 wall clock time 不花在生成 token 上，它花在 user testing validator 和真实应用交互的等待上。Luke 也给了一组经济账。以前一支 5 人工程师团队同时能推 10 条工作流，现在用 mission 可以推 30 条，团队的注意力从执行本身前移到架构和产品决策这一层。另一个容易被忽略的红利是，mission 跑完之后代码库比开工时更干净，端到端测试、单元测试、skill 文件、结构性产物全都留下来，后续无论是 agent 还是人在这个环境里工作都更高效。

几点起发启发

一个是验证和实现要分家，还要分到不同模型厂商。让同一个模型既做实现又做验证，这会丧失系统里最重要的对抗性红利。

另一个是跨 agent 的 handoff 必须强制结构化。口头交接不行，JSON 随便塞也不行。严格定义要填哪些字段，至少包含完成项、未完成项、执行过的命令和退出码、发现的问题、SOP 遵守情况。这是最低成本、最容易落地的改造，做任何长任务 agent 产品都可以直接照抄。

第三是 validation contract 这种「在代码之前敲定正确性」的做法可以迁移出 coding 场景。做报告生成、做市场研究、做多日复杂流程的自动化时，都可以先写几百条断言，把怎样算做完锁死在实现前面。这能解决 agent 系统跑着跑着越来越偏、最后不得不人工 debug 的问题。

第四是编排逻辑尽量往 prompt 和 skill 里搬。Luke 那 700 行文本改四句话就能改写系统行为，这是国内团队少有的工程纪律。大多数国内产品团队更习惯把流程逻辑写进代码和状态机，等到模型升级就得重写一轮。

内容来源，AI Engineer 频道「The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory」，YouTube 链接 https://youtu.be/ow1we5PzK-o

---

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。