让AI Agent连跑16天：Factory多Agent架构拆解

单个AI Agent的瓶颈，往往不是模型不够聪明，而是人不够用。Factory核心Agent团队负责人Luke在演讲中抛出一个判断：现代软件工程的瓶颈已经从智能水平转移到人类注意力——工程师手上可能堆着50个任务，但每天只能推进两三个，因为每个commit都需要人盯着。

那么，如果让人只负责决定做什么，由一套Agent系统自主决定怎么做，连续跑上几天，回来时任务已经完成呢？这正是Factory推出Missions系统的出发点。这套系统最长连续运行了16天，团队认为跑到30天并非不可能。

多Agent协作的五种基础模式

Luke先给混乱的多Agent领域提了一个简明分类法，把前沿框架归结为五种模式：

委托（Delegation）：一个Agent派出子Agent执行子任务并回收结果，是最简单的多Agent通信形式，也是大多数人最先实现的模式。
创建者-验证者（Creator-Verifier）：一方负责实现，另一方在全新上下文中检查工作。关键在职责分离——写完代码的Agent会有沉没成本偏见，而干净上下文的验证者更容易发现问题，这与人类代码评审的逻辑一致。
直接通信（Direct Communication）：Agent之间不经过中心协调者直接对话。状态容易碎片化，缺乏单一事实来源，很难做对。
协商（Negotiation）：Agent围绕共享资源（同一API、同一段代码库）沟通，最佳场景是双赢的正和博弈。
广播（Broadcast）：一对多传递状态更新或全局约束。看起来不炫酷，但对长时间运行任务的连贯性至关重要。

正和博弈是博弈论中的概念，指参与者通过合作能够创造出比各自单独行动总和更大的价值，双方都能从中获益，而非一方的收益必然等于另一方的损失（零和博弈）。在协商模式中，当多个Agent需要围绕共享资源（如同一段代码库、同一套API配额）达成一致时，最佳情形是找到让双方都能改善的方案——例如一个Agent让出某文件的修改权，换取另一个Agent在接口上的兼容承诺，两者最终都能更快完成任务。若陷入零和思维，Agent之间就会互相阻塞、争夺资源，导致整体效率下降。

Missions的三角色架构

Missions把委托、创建者-验证者、广播和协商组合成单一工作流：你描述目标、通过对话明确范围、批准计划，系统便自主执行数小时甚至数天。它由三个角色构成：

编排者（Orchestrator） 负责规划，像战略顾问一样追问关键问题、检查需求盲区，最终产出包含功能点、里程碑和验证合约（Validation Contract）的计划。验证合约在写任何代码之前就定义了"什么算完成"。

工作者（Worker） 负责实现。每个功能分派给一个上下文干净的工作者，没有累积包袱、没有注意力衰减。工作者读规格、实现功能、提交Git，让下一个工作者继承一个干净的工作区和可运行的代码库。

验证者（Validator） 负责验证，分为两种。审查验证者运行测试套件、类型检查和lint；用户测试验证者更像QA工程师——它启动应用，通过computer use与界面交互，填表单、点按钮、检查页面渲染，确认功能流程整体可用。

这条验证路径揭示了Missions最核心的设计取舍：大部分任务的墙钟时间花在等待真实世界执行上，而不是生成token。

验证合约：对抗"测试确认代码而非验证行为"

Luke点出了编码Agent的一个通病：Agent写完功能，再补写测试，测试全部通过、覆盖率拉满，但这些测试是被代码塑造的，而非由代码本应实现的行为定义。事后补写的测试抓不住bug，只是在确认已有的决策。依赖这种验证的系统迟早会漂移。

验证合约在规划阶段、代码之前写就，独立于实现定义正确性。复杂项目的合约可达数百条断言，每个功能必须满足其中一条或多条，所有功能的并集必须覆盖全部断言。每完成一个里程碑，两类验证者依次运行，且两者都没看过代码——验证在设计上就是对抗性的。

验证合约（Validation Contract）借鉴了软件工程中的契约式设计（Design by Contract）思想：在实现开始之前，用可检验的断言明确系统应满足的行为规范，而不是等代码写完再反推测试。它相当于一份双方签署的"验收协议"——编排者代表需求方定义"什么算完成"，工作者和验证者则必须按此标准交付与检查。与传统的需求文档不同，验证合约的断言必须是可自动验证的，例如"提交表单后数据库应新增一条记录"或"点击删除按钮后列表不再显示该项"。由于合约独立于实现存在，它天然抵抗了"测试被代码塑造"的偏差，也为里程碑检查提供了客观依据。

结构化交接：不靠Agent记忆，靠强制记录

跑几天的系统必须解决上下文丢失。Worker完成功能后不能只说一句"做完了"，而要填写结构化交接：完成了什么、遗留了什么、执行了哪些命令及其退出码、发现了什么问题、是否遵守了编排者定义的程序。

错误在里程碑边界被捕获，纠正性工作被重新划定范围，任务由此自我修复、重回正轨。这不是寄希望于Agent记住发生了什么，而是强制它写下来并真正处理问题。

提示缓存（Prompt Caching）是大模型推理中的一项优化技术：当多次请求共享相同的前缀提示（如系统指令、长文档、对话历史）时，服务端可以缓存这些内容的计算结果，后续请求只需处理变化的部分，从而显著降低延迟和成本。在Missions这类长时运行系统中，编排者的计划、验证合约、技能定义等大量文本会在每个Worker或Validator的每次调用中重复出现，提示缓存能将这些固定开销摊薄到极低水平。这也是Factory能在生产案例中大量使用提示缓存的原因——没有它，连续数天的任务成本会因重复处理相同上下文而急剧膨胀。

为什么要串行执行而非并行

直觉上，十个Agent并行意味着十倍吞吐。但Factory试过，在软件工程领域行不通：Agent互相踩踏修改、重复劳动、架构决策不一致，协调开销吃掉速度收益，token还照烧不误。

Missions的做法是功能层面串行，同一时刻只有一个Worker或Validator在跑；功能内部的只读操作（搜索代码库、调研API、代码评审）则并行化。表面看更慢，但错误率大幅下降——对于动辄数天的任务，正确性会复利。

配套的Mission Control提供专门视图，随时查看当前Worker在做什么、交接摘要揭示了什么问题、项目完成度和预算消耗多少，让人可以异步地以项目经理身份监督，或干脆去和朋友聚会。

模型混编：每个座位放对的模型

整套架构有个隐含前提：每个角色都用对的模型。规划受益于慢而审慎的推理，实现受益于快速的代码流畅度和创造力，验证受益于精确的指令遵循。没有单一模型或供应商能在三者上都做到最好。

Factory内部把这项新技能称为"droid whispering"——在脑中建模不同LLM如何交互、在哪里失败、失败如何在多天的运行中累积，然后有意识地安排模型座位。验证环节甚至可能使用完全不同的供应商，以避免被相同训练数据带来的偏差影响。模型无关架构带来结构性优势：如果锁定一家供应商，你就受制于该家族最弱的那项能力。反过来，验证合约和里程碑检查点让Missions即使使用开放权重模型也能跑得相当成功。

生产数据：Slack克隆案例

Factory用一个Slack克隆项目展示了真实表现：60%的时间和60%的token花在实现上；验证几乎从不一次通过，总要创建后续功能——这恰恰证明了QA循环的价值；最终代码中50%的行数是测试，测试覆盖了90%的代码；提示缓存被大量使用以摊薄长任务的成本。

企业场景中，Missions被用于通宵原型验证、快速搭建内部工具、大规模重构与迁移、支撑ML研究、以及现代化代码库让Agent在其中更高效。原本五人团队同时推进10条工作流的产能，可能提升到30条，团队得以专注架构和产品决策——而且交付后的代码库比开始时更干净。

对抗苦涩教训：为下一个模型发布而设计

多Agent系统的建设者都害怕下一个模型发布让自己的架构一夜过时。Missions的应对是把几乎所有编排逻辑写进提示词和技能，而非硬编码状态机——约700行文本，改动四句话就能显著改变执行策略。Worker行为由编排者为每次任务定义的技能驱动，唯一的确定性逻辑很薄，只负责记账：跑验证、在交接问题未解决时阻断进度。系统提供纪律，模型提供智能，用的是Agent本来就熟悉的agents.md、skills等原语。

这也呼应了演讲的落点：人类注意力曾是瓶颈，如今经济账在改变。Luke留给听众的行动建议很直接——打开OpenDroid，运行slash missions，和编排者争论范围，批准计划，然后去做别的事。