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

tool描述确实很关键，但更可能是你的prompt里没给模型“先判断再调用”的强制路径。我建议把每个tool的description写成包含触发条件和反例，比如“仅当用户明确提到天气时才调用，提到提醒时绝不调用”。另外加一个“意图路由”步骤，让模型先输出结构化意图，再决定调用哪个工具，能大大减少乱选。温度调低到0.1左右通常更稳，few-shot可以保留但别太多，容易让模型过度模仿。

tool描述确实关键，把触发条件写死成“仅当用户明确问天气”，能挡掉一大半瞎调用。

我试过加个预分类步骤，先判断意图再选工具，比堆示例管用多了。

这问题太典型了，我当初也被坑过。你调temperature和加few-shot方向没错，但大概率是tool description写得太笼统，模型分不清“查询天气”和“提醒带伞”的边界。建议把每个tool的描述写成“当用户明确提到XX关键词时才调用”，比如天气那个必须出现“天气”“气温”“下雨”才触发。另外加个中间校验层确实有用，我是让模型先输出意图JSON，再根据意图去匹配工具，基本杜绝了乱选。试试看，比单纯改prompt稳得多。

tool描述太简略确实会让模型瞎猜，把每个工具的触发条件写具体点能好不少。另外加个校验节点拦截明显不合理的调用也挺管用。

我之前也踩过这个坑，核心问题多半不在temperature，而在tool description和意图路由。建议把每个tool的描述写得更“排他”，比如天气那项明确加一句“仅当用户明确提到天气/温度/降雨时才调用”，提醒则强调“识别时间+动作”。

另外别依赖模型自觉，可以加一层轻量校验：用LLM先输出一个结构化意图（intent+params），再根据intent白名单去映射工具，幻觉会少很多。few-shot确实有用，但别放太泛的例子，最好直接贴你实际翻车的那几条case。

还有个小技巧，把“不做什么”写进system prompt，比如“不要将‘带伞’作为提醒内容”。我这么调完，成功率从60%升到了90%左右，你可以试试看。

这问题太真实了，我当初也卡在这。tool描述确实关键，但光写清楚功能不够，得把“什么时候别用”也写进去，比如天气工具里加一句“仅当用户明确提及天气或降雨时才调用”。另外temperature调低点反而稳，0.1左右试试，太高它容易自由发挥。还有个小技巧，在prompt里加个“先判断意图再选工具”的硬性规则，比堆few-shot管用。你那个“带伞”设成提醒内容，大概率是解析参数时格式没约束死，试试给提醒工具加个JSON schema强制字段类型。

这问题太典型了，我最近也被工具描述坑过。你试试把tool的description写得更“刻薄”一点，比如明确写“仅当用户提及降水概率或天气状况时才调用，否则绝不使用”，比单纯加few-shot管用。另外建议加个“意图预判”步骤，先用一个轻量模型把用户请求分类成“查询类”还是“操作类”，再决定走哪条工具链，能砍掉大半幻觉。温度调太低反而会让模型在边界情况瞎猜，0.2左右就行。

工具描述里直接加“仅当用户明确提到天气时才调用”，比调参管用多了。再不行就加个规则校验，拦截明显不对的调用。

tool描述确实很关键，但我觉得问题核心不在temperature，而是你缺少一个“意图路由”的显式步骤。我试过在LLM和工具之间加一个轻量分类器，先判断用户到底要调哪个功能，再传参，效果立竿见影。另外提醒动作的实体提取最好单独做一步，别让模型直接输出完整tool_call，否则“带伞”被当成提醒内容太正常了。你可以试试把每个工具的描述改成“仅当用户明确提到XX词时才调用”，并且加一个“不调用任何工具”的默认选项，这样能压掉不少乱选。

Tool描述和few-shot都得加，尤其要写明“仅在用户明确要求天气时调用”，再让模型先输出意图再选工具。

说实话你这个情况我太熟了，之前我调一个订餐Agent也这样，用户说“帮我看看附近有啥吃的”，它直接去调了支付API，给我整不会了。我觉得问题大概率不在temperature上，反而调低点可能更稳，因为温度高会让模型更发散，更容易脑补出“用户可能想问天气”这种多余意图。工具描述确实得写细，别光写“查天气”，要写清楚“仅当用户明确提到天气、温度、降雨等词时才调用，否则绝不调用”，这种否定式约束比正向描述管用得多。另外我强烈建议你加一个中间校验层，让Agent先输出一个“意图JSON”比如{工具名，参数，置信度}，你先拿这个去跟用户原话做一次规则匹配，匹配不上就直接拒绝调用，而不是让模型直接跳到执行。few-shot示例别放太多，三五个就够了，但每个例子都要故意放一个“看起来像但实际不该调”的陷阱案例，比如“明天带伞”这种，模型学这种边界比学正例快。最后提醒你检查下提醒工具的参数定义，是不是把“内容”和“时间”混在一个字段里了，模型就容易把“带伞”当成内容塞进去，拆开成两个必填参数会好很多。

工具描述里得写清楚触发条件，比如“仅当明确询问天气时调用”，再加个提醒内容的格式校验能稳不少。

把tool描述写具体点，比如提醒就强调“只设时间+事项，不查天气”，再在中间加个意图分类步骤挡一下。

把tool描述里加上“仅当用户明确要求天气时才调用”，再在system prompt里加个决策规则试试，比堆示例管用。

工具描述改成触发条件+反面例子，比如“仅在用户明确问天气时调用”，能少一半幻觉。

这问题我太有同感了，之前做类似的agent也被工具幻觉折磨得够呛。你提到tool描述简单，这确实是个关键点，但我觉得更核心的是模型对“意图”和“工具参数”的边界理解不够。比如“明天下午提醒我带伞”，它可能把“带伞”当成了提醒内容的实体，却没意识到“提醒功能”本身就隐含了时间解析，根本不需要碰天气API。我建议你把每个工具的description写成“触发条件+执行动作+典型输入示例”的格式，尤其要强调“当且仅当用户明确提到XX时才调用”，比如天气工具写“仅当用户询问降雨、温度、风力等气象信息时使用，提醒类任务严禁调用”。另外，中间校验步骤很值得加，比如用一个轻量级LLM先做意图分类，把结果结构化后再决定调哪个工具，相当于加个路由层，能过滤掉不少乱选的情况。还有个小技巧，few-shot例子别光给正确案例，也放一两个错误调用被纠正的负样本，模型能学得更稳。温度我觉得不用调太高，0.2到0.3反而更可控，太高容易发散。你可以试试把工具参数schema加上regex或枚举限制，比如提醒时间强制匹配“明天下午”这类格式，无效内容直接拒绝。最后，如果还抽风，考虑用function calling的强制模式，或者干脆把工具数量精简到两个，先跑通再扩展。

你这个问题太典型了，我踩过一模一样的坑。tool description真别嫌麻烦，得把触发条件、参数格式、甚至“什么情况下坚决别用”写清楚，比如天气API里加一句“仅当用户明确询问天气时调用”。另外temperature调低到0.1-0.2比加few-shot管用，模型乱选工具很多时候是采样太随机了。中间校验我觉得值得加，搞个简单的规则层，比如识别到“提醒”关键词就直接路由到提醒工具，能挡掉八成幻觉。最后提醒下，log里把每次tool选择的score打出来，能帮你定位是prompt问题还是模型抽风。

温度调高反而更容易乱选，我建议先回到0附近，把tool description写得更“行为导向”一些，比如“当用户明确提到带伞时，才调用提醒工具”。另外试试在prompt里加一个“意图分类”前置步骤，让模型先判断该不该动工具，再决定调哪个，这样能砍掉不少幻觉。

这问题我踩过差不多的坑，tool描述太简单确实是主因，但更关键的是得把触发条件写死。比如提醒工具里直接写明“仅当用户明确提到时间+事件时才调用，否则不触发”，比堆一堆自然语言描述管用。另外调temperature反而可能让选择更随机，建议降到0.1左右，再加个if-else式的prompt模板让模型先判断意图再选工具。校验步骤我觉得有必要，但别搞太复杂，让模型输出一个“是否调用”的布尔字段就行，抽风概率能降一半。

你这个现象我之前也踩过坑，核心问题大概率不是temperature，而是tool description里没写清楚“什么时候不该调用”。比如天气工具里加上“仅当用户明确提及天气/降雨/温度时才调用”，效果会立竿见影。另外建议在Agent外面套一层规则校验，比如先判断用户意图里有没有“提醒”关键词再决定走哪条链路，比纯靠LLM自觉靠谱多了。