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，我建议别无脑重试三次，根据错误类型区分，网络抖动可以退避重试，但限流或参数错误直接短路，让模型换一条工具路径或者问用户要澄清信息，反而更稳定。多工具连续调用这块，我目前是把整个流程拆成有向图，每步执行前先存快照，失败就回滚到最近一个成功节点，再让模型基于那个状态重新规划后续动作，不会从头再来。另外你提到把错误塞回给模型二次生成，我试过效果飘，后来改成只给模型“哪个工具失败+失败原因+当前已有数据”，不把原始堆栈给它，它就不容易乱发挥。还有个偏门技巧，如果某个工具频繁失败，可以临时把该工具的权重调低，引导模型优先用其他工具，或者干脆在工具描述里加上“此接口不稳定，若失败请明确告知用户”这类说明，实测比“不要猜测”管用。不知道你那边多个工具之间的参数依赖是怎么处理的？是让模型一次性生成所有参数，还是分步执行拿到结果再生成下一步？前者出错时状态特别难回退。

工具层加个schema校验和重试，模型编结果就拦下来重调，别让它自己圆。

我一般直接在代码层拦异常，出错就重试或返回兜底，别全指望prompt。连续调用建议每步存状态，失败就从当前节点回退。

这个问题我踩过类似的坑，说点实际感受。光靠prompt真的很难彻底解决，模型在工具报错时“顺手编一个”几乎算是它的本能反应，因为它的训练目标就是给出看起来合理的回答，而不是老实说“我失败了”。我的做法是在代码层强制拦截，工具调用返回的结果必须经过一个校验层，凡是异常就直接标记成硬失败，根本不给模型看到原始错误的机会，而是用固定的模板告诉它“该工具当前不可用”，这样它编造的空间会小很多。

另外retry要分错误类型，超时和限流可以退避重试，但参数错误这种重试多少次都没用，反而浪费token。多工具串联的话，我建议把每一步的中间结果显式存到一个状态对象里，失败时从最近一个成功节点回退，而不是让模型自己记住上下文。还有个思路是给每个工具加一个降级版本，比如搜索失败就退回用缓存或者直接告诉用户稍后再试，别让模型自由发挥。二次生成那个办法我也试过，确实不稳定，因为模型会把错误信息当成一种“提示”去圆场。

这个坑我也踩过，光靠prompt确实不靠谱，模型天生就爱“圆谎”。我的做法是在工具调用层加个硬校验：返回结果如果是异常状态码或者空值，直接拦截，不让它进下一轮上下文，然后走代码层的retry或者降级逻辑，比如搜索失败就返回缓存结果或者明确告诉模型“这个工具暂时不可用”。多步调用的话，我习惯把每步的状态存成一个结构化对象，失败时根据当前步骤决定是重试、跳过还是整体回滚，别让模型自己去“脑补”中间结果。

这个问题其实挺典型的，我自己的经验是光靠prompt基本兜不住，模型天生就有“补全”的倾向，你越强调不要猜它反而可能理解成另一种指令。我的做法是在工具调用层加一层硬校验，比如搜索结果为空或者API返回非200，就直接拦截，不让这个结果进到模型上下文里，而是走代码层的retry或者降级逻辑。比如搜索超时就重试两次，还不行就返回一个结构化的错误对象，让模型基于“已知失败”去决定下一步，而不是给它留编造的空间。多工具连续调用的话，状态管理确实麻烦，我一般会给每个step打上状态标记，失败的那一步要么整体回滚到上一个checkpoint，要么走预设的fallback工具链，别让模型自由发挥去“跳过”失败步骤。另外可以试试把工具返回统一包装成带status字段的JSON，模型看到明确的success/fail比看到一堆自然语言错误提示要老实得多。还有个小技巧是在工具描述里写清楚“如果调用失败必须原样返回错误码”，配合few-shot示例，比单纯在system里喊口号管用。