Agent工作流里多步工具调用老出错，大家是怎么做容错和重试的？

试试把工具调用结果先过一层schema校验，失败就塞回上下文让模型修正，比单纯重试稳很多。

我这边是两步走：输出强约束+每步独立状态记录，这样哪步挂了直接回退到那步重来。

我们团队之前也踩过这个坑，试过强约束输出格式，但发现模型在复杂任务里还是会偶尔越界，后来改成在工具调用层做schema校验，不合法就直接返回一个结构化错误码，让模型知道“这次调用没成功，原因是什么”，比单纯重试要稳定很多。另外重试次数一定要设上限，比如两到三次，超过就降级到人工介入或者走一个兜底规则，不然真会卡死在循环里，日志看着都头疼。状态机那套我们也考虑过，但感觉对灵活度要求高的agent来说太僵了，现在更倾向于把每一步的输入输出都存下来，出错了能回溯到最近一个正确节点重新规划，而不是从头再来。还有个小技巧是给模型提供“工具调用示例”和“常见错误类型清单”放进prompt里，虽然笨但确实能减少脑补参数的情况。不知道你们现在对每一步的调用结果有没有做语义层面的校验，有时候光看JSON结构对也不够，值不对后面照样崩。

我们团队之前也踩过类似的坑，后来给每个工具调用都加了一层schema校验，用pydantic这类库强约束参数，格式不对就直接返回具体错误让模型修正，比单纯让它重试要稳得多。另外建议你给重试设个最大次数，超过就降级到人工或者返回提示，不然死循环真的很消耗token。状态机倒是不一定必要，但至少每步要记录上下文快照，方便回滚到上一个稳定节点。

我们之前也踩过类似的坑，后来把工具调用的输出schema用pydantic强校验了一遍，格式不对直接抛错给模型看错误信息，比让它瞎猜靠谱多了。重试这块建议加个最大次数和退避策略，别无限循环，另外可以在prompt里明确告诉模型“如果上一步失败，就基于错误信息修正参数，不要生成新函数”。状态机我们没用，但会记录每步调用链的输入输出，出问题能快速定位是哪一环的锅。

我一般会先做一层JSON schema校验，再对每个工具输出做字段级白名单，重试次数超过2次就直接降级成固定兜底逻辑。

建议把工具调用改成“校验-修正-确认”三步，别让模型自己反复生成，死循环基本都是因为没限定重试时的状态快照。

格式校验得做，但别全靠模型自觉，我一般让工具返回schema强校验，错了直接返回错误信息给它自己修，比盲重重试稳。

状态机控流转确实有效，但前期成本高，小项目先给每步设个最大重试次数，超了就降级到人工兜底。

试试给每个工具调用加个schema校验，失败就带错误信息重试，比无脑重新生成稳定多了。

试试把每步输出都做schema校验，不合法就直接按失败重试，别让模型自己改错。

我们这边是给每步定义好状态，最多重试两次就降级到人工兜底，别跟模型死磕。

我们之前也踩过这坑，尤其是模型脑补参数那块，后来干脆在prompt里把每个工具的schema贴全，再加一层pydantic校验，不对就直接把报错信息喂回去让它改，比光try-except强多了。重试次数设个上限，超过就降级成让用户确认或跳步，别死磕循环里。状态机倒是不必上，但每步工具的输出我会固定抽成个中间变量传给下一步，相当于软约束，体感稳定不少。你们现在重试是每次都让模型从零看全链路还是只回放当前这一步？我试过后者成功率更高。

加个schema校验再重试，别让模型自由发挥，参数错了直接打回。

这个问题我也踩过，说下我的做法。核心思路是把“模型生成”和“工具执行”彻底隔开，模型只负责输出意图，真正调API之前先过一层严格的schema校验，多余的字段直接丢掉而不是报错，缺字段才触发重试。重试别让模型自由发挥，把上一次的错误信息和正确格式一起塞回去，限制它只能修那一步，不要重规划整个流程。死循环基本是因为重试没有上限，我一般设两到三次，超了就降级成让模型用已有信息给个兜底回答，或者直接转人工。另外状态机真的很管用，每一步的输入输出都落库，哪步挂了从哪步续，不用整条链重跑。至于脑补参数，可以在工具定义里把required写死，再加个参数白名单校验，模型瞎编的直接拦掉。强约束格式和状态机我觉得不冲突，格式约束管单步，状态机管全局，两个一起上才稳。

可以试试让模型只输出函数名和参数，别让它自由发挥，再用状态机卡住流程，比单纯重试靠谱。

我一般加个schema校验层，格式不对直接打回让模型重写，别让它带着错往下跑。

这个问题我们也踩过不少坑，感觉核心不是重试次数不够，而是每次重试前有没有把上下文清理干净。模型脑补参数这事，光靠prompt里写“不要编造”基本没用，得在工具层做一层schema校验，参数对不上直接打回，把报错信息喂回去让它重生成，而不是让它自己判断对不对。

另外死循环很多时候是因为错误信息没变，模型每次拿到的反馈一样，自然就反复犯同一个错。我们后来会在重试时把前几次失败的尝试和原因一起塞进上下文，逼它换个思路，效果会好很多。

格式方面我倾向于强约束，能用function calling或者结构化输出就别让它自由发挥，多一个字段这种事在解析层直接过滤掉，别让它污染后面的步骤。状态机控制流转也挺关键，每一步的输入输出都落库，出问题能回放，不然调试起来真的抓瞎。

降级的话，我的经验是别指望模型每次都救回来，关键路径上要有确定性兜底，比如某步失败超过两次就转人工或者走预设的默认分支。你们内部API的返回格式稳定吗？如果接口本身返回就飘忽，那再强的容错也白搭，可能得先在最外层做一层适配。