企业官网建设流程全解析

17 · Agent 出错怎么兜底

面试里我被问过一个概率很高的问题：「你的 Agent 出错了怎么办？」

我后来意识到，这个问题比「你的 Agent 有多聪明」重要得多。

因为让 Agent 跑起来是 demo，让它在出错时不闯祸才是工程。而后者恰恰是没有真实业务经验的人最难答好的——你没见过它坏，就编不出它坏的样子。

第四周我把自己项目里所有已知的失败模式整理了一遍，一共 12 类，分四层。这篇挑几个最有讲头的写。

一、先说分层

┌── 模型层 ── 循环不收敛 / 工具选错 / 参数幻觉 / 格式不可信 / 上下文爆炸 ├─ 工具层 ── 越权动作 / 重复副作用 / 提示注入 ├─ 系统层 ── 成本失控 / 上游故障 / 确认超时 └── 元 层 ── 观测自身失效（尺子自己坏了）

前三层大家都能想到。第四层是我踩过坑之后才加的，也是我觉得最能体现经验的一层，放在最后细说。

二、模型层：熔断的目标不是「有个答案」

Agent 最容易出的状况是停不下来——反复调同一个工具，参数每次微调，永远不给最终答案。

兜底是步数硬上限（默认 6 步）。但这里有个取舍我想了很久：

到上限时，返回空答案，还是让模型「总结一个」？

我选了空答案。代码里是ok=False+ 空字符串，绝不编。

理由：熔断的目标是**「不烧钱 + 不骗人」**，不是「一定要有个答案」。让模型在没搞清楚的情况下硬编一个，比空手而归糟糕得多——用户分不清哪个是真的。

同理，连续 2 次解析不出格式就熔断（设 2 而不是 1，是给模型一次「照着格式重来」的机会；设 3 太浪费，改不对的格式改三次也改不对）。

三、工具层：一个很多人会搞混的护栏 bug

写操作（建工单、发通知）必须有人工确认。这块我踩过一个认知坑，值得单独说：

流程层批准 ≠ 动作层批准。

什么意思？我的图（LangGraph）里有个approve节点，流程走到这里代表「这条链路被批准了」。但这不代表具体的这个动作被批准。

这两个是两套令牌。如果混用一个，就会出现：人批准了 A 动作，结果 B 动作也被放行了——因为「流程已经批准过」。

这是护栏里最危险的一类 bug，因为它看起来是work的：控制台显示「已确认」，日志里也有记录，只有副作用是错的。

我的处理：写工具必须带request_id令牌，流程层的graph.approve和动作层的confirmed集合完全独立，各查各的。

另外两个：

• 重复副作用：重试导致建了两张工单。兜底是request_id幂等，而且做双层——闸门里预拦截一次，真正落盘时再查一次。单层的幂等会在并发下漏。
• 确认超时：默认 120 秒没人点，fail-closed，按拒绝处理。绝不「等不到就默认批准」。

四、系统层：成本闸门必须放在代码里

Agent 是循环调用，一次任务几十次调用很正常，烧钱是指数级的。

我做的事很简单：每次调用落到.cost_ledger.jsonl，累计到阈值（默认 ¥20）直接抛异常中止。

关键是闸门在代码里，不在脑子里。脑子里的闸门在凌晨两点会失效——我失业在家做这个，一次跑飞的全量评测就能吃掉一天预算，没有公司账单兜底。

五、元层：观测自己会坏（我最想讲的一层）

第四周末尾我给 Agent 接了可观测，把事件流翻成 span 树画瀑布图。跑起来一看：

step 1: 651ms step 2: 640ms step 3: 620ms step 4: 590ms ───────────────── 合计: 244%

四步加起来 244%。我第一反应是「系统变慢了」，开始查模型调用、查检索。

查了半天，发现系统没变慢，是我的尺子坏了。

原因：我的 ReAct 事件词汇里有step_start，没有step_end。没有结束信号，每一步就只能靠下一个step_start推断结束；最后一步更是要等到根 span 兜底关闭才结束。于是每一步的耗时都变成了「从它开始到全程结束」。

观测层的 bug 和被测系统的 bug，在数字上长得一模一样。

这跟第三周评测端的事（第 15 篇）是同一个教训换了个地方出现：你不先确认尺子是对的，就会拿着坏数据去优化一个本来没问题的系统——而且越优化越自信，因为「数字在变好」。

修完之后我干了三件事：

1. 下一个step_start/final/stop到来时关闭上一步；
2. 加一条测试专门钉死这个行为——这类 bug 特别容易在改事件词汇时复发；
3. 把「观测自身失效」单独列成一类失败模式，写进兜底文档。

还有一条设计原则值得说：接 trace 时，我Agent 代码一行没改，只在端点挂了个钩子。

这不是运气好。是我从第一周就埋了on_event回调（本来是给 SSE 用的），第四周只是加了个「消费者」。

可观测必须是主循环的副产品，不是事后插桩。
如果接观测需要改 Agent 逻辑，说明钩子当初就没埋对。

六、面试怎么答这个问题

不要背那张 12 类的表——背出来像背书。

我的建议是：分层说，然后举一个你亲手踩过的坑。

「我分成模型层、工具层、系统层，还有观测层自身四类。
最有意思的是第四类：观测层自己会坏。
我实际踩过一次——ReAct 的事件词汇里有step_start没有step_end，
结果每一步耗时都算成了『从它开始到全程结束』，四步加起来 244%。
我第一反应是系统变慢了，查了半天发现是尺子坏了。
修完我加了条测试专门钉死它。」

这段话同时证明了三件事：你会分类、你踩过真坑、你知道要防回归。

比「我用 try-except 兜底」强一百倍。

上一篇：16 · 我把成本拆成三项之后，发现 judge 占了 91%
下一篇：18 · 四道闸门：怎么让 Agent 别乱来