1. 当Agent开始自作主张问题才真正开始做过AI Agent落地的朋友大概都有这种体会Demo阶段一切丝滑一旦接入真实业务各种离谱的失败模式就冒出来了。它可能调用了一个参数错误的工具可能把用户随口说的一句话当成了必须执行的指令也可能在连续多步推理中悄悄跑偏最后交出一个看起来像模像样、实际上完全错误的结果。更麻烦的是有些操作一旦执行就产生了副作用——发了邮件、改了数据库、提交了订单、删了文件——这时候你才发现Agent的手比它的脑子快太多了。这篇内容想聊的就是这个绕不开的话题AI Agent执行出错之后我们到底该怎么办。核心思路可以概括成四个动作——校验、暂停、回滚、人工接管。这四个词听起来简单但每一个背后都有一堆工程细节和踩坑经验。我会从Agent的组成结构讲起把校验规则怎么设计、暂停机制怎么触发、回滚方案怎么落地、人工接管怎么做得不别扭一层层拆开来说。不管你是刚开始搭第一个Agent练手小项目还是已经在做企业级的Agent应用开发这些内容应该都能对上号。需要先说明一点Agent和LLM不是一回事。LLM大语言模型是那个会说话的大脑比如大家常问的DeepSeek属于哪一类——它就是一个LLM负责理解和生成。而Agent是在LLM基础上加了规划、记忆、工具调用、执行循环的一整套系统。正因为Agent多了执行这个环节它才会出错也才需要校验、暂停、回滚和接管。纯聊天机器人说错话你忽略就行Agent做错事可能真的要收拾残局。2. 先搞清楚Agent为什么会闯祸2.1 Agent的组成结构决定了它的脆弱点一个典型的Agent大致由这么几块拼起来LLM推理核心、任务规划模块、记忆短期上下文长期存储、工具/函数调用层、执行循环控制器。这个结构里每一块都可能是故障源。LLM推理核心的问题在于它是概率性的。同样的输入温度参数稍微高一点输出就可能不一样。它没有确定性这个概念所以你不能指望它每次都给出完全一致的结果。任务规划模块的问题在于它会把一个大目标拆成若干子步骤但拆解逻辑本身依赖LLM一旦某一步拆错了后面全盘皆输。工具调用层是最危险的因为这是Agent真正动手的地方——参数传错、调用了不该调用的工具、在错误的时机调用都会造成实际影响。记忆模块也有坑。短期上下文太长会稀释关键信息长期记忆检索不准会把无关的旧信息拉进来干扰判断。执行循环控制器如果缺少步数限制或终止条件Agent可能陷入死循环反复调用同一个工具。理解这些脆弱点是设计校验和回滚方案的前提。你得先知道它会在哪里出错才能在那里设卡。2.2 常见的失败模式分类我把实际遇到的Agent失败大致分成几类方便对症下药失败类型典型表现危险等级参数错误工具调用时传了错误的参数值或格式中工具误选该查数据库却去发了邮件高指令误解把用户的假设性提问当成执行命令高推理跑偏多步推理中逐渐偏离原始目标中循环失控反复调用同一工具无法终止中副作用不可逆已发送、已删除、已支付极高危险等级最高的那类就是产生了不可逆副作用的操作。这也是为什么回滚在Agent系统里是个硬需求——不是所有操作都能撤销但你必须为能撤销的操作准备好撤销路径为不能撤销的操作准备好事前拦截。2.3 为什么事后补救往往来不及很多人第一反应是出错了再修不就行了问题在于Agent的执行速度。一个配置好的Agent几秒钟内可能连续调用十几个工具。等你发现不对劲副作用早就产生了。而且Agent的失败往往是静默的——它不会报错它会自信满满地给你一个错误结果。这种静默失败比崩溃更难发现。所以正确的思路是把控制点前移在工具真正执行之前校验在连续执行之间暂停确认在发现异常时立即中断并回滚。这就是接下来要展开的四个动作。3. 校验在Agent动手之前设好关卡3.1 校验应该发生在哪几个层次校验不是单一动作而是一个分层的体系。我在实践中通常把它分成三层第一层是输入校验。用户给Agent的指令进来时先做一轮规则校验。比如用户说帮我删掉所有超过30天的日志你得先判断这个指令是否在Agent的权限范围内是否包含危险操作关键词参数是否完整。这一层可以用传统的rules校验规则来做也可以用一个小模型做意图分类。第二层是工具调用前的参数校验。Agent决定调用某个工具时在真正执行前拦截下来检查参数。这一步非常关键因为大部分参数错误都在这里能拦住。比如调用发送邮件的工具收件人地址格式对不对、主题是否为空、是否在允许发送的白名单域名内。第三层是结果校验。工具执行返回后检查返回结果是否符合预期。比如查询数据库返回了空结果Agent却当成查询成功继续往下走这就是结果校验缺失。三层校验叠起来能拦掉大部分低级错误。但要注意校验规则不能太死否则Agent的正常灵活性会被扼杀。这个度需要根据业务场景调。3.2 规则校验与语义校验的取舍规则校验rules校验规则的好处是确定性强、速度快、可解释。比如金额字段必须是数字且不超过10000这种用规则校验最合适。但规则校验覆盖不了语义层面的问题。用户说把那个东西处理一下那个东西指什么规则校验无能为力。这时候就需要语义校验。常见做法是让LLM自己当裁判——把Agent的决策和上下文一起丢给一个校验用的LLM问它这个操作是否合理。这种做法灵活但引入了新的不确定性校验LLM也可能判断错。所以我的经验是能用规则校验的地方坚决用规则规则覆盖不了的再用语义校验兜底而且语义校验的结果最好只作为警告而非阻断除非置信度极高。还有一种折中方案是结构化输出校验。要求Agent在调用工具前先输出一个结构化的执行计划包含工具名、参数、预期结果。这个计划本身可以被规则校验也可以被人快速扫一眼。这比直接执行要安全得多。3.3 校验失败之后Agent该怎么反应校验失败不是简单抛个异常就完事。Agent需要知道失败了接下来怎么办。这里有几种处理策略重试如果是参数格式问题可以让Agent根据错误信息修正后重试但要限制重试次数比如最多2次。降级换一个更安全的工具或更保守的参数重新尝试。上报把问题抛给人工接管流程。终止直接停止整个任务返回失败原因。选择哪种策略取决于失败的性质和业务容忍度。我的建议是给每类校验失败预设好处理策略而不是让Agent自己临场决定——临场决定往往就是它再次犯错的时候。提示校验规则本身也需要版本管理。业务规则变了校验规则要跟着更新否则会出现Agent被旧规则卡死的尴尬。4. 暂停给Agent装一个刹车4.1 暂停的触发条件设计暂停机制的核心是什么时候该停下来。我一般设置这几类触发条件步数阈值。Agent执行超过N步比如15步还没完成强制暂停。这能有效防止死循环。N的取值要看任务复杂度简单任务5步复杂任务可以到20步。高风险操作前置暂停。当Agent即将执行标记为高风险的工具时比如删除、支付、发送对外消息先暂停等待确认。这个确认可以是人工的也可以是一个额外的校验流程。置信度低时暂停。如果Agent对自己的决策置信度低于阈值暂停。不过置信度这个东西LLM给得不太靠谱实践中更多是用多次采样一致性来判断——让Agent对同一个决策采样几次如果结果分歧大就暂停。异常信号暂停。比如工具返回了错误码、返回结果为空、执行时间异常长这些都可以触发暂停。4.2 暂停状态怎么保存和恢复暂停不是简单地把程序挂起。Agent的状态需要被完整保存下来包括当前执行到哪一步、上下文是什么、已经产生了哪些副作用、待确认的操作是什么。这样恢复时才能接着往下走。实现上我倾向于把Agent的每一步执行都持久化成一个检查点checkpoint。暂停时当前检查点就是恢复点。这跟游戏存档是一个道理。检查点里要记录足够的信息让Agent恢复后能重建上下文。这里有个容易忽略的点暂停期间外部状态可能变化。比如Agent暂停时数据库里的数据被别的进程改了恢复后Agent基于旧上下文继续执行就可能出错。所以恢复时最好重新校验一遍关键状态而不是盲目接着跑。4.3 暂停不等于卡死超时与兜底暂停机制最怕的就是暂停了但没人管。Agent停在那里任务永远不完成资源一直占着。所以暂停必须配超时。超过一定时间没人确认就自动走兜底流程——要么终止任务并回滚要么降级执行一个安全版本。我在实际项目里会给暂停设置两级超时第一级超时比如5分钟发提醒第二级超时比如30分钟自动终止。这样既给了人工介入的窗口又不会无限期挂着。5. 回滚把Agent造成的副作用收回来5.1 哪些操作可以回滚哪些不能回滚的前提是操作可逆。这里必须清醒不是所有操作都能回滚。可以回滚的数据库事务内的修改、文件系统的变更如果有备份或版本控制、配置的更改、临时资源的创建。难以回滚的已发送的邮件、已推送的通知、已提交的对外API请求、已支付的交易。对于难以回滚的操作策略不是想办法回滚而是事前拦截——把它标记为高风险执行前必须暂停确认。这就是为什么暂停和回滚要配合使用。5.2 基于检查点的回滚实现对于可回滚的操作我通常用检查点机制来实现。每个检查点记录操作前的状态快照回滚时按检查点逆序恢复。这跟git代码回滚的思路类似——你有一个操作历史可以回退到任意一个历史点。具体实现上如果操作涉及数据库用事务是最干净的。把Agent的一系列操作包在一个事务里出错就整体回滚。但Agent的执行往往是跨系统的一个事务包不住这时候就需要自己维护补偿逻辑。补偿逻辑的意思是为每个操作定义一个逆操作。创建了资源就删除它修改了值就改回去发送了消息就发一条更正消息。补偿逻辑写起来麻烦但对于关键业务是必须的。5.3 回滚不干净怎么办几个真实教训回滚不干净是常态不是例外。我踩过的坑包括部分回滚。Agent执行了5步回滚时只成功了3步剩下2步因为外部依赖变化回不去了。这时候系统处于一个半吊子状态比不回滚还麻烦。应对办法是回滚也要有重试和告警回滚失败必须让人知道。回滚顺序错误。操作之间有依赖关系回滚时必须逆序。如果先回滚了被依赖的操作再回滚依赖它的操作就会失败。所以检查点要记录依赖关系。外部系统不支持回滚。你调了别人的API人家没有撤销接口你只能发一个反向请求去抵消但反向请求本身也可能失败。这种就只能靠事前拦截了。注意回滚逻辑本身也需要测试。很多人只测正常流程不测回滚流程结果真出事时回滚代码是坏的。回滚路径要和主路径一样认真对待。6. 人工接管什么时候该让人来接手6.1 接管的触发时机与交接内容人工接管不是Agent不行了换人上这么简单。关键是交接要顺畅——人接手时得知道Agent做了什么、做到哪了、为什么停、当前状态是什么。如果人接手后还要从头查一遍那接管的价值就大打折扣。所以接管触发时系统应该自动生成一份交接报告包含任务目标、已执行步骤、每步的结果、当前暂停原因、待决策事项、可选的后续方案。这份报告质量直接决定接管效率。触发时机上我一般设这几种高风险操作待确认、校验连续失败、Agent主动请求帮助、超时未完成、检测到异常模式。其中Agent主动请求帮助这一条很有意思——可以在提示词里告诉Agent遇到不确定的情况可以主动停下来求助而不是硬着头皮猜。6.2 接管界面的设计要点接管界面最忌讳信息过载。人需要的是我现在要做什么决定而不是一堆原始日志。好的接管界面应该把待决策事项放在最显眼的位置把支撑决策的信息放在旁边把原始日志折叠起来备用。另外接管界面要支持部分接管——人不一定要接手整个任务可以只处理当前这个卡住的决定然后让Agent继续。这样人的负担小Agent的自动化价值也保留得多。6.3 接管之后如何让Agent继续或安全退出人做完决定后有两条路让Agent带着人的决策继续执行或者终止任务。继续执行时要把人的决策作为新的上下文注入让Agent知道这一步已经定了别改。终止时要走回滚流程把已产生的副作用清理掉。这里有个细节人接管后做的决定最好记录下来作为后续优化校验规则和提示词的素材。哪些地方Agent老是搞不定需要人介入哪些就是改进的重点。7. 把四个动作串成一套可落地的防护体系7.1 一个完整的执行流程示例把校验、暂停、回滚、接管串起来一个完整的Agent执行流程大概是这样接收用户指令做输入校验判断是否在权限范围内。Agent规划任务生成执行计划。对计划做结构化校验检查工具选择和参数。逐步执行每步执行前做参数校验。遇到高风险操作暂停等待确认。每步执行后做结果校验异常则触发处理策略。执行过程中持续保存检查点。全部完成则提交中途失败则从检查点回滚。无法自动处理的情况生成交接报告转人工接管。人工处理后决定继续或终止。这套流程听起来步骤多但很多步骤是自动的实际增加的延迟有限。关键是它把出错从一个灾难性事件变成了一个可管理的常规分支。7.2 不同复杂度Agent的防护取舍不是所有Agent都需要全套防护。一个只读查询的Agent不需要回滚校验也可以轻量。一个内部工具型Agent暂停和接管可以简化。只有涉及写操作、对外操作、资金操作的Agent才需要完整的四件套。我的建议是按风险分级低风险Agent只做基础校验中风险加暂停和检查点高风险全套上而且高风险操作的确认必须是人工的不能自动放行。别为了省事把高风险Agent的防护砍掉出事的时候代价远大于省下的开发成本。7.3 监控与持续改进防护体系上线不是终点。你需要监控几个关键指标校验拦截率、暂停触发频率、回滚成功率、人工接管率。这些指标能告诉你防护体系哪里太松、哪里太紧。拦截率太低说明校验形同虚设太高说明规则太严误伤正常操作。接管率持续偏高说明Agent在某些场景能力不足需要优化提示词或补充工具。这些数据是迭代的依据。我在实际项目里的体会是Agent的可靠性不是靠单点技术堆出来的而是靠这一整套校验-暂停-回滚-接管的工程体系兜住的。LLM本身的能力会波动但工程防护是确定的。把确定性做厚把不确定性管住Agent才敢真正放到生产环境里跑。最后分享一个小技巧初期可以把所有高风险操作都设成必须人工确认跑一段时间收集数据后再把那些从未出错的场景逐步放开自动执行——用真实数据驱动防护策略的松紧比拍脑袋定规则靠谱得多。
