17 · Agent 出错怎么兜底面试里我被问过一个概率很高的问题「你的 Agent 出错了怎么办」我后来意识到这个问题比「你的 Agent 有多聪明」重要得多。因为让 Agent 跑起来是 demo让它在出错时不闯祸才是工程。而后者恰恰是没有真实业务经验的人最难答好的——你没见过它坏就编不出它坏的样子。第四周我把自己项目里所有已知的失败模式整理了一遍一共 12 类分四层。这篇挑几个最有讲头的写。一、先说分层┌── 模型层 ── 循环不收敛 / 工具选错 / 参数幻觉 / 格式不可信 / 上下文爆炸 ├─ 工具层 ── 越权动作 / 重复副作用 / 提示注入 ├─ 系统层 ── 成本失控 / 上游故障 / 确认超时 └── 元 层 ── 观测自身失效尺子自己坏了前三层大家都能想到。第四层是我踩过坑之后才加的也是我觉得最能体现经验的一层放在最后细说。二、模型层熔断的目标不是「有个答案」Agent 最容易出的状况是停不下来——反复调同一个工具参数每次微调永远不给最终答案。兜底是步数硬上限默认 6 步。但这里有个取舍我想了很久到上限时返回空答案还是让模型「总结一个」我选了空答案。代码里是okFalse 空字符串绝不编。理由熔断的目标是**「不烧钱 不骗人」**不是「一定要有个答案」。让模型在没搞清楚的情况下硬编一个比空手而归糟糕得多——用户分不清哪个是真的。同理连续 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 篇是同一个教训换了个地方出现你不先确认尺子是对的就会拿着坏数据去优化一个本来没问题的系统——而且越优化越自信因为「数字在变好」。修完之后我干了三件事下一个step_start/final/stop到来时关闭上一步加一条测试专门钉死这个行为——这类 bug 特别容易在改事件词汇时复发把「观测自身失效」单独列成一类失败模式写进兜底文档。还有一条设计原则值得说接 trace 时我Agent 代码一行没改只在端点挂了个钩子。这不是运气好。是我从第一周就埋了on_event回调本来是给 SSE 用的第四周只是加了个「消费者」。可观测必须是主循环的副产品不是事后插桩。如果接观测需要改 Agent 逻辑说明钩子当初就没埋对。六、面试怎么答这个问题不要背那张 12 类的表——背出来像背书。我的建议是分层说然后举一个你亲手踩过的坑。「我分成模型层、工具层、系统层还有观测层自身四类。最有意思的是第四类观测层自己会坏。我实际踩过一次——ReAct 的事件词汇里有step_start没有step_end结果每一步耗时都算成了『从它开始到全程结束』四步加起来 244%。我第一反应是系统变慢了查了半天发现是尺子坏了。修完我加了条测试专门钉死它。」这段话同时证明了三件事你会分类、你踩过真坑、你知道要防回归。比「我用 try-except 兜底」强一百倍。上一篇16 · 我把成本拆成三项之后发现 judge 占了 91%下一篇18 · 四道闸门怎么让 Agent 别乱来 17_Agent出错怎么兜底
17 · Agent 出错怎么兜底面试里我被问过一个概率很高的问题「你的 Agent 出错了怎么办」我后来意识到这个问题比「你的 Agent 有多聪明」重要得多。因为让 Agent 跑起来是 demo让它在出错时不闯祸才是工程。而后者恰恰是没有真实业务经验的人最难答好的——你没见过它坏就编不出它坏的样子。第四周我把自己项目里所有已知的失败模式整理了一遍一共 12 类分四层。这篇挑几个最有讲头的写。一、先说分层┌── 模型层 ── 循环不收敛 / 工具选错 / 参数幻觉 / 格式不可信 / 上下文爆炸 ├─ 工具层 ── 越权动作 / 重复副作用 / 提示注入 ├─ 系统层 ── 成本失控 / 上游故障 / 确认超时 └── 元 层 ── 观测自身失效尺子自己坏了前三层大家都能想到。第四层是我踩过坑之后才加的也是我觉得最能体现经验的一层放在最后细说。二、模型层熔断的目标不是「有个答案」Agent 最容易出的状况是停不下来——反复调同一个工具参数每次微调永远不给最终答案。兜底是步数硬上限默认 6 步。但这里有个取舍我想了很久到上限时返回空答案还是让模型「总结一个」我选了空答案。代码里是okFalse 空字符串绝不编。理由熔断的目标是**「不烧钱 不骗人」**不是「一定要有个答案」。让模型在没搞清楚的情况下硬编一个比空手而归糟糕得多——用户分不清哪个是真的。同理连续 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 篇是同一个教训换了个地方出现你不先确认尺子是对的就会拿着坏数据去优化一个本来没问题的系统——而且越优化越自信因为「数字在变好」。修完之后我干了三件事下一个step_start/final/stop到来时关闭上一步加一条测试专门钉死这个行为——这类 bug 特别容易在改事件词汇时复发把「观测自身失效」单独列成一类失败模式写进兜底文档。还有一条设计原则值得说接 trace 时我Agent 代码一行没改只在端点挂了个钩子。这不是运气好。是我从第一周就埋了on_event回调本来是给 SSE 用的第四周只是加了个「消费者」。可观测必须是主循环的副产品不是事后插桩。如果接观测需要改 Agent 逻辑说明钩子当初就没埋对。六、面试怎么答这个问题不要背那张 12 类的表——背出来像背书。我的建议是分层说然后举一个你亲手踩过的坑。「我分成模型层、工具层、系统层还有观测层自身四类。最有意思的是第四类观测层自己会坏。我实际踩过一次——ReAct 的事件词汇里有step_start没有step_end结果每一步耗时都算成了『从它开始到全程结束』四步加起来 244%。我第一反应是系统变慢了查了半天发现是尺子坏了。修完我加了条测试专门钉死它。」这段话同时证明了三件事你会分类、你踩过真坑、你知道要防回归。比「我用 try-except 兜底」强一百倍。上一篇16 · 我把成本拆成三项之后发现 judge 占了 91%下一篇18 · 四道闸门怎么让 Agent 别乱来 
