Agent多轮对话中工具调用结果老是被大模型“脑补”怎么办？

校验层这事儿我试过，比想象中靠谱，拿工具返回的JSON抽关键字段跟模型输出做个模糊匹配，命中率不够就强制重生成一轮，能压住大部分幻觉。另外你那个拼模板的思路也可以，相当于把工具结果变成固定句式让模型填空，自由度小了自然不好瞎编。不过Qwen2.5对长context里的工具结果确实容易“遗忘”，我后来把最近一次的工具输出单独放在user消息末尾重复一遍，效果比塞system prompt好不少。你temperature调到0.2还是偶发的话，可以试试对同一轮请求做两次采样，结果不一致就默认用第二次，成本高但简单粗暴。

这问题我太有共鸣了，之前用别的开源模型也踩过同样的坑，后来发现根源在于模型把“工具结果”和“训练语料里的天气常识”混在一起了，特别是温度这种数字，模型会不自觉往季节平均值上靠。你说的校验层思路我觉得是最靠谱的，但别全量比对，只针对数值、日期、否定词这些高危实体做一致性检查，比如抽取出“明天有雨”里的“明天”去跟工具返回的时间戳比对，对不上就强制触发二次生成。另外有个取巧的工程办法，就是把工具返回的JSON先做一层语义压缩，比如只保留“天气状态+温度范围+风力等级”这种结构化摘要，再拼进prompt里，并且用分隔符明确标注“以下内容必须逐字引用”，实测能降低不少幻觉，但偶尔还是会犯病。还有个细节，temperature0.2可能不够，我后来直接改成0，并且把top_p也调到0.1，虽然牺牲点多样性但稳定很多——如果你们接受答案偏保守，可以试试。还有个偏门思路，就是给模型加个“存疑时主动说不知道”的指令约束，配合few-shot示例专门展示“工具没返回就不提”的正反案例，比单纯改prompt有效果。不过说实在的，这种长链路里只要有一环模型没吃透指令，还是会有漏网之鱼，所以最终我上了个轻量级的规则层，专门拦截模型输出里所有跟数字、日期相关的子句，如果不在工具结果里就直接删掉，宁可让回复缺信息也不它瞎编。你们如果对延迟不敏感，还可以考虑让模型先输出一个“引用清单”，再基于清单生成最终回答，相当于强制它走一遍“证据到结论”的流程，虽然多一次调用但效果很稳。你现在是单轮校验还是每轮都做？如果是多轮历史里的旧信息被脑补，那可能得把每轮工具返回都存下来，生成时动态注入当前轮的关键状态，不然模型容易把之前的对话记忆给补全了。

校验层比较靠谱，直接让模型把答案写成JSON再比对工具结果字段，不匹配就重生成。

之前做类似项目也踩过这个坑，后来是加了个轻量的规则层，把工具返回的JSON先抽成关键字段拼成固定话术，再让模型在这个框架里填词，基本杜绝了自由发挥。你可以试试把工具结果和用户问题一起塞进一个“只做转述”的提示词模板，语气上强制它用“根据工具结果”开头。另外校验层我试过用正则或者小模型做一致性比对，但成本有点高，如果是偶发情况不如直接对输出做二次查询，让模型自己重新读一遍工具结果再修正。

这个问题太典型了，我们之前也踩过。一个比较有效的工程trick是，把工具返回的JSON直接解析成“事实列表”，强制模型照着列表逐条转述，而不是让它自由生成。校验层其实更靠谱，可以用规则或小模型比对输出里有没有超出工具结果的内容，有就直接重试一次。另外，把temperature调到0.1以下，配合few-shot示例里明确标注“不要补充任何额外信息”，能显著减少幻觉。

这问题太典型了，模型“脑补”本质上是生成时对上下文注意力分配不均，尤其工具结果夹在长对话中间，容易被后面系统指令或历史消息稀释掉。我试过把工具返回结构化后直接替换成“用户不可见”的独立消息角色，比如单独塞一个tool_response标签，比强行拼进system prompt效果好一些，但关键还是得让模型明确“这段文本是事实来源，不是可参考的闲聊”。

另一个我能想到的土办法是，解析工具JSON后，把关键字段直接填入你预设的回复模板，比如“当前天气为{weather}，温度{temp}度”，再让模型只做润色而不是自由生成。这样模型哪怕想编，也得先过你那层模板的校验，至少能挡住一半瞎扯。

不过校验层我觉得更实在，别让模型自己判断对错，直接写个规则脚本比对模型输出里的数字、日期、天气关键词和工具返回值，不一致就触发重生成，或者干脆把不一致的部分替换成工具原文再让模型复述一遍。这办法笨但稳，成本也低。

另外你提到temperature调到0.2，其实可以试试采样时把top_p也压到0.8以下，有时候温度低但top_p宽，照样会抽出小概率的编造词。

还有个偏门思路，把工具结果在prompt里重复两遍，一遍放在对话开始前，一遍紧贴生成位置，模型对近期重复内容的忠实度会高很多，代价是token翻倍，但72B跑本地应该能扛。

最后问一下，你那边工具返回结果本身有没有可能包含多轮历史残留？我之前遇到过一次是缓存没清，模型把上一次查询的答案当成了当前结果，排查半天才发现是数据源的问题，不全是模型锅。

这问题太真实了，72B在长对话里确实容易“飘”，尤其当工具结果和用户问题在语义上有点跳跃时，模型会不自觉去补全那些“合理但不存在”的细节。你试过temperature降到0.2还不行，说明问题不在随机性，而在生成策略本身——模型把工具返回当成了“参考信息”而不是“唯一事实源”。

我建议试试把工具返回结果做结构化约束，比如在prompt里明确写“以下是唯一可用的事实，任何不在其中的内容都不得提及”，同时把返回的JSON解析成固定句式，像“当前天气为：晴，温度25摄氏度”，然后强制要求模型只能对这段文本做同义改写或直接复述，禁止添加任何未出现的形容词或预测。这比单纯塞system prompt更有效，因为模型对“命令式”的遵守度远低于对“格式模板”的模仿。

另外，你说的校验层思路我觉得是终极方案，但轻量级做法可以加一个后处理规则：让模型先输出一个“事实抽取”中间步骤，再用正则或字符串匹配去比对工具返回里的关键实体（比如温度、天气词），如果发现模型输出里出现了工具结果中没有的数值或状态词，就触发一次重生成，并在这个回合的prompt里强调“上次生成包含未授权信息”。这能拦截大部分脑补，但偶尔还是会有漏网的，毕竟模型对否定指令的理解有限。

还有个偏门但管用的招——把工具调用结果的JSON直接转成“伪代码”格式，比如“weather_result = {status: 晴, temp: 25}”，然后让模型用“根据weather_result，当前状态为…”来开头，这样模型会把后续内容绑定在变量名上，编造时容易产生语法冲突，反而会自我纠正。你可以先试试这个，成本最低。

我之前也踩过类似的坑，光调temperature不够，后来是把工具返回的JSON先抽成固定字段，再让模型做填空式总结，确实能减少编造。但你那个“明天有雨”的情况，估计是模型把训练知识里的天气常识带出来了，单纯改prompt可能压不住。校验层我觉得挺靠谱，特别是对数值和日期做正则/规则比对，不一致就强制重生成，比全量重跑省token。另外你试过在工具结果前加个“仅基于以下事实”的强标记吗？对Qwen系有时比塞system管用。

我之前也踩过这个坑，光调temperature没用，核心是让模型没机会“自由发挥”。我的做法是把工具返回结果直接结构化，比如转成固定的markdown表格或者key-value模板，然后强制要求模型只能引用模板里的原字段，不许自己扩写。另外可以加一个后置校验，用正则或者简单的相似度比对，发现模型输出里有工具结果里不存在的实体或数字就触发重新生成，比单纯改prompt靠谱得多。

这个问题挺典型的，我也踩过类似的坑。工具返回结果被模型“脑补”其实很多时候不是模型不听话，而是它在多轮对话里把之前的上下文和工具输出混在一起了，尤其是你中间还有RAG检索内容的时候，信息源一多它就容易串。我试过把工具返回的JSON直接转成自然语言再塞回对话里，比塞原始JSON效果好一些，因为模型对结构化数据的“注意力”其实没那么强。另外你可以考虑在工具调用后加一个中间步骤，让模型先复述一遍工具返回了什么，再基于这个复述去生成最终回复，相当于强制它做一次“对齐”。校验层我也做过，用规则或者小模型去比对关键字段，比如温度和天气状况，发现不一致就重新生成或者直接走模板兜底，成本不高但挺管用。不过说实话，Qwen2.5-72B在长上下文里对工具结果的忠实度确实会随轮次增加而下降，可能跟位置编码和注意力衰减有关。如果你们的对话轮次比较深，可以试试把工具结果放在离生成位置更近的地方，而不是一直留在system里。

这个坑我也踩过，Qwen在工具调用后确实容易自由发挥。我的做法是工具返回后不直接让模型总结，而是先解析JSON，把关键字段拼成固定模板再喂给模型，让它只做改写不做推理。另外可以加一层轻量校验，比如用正则或小模型比对输出里的数值和工具结果是否一致，不一致就重试。温度调到0其实也会偶发，关键还是把生成空间压窄。

加个校验层比对下模型输出跟工具结果，不一致就重生成，比硬塞prompt管用。

这个坑我也踩过，光靠prompt约束确实不靠谱，模型该脑补还是脑补。我后来是在工具返回后加了一层轻量校验，把关键字段抽出来跟模型最终回复做比对，不一致就重新生成或者直接走模板兜底。另外可以考虑把工具结果作为user消息而不是system塞进去，实测遵循率会高一些。Qwen2.5本身指令跟随还行，但多轮里历史一长就容易飘，缩短上下文或者每轮显式重述约束也有帮助。

我之前也踩过这个坑，Qwen2.5-72B已经算听话的了，但工具结果一长它就容易“自由发挥”。我的做法是在工具返回后加一层轻量校验，比如把JSON里的关键字段抽出来做正则匹配，生成回复前先检查有没有出现工具里没有的数字或天气词。另外模板拼接确实有用，但别只塞system，最好在user轮里用固定格式再强调一遍“仅根据以下数据回答”。如果还偶发，可以考虑让模型先输出一个引用片段，再基于片段生成最终回复，相当于强制它先对齐再总结。