1. 从写死到放手工具选择策略到底在解决什么问题如果你正在做 Agent 开发大概率遇到过这个场景你精心设计了一个 Agent给它配了五六个工具——搜索、计算、数据库查询、文件读写、API 调用结果跑起来之后发现它要么翻来覆去只用那一个工具要么在明显该用 A 工具的时候偏偏选了 B要么干脆把所有工具都调一遍token 烧得你心疼。这不是模型不够聪明而是工具选择策略本身出了问题。所谓工具选择策略说白了就是 Agent 在每一轮推理中面对一个用户请求和一长串可用工具列表如何决定用哪个工具、按什么顺序用、什么时候不用。这件事看起来简单实际上它是 Agent 架构中最容易被人低估的一环。很多人把精力全花在 prompt 工程和模型选型上却忽略了工具选择策略才是决定 Agent 能不能真正干活的关键。硬编码是最原始的做法在 prompt 里写死如果用户问天气就调天气 API如果问数学就调计算器或者用 if-else 在代码层面做路由。这种方式在工具数量少、场景固定的情况下确实能用但一旦工具超过十个、用户意图变得模糊硬编码就会变成一场维护噩梦。动态决策则是让 Agent 根据当前上下文、历史对话、工具描述和任务目标自主判断该调用哪个工具。它更灵活但也更难控制更容易出现幻觉调用和工具滥用。这篇文章想做的事情很明确把工具选择策略从硬编码到动态决策的演进路径讲清楚把每一步的取舍逻辑拆开把实际开发中踩过的坑和验证过的方案分享出来。不管你是刚接触 Agent 开发的新手还是已经在用 LangChain、Dify、CrewAI 这类框架搭系统的老手都能从中找到可以直接抄作业的东西。关键词里的 MCP、Agent 架构、动态决策快照这些概念我也会在对应的章节里自然展开不堆术语只讲人话。2. 硬编码时代if-else 路由为什么一开始好用后来要命2.1 硬编码路由的典型实现与它的黄金适用期硬编码工具选择最朴素的形式就是在系统 prompt 里写规则。比如你做一个客服 Agent工具只有三个查订单、退换货、转人工。你完全可以在 prompt 里写当用户询问订单状态时调用 query_order当用户表达退货意愿时调用 process_return当用户情绪激动或问题超出范围时调用 transfer_to_human。 这种写法在工具数量少于五个、意图边界清晰的情况下准确率可以做到很高因为规则是确定的模型只需要做意图分类不需要做工具排序。代码层面的硬编码更直接。我见过不少项目用关键词匹配做路由检测到天气就调天气 API检测到股价就调行情接口。这种方案的好处是零延迟、零 token 消耗、完全可预测。在嵌入式场景或者对响应时间要求极高的场景里硬编码路由反而是最优解。你不能说它落后只能说它有它的适用边界。但问题在于Agent 的价值恰恰在于处理开放式任务。当用户说帮我看看最近有什么值得关注的股票顺便查一下我持仓的那几只时硬编码路由就懵了——这句话同时涉及行情查询和持仓查询还隐含了值得关注这个需要判断的语义。你没法用 if-else 穷举所有可能的表达方式。2.2 硬编码的维护成本曲线从线性到指数硬编码路由的维护成本不是线性增长的而是随着工具数量和意图复杂度呈指数上升。我做过一个粗略的统计当工具数量从 3 个增加到 10 个需要处理的意图组合从大约 6 种增加到 90 种以上。你不可能为每一种组合都写一条规则于是规则之间开始冲突优先级变得模糊最后连你自己都说不清某个请求到底该走哪条路。更麻烦的是工具描述和实际行为的不一致。硬编码规则通常基于你对工具的理解来写但工具本身可能在迭代中改变了行为。比如你的搜索工具原本只返回网页摘要后来升级成返回完整页面内容token 消耗翻了好几倍。硬编码规则不会感知到这种变化它还是会无脑调用直到你发现账单异常。还有一个隐蔽的坑硬编码规则会抑制 Agent 的推理能力。当你把所有路由逻辑都写死在 prompt 里模型实际上退化成了一个分类器它不再需要理解任务、规划步骤、权衡工具只需要匹配规则。这在简单场景下没问题但当你希望 Agent 处理复杂多步任务时这种抑制会成为瓶颈。2.3 什么时候该果断放弃硬编码我的经验判断标准很简单当你的工具数量超过 5 个或者用户请求中出现顺便然后帮我看看有没有这类连接词时硬编码就该退场了。前者意味着组合爆炸后者意味着多步推理需求。这两个信号出现任何一个继续用硬编码就是在给自己挖坑。但放弃硬编码不等于完全不要规则。合理的做法是保留一层轻量级的前置过滤比如用关键词或小模型做一次粗筛把明显不相关的工具排除掉再把剩下的工具交给动态决策。这样既控制了 token 消耗又保留了灵活性。这个思路在后面讲动态决策优化时还会展开。3. 动态决策的底层逻辑Agent 到底是怎么选工具的3.1 工具描述的质量决定选择的上限动态决策的核心机制其实不复杂Agent 在每一轮推理时会把所有可用工具的名称、描述、参数 schema 一起塞进上下文然后让模型输出一个工具调用请求。模型选择哪个工具很大程度上取决于工具描述写得好不好。这是最容易被忽视、但影响最大的因素。我见过太多项目把工具描述写成查询数据库这种废话。模型看到这个描述根本不知道这个工具能查什么库、支持什么查询语法、返回什么格式。正确的写法应该像给新员工写操作手册一样这个工具叫什么、解决什么问题、输入参数是什么含义、返回结果长什么样、有什么使用限制。比如不要写搜索工具而要写根据关键词搜索互联网网页返回标题、摘要和链接适合获取实时信息不适合查询结构化数据。工具描述的质量直接决定了模型能否在多个相似工具之间做出正确选择。如果你有两个工具都叫查询一个查订单一个查库存描述里不写清楚区别模型只能靠猜。描述里的每一个字都是在给模型提供决策依据省字就是省掉了模型的判断力。3.2 上下文窗口里的工具列表塞得越多选得越差很多人有个误区工具越多Agent 能力越强。实际情况恰恰相反。当工具列表超过一定长度模型的注意力会被稀释选择准确率反而下降。这就像你给一个人同时递上二十份菜单他反而不知道吃什么。实测下来单次推理中工具数量控制在 10 到 15 个以内选择准确率比较稳定。超过 20 个错误率明显上升。如果你的系统确实需要大量工具正确的做法不是全塞进去而是做分层路由先用一个轻量级分类器把工具缩小到相关子集再让主模型在子集里做精细选择。这个分类器可以是一个小模型也可以是一组关键词规则甚至可以是另一个 Agent。MCP 的出现让这个问题变得更突出。MCP 服务器可以动态提供工具一个 Agent 可能同时连接多个 MCP 服务器每个服务器暴露十几个工具。如果不做筛选上下文瞬间就被工具描述占满了。所以 MCP 场景下工具发现和工具选择必须分开处理先发现有哪些工具可用再根据当前任务筛选出相关工具最后才做选择。3.3 动态决策快照让每一次选择都可追溯动态决策最大的问题是不可预测。同一个请求今天调了 A 工具明天可能调 B 工具你很难复现问题。动态决策快照就是解决这个问题的在每次工具选择发生时把当时的完整上下文——包括用户输入、对话历史、可用工具列表、模型输出的选择结果和理由——全部记录下来。这个快照的价值在排查问题时体现得淋漓尽致。当 Agent 选错工具时你可以回看快照判断是工具描述有歧义、上下文太长导致注意力分散、还是模型本身的能力边界。没有快照你只能靠猜有了快照你能精确定位到是哪一环出了问题。我在实际项目中会把快照存成结构化数据包含时间戳、会话 ID、轮次、候选工具列表、最终选择、模型给出的理由如果模型输出了的话。这些数据积累起来之后还能用来做选择策略的离线评估拿历史快照重新跑一遍看新策略是否比旧策略选得更准。这比在线 A/B 测试高效得多。4. 从硬编码过渡到动态决策的实操路径4.1 第一步把硬编码规则改写成工具描述过渡的第一步不是直接删掉规则而是把规则翻译成工具描述。你原来写的如果用户问天气就调天气 API可以改写成天气工具的描述获取指定城市的实时天气和未来预报当用户询问天气、气温、降水、风力等信息时使用。 这样规则就从代码层面转移到了描述层面模型开始有机会参与决策。这个翻译过程本身就是一次梳理。你会发现有些规则其实是在弥补工具描述的不足有些规则是在处理模型能力不够的情况还有些规则纯粹是历史遗留。翻译完之后你对整个工具集的理解会清晰很多。4.2 第二步引入选择理由输出建立可观测性让模型在调用工具时输出选择理由是提升动态决策质量的关键一步。你可以在 prompt 里要求模型先说明我选择这个工具是因为……再输出工具调用。这个理由不一定要给用户看但一定要记录下来。理由输出的好处有两个。一是迫使模型做更审慎的推理而不是凭直觉选一个。二是给你提供排查线索。当选择错误时理由会告诉你模型是怎么想的你就能判断是描述问题、上下文问题还是模型问题。我见过很多团队跳过这一步结果出了问题完全无从下手。4.3 第三步用快照数据做策略迭代有了选择理由和快照数据你就可以开始迭代了。迭代的方向通常有三个优化工具描述、调整工具列表的筛选逻辑、更换或微调模型。每次迭代后用历史快照做离线评估看选择准确率有没有提升。这里有个经验不要一次性改太多变量。如果你同时改了描述、筛选逻辑和模型准确率提升了也不知道是谁的功劳下降了也不知道该回滚哪个。每次只改一个维度观察效果再决定下一步。这个原则听起来简单但实际执行时很容易被忽略尤其是在赶进度的时候。5. 动态决策的常见翻车现场与修复方案5.1 工具滥用为什么 Agent 总爱把所有工具都调一遍工具滥用是动态决策最常见的翻车方式。Agent 面对一个简单问题却把搜索、计算、数据库查询全调了一遍最后给出一个冗余的答案。这通常是因为工具描述之间边界模糊模型不确定哪个工具能解决问题于是采取广撒网策略。修复方案是明确工具的使用边界和禁用场景。在描述里写清楚这个工具不适合做什么往往比写适合做什么更有效。比如搜索工具的描述里加上不要用于查询结构化数据或已在本地的信息计算器工具加上不要用于简单的心算或单位换算。这些否定性约束能显著减少滥用。另一个原因是模型被训练成了尽量多调用工具。有些框架的默认 prompt 会鼓励模型积极使用工具这在工具少的时候没问题工具多了就会导致滥用。你需要根据实际情况调整这个倾向在 prompt 里明确只在必要时调用工具能用已有信息回答的直接回答。5.2 工具幻觉调用了根本不存在的工具工具幻觉指的是模型输出了一个工具调用但这个工具根本不在可用列表里。这种情况在工具列表很长、或者工具名称相似时特别容易出现。比如你有search_web和search_db两个工具模型可能输出search_internet这种不存在的名称。修复方案有两个层面。工程层面要做严格的校验模型输出的工具名称必须和可用列表精确匹配不匹配就拒绝执行并返回错误信息让模型重试。描述层面要避免工具名称过于相似尽量让每个工具的名称有独特的语义标识。如果两个工具确实功能相近考虑合并成一个工具用参数来区分行为。5.3 选择震荡同一个请求两次运行选了不同工具选择震荡指的是同一个请求在不同运行中选了不同工具。这在 temperature 大于 0 时很常见因为模型输出本身有随机性。适度的随机性没问题但如果震荡导致结果质量不稳定就需要处理。最直接的办法是降低 temperature在工具选择阶段用更确定的输出。但这样会牺牲一些灵活性。更好的办法是在 prompt 里加入决策优先级比如当多个工具都能解决问题时优先选择参数更少、执行更快的那个。这样即使有随机性选择结果也会收敛到更优的选项上。还有一种震荡是因为上下文中的信息顺序影响了模型判断。工具列表的排列顺序、对话历史的呈现方式都可能影响选择。解决办法是固定工具列表的顺序并且在描述里用一致的格式减少无关变量。6. MCP 场景下的工具选择新机会与新麻烦6.1 MCP 让工具动态发现成为可能但也让选择更难MCP 的核心价值之一是工具的动态发现Agent 不需要在启动时就知道所有工具可以在运行时连接 MCP 服务器获取可用工具列表。这让 Agent 的能力可以按需扩展不用把所有工具都硬编码在系统里。但动态发现带来了新的选择难题。传统场景下工具列表是固定的你可以针对每个工具精心写描述、调优先级。MCP 场景下工具列表可能随时变化你没法为每个工具都做精细调优。而且不同 MCP 服务器提供的工具描述风格不一有的详细有的简略模型需要在质量参差不齐的描述中做判断。我的做法是在 MCP 工具接入时做一层描述标准化不管原始描述长什么样都转换成统一的格式包含功能、输入、输出、限制四个部分。这层转换可以手工做也可以用一个小模型自动生成。标准化之后模型的选择准确率会明显提升。6.2 多 MCP 服务器并存时的工具筛选策略当一个 Agent 同时连接多个 MCP 服务器时工具数量可能轻松超过 30 个。这时候全量塞进上下文是不现实的必须做筛选。筛选策略我一般分三步走。第一步是按任务类型粗筛。如果当前任务是代码相关就只保留代码工具服务器提供的工具如果是数据分析就保留数据库和计算工具。这个粗筛可以用关键词匹配也可以用一个小分类模型。第二步是按历史使用频率排序。在同一个会话中已经用过的工具大概率还会再用把它们的优先级提高。这个策略在长对话中特别有效能显著减少选择时间。第三步是按工具描述的相关性做语义筛选。把用户请求和工具描述都做 embedding算相似度取 top-K。这一步计算量稍大但可以用缓存优化相同请求不用重复计算。6.3 MCP 工具的安全边界别让 Agent 拿到不该拿的工具MCP 让工具接入变得容易但也带来了安全风险。如果 Agent 连接了一个提供文件删除或系统命令执行的 MCP 服务器而用户请求被恶意构造可能导致严重后果。工具选择策略必须包含安全过滤层某些工具在特定上下文下应该被禁用不管模型多想调用。具体做法是在工具列表进入模型之前先过一遍权限检查。比如涉及写操作的工具只在用户明确授权时才加入候选列表涉及敏感数据的工具只在特定会话中可用。这层过滤要在工程层面实现不能依赖模型自觉。模型可以被 prompt 诱导但代码层面的权限检查是硬约束。7. 工具选择策略的评估与持续优化7.1 用什么指标衡量选择策略的好坏评估工具选择策略不能只看最终答案对不对因为答案对可能是模型能力强跟选择策略无关。需要专门的指标。我常用的有三个选择准确率选对了工具的比例、调用效率完成任务所需的工具调用次数、冗余率不必要的工具调用占比。选择准确率需要标注数据成本较高适合在关键场景做抽样评估。调用效率和冗余率可以从日志中自动计算适合做持续监控。三个指标结合起来看能比较全面地反映策略质量。如果准确率高但调用次数多说明策略保守如果调用次数少但准确率低说明策略激进。7.2 用离线回放做策略迭代在线 A/B 测试成本高、周期长而且可能影响真实用户。离线回放是更高效的迭代方式把历史请求和对应的快照数据拿出来用新策略重新跑一遍对比新旧策略的选择结果。如果新策略在历史数据上表现更好再考虑上线。离线回放的关键是快照数据要足够完整。如果快照里只有用户输入和最终选择没有当时的工具列表和上下文回放就没法复现真实场景。所以前面强调的快照记录在这里就体现出价值了。我一般会保留至少一个月的快照数据足够做多轮迭代评估。7.3 什么时候该换模型什么时候该改策略工具选择出问题很多人第一反应是换更强的模型。但根据我的经验大部分选择问题不是模型能力不够而是策略设计有问题。工具描述模糊、上下文太长、筛选逻辑不合理这些换模型都解决不了反而增加成本。判断标准是这样的如果模型在简单场景下也选错可能是模型问题如果简单场景没问题复杂场景出错大概率是策略问题。先优化策略策略优化到瓶颈了再考虑换模型。这个顺序能帮你省下不少冤枉钱。8. 我踩过的几个坑和最后想说的第一个坑是过早引入动态决策。我有个项目一开始就上了全动态选择结果调试成本极高因为每次出错都要排查是描述问题、上下文问题还是模型问题。后来退回到半硬编码半动态的混合模式先用规则做粗筛再让模型在子集里选稳定性立刻上来了。所以我的建议是从硬编码开始遇到瓶颈再逐步放开不要一上来就追求全动态。第二个坑是忽视工具描述的一致性。不同人写的工具描述风格差异很大有的用陈述句有的用祈使句有的详细有的简略。模型在面对风格不一致的描述时选择准确率会下降。后来我们制定了描述模板强制统一格式问题就缓解了。这个工作看起来琐碎但收益很直接。第三个坑是没有给模型不选工具的选项。早期我们的 prompt 默认模型必须调用工具结果模型在应该直接回答的时候也硬调一个工具浪费 token 还降低体验。后来在 prompt 里明确加入如果已有信息足够回答直接回答不要调用工具冗余调用明显减少。工具选择策略这件事说到底是在控制权和灵活性之间找平衡。硬编码控制力强但灵活性差动态决策灵活但难控制。没有银弹只有根据具体场景做取舍。我的经验是核心流程用硬编码保底边缘场景用动态决策兜底中间用筛选层做缓冲。这个结构在多个项目中验证下来稳定性和扩展性都还不错。