长时间自治运行的Agent团队揭示关键问题不在组队

前段时间，一项颇具深度的实验引发了关注：让一个 AI Agent Team（多智能体团队）长时间自主推进真实业务任务。需要特别说明的是，这并非演示性质的 demo，也不是让几个 agent 彼此闲聊。这个团队包含 coordinator（协调者）、多位 worker（执行者），以及 implementation（实现）、QA/review（质量审查）、handoff（任务交接）、版本推进、本地检查等角色，外加一个 monitor（监控器）负责定时唤醒并推动持续运行。

从短期表现来看，这套系统确实能够运作起来——它可以拆解任务，将不同类型的问题分配给不同的 worker，能够产出 handoff，能够执行 review，能够运行检查，也可以在无人值守的情况下持续前进。但运行时间拉长之后，暴露出的问题已然大不相同。这并非“某个 agent 能力不足”这类表层问题，也不是“把 prompt 写得更细致就能解决”的范畴。更准确地说：这个团队已经学会了如何协作，但缺少一个足够坚实的 runtime（运行时层）来支撑长期运行中的状态管理、权限控制、故障恢复和成果验收。

当前市面上很多关于 multi-agent（多智能体）的文章，主要都在讲如何组队：planner 应该怎样拆解任务，coder / reviewer / architect 如何分工合作，如何设计 prompt，如何实现 handoff，如何接入工具。这些内容固然有价值，但它们主要解决的是“团队如何启动运行”的问题。本次实验所遇到的困境，恰恰是在系统成功跑起来之后才逐渐浮现的：当前版本通过了测试，但它实际上并不是最终交付成果；用户说“继续”，系统却无法判断这个指令的授权范围究竟到哪里；worker 崩溃之后，新 worker 完全不了解真实任务的上下文；coordinator 接管实现工作后，开始偏离项目的原始目标；review 和 gate 流程越来越冗余，运行成本甚至超过了产品推进本身的价值；模型返回 503 错误后，任务状态无法可靠恢复。

下面只挑选几个最有代表性的故障来深入分析，不再重复完整的实验文档。

1. 最容易误判的是“看起来已经完成了”

有一次，本地 release candidate 通过了 QA 测试。测试状态全部显示为绿色，本地入口可以正常打开，代码 review 也顺利通过。随后 coordinator 来找你验收。但最初的原始目标远不止“本地能跑起来”——其中还包括真实的外部连接、真实的页面展示或数据读取、API / LLM 配置边界、外部操作策略等能力。换句话说，这个 local candidate 只是一个内部阶段性成果，绝不是最终交付物。

这个问题的隐蔽性在于，系统并不是在胡编乱造。build 确实通过了，QA 确实执行了，当前版本的 gate 也确实满足了要求。错误发生在更高层次：coordinator 把“眼前这个可以验证且已经通过的东西”错误地当成了“最初承诺的最终目标”。后来有人将这种现象称为 Acceptance Contract drift（验收契约漂移）。它并非普通的 hallucination（幻觉），而是成功标准的系统性偏移。

如果 final definition（最终定义）和 acceptance contract（验收契约）只存在于 coordinator 的上下文中，那么在长期运行后，系统很容易被当前产出的阶段性成果所误导。它看到一个通过的 local candidate，就开始将其视为可以交付的成果。这里需要的不是提醒模型“更认真一点”，而是在 runtime 层明确区分以下状态：internal gate passed（内部关卡通过）、local candidate（本地候选版本）、not final（尚未终版）、external acceptance requested（已请求外部验收）、final complete（最终完成）。本地通过只能说明内部 gate 通过了，绝不能自动等同于 Final 已完成。

2. “继续”不是一个足够精确的授权指令

运行过程中会发现，“继续”这个词很容易把系统带偏。有时你说继续，coordinator 会变得极其保守——只要下一步涉及到真实环境、真实账号、真实 API，它就停下来询问是否需要授权。问一次还可以接受，问题在于它可能每一步都要问。但也有相反的情况：它会把“继续”理解得过于宽泛，直接进入本不该触及的动作范围。同一个词，两个方向都可能引发问题。

后来我们意识到，这并非模型应该更大胆还是更谨慎的问题，而是授权语义本身没有被建模。真实项目中至少需要划分三个授权层次：第一层是项目级预授权——初始目标中已经明确要设计、实现、集成、测试的能力，只要没有外部副作用、费用风险、账号风险，就可以继续推进；第二层是运行时危险动作授权——例如真实发送数据、批量操作、修改远程状态、发布 release、创建 tag、消耗大量额度、操作真实账号等，这些需要当场确认；第三层是沙盒 / 只读 / 测试环境授权——例如本地环境、mock 模拟、fixture 测试夹具、测试账号、只读检查、安全模式下的真实集成，这些不应被当作危险动作而卡住。

从这个角度来看，“继续”只能映射到第一层，不能自动扩展到第二层，也不应该阻塞第三层。如果没有 Authorization Contract（授权契约），系统就会在“过度保守”和“越界执行”之间不断摇摆。

3. 聊天上下文看起来像任务系统，但并非如此

在短时间运行 agent workflow 时，很容易觉得聊天窗口已经足够用了——coordinator 记得上下文，worker 也记得上下文，大家看起来都能顺利衔接。长期运行之后，这个假设被彻底打破。一旦 worker 崩溃、模型返回 503 错误、上下文被压缩、新线程接手运行，原来隐藏在聊天记录中的状态就会全部中断。

新 worker 可能完全不知道：当前任务到底要解决什么，当前版本的目标是什么，上一个 worker 已经完成了哪些工作，哪些文件只是半成品，哪些方案已经被否决，它能够编写哪些路径，验收标准是什么，下一步应该恢复执行、重新做还是打回重审。结果就是重复执行，或者做出局部正确但整体存在冲突的修改。

因此我们不再把聊天历史当作任务系统。每个任务至少需要几个外部化的核心要素：Task Snapshot（任务快照）记录任务当前所处的状态；Context Pack（上下文包）是派工时给 worker 的最小权威上下文；Handoff（交接记录）是 worker 完成后留下的交接信息；Review Evidence（审查证据）记录 review 为什么通过或打回。worker 不应该靠翻阅聊天记录来恢复任务，它应该依靠 runtime state（运行时状态）来恢复任务。

4. Coordinator 接管实现，短期看似高效，长期极为危险

有一个场景非常常见：worker 卡住了，coordinator 为了推进进度，干脆自己开始收尾。短期来看这似乎很合理——coordinator 拥有最多的上下文信息，了解全局状况，也能够快速 patch 问题。但运行时间一长就会发现，这是一个非常危险的信号。

coordinator 的上下文容量是有限的。一旦它开始写代码、修 bug、跑测试、改配置、看截图、处理边界扫描，这些细节会迅速占满其上下文窗口。而被挤出去的，往往恰恰是最不该丢失的东西：用户为什么做这个项目，Final 最终目标到底是什么，Acceptance Contract 验收契约，Authorization Contract 授权契约，产品边界，已经否决的方案，哪些路线不能走。最终 coordinator 会从“调度和状态推进者”蜕变为“唯一大脑 + 实现者 + 验收者”的合一体。

这会带来两个严重后果：独立的 review 流程被削弱，同时 worker failure 的真实原因也被掩盖。到底是任务拆分得太大、上下文不够用、权限不清晰、模型不稳定，还是 worker 真的无法完成？如果 coordinator 直接接管，这些问题全部被掩盖过去。

现在我们更倾向于将 worker failure 走成一个明确的流程：要求最小化 handoff，或者明确标记 blocked / cannot_start / needs_context 状态；标记 worker lease 已过期；记录 root cause（根本原因）；重新派遣给新 worker；缩小任务粒度；创建 recovery task（恢复任务）；必要时进入 safe_pause（安全暂停）模式。coordinator 可以组织恢复工作，但不应成为默认的 fallback implementer（后备实现者）。

更重要的是，系统的大脑不能放在 coordinator 里。计划、意图、contracts、状态、decisions、版本目标，这些应该全部放在 runtime 层。coordinator 可以读取它们、按照它们推进状态，但不应该拥有它们。

5. 过度谨慎也会变成失败

很多人会担心 agent team 过于鲁莽。但这次实验观察到的另一个问题是：它也可能过度谨慎。版本被拆得越来越细，每个微小的变化都变成一个 gate，每个 gate 都需要 review，每次 review 又可能引发下一轮修正。表面上看，这似乎非常稳健。

但如果一个 gate 没有降低真实风险，没有带来用户可感知的进展，也没有提供新的系统能力，那么它就是流程摩擦（process friction）。流程摩擦会消耗 token、时间和注意力。到达某个阶段后，团队花在证明自己很谨慎上的成本，会超过花在推进产品上的成本。

因此成本也必须纳入 runtime state 管理。至少需要记录：当前版本轮次、worker 调用次数、强模型调用次数、失败次数、retry 次数、review 次数、被打回次数、safe_pause 次数、用户介入次数，以及大致的时间和 token 成本。谨慎本身不是问题，没有 ROI（投资回报率）的谨慎才是问题。

结论：这不是组队问题，而是 runtime 问题

这次实验之后，我们对 agent team 的看法有了根本性的转变。角色分工、prompt、handoff、review 这些当然都不可或缺。但如果目标是长时间自治运行，仅仅依靠这些是远远不够的。更关键的是把状态、事件、上下文、权限、验收、验证、恢复、模型路由、成本控制这些核心要素从 agent 的上下文里抽离出来——也就是从 orchestrator-led team（编排者主导的团队）转向 protocol-led team（协议主导的团队）。

coordinator 不是老板，worker 不是工具人，reviewer 也不是只看测试是否变绿。真正稳定的根基应该是下面那层 runtime。完整的实验文档将问题归纳为四个层次：目标与契约层、状态与恢复层、调度与版本层、模型与权限层；同时也整理了最小 runtime primitives（运行时原语）：Append-only Event Log（仅追加事件日志）、Task Snapshot（任务快照）、Context Pack（上下文包）、Coordinator Checkpoint（协调者检查点）、Leader / Worker Lease（领导者/执行者租约）、Model Registry / Router（模型注册表/路由器）、Verification Gate（验证关卡）、Mission Epoch（任务纪元）、Runtime Metrics / Iteration Budget（运行时指标/迭代预算）、Chaos Test Harness（混沌测试框架）。

如果只是做 demo 演示，可能暂时不会遇到这些问题。但如果你想让一个 AI agent team 运行几个小时、几天，甚至实现长期自治，问题将很快从“如何让它们协作”转变为“如何恢复、如何验收、如何授权、如何防止漂移、如何控制成本”。这大概就是我们现在真正应该关注的 runtime 层核心课题。