如何用 Agent Teams 完成单 Agent 不可能的任务。Luke 这场演讲，核心其实就一句话：
软件工程的瓶颈已经不再是智能，而是人类注意力。
顶级工程师一天也只能推进少数几个任务，但现实里的 backlog 可能有 50 个功能、20 个 bug、10 个 migration、还有一堆遗留系统需要清理。模型已经越来越聪明，理论上很多任务都能做，真正缺的是：长时间、低监督、可验证地执行复杂任务的能力。
Luke 的目标很直接：听完这 20 分钟，你应该能理解怎么组装一个 Agent 团队，让它跑几天，完成单个 Agent 做不了的复杂软件工程任务。
背景也很硬：Luke 之前从 Block 孵化出 Goose，这个项目现在已经捐给 Agentic AI Foundation；他现在在 Factory 负责核心 Agent Harness，目标是让整个软件开发生命周期逐步走向自治。
多 Agent 不是堆几个 Bot，而是一套协作模式
现在多 Agent 框架非常混乱，大家都在说 multi-agent，但具体是什么意思并不统一。Luke 先做了一件很有价值的事：给前沿模式做了一个 taxonomy。
他把多 Agent 协作拆成五种典型模式。
第一种是 Delegation，也就是父 Agent 派生子 Agent。比如主 Agent 发现当前任务需要数据库设计，就派一个子 Agent 去专门设计 schema。这是最常见的模式，也是很多工具最先支持的模式。
第二种是 Creator-Verifier。一个 Agent 负责写代码，另一个完全独立的 Agent 负责审查。这个模式的关键是解决 sunk cost bias。写代码的 Agent 很容易为自己的实现辩护，而独立验证者没有这个心理包袱，更容易发现问题。
第三种是 Direct Communication，也就是 Agent 之间直接聊天。听起来很自然，但实际上很难，因为状态会变得碎片化，没有单一真相来源，最后很容易出现“每个 Agent 都以为自己知道全局，但其实没人真的知道”的情况。
第四种是 Negotiation。当多个 Agent 围绕共享资源工作时，比如同一个 API、同一个模块、同一段代码，就需要协商。好的协商不是互相阻塞，而是找到正和解法。
第五种是 Broadcast。一个 Agent 向全体推送新的约束、状态更新、计划变化。这个模式对长期任务特别重要，因为任务一旦跑几天，最怕的就是上下文漂移。Broadcast 的价值就是让整个系统持续对齐。
这五种模式看起来简单，但后面 Factory 的 Missions 系统，本质上就是把它们组合成了一个可以长期运行的闭环。
Missions：不是一个 Agent Session，而是一个 Agent 生态系统
Factory 的核心系统叫 Missions。
它不是一个更长的 Agent Session，也不是把上下文窗口硬撑大，而是一个由多个角色、共享状态、结构化交接和验证机制组成的 Agent 生态系统。
Missions 里有三个核心角色：**Orchestrator、Workers、Validators。**Missions 中有三个核心角色：协调者（Orchestrator）、执行者（Workers）和验证者（Validators）。
Orchestrator 是指挥官。它在对话里帮你 scope 需求，提出战略问题，把模糊目标变成可执行计划。最重要的是，它会在写代码前输出两个东西：Plan 和 Validation Contract。
Plan 是怎么做。Validation Contract 是“什么叫做 Done”。
这点非常关键。传统 Agent 很容易写完代码以后再补测试，最后测试会迁就实现，而不是真正验证需求。Missions 反过来，在实现之前就定义验收标准。
Workers 是工人。它们拿到干净上下文，负责实现具体特性。一个 Worker 做完以后提交 Git Commit，然后下一个 Worker 继承的是一个干净代码库，而不是一坨混乱聊天记录。
Validators 是验证者。它们不负责帮你圆场，而是严格验证任务是否真的完成。
这里最大的创新是：Validation Contract 在规划阶段提前写好。
它可能包含几百条独立于实现的断言，每条特性都绑定对应断言。里程碑完成后，系统必须证明这些断言被覆盖，而不是“看起来差不多”。
验证体系，才是长期任务不漂移的核心
Agent 写代码最大的问题，往往不是第一步写不好，而是长期任务会漂移。
一开始方向是对的，写着写着就偏了；再写一会儿，测试也开始迁就实现；最后系统看起来很忙，但离真实目标越来越远。
Missions 的验证体系，就是为了解决这个问题。
第一类验证者叫 Scrutiny Validator。它会跑测试、类型检查、Lint，还会为每个特性 spawn 独立的 Code Review Agent。这个 Code Review Agent 是全新上下文，没有参与过实现，所以更像一个真正的外部 reviewer。
第二类更强，叫 User Testing Validator。它像 QA 一样启动应用，用 Computer Use 真实点击页面、填写表单、走完整流程。也就是说，它不是只看代码，而是像用户一样验证产品到底能不能用。
这两类验证都是对抗性的。验证者没见过实现过程，也没有 sunk cost，所以不会天然站在实现者这边。
Luke 提到一个很重要的数据点：验证阶段会占掉大部分 wall clock time，但这正是长期任务能跑下去的关键。它牺牲了一些速度，换来的是长期正确性。
结构化 Handoff：不是靠记忆，而是靠强制写下来
要让任务跑几天，甚至十几天，最危险的不是模型不聪明，而是信息丢失。
所以 Missions 很重视 结构化 Handoff。
每个 Worker 完成特性后，都必须填写交接单。里面要写清楚：完成了什么，留下了什么，运行过哪些命令，对应 exit code 是多少，发现了什么问题，是否遵守了 Orchestrator 定义的流程。
这听起来像繁琐流程，但它解决的是长期任务里最致命的问题：系统不能靠记忆运行，必须靠结构化记录运行。
在里程碑边界，系统会检查所有 handoff。如果发现未解决问题，就会自动创建 Follow-up Features，把任务拉回正轨。
这就是 Missions 的自愈机制。它不是指望 Agent 永远不犯错，而是默认 Agent 会犯错，然后用结构化交接和里程碑检查把错误及时暴露出来。
Luke 说，最长的 Mission 已经跑了 16 天，目标是跑到 30 天。这个数字本身就说明：长期 Agent 系统的核心，不是更大的 prompt，而是更强的交接和验证纪律。
为什么不是全并行？因为软件工程不是简单分包
早期他们也尝试过全并行，但失败了。
原因很现实：冲突、重复劳动、架构不一致。多个 Agent 同时改代码，看起来很快，但最后合并和修复成本会爆炸。
所以 Missions 采用的是一种更克制的策略：Serial 主干 + 局部并行。
特性层面是串行的。同一时间只有一个 Worker 和对应 Validator 在推进主干任务，保证代码库的演化是连续的、可理解的。
但只读操作可以并行，比如代码搜索、API 调研、Code Review。这些任务不会直接修改主干，所以并行收益很高，风险也更低。
这个设计特别像真实工程团队：核心架构和主线开发要有顺序，但调研、审查、资料收集可以并行。它没有追求表面的最大并发，而是在追求长期正确性的复利。
Mission Control：多天任务需要专属仪表盘
当一个任务要跑几天，传统聊天窗口就不够用了。
所以 Factory 做了 Mission Control，一个专门给长期任务看的仪表盘。
你可以实时看到当前 Worker 在干什么，Handoff 摘要是什么，下一步计划是什么，项目完成度到哪了，Token 预算消耗了多少。
更重要的是，它支持完全异步。你可以去睡觉、陪朋友、开会，系统继续跑。等你回来，不是面对一大段聊天记录，而是看到结构化状态：当前在哪、完成了什么、卡在哪里、下一步做什么。
这也是 Agent Harness 和普通 Chatbot 的区别。Chatbot 是对话界面，Harness 是任务运行系统。
模型选择是一门艺术：Droid Whispering
Luke 把模型选择称为 Droid Whispering，这个说法很形象。
没有一个万能模型适合所有角色。Planning 需要慢思考强模型，因为它要做战略拆解和约束设计。Implementation 需要代码流畅、创造力强的模型，因为它要快速落地。Validation 则需要精确遵循指令的模型，因为它必须严格按照验收契约检查结果。
他还建议，不同角色最好使用不同 Provider，避免同源偏差。比如一个模型家族负责写，另一个模型家族负责审，这样更容易发现盲点。
更有意思的是，Missions 的结构化架构也能让开源模型跑得不错。因为 Validation Contract、里程碑检查、Handoff 这些机制提供了纪律。换句话说，系统不是完全依赖模型自己“自觉”，而是用架构约束模型行为。
真实案例：从 0 造一个 Slack Clone
Luke 举了一个真实案例：从 0 构建 Slack Clone。
在这个任务里，大约 60% 的时间和 Token 花在 Implementation 上。但 Validation 几乎从来不会一次通过，系统会自动创建 Follow-up Features，继续修复和推进。
最终结果是，代码里大约 50% 是测试，覆盖率超过 90%。这点很有意思：Agent 不是只产出更多代码，而是在验证机制驱动下产出更可维护的代码库。
他们还大量使用 Prompt Caching 控制成本，否则这种长期任务的 Token 消耗会非常夸张。
企业真实用法也很清晰：一夜之间原型一个新特性，大型 Refactor 或 Migration，现代化老代码库，让后续 Agent 更容易接手。
这类任务恰恰是单 Agent 最容易崩的任务：周期长、依赖多、上下文复杂、验证困难。而 Missions 的价值，就是把这些任务拆成可交接、可验证、可恢复的长期执行流。
架构哲学：拥抱 Bitter Lesson
这场演讲最让我有感触的一点，是 Luke 对系统架构的取舍。
他们没有把所有编排逻辑写成复杂的硬编码状态机，而是把大量逻辑写在 Prompt + Skills 里，整个系统只有大约 700 行文本。
为什么？
因为这样可以拥抱 Bitter Lesson：模型升级时，系统会自动变强。
如果你把太多智能写死在代码里，模型变强反而吃不到红利。但如果你把行为模式、角色定义、协作协议写在 prompt 和 skills 里，那么模型越强，整个系统越强。
当然，它不是完全没有确定性逻辑。Missions 仍然保留了一层很薄的硬逻辑，比如 Handoff 检查、阻塞条件、里程碑边界。但除此之外，它尽量把智能留给模型。
这也是未来 Agent Harness 很可能会走向的方向：确定性逻辑负责边界和纪律，模型负责判断和执行。
真正改变的，是软件工程的经济学
Missions 最终改变的不是“一个 Agent 能写多少代码”，而是团队的吞吐量模型。
Luke 的说法是，一个 5 人团队原来可能同时推进 10 个工作流，有了 Missions 以后，可能可以推进 30 个。
这不是因为人类突然变成 3 倍努力，而是因为人类从执行中解放出来，转向更高杠杆的位置：架构判断、产品决策、验收标准、优先级排序。
执行交给系统，验证交给系统，交接交给系统，自愈也交给系统。人类真正负责的是定义方向和做关键判断。
更重要的是，Missions 产出的代码库不是越跑越脏，而是可能比开始时更干净。因为它会留下测试、结构、Skills、Handoff 和验证契约。这些东西会形成正向飞轮，让后续 Agent 更容易继续工作。
一句话总结
Missions 本质上是 Delegation、Creator-Verifier、Broadcast、Negotiation、结构化 Handoff 和 Validation Contract 的组合。
它真正厉害的地方，不是让 Agent 看起来更聪明，而是把“人类定义要什么”和“系统自主执行多天”彻底解耦。
人类负责 scope、计划、验收和关键决策；Agent 团队负责实现、验证、交接和修复。
这才是 multi-agent 真正有价值的地方：不是几个 Agent 在聊天室里互相聊天，而是一个可运行、可验证、可恢复的生产系统。
Luke 最后的建议也很实在：可以去 Open Droid 试 /missions，先跟 Orchestrator 吵清楚 Scope，认真批 Plan，然后就可以去做别的事了。
他最后那句话很值得记住：
未来能建立起“不同模型在长期高压任务下如何协同”这种直觉的人，会引领下一代创新。
更多 AI Engineer 精彩演讲，欢迎前往 Podwise 免费获取系列拆解