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

我们团队之前也踩过这个坑，后来发现单纯靠提示词约束输出格式根本不够，模型该乱还是乱。我们现在的做法是把工具调用拆成两步：第一步让模型只输出一个意图和参数草案，第二步用代码去校验和补全参数，缺的字段就根据上下文硬填或者直接问用户，不让模型自己发挥。重试这块我们加了退避机制，同一个步骤最多重试两次，第三次就直接降级成人工确认或者返回一个固定兜底结果，不然真的会卡死。状态机我觉得很有必要，至少能保证流程是确定的，模型只负责在每个状态里产出动作，流转逻辑交给代码控制，这样哪怕某一步返回了垃圾数据，顶多就是跳到一个异常分支，不会把整个链条带偏。另外你提到的JSON多了字段，我建议直接用pydantic这类库做严格解析，多余字段直接报错，让模型重新生成一次，比让它自己纠错靠谱。还有一个细节，工具定义里一定要把参数类型和枚举值写死，模型脑补参数很多时候是因为定义得太模糊了。最后想问下你们现在用的模型支持function calling的原生接口吗？如果支持的话，最好直接走那个协议，比自己解析文本稳定太多。

我之前也被这个折磨过，后来发现与其让模型自由发挥，不如把工具调用的schema卡死，用Pydantic这类库做严格校验，格式不对直接抛错重试，比try-except硬扛稳得多。另外状态机那个思路靠谱，每个步骤定义好前置条件和输出契约，模型只负责填参数，别让它决定流程走向，基本能避免脑补。还有个土办法是给每次重试加个最大次数限制，超了就降级成人工介入，不然真能跟你死磕到天荒地老。

我之前也踩过类似的坑，后来发现光靠try-except真不行，得在工具调用前加一层schema校验，格式不对直接让模型按错误信息重新生成，比让它瞎猜强多了。另外状态机确实是个思路，但我觉得轻量场景下不如把每个工具的输出都做成强类型，再让模型输出时带个confidence字段，低置信度就直接降级到默认值或人工介入。你们现在死循环有设置最大重试次数吗？我上次加了个3次上限后至少不会卡死了。

我之前也踩过类似的坑，后来发现光靠try-except真不够，尤其模型脑补参数那块，直接在prompt里加白名单约束，再配合JSON Schema做严格校验，能挡掉大部分问题。重试的话，我一般限制最多两次，超过就降级成让用户确认或者走兜底逻辑，不然真容易卡死。状态机听起来重，但反而能让流程更可控，你可以试试把每步的输出强转成中间表示，别让模型直接碰API。顺便问下，你们现在对API返回的异常有做分类吗，比如格式错和业务错分开处理会不会好点？

格式校验得前置，别等解析挂了才重试，JSON schema直接卡死能省好多事。

重试次数设上限，超了就走降级分支，别让模型无限自嗨。

我一般是输出强校验+重试次数上限，超了就直接降级到人工兜底，死循环真不能忍。

格式校验做严点，模型脑补参数就用jsonschema卡死，比让它自己改靠谱多了。

说到这个我可太有感触了，之前我们搞agent也是栽在工具调用上，后来干脆把每个工具的输入输出都做了严格的schema校验，模型输出先过一层正则加类型检查，不合法就直接把报错信息丢回给模型让它修正，而不是单纯让它重跑。你那个JSON多字段的问题，其实可以试试只提取必要字段，用白名单方式解析，别让模型自由发挥。

另外关于重试死循环，我建议设个最大重试次数，比如三次，超过就直接降级到人工处理或者跳过一个步骤，别让它无限纠缠。状态机倒是个好思路，但别过度设计，小项目用简单的状态枚举加上每步的校验函数就够用了，反而比复杂的流程控制更稳。

还有个坑是模型会脑补参数，这个得在prompt里把每个函数的必填参数和类型示例写死，甚至用few-shot给几个典型的调用例子，比单纯说“别乱传参”有效得多。你可以试试把工具描述改成类似OpenAPI那种格式，模型对结构化描述的理解通常更准。

我最近还在试一个思路，就是每次工具调用前先让模型输出一个“意图确认”步骤，人工或者规则确认后再执行，虽然多一次调用，但能减少后面连环出错。你们生产环境有没有试过给模型加个“undo”能力，就是检测到某步结果异常时，让它自己回退到上一步重新规划？这个对长流程还挺有用的。

我们生产环境踩过一样的坑，最后发现光靠try-except重试真的会陷入逻辑死循环，尤其是模型自己脑补参数那种情况，重试多少次它都可能犯同样的错。我们现在的做法是三层防护：第一层是在工具调用前加一个schema校验，用pydantic或者json schema强约束输出，不合法就直接打回让模型重新生成，但会附带具体错误原因；第二层是给每个工具调用加超时和失败计数，连续失败超过两次就触发降级策略，比如跳过该步骤用默认值，或者走一条更简单的备选流程；第三层是搞了个状态机，但不是控制整个流程，而是控制每一步的输入输出契约，每一步都必须返回一个标准化结果对象，这样模型哪怕乱来，状态机也能兜底。另外你说模型脑补参数，我们试过在prompt里把所有可用函数和参数类型明确列出来，并强制要求它先输出一个“思考草稿”再生成调用，效果好了很多。还有个比较土但有用的办法，就是把JSON解析改成宽容模式，用类似jq的库去提取关键字段，多余字段忽略掉，这样至少不会因为多一个key就全盘崩掉。

我之前也踩过这个坑，后来发现光靠重新生成真的容易死循环，尤其模型越修越离谱。现在我是强制要求输出带schema的JSON，解析失败就直接把错误信息原样喂给模型，让它基于报错改而不是凭空猜。状态机那套我觉得适合流程完全固定的场景，但稍微灵活点儿的任务还是得靠校验+重试次数上限，超了就直接降级到人工兜底。另外你提的“脑补参数”我试过把函数定义也塞进system prompt里，效果有改善但没根治，偶尔还是会冒出来奇怪的键。

学到了，感谢分享！

我之前也踩过类似的坑，后来发现光靠try-except真不行，模型一抽风就无限重试。我现在是给每个工具调用加了个轻量级的schema校验，不匹配就直接返回具体错误让模型修正，而不是让它重新生成整个计划。另外状态机那套太笨重，我试过用个简单的计数器控制最大重试次数，超过就降级到人工输入，感觉比硬约束输出格式实用一些。

插一句，你那边模型“脑补”参数的问题，试试在prompt里给几个反例，比如明确说不要传foo这个字段，会收敛很多。还有你们API返回格式不统一的话，是不是考虑在工具层做个适配器统一清洗一下，省得后面全乱套。

强约束输出格式只能治标，关键还是得给模型配个schema校验器，不合格就直接重试别让它瞎编。

试过状态机+每步快照，失败回退到最近合法节点，比无脑重试稳多了。

强约束输出格式+状态机双保险，容错重试设个最大次数直接降级到人工兜底，别让模型无限循环。

输出校验用JSON Schema挡掉脏数据，重试前把错误信息喂回去让它自己纠错，比盲试稳多了。

强约束输出格式是真有用，但更关键的是给模型配个入参schema校验，错了直接拦下来重新生成。

我这边是重试次数设上限，超过就降级给默认值或者让用户介入，死循环基本就断了。

强约束输出格式只能减少问题，真正稳还得靠状态机加每步校验，重试次数设上限。

强约束输出格式不如把每步结果做schema校验，错了直接返回错误信息让模型自己改。

我一般给工具调用加个最大重试次数，超了就走人工兜底分支，避免死循环。

我一般会在每步工具调用后做个schema校验，格式不对直接丢弃重来，比让模型瞎试稳多了。

强约束输出格式+状态机双管齐下，重试设个上限再降级到人工兜底吧。

每步结果都做schema校验，错了就带上错误信息重试两次，再不行直接跳下一步。

强约束输出格式治标不治本，关键还是得给模型配个校验器，错了就自动纠正参数再重试。

我们之前加了重试上限和降级兜底，死循环直接走人工，效果比纯try-except稳多了。

强约束输出格式+每步校验，比让模型自己重试靠谱多了，状态机控制流转能避免死循环。

建议给每个工具定义严格schema，返回前先用代码校验一遍，别全指望模型自觉。