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

这问题太真实了，我最近也被多步调用的“幻觉参数”折磨得够呛。我的做法是给每个工具定义一个严格的JSON Schema，模型输出后先做一次校验，不光是字段类型，连枚举值、必填项都卡死，一旦不通过就直接让模型“修正错误”而不是重新生成，这样死循环概率会小很多。另外你说的状态机，我觉得在关键节点上很有用，比如把“规划-执行-校验”拆成独立步骤，每步结果存下来，失败时只回退到上一个成功状态，而不是从头再跑。还有个土办法，就是在prompt里给几个“反面案例”，明确告诉模型哪些参数组合是禁止的，比单纯说“请遵守格式”管用。至于重试次数，我一般限制在2-3次，超过就降级到人工介入或者返回一个兜底结果，毕竟生产环境稳定比“智能”重要。对了，你试过用函数调用模式而不是让模型自己拼JSON吗？有些模型对结构化输出的支持能省不少事。

我们之前也被这个坑过，后来干脆在工具定义层加了严格的schema校验，模型输出先过一遍JSON解析和字段类型检查，不合法就直接返回错误信息让模型自己修正，而不是盲目重跑整个流程。状态机倒是没上，但给每一步设了最大重试次数和降级分支，比如某步失败就跳到一个兜底函数。还有个心得是别让模型自由发挥参数，把所有可枚举的选项都列在prompt里，配合few-shot示例，能少很多“脑补”。你们现在死循环是卡在同一个错误上还是每次错误都不一样？

我最近也被这个坑过，后来发现光靠try-except不够，关键得在prompt里把工具返回的schema给死，再让模型输出前先做一步自检，能省好多事。另外重试次数设个上限，超过就直接降级到让用户确认下一步，避免死循环。你试过用pydantic或者json schema做严格校验吗？比让模型自己判断靠谱多了。

我之前也踩过这个坑，后来是把工具调用的输出先做一层schema校验，不合法就直接把错误信息拼回prompt让模型修正，比单纯重试成功率高不少。另外状态机确实更稳，尤其是分支多的时候，能避免模型自己乱跳。你那个死循环问题，可以加个最大重试次数，超了就直接降级返回兜底结果，别让它无限耗着。

我之前也踩过这个坑，后来是给每个工具调用加了严格的schema校验，不光看类型，连必填字段和枚举值都查一遍，不符合就直接返回一个结构化的错误给模型，比让它自己猜强多了。重试这块我建议设个最大次数，而且每次重试前把上一次的具体报错信息拼进prompt里，不然模型确实容易在一个地方打转。还有一个笨办法是给关键步骤做个幂等设计，即使某一步重复执行了也不会产生副作用，这样容错压力小很多。

强约束JSON Schema加状态机，重试次数上限3次，再不行就降级默认值或人工兜底。

我们之前也踩这坑，后来直接不重试，靠校验失败就跳下一步带默认值，反而稳得多。

我们之前也踩过这个坑，后来是给每个工具调用加了个schema校验层，JSON解析失败直接返回一个结构化的错误码给模型，而不是让它瞎重试。另外重试次数得设上限，超过就降级成让用户确认或走兜底流程，不然真会卡死。状态机倒是没上，但会把每步的输入输出存下来，出问题能回溯到具体那一步。你们现在对模型“脑补”参数是咋处理的？我试过few-shot给例子，但效果还是时好时坏。

我们团队之前也踩过类似的坑，后来发现单纯靠try-except重试确实容易陷入死循环，因为模型可能反复生成同一个错误。后来我们改成两段式校验，第一层用json schema强制卡字段类型和必填项，第二层对工具参数做白名单过滤，不在定义里的参数直接丢弃，这样至少能避免模型“脑补”出来的东西进到API里。但光有校验还不够，重试策略也得有上限，比如最多重试三次，每次重试前把上次的错误信息拼到prompt里，让模型知道具体错在哪，比让它盲目重生成要有效得多。还有一点，如果连续两次重试返回的错误是同一类型，我们就直接放弃这条路径，触发降级逻辑，比如调用一个兜底工具或者让用户手动确认，而不是死耗。状态机确实是更稳的方案，但实现成本高，我们目前是在“伪状态机”的层面做，就是每一步工具调用前都先让模型输出一个当前状态的摘要，这样即使中途出错，也能定位到具体是哪一步的状态对不上。另外，我比较好奇你们对工具返回结果的解析是怎么做的，是直接让模型当作上下文继续，还是先转成结构化数据再喂回去？因为返回格式不干净的话，后面所有步骤都会受影响。

强约束输出格式只能减少出错，重点是给模型加个工具调用schema校验层，失败就降级到人工兜底。

强约束输出格式只能治标，建议给每步定义JSON Schema校验，失败就带错误信息重试，最多三次直接降级到人工兜底。

我之前也踩过这坑，后来发现光靠try-except真不够。现在我是让模型输出一个固定的中间结构，再用json schema强校验，不合法就直接标记这步失败，然后走一个预设的降级分支，比让它自己重试靠谱多了。

另外你说的脑补参数，我试过在系统提示里把函数定义写得很死，还加了few-shot例子，效果好了不少。不过状态机那套我还没用上，感觉小项目里维护成本有点高，你们是用什么判断该重试还是直接降级的？

我之前也被这个问题折磨过一阵，后来发现与其让模型自由发挥再靠try-except兜底，不如在提示词里把工具签名写成严格的伪代码，同时要求它先输出一个“意图确认”步骤，确认参数和动作后再真正调用。这样虽然多一次往返，但能砍掉一大半脑补参数的情况。至于重试，千万别让它无限重试，我一般设成最多两次，而且第二次会让它先解释上一次哪里错了再重新生成，相当于给个反思机会，效果比直接重来稳定很多。你提到的状态机我也试过，但对于灵活的agent反而太死板，后来我用的是“阶段校验”，就是每步输出后做个schema校验，不通过就返回具体错误字段让它修正，而不是整段重来。还有个坑是JSON解析，别用默认的，自己写个宽容解析器，把多余字段忽略掉，再把字符串里的布尔值和数字类型强行规范化，能挡掉不少格式问题。最后降级的话，如果某一步连续失败，就直接跳过它并把结果标记为“未知”，让后续步骤基于缺省值继续，至少不会整个流程崩掉。

我们团队之前也踩过这个坑，后来发现光靠重试不行，得在工具调用前加一层schema校验，用pydantic这类库强约束参数，格式不对直接拦截而不是丢给模型。另外重试次数设个上限，比如2次，超过就降级成让用户确认或者走一个固定模板的兜底逻辑，死循环基本都是因为没设硬性退出条件。你们现在模型是用的function calling还是自己解析输出？如果自己解析的话，建议试试把工具定义和返回示例直接塞进系统提示词里，能少很多“脑补”的情况。

可以试试把每个工具调用结果都做schema校验，不合规就自动转成错误消息喂回给模型，比单纯重试稳很多。

这问题太真实了，我这边之前也是被多步调用坑得死去活来。后来我干脆不再完全信任模型输出的参数，每步工具调用前都加一个独立的schema校验层，用pydantic或者json schema强校验，格式不对直接返回具体错误信息给模型，而不是单纯让它重试。你那个try-except重试会死循环，多半是因为模型不知道错在哪，你把它报错的具体字段和期望格式拼回去提示词里，它自己就能修正大部分问题，成功率能提不少。

另外状态机确实是个好思路，但别搞太复杂，我见过有人把每一步工具定义成有限状态，模型只能按顺序走，中间状态不对就回退到上一步而不是从头开始，这样能避免很多连锁崩溃。但我也挺好奇，你们对那种“模型脑补参数”的情况，是直接拒绝调用还是尝试用默认值兜底？我现在是拒绝并让它重新生成，但有些业务场景其实允许部分参数缺失，这个度挺难把握的。

还有一个坑是超时和重试次数，我建议给每步调用单独设超时和最大重试次数，超过就降级到人工审核或走一个简单规则逻辑，别让agent无限卡在那。你们现在有做这种降级策略吗？还是说全靠模型自己纠错？

我们之前也踩过类似的坑，后来是把工具调用结果强制走一层schema校验，不合法就直接返回给模型一个明确错误码和修正提示，比单纯让它重试靠谱得多。另外你可以试试给每一步定义一个最大重试次数，超了就跳到兜底分支，别让模型无限循环。状态机我们也在用，但感觉对复杂流程反而维护成本高，不如把每一步的输入输出都做严格约束，再配合一个全局的异常捕获池。

试试把工具调用结果先做一层schema校验，不合规就自动修正字段再喂给模型，能少一半幺蛾子。

重试别光靠模型自己改，加个最大次数和降级策略，到点直接走兜底流程。

我们这边当时也踩过类似的坑，后来发现光靠try-except重试是真的不行，模型会越试越偏，甚至把错误信息当成上下文继续编。后来我们改成了两段式校验：第一层是硬性的schema校验，用pydantic或者json schema直接卡死，字段多一个少一个立刻打回，根本不给模型解释的机会；第二层是针对业务逻辑的软校验，比如参数值范围、枚举类型这些，校验失败就带着具体错误信息重新构造prompt，让模型只改那一个函数调用，而不是整段重生成。另外你提到状态机，我觉得这个方向是对的，至少要把每一步的输入输出缓存下来，这样重试的时候可以直接从失败那步开始，不用从头跑一遍，能省不少token。还有个土办法是给每个工具调用加一个“确认”步骤，让模型先输出意图再输出参数，虽然多一次交互，但错误率能降一半。最后降级的话，我们会对关键API做个简单mock，实在不行就返回预设的兜底结果，至少不让流程卡死。你们现在模型是用function calling还是自己解析JSON？如果是后者，强烈建议试试前者，格式问题能少一半。

我们这边是三步走：先对模型输出做一层严格的schema校验，不合规直接重试，重试前把报错信息塞回prompt里让它自己改；其次给每步工具调用都设个最大重试次数和超时，过了就直接降级返回默认值或者让用户确认；最后是用状态机把流程固定住，模型只负责生成参数，流转逻辑完全由代码控制。你那个死循环大概率是重试时没保留上下文痕迹，试试把失败原因和当前状态都拼进下一次请求里。

试过把输出直接丢给jq校验，不合规就带错误信息重试，比纯try-except稳不少，但还得限制重试次数。

我们后来加了层轻量状态机，每步卡schema，模型瞎编参数就直接回退上一步，死循环基本绝迹了。