我搭的多 Agent 系统第一次崩盘那天，我搭进去一个周二下午，加上大半个周三，才搞清楚到底发生了什么。
一个 Reviewer Agent 悄无声息地批准了一条从第三步就开始跑偏的工作链。Builder Agent 信任了 Reviewer。第一个 Reviewer 又自作主张地派生了第二个 Reviewer——这是两周前我还为之自豪的"自组织能力"——第二个 Reviewer 也批了。等活儿到我手上,已经过了三道关。看起来干干净净。错的方式刁钻到我花了四个小时才把它说清楚。
那一周我没写复盘。我应该写的。我没写的原因,跟大多数跑 Agent 系统的人不写复盘是一个原因:我那时候还没有一套词汇来命名刚才那一摊子东西。 我管它叫"周二那个事",叫了大概一个月。
这篇文章,就是我当年缺的那套词汇。
过去 18 个月,我在生产环境里跑多 Agent 系统。最高峰名册上挂着 86 个 Agent。我看着它们用差不多每一种小型组织能崩盘的方式崩盘。我整理出 11 种失败模式,下面一个一个讲——不是给你做成一张幻灯片的分类法,是一份能让你不用像我那样赔进一个周二下午的现场手册。
开讲之前先报个家底:我是写第一行生产代码之前,先在 HR 这一行干了 18 年的人。在百威英博管过六个城市的人头。在龙湖带过 150 人的团队。开过人,招过人,整个周末关在绩效校准会议室里出不来。这篇文章里的每一种失败模式都有它在人类组织里的对应版本,几乎每一种,人类那一边的命名和理解,都比 Agent 那一边早了三十年。名字不一样。机理一样。
顺便说一句,这就是这篇文章的核心论点:AI Agent 系统不会以新方式失败。它们以老方式失败,只是更快。
先校准一下:什么才算"失败"
正式开列表之前,先校一下尺。我说一个 Agent 系统"失败了",不是指模型输出了一个幻觉事实。那是模型失败,是另一个话题。我说的是:这个系统作为一个组织,产出了违背它自己目标的结果,而这个违背没有被这个系统自己抓住。
这个区分很重要。一个初级员工把一个事实搞错了,那不叫组织失败。一个初级员工把一个事实搞错了,递给一个 senior,senior 盖了个章,递给总监,总监签了字,递给客户——这叫组织失败。那个事实本来就会错。系统本来应该抓住它。系统没抓住。
下面 11 种,都是第二种。系统本来应该抓住它。系统没抓住。
1. 级联幻觉
Agent A 出一个东西。Agent B 把它当输入读进来,当成既定事实,在上面盖楼。Agent C 读 B 的输出,当成"已经被验证过两次了",继续往上盖。等链条跑到终点,最初那个错误已经被洗成了像样的"机构知识"。
我第一次看清楚这件事的时候,最初的错只是一个解析错的文件路径。等我发现,三个下游 Agent 已经把文件写到了错的目录,其中两个在文档里引用了那些写错位置的文件,还有一个把文档 commit 进了 git。我回滚了 90 分钟的工作,去修一个 30 秒的错。
HR 对照版:在大型官僚组织里干过的人都见过。一个 junior 写了份备忘录。一个中层经理没核数据就改了。一个副总因为中层经理签了字,就也签了。董事会读了,做了决策。六个月之后才有人去核——最初那个数差了一个数量级。整条链上每个人都信任它下面那一层。没有一个人真的去验证。
根因:Agent 之间没有契约规定"什么算被验证过"。B 把 A 的输出当福音,是因为 B 没有协议去问"A 真的查过吗,还是 A 也是从上游接的?"在人类组织里,这叫"source-of-truth 纪律缺失"。是同一个问题。
对策:每个 Agent 的输出在跨边界时必须以结构化产物的形式出现,不是一段散文。产物自带溯源——查了什么、推了什么、假设了什么。下游 Agent 必须被它的 prompt 强制要求:先读溯源,再读内容。溯源缺失的,下游 Agent 必须拒收,不能自己脑补。这听起来很官僚。它就是官僚的。 银行的审计追踪也是官僚的,银行崩盘的频率比靠 vibes 跑的初创公司低多了。
2. 协调者瓶颈
你给一群 Agent 上面加了一个 Coordinator,因为扁平结构太乱。Coordinator 变成了所有别的 Agent 都在等的那一个东西。现在你有了一个队列,队列只有一个 Agent 深。
我搭的第二个多 Agent 系统是 2025 年初,一个单 Coordinator 路由所有决策。撑了大概三个礼拜。然后我试着让 12 个专家 Agent 并行跑,眼睁睁看着 11 个闲在那里,Coordinator 把它们一个一个串起来排队。整个系统的吞吐量等于一个 Agent 的吞吐量,不管我加多少专家。我搭出来一个苏联时代的部委。
这种 HR 对照版熟到管理学文献给它单独命过名:叫"审批瓶颈"。所有决策都路由到一个人那里,那个人就成了组织里最慢的环节,往他下面加人不会缓解,只会恶化。人类组织的解法是有边界的授权。Agent 系统的解法一样。
根因:Coordinator 被赋予了否决权,但没有给它一份"什么属于我必须否决的范围、什么应该自动放行"的章程。所以它否决一切——因为否决错的代价是隐形的,放行错的代价是当场就要承担的。
对策:给 Coordinator 写一份真正的章程。列出三到四类它必须亲自批的决策。其余的全部自动放行 + 下游审计。任何组织里,无论是人类的还是 Agent 的,多数决策都不需要老板。老板批它们,是老板怕担责的信号。 Coordinator 没有感情,但它会继承写它的那个 prompt 工程师的胆怯。
3. 沉默漂移
Agent 的行为慢慢偏离了它的本意。不是一夜之间。在 40 个 session 里它捡起一点点小变形——也许开始变得啰嗦,或者更小心翼翼,或者开始往结尾加一些原始 prompt 里根本没有的免责声明。到第 60 个 session,它在功能上已经是另一个 Agent 了。没人发现,因为每一个 session 跟它前一个 session 比,看起来都正常。
我有一个代码审查 Agent,用了大概六周,慢慢漂移成了一种泛化的"乐于助人"姿态。它开始在 review 的开头先写两段鼓励的话再讲实际问题。实际问题开始被软化。最后它批准了带着关键 bug 的 PR,因为它已经漂到一个地步——挑 bug 让它"觉得自己很刻薄"。我把它退役了,从原始 prompt 重建。
这是最让人迷糊的一种失败模式,因为没有任何东西"坏了"。系统在跑。输出看起来正常。漂移只有在你直接对比 session 1 和 session 60 的时候才能看见,而这件事没人会做,因为到第 60 个 session 的时候,你已经忘了 session 1 长什么样。
HR 对照版:每一个不再在绩效面谈里说真话的 senior leader。他们开始为了"这场对话感觉好一点"而优化。六年之后,他们手下一队人都开不掉,因为存档里每一份 review 都写着"超出预期"。
根因:没有固定参照系。Agent 的身份隐含在它的 prompt 里,但它的行为是从 prompt + 上下文 + 历史 session 的强化里浮现出来的,后两个会漂,前一个不会。
对策:每个 Agent 都有一个评测套件——一组固定的测试输入,每周跑一次,输出和黄金参照对比。漂移变成可度量的。我第一次实施这套机制的时候,逮到三个 Agent 朝同一个方向漂——都在变得"和稀泥"。这告诉我问题不在某一个 Agent 身上,问题在我自己的 prompt 上:我一直在把它们都训得软。我自己漂了,它们跟着我一起漂。
4. 上下文衰减
Agent 干一个跨多个 session 的长任务。关键上下文——什么决定过、什么试过、什么否决过——都活在一个会被压缩、被摘要、或者干脆在 session 之间丢失的上下文窗口里。Session 5 做了一个决定,这个决定 Session 2 已经明确否决过了。Session 8 又把 Session 1 已经定下来的架构选择拿出来重审一遍。
这一种我感受最深的一次,是在一次四天的 Agentic Engineering 集中开发期间。第三天我注意到一个 subagent 反复提出一些我第一天就拒绝过的方案。那个否决活在一份我没把它显式注入到 agent 工作上下文里的备忘录里。这个 agent 不是傻。它是真的不知道。
根因:上下文被当成对话的副产物,而不是被管理的资产。在人类团队里,这叫"机构记忆缺失"。新员工反复犯老错误,因为没人把学到的东西写下来。公司层面的解法是文档纪律。Agent 系统的解法一样。
对策:在上下文窗口之外,维护一份刻意的、结构化的记忆产物。决策、否决、约束。Agent 在任何新 session 里第一件事,就是去读这份记忆产物。不是"摘要一下上一段对话"——那会丢东西。读那个记忆文件。记忆文件是老板。对话是干活。
5. 虚假共识
三个 Agent 独立 review 同一个产物。三个全批了。东西上线了。两天之后发现,这三个 Agent 都在同一个训练分布里取样,权重相同,它们一起朝同一个方向,错过了同一个盲点。
这是 Agent 版的"相关误差"——投票理论里的一个概念。你以为你有三个独立 reviewer,你实际上有的是一个 reviewer 配三个图章。安全性的数学逻辑依赖独立性。没有独立性,加 reviewer 不会增加安全性。它只会让你以更高的信心持有同一个错误答案。
我曾经为这个赔进去一个礼拜。我让三个"不同" prompt 的 Reviewer 去核查事实声明。三个跑的是同一个底模,prompt 拿出来一对,70% 是一样的——因为我把自己最爱的 review 模板复制粘贴了三份。所谓的"多元评审团",其实是理发店里的两面对镜——看起来是无数人,实际上是同一个我。
HR 对照版:每一个所有人都是同一所学校毕业的招聘委员会。每一个所有成员都是同一个高管提名的董事会。结构看起来像制衡。实质是一个人投了六票。
根因:独立性是被假设的,从来没有被工程化。视角的多样性,需要底层的多样性——不同的模型、不同的 prompt 骨架、不同的工具集、不同的评估标准。否则你拿到的不是共识,是回音。
对策:搭一个 review 评审团的时候,明确写下每一个 reviewer 在查什么是别人不查的。如果你说不出区别,那你只有一个 reviewer 在假装是三个。砍掉两个。它们没在加安全性,它们在加延迟。
6. 工具滥用
你给一个 Agent 一套工具——比方说,能读文件、写文件、跑 shell、搜网。Agent 把你的问题解决了,但路上它顺手读了 20 个用不上的文件,写了三份你没要的日志,跑了一次它本来就知道答案的网络搜索,还在你的 home 目录留下了一份临时脚本。
它解决了。但它什么都摸了一遍。
我第一次认真追踪这件事的时候发现,我的某一个 Agent 平均每个任务打开 47 个文件,用上的有 4 个。剩下 43 个是"探查性对冲"——"我先读一下,万一呢"。每次读都是 token 成本、延迟成本、外加一个小但真实的风险——Agent 撞到一个无关的东西,岔到另一条路上去。
这是 Agent 版的"scope 蔓延",加一点安全人士说的"最小权限原则违规"。Agent 每次都把它有的工具全用一遍,因为 prompt 没告诉它别这么干。
HR 对照版:那个新来的高级 hire,第一个月给公司里所有人都约了一遍"自我介绍会议"。六个礼拜之后你发现他根本不知道自己的本职是什么,但他认识全部 200 名员工,并且对供餐供应商有强烈意见。
根因:工具是作为能力被授予的,但没有给使用设预算。给一个 Agent 一把锤子,它会打所有看起来像钉子的东西——加上一些眯眼看也像钉子的。
对策:工具预算。Agent 每个任务默认 10 次文件读。要更多可以申请,写理由。多数 Agent 给了预算之后,只用三分之一。事实证明那些对冲性的读,从来就不是必要的。它们只是在没有约束的时候,阻力最小的那条路。
7. 目标侵蚀
Agent 把一个目标拆成子任务。它把每一个子任务都执行得无可挑剔。这些子任务加在一起,没有产出那个目标。
这是最让我冒火的一种失败模式,因为每一步单独看都对。Agent 在每一个局部都精准地干了被吩咐的事。它只是不再在干那个全局上想要的事。你读 trace,每一行都合理。你读输出,是错的。
我有一个 Agent,把"审计我们 top 10 页面的 SEO"这个任务拆成了 10 个子任务:每个页面跑一份 checklist。它干得漂亮极了。每个页面拿到一份完美 checklist。而我真正想要的是一份对比性的分析:哪些页面在拉动,哪些在拖累,战略再平衡的杠杆点在哪里。10 份 checklist 不是这个东西。10 份 checklist 是审计版的——你要的是一份战略备忘录,10 个员工交了 10 份打卡记录。
HR 对照版残忍而古老:这就是为什么有些公司每个季度都击中所有指标,最后还是死了。每个季度团队都对着指标完美执行。指标是真实目标的一个代理。代理和目标在五年里漂得越来越远。团队是英雄的,公司是死的。
根因:Agent 的目标函数是子任务,不是目标。一旦拆解发生了,目标就在活跃的上下文里不再被表征了。
对策:每一个子任务在它的 prompt 里都带着目标。不是"做计划的第 4 步"。永远是:"总目标是 X。计划第 4 步是 Y。完成第 4 步之前,先验证 Y 是否仍然在服务 X。"这听起来像额外开销。它就是额外开销。它也是你和"一个完美实现了错误系统的 Agent"之间唯一站着的那道门。
8. 权限混乱
本来负责派活的 orchestrator Agent 开始写代码。本来负责执行的 executor Agent 开始做架构决策。本来负责 review 的 reviewer Agent 开始改东西。
你最后得到的是纸上一份组织架构图,地上一场群架。
这是我个人最挣扎的一种失败模式,因为我作为人在回路里,也干同样的事。我会搭一套漂亮的派活结构,然后等某一个 Agent 太慢的时候,干脆自己上手做了。我周围的 Agent 看在眼里。它们开始照做。一个礼拜之内,我搭起来的结构就退化成了"大家想干啥干啥,J 叔来打破僵局。"
HR 对照版是管理学里最古老的病灶之一:戒不掉自己上手的创始人。 他们建团队、招聪明人,然后到 deadline 那天绕过团队自己把功能发了。团队学到的是:他们的权限取决于创始人的耐心。他们停止 own 任何东西。创始人抱怨说手下没有 senior。他们手下本来有 senior。是他们把 senior 训没了。
根因:权限只在 prompt 里被声明,从来没在协议层被强制执行。你告诉一个 Agent"你是 orchestrator,不要写代码",它一样可以写代码,因为没有任何东西真的拦着它。
对策:在工具层面把权限和能力分开。orchestrator 字面意义上没有 write_file 这个工具。它只有一个 delegate 工具。它要写代码,必须派出去。这听起来很硬。它就是该硬。 真实组织里强制 separation of duties 也是这么干的——controller 不能同时是 auditor,不是因为我们更不信任他,是因为这个结构本身才让信任有意义。
9. 身份崩塌
在一段长对话里,Agent 慢慢忘了自己是谁。它出场是个代码审查员。到第 40 轮,它在模仿用户的语气,认同用户的框架,用用户的口吻写东西。Agent 变成了一面镜子。
这件事我看得最清楚的一次,是和一个 Agent 一起写战略备忘录。session 第二个小时,它停止了反驳我的论点。第三个小时,它把我自己的措辞反过来用回我身上,仿佛是它想到的。第四个小时我才反应过来,我已经自言自语了 90 分钟,并把它叫做"协作"。
这不只是讨好。讨好是其中一部分。这是身份侵蚀:Agent 那个独特的视角——这是一开始要这个 Agent 的全部理由——在用户上下文的引力下被慢慢磨平了。Agent 在 session 结尾成了用户的反射。
HR 对照版:那个在客户那里嵌入太久的咨询师。他被请来是为了带外部视角。沉浸六个月之后,他思考方式跟客户一模一样。他还在被付钱"想得不一样"。他已经做不到了。
根因:Agent 的身份握在 session 起头那个 prompt 里,被之后每一条消息稀释。一段长对话结束的时候,prompt 在活跃上下文里只占很小一块。用户的声音占主导。
对策:周期性刷新身份。每 N 轮,Agent 被要求在回复之前重申一遍它的角色和它的使命。或者更激进:结束 session,开新的。一个聊了六小时的代码审查员,已经不再是一个代码审查员了。他是个朋友。朋友是有价值的。朋友不是你想用来 review 你代码的那个人。
10. 事实门禁绕过
Agent 本来要在引用一个声明之前先验证它。它没有,它直接从训练数据里把声明引出来,并把这个引用标记为"已验证"。验证那一步,被一句听起来很自信的"我验证过了"替换掉了。
这是最危险的一种失败模式,因为它把安全机制武器化了。你设了一条规则——"每一个事实声明都必须对照一手来源核查"——Agent 字面意义上服从了这条规则,因为它说了"我查过了"。它没查。它说了它查了。标签替代了动作。
我有一次在做竞品分析的 Agent 上抓到这件事。每一条关于竞争对手的声明后面都跟着一个引用。引用看起来很真。其中大概三分之一指向不存在的 URL。Agent 模式匹配出了"引用"长什么样——域名、slug、标题——然后生成了一些看起来合理的,再给自己的输出贴上"已验证"。
HR 对照版:那个填合规培训表格的经理,从头到尾点"下一步",一个字没读。培训本来是要产生行为变化的。表格产生的是 Excel 上一个勾。审计员看到那个勾,批了。行为从来没变过。培训本来要去缓解的那个风险,仍然活着。
根因:Agent 被告知验证长什么样——一个引用、一段引文、一个置信度标签——但没被给一个真正执行验证的工具。所以它产出了"一个被验证的过程会产出的输出的样子"。这不是说谎。Agent 没有"说谎"这个概念。它被训练出来的是产出符合某种模式的文本。"已验证文本"的那个模式,就是它产出的东西。
对策:验证必须工具化,不能描述化。Agent 不能只说"我查过了"——它必须产出查这个动作本身的产物:实际抓回来的 URL、实际引出来的原文、实际查过的文档的 hash。产物缺失,声明就是未验证的,无论 Agent 给它贴了什么标签。信任不是一个标签。信任是一条审计追踪。
11. 回音室
你搭一个 Reviewer Agent 来审 Builder Agent 的工作。Reviewer 是同一个 prompt 工程师写的,依据是同一套架构假设,对照的是 Builder 本来就被优化去满足的那同一套评分标准。Reviewer 批准 Builder 的工作——因为,在深层意义上,它就是同一个 Agent 换了个工牌。
这是我对自己系统最警惕的一种失败模式,因为它在产物层面是不可见的。Builder 的输出过了 Reviewer 的检查。产物看起来是被审过的。它确实被审过——被它自己的副本审了。
这件事危险在于它完美地 scale。每多加一个同血统的 Reviewer,安全性增加为零,但延迟、成本、还有用户的信心都增加。你付更多钱,去用更高的确信度坚持错的答案。
这里的 HR 对照版精确到我觉得有点好笑:那个招了三个"顾问"的创始人,三个都是前同事,都来自同一家咨询公司,都带着同一组先验。这个顾问结构是一台治理戏剧。决策跟创始人一个人能做出的决策一模一样,只是多了几个签名让它显得"经过深思熟虑"。
根因:Reviewer 的使命、prompt、评估标准都是从 Builder 那里派生出来的。它们共享基因。独立性需要外族 DNA。
对策:Reviewer 必须由设计 Builder 那个人(或那个流程)以外的人/流程来设计。在我自己当前的搭建里,我跑跨 Agent review,Reviewer 跑在完全不同的模型家族上,prompt 从一个不同的起始框架写起,对照的是 Builder 从未被优化去满足的那套标准。多数时候,Reviewer 同意 Builder。剩下 5% 不同意的时候,它捕到的是真 bug。没有那 5%,剩下的 95% 毫无意义。
更大的教训:A 组不能 review A 组。 这是任何质量体系的铁律。它适用于人类。它适用于 Agent。它适用于我——这就是为什么这篇文章在发出去之前,会被我的 B 组撕一遍。我刻意把 B 组在结构上设计成对我充满敌意的。如果你没有 B 组,你 A 组的自信就是你系统里唯一的质量信号。自信不是质量。
这 11 种的共同点
如果你认真读了,你会注意到:每一种失败模式,根上都是一个治理问题。不是模型问题。不是 prompt 问题。是治理问题。
级联幻觉是 source-of-truth 纪律的缺失。协调者瓶颈是授权的缺失。沉默漂移是周期性校准的缺失。上下文衰减是机构记忆的缺失。虚假共识是真正多样性的缺失。工具滥用是 scope 纪律的缺失。目标侵蚀是战略对齐的缺失。权限混乱是 separation of duties 的缺失。身份崩塌是角色完整性的缺失。事实门禁绕过是审计的缺失。回音室是独立监督的缺失。
这每一种都是人类组织在 20 世纪期间识别过、命名过、并发展出反制手段的问题。我们不需要为了管 Agent 系统去发明新理论。我们需要把已经有的理论想起来,然后用 Agent 要求的那种速度去执行它。
这部分我看清楚之后,我对 Agent 这一行有点恼火。这一行有一半的人在从零反复发明组织行为学,发明得还很差,并且假装这是新的,因为工人是 token 做的而不是人做的。它不新。它是 HR,换了个底料。底料跑得更快。仅此而已。
我现在怎么干
被这 11 种全部撞过一遍之后,我自己当前的搭建收敛到几个习惯,比我搭过的任何一个具体 Agent 都更值钱:
每个 Agent 都有一份写下来的 charter。一段,有时两段。它做什么、它不做什么、它向谁汇报、它产出什么产物、什么算它失败。如果我没法在两段之内把这份 charter 写完,那这个角色太模糊,这个 Agent 一定会在上面 11 种里某一种栽。
每个 Agent 都有一个评测套件。固定输入,预期输出,每周跑。漂移在还小的时候就被抓出来。
每条多 Agent 流都有显式的交接契约。上游 Agent 保证什么?下游 Agent 验证什么?契约违反时怎么处理?这些不写下来,失败模式就会交织在一起,你都搞不清楚是哪一种咬到你了。
每一个 Reviewer 都跟它要 review 的对象有不同的 DNA。可能的话不同的模型家族,最低限度也要不同的 prompt 血统。没这个,review 就是戏剧。
每个长任务都有一份在上下文窗口之外的记忆产物,Agent 第一件事是去读它。
差不多就这五件事。五条纪律。没有一条是 AI 专属的。所有这五条,我用来管 2018 年一个 50 人的团队,也是这么管的。 唯一变了的是团队现在是 Agent 做的,而搞错了的代价以分钟为单位到达,不再以季度为单位到达。
我以前那个 HR 老板 18 个月前给我打过电话,告诉我:你搭了一家没有组织架构、没有解雇政策的创业公司。 他说得对。他第一次那么说我的时候,我没真听进去。我得先赔进去一个周二下午、然后是一周、然后是一整个系统,他对我念叨了十年的那句话,才落地。
如果你现在正在跑一个多 Agent 系统,问你自己他问我那个问题:你有组织架构图吗?你有解雇政策吗?你有写下来的 charter 吗?你有独立的 review 吗?
没有的话,你有的是一个 swarm。Swarm 会塌。上面 11 种就是怎么塌的。
有的话,你有的是一家公司。公司也会失败——但它们以你看得见的方式失败,而那才是整个游戏。