Agent开发中多工具调用频繁出错，大家是怎么做容错和回退的？

这问题太真实了，我最近也被搞到头疼。光靠prompt说“别猜”基本没用，模型该幻觉还是幻觉，尤其是遇到超时这种模糊错误，它甚至会自己脑补一个“合理”的返回值。我现在的做法是在代码层面把工具调用包一层，强制校验返回结构，只要格式不对或者缺关键字段就直接抛异常，根本不给模型“编”的机会。

关于retry，我建议别做无脑重试，特别是限流场景，越重试越糟糕。我现在是给每个工具配一个“错误类型→策略”的映射表，比如网络超时重试两次加指数退避，限流就直接等固定时间，而那些业务逻辑错误（比如API返回了“没找到”），我压根不重试，而是把错误信息当成一个“伪工具结果”返回给模型，让它基于这个结果重新规划下一步，而不是重新调用。

至于多工具连续调用失败的状态管理，我之前也掉过坑。后来学乖了，引入一个简单的状态机，每个工具执行前先记录当前状态，执行后无论成功失败都更新状态快照。如果中间某步挂了，就回滚到最近一个成功状态，再让模型基于这个快照重新决策，而不是让它从头开始。还有个关键点，所有工具调用的日志要保留完整上下文，这样排查的时候才能看清是模型决策错还是工具本身的问题。你可以试试，比纯靠prompt稳定多了。

代码层做强制校验，工具返回不符合schema就直接抛异常，别给模型编造的机会。

状态管理用个轻量级状态机，每步记录快照，失败就回滚到最近成功节点重跑。

这问题太真实了，光靠prompt真拦不住模型硬编。我现在的做法是在代码层把所有工具返回值包一层schema，异常直接抛给上层，模型只能拿到成功的数据结构，拿不到原始错误信息，从根上杜绝它乱编。retry的话，对超时和限流分开处理，限流就指数退避，超时最多两次。至于多工具串联，我习惯用状态机或者简单的workflow引擎，每一步结果存context里，失败就中止整个链路，等用户手动触发重试，别让模型自己瞎补救。

代码层面必须做硬校验，别指望prompt能根治，模型在上下文压力下就是会瞎编。我一般把工具返回结果包一层schema校验，字段对不上直接抛异常给模型重试，超过两次就标记成失败状态。

至于多工具连续调用，我是维护一个执行栈，每步结果带个状态标记，哪步挂了就回滚到最近的有效节点，用快照重放后面的逻辑，比让模型自己决定回退路径靠谱多了。

代码层做强制校验吧，返回格式不对就直接重试，别指望prompt能管住模型嘴硬。状态机管理多步调用，哪步挂了就回滚到上一个稳定节点。

代码层必须兜底，别指望prompt能根治，我一般会给每个工具封装一层带超时和状态码校验的调用器，遇到异常直接抛自定义错误，让模型只能拿到“工具结果”或“明确失败”两种输入，从源头掐掉编造空间。

至于多工具连续失败，我习惯用一个轻量的状态机或简单的事件总线来记录每步的输入输出和错误类型，回退策略就按依赖关系分两种：要么整体重试最近一次成功的快照，要么做降级——比如搜索挂了就换本地缓存或直接调备用API。

另外你提到的二次生成，我觉得别把原始错误堆给模型，最好先格式化成一个“下一步可操作”的提示，比如告诉它“搜索失败，建议改用计算器验证”，这样比单纯说“别猜”靠谱得多。

代码层做硬校验吧，prompt那套真不太靠谱。我一般是给每个工具返回值加个schema，模型输出直接过json校验，不合法就强制走异常分支，宁可直接报错也不让它瞎编。多工具连续调用的话，我会维护一个简单的状态机，每步执行前记录当前上下文，失败就回滚到最近一个成功节点重试，而不是从头再来。

代码层做好重试和降级吧，prompt只能兜底，别指望它稳定。工具状态机管住，失败就跳分支，别让模型硬编。

代码层面得兜底，别全指望prompt，我一般会给每个工具包一层带超时和异常捕获的函数，返回统一的结构体，里面带上状态码和错误详情，模型拿到这个结构体再决定是重试还是换路径。关于连续调用失败，可以维护一个工具调用链的栈，哪一步挂了就根据依赖关系回滚到最近的可用状态，同时把错误摘要拼到下一次请求里，让模型知道别走老路。另外retry策略建议用指数退避加随机抖动，不然限流的时候容易雪上加霜。

代码层做强制校验吧，prompt真靠不住，返回值不符合schema就直接抛异常重试。
多工具串联建议搞个状态机，每步落盘，失败就从最近的成功节点恢复。

这个太有同感了，模型瞎编结果那块简直是必经之痛。我后来基本放弃纯靠prompt约束，直接代码层硬校验，比如给每个工具定义一个返回值schema，解析失败或状态码不对就自动抛异常，然后走独立的retry队列，重试次数和退避时间写死在配置里。多工具链路的话，我习惯每个步骤打点记录输入输出快照，一旦某步失败就根据依赖树回滚到最近的安全状态，而不是让Agent自由发挥续跑，状态管理用个简单的状态机反而比让模型自己记靠谱。

代码层必须做硬校验，别指望prompt能兜底。我一般会给每个工具返回包一层schema校验，非预期结构直接抛异常，模型拿到的就是明确错误标记，这样它想编都编不了。

retry策略我会区分错误类型，限流就指数退避，超时最多重试两次，再不行就降级到缓存或者让模型用另一个工具替代。关键是设定一个“工具调用结果可信度”阈值，低于阈值宁可中断流程也别让它硬往下走。

多工具连续调用这块，我目前是维护一个轻量级状态机记录每步的工具名、入参、出参和结果状态，失败时能按预设的备选路径跳转，而不是让模型自由发挥。你可以试试把状态机决策逻辑外置到代码里，模型只负责生成候选动作，这样可控性会高很多。

这个坑我太懂了，模型在工具报错时“强行圆场”几乎是通病，光靠prompt真压不住，它宁可编个合理结果也不愿承认自己调用失败。我现在的做法是放弃让模型感知错误，直接在代码层给每个工具包一层强制校验，比如搜索必须返回结构化字段，超时或限流就抛特定异常，这样模型根本拿不到“可以编造”的原始错误文本。至于retry，我建议别无脑重试三次，根据错误类型区分，网络抖动可以退避重试，但限流或参数错误直接短路，让模型换一条工具路径或者问用户要澄清信息，反而更稳定。多工具连续调用这块，我目前是把整个流程拆成有向图，每步执行前先存快照，失败就回滚到最近一个成功节点，再让模型基于那个状态重新规划后续动作，不会从头再来。另外你提到把错误塞回给模型二次生成，我试过效果飘，后来改成只给模型“哪个工具失败+失败原因+当前已有数据”，不把原始堆栈给它，它就不容易乱发挥。还有个偏门技巧，如果某个工具频繁失败，可以临时把该工具的权重调低，引导模型优先用其他工具，或者干脆在工具描述里加上“此接口不稳定，若失败请明确告知用户”这类说明，实测比“不要猜测”管用。不知道你那边多个工具之间的参数依赖是怎么处理的？是让模型一次性生成所有参数，还是分步执行拿到结果再生成下一步？前者出错时状态特别难回退。