企业官网建设流程全解析

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 里明确加入"如果已有信息足够回答，直接回答，不要调用工具"，冗余调用明显减少。

工具选择策略这件事，说到底是在控制权和灵活性之间找平衡。硬编码控制力强但灵活性差，动态决策灵活但难控制。没有银弹，只有根据具体场景做取舍。我的经验是：核心流程用硬编码保底，边缘场景用动态决策兜底，中间用筛选层做缓冲。这个结构在多个项目中验证下来，稳定性和扩展性都还不错。