智能体乱调工具：用 Dify 加 2 道判断前置

Dify 上搭的客服智能体接了 5 个工具：查订单、查物流、改地址、发起退款、转人工。40 个真实任务一测，只有 22 个跑对——13 个调错工具或参数不全，5 个根本不需要调工具却去查了一遍。问题不在模型能力，在缺两道判断。加上「该不该调」「调哪个」两个前置节点后，跑对 36 个。全程 135 分钟。

一句话结论

智能体乱调工具，不是工具描述写得不够细，是流程里没有「先判断再行动」的环节。默认行为是看到任务里有动词就去匹配工具名，于是「我这个单子还能改地址吗」被理解成一次改地址操作，而正确答案是「已发货不能改」。加两道前置判断——这道题要不要动手、动手该用哪个——比继续往工具描述里堆说明有效得多。

这篇解决什么问题

三种情况最常见。一是工具描述越写越长：每个工具的说明从 3 行写到 20 行，乱调依旧，因为模型是在有限候选里挑最近的，描述再细也只是挑得更像。二是把调错工具当参数问题：发现参数缺失就去补默认值，可工具本身选错了，参数再全也没用。三是允许它「试一下」：调错就换一个重试，用户侧看到的是反复确认和明显延迟。

根子是把工具调用当成语言任务。它其实是决策任务：先判定要不要动手，再判定动哪一个。这两步不显式写进流程，模型就会在生成答案的同时顺手把工具调了，顺序和理由都不在控制之内。

开始前要准备什么

• 40 个真实任务，从会话记录里抄用户原话。其中必须包含 8 个「不需要工具就能答」的。
• 每个任务的正确路径：调哪个工具、参数从哪来，或者「直接回答、不调工具」。
• 调用日志：每轮实际调了哪个工具、传了什么参数、返回什么。没有日志等于没测。
• 一条纪律：不该调的调了，和调错同样算失败。多调一次不只是慢，还会把错误信息带进最终答案。

具体怎么做

第一步：任务清单里必须有「不用工具」的题

40 个任务按四类配：直接回答 8 个、单工具一次调用 18 个、多工具有先后顺序 9 个、参数需先问用户 5 个。清单 25 分钟写完。

那 8 个直接回答的是关键对照组，它们长得很像要动手。「我这个单子还能改地址吗」听着是要改，实际只需答一句「已发货的改不了，可以联系快递改派」。清单里如果全是需要工具的任务，测出来永远是「该调」，第一道判断就无从验证。

这是我的 5 个工具（查订单、查物流、改地址、发起退款、转人工）与 40 条真实用户原话。

请帮我配成测试清单，按四类分配：
1. 直接回答、不该调工具的 8 条（要挑那些听起来像要动手、实际只需解释的）；
2. 单工具一次调用的 18 条；
3. 需要两个以上工具且有先后顺序的 9 条；
4. 参数不全、必须先向用户追问的 5 条。

要求：每条标注正确路径（调哪个 / 参数从哪来 / 或直接答），并说明为什么另外几类不适用于它。

第二步：首测，把每次调用都记下来

首测 30 分钟。40 个任务跑完，22 个正确、13 个出错、5 个不该调却调了。出错的 13 个再细分：选错工具 6 个（问物流去查了订单）、顺序错 4 个（先改地址后校验订单状态）、参数缺失 3 个（没问新地址就直接调）。

这个细分决定后面加哪道判断。选错工具是「候选没收敛」，顺序错是「依赖关系没写进流程」，参数缺失是「缺必填校验」。三类混在一起看会得出「模型不稳」这种没法改的结论，分开看每类都有明确改法。

这是 40 个任务的调用日志（含每轮的工具名、参数、返回值）与标准路径。

请帮我归因：
1. 把 13 个失败按「选错工具 / 调用顺序错 / 参数缺失」分类，各举 2 个案例；
2. 单独统计「不需要工具却调了」的 5 个，分析它们被误判的共同措辞特征；
3. 对每类给出对应改法（收紧候选 / 加依赖约束 / 加必填校验）。

要求：不要归因为“模型能力不足”，要给可操作的流程改法。

第三步：加第一道前置判断——这道题要不要动手

在工具节点前插一个判断节点，只回答一个问题：这条消息需不需要调工具。判定标准写成三条可执行的信号：问的是规则或政策（能不能、可不可以、多久到）、问的是当前状态但答案不依赖查询（已发货能否改）、纯粹的情绪表达。命中任一条就直接走回答分支。35 分钟。

这道判断的价值是拦住那 5 个误调。它们有个共同点：句子里有动作动词，但诉求是确认规则。「还能改吗」里的「改」触发了改地址工具，可整句问的是「还能不能」。把「能/不能/可不可以/多久/是否」这类疑问词列为规则询问信号，误调就降下来了。

这是第一道前置判断节点的配置。

请帮我写判定规则：
1. 列出「不需要调工具」的可执行信号（疑问句式、政策类词汇、当前状态类问法），每条给正例与反例；
2. 输出成 IF 条件组的描述，能直接照着在 Dify 里配；
3. 说明边界情况怎么处理：既要查状态又要问规则的混合句，应该走哪条分支。

约束：规则要能落到关键词与句式上，不要写成“判断用户意图”这种无法执行的表述。

第四步：加第二道前置判断——调哪个、参数齐了没

第二道判断负责两件事：在候选中锁定唯一工具，以及检查必填参数是否齐全。做法是先让模型输出一行结构化结论（工具名 + 三个必填参数），参数缺任何一个就转成追问，不进入调用。20 分钟加完。

顺序错的问题也在这里解决：把依赖关系写成硬约束，比如改地址必须在订单状态查询之后。之前是让模型自己安排顺序，它经常先动手后校验。改成「前一个工具返回成功才允许进入下一个」之后，4 个顺序错的案例全部走对了。

这是第二道前置判断的配置位与 5 个工具的参数定义。

请帮我产出：
1. 一个「先输出结论再调用」的输出格式（工具名 + 必填参数 + 缺哪个）；
2. 参数不全时的追问话术，要一次问全、不要来回问；
3. 工具间依赖顺序的硬约束写法（哪个必须在哪个之后，依据是什么）。

要求：参数不全时不允许用默认值兜底，必须追问，因为地址和订单号猜错代价很大。

第五步：重测，把「拒答」也算合格

重测 25 分钟。40 个任务里 36 个正确、3 个仍错、1 个拒答转人工。拒答的那个是参数怎么问都问不出来的任务（用户只给了昵称没给订单号），转人工是正确处置。

判分标准要跟着改：「正确拒答并转人工」算合格，不算失败。如果只按「任务是否完成」判分，团队会倾向于逼模型硬做，而硬做的结果就是编一个订单号去查。剩下 3 个错的是多工具顺序里的边角组合，需要再补两条依赖约束。

这是加了两道前置判断后的重测日志。

请帮我判定：
1. 逐条标为 正确 / 调错工具 / 参数缺 / 正确拒答转人工 / 不该调却调了；
2. 单列「正确拒答」的条目，确认它们是真做不到而不是判断过严；
3. 对仍然出错的条目，指出是缺依赖约束还是候选没收紧。

要求：判分时把“正确拒答转人工”计入合格，避免为了完成率硬做。

实测记录

素材是 5 个工具与 40 条真实会话原话。配任务清单 25 分钟、首测 30 分钟、第一道前置判断 35 分钟、第二道 20 分钟、重测 25 分钟，合计 135 分钟。

结果对比：首测 40 个任务 22 个跑对（55%），其中 13 个调错、5 个误调。加两道前置后 36 个跑对（90%），另有 1 个正确拒答转人工，剩 3 个仍在多工具顺序组合上出错。误调从 5 个降到 0。

要说清一点：这 135 分钟里，改工具描述的只占 10 分钟，其余全花在加判断节点和重测上。原因很直接——首测时把工具描述从 3 行加到 12 行试过一轮，乱调从 18 个降到 16 个，几乎没用。真正见效的是把「要不要动手」变成流程里的一个显式节点。

最容易错的 3 个地方

第一，只拿需要工具的任务去测。清单里没有「不用工具」的对照组，第一道判断就永远测不出问题，上线后遇到规则类提问就会去查一遍。这次 8 个对照组占 20%，是有意加压。

第二，把乱调归因为模型不行。换更强的模型确实能好一点，但顺序错和参数缺失不会消失——这两类是流程没约束，不是理解力不够。这次三类失败各自对应一个改法，没有一条是「换个模型」。

第三，参数缺失用默认值兜底。地址、订单号、金额这类参数猜错的代价远大于多问一句。规则要写成「缺就追问，且一次问全」，否则会出现来回问三轮、用户直接放弃的情况。

可复用的东西

四类配题：直接答 8、单工具 18、多工具有序 9、参数待问 5，对照组必须占两成。

失败三分法：选错工具 / 顺序错 / 参数缺，各对应收紧候选、加依赖约束、加必填校验。

两道前置：先判该不该动手，再判动哪个且参数齐不齐，中间不合并。

拒答算合格：正确拒答并转人工计入通过，避免为了完成率硬编参数。

描述不是主要手段：把工具说明从 3 行写到 12 行，这次只带来 2 个改善，性价比很低。

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接