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

跟你遇到一模一样的问题，后来我仔细排查发现，LangChain默认的ReAct框架里，工具描述其实比few-shot更重要，尤其当模型拿不准该调哪个工具时，它会倾向于选描述里带“天气”或“提醒”关键词的那个，哪怕语义不完全匹配。你那个例子，我觉得是模型把“带伞”和“天气”做了过度关联，这其实是语义相似度误导，跟temperature关系不大，反而调低一点可能更稳。我自己的做法是给每个工具加一个“使用条件”字段，比如天气工具写“仅当用户明确询问气温、降雨、风速等气象信息时调用”，然后配合一个前置的意图分类Prompt，先把用户请求归类到“查询”“提醒”“邮件”等桶里，再让Agent只从桶内选工具，相当于加了一个硬约束。另外，提醒内容那种无效输出，我试过在tool的输入schema里加正则校验，比如提醒必须包含“时间+事件”，不符合就返回错误让模型重试，这样比事后校验更省心。你现在的tool描述能贴出来看看吗？感觉可能描述太泛了，比如“设置提醒”这种，模型根本不知道“带伞”算不算有效事件。

tool描述确实是个大坑，我之前也栽过，你试试把每个工具的description写成“当用户明确提到XX时才调用，否则绝不调用”这种强约束句式，比单纯写功能管用。另外temperature别调太高，0.2左右就够，太高反而容易发散。还有个土办法，在agent前面加个简单的意图分类节点，把“提醒”和“查询天气”先分流，再进工具调用，能砍掉大半幻觉。你那个“带伞”设成提醒内容的问题，八成是prompt里没强调“提醒内容必须是时间+事件”的结构化格式，加个输出模板试试。

我最近也踩过这个坑，tool description写得像说明书一样反而更容易让模型乱猜。后来我把每个工具的name和description都改成带明确动词和触发条件的短句，比如“search_weather: 仅当用户明确提到天气/温度/降雨时调用”，幻觉率明显降了。另外可以在Agent的system prompt里加一句“所有工具调用必须基于用户原话中的显式意图，不要推测”，比单纯堆few-shot更管用。你那个“带伞”设成提醒内容的问题，我猜是模型把工具参数和用户口语混淆了，试试在工具schema里把参数描述写成“提醒的具体事项，需从用户原话中提取名词短语”，或者干脆加一个校验节点，先让LLM输出意图分类再决定调哪个工具。

我之前也踩过这个坑，后来发现核心问题多半在tool description上，你写得太笼统，模型就分不清“查天气”和“提醒带伞”的边界。建议把每个工具的描述改成“当用户明确表达对天气状况的查询时使用，不要推测天气预报”，同时把参数schema写得像填空一样严格，比如提醒工具的时间字段必须带具体日期。另外加个中间校验层确实管用，让Agent先输出“意图+参数”的JSON，你验证通过了再真正执行，能拦住大部分幻觉。

说实话你这个情况我太熟了，之前用LangChain调Agent也踩过同样的坑，后来发现核心问题往往不在temperature，而是tool的描述太“泛”了。比如“查天气”这个工具，如果描述里只写“查询天气”，模型根本分不清用户是问天气还是需要根据天气做提醒，你得把触发条件写得极其明确，比如“仅当用户明确提到天气/温度/下雨等关键词时才调用，其他情况不要使用”。另外，我建议你在工具描述里加上“负面提示”，比如“提醒工具负责创建提醒，不要包含天气信息，若用户未指定时间则默认当前时间”，这样能大幅减少无效内容。至于中间校验，我试过加一个简单的“意图分类”节点，先让模型判断用户到底想干嘛，再决定调哪个工具，虽然多一步延迟，但准确率提升很明显。还有个小技巧，few-shot示例别只给正常案例，一定要给几个“易混淆”的反例，比如用户说“明天带伞”时，正确行为是设提醒而非查天气，模型见过这种边界情况会稳很多。最后提醒下，别迷信调参，LangChain的Agent本质还是靠LLM的指令遵循能力，把prompt当成代码来写，每个词都可能是触发开关。

我之前也踩过这坑，tool描述太短确实容易让模型瞎猜，试着把每个工具的触发条件写具体点，比如“仅在用户明确提到天气时调用”。另外别全指望模型自觉，加个简单的if校验逻辑，比如提醒内容里带“明天下午”这种时间词就强制走提醒工具。调temperature其实作用不大，反而把输出搞得更飘，降到0.2左右试试。你还可以在prompt里加一句“不确定时先问用户”，能少很多误判。

描述里把触发条件写死，比如“仅当用户明确提到下雨时才调天气API”，校验逻辑丢给模型不如写进工具描述。

我试过加个“意图确认”步骤，让Agent先复述动作再执行，抽风概率能降一半。

工具描述确实关键，把触发条件和参数写死一点，再加个意图识别前置过滤试试。

这问题太真实了，我试过类似场景，tool描述写详细点确实有用，但别光堆功能，得把触发条件写死，比如“仅当用户明确提到天气时才调用”。另外temperature调低点反而更稳，你试过0.1以下没？中间加个校验步骤也靠谱，我后来在调用前加了个意图分类的LLM判断，抽风概率降了不少。

描述里强制加触发条件试试，比如“仅当用户明确提到天气时才调用”。另外可以加个前置意图分类节点，比让模型直接选工具稳得多。

巧了，我前两天也被这问题折磨过，后来发现把tool描述从“天气查询”改成“根据用户请求中的地理位置和时间词，返回对应日期的天气状况”，效果立竿见影。你那个提醒设成“带伞”的情况，大概率是tool的输入schema约束不够，试试把参数类型从string改成enum或者加正则校验。另外可以加个前置的意图分类节点，先让模型判断用户要调哪个工具，再单独路由，能砍掉一半误触发。温度调到0.1以下，few-shot别放太多，反而容易带偏。

这个问题我太有同感了，之前调一个多工具Agent也是被幻觉搞得头大。你提到tool描述太简单，我觉得这确实是核心，LangChain的LLM在选工具时对描述里的动词和名词特别敏感，比如“提醒”和“天气”如果都出现在同一个句子里，它就容易把语义权重搞混。我后来是把每个工具的description改成“仅当用户明确提到XX关键词时才调用”，并且加上了“否则不要调用”这种负向指令，抽风率降了很多。另外temperature真的别调高，工具选择是确定性任务，我都是调到0或者0.1，让模型更保守。还有个土办法，就是在用户输入后面加一个system的校验提示，比如“你只能调用与当前请求直接相关的工具”，相当于给模型一个强制约束。最后，你可以考虑在工具调用前加一个简单的意图分类步骤，用一个小模型先判断是查询还是动作，再让主Agent去选具体工具，这样能隔离很多误判。我现在的架构就是这种分层思路，虽然多了一步，但稳定性提升非常明显。

我之前也踩过这个坑，tool描述太短或者太笼统，模型根本分不清边界。建议把每个工具的触发条件写明确，比如天气工具里加一句“仅当用户明确提到天气或降雨时才调用”，提醒工具则强调“从对话中提取具体时间+事件”。另外temperature别调太高，0.2左右就行，太高会让选择更随机。中间加个校验层确实有用，我是在调用前让模型先输出一个结构化意图，再匹配工具，抽风概率低了不少。

我之前也踩过这个坑，tool description写太长反而容易干扰模型判断，建议精简成“当用户需要时”这种强触发词，然后few-shot里多放几个“用户没提天气但语气像”的负例。另外temperature别调太高，0.2左右就行，太高会让它在工具选择上发散。中间加个校验层挺必要的，我后来就是让模型先输出意图和参数，再用规则卡一道，明显稳多了。

我之前也踩过这个坑，后来发现核心问题不在temperature，而是tool description里没把触发条件写死。比如提醒工具描述里直接加一句“仅当用户明确提到时间+动作时才调用”，天气工具加“仅当用户想查当前或未来天气时才调用”，效果立竿见影。另外我还会在每个工具返回结果前加一个简单的规则校验，比如提醒内容必须包含动词和对象，不然就强制返回“请确认提醒内容”，这样至少不会把“带伞”这种半截话存进去。你可以试试把few-shot改成反例，专门放几个“用户没问天气但差点误调用”的例子，模型会学得更快。

这问题我也踩过坑，tool description真不能写太短，得把触发条件、参数含义、甚至反例都塞进去，比如“仅当用户明确提到天气时调用”。另外temperature调低点反而稳，0.1左右试试，高熵输出更容易乱跳。中间加个校验步骤挺管用，我就在调用前用另一个LLM判断意图和工具匹配度，能过滤掉一半幻觉。你那些few-shot可能太笼统，试试专门给“用户没说天气但Agent调了天气API”这种错误案例做负样本。

说实话你这个情况太典型了，我刚开始玩LangChain的时候也被工具选择的随机性折磨过，后来发现核心问题往往不是模型本身，而是tool的description写得太像“功能列表”了。你试试把描述改成“当用户提到带伞、出行准备、天气相关关键词时使用”，并且明确加上“不要主动调用除非用户明确要求”这种限制性语句，效果会立竿见影。另外temperature别调高，这类任务反而要调低到0.1左右，让模型更保守，减少随机探索。你说的中间校验步骤我觉得很有必要，可以加一个轻量级的意图分类器，先判断用户到底是想查天气还是设提醒，再决定调哪个工具，相当于给Agent加了个“路由器”。关于设成“带伞”这种无效内容，我怀疑是prompt里没告诉它提醒内容需要包含具体时间+动作，你可以在few-shot里补一个反面案例，比如“用户说提醒我带伞，正确输出是明天下午3点提醒带伞，而不是只写带伞”。最后建议你给每个工具加一个required_fields参数，比如提醒工具必须有time和text，如果缺失就让Agent自己反问用户，这样能硬性挡住不少幻觉。

我之前也踩过这个坑，tool描述写得太笼统确实容易让模型瞎猜，你试试把每个工具的触发条件写死，比如“仅当用户明确提到天气或降雨时才调用天气API”。另外提醒那个问题，建议在工具执行前加一步规则校验，比如“提醒内容必须是动词+名词”的格式，不符合就强制重写。还有，temperature调低到0.1-0.2比加few-shot管用，高温度反而放大随机性。你现在的tool描述具体是怎么写的？发出来看看，大概率是关键词没覆盖到边界情况。

说实话tool description影响挺大的，我之前也踩过这坑，比如“提醒”和“天气”功能描述里都带上“明天”这种词，模型就容易混淆。你可以试试把每个工具的description写得更具排他性，比如明确写“仅当用户直接询问天气时才调用”，再加一个“否则调用提醒工具”的兜底规则。另外我建议别只调temperature，试试把few-shot示例改成“错误调用→正确调用”的对比对，模型学得会更快。还有个土办法，在中间加个简单的关键词过滤，比如检测到“提醒”就直接走提醒流程，天气API压根不暴露给模型，这样能根治幻觉。

这问题我太有共鸣了，之前搭类似工具的时候也被幻觉搞到头大。你调temperature和few-shot其实方向对，但关键可能真在tool描述上——描述太短或者关键词太泛，模型就分不清“查询天气”和“提醒带伞”的边界，建议把每个工具的描述写成“当用户明确提到XX词时才调用”这种条件式，甚至把不相关的场景也写进负面示例里。另外我试过在中间加一层意图分类的LLM，先让模型判断用户到底要调哪个工具，再丢给执行器，虽然多一次调用但稳定很多，尤其能拦掉那种“明天下午”被误判成天气查询的情况。还有个土办法，给工具调用加个置信度阈值，低于某个值就反问用户确认，虽然体验会笨一点，但至少不会瞎跑。你设提醒设成“带伞”这个案例，感觉是模型没区分“提醒内容”和“用户意图”，可以在prompt里强行要求输出JSON结构，比如提醒必须带time和text字段，text里只能填动词短语。最后想说，LangChain这层抽象本身就会吞掉很多细节，实在不行就看看底层prompt模板，手写一版再包进去，有时候比调参管用。