用LangChain搭Agent时，工具调用总是“幻觉”乱选，怎么调教？

我之前也踩过这个坑，后来发现核心问题往往不在temperature，而是tool description太“宽泛”了。你试试把每个工具的触发条件写得极端具体，比如“仅当用户明确提到天气/降雨/温度时才调用”，同时把“提醒”工具里加一句“禁止包含天气信息”。另外强烈建议加个中间校验层，让Agent先输出一个结构化意图（比如“意图:提醒,参数:带伞”），再用规则判断该不该调工具，比硬调prompt稳得多。

tool描述里把触发条件写死，比如“仅当明确提到天气时才调用”，比加示例管用。

校验步骤必须加，先让模型输出意图再映射工具，能砍掉大半幻觉。

描述里一定要把触发条件写死，比如“仅当用户明确提到天气相关词才调用”，否则模型默认啥都沾边。另外温度调低点，0.1左右试试，高温度反而容易发散。中间加个校验层挺有效的，让模型先输出意图再匹配工具，比直接让它选靠谱。

tool description里把触发条件写死，比如“仅当用户明确提到天气时才调用”，再让LLM先复述意图再选工具，能好不少。

或者加个规则层，用正则拦住明显不该调用的工具，让Agent只做它擅长的部分。

工具描述里加触发条件和反例，比堆few-shot管用，校验层也建议上。

你这问题我太熟了，之前我调Assistant也这样。工具描述别光写“查天气”，得明确触发条件，比如“仅当用户明确提到天气/降雨/温度时调用”，把边界划死。另外我建议加个前置意图识别，先用一个轻量LLM判断该不该动工具，再走Agent，能砍掉大半幻觉。还有，temperature别调高，调低到0.1左右，few-shot放错例比放正例管用。

这问题我太有同感了，之前调一个能查库存和下单的agent也是被工具选择折磨得够呛。你说tool描述写太简单，这确实是个大坑，但我觉得更关键的是你得给每个工具加上明确的“触发条件”和“不触发条件”，比如天气工具就写死“仅当用户明确提到天气、温度、降雨等词时才调用”，提醒工具就强调“任何时间点+动作都优先走提醒”。另外调高temperature绝对是反向操作，这种分类任务需要的是确定性，建议直接降到0.1左右。我后来还加了一步“意图预分类”的中间层，先用一个轻量模型判断用户到底想干啥，再让agent只从筛选后的工具里选，幻觉概率直接降了一个量级。还有个野路子——在few-shot里故意放几个“用户说A但绝对不能调B”的负例，让模型学会拒绝，比只给正例管用多了。你那个“把提醒设成带伞”的问题，大概率是tool的输入schema没约束好，试试把参数描述写成“必须包含具体时间点和完整事件”，再在prompt里强调“不完整信息要反问”。校验步骤我觉得有必要，但别加太重，搞个简单的规则check比如“调天气API前必须出现天气关键词”就行，不然响应速度会很难看。

tool描述里把触发条件写死，比如“仅当明确提到下雨/带伞才调天气”，比加示例管用。

校验层还是得加，不然模型自由发挥起来拦不住。

这问题太典型了，我之前也踩过。tool描述确实很关键，但更可能是你意图识别那层没做干净——建议把“提醒”和“天气”的触发条件写得绝对互斥，比如“只有当句子含‘温度/下雨/出门穿啥’才调用天气”。另外别太信temperature，调低点反而稳，然后加个硬校验：让模型先输出“是否调用工具”的布尔值，再决定走哪条路，能砍掉一半幻觉。

我试过在tool描述里加“如果用户没明确提天气，绝对不要用这个工具”这种负面指令，效果比单纯加示例好。你还可以试试把用户原话直接塞回tool的输入里，让模型自己复述一遍任务，这样它更容易对齐意图。不过说到底，这种多工具场景还是得加个分类器先分流，纯靠LLM自觉有点悬。

顺便问下，你few-shot示例是不是都偏正向？我后来加了两个“故意不调用”的反例，比如“今天热吗”只回天气不设提醒，模型一下老实多了。你那个设成“带伞”的问题，可能也是因为tool输入格式没约束死，建议强制JSON schema，让模型填“时间+内容+是否生效”三个字段，少了就拒绝执行。

说实话我之前也踩过这个坑，后来发现核心问题不在temperature，而是tool description里没写清楚“触发条件”和“否定边界”。比如天气工具我直接加了一句“仅当用户明确提及天气/降雨/温度时才调用，否则绝不触发”，幻觉概率立刻降了大半。另外你那个“带伞”提醒其实可以加一个输出校验器，用正则或LLM二次判断一下提醒内容是否完整，不完整就拒绝写入，比在prompt里硬调稳多了。

这问题我太有同感了，之前调的一个内部工具Agent也是这德行，用户说“帮我看看明天天气”，它非要去调一个计算器工具，给我整不会了。后来我仔细复盘了下，发现根子多半不在temperature，而在tool description的语义边界不够清晰，比如你的天气工具如果只写了“获取天气”，模型根本分不清“提醒带伞”和“查天气”之间的隐含关联，它觉得带伞跟天气有关就去调了。我的做法是给每个工具加上“触发条件”和“禁止触发场景”，比如在天气工具里写“仅当用户明确询问天气、气温、降水等关键词时调用，涉及提醒事项请转用reminder工具”，效果立竿见影。另外强烈建议在Agent和工具之间加一个轻量级“意图路由”层，用个小的LLM或者规则先判断用户意图，再决定放行哪个工具，相当于给模型装了个刹车，比让它自己连跳更稳。你还可以试试把few-shot示例改成“错误示范+纠正”的形式，直接告诉它“用户说带伞提醒时，不要调用天气API，正确动作是创建提醒”，模型对负例的学习往往比正例更敏感。最后提醒下，如果工具返回结果和用户原意对不上，可以加个简单的“结果校验”步骤，比如提醒工具返回后让模型确认一下“是否创建了带时间和地点的提醒”，不对就让它重新生成，成本低但能兜底。

温度调高反而会让工具选择更随机吧，我一般是降到0.2左右再配合强约束的prompt。你试试在tool描述里直接写明“仅当用户明确提到天气时调用”，比一堆示例管用。另外中间校验挺值得加的，我习惯让agent先输出意图再选工具，相当于多一层把关。提醒内容无效的问题，可以给提醒工具加个参数校验，比如非空且长度大于2，不然就返回错误让agent重试。

我之前也踩过这个坑，后来发现核心问题多半在tool的description上，得像教新同事一样写清楚“什么时候用、什么时候绝对别用”，不然模型真会自由发挥。另外建议在prompt里加个硬性规则，比如“除非用户明确提到天气，否则禁止调用天气API”，这种负向约束比few-shot管用得多。中间校验步骤我觉得挺必要的，至少对关键参数做个格式校验，能把“带伞”这种无效内容拦下来。你现在这个情况，temperature调低点反而靠谱，高temperature会让工具选择更发散，不是好方向。

这问题我也踩过坑，tool描述真别偷懒，把触发条件写死，比如“仅当用户明确提到天气相关词时才调用”。另外加个规则层做二次校验，让模型先输出意图分类再选工具，比直接让它调API稳得多。温度调低点，0.1左右试试，高温度容易发散。

工具描述里把“提醒”触发词写死试试，比如“带伞”必须关联提醒字段，不然模型老往天气上带节奏。

可以先加个规则校验层，让模型只输出意图和参数，匹配不到工具就默认拒绝调用，别让它自由发挥。

我最近也踩过这个坑，tool的description真得抠字眼，比如“只用于查询当前天气，不包含预报和提醒功能”这种明确边界，比写一堆场景示例管用。另外temperature别调太高，0.2左右更稳，我试过降到0.1之后幻觉少了大半。中间校验的话，可以加个简单的意图分类器或者规则，先判断用户有没有提到“天气”这个词再放行工具调用，成本低但效果挺明显的。你那个“带伞”的提醒，可能是系统把“伞”关联到了下雨，所以误触了天气API，建议在提醒工具的描述里强调“只处理时间和事件，不推断天气”。

说实话你这个问题我太有共鸣了，之前搭类似Agent的时候也被工具幻觉折磨得够呛。我觉得核心问题不在temperature，那玩意儿调高了反而更容易乱飘，你试试把它降到0.1-0.2，让模型更“保守”一点。tool description确实很关键，我后来把每个工具的描述都改成了“当用户明确表达XX意图时才调用，否则绝不调用”这种带否定条件的写法，效果立竿见影。另外你提的中间校验步骤我觉得很可行，最简单的做法是在调用工具前加一个LLM判断节点，让它先输出“用户意图是提醒还是查天气”这样的结构化JSON，再决定走哪条路，相当于给Agent加了个刹车。few-shot示例别光给正例，我建议混几个错误调用的反例进去，比如“用户说提醒带伞，此时不应该查天气”，模型对负面信号的吸收往往比正面指令快。最后一个小技巧：把提醒类工具的参数设计得更具体，比如要求必须包含日期、时间和文本内容，模型就没法生成“带伞”这种残缺值了。你试试这几个方向，大概率能把抽风率压下去不少。

这问题太典型了，我怀疑根本不是temperature的事，你调低点可能反而更稳。核心原因大概率是tool description写得太笼统，模型分不清“查天气”和“设提醒”的触发边界，尤其“带伞”这种词天然和天气关联，它就直接抢答了。我建议你把每个tool的description改成“只有当用户明确询问天气时才调用此工具，禁止根据提醒内容推断天气需求”这种带否定约束的写法，效果立竿见影。另外别指望few-shot能根治，那只是让模型模仿格式，不是学会判断意图。更靠谱的是在Agent外面套一层轻量的意图分类器，先用一个便宜的模型判断用户到底要干嘛，再决定放行哪个工具，相当于给工具调用加个门卫。我自己试过在prompt里强行加“如果工具调用与用户原话中的动词不匹配，直接拒绝执行”这种规则，也能减少一半抽风。最后提醒一句，如果你用的模型本身指令遵循能力弱，比如某些开源小参数模型，那再怎么调prompt都白搭，趁早换GPT-4或者Claude系列。

tool描述里把触发条件写死，比如“仅当明确提到天气才调用”，比加示例管用。校验步骤也别省，能挡掉一半幻觉。

tool描述确实是关键，我之前也踩过这个坑，建议把每个工具的触发条件写死，比如天气API只认“天气”“下雨”“温度”这些词，提醒工具只认“提醒”“明天下午”这种时间+动作的组合。另外加个路由步骤会稳很多，先用一个轻量LLM判断用户意图属于哪类工具，再让主Agent只处理对应分支，能大幅减少串台。温度别调太高，0.2左右就行，高了反而让模型自由发挥。