Agent 失败模式与评审训练

0. 为什么先认识失败,而不是先学怎么修

先说清这一章的位置,你才知道该用什么姿势读它。前面九章一直在往 harness 上加能力,每加一样,你其实都在和某一类失败作战:加终止和预算是怕死循环烧钱,加沙盒是怕模型生成的代码搞破坏,加 context 工程是怕长任务把模型用糊涂,加评测是怕你自信地部署一个会翻车的 agent。换句话说,前九章是按「能力」组织的,而这一章把同样的知识按「失败」重新组织一遍。这种重新组织本身就是一种学习,它让你从「我知道怎么做对」升级到「我能闻出哪里要做错」。

这里有一个被反复验证的教学事实:陈述性知识不等于程序性知识。你读完一份失败清单、能复述每一种,这是陈述性的;但真到一个失败在你眼前发生、你能瞬间认出它,这是程序性的,两者之间隔着「真正在脑子里见过几次」。优秀的工程师和新手最大的差距,往往不是谁懂的概念多,而是谁的脑子里安了更多报警器。所以这一章的读法不是背清单,而是对每一种失败,先在脑子里放一个它发生时的画面,等真见到时,警报会自己响。

在进入具体失败之前,先装三条贯穿全章的素养,它们比任何单条失败都更值钱。第一,大多数 agent 失败不是模型失败,而是系统、context、编排的失败。研究 multi-agent 失败的 MAST、微软的系统级 taxonomy、以及大量生产实践,三方收敛到同一句话:生产里的失败主要不是模型不够聪明,而是 harness 没搭好。这恰好呼应整条路书那句模型加 harness 才等于 agent,失败也主要落在 harness 侧,所以它们大多可以工程修复。第二,agent 失败常常局部看着没问题。每一步的输出单独看都通顺、都合理,失败只在跨步累积或回看更早的 context 时才显形,这是 agent 失败比传统软件失败难抓的本质,也是为什么你必须读整条轨迹而不是只看最后一步。第三,失败常常成对出现在两极,而两极同源于一个根因。

停不下来的失控循环,和没干完就宣布完成的过早终止,是一对;反复自查不前进的过度验证,和让错误逃逸到下游的不验证,是一对;历史太多淹没新计划的上下文干扰,和该记的没记住的记忆遗漏,又是一对。每一对的两极看起来相反,根因却是同一个:agent 不会可靠地评估自己的进度和状态。成对地记比单条地记解释力强得多,而且它会提醒你一件很实用的事,修一极的时候别用力过猛滑到另一极。这三条素养是这一章其余部分的地基。

1. 2026 的失败地图:六份 taxonomy,各切一面

到了 2026 年,agent 失败已经从「大家私下吐槽」变成了一个有多份学术 taxonomy 的研究领域,而这件事本身就是一个 why-now 信号:它和对抗安全、context 工程在同一时期结晶,因为 agent 真的开始进生产、失败开始有真实代价,业界才被迫把它系统化。但这里要立一条记分牌素养:不存在一份权威的失败清单,存在的是好几份互补的 taxonomy,各从不同切面切。你要学的不是背诵某一份,而是知道每份量的是哪个切面,再把它们合成一个你自己能用来诊断的视图。

把这六份合起来读,你会发现它们其实在拼同一张地图的不同区块:MAST 擅长协同层,AgentDebug 擅长「坏在哪个模块」,微软擅长系统级隐藏失败,Breunig 擅长上下文。这一章接下来做的事,就是把它们重组成一个对单 agent 和 multi-agent 都通用的、可诊断的视图,而不是让你在六份清单之间反复查表。

2. 规范失败 taxonomy:五个家族,每族指回哪章修

现在交付这一章的核心:一套规范的失败 taxonomy。它沿用一个很老但很好用的教学结构,每个失败模式都有症状、根因、和防御三栏,而这一章给它加了关键的第四栏,哪一章修。这第四栏是整条路书的整合价值所在,它让每一种失败都不再是孤立的怪事,而是某一章技术缺位的征兆。失败分成四个功能家族,外加一个指针类。

四个功能家族是这一章诊断的对象:A 工具与动作层、B 推理与控制层、C 上下文与记忆层、D 协同与验证层。第五个家族 E 是安全,它由攻击者故意诱发,防御归 Ch5,这一章只把它当一个指针。判断一个失败属不属于 E 有一个很干净的边界闸,问一句:没有攻击者,这个失败也会发生吗?会,就是功能失败,在这一章;只在有人故意构造时才发生,就是对抗失败,去 Ch5。

2.1 族 A · 工具 / 动作层

这一族是 agent 伸手去做事时手滑。最典型的是幻觉工具调用,你给了它 search_web,它却去调一个根本不存在的 google_search,然后要么报「工具不存在」要么静默崩掉。这里有一个 2026 年颇反直觉的发现:用强化学习把模型的推理训得越好,它幻觉工具的概率反而越高,因为更强的推理让它更敢于「脑补」一个本该存在的工具。第二种是幻觉输出或参数,它编造一个根本没发生的 API 返回,或者给一个合法工具喂了不合法的参数。第三种最阴险,叫错误级联:工具返回了一句 "Error: rate limited",agent 把这句错误当成搜索结果总结了进去,于是这一步的错静默污染了后面每一步。

这一族的防御几乎全在 Ch3 怎么写让模型用对的工具:工具描述写清楚、参数上 schema 校验、返回值结构化地区分成功和失败,模型手滑的概率就大幅下降。

2.2 族 B · 推理 / 控制层

这一族是 agent 脑子转歪了,是失败模式里最丰富的一族。一头是失控循环,几十次调用烧到上限、反复在做同一件事却不交付,根因除了没设干净的终止信号,还有 reasoning 模型本身的循环倾向;另一头是它的镜像,过早终止,部分进度就宣布完成、功能没测就标完成。这两极同源于 agent 不会可靠评估「任务真做完没」。目标漂移是另一个高频且涌现的失败:没有任何单步出错,但「修个 bug」五步之后变成了重构加改 import 加重写测试,因为每一步的即时 context 一点点压过了最初的意图。还有想做的和做的不一致,thought 里说要做 A、action 却做了 B;以及谄媚,用户一质疑就把本来正确的答案改错。

失控和过早这一对的防御在 Ch2 的终止与预算;目标漂移要靠 context 工程在每步重述原始目标;谄媚和钻空子的训练级根因归后训练,但识别它们是这一章的事。注意 B5、B6 这两条,根因虽然在训练侧,可你在生产里照样会观察到,所以诊断时要认得出来。

2.3 族 C · 上下文 / 记忆层

这一族是 agent 的工作记忆被搞坏了,正好对应 context 失败的四种经典形态。投毒是一个幻觉或错误进了 context 又被反复引用,agent 自信地在错误前提上一路推下去;DeepMind 那个玩宝可梦的 Gemini 是最直观的例子,它的目标段被污染后,追着另一个游戏里根本不存在的道具找了几十回合。干扰是 context 长到模型过度依赖历史、不再综合新计划,超过十万 token 后尤其明显。混淆是无关信息尤其是工具过载拉低了输出质量,这不是长度问题而是复杂度问题,工具一多模型就开始选错。冲突是 context 里不同来源互相矛盾,模型挑一个而你无法预测它挑哪个。

这一族的机制深挖几乎全归 Ch6 的 context 策略,跨会话的记忆遗漏归 Ch7。这一章只要你认得出「这是 context 投毒,不是模型变笨了」,就达到了目的。

2.4 族 D · 协同 / 验证层

这一族是多个 agent 一起干或 agent 自查时出的问题。不验证是最朴素的一条,agent 不自查,错误就直接逃逸到下游。交接错位是协同的核心失败,handoff 把 context 丢了、或者一个 agent 忽略了另一个 agent 的输入、或者并行的 agent 基于各自没明说的假设做出了冲突的决策。跨 agent 的错误级联是单 agent 那个 A3 在多 agent 里的放大版,Agent A 的脏输出进了 Agent B 的 context 被当成事实往下传。成本崩溃是账单突然 30 倍,但它多半不是独立根因,而是失控循环或没有预算执法的下游后果。版本漂移是个很现代的模式,模型、prompt、或工具 schema 升级之后,行为悄悄变了。

交接和跨 agent 级联归 Ch8 的协同机制,版本漂移和不验证归 Ch9。Anthropic 在 2026 年 4 月那次 Claude Code 质量事故,根因正是三个看似无害的改动叠加成的版本漂移,后面 demo 会细讲。

2.5 族 E · 指针类 · 对抗诱发的失败 → Ch5

最后这一族不在这一章展开。提示注入、致命三连、工具投毒、目标劫持,这些都是上面某个功能失败的对抗版本,目标劫持就是被故意诱发的目标漂移,记忆投毒就是被故意诱发的上下文投毒。它们的系统防御在 Ch5 的对抗安全。判断一个失败该不该来这一族,就用那把边界闸:没有攻击者也会发生的,是功能失败,留在这一章;只在有人故意构造时才发生的,去 Ch5。

3. 两套 SOP:诊断一条失败,评审一份方案

认识了失败的家族,接下来是把它变成两个可操作的动作。一个是事后的,拿到一条已经失败的轨迹,怎么一步步定位根因;另一个是事前的,拿到一份还没跑的设计方案,怎么提前揪出它会暴露的失败。两个动作共享同一套坐标系,区别只在输入。

3.1 SOP-A · 诊断一条失败轨迹

这是这一章比传统设计评审更进一步的地方,也是顶尖实验室 agent 工程师的日常技能:读一条失败的 trajectory,定位到根因那一步。

第一步,复现并取全 trace,读整条轨迹而不是只看最终输出。这是第一性原理:agent 失败局部看着没问题,只看最后一句话会系统性漏掉很大一部分失败。Anthropic 有个惨痛教训,他们早期的一个 agent 系统只有 WebSocket 事件流、看不到失败具体在哪发生,于是 harness 的 bug、丢包、容器掉线长得一模一样,根本没法诊断。可观测性不足,等于诊断不可能。第二步,沿轨迹找第一处偏离,也就是最早一步、模型的输出或动作开始偏离正确路径的点;研究发现这种偏离常常能追到一个特定的决策点,而且往往在很靠前的第二步左右。这一步有个关键的坑要避开:不要被传播错误误导,下游一堆错可能都源于上游一个根因错,你要找的是那个根,不是它带歪的一长串。

第三步,把根因那一步归到一个模块,是 memory 召回错了、reflection 没反思或反思错了、planning 计划不可行、还是 action 幻觉了工具,把「坏在哪」收敛到一个模块。第四步,把它归到 Ch9 立的失败归因四象限:根因是 harness 失败、model 失败、inference 失败、还是 product 失败?这一步决定修复落在哪,harness 失败去 #8 各章工程修复,model 失败换模型或交给模型设计和后训练,product 失败改任务定义。第五步,给这个失败一个规范名,就是上一节 taxonomy 里的 A1、B3、C1 之类,并指到它的哪章修。命名的价值是把「这次怪怪的」升级成「这是 C1 上下文投毒,Ch6 的失败标记加 reset 能治」。第六步,给修复并固化:不只是「加个 X」,而是说清楚加 X 解决了 Y、代价是 Z,而且把这条失败固化成一个回归用例、一条规则、或一个 skill,否则它一定复发。

这套 SOP 的边界要划清:第一步和第四步背后的归因框架与评测基础设施是 Ch9 拥有的,这一章教的是拿到 trace 之后,人怎么逐步走诊断动作。第六步里那个让 agent 自己学的自动闭环归 Ch7,这一章是人主导的固化。

3.2 SOP-B · 评审一份还没跑的方案

事前评审几乎照搬一套经过验证的六步动作,只把坐标系换成了 #8 自己的脊柱。第一步,读完提议方案,先停下来做一个第一印象判断,把直觉记下来,后面好对照;这一步看着多余,其实是把判断力逼成直觉的关键动作。第二步,用三支柱挨个问,这个方案可靠吗、可扩展吗、可维护吗,各列出具体威胁。第三步,用 #8 的章节脊柱挨个扫一遍:循环的终止和预算稳吗(Ch2)、工具设计和治理对吗(Ch3)、安全防住了向内和向外吗(Ch4 / Ch5)、context 管理跟得上长任务吗(Ch6)、memory 和自我改进有没有(Ch7)、真需要多 agent 吗(Ch8)、可观测和评测够吗(Ch9)。第四步,拿上一节的失败 taxonomy 扫一遍,看哪一族失败的征兆已经在方案里冒头。第五步,找出最严重的三个具体缺陷,不要泛泛说「这里不太好」,要具体到哪个组件、什么场景、什么症状。第六步,给修改方向,还是那句「加 X 解决 Y、代价 Z」。

两套 SOP 共享的坐标系就是这几样东西的叠加:Ch9 的失败归因四象限决定修哪,这一章的五个失败家族给规范名,AgentDebug 的四个模块给归因粒度,再加上那条贯穿的铁律,只修根因别追传播。把这套坐标系记熟,无论手里是一条已经失败的轨迹还是一份还没跑的方案,你都能用同一套尺子扫一遍。

4. 三个评审 demo:把动作走给你看

光有 SOP 不够,得看几遍真的怎么走。下面三个 demo 都按同一个五段结构:提议方案、第一印象、走坐标系评审、找出三个具体缺陷、给改后方案。

第一个是客服 agent。提议方案是:一个 agent 接所有客服请求,挂上查订单、退款、改地址、查物流四个工具,系统提示写「你是一个有帮助的客服助手」。第一印象就该响一串警报。走坐标系评审会发现:工具里有退款这种高风险写操作,却没有任何审批门(Ch4 / Ch5 的向外威胁);四个工具都堆在一个 agent 上,简单的查物流和危险的退款共用一套权限(C3 工具混淆的苗头);系统提示太空泛,没有任何 policy 约束,模型遇到「我要全额退款」这种请求时无所适从(B5 谄媚的温床)。三个具体缺陷定下来,改后方案就清楚了:退款走单独的审批门、按风险给工具分级权限、系统提示里写死退款的 policy 条件。这个 case 的教学点是,客服这种场景的核心风险不在「答得好不好」,而在「该不该执行这个写操作」。

第二个是 RAG 问答。提议方案是:用户提问,检索文档,把 top-5 塞进 context,让模型基于检索结果回答。第一印象:看着标准,但有几个 2026 年已经成共识的洞要补。走坐标系:检索不到相关文档时会怎样?多半是模型硬编一个答案,因为没有「答不出来就承认」的兜底(D1 不验证 + A2 幻觉)。top-5 直接塞进去,排序质量靠检索器一锤定音,没有重排(C3 的苗头,无关文档进了 context)。检索结果和模型自己的训练知识冲突时,挑哪个不可预测(C4 上下文冲突)。三个缺陷,改后方案:加一个「检索置信度低就明说不知道」的兜底、在 top-k 之后加一层重排、并在提示里规定以检索结果为准并标注出处。教学点是,RAG 的失败大多不在生成而在检索和兜底。

第三个是 multi-agent 研究系统。提议方案是:一个主 agent 把研究任务拆给五个并行的子 agent,各自搜一个子方向,主 agent 汇总。第一印象:这是 Anthropic 那个系统的形状,能用,但要先问一句该不该上多 agent。走坐标系:子任务真的互相独立吗,如果其实需要共享上下文,并行会让它们基于冲突假设各干各的(D2 交接错位、Cognition 那个 Flappy Bird 的教训);五个子 agent 各烧一份 token,成本是单 agent 的十几倍,任务价值撑得起吗(D4 成本);主 agent 汇总时,某个子 agent 的脏输出会不会被当成事实(D3 跨 agent 级联)。改后方案:先用决策框架确认任务确实可拆且不需共享上下文、给每个子 agent 写死边界和输出格式、汇总前对子结果做一致性检查。教学点是,多 agent 不是更强,是一个 trade-off,评审它的第一问永远是「这里真的需要它吗」。

5. 把坐标系装进脑子:内化 drill 与五个模板

到这里你已经有了完整的坐标系,但前面说过,陈述性知识不等于程序性知识,中间隔着真正用过几次。这一节给你把坐标系装进脑子的具体动作。核心动作很简单:打开你当前手上的 agent 项目,逐个模块用下面的模板去问 AI,把它回答里你不熟的术语圈出来,那就是你下一份阅读清单。一周里每天跑一个不同模块,七天后看你的术语表收敛到哪。有三个信号告诉你坐标系正在装进脑子:一是 AI 反复用某些术语,那是你这条业务线的高频锚点;二是你开始能预判 AI 会怎么答,说明坐标系进脑了;三是你能挑出 AI 答案里不到位的地方,说明判断力起来了,你从「用 AI 写代码」升级到了「用 AI 写代码并且能 review AI」。这第三条,正是这条路书终点那句「看一份 agent 方案能 spot 反 pattern」的操作化。

五个模板分别练不同的动作。前四个是评审和选型用的:T1 让 AI 用三支柱对比两个方案,并说明每个方案最先暴露哪一族失败;T2 让 AI 判断一个需求该用 workflow 还是 agent,逼出简单优先的纪律;T3 让 AI 沿四个失败家族预演,每族列出具体失败模式和哪章的技术能防,再按影响乘概率排序;T4 让 AI 用 #8 的章节脊柱给你的方案做一次自评审。第五个模板是这一章专属的,直接练 SOP-A。

这是我一个 agent 失败的完整 trajectory:
[贴 thought / action / observation 逐步 trace + 任务目标 + 期望输出]

请按以下步骤诊断,不要只看最终输出:
1. 找出最早一步开始偏离正确路径的点(first divergence),
   引用具体是第几步、那步做错了什么。
2. 区分这是 root-cause error 还是 propagated error
   ——如果下游一堆错都源于上游一个错,只指出那个根。
3. 把 root-cause 归到一个模块:memory / reflection /
   planning / action,并说明为什么。
4. 归到失败归因四象限:harness / model / inference /
   product——这决定修复落在哪。
5. 给这个失败一个规范名(从工具层 / 推理控制层 /
   上下文层 / 协同验证层里选)。
6. 给一个修复:不只是「加 X」,说明加 X 解决 Y、代价 Z,
   并给出怎么把这条失败固化成一个回归 eval case
   / 一条规则 / 一个 skill,防止复发。

回答里所有专业术语请加粗,我要拿去补盲。

这个尸检模板是这一章最高价值的练习。读一条轨迹定位根因,是这条路书一开始就承诺的核心能力,也是顶级实验室 agent 工程师 JD 里隐含的日常工作。拿你自己真实的失败跑上几次,SOP-A 就从一份清单变成了你的直觉。

6. 把杂乱的失败转成持久的修复

诊断出根因只是一半,另一半是让这次失败再也不发生。这里要和 Ch7 划清一条线:Ch7 讲的是 agent 自己从失败里自动学,运行时无梯度地自演化;这一章讲的是人从失败里学,读轨迹、做评审、把修复固化下来。两者是同一种精神的两端,这一章是人在环的那一端。OpenAI 公开的那个自我改进的报税 agent,是这个人主导闭环最好的工业范本。

它的闭环是这样转的。先是分诊,把反复出现的产品失败和预期内的噪声分开,只有可行动的、反复出现的失败才值得修,不是每个失败都修。然后把一个反复出现的失败打包成一个带代表性输入和期望输出的定向评测集,用他们的话说,给模型一座可以爬的山头。接着是根因调查,这一步和 SOP-A 的第三到五步同构:不是只盯着糟糕的最终输出,而是把轨迹、评测、代码库、技能放在一起看,对照一份候选根因清单,判断到底是某个字段没支持、抽取模式漏了、还是选错了源、还是 grader 本身有问题。修完验证,把这条失败固化成一个回归评测;而那些模糊的、说不清的案例,退回给人,不硬塞给自动化。三个月跑下来,这个系统可被度量地比三个月前更好了。

这条闭环的精神就一句话:把失败转成持久修复,等于分诊、打包成定向评测、根因调查、修复验证、固化成回归,模糊的退回人。它越往自动化的右端走,就越接近 Ch7 的自动闭环;而这一章教的,是这条闭环本身,以及人在其中读轨迹、做判断的那几步。这也是为什么这一章和 Ch7 不重复:同一座桥,Ch7 站在 agent 自动那头,这一章站在工程师手动那头。

综合 · 这一章是诊断科,也是全书的整合复习

回头看这一章,它和别的章不太一样。别的章教你怎么把某件事做对,这一章教你怎么闻出哪里做错了。你拿到了一套规范的失败 taxonomy,五个家族外加一个安全指针,每一族都指回某一章的技术;你学会了两套共享坐标系的 SOP,一套事后诊断一条失败轨迹、一套事前评审一份方案;你看了三个评审 demo 怎么一步步走;你拿到了五个把坐标系装进脑子的模板,尤其是那个练 SOP-A 的尸检模板;最后你看了怎么把一次杂乱的失败转成一个持久的修复。

把这一章放进整条路书,它的位置很讲究。它在 Ch9 之后,因为评测先暴露失败,评审才能把失败转成判断力,这是它的 why-now,也是第四站这两章的咬合点。它又在 Ch11 源码巡礼之前,因为你带着这套失败坐标系去读一个真实系统的源码,才能对号入座地看懂它每一处设计在防哪一族失败。所以这一章本质上是全书的整合复习章,前面九章的技术在这里被按失败重新点了一遍名。这也是为什么它训练的是直觉:你不是在学新东西,你是在把学过的东西从「知道」磨成「闻得到」。

但要诚实地说一句,这一章是诊断科,不是治疗科。它教你识别失败、定位根因、把失败转成修复,可每一种失败具体怎么防,机制都在它对应的那一章。合上书,去做一件事:打开你自己的一个 agent 项目,挑一次它真实出过的错,把完整轨迹翻出来,用这一章那个尸检模板跑一遍,看你能不能定位到第一处偏离、归到一个模块和一个象限、给它一个规范名。能,你的报警器就装上了。带着这套坐标系,进 Ch11,去一个真实的开源 agent 系统里,看顶尖团队是怎么把这些防御一个个焊进代码的。

本章关键术语

下面按本章顺序复习。加粗是术语,后面是一句话解释;带链接的词可点进术语表看更完整的解释。

诊断方法与坐标系

• 失败模式 taxonomy(failure-mode taxonomy) 5 族(工具 / 推理 / 上下文 / 协同 + 安全指针)~19 具名模式,每族带「哪章修」第四栏;不背诵任一份学术 taxonomy,合成一个可诊断视图
• 根因 vs 传播错误(root-cause vs propagated) 下游一串错常源于上游一个根;诊断只修根,别追被它带歪的一长串
• 首处偏离(first divergence) 沿轨迹找最早一步开始偏离正确路径的点(常在第 2 步左右),是定位根因的锚
• 失败轨迹尸检(trajectory postmortem · SOP-A) 6 步诊断:取全 trace → first divergence → 归模块 → 归 Ch9 四象限 → 命名 + 指章 → 修复 + 固化
• 设计前评审(design review · SOP-B) 用三支柱 + #8 章节脊柱 + 失败 taxonomy 扫一份还没跑的方案,先停下做第一印象再对照

功能失败模式

• 目标漂移(goal drift) 无单步失败,每步即时 context 一点点压过原始意图,任务整体跑歪(「修 bug」漂成大重构)
• 失控循环(runaway loop) 停不下来、反复做同一件事烧 token;与过早终止是同源两极
• 过早终止(premature termination) 没干完就宣布完成;根因同失控循环——不会可靠评估任务真做完没
• 错误级联(error cascade) 一步的错(工具报错被当结果)静默污染后续每步,在多 agent 里被放大
• 谄媚 / 社会锚定(sycophancy) 用户一质疑就把正确答案改错;训练级根因归 #6,本章教识别
• 版本漂移(version drift) 模型 / prompt / 工具 schema 升级后行为悄悄变;靠每次变更跑 per-model eval 守护

修复闭环

• 人主导修复闭环(failure-to-fix loop) 分诊 → 打包定向 eval → 根因调查 → 修复验证 → 固化成回归,模糊案例退回人;与 Ch7 的 agent 自动闭环互为两端

防御机制散在各章(Ch2 / 3 / 5 / 6 / 7 / 8 / 9),完整术语见术语表 /glossary。

参考文献

Mode A · 引用出处(正文 inline,集中列在此)

• Why Do Multi-Agent LLM Systems Fail? (MAST)(Cemri 等 · NeurIPS 2025)· 第 1 节 / 第 2 节 —— multi-agent 失败三层骨架 + 14 模式(任务漂移、过早终止、不验证、忽略他 agent 输入等),1600+ 轨迹、标注一致性 κ=0.88
• Where LLM Agents Fail and How They Can Learn From Failures (AgentDebug)· 第 3 节 诊断 SOP 脊柱 —— memory / reflection / planning / action 四模块归因 + 根因 vs 传播错误
• Failure Modes in LLM Systems(Microsoft · 2025-11)· 第 1 节 / 第 2 节 —— 系统级隐藏失败(版本漂移、成本崩溃),「可靠性是系统工程问题不是模型问题」
• How Long Contexts Fail(Drew Breunig · 2025-06)· 第 2 节 族 C —— 上下文失败四型(投毒 / 干扰 / 混淆 / 冲突)+ 宝可梦 Gemini 投毒实例
• How Enhancing LLM Reasoning Amplifies Tool Hallucination(ICLR 2026)· 第 2 节 A1 —— 推理 RL 越强、工具幻觉越高的反直觉发现
• An Update on Recent Claude Code Quality Reports(Anthropic · 2026-04)· 第 2 节 D5 / 第 4 节 demo —— 三个无害改动叠加成版本漂移;检测难、内部 eval 一开始复现不出
• Managed Agents(Anthropic)· 第 3.1 节 —— 可观测性不足等于诊断不可能;内部 agentic 事故日志
• Building Self-Improving Tax Agents with Codex(OpenAI)· 第 6 节 —— 人主导修复闭环工业范本:分诊 → 定向 eval → 根因调查 → 固化

深 dive 资源(可选 · 想往下走再看)

• Characterizing Faults in Agentic AI · 第 1 节 —— 类型 × 症状 × 根因三层关联(13602 个 issue);偏软件 / infra 故障,取其症状到根因的映射方法
• When Agents Disagree With Themselves · 第 3.1 节 —— 不一致常追到特定决策点、路径长度是预测信号

说明:本章纯 Mode A,直觉训练 seed 继承自架构师课失败章(评审三件套、先停下做第一印象、内化论、三个评审 demo、prompt 模板),内容侧按 #8 脊柱大幅 modernize 并把提示注入 re-home 到 Ch5。Replit 事故的具体数字(1200+ 高管、4000 假用户)与 Anthropic 社区审计数(6852 session、234000+ tool call)均为披露 / 社区数据,正式 postmortem 截至披露未发,引用前 pin 原文。学术 taxonomy 的 2026 预印本(微软 15 模式、故障 taxonomy 等)引用具名模式前 pin 原文,勿 fabricate 未核实清单。

下一章

下一章(Ch11)还在第四站,从「认识失败」走到「读真实系统」:真实 Agent 系统源码巡礼。你带着这一章的失败坐标系,去 OpenAI 开源的 Codex 这个真实的 Rust agent 系统里,逐个子系统对号入座:它的循环怎么写、工具和 MCP 怎么接、沙盒怎么隔离、审批怎么把关、compaction 怎么做、状态怎么存。把前十章学的每一个抽象,在一个能跑、能读、能改的真实系统里找到它对应的代码,抽象就有了形、具象就有了名。