实际的大模型 Agent 项目中异常处理很容易被当成普通的 try-catch 来写结果往往是异常是捕获了但捕获之后做什么并没有想清楚。Agent 与普通接口不同它的执行链路更长参与方更多涉及模型调用、工具调用、记忆读写、异步编排等多个环节。任何一个环节异常都可能让整个任务反转、卡死、重复执行或返回错误答案。更麻烦的是Agent 的异常处理往往不是“必须做”的而是“可选做”的。这个“可选性”既是 Agent 框架给开发者的自由度也是线上问题最容易滋生的地方。要注意不要把“可选”理解成“可以不管”。在 Agent 开发中异常处理的可选性通常体现在三个层面语言和框架是否强制你处理异常、任务策略是否允许你选择重试或降级、异常发生后是否把处置权交给 Agent 自己。每个环节都有选择但每个选择都有代价。下面先说明 Agent 异常处理和普通异常处理的差异再梳理异常来源和传播链路然后给出一套判断规则和可配置策略最后用一个执行器超时案例说明排查路径。1. 为什么 Agent 异常处理的关键不是“捕获”而是“决定要不要处理”先做一个对比。普通接口的异常处理目标是明确的外部参数错误返回 4xx内部依赖故障返回 5xx业务状态异常返回业务错误码。链路短输入输出可预期异常处理基本等价于“翻译错误并返回结果”。Agent 则完全不同。Agent 的一次执行通常包含规划、调用模型、执行工具、观察结果、再次规划这样的循环。每一步都可能失败而且失败并不总是终点模型超时后可以重试工具返回错误后可以重新生成参数再次调用整个计划跑偏后可以让 Agent 重新规划。异常处理从“翻译错误”变成了“在多种后续动作中做选择”。1.1 普通接口异常处理和 Agent 异常处理的差异差异主要体现在四个维度整理成表更直观| 维度 | 普通接口异常处理