Agent开发中工具调用老是出幻觉，大家是怎么约束的？

这问题我太有同感了，之前做内部工单系统Agent时也栽在这上面。我的经验是光靠prompt约束确实治标不治本，后来直接上了两层保险：第一层是强制用function calling的strict schema模式，把每个字段类型、必填项、枚举值都钉死，模型一旦输出不合规的JSON就直接拦截；第二层是写了个校验重试模块，解析失败自动把错误信息回传给模型，让它自己根据报错修正参数，最多重试三次。这套下来错误率降了大概七成，但说实话还是有漏网之鱼，尤其当API字段带歧义时模型会自作主张。我觉得换更强模型是最后的选择，毕竟成本摆在那，但如果你对实时性要求不高，也可以试试在system prompt里明确告诉它“宁可拒绝调用也不能编造”，并把所有真实字段名用代码块单独列出来。倒是想问下，你们下游接口有没有试过把参数校验逻辑前置，比如直接在API网关层做白名单过滤？

我这边是直接上JSON Schema强校验+失败自动重试，基本能把幻觉卡死，但偶尔还是得靠人补一刀。

说到底工具调用还得靠约束，别指望模型自觉，校验循环比换模型省事儿多了。

function calling的schema校验必须上，再加个重试机制，能过滤九成幻觉，别指望模型自觉。

试试把工具参数改成严格枚举类型，再写个解析失败自动回退的兜底逻辑，比换模型实在。

我之前做类似的东西也踩过这个坑，后来发现光靠prompt约束确实不顶用。我这边是把所有工具参数定义成严格的JSON Schema，然后在调用前用pydantic做一层校验，不合法就直接触发重试逻辑让模型重新生成，大概能砍掉八成幻觉。不过有时候模型会死循环重试，最后我还是得在循环里加个最大次数，超了就给个默认值兜底。说到底模型能力还是有瓶颈的，4o已经算稳了，换claude或者gpt-4-turbo可能好点，但成本也上去了。

我自己的经验是工具调用这块别太依赖模型自觉，干脆把schema校验和重试做成一个独立模块，跟ReAct循环解耦。每次模型输出先过一遍校验，失败就把错误信息拼回去让它修，比单纯few-shot管用。但注意别让它无限重试，我设了三次上限，过了就直接报错。另外你试试把工具描述写得特别细，比如每个字段标清楚“必填”和“示例值”，幻觉会少很多。换模型的话，Claude 3.5 Sonnet在这块确实比GPT-4o稳一些。

你这问题我太有共鸣了，之前做Agent被这个折磨得不行。我现在的做法是双保险：一是用function calling原生的strict模式，只要模型返回不是合法JSON就直接拒绝；二是

schema强制校验这块我建议直接上，别只靠prompt，用JSON Schema套一层严格校验，不合法就让模型根据报错信息重试一次，能过滤掉大半幻觉。另外你试试把工具参数改成扁平化结构，别用嵌套对象，模型编造字段的概率会低不少。我这边还加了个“参数白名单”机制，不在定义里的key直接丢弃，比让模型自己纠错靠谱多了。

说实话，光靠prompt约束这问题很难根治，我这边之前也踩过类似的坑。后来直接在工具调用外面套了一层JSON Schema校验，解析失败就自动重试，配合一个简单的错误信息回传给模型，效果好了很多。不过你那个编造字段的情况，可能还得检查下是不是工具描述给得太开放了，把每个参数边界写死能减少不少幻觉空间。至于换模型，GPT-4o其实够用，关键还是得靠工程手段兜底，别指望模型自己变老实。

我们项目也踩过这坑，后来加了JSON Schema强校验加自动重试，幻觉率降了七成，你可以试试。

试过在prompt里明确要求“只输出JSON，不要补全未知字段”效果一般，后来直接用Pydantic做schema强校验加两轮重试，命中率提升不少，但偶尔还是会瞎编。感觉本质还是模型对工具语义理解不够，换带tool-use微调的模型会好很多，GPT-4o本身在这块不算最优解。

schema强校验加一层重试循环基本能拦住九成问题，剩下的偶尔抽风就当运气吧。

我们团队之前也踩过这个坑，后来是直接上function calling的strict schema模式，配合一个轻量的校验层，解析失败就自动带错误信息重试一次，幻觉率降了不少。另外发现温度调低到0.1对减少编造字段挺管用的，你可以试试。至于换模型，除非业务允许上更强的，不然还是靠工程手段兜底更实际。

我之前做类似的东西也被这个坑过，后面直接套了一层JSON Schema校验，解析失败就让模型根据报错信息重新生成一次，大概能救回来七八成。但说实话，如果工具本身字段定义得太宽松，模型还是会钻空子，我觉得本质还是得把每个参数的描述写死，甚至给个默认值兜底。另外也试过把工具返回的error message直接喂回给模型让它自我修正，比单纯重试效果稳定一些。换更强模型确实有用，但成本上不划算，除非业务场景对准确率要求特别苛刻。

我之前也踩过这个坑，后来干脆在工具定义里把必填字段和枚举值写得特别死，然后套了一层pydantic做输出校验，一旦解析失败就让模型基于报错信息重新生成一次，基本能压到5%以下的幻觉率。不过说实话，遇到那种多步依赖的调用链，光靠校验治标不治本，模型该编还是会编，最后我还是换了个更强点的模型才舒服。

schema强校验加一层重试循环基本能解决九成问题，剩下的交给模型自己反思修正就行。

我们项目里就是这么干的，比换模型省钱多了，GPT-4o够用。

试过加一层轻量级JSON Schema校验，失败就自动重试一次，成本低还能拦住大部分幻觉。

说实话schema强制校验这块真得加上，我之前用function calling的时候也遇到过类似问题，后来在解析参数前先跑一遍json schema校验，不合法就直接让模型重新生成，成功率能提不少。不过你提到的重试循环要注意控制次数和反馈方式，最好把校验失败的具体原因拼进错误消息里再喂给模型，不然它容易原地打转。换个角度想，GPT-4o在复杂工具组合时确实容易放飞，如果业务允许的话，把大工具拆成几个更原子化的小工具，每个只接收少量必填参数，幻觉概率会低很多。

说实话schema强校验这块我觉得是必须上的，别指望提示词能完全堵住漏洞。我之前用function calling也遇到过类似问题，后来是把每个API的参数定义成严格的JSON Schema，模型输出后直接走一层pydantic解析，解析失败就自动带错误信息重试一次，效果比单纯改prompt稳得多。

不过有个坑要注意，重试逻辑别设计得太死，不然模型会陷入反复生成同样错误参数的循环，我后来加了随机扰动或者把错误信息写得更具体一点才缓解。另外你说的“编造JSON结构”这个，我怀疑是不是有些API返回的字段名本身太模糊，模型容易联想出相似的假字段？可以试试把所有枚举值、可选字段在schema里写死，甚至给每个字段加description说明“不存在这个字段”，这种负向提示有时候挺管用。

至于换更强模型，我觉得是最后一步，毕竟成本摆在那。GPT-4o在复杂工具场景下确实会暴露这个短板，但通过“校验-反馈-重试”这个闭环，能压掉大部分幻觉。我还见过有人用两个模型互相检查，一个生成一个验证，但延迟翻倍，看你的业务能不能忍了。

还有个偏门思路，就是把工具调用的结果也作为上下文塞回去，让模型看到“上次生成的参数导致报错”，这样它在下一次生成时会倾向于参考真实返回结构。你可以试试把校验失败的具体原因直接拼接进对话历史，而不是只给个“调用失败”的笼统反馈。

我们团队之前也踩过这个坑，后来是在工具定义里加了一层严格的jsonschema，并且把必填字段的description写得特别具体，比如标明枚举值或者格式示例，模型瞎编的概率明显降下来了。另外你提到的重试循环我觉得挺有效的，但别让模型自己纠错，直接用解析失败的错误信息去触发二次生成，成功率会高不少。还有个小技巧，把工具返回的结果也喂回上下文里，让模型看到真实结构，它就不太会凭空捏造了。

我们项目加了pydantic校验+自动重试，把报错喂回模型重新生成，幻觉基本压到2%以下。

试过强制JSON schema但治标不治本，关键还是得让模型看到校验失败的真实报错，它自己会收敛。

我之前搞tool calling也踩过这坑，后来发现光靠prompt真压不住。你可以试试把每个API的参数定义成严格的JSON Schema，配合function calling一起用，模型编造字段时直接校验失败触发重试，多试几次基本能把这问题洗掉。不过要是你的API参数本身就很杂，那确实得考虑换更强的模型，比如Claude或者新出的推理模型，它们对指令边界的遵守会好不少。另外你可以在生成后加个轻量级的pydantic校验层，把非法调用直接过滤掉，至少能保住下游不崩。

说实话你这情况太典型了，我这边之前用GPT-4o做内部工具调用也踩过一模一样的坑，尤其当API字段多、嵌套深的时候，它特别喜欢脑补默认值。后来我把所有工具定义里的required字段全改成显式null而不是省略，再配合一个轻量级的JSON Schema校验层，不合法就直接把具体报错信息丢回给模型让它自己修正，效果比单纯调prompt稳得多。另外别指望换模型能根治，Claude和GPT-4o在复杂参数生成上各有各的离谱，关键是得让模型意识到每次调用都有“成本”。我现在习惯在system里加一句“如果参数不确定就返回UNKNOWN，不要猜测”，配合一个重试计数器，最多让模型自我纠正两次，超过就直接转人工兜底，基本能把幻觉率压到5%以下。你那个ReAct框架里其实可以塞一个工具调用前的“语义预检查”步骤，用另一个轻量模型把自然语言意图和参数列表对一遍，也能挡掉不少瞎编的情况。不过说真的，如果你们内部API字段特别多，不如考虑直接上Pydantic这类强类型库，让模型输出结构化对象而不是裸JSON，解析层彻底跟模型解耦，这招对我这边最管用。