大模型如何选择正确的工具？

简化版

工具选择本质是受约束的路由：根据用户意图、当前状态、工具适用条件、权限、成本和风险，决定不调用、调用哪个或先澄清。不要把几百个相似工具全部塞给模型；先由策略和检索筛出候选，再让模型在清晰、互斥的工具契约中选择。执行前仍要验证参数、权限和前置条件，选择结果不是授权。

详细版

工具描述要写能力、输入、适用与禁止场景、成本和副作用，而不是只有函数名。路由可分两级：确定性策略先过滤无权限、地域不符和高风险工具，语义检索选出 Top-K 候选，模型再输出工具或 no_tool/need_clarification。

request + task state
 -> policy filter
 -> candidate retrieval
 -> LLM selection + arguments
 -> precondition/permission validation
 -> execute or clarify

相似工具应减少重叠或设显式判别字段，例如“查实时库存”与“查历史销量”。评测不仅看工具名准确率，还看不该调用时的克制、参数正确率、澄清质量、端到端成功率、成本和危险调用拦截率。混淆矩阵能定位哪些工具描述边界不清。

完整版教学

一、工具选择不是关键词匹配

用户说“看看这个订单”，可能只是查询，也可能随后退款。模型需要结合当前任务、已有信息和用户权限判断；包含“退款”一词也不代表应该立刻调用退款接口。

正确决策空间至少包括调用某工具、不需要工具、信息不足需澄清、权限不足需拒绝。若协议强迫每次选一个工具，模型会产生不必要甚至危险的调用。

记忆钩子：选择工具先判断“要不要动外部世界”，再判断“哪种能力最匹配”。

二、工具契约决定可区分性

工具名只是标签，描述要明确它解决什么、前置条件、输出、是否有副作用和不适用情况。两个工具边界重叠时，模型很难稳定选择。

工具	适用	不适用
get_live_stock	当前可售库存	历史趋势
query_sales_history	一段时间销量	当前库存承诺
create_refund	已确认订单退款	仅查询退款政策

参数 Schema 使用清晰枚举和单位，避免一个自由文本字段承载多个含义。

三、候选工具要先过滤再检索

一次暴露 300 个工具会增加 token、选择混淆和攻击面。策略层先删除当前身份无权使用、地域不匹配、状态前置条件不满足的工具；再按意图检索少量候选。

假设每个工具定义平均 150 token，300 个需 45K token；筛到 8 个仅约 1200 token。节省的不只是费用，还降低相似描述之间的注意力竞争。

检索必须有高召回，真正工具若没进入候选，后续模型无法选中。低分时应回退到更大候选集或澄清。

四、选择前先识别缺失信息

调用工具所需关键参数缺失时，应询问用户或从可信状态获取，不能猜。用户说“给张伟发报告”，通讯录有三位张伟，应先澄清收件人。

可以把工具参数分为模型可抽取、系统可信注入、必须用户确认三类。租户 ID 由认证上下文注入，主题可由模型生成，真实收件人与金额需确认。

澄清问题只问影响选择或风险的缺口，避免一次抛出所有可选字段。

五、选择不等于获得执行权

模型选择 delete_file 并填好路径后，网关仍要检查该路径属于任务目录、调用者有删除权、动作是否需审批。工具选择器只是提出候选意图。

高风险工具可以要求绑定动作参数的审批令牌；参数改变后旧批准失效。模型也不能通过构造工具名或 URL 调用未注册能力。

把权限放在执行层，可使提示注入即使影响选择，也难以突破实际边界。

六、错误结果要反馈可行动信息

工具选择错了时，简单返回“失败”容易导致原样重试。适配层应区分工具不适用、参数缺失、权限拒绝、资源不存在和瞬态故障。

若工具返回 NOT_APPLICABLE: order is unpaid，模型应改为解释无法退款，而不是换另一个退款接口。只有真正瞬态错误才有限退避重试。

反馈中可列出允许的恢复选项，但不能泄露未授权工具和资源详情。

七、多工具计划要考虑依赖

有些请求需要先查询订单，再根据状态决定退款；并非两个调用都能并行。工具选择应结合计划状态和前序 Observation，避免在事实未知时提前执行写操作。

get_order -> if paid and refundable -> request approval -> create_refund

独立的多来源搜索可以并行，但共享写资源或存在数据依赖时必须排序。调用 ID 和步骤 ID用于关联并行结果。

八、评测需要包含“不调用”样本

若测试集每题都需要工具，模型会学会过度调用。应加入纯知识问答、缺信息、越权请求、不可用工具和需要澄清的样本。

200 个用例中，160 个需要工具。模型对其中 144 个选对，对 40 个不应调用样本却误调 12 个：需要工具的召回是 90%，但克制准确率只有 28/40=70%。两者都必须报告。

再看参数准确、端到端成功、平均候选数、决策 token 和危险调用被网关拦截次数。

九、常见误区与追问

• 误区：工具越多，模型能力越强。 候选过多会增加成本、混淆和攻击面。
• 误区：工具描述写功能即可。 还需适用条件、禁止场景、副作用和关键差异。
• 误区：模型选择工具后可以直接执行。 权限、参数、前置条件和审批必须由网关校验。
• 误区：信息不全时先调用再说。 高风险参数不能猜，应澄清或读取可信状态。
• 误区：评测只看选对工具的比例。 还要测不调用、澄清、参数和端到端结果。
• 追问：候选 Top-K 怎么定？ 在验证集权衡正确工具召回率、混淆率和 token 成本。
• 追问：相似工具总混淆怎么办？ 重划边界、合并工具或增加显式路由字段，而不是只堆示例。
• 追问：如何防提示注入诱导调用？ 外部文本标记为数据，执行层实施最小权限和审批。

十、加强记忆

工具选择记住“先过滤、再召回、可澄清、后校验”：策略层按权限和状态删除不可能工具，检索层缩小候选，模型在清晰契约中选择工具、拒绝或澄清；执行前网关重新检查参数、前置条件和审批。评测既看选对，也看不该调用时能否克制，最终以端到端成功与风险为准。

项目实战落地

项目里怎么做的

《AI Agent 智慧医院智能导诊就诊系统》的分诊 Agent 在 6 个工具里自己选：患者档案、既往就诊、症状标签检索、科室查询、医生排班查询、医学知识库检索。选得准不准，项目在三处下了功夫：

• 说明决定选不选：工具说明存在 mcp_tool.description，原样发给模型。症状标签检索如果只写「检索症状标签」，患者说「胸口闷」时模型不知道该不该调；写成「按患者主诉里的症状关键词检索症状标签库，返回匹配到的科室与权重，命中危急征象时会带 is_red_flag 标记」，模型就知道什么时候用、返回里看什么；
• 只给启用的工具：每次分诊按 status = '启用' 现查表构建工具池，模型看不到停用的工具；
• 查不到时给出下一步提示：主诉是一整句口语（「肚子胀痛吃一点就饱」），整句模糊匹配经常落空，症状检索先按空格和中文标点拆词、逐词查、按标签 ID 去重；一个都没命中时，返回里带上标签库收录的规范词和同义词，引导模型换词再查一次；
• 一轮一轮地选：chatWithTools 每一轮把完整历史和全部可用工具发给模型，模型不再请求工具即结束，典型路径是症状标签 → 科室 → 排班 → 给出建议。

为什么这样取舍

• 说明存表：模型选工具只看说明文字，改说明和调 Prompt 是同一类工作，存表才能改完下一次执行就验证。
• 空结果带提示：患者说的是口语，标签库收录的是规范词，把规范词和同义词列给模型，引导它换词再查一次，而不是让整句口语反复落空。

面试官还会追问

• 模型调用医生排班查询时没传日期，工具怎么保证一定查得到真实有号的排班？
• 判断模型是不是在空转，为什么要比对工具的入参，而不是只看同一个工具调了几次？

学完《AI Agent 智慧医院智能导诊就诊系统》，上面这些追问你都会迎刃而解。