Factory.ai Missions 多 Agent 架构
来源：raw/newsletters/Ben's Bites/2026-04-14 Big lab leaks 原文：How Missions Work
核心洞察
Agent 对上下文高度敏感。 轨迹是 append-only 的，模型在任何时刻的推理都是所有历史思考、观察和行动的函数。上下文越宽泛，信噪比越低，性能越差。
架构设计原则
1. 关注点分离（Separation of Concerns）
| 角色 | 职责 | 不做什么 |
|---|---|---|
| Orchestrator | 规划、分解任务、定义验证合约 | 不直接实现代码 |
| Workers | 实现具体功能 | 不做规划，不做验证 |
| Validators | 验证输出质量 | 不实现修复 |
三者激励互不干扰，防止"既当运动员又当裁判"。
2. 两层 TDD（Test-Driven Development）
- Worker 级别：先写测试再写代码（传统 TDD）
- Mission 级别：Orchestrator 先定义验证合约（behavioral assertions checklist），再分解功能
3. 外部化状态
没有单一 Agent 需要在上下文中持有完整图景。状态分布在共享 artifacts（文件系统）中，每个 Worker 从全新上下文开始。
4. 模型专业化
不同角色使用不同模型：
- 规划（Orchestrator）：推理能力强的模型
- 执行（Workers）：成本低的模型
- 验证（Validators）：彻底、严格的模型
实际案例：构建 Slack 克隆
| 指标 | 数据 |
|---|---|
| 总运行时间 | 16.5 小时 |
| Agent 运行次数 | 185 次（1 Orchestrator + 63 Workers + 27 Validators） |
| 总 token | 7.785 亿 |
| 缓存读取占比 | 95.7%（7.449 亿 token）— 成本控制关键 |
| 代码行数 | 38,800 行 |
| 测试代码占比 | 52.5% |
| 语句覆盖率 | 89.25% |
| Validators 发现问题 | 81 个 |
| 修复功能数量 | 21 个（占实现工作量的 34.4%） |
| 每 Milestone 收敛轮数 | 2-4 轮 |
功能覆盖：workspace auth、channels、real-time messaging、file uploads、search、notifications
与其他架构的对比
| 维度 | Factory Missions | 传统单 Agent | 文件夹即 Agent |
|---|---|---|---|
| 上下文管理 | 每个 Worker 新鲜上下文 | 单一累积上下文 | 文件夹隔离上下文 |
| 验证 | 独立 Validator 角色 | 自我验证 | 手动审查 |
| 状态共享 | 共享 artifacts | 单一上下文 | 文件系统 |
| 适用场景 | 大型工程任务 | 简单任务 | 日常开发运维 |
关键教训
- Validator 是必须的独立角色：81 个问题中，Validator 发现的问题占实现工作量的 34.4%，说明自我验证严重不足
- 缓存是成本控制的核心：95.7% 的 token 来自缓存读取，没有缓存这个系统将不可行
- 先定义验证合约：在 Orchestrator 开始分解任务之前，先定义 behavioral assertions checklist
相关页面
- harness-engineering/multi-agent-coordination-patterns — 多 Agent 协调模式综述
- harness-engineering/self-verification-loops — 自我验证循环
- harness-engineering/folder-is-the-agent — 文件夹即 Agent（轻量级替代方案）
- harness-engineering/context-rot — 上下文腐化问题