多智能体流水线复盘：子智能体编排出错的 5 种方式（2026）

引言 #

多智能体编排是 Claude Code 里最强大——也是最悄无声息地危险的模式。当它奏效时，你能并行地横扫一整个代码库、得到独立的审查、攻克单个上下文窗口永远装不下的问题。而当它失败时，它是静默地失败：流水线报告成功，你发布上线，而它本该抓住的 bug 早已进入了生产环境。

这是一份复盘，覆盖我们在生产环境运行智能体流水线时实际踩过的五种失败模式。每一种都附带你会看到的症状、它底下的根因，以及修复方案。如果你已经读过 子智能体模式 和 自定义智能体编写，现在正在跑真实的编排，那么这篇就是让你别翻进沟里的那一篇。

失败 1：信任陷阱 #

症状。 你的编排器报告"auth 模块已重构，所有测试通过"。你发布上线。运行时立刻在一条"通过的测试"从未覆盖的路径上崩溃。

根因。 子智能体返回的是一份摘要——对它打算做什么的描述，而不是它实际做了什么的经核验记录。“所有测试通过"可能意味着它真跑了测试，也可能意味着它相信测试会通过。编排器把散文当成了基准事实。

修复方案。 对照产物来核验，绝不对照摘要。当一个子智能体声称做了某项改动后，编排器要去读实际的 git diff、检查测试命令的退出码，或者重新读一遍文件。我们是吃过苦头才学会这一条的——这也是为什么，当我们 用一个翻译子智能体写一篇四语言文章 时，我们跑 npm run build 作为基准事实，而不是相信智能体说的"YAML 有效：是”。摘要是一个声明。构建是证据。

失败 2：上下文串台 #

症状。 两个子智能体并行运行。其中一个的改动消失了，或者文件最后变成了来自两边、乱七八糟的半合并产物。

根因。 两个智能体都写入了同一个文件，或者各自假设了一个被对方在底下改掉的工作树状态。并行写入者共用一个工作树，就是加了几道工序的竞态条件。

修复方案。 互不重叠的作用域加 worktree 隔离。把智能体 A 的作用域限定在 /auth/、智能体 B 限定在 /payments/，零重叠。当智能体要做非琐碎的改动时，给每个智能体它自己的 git worktree，让它们在独立的检出上操作，事后你再刻意地合并。绝不要让两个写入者共用一棵树。

失败 3：失控的扇出 #

症状。 一次本该只花几千 token 的运行花了 10 倍。或者流水线永远跑不完——它一直在派生智能体。

根因。 在一个没有收敛条件的循环里派生智能体，或者扇出了远超工作量所需的工作者数量。每个子智能体都是一整个上下文那么多的 token；条件反射式的扇出会让成本迅速翻倍。

修复方案。 一份预算加一个停止条件。限定每个阶段的智能体数量上限。对于探索型循环（“找出所有 bug”），改用"连续 K 轮没有冒出任何新东西就停"，而不是开放式的"一直跑"。要刻意地扇出，用一个你有意选定的数字。当你在盯着成本时，这一条加倍重要——在你扩展一条流水线之前，先看看 token 账实际上是怎么算的。

失败 4：静默截断 #

症状。 流水线报告"安全审计完成——未发现问题"。一周后，一个明显的注入 bug 在审计本应覆盖到的代码里冒了出来。

根因。 某个查找型智能体把结果截断到了前 N 个，或者用抽样代替了对整个表面的全量扫描——而没有人记录任何东西被丢弃了。编排器把 60% 的覆盖当成了 100%。

修复方案。 让截断变得高声可见。如果一个智能体限定了它的覆盖范围——前 N 个、抽样、时间上限——它必须在报告里明确讲出来：“检查了 30 个端点中的 18 个；12 个未检查。“编排器要把这个缺口暴露出来，而不是把它咽下去。把局部结果当作完整结果呈现，比诚实地说"我没做完"更糟糕。

失败 5：孤儿 worktree #

症状。 陈旧的 git worktree 越堆越多。更糟的是：后面的某个智能体把一个做了一半的 worktree 当成标准的主树来读，并在一个虚构之上继续往上盖。

根因。 为了隔离而创建的 worktree，却从未被当作有作用域的资源对待。完成后没有清理；没有清晰地界定哪棵树是标准的。

修复方案。 把每个 worktree 都当作一个有生命周期的资源对待。当一个智能体没有做任何改动时，自动清理。当有改动时，显式地 review-and-merge 或丢弃——别让它悬在那。而且绝不让下游智能体把另一个智能体的 worktree 当作基准事实来读；标准状态就是主树，没有例外。（我们亲手在流水线进行到一半时清理过一个孤儿 worktree——这是一个五秒钟的 git worktree remove，能省下一个小时的"这文件怎么是错的”。）

原则 #

这些失败每一个都共享同一个根：把一个智能体的声明当成了经核验的现实。 没被检查的摘要、没被隔离的作用域、没设边界的循环、没被记录的截断、没人负责的 worktree。多智能体编排失败，不是因为智能体笨——它失败是因为编排器未经核验就信任了。把核验和明确的边界内建进每一道接缝里，流水线就会变得既强大又可靠。

搭建生产级的 Claude Code #

可靠的流水线需要一套不会自己制造失败的基础设施：

1. 撑得起长流水线和 CI 关卡的稳定主机。 编排进行到一半时掉了 SSH 会话，本身就是一种失败模式。HTStack ——香港 VPS，对中国大陆低延迟接入，稳定的 BGP。和托管 dibi8.com 的是同一个 IDC，我们就在那里跑这些流水线。每月 $5-12。

2. 供并行扇出用的云端余量。 当你（刻意地、带着预算地）扇出工作者时，多余的 CPU 能让它们不互相争抢。DigitalOcean ——$200 免费额度，有效期 60 天，14+ 个区域。

3. 一套技能包。 避开这五种失败，主要是靠提示词纪律——核验步骤、停止条件、有作用域的资源。我们把五个经过实战检验的技能打包成了一个 $19 的 Gumroad 套件——见角落里的浮动 CTA——其中包含已经把核验接缝内建好的编排器提示词。

延伸阅读 #

• 子智能体模式——这些失败潜伏其中的五种工作流。
• 自定义智能体编写——用输出契约构建可靠的工作者。
• 子智能体 vs MCP vs 技能——挑对扩展方式，免得过度搭建。
• AI 编码智能体的月度账单——失控扇出背后的 token 账。

结论 #

多智能体编排是值得的——当任务确实超出单个上下文窗口、或需要独立核验时。但要刻意地上手它，而不是条件反射地上手。一个提示词写得好的单智能体，每一次都胜过一条有 bug 的五智能体流水线。当你确实要编排时，强大与灾难之间的区别只在一个习惯：对照基准事实核验每一个声明，给每一个循环设定边界。 你无法核验的复杂，比你能核验的简单更糟糕。