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

这问题我太熟了，之前搞类似Agent时也是被工具选择坑到怀疑人生。你调的temperature和few-shot其实方向没错，但关键往往在tool描述上，得把触发条件写死，比如“仅当用户明确提到天气或降雨时才调用”，否则模型就容易自由发挥。

另外强烈建议加一道校验层，用另一个LLM调用或者简单规则检查工具参数，像“带伞”这种明显不是有效提醒内容的，直接拦下来重写或者要求用户确认。我当时就是靠这招把幻觉率降了大半。

还有个土办法，把工具的选择改成先让模型输出意图分类，再根据分类映射到具体工具，别让它直接选。虽然多一步延迟，但稳定很多。你可以试试这几个组合，比单调prompt靠谱。

说实话你这问题我也踩过坑，tool description写得太简单确实是主因，模型对意图边界理解模糊就会瞎猜。我后来是把每个工具的description改成“只有当用户明确提到xx关键词时才调用”这种霸道句式，幻觉少了一大半。另外temperature建议直接降到0.1，这种任务需要确定性，不是创意写作。还有个偏方是加一个“无关判断”的output parser，先让模型输出“用户是否提到工具相关实体”，再决定调不调，相当于硬加一道闸门。你试试看，比堆few-shot管用。

说实话你这个情况我太懂了，LangChain的Agent本质就是个“猜意图”的游戏，工具描述写得太短太泛，模型就只能靠猜，肯定容易翻车。我建议你把tool description改成带触发条件的完整句子，比如“当用户明确提到下雨、带伞、天气情况时，才调用此工具，否则绝不调用”，这种强约束比few-shot管用多了。另外temperature别调太高，Agent任务里0到0.2之间比较稳，调高反而让它更“放飞自我”去乱选工具。中间加校验步骤我觉得很有必要，我自己是在tool调用前加了一个LLM做的意图分类器，先判断用户到底是想查天气还是设提醒，再决定走哪个分支，相当于给Agent加了个“闸门”。还有个小技巧，把提醒工具的参数设计成“时间+内容”的JSON格式，并在描述里强调“内容必须是用户明确要求提醒的具体事项”，这样能减少“带伞”这种无效填充。最后，建议你跑个回归测试集，把之前抽风的例子全录进去，每次改完prompt都跑一遍，别指望一次调好，这玩意儿就是反复磨出来的。

说实话你这个情况我太懂了，之前调agent的时候也被工具选择坑得想砸电脑。tool描述确实很关键，但光改描述解决不了根本问题，我后来发现核心是让模型在调用前先做一次“意图确认”——比如加一个router步骤，先让LLM判断用户到底要干嘛，再决定调哪个工具。另外你那个“提醒带伞”的例子，本质是模型把实体抽取和工具调用混在一起了，建议把“设提醒”这个工具的参数拆细，比如要求必须包含时间和事件两个字段，缺一个就拒绝调用，这样能逼模型先想清楚再动手。温度调低反而更稳，0.2左右试试，太高容易发散。还有个小技巧，在system prompt里明确写“除非用户主动提到天气，否则禁止使用天气工具”，这种硬性约束比few-shot管用得多。最后，如果还不行，就上校验层，用正则或者一个小的分类模型先过滤用户输入，把意图识别和工具执行解耦，虽然笨但是绝对可靠。

tool描述确实很关键，我之前也踩过坑，把“设置提醒”写成“在日历中创建事件”后误调用少了很多，你试试把每个tool的用途和触发条件写得更绝对一点，比如“仅当用户明确提到天气时才调用”。另外temperature别调太高，0.2左右就行，高了容易发散。中间加个规则校验层也挺管用的，先让LLM输出意图分类，再根据分类白名单去选工具，能挡住大部分幻觉。

tool描述确实关键，写清楚触发条件和参数格式能少一半幻觉。

我试过在system prompt里加硬性路由规则，比调temperature管用多了。

描述里把触发条件写死，比如“仅当明确提到天气时才调用”，再加个tool选择前的规则校验能稳很多。

tool description写清楚输入输出格式和边界，few-shot里塞几个易混case对比，比调温度管用。

tool描述里明确“仅当用户主动询问天气时才调用”，再加个规则做意图过滤，比单纯堆示例管用。

试试把提醒的tool描述改成“解析时间+事件”，让模型只输出结构化参数，别让它自由发挥内容。

你这个情况我太懂了，tool description写得模糊绝对是主因，模型不知道啥时候该用哪个工具就容易乱来。建议把每个工具的触发条件写死，比如天气API只允许包含“天气”“下雨”“温度”这类词才调用。另外别调temperature，越低越稳，few-shot放两个正反例就够了。中间加个校验步骤确实有用，我后来是自己写了个简单的规则层，先判断用户意图再决定走哪个tool，抽风率明显降了。

这问题我太有同感了，之前搭Agent也踩过同样的坑，后来发现核心不在temperature，而在tool description的“边界感”。你那个天气tool的描述如果只写了“查询天气”，模型就会把“提醒带伞”和天气强关联，我后来在描述里强制加上“仅当用户明确提及天气、气温、降雨等词时才调用”，抽风概率直接降一半。另外中间校验步骤真的有必要，我加了一个简单的规则层，先判断用户意图是“查询”还是“操作”，再决定走tool还是直接回复，相当于给模型加了个安全带。few-shot别贪多，三五个极端案例就够，重点是给反例，比如“用户说记得带伞，不调用任何tool，直接回复‘好的，已记住’”。还有一个偏方，把tool的返回值格式设计得严格点，比如提醒必须是“时间+动作”结构，模型如果生成“带伞”这种空壳，校验层直接打回重生成，比单纯改prompt稳。最后建议你log一下每次错误的调用链，看是不是某个特定描述词在误导，有时候就是一句话的事。

我之前也踩过这个坑，tool描述写得太笼统确实会让模型瞎猜，建议把每个工具的触发条件写死，比如“仅当用户明确提到降雨或天气变化时才调用天气API”。另外你那句“带伞”其实可以拆成两个动作，提醒内容得让模型生成结构化数据，别让它自由发挥字符串。中间加一层校验逻辑挺有用的，我后来用了一个简单的if判断，发现比调prompt管用多了，还能省token。温度调低点反而更稳，0.1左右试试？

我之前也踩过这个坑，后来发现tool描述里把“触发条件”和“参数约束”写清楚比堆few-shot管用得多。比如提醒工具里明确写“仅当用户提到时间+事件时才调用，且事件必须是非天气类动作”。另外加个简单的规则层做预处理，先判断用户意图是否含“天气”“降雨”等关键词，再决定放不放权给模型，抽风概率能降一大截。

温度调高反而容易放大幻觉，我一般固定0.2以下，靠prompt引导而不是靠随机性。你试试把每个工具的description写成“当且仅当...才调用”，再在系统消息里加一句“不确定时优先询问用户”，应该能稳不少。

还有个思路是给工具加个“自检”输出，让模型在调用前先输出一句“用户要求X，因此调用Y”，这样即使错了也能从日志里看出决策链路。不过最好还是先检查下是不是你的工具返回格式没对齐，LangChain有时候是解析出错导致乱选。

这问题我太熟了，tool description写得越像“人话”越容易带偏，建议把每个工具的目标和边界写死，比如天气API里直接加一句“仅当用户明确要求查询天气或气温时调用”。另外temperature别调太高，不然模型发散起来更容易乱选，0.1-0.3就够用。我后来还加了个轻量的规则层做预筛选，把明显不符合意图的工具直接屏蔽掉，效果立竿见影，你可以试试。

调低temperature真的有用，我踩过一样的坑。不过我觉得核心问题可能出在工具描述太“功能化”了，得像给新手看的那样写清楚“什么场景绝对不能调用”。另外可以试试让模型先输出一个“意图确认”步骤，再决定调哪个工具，相当于加个缓冲，能拦掉不少幻觉。

你提到few-shot，但示例别光给正确调用，得故意放几个“用户说A但绝不能调B”的反例，模型学这个比学正向示例快多了。我自己还会在system prompt里强调“如果意图模糊，优先问用户而不是猜”，这样能把选择压力推回去，抽风概率小很多。

这问题我太有同感了，之前调一个订餐Agent时也差点被工具选择逼疯。你那个“明天下午提醒我带伞”触发天气API，其实根源很可能不是tool描述长短，而是LLM在做意图推理时把“伞”和“天气”的语义关联过度放大了，这时候光加few-shot不一定管用，因为示例覆盖不了所有变体。我后来试了个比较笨但有效的办法：在每个tool描述开头强制加一句“仅当用户明确要求查询天气时才调用”，并且把参数schema里的description写成“如果用户没有提到具体城市，直接返回错误”。另外你提到加校验步骤，这个方向是对的，但别放在Agent主链路里，最好是加一个轻量级router，用另一个更便宜的模型先做一次意图分类，把“提醒”和“查询”硬性分流，再进LangChain，这样就算主模型抽风也翻不了天。还有个小坑，temperature别调太高，工具调用场景我一般锁在0.1-0.2，高了反而容易发散到无关工具。最后提醒一下，检查下你的工具返回格式，有时候模型是因为上一个工具返回的内容太模糊，才被迫乱猜下一个动作的。

tool描述一定要写清楚触发条件和参数格式，不然模型只能瞎猜。建议再加个校验节点，不符合预期就重试一次。

同款问题折磨了我两周，最后发现大概率不是temperature的事，反而是你tool description写得太“功能化”了。模型对“查天气”和“设提醒”的边界理解完全取决于你描述里有没有强调触发条件，比如“仅当用户明确提及天气相关词才调用”。我试过把每个tool的输入schema里加一个必填的“用户意图置信度”字段，让模型自己先输出判断，效果立竿见影。另外你那个“带伞”变成无效内容的问题，本质是模型把提醒内容里的实体和工具参数搞混了，建议在prompt里强制要求它先抽取出“时间实体”和“动作实体”，再映射到工具参数，别让它直接生成。中间校验步骤强烈建议加，哪怕只是个简单的关键词检查，比如设提醒的输入里必须包含“提醒”或“明天”之类的时间词，不满足就返回重写。还有个野路子，把几个工具的调用顺序反着写进few-shot里，比如先给一个“用户说下雨带伞”的例子，让它同时调天气和设提醒，模型会慢慢学会区分主次意图。最后试试把temperature降到0.1以下，这类任务真不需要随机性，反而需要它更“保守”地调用工具。

temperature调低点试试，调高反而容易乱飘，我一般固定0.1-0.2之间。另外tool描述别光写功能，要加触发条件，比如“仅当用户明确询问天气时才调用”，few-shot里也放几个反面例子。

中间校验确实有必要，我后来加了个轻量规则层，先判断意图再放工具，成本低很多，基本能拦住八成的幻觉调用。

你提醒设成“带伞”这种问题，大概率是prompt里没限定参数格式，建议给每个工具加严格的输入schema，让模型只能填结构化字段。

这问题太典型了，我折腾agent的时候也踩过这坑。tool description真得好好写，别就一句“查天气”，得把输入输出格式、适用场景、触发条件全写清楚，模型才不容易乱猜。另外你试试把few-shot里加上“用户没明确要求就别调工具”的负样本，比只给正例管用得多。至于校验那步，我觉得可以加个轻量的规则层，比如“提醒”和“天气”关键词同时出现时才允许调API，能挡掉不少幻觉。

同感，temperature调高只会让模型更放飞，建议你把它降回0.1左右，重点放在tool description的结构化上，比如明确写清楚“当且仅当用户提到降水概率或当前天气时才调用”。另外可以试试在中间加一层意图分类的LLM，先判断用户要触发哪个工具，再让Agent去执行，这样能挡住大部分误触。至于“带伞”这种无效提醒，我猜是参数提取的prompt太弱，给每个字段单独写几条正反例，比堆few-shot管用。

工具描述里把触发条件写死，比如“仅当明确提到天气时调用”，再让LLM先输出意图再选工具。