Factory Missions: The Multi-Agent Architecture That Ships for Days

概述

2026 年 5 月，在 AI Engineer London 大会上，Factory 的 Luke Alvoeiro 抛出了一个在 AI 基础设施圈持续发酵的论点："软件工程的瓶颈不再是模型的智能水平，而是人类的注意力带宽。"

本文深度拆解 Factory 的 Missions 架构——一个让多 Agent 系统自主运行 16 天、构建出 Slack 克隆版、测试覆盖率达 89.25% 的工程系统。我们将从设计原理、生产数据、架构取舍三个维度，分析这对每一个正在构建 Agent 基础设施的人意味着什么。

核心问题：上下文的"毒性"

Factory 官方架构文档（作者 Theo Luan）对问题的定义非常精确：Agent 对上下文高度敏感。Agent 的执行轨迹是只追加的——模型在任一点的推理，是其迄今为止看到的每一个思考、每一次观察、每一步操作的函数。模型天然寻求连贯性，会把上下文中的一切整合成一个统一的世界观。

这导致了两种致命失败模式：

• 上下文稀释（Context Dilution）——随着任务范围变宽，无关信息不断堆积。Factory 给出了量化数据：聚焦任务中，有用信号占 88%；宽泛任务中，信号占比暴跌至 38%。近三分之二的上下文变成了噪音。
• 自我评估偏差（Self-Evaluation Bias）——一个实现了某段代码的 Agent，天然无法客观评估自己的工作。它在实现过程中积累的推理步骤形成了一个"引力场"，后续的评估被这个场锚定，倾向于确认而非发现错误。

Missions 架构全景

Missions 不是一个单 Agent 会话。它是以三个角色严格分工的 Agent 生态系统：

角色定义（比你想象的更严格）

关键约束：两个验证器都从未见过代码实现。它们带着全新的上下文进入，这使得验证天然具有对抗性——就像人类做 Code Review 时，审查者比实现者更容易发现问题。

两个层次的 TDD——最被低估的设计

这是 Missions 架构中最精巧、也最容易被忽视的创新。TDD 在两个尺度上同时运作：

微观层（Worker 级别）：每个 Worker 先写测试再写代码，确保测试反映的是意图行为（intended behavior），而非实现细节。彻底消除了"测试跟着代码走"的确认偏差。

宏观层（Mission 级别）：编排器在定义任何 Feature 之前，先撰写一份 验证合约（Validation Contract）——一组可测试的行为断言，独立于实现定义"什么是正确"。

这个顺序约束至关重要：如果编排器先创建了 Feature，验证合约就会不可避免地被它已经形成的实现方案所污染。先定义"对"，再分解"怎么做"——这个顺序本身就是一道防火墙。

验证合约长这样：

### VAL-AUTH-001: 登录成功
拥有有效凭证的用户提交登录表单后，
被重定向到 dashboard。
工具：agent-browser
证据：截图, network(POST /api/auth/login -> 200)

### VAL-CROSS-001: 认证控制定价页可见性
未登录用户在 catalog 页看到"登录后查看价格"。
登录后，真实价格展示。
工具：agent-browser
证据：screenshot(未登录视图), screenshot(已登录视图)

这些断言由用户测试验证器（User-Testing Validator）以黑盒方式验证——启动真实应用、通过 computer use 交互、填写表单、点击按钮、验证端到端功能流程。如 Luke 在演讲中所说："Missions 的大部分 wall clock time 其实花在这里——等待真实世界执行发生，而非生成 token。"

结构化 Handoff：系统的结缔组织

Worker 完成一个 Feature 时，不会只说"做完了"。它必须填写一份结构化 Handoff，包含：

• 完成了什么、未完成什么
• 执行过的每一条命令及其退出码
• 实现过程中发现的问题
• 是否遵循了编排器定义的操作规程

这就是系统自我修复的机制。错误在 Milestone 边界被捕获。编排器将纠正工作转化为 Fix Feature 分配给新 Worker。系统自己把自己拉回正轨——"不是靠 Agent 记住发生了什么，而是强制它们写下来，然后真正去解决问题。"

串行执行——反直觉的正确选择

并行看似理所当然：10 个 Agent = 10 倍吞吐量。Factory 试过了。行不通。

• Agent 在共享代码上发生冲突
• 重复工作大量出现
• 架构决策不一致
• 协调开销吞噬了速度收益，同时狂烧 token

Missions 采用 串行执行 Feature——同一时间只有一个 Worker 或 Validator 在运行。但在 Feature 内部，只读操作（代码搜索、API 调研）被并行化。在验证阶段，Code Review 跨 Feature 并发执行。

"纸面上看起来更慢，但错误率大幅下降。当任务需要跑很多天时，这种正确性的复利效应远超并行带来的表面加速。"

生产数据：构建一个 Slack 克隆版

Factory 官方博客提供了完整 Slack 克隆版构建的精确指标：

• 38,800 行代码——其中 52.5% 是测试（20,400 行测试 / 18,500 行业务代码）
• 89.25% 语句覆盖率
• 7.785 亿总 token（其中 7.449 亿是缓存读取——Prompt Caching 是成本控制的关键）
• 185 次 Agent 运行：63 次 Worker、27 次 Validator（含 82 个子 Agent）、1 次编排器（含 12 个子 Agent）
• 中位轨迹长度：实现 51 轮（P90=123），验证 30 轮（P90=37）

可靠性闭环

6 个 Milestone 中，0 个在第一轮验证通过。每个 Milestone 需要 2-4 轮验证才能收敛。验证器共发现 81 个问题（65 个阻塞级、11 个非阻塞、5 个建议），编排器将其转化为 21 个 Fix Feature——占实现总工作量的 34.4%。

这个数字——超过三分之一的工作是修复——既令人震撼，又令人清醒。震撼是因为系统自主发现并修复了这些问题，清醒是因为它揭示了 Agent 生成代码的固有错误率。

Droid Whispering：一种新的工程技能

Luke 提出了一个他称之为 "Droid Whispering"（机器低语者） 的概念——一种能够在大脑中模拟不同 LLM 如何交互、在哪些点会失败、这些失败如何在多天运行中复合并放大，然后有意识地选择哪个模型坐在哪个位置上的能力。

• 规划（Planning）→ 需要慢速、谨慎的推理 → 顶尖推理模型
• 实现（Implementation）→ 需要快速的代码流畅性和创造力 → 高性价比编程模型
• 验证（Validation）→ 需要精确的指令遵循 → 甚至使用不同的模型提供商，消除相同训练数据的偏差

"没有一个模型或模型提供商能在这三者上都做到最好。如果你被锁定在一个模型提供商上，你就被那个模型家族最弱的能力所限制。"

"苦涩教训"安全网

每个多 Agent 系统的构建者都怕下一个模型版本一夜之间让自己的架构过时。Factory 的防御策略：编排逻辑几乎全在 Prompt 和 Skill 中，而非硬编码的状态机。

"特征分解和失败处理的所有逻辑，大约在 700 行文本里。其中四句话的改动，就能显著改变执行策略。"

唯一确定性的逻辑是非常薄的簿记层——运行验证、当 Handoff 标记问题时阻塞进度。真正的智能在 Prompt 中，意味着每一次模型升级都自动提升整套系统的能力。

五种通信模式，全部编排其中

Alvoeiro 提出的多 Agent 通信模式分类法，在 Missions 中全部被有机组合：

1. 委派（Delegation）——编排器生成 Worker 和调研子 Agent
2. 创作者-验证者（Creator-Verifier）——实现和验证永远是不同的 Agent，拥有不同的上下文
3. 广播（Broadcast）——所有 Agent 共享同一份 Mission 状态
4. 协商（Negotiation）——在 Milestone 边界，编排器根据验证合约审查 Handoff 摘要的正确性
5. 直接通信（Direct Communication）——为特定场景保留；状态碎片化是主要风险

"策略本身不够。你需要结缔组织——结构化 Handoff、每个角色匹配正确的模型、以及一个随每一代模型改进而自动进步的架构。"

对 Agent 基础设施的启示

如果你在构建 Agent 编排系统（Hermes、OpenCode、OmO、自定义 Harness），以下是 Factory 的工程手册中可以直接借鉴的东西：

1. 验证合约层（Validation Contract）——在"怎么做"之前定义"什么算对"。用全新上下文的独立验证器来执行。这是目前大多数 Agent 系统最缺失的一环。
2. 结构化 Handoff——子 Agent 的返回结果必须包含：完成了什么、未完成什么、执行的命令和退出码、发现的问题。自由文本摘要在多天自主运行中完全不够用。
3. 按角色选模型——编排器用 Pro（昂贵推理），执行器用 Flash（低成本执行），验证器应该用不同的模型提供商来消除训练数据相关性偏差。
4. 串行 Feature 执行——代码修改上的并行带来的协调成本远超收益。并行化读操作即可。
5. Prompt 驱动的编排——硬编码状态机会僵化。Prompt 驱动的逻辑随每次模型发布自动提升。这是多 Agent 系统的"苦涩教训"。

结论

Factory 的 Missions 证明了一件事：多天自主软件开发不是研究幻想，而是今天的工程现实。但真正的洞察不在于"更好的模型"——在于更好的编排：如何拆分工作、独立验证、以及让 Agent 在连续数天的运行中不互相踩脚。

随着模型持续进步，竞争优势从"谁拥有最聪明的模型"转移到"谁拥有最聪明的模型组合"。赢家将是那些用 Agent 生态系统而非单 Agent 会话的视角思考问题的人。

"发展出对不同模型在压力下如何组合的直觉的人——将是下一代创新的真正推动者。"

系列文章：

1. 本文 — Factory Missions：真正能交付的多 Agent 架构
2. AI 时代，开发者是否还需要 IDE？
3. Agent 时代开发环境的核心技术依赖

来源：

• Luke Alvoeiro — "Missions: Multi-Agent Systems That Ship for Days", AI Engineer London 2026（YouTube 视频）
• Theo Luan — "How Missions Work", Factory Engineering Blog, 2026 年 4 月（factory.ai）
• Factory AI — 官方文档