跳转至

Factory Missions：多智能体工程纪律

Ch04.151 Factory Missions：多智能体工程纪律

📊 Level ⭐⭐ | 12.6KB | entities/factory-missions-architecture.md

概述

Factory 的 Missions 是一种串行优先的多智能体软件工程执行架构，核心理念是：多智能体系统的瓶颈不是智能，而是人类注意力。架构用纪律而非并行来解决问题。 | 角色 | 职责边界 | |------|---------| | 编排者（Orchestrator） | 澄清目标、拆功能、写验收合同（规划阶段先于任何代码） | | 工人（Worker） | 干净上下文实现，Git 提交，结构化交接 | | 验证者（Verifier） | adversarial 判断，不背实现上下文，不替工人圆场 | Factory 的核心创新：验收标准前置到规划阶段，而非实现后补测试。 验收合同写的是"用户要的东西有没有发生"，而非"我这样写有没有问题"。 外层串行（同一时间只有一个工人或验证者跑），内层可并行（只读任务：搜索、查接口、读文档、只读审查）。 原因：多个智能体同时改代码会踩彼此修改、做冲突架构决定。协调成本 > 并行收益。 验证者不看实现过程，没有心理负担，不需要证明前一个智能体是对的。这是有别于普通代码审查的本质差异。 两类验证： 同一任务不同位置使用不同模型： "Droid whispering"：知道模型在压力下怎么失败，失败怎么在长任务里累积。 Factory Missions = 工程任务执行方法（纪律层） Claude Managed Agents = 平台托管能力（基础设施层） 共同点：先定义成功标准，再独立评分器验证。

深度分析

Factory 选择"串行优先"不是技术限制，而是深思熟虑的工程判断。在软件工程领域，并行开发最大的问题是协调成本——当多个工人同时修改同一代码库时，冲突检测、上下文切换、合并冲突等成本往往抵消了并行带来的时间收益。人类工程师对此有丰富经验：两个人同时改同一个文件，往往比一个人单独改两次更慢。 对多智能体系统来说，这个问题更加严重。LLM 的输出具有概率性——同一段代码，让同一个模型跑两次可能产生不同的结果。这种不确定性在并行场景下会指数级放大：两个 Agent 同时看到 V1 版本代码，各自修改后产生 V2a 和 V2b，两个版本可能存在无法自动合并的语义冲突。 Factory 的解法是外层串行、内层并行：同一时间只有一个 Worker 在修改代码（避免冲突），但 Worker 内部可以并行执行只读任务（搜索、查文档、看接口）。这是对人类软件工程团队工作模式的精准抽象——一个程序员在写代码的时候，可以同时让另一个程序员去调研技术方案，但不能让两个人同时提交到同一个分支。 Factory 最深刻的洞察之一是把验收标准前置到规划阶段。传统软件开发中，需求 → 设计 → 实现 → 测试的线性流程有一个根本缺陷：测试是在实现之后写的，这意味着测试无法真正验证"需求是否被满足"，只能验证"实现是否与设计一致"。 验收合同（Validation Contract）的本质是从结果而非过程定义成功。"用户要的东西有没有发生"是一个客观事实判断，而"我这样写有没有问题"是一个主观过程判断。前者与实现路径解耦，后者与实现路径绑定。这就是为什么"Tests written after implementation don't catch bugs. They confirm decisions"——后写的测试测的是工程师的决策，不是用户的需求。 对 AI Agent 系统来说，这个区分更加关键。AI Agent 的行为具有高度不确定性，同样的需求、同样的大模型，两次实现可能产生完全不同的代码路径。如果验收标准绑定到实现细节，测试将完全失效；如果验收标准绑定到最终效果，测试才能真正指导方向。 Factory 三角色（Orchestrator/Worker/Verifier）的分离不是简单的分工，而是基于认知角色冲突的深刻洞察。 Verifier 面临的认知挑战是"确认偏见"（confirmation bias）——如果 Verifier 知道 Worker 花了多少时间、走了多少弯路、解决了多少困难，就会不自觉地降低验证标准。人类代码审查中的"人情分"现象就是确认偏见的典型表现。 Factory 的解法是让 Verifier 完全不看实现过程。这相当于双盲实验设计——评审者不知道被评审者的上下文，就无法用上下文来为自己的判断找借口。Adversarial Verification 的"adversarial"二字正是来自于此：Verifier 的角色是"攻击"Worker 的实现，而非"帮助"Worker 通过审查。 "Droid whispering"——知道模型在压力下怎么失败，失败怎么在长任务里累积——这个说法捕捉到了 Factory 对 LLM 本质的理解：LLM 是有特定失效模式的工程系统，而非通用的智能体。 传统软件工程的"模型"是确定性的——同样的输入，同一段代码总是产生同样的输出。LLM 是概率性的——同样的输入，不同温度、不同上下文、不同采样策略，输出都可能不同。更重要的是，LLM 的失效模式与人类直觉不同：它不是因为"计算错误"而失败，而是因为"分布外泛化失败"而失败。 "Droid whispering"意味着：在不同位置使用不同模型（规划用慢模型、执行用快模型、验证用不同供应商模型），本质上是利用不同模型的不同失效模式分布，让整个系统在单点失效时仍有鲁棒性。这比用一个模型的不同温度参数更加根本——因为不同供应商的模型有真正独立的失效模式。 Factory 能支持 16 天（目标 30 天）的长任务，核心依赖不是长上下文，而是结构化交接文档。这揭示了一个重要的工程原则：信息传递的质量比信息容量更重要。 长上下文的根本问题是"注意力漂移"——模型对上下文中任何位置的关注度不是均匀的，越早出现的信息越容易被遗忘。这不是技术问题，而是注意力机制的固有特性。Factory 通过强制交接文档把"重要状态"显式化——让模型不需要"记住"关键信息，而是可以"查询"关键信息。 这与 RAG（Retrieval-Augmented Generation）的思想高度一致：不是把一切都塞进上下文，而是建立外部知识库，让模型在需要时查询。Factory 的交接文档本质上是一个由 Worker 实时构建的、任务特定的 RAG 知识库。 1. 采用验收合同先行的开发流程：在任何实现之前，先由 Orchestrator 定义清楚"成功是什么样子的"。这要求团队在规划阶段就深入思考用户需求，而非在实现过程中摸索。 2. 实现 Verifier 的 adversarial 独立性：确保 Verifier 看不到 Worker 的实现上下文。如果使用同一个模型，至少在 Verifier 的 prompt 中明确说明"不要参考实现过程，只看最终结果"。引入不同供应商的模型作为 Verifier 能进一步减少偏见。 3. 强制结构化交接文档：不依赖模型的"记忆"，而是要求每次交接必须包含：完成项、命令、退出码、问题、流程遵守情况。这不仅对 Factory 有效，对任何多 Agent 协作系统都是必要的。 4. 在验证中区分两类检查：审查型（跑测试、类型检查）属于低认知负荷的机械检查，可以用自动化工具替代；用户测试型（真启动应用、点页面）属于高认知负荷的端到端验证，必须由 Verifier 强制执行。 5. 模型选择要有位置意识：不同任务位置需要不同的模型特性。规划需要战略思考（慢模型）、执行需要代码能力（快模型）、验证需要独立判断（不同供应商）。不要用同一个模型覆盖所有位置。 1. 构建 Agent 通信协议规范：Factory 的三角色通过结构化消息通信（规划、交接、验证）。这种协议应该标准化，使不同团队的 Agent 能互操作。 2. 建立长任务状态管理机制：不要依赖模型的内部记忆。设计外部状态存储（交接文档、检查点快照），让任务能在中断后精确恢复，而非从头重来。 3. 提供模型失效模式画像：建立每个模型/版本的失效模式知识库，让 Orchestrator 在规划阶段就能预判哪些任务位置可能出现哪种类型的失效，提前设计恢复机制。 4. 实现交接完整性检查：Worker 的交接文档是否完整？是否有缺失字段？这些问题应该在交接时自动检查，而非等到 Verifier 运行时才发现。 1. 重新审视并行 vs 串行的权衡：大多数多 Agent 研究追求并行效率，但 Factory 的实践表明串行优先可能是更工程化的选择。在追求并行效率之前，先量化协调成本，再决定架构。 2. 研究交接文档的最佳实践：结构化交接文档的内容字段、格式规范、更新频率——这些都是未充分研究但对长任务成功的关键变量。 3. 探索 Verifier 独立性的度量：如何量化"Verifier 对 Worker 上下文的依赖程度"？这可以作为验证系统质量的指标，指导 Verifier 的 prompt 设计。

  • Multi Agent Systems — 多智能体系统的一般概念
  • adversarial testing（对抗性验证）— 验证者不看实现过程，没有心理负担，不需要证明前一个智能体是对的
  • code review（代码审查）— 传统工程检查，但 Factory 的验证者不参与实现，区别于普通审查
  • Claude Managed Agents — 平台层的对照系统
  • test-driven development（TDD）— 与 Factory 相反：Factory 验收合同前置，TDD 测试后写
  • human-in-the-loop — 人类注意力作为瓶颈的设计前提
  • golden set evals（黄金集评估）— 验证者使用独立参考答案的评估方法

相关实体