前段时间我做了一次比较重的实验：让一个 AI Agent Team 长时间自治推进真实任务。这里说的不是 demo，也不是让几个 agent 互相聊天。这个 team 里有 coordinator，有多个 worker，有 implementation，有 QA/review，有 handoff，有版本推进，有本地检查，还有 monitor 定时唤醒继续推进。
短时间看，它是能工作的。它能拆任务，能把不同问题分给不同 worker，能产出 handoff，能 review，能跑检查，也能在我不一直盯着的情况下继续往前走。但跑久以后，问题开始变得不一样。不是"某个 agent 太笨"这种问题，也不是"prompt 再写细一点就好了"。更像是：这个 team 已经会协作了，但没有一个足够硬的 runtime 来接住长期运行里的状态、权限、恢复和验收。
现在很多 multi-agent 文章都在讲怎么组队：planner 怎么拆任务，coder / reviewer / architect 怎么分工，怎么写 prompt，怎么做 handoff，怎么接工具。这些我觉得都有价值，但它们主要解决的是"团队怎么开始跑"。我这次遇到的问题是在它已经跑起来之后出现的：当前版本通过了，但它其实不是最终交付；用户说"继续"，系统不知道这句话授权到哪一步；worker 崩了以后，新 worker 不知道真实任务上下文；coordinator 接管实现后，开始丢掉项目原来的目标；review 和 gate 越来越多，流程成本超过产品推进；模型 503 以后，任务状态无法可靠恢复。
我把完整复盘放到了 GitHub：
这篇只讲几个最有代表性的故障，不重复完整文档。
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 没有降低真实风险，没有带来用户可感知进展，也没有提供新的系统能力，它就是流程摩擦。流程摩擦会消耗 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。我在 GitHub 文档里把问题分成了四层：目标与契约层、状态与恢复层、调度与版本层、模型与权限层；也整理了最小 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 层。