瓶颈不再是智能，
而是 人类的注意力。
如果由人决定"做什么"，由系统决定"怎么做"，让 Agent 自主工作数小时甚至数天，会是什么样？ Factory 把所有多智能体通信归纳为五种基础模式，并以此构建出可以连续运行 16 天的 Missions 架构。
五种基础通信模式
Missions：四种模式合奏的三角色架构
Orchestrator
扮演用户的思想伙伴，提出战略性问题，澄清模糊需求。最终产出一个包含特性、里程碑以及验证契约的计划 —— 在任何代码动手前，"完成"的标准就已经被定义。
Workers
每个被分配特性的 Worker 拥有干净的上下文，没有累积的历史包袱，没有衰减的注意力。读规格 → 实现 → git 提交。下一个 Worker 在干净的工作代码库上接力。
Validators
不仅跑 lint、类型检查、测试和 code review，更关键的是验证行为 —— 不只问"代码看起来对吗"，而是问"端到端真的能工作吗"。这是 Mission 多天不漂移的关键。
Mission Lifecycle
Validation Contract：写代码之前先定义"正确"
Scrutiny Validator
相对传统的一类 —— 跑测试套件、类型检查、lint，并且为每个完成的特性派生专门的 code review agent。
- 运行完整测试套件
- 类型与静态检查
- 为每个特性派生 code review agent
- 无实现包袱的干净上下文
User Testing Validator
扮演 QA 工程师 —— 启动应用，通过 Computer Use 真实交互：填表、检查渲染、点按钮，确保功能流端到端工作。
- Computer Use 真实点击交互
- 填表 + 检查页面渲染
- 端到端功能流验证
- Mission 大部分挂钟时间花在这里
两个验证者都没有看过代码
对实现没有任何投入 —— 因此验证在设计上就是对抗性的（adversarial by design）。 结构化交接强制 Worker 写下完成了什么、未完成什么、跑了哪些命令及退出码、发现哪些问题、是否遵循了 Orchestrator 定义的程序。
串行优于并行 —— 反直觉但被生产数据验证
10 Agents × 1 = chaos
Agent 互相冲突、覆盖彼此的修改、做出不一致的架构决策。表面看更快，实际上正确性下降，token 浪费严重。
Serial with directed parallelism
特性级别串行 —— 任何时刻只有一个 Worker 或 Validator 在跑。但在特性内部对只读操作（搜索、研究）做定向并行。正确性会复利累积。
来自构建 Slack 克隆的真实数据
时间与 token 比例
总行数的比例
测试覆盖率
prompt 总长度
配套设计 —— 让系统随每代模型变强
Structured Handoffs
Worker 完成特性时不能只说"我完成了"。必须填写一份结构化交接：完成了什么、未完成什么、跑了哪些命令及退出码、发现了哪些问题、是否遵循了程序。
Droid Whispering
没有任何一个模型在规划/实现/验证三方面都是最强的。需要心里有数不同 LLM 如何交互、它们在哪里失败，并有意识地选择哪个模型坐哪把椅子。
Mission Control
传统聊天界面不适合数天任务。专用视图展示当前活跃 Worker 在做什么、交接摘要发现了什么、计划如何调整 —— 用户像项目经理一样介入，或者直接去和朋友玩。
The Bitter Lesson
几乎所有编排逻辑都定义在 prompts 和 skills 中，而不是硬编码的状态机。约 700 行文字 —— 其中四句话就能显著改变执行策略。
现在用 Missions 也许能推进 30 条。