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

这个问题我最近也踩过类似的坑，tool description写得太简略确实是元凶之一，尤其当多个工具功能有重叠时，LLM很容易混淆边界。比如“查天气”和“设提醒”都和时间、地点相关，如果描述里没明确说“提醒工具只负责创建日程，不执行数据查询”，模型就会跨领域调用。另外temperature调得太高反而会放大随机性，我一般控制在0.1-0.3之间，然后给每个工具加一个“使用条件”字段，比如对天气工具写“仅当用户明确询问天气预报或气温时调用”，few-shot示例里也要覆盖易错的边界情况。不过还有一个容易忽略的点：你的prompt里是否让模型先做意图分类再选工具？我试过在system prompt里加一句“先判断用户请求属于以下哪一类：查询/操作/提醒”，错误率降了快一半。还有就是可以在工具返回结果后加个简单的校验逻辑，比如提醒内容如果只有名词没有时间状语就拒绝执行并让模型重新生成，虽然粗暴但很管用。你试过把tool的input schema定义得更严格吗？比如让提醒工具要求必须含时间参数，不然就报错，这样能逼模型更精准地提取信息。

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

我也踩过这个坑，tool description写得太笼统确实是主因之一。比如你那个“设提醒”的工具，如果描述里只写“设置提醒”，模型很容易把它和“查天气”混淆，尤其是当用户提到“下雨”“带伞”这种天气相关词时。建议把每个tool的description写成“场景+原理+限制”的格式，比如“当用户需要创建日程或定时任务时调用，注意提醒内容必须包含具体时间点，不能根据天气预测自动生成内容”。另外temperature建议调回0.1-0.3，太高会让模型更发散，反而容易“发散”到错误工具。还有一招是加一个简单的“意图确认”步骤，比如在调用工具前让Agent输出一个JSON字段“intent”，然后写个函数校验这个intent是否与用户需求匹配，不匹配就重新生成。不过我自己试下来最有效的还是把few-shot示例做成“错误调用+正确调用”的对比对，让模型记住“用户说带伞但没问天气时，应该只调提醒，不碰天气API”。

tool描述确实得写详细点，把触发条件说清楚，不然模型容易脑补。再就是加个校验逻辑，调用前先让模型确认一下意图。

tool描述太简单确实是常见坑，建议把每个tool的输入输出格式、触发条件写具体点，比如提醒工具明确要求“时间+内容”结构。另外可以加个中间路由层，先让LLM判断用户意图再调具体工具，能减少幻觉。调低temperature到0.1-0.2试试，太高反而容易发散选错。

这问题我太有共鸣了，刚入坑LangChain那会儿也被工具幻觉折磨得够呛。你提到的tool描述太简单确实是常见坑——LLM对工具的理解完全靠那几行字，如果描述里没明确区分“查天气”和“设提醒”的触发条件，它很容易把“带伞”这种关键词和天气API关联起来。我自己的经验是，除了把每个tool的description写得更具体，比如明确说“此工具仅当用户明确提到‘天气’‘气温’‘下雨’等词时才调用”，还可以在prompt里加一条硬性约束，比如“如果用户意图不明确，先调用一个‘意图澄清’工具而不是直接执行”。另外，你提到的temperature调高反而可能加剧幻觉，建议调到0.1-0.3之间让模型更“保守”。还有个偏方是给每个工具加一个“调用前验证”的中间步骤，比如让LLM先输出一个JSON字段检查是否匹配用户原始意图，不匹配就返回重新选择。不过说实话，有时候模型抽风是底层LLM本身的问题，换个更擅长function calling的模型（比如Claude或GPT-4-turbo）可能立竿见影。

tool描述确实很关键，把每个工具的触发条件和边界写清楚能减少幻觉。加个校验步骤也管用，让Agent先确认再执行。

遇到过类似的问题，感觉tool description写得太简略确实会影响模型判断，我后来把每个工具的功能、触发条件和参数限制都写得更具体，像“天气查询仅在用户明确提到‘天气’、‘下雨’等关键词时才调用”，效果好了不少。另外加个中间校验步骤很管用，比如先在prompt里让模型输出一个结构化的“意图+参数”json，再根据这个去调工具，能过滤掉很多幻觉调用。你还可以试试给每个工具加一个“不适用场景”的例子，比如提醒工具里写“不要将‘带伞’这类物品名作为提醒内容”，few-shot里多放几个边界情况。

遇到过类似的问题，后来发现tool的描述里把“提醒”和“天气”的边界写清楚会好很多，比如明确说“天气查询只返回当前或未来天气数据，不处理提醒”。另外可以加个简单的意图分类步骤，让模型先判断用户是不是在问天气，再决定调哪个工具，比直接让它选靠谱。temperature调低一点（0.1左右）试试，太高容易发散。

tool描述确实很关键，得写清楚“什么情况下用/什么情况下千万别用”，比如天气API可以加一句“仅当用户明确询问天气时才调用”。另外温度调低点可能更稳，0.1-0.3试试，太高容易发散。中间加个校验步骤也挺实用的，比如让Agent先输出一个“意图确认”再执行调用，能拦住不少幻觉。

试过把tool description写得更具体点，比如“查询实时天气数据，输入城市名”这种，模型乱选的情况会少很多。另外可以在system prompt里加一句“不要猜测用户意图，只执行明确指令”，有时候能治住它脑补。温度调太高反而容易放飞，我一般设0.1-0.3之间。

加个校验步骤确实管用，我一般会在tool description里写清楚“必须包含关键词才触发”。

遇到过类似问题，后来发现tool描述太简略确实是元凶之一。比如“提醒”的tool里最好写清楚“时间参数必须是标准时间格式，内容参数只接受具体事务名词”，再加个“非天气相关请求不准调用天气API”的硬约束。另外可以在中间加个简单的意图分类步骤，让Agent先判断用户意图再选工具，比直接让LLM自己选靠谱得多。

这个问题我最近也踩过类似的坑，感觉核心出在tool的描述和LLM对意图的边界理解上。你试试把每个工具的description写得更“防御性”一点，比如天气API的描述里明确加一句“仅当用户明确询问天气或预报时才调用，不要猜测天气相关需求”，提醒工具则强调“必须包含具体时间和可执行的动作，拒绝模糊文本”。另外temperature我个人建议调低到0.1甚至0，因为Agent场景需要确定性，太高反而容易发散。还有一个偏门但有效的方法：在系统prompt里加一条“如果用户请求同时涉及多个工具，优先执行时间敏感或明确动作的那个”，这能减少幻觉式乱跳。实在不行就加个中间校验层，用一个小模型先判断意图再路由到对应工具，虽然多了步延迟但准确率会稳很多。你工具描述方便贴出来看看吗？可能问题就出在描述太泛了。

碰到过类似的问题，后来发现确实是tool description写得太笼统导致模型理解偏差。可以试试把每个工具的输入输出格式和触发条件写得更具体，比如天气工具明确加上“仅当用户明确提到天气关键词或查询天气时才调用”。另外我还会在prompt里加一条“先判断用户意图再选择工具”的规则，配合few-shot里故意放几个边界案例，效果会好很多。调高temperature反而容易让模型更发散，建议先降到0.1左右固定一下行为。

我个人感觉tool描述太短确实容易翻车，建议把每个工具的场景边界写清楚，比如天气API只处理“未来24小时具体地点”这种请求，提醒就只认“时间+动作”结构。另外加个分类器先判断用户意图再路由到对应工具，比直接让LLM选靠谱得多。调temperature其实影响不大，核心还是把prompt里的约束写硬一点。

这问题我太有同感了，之前调一个订餐Agent，用户说“帮我看看附近有啥辣的”，它直接去调了支付接口，给我整不会了。你提到的tool描述确实是个大坑，我后来是把每个工具的描述都改成了“当用户明确提到XX关键词时才调用”，比如天气工具就写“仅在用户询问气温、降雨、出行建议时使用，其他意图一律不触发”，效果立竿见影。但光靠描述还不够，temperature建议直接压到0.1甚至0，这玩意儿不是创意写作，随机性越低越稳。你加few-shot的思路对，但例子得包含“相似意图但不同工具”的对比，比如“明天带伞”和“明天天气”，让模型看到区分边界。另外我强烈建议你在工具调用前加一个意图分类的中间层，哪怕用个简单的if-else规则先过滤一遍，比如检测到“提醒”就只走提醒工具，不把选择权全交给LLM。最后提醒一点，检查一下你的工具返回值格式，有时候模型是因为看到了空结果才被迫乱选，给个默认“无匹配”的反馈也会帮助它收敛。你可以先试试把描述细化+温度调低，大概率能解决八成问题。

我之前也踩过这个坑，核心问题多半不在temperature，而是tool description里没写清楚“触发条件”。比如天气工具得写明“仅当用户明确提到天气或出行建议时才调用”，不然模型很容易靠语义联想误判。另外建议把“设提醒”这类动作拆成两个工具，一个负责解析时间，一个负责提取内容，中间再加个校验节点，让模型先输出JSON再决定是否执行，能砍掉大半幻觉。你可以试试把few-shot例子换成“不该调用”的反例，比正向示例管用得多。

我之前也踩过这个坑，核心问题多半出在tool描述和用户意图的匹配粒度上。你试试把每个工具的描述写得像“触发条件+反面例子”的结构，比如天气API就明确写“仅当用户提及天气、温度、降雨等词时才调用”，比单纯说“查询天气”管用得多。

另外temperature别调太高，0.2左右就行，这玩意儿不是创意写作，越低越稳定。还有个小技巧，在prompt里加一句“先判断用户是否明确要求某个工具，否则不要执行任何调用”，能压掉不少幻觉。

至于提醒内容设成“带伞”，我怀疑是模型把用户原话当参数直接填了，建议在tool定义里加个“提取核心动词+时间”的说明，或者干脆在中间加个校验节点，让LLM先输出一个JSON结构，你代码里检查下字段再真正执行调用。

我之前也被这个坑过，tool description写得太笼统确实容易让模型瞎猜，建议把每个工具的触发条件写明确，比如天气API就强调“仅当用户明确提到天气/降雨/温度等关键词时才调用”。另外你提到的中间校验挺靠谱，可以在调工具前加一个简单的意图分类节点，硬规则过滤掉明显不相关的调用。还有个小技巧，few-shot里尽量放一些边界案例，比如“明天带伞”这种不带天气词的提醒，模型见过类似正例后误判率会降不少。