一句话：Factory（＄1.5B 估值，Khosla 领投）的 Luke Alvoeiro 在 AI Engineer Europe 2026 上公布了 Missions 架构——一个 Orchestrator 规划任务、Workers 写代码、Validators 独立验证的多 Agent 系统。核心悖论：并行执行看似更快，串行执行更可靠。正确性在时间长河中产生复利。最长运行 16 天，90% 测试覆盖率。客户包括 Nvidia、Adobe、Morgan Stanley。

一、瓶颈不是 AI 不够聪明，是人盯不过来

Luke Alvoeiro 的开场白很直接：软件工程的天花板不是机器智力，是人的微观注意力。

一个资深工程师同时能盯几件事？三到五件。再多，质量就断崖。但一个复杂项目需要数百个决策——架构选型、接口设计、测试策略、边界条件处理。这些决策中，大部分是"可程序化的"，但人不得不一一过目。注意力耗尽之后，bug 就趁虚而入。

AI coding 工具（Claude Code、Cursor、GitHub Copilot）解决了一部分问题——写代码更快了。但它们的模式是"你问我答"：你给 prompt，它给代码，你审阅。这并没有解放你的注意力，只是把"写"的时间压缩了，"审"的时间没有变。

Missions 的假设是：如果 AI 能自己规划、自己执行、自己验证，人只需要在关键节点做决策，那么一个工程师可以 oversee 的复杂度，不是 3-5 个任务，而是 30-50 个——甚至上百个。

二、多 Agent 的五种策略，Missions 整合了四种

Alvoeiro 先画了一张多 Agent 策略的地图：

Missions 的架构整合了前四种（Delegation、Creator-Verifier、Broadcast、Negotiation），但不包括 Direct Communication。原因是：无中心协调会导致状态碎片化——每个 Agent 有自己的局部认知，没有单一真相源。

三、三角色架构：Orchestrator、Workers、Validators

3.1 Orchestrator（协调者）

Orchestrator 不是"项目经理"，而是使命架构师。它做三件事：

1. 规划：把用户目标拆成 milestones，每个 milestone 拆成 features
2. 验证契约：在写任何代码之前，定义一组行为断言——"什么算成功"
3. 决策：当 Workers 或 Validators 返回问题时，决定下一步行动

关键约束：Orchestrator 不直接写代码，也不直接验证。它把具体工作全部委派给 subagents。这保证了它的上下文不会膨胀到"知道每一行代码的细节"。它只需要知道"大局是否仍在轨道上"。

Orchestrator 的 system prompt 有 51KB——这是一个巨大的结构化指令，包含了 Factory 积累的所有工程知识、模式、陷阱、最佳实践。

3.2 Workers（工作者）

Workers 是执行者。每个 Worker 只负责一个 feature，从 fresh context 启动——不继承前一个 Worker 的上下文。它读到的只有：

• mission.md（全局目标）
• AGENTS.md（操作规范）
• SKILL.md（该 Worker 类型的技能文件）
• feature description（具体任务 + 前置条件 + 预期行为 + 验证步骤）

Worker 的操作流程：

1. 写测试（先写测试，后写代码——TDD）
2. 实现 feature
3. 自我验证（跑测试、lint、typecheck）
4. 提交 Git commit
5. 输出 handoff summary（成功状态、发现的问题、未完成事项）

Worker 看不到验证契约的全貌。它只知道"我的 feature 需要满足什么条件"。这防止了 Worker 为了通过验证而"作弊"——比如写测试时只测自己的实现路径，不测边界条件。

3.3 Validators（验证者）

Validators 是独立法官。它们不实现任何功能，只评判。两种类型：

• Scrutiny Validator：检查代码质量——测试覆盖率、lint、typecheck、代码审查
• User-Testing Validator：黑盒测试——像真实用户一样使用系统，验证行为是否符合验证契约

关键：Validators never see implementation reasoning。它们只拿到代码和验证契约，不知道 Workers 是怎么想的。这切断了"确认偏见"——Worker 不会无意中影响 Validator 的判断。

Alvoeiro 的金句："Tests written after implementation don't catch bugs. They confirm decisions."（实现后写的测试抓不到 bug，它们只是在确认自己的决策。）

四、四个核心设计原则

4.1 分离关注点与激励

每个角色只有一个目标，系统架构确保没有任何东西会把 Agent 从目标上拉走：

• Orchestrator 计划并执行，但不写代码
• Workers 写代码并相信自己对，但最终判断不是他们的
• Validators 发现问题并报告，但不实现修复

修复工作被重新委派给新的 Workers。这防止了"自己写、自己测、自己修"的循环——那个循环太容易滑向自欺欺人。

4.2 两层测试驱动开发

Worker 层面：每个 Worker 先写测试，再写代码。测试反映意图行为，不是事后 retrofit。

Mission 层面：Orchestrator 在定义任何 feature 之前，先写验证契约——一组可测试的行为断言。这改变了顺序：不是"先规划怎么做，再想怎么验证"，而是"先定义什么算对，再规划怎么做"。

当创建验证契约时，Orchestrator 只从需求理解出发。如果先定义 feature 再写契约，契约会被 planned implementation 污染，产生确认偏见。

4.3 外部化状态

没有单个 Agent 需要同时持有完整图景。全部状态存在文件系统里：

• mission.md：全局目标和需求
• validation-contract.md：行为断言
• validation-state.json：断言状态追踪
• features.json：有序 feature 列表
• AGENTS.md：操作规范
• .factory/skills/：Worker 类型技能文件
• .factory/library/：累积知识库

每个 Agent 只读自己需要的。Orchestrator 甚至把深度调研委派给 subagents，避免自己消化所有细节。

4.4 串行执行

并行执行看似更快，但串行执行更可靠。

原因：

• 并行 Workers 可能同时修改同一文件，产生 Git 冲突
• 并行 Workers 可能做重复工作（两个 Worker 各自发现需要同一个 utility function，各自实现）
• 并行 Workers 的决策基于不同版本的代码库，导致状态漂移

Missions 的 feature 执行是串行的——一次只有一个 Worker 或 Validator 在运行。但内部并行存在：只读操作（代码搜索、API 调研）可以并行，因为它们不修改状态。

Alvoeiro 的论证：对于多天的 mission，正确性产生复利。一个错误的 feature 如果不被及时发现，会影响后续所有 feature。串行执行保证了"每一步都站在正确的基线上"。

五、验证契约：在代码之前定义"对"

验证契约是 Missions 的杀手级概念。它不是测试文件，而是行为断言清单——在写任何代码之前，定义"什么算成功"。

示例：

### VAL-AUTH-001: Successful login
A user with valid credentials submits the login form
and is redirected to the dashboard.
Tool: agent-browser
Evidence: screenshot, network(POST /api/auth/login -> 200)

### VAL-CROSS-001: Auth gates pricing
A guest user sees "Sign in for pricing" on the catalog.
After logging in, real prices are shown.
Tool: agent-browser
Evidence: screenshot(guest-view), screenshot(authed-view)

每个断言有：

• 稳定 ID（VAL-AUTH-001）
• 行为描述（用户做什么，系统应如何响应）
• 验证工具（agent-browser、API 测试等）
• 证据要求（截图、网络请求、日志）

覆盖检查：每个断言必须被恰好一个 feature 覆盖。验证契约是"先验标准"，feature 是"后验实现"。

六、里程碑密封：已验证的不再回头

Missions 把 work 组织成 milestones，每个 milestone 是一个逻辑功能单元。当一个 milestone 通过验证后，它被密封——不再修改。

这有多层含义：

• 防止回归：已验证的功能不会被后续工作意外破坏
• 减少上下文：Workers 不需要知道 sealed milestones 的细节
• 提供检查点：如果 mission 失败，可以回退到上一个 sealed milestone

密封不是技术上不可修改，而是流程上的约定：除非用户明确要求，否则 sealed milestones 不重新打开。

七、模型不可知：不同角色用不同模型

Missions 的架构是模型不可知的——不绑定某个特定模型。Factory 的实践：

• Orchestrator：用推理能力强的模型（如 Claude Opus）——需要慢思考、仔细规划
• Workers：用代码能力强的模型（如 Claude Sonnet）——需要快速、创造性地写代码
• Validators：用指令遵循强的模型（如 Claude Haiku）——需要严格按规则执行，不"创意发挥"

随着新模型发布，系统可以切换，不需要修改代码。Alvoeiro 把这叫"Droid Whispering"——人类不是写代码，而是"对机器耳语"，告诉它们如何协作。

八、Mission Control：人的窗口

Factory 开发了 Mission Control 界面——管理长时间运行的异步 mission。功能：

• 监控活跃 Workers
• 读取 handoff summaries
• 理解任务进度
• 在 mission 被阻塞时介入

设计意图：工程师不需要"一直盯着"，只需要"偶尔看一眼"。Mission Control 提供足够的上下文，让工程师在 5 分钟内理解当前状态，决定是否需要干预。

九、Factory 的野心与背景

9.1 公司信息

• 创立：2023 年，Matan Grinberg（UC Berkeley 博士辍学）和 Eno Reyes
• 融资：Series C，＄150M，估值 ＄1.5B（2026-04-16）
• 领投：Khosla Ventures（Keith Rabois 加入董事会）
• 参投：Sequoia Capital、Blackstone、Insight Partners、NEA、NVIDIA 等
• 收购：2026-04-16 收购 Lumetric（YC W24，模型不可知 AI 系统）

9.2 客户

Nvidia、Adobe、Adyen、Klarna、Ernst & Young、Palo Alto Networks、Morgan Stanley、MongoDB、Bayer、Zapier。

9.3 竞争格局

AI coding 市场：Claude Code 约 54%（Menlo Ventures 估计），Cursor、GitHub Copilot、Cognition 在追赶。Factory 的差异化：

• 模型灵活（可切换 Claude/DeepSeek/GPT）
• 覆盖全生命周期（不只是代码生成，还有测试、review、文档、部署）
• 长时间自主运行（multi-day missions）
• 企业级治理（SSO、合规、审计）

十、信息汇总

• 演讲："Missions: Multi-Agent Systems That Ship for Days"，AI Engineer Europe 2026（2026-04-12）
• 演讲者：Luke Alvoeiro（Factory）
• 公司：Factory AI，https://factory.ai
• 融资：Series C ＄150M @ ＄1.5B（2026-04-16），Khosla Ventures 领投
• 创始人：Matan Grinberg（UC Berkeley 博士辍学）、Eno Reyes
• 客户：Nvidia、Adobe、Adyen、Klarna、EY、Palo Alto Networks、Morgan Stanley、MongoDB、Bayer、Zapier
• 核心架构：Orchestrator（51KB system prompt）→ Workers（fresh context）→ Validators（独立验证）
• 多 Agent 策略：Delegation、Creator-Verifier、Broadcast、Negotiation（排除 Direct Communication）
• 设计原则：分离关注点、两层 TDD、外部化状态、串行执行
• 验证契约：在代码之前定义行为断言，每个断言有 ID、描述、工具、证据要求
• 里程碑密封：验证通过后不再修改
• 模型策略：Orchestrator 推理型、Workers 代码型、Validators 指令遵循型
• 技术栈：PHP 8.4 / Symfony 8.0（后端）、TypeScript / React / Node.js / Electron（前端）
• 最长运行：16 天，90% 测试覆盖率
• 关键金句："Tests written after implementation don't catch bugs. They confirm decisions."

#记忆 #Missions #FactoryAI #多Agent系统 #AI编码 #Orchestrator #Workers #Validators #验证契约 #串行执行 #模型不可知 #小凯