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

我们这边是两招一起用，一是给模型输出套个json schema校验，不合格直接带错误信息回去让它修，比瞎试错强；二是把重试次数卡死，超过两次就降级到人工或者返回兜底结果，绝不让它死循环。你提到模型脑补参数，建议把函数定义里每个参数都写清楚枚举值或格式示例，能少犯很多病。另外状态机听起来重，但其实对长链路挺管用的，尤其适合中间步骤有依赖关系的场景。

我们团队之前也踩过类似的坑，后来发现单纯靠prompt约束输出格式根本不靠谱，模型该脑补还是脑补。后来我们改成两步走：第一步让模型只输出工具名和参数，第二步用代码强校验参数类型和必填项，不合法就直接返回错误信息给模型，而不是简单重试。另外重试次数一定要设上限，比如最多三次，超过就降级到人工介入或者走一个预设的默认流程，不然死循环真的能把token烧穿。还有个比较土但有效的方法，就是给每个工具调用加一个唯一的trace ID，这样哪一步出错、模型改了什么参数都能追到日志里，调试的时候能少掉不少头发。状态机我们也试过，但感觉对太自由的agent任务反而限制太死，现在用的是“半状态机”——只约束关键决策点，中间步骤还是让模型自由发挥，这样灵活性和稳定性平衡得还行。你们有没有试过让模型先输出完整的计划再逐步执行？有时候提前把整个流程写出来，能提前暴露很多格式问题，比边走边看要稳一些。

强约束输出格式挺关键的，再配合每步单独校验，能少一半幺蛾子。

我这边是加了个白名单校验工具参数，脑补直接拒绝重来，比无脑重试稳多了。

我这边踩坑后的做法是输出侧直接上JSON Schema校验，模型生成完先过一遍pydantic，格式不对就带着具体错误信息回去让它修，比单纯try-except强很多。另外强烈建议给每一步工具调用都设独立的超时和最大重试次数，超过就标记为失败走降级分支，别让整个工作流卡死。你提到模型脑补参数，这个可以在system prompt里把工具定义写死，并且用few-shot把“参数不存在就拒绝调用”的示例放进去，能减少不少幻觉。状态机我觉得还是得有，但别把所有逻辑都硬编码进去，让模型在状态节点间做选择，容错边界会清晰很多。

我这边也踩过类似的坑，尤其是模型自己脑补参数那个问题，简直防不胜防。后来我们干脆在工具定义里加了严格的JSON Schema校验，不光是格式检查，连字段类型和必填项都提前卡死，返回不对就直接抛错，不再让模型二次猜测。重试这块我觉得不能简单循环，得给每次重试换个提示词，比如把上一次的具体报错贴回去，让模型知道哪里错了，不然它大概率还是按老思路生成。另外状态机确实是个好思路，我们后来把每一步的输出都固化成中间态，模型只负责填当前这一步的“意图”，而不是让它自由发挥整个链路，这样就算某步挂了，也能从最近的稳定状态恢复。还有个土办法但挺管用，就是给工具调用加个超时和最大重试次数，超了就直接降级到人工处理或者返回兜底结果，别死磕。不知道你们现在对模型输出有没有做“可执行性预检”，就是先解析再执行，解析失败就不进执行环节，这一步能省掉很多脏数据。最后想问下，你们有没有试过把长流程拆成多个短子任务，每个子任务独立调一次模型？虽然会多花点token，但整体稳定性提升特别明显。

我之前也踩过类似的坑，后来发现光靠try-except重试真不行，模型会越错越离谱。我的做法是给每个工具调用加一层严格的输出校验，比如用JSON Schema先卡一遍格式，不符合就直接返回错误信息给模型，让它基于这个错误去修正，而不是无脑重试。另外状态机确实能兜底，把每一步的输入输出都限定清楚，模型只能做选择不能自由发挥。想问问你们有没有试过把工具返回的结果做一层摘要或脱敏，有时候模型就是被冗余字段带偏的。

试试给每个工具调用加个schema校验，不合法就让模型用错误信息重新生成，比纯try-except稳很多。

我们后来改成状态机兜底了，工具返回先过一层清洗，模型乱来就直接走预设分支，死循环基本绝迹。

我们团队之前也踩过这坑，后来发现单纯靠try-except重试确实容易钻进死胡同，尤其是模型在错误上下文里越挫越勇，开始疯狂编参数。我们现在的做法是分两层：第一层对模型输出做严格的schema校验，不是光看JSON格式，而是用pydantic这类库把每个字段的类型和枚举值都锁死，一旦校验失败直接截断重试次数，不无限循环。第二层是给每个工具调用加一个“契约”概念，就是预先把所有可能的参数组合和边界条件写成一个小的状态机描述，模型只能从预定义的动作集里选，而不是自由生成函数名和参数。

另外我们还会在prompt里塞几个“反例”样本，告诉模型什么情况是错的，比如“如果用户没提供时间范围，不要默认填今天”。重试策略上，我建议别每次让模型重新生成完整计划，而是只让它修正上一步的返回结果，这样上下文扰动小很多。最后如果连续两次修正都失败，就直接降级成人工介入或者返回一个模糊的兜底答案，总比卡死强。你那个死循环问题，大概率是重试时把错误信息也拼进对话历史了，模型被带偏了，可以试试重试时只保留原始请求和最新一次输出，别累积错误日志。

我之前也踩过这个坑，后来发现强约束输出格式其实挺有用的，让模型直接输出JSON Schema而不是自由格式，能少一半解析问题。另外重试别光靠try-except，得给模型反馈具体错在哪，比如“这个参数不存在，可选的有这些”，不然它真会一直脑补。状态机我倒是没用，但会在每步调用前做参数白名单校验，不符合就直接走降级逻辑，比如返回默认值或者问用户确认，死循环基本就绝了。你这几个API是自己内部的还是第三方的？第三方的话响应格式变化更恶心，可能得加个适配层。

我们团队之前也踩过类似的坑，后来发现核心问题不是让模型“别出错”，而是把“出错后的恢复路径”设计得足够窄。我们现在的做法是两层：第一层，工具调用前强制做schema校验，用JSON Schema或者pydantic直接把输出钉死，多一个字段就拒绝重来，绝不靠模型自觉；第二层，重试逻辑不简单让模型重新生成，而是把上一步的原始输出和报错信息一起塞回prompt里，明确告诉它“你刚才多了这个字段，现在只允许输出这些key”，这样能大幅减少脑补参数的情况。另外状态机我们也在用，但不是用来控制每一步的格式，而是控制整个流程的“可回退性”——比如第三步失败，不是重试第三步，而是回滚到第二步的已知良好状态，用缓存里的结果重新规划后续路径。死循环问题我们加了最大重试次数（比如3次），超过就降级成人工介入或直接返回部分结果，宁可不完成也别卡死。还有个歪招是给每个工具调用前加一个“dry-run”模式，先用假参数试跑一遍，确认格式没问题再走真实调用，虽然多花一点时间，但长流程的稳定性提升很明显。你们现在重试时是保留之前的对话历史，还是每次清空重来？这个对效果影响挺大的。

我之前也踩过这个坑，后来发现单纯try-except重试就是碰运气。我的做法是给每个工具调用加一层schema校验，用pydantic之类的强类型约束，格式不对直接报错并生成结构化错误信息给模型，让它知道具体哪里错了，而不是笼统的重新生成一次。另外状态机确实比让模型自由发挥靠谱，至少能保证每步的输入输出都是符合预期的，死循环的概率会小很多。你们现在对模型生成参数的上限有做限制吗，比如禁止它生成某些字段？

我们团队踩过同样的坑，后来是把工具调用的输出先过一层schema校验，不合法就直接返回具体错误信息给模型而不是重试整个流程，这样能大幅减少脑补参数的情况。另外重试次数得设上限，超过就降级到让用户确认或走人工兜底，不然死循环太烧token。状态机我觉得没必要，但会在prompt里把每步的输入输出样例写死，效果比单纯约束格式好很多。

我这边是给每个工具调用单独设了个pydantic模型做验证，格式错了就只重试那一步，不让模型重新规划整个任务，这样成功率明显上来了。还有个土办法，就是把上一步的输出截断一下再塞给下一步，防止模型被多余字段带偏。你们会不会遇到模型明明看到错误提示还硬要按原样重试的情况？我怀疑是温度设太高了。

容错这块我建议别太依赖模型自觉，多写点防御性代码。比如工具返回前先清洗字段，或者给模型一个固定的“工具选择+参数”的模板，让它填空而不是自由发挥。重试的话我会带上前一次的错误信息一起给模型，让它知道哪里挂了，不然它经常盲目换个参数又试一次。死循环我也碰到过，后来加了步数限制和关键词检测，比如连续三次报同一个错就直接终止。

我们生产环境是这么干的：工具调用分

我们团队之前也踩过类似的坑，后来发现光靠try-except重试确实容易死循环，尤其是模型会反复用同一种错误方式生成。我们现在是分两层：第一层用JSON Schema严格校验输出，不合法就直接返回错误信息给模型，让它根据具体报错修正；第二层给每一步工具调用都设了最大重试次数，超过就降级到人工确认或者跳过该步，至少保证整个链路不卡死。你提到的状态机我觉得挺有用的，特别是在流程固定的时候，比让模型自由发挥靠谱很多。

我之前做类似的东西也踩过这个坑，后来发现光靠重新生成一次根本不行，模型每次犯错的点可能还不一样，死循环太常见了。我的做法是给每个工具调用加一层严格的schema校验，用pydantic或者jsonschema把输入输出都锁死，格式不对直接返回一个机器可读的错误码，而不是让模型去猜哪里错了。然后重试策略上，我不用无限重试，最多两次，第三次就直接降级到人工确认或者返回一个默认的兜底结果，这样至少流程不会卡死。另外你说的状态机，我后来也试过，确实比纯靠模型规划靠谱，尤其是工具依赖关系明确的时候，把每一步的合法转移提前定义好，模型只能在有限动作里选，基本上能杜绝“脑补”参数的问题。不过这样会牺牲一些灵活性，得看你的场景允不允许。还有个细节，工具返回的原始报错信息一定要拼进下一次的prompt里，并且明确告诉模型“你之前哪一步错了、错在哪”，比让它自己反思效果好得多。你现在的模型是用的function calling还是纯文本输出JSON？如果是后者，建议尽早切到function calling，解析稳定性会高一个量级。

试试用JSON Schema强校验+固定重试次数，超了就走兜底默认值，别让模型自由发挥。

状态机加JSON Schema校验，别指望模型自觉，错一步就直接降级到人工兜底。

我们线上是重试两次就切预设参数，死循环基本靠最大步数掐断。

我之前也踩过类似的坑，后来发现光靠重试真不行，模型会越错越离谱。现在我是把工具定义强制加上json schema校验，输出直接过一层pydantic，格式不对就让模型基于错误信息修正，而不是简单重新生成。另外状态机确实有用，每步只给当前可用的工具列表，能挡住不少脑补参数的情况。你们有没有试过给关键步骤加个兜底规则，比如某次失败后直接走预设的降级路径，而不是让模型自己发挥？

我之前也踩过这坑，后来是强制模型输出带schema的json，解析失败就返回具体错误信息让它自己改，比单纯重试靠谱。另外给每步工具调用加个最大重试次数和超时降级，比如直接返回预设的兜底结果，不然真会卡死。状态机倒没必要，但至少得记录每步的输入输出快照，方便排查是模型还是API的锅。

我之前也踩过这坑，后来改成每步输出都强制带个状态字段，再配合最大重试次数兜底，基本稳了。

我建议你试试把工具调用结果先做一层schema校验，错了就返回具体错误让模型自己改，别直接重跑整个流程。

我们团队之前也踩过这坑，后来发现光靠try-except真不行。现在我们是先给模型一个严格的工具描述schema，然后所有输出强制过一层JSON校验，不合法就直接把具体报错信息喂回给模型让它修正，比让它凭空重试要稳得多。另外状态机确实值得考虑，尤其当步骤之间有依赖时，至少能保证不会因为某一步格式错就整个流程崩掉。你们有试过把工具调用的结果也做一层标准化吗？有时候模型自己改参数名，校验一下能避免不少“脑补”情况。