一、对比背景：当工具从几个变成几十个

在大模型应用从“聊天”走向“做事”的演进中，工具调用（业界也常称函数调用，Function Calling / Tool Calling）是最核心的机制之一：模型根据用户问题，判断是否需要调用某个工具、传什么参数，再由应用侧执行并把结果回传。

但很多团队在工具数量增长后会遇到同一个瓶颈。一个工具从来不只是“一个函数名”，完整的工具定义通常包含：

• 工具名称；
• 工具描述（description）：告诉模型这个工具什么场景下该用；
• 参数名称、参数类型、参数说明：告诉模型该怎么传参。

单条定义看似不大，几十条累计就是一大段上下文，而且每次请求都要重复注入。除了成本，还有一个更隐蔽的问题——命名相似。以电商业务为例：

getOrder / getOrderDetail / getOrderStatus
getRefundOrder / getRefundStatus

对开发人员来说，这些名字的语义边界很清晰；但对模型来说，等于每一次都要从几十个高度相似的候选里重新做一次选择，误选概率随之上升。选错工具不仅浪费一轮对话，还可能触发错误的业务动作。

围绕这个问题，业界目前有三类典型做法，也就是本文要对比的三个对象：

• 方案A：全量工具注入——把所有工具一次性塞给模型（多数开发框架的默认行为）；
• 方案B：手工拆分领域智能体——按业务域拆分多个智能体，加一个总控路由；
• 方案C：工具检索（Tool Search）——先检索出与当前问题相关的工具子集，再注入模型。一些主流大模型应用开发框架的新版本已经开始内置这类能力。

二、对象定义：三种方案分别是什么

方案A：全量工具注入

把系统里全部工具一次性放进请求的上下文中，模型每次都在完整清单里做决策。这是最直接的方式，开发量最小，工具多了会同时恶化成本与选择准确率。

方案B：手工拆分领域智能体

按业务域切分工具：订单智能体只挂订单工具、售后智能体只挂退款工具、物流智能体只挂物流工具，再在最前面加一个总控智能体（或规则路由）判断问题应该交给谁。本质是用“人工先验”替代“模型在长列表里做选择”，是很多团队早期的优化手段。

方案C：工具检索（Tool Search）

先为工具库建立索引（通常基于工具名称、描述等文本做向量化，或采用关键词检索）。用户问题进来时，先检索出与该问题最相关的 Top-K 个工具，只把这个子集注入模型上下文。模型始终面对一个小而相关的候选集，“选工具”的部分负担从模型侧前移到了检索链路。

三、相同点分析

三种方案虽然形态不同，但存在明显的共同基础：

1. 目标一致：都是为了让模型在正确的时机调用正确的工具，同时控制上下文开销；
2. 都依赖模型的工具调用能力：底层都走“模型决策—应用执行—结果回传”这条公共链路，差异只在“给模型看哪些工具”；
3. 工具描述质量是共同命门：方案A靠描述帮模型选对，方案B靠描述做人工归类，方案C靠描述做检索召回，描述写得含糊，三种方案都会退化；
4. 对最终用户透明：用户感知不到背后的工具供给方式，切换方案不影响交互形态；
5. 都需要统一的注册、校验、执行与异常处理：这是无论选哪种方案都要先做扎实的公共部分。

四、核心差异分析

1. 架构与链路复杂度

• 方案A：单一链路，结构最简单，几乎无额外组件；
• 方案B：N 个领域智能体 + 1 个总控，链路被拉长，多一次路由决策；路由判断错，整条链路就会走向错误分支，且路由规则/路由提示词本身是需要维护的资产；
• 方案C：链路长度与方案A接近，但引入了索引构建与更新环节，多了一个需要运维的检索组件。

2. 上下文开销与响应表现

• 方案A：注入的 token 量随工具数线性增长，几十个工具可能让每次请求多出数千 token，直接推高调用成本，长上下文也会稀释模型对工具细节的注意力；
• 方案B：单轮只注入一个领域的子集，单轮 token 可控，但“总控一轮 + 领域一轮”使整体交互轮次增加；
• 方案C：只注入 Top-K 个工具，token 基本恒定，不随工具总数增长；额外增加一次检索计算（通常耗时在毫秒级），换取上下文大幅缩短，在工具规模大时通常是合算的交换。

3. 选择准确率

• 方案A：候选集越大、命名越相似，误选率越高，这是它被替代的核心原因；
• 方案B：领域边界清晰时准确率高，但跨领域问题是弱项。例如“帮我查一下订单 789 的物流到哪了，顺便看看退款进度”，这类一句话跨两个域的问题，很容易被路由到单一智能体后无法完整处理；
• 方案C：取决于检索质量。描述写得好，召回就准；描述含糊或问题表达口语化，可能漏掉真正需要的工具。它是概率式召回，行为存在波动。

4. 扩展性与维护成本

• 方案A：新增工具零改造，但每加一个都在持续恶化上下文与误选问题，属于“短期最省事、长期不可持续”；
• 方案B：新增业务域要新建智能体并修改路由；工具归属调整（例如一个查询工具既属于订单又属于售后）需要跨智能体复制或重新设计边界，人工成本随规模上升；
• 方案C：新增工具只需注册并更新索引，业务代码基本不动；但引入了“检索质量”这一新的运维维度——描述质量、索引新鲜度都需要持续投入。

5. 确定性与可控性

• 方案B确定性最高：路由规则可以人工审计，出问题能定位到具体规则；
• 方案C是概率式召回，需要靠评测集兜住质量下限；
• 方案A介于两者之间：候选集是确定的，但选择权完全交给模型。

6. 示意性伪代码对比

方案B（人工路由）：

if question 包含 "订单/下单":   routeTo(订单智能体)
elif question 包含 "退款/售后": routeTo(售后智能体)
elif question 包含 "物流/快递": routeTo(物流智能体)
else: 转人工兜底

方案C（工具检索）：

index  = 对全部工具的 name/description 建立向量索引
query  = 向量化(用户问题)
tools  = index.search(query, topK=5)
result = model.chat(问题, tools)   // 只把候选子集注入上下文
execute(result.toolCalls)          // 执行命中的工具

五、对比表格

维度	全量注入（A）	手工拆分智能体（B）	工具检索（C）
架构复杂度	低，单链路	高，多智能体+路由	中，多一个检索组件
上下文开销	随工具数线性增长	单轮可控但轮次变多	基本恒定（Top-K）
误选风险	候选多且相似时高	路由错则整体失败	依赖检索召回质量
新增工具成本	零改造但持续恶化	需调整边界与路由	注册+更新索引
跨域问题	天然支持	弱项，易路由偏	取决于跨域工具能否被同时召回
确定性	中	高，可审计	中低，概率式
适合规模	工具个位数	领域边界清晰的中等规模	几十上百且持续增长

六、典型场景选择

• 工具总数少（例如不超过十个）：方案A完全够用，此时引入检索组件属于过度设计，反而增加排查面；
• 领域边界天然清晰、对行为确定性要求高（如风控、生产操作类场景）：方案B更合适，人工路由可审计、可灰度、可回滚；
• 工具几十上百且持续增长、用户问题经常跨域、希望保持单入口：方案C更适合，扩展成本近似恒定；
• 混合模式：把高频核心工具常驻注入，长尾工具走检索，兼顾确定性与扩展性，是工程上常见的折中。

七、选型建议（条件化）

• 如果当前工具数量不多、token 成本占比可控、误选率尚可接受，不必急着迁移，先优先把工具描述写好——这能同时改善三种方案；
• 如果误选已成为质量瓶颈且工具还在继续增加，优先评估方案C，并配套建设评测与兜底；
• 如果业务有强审计诉求、路由必须可解释，可保留方案B的骨架，在领域内部叠加检索；
• 如果团队不想自建检索、索引与评测链路，也可以评估托管型智能体开发平台（例如百度智能云提供的智能体相关服务）在工具注册、管理与调用层面的托管能力，把基础设施维护交给平台，团队专注工具实现质量本身。

八、迁移与使用注意事项

1. 描述质量先行：迁移前重写 description，写清“什么问题该用、什么时候不该用、与相似工具的区别”，这既是模型决策依据，也是检索召回依据；
2. Top-K 的权衡：K 太大退化为全量注入，K 太小容易漏召回，建议从较小值起步，用评测数据驱动调整；
3. 设计兜底策略：核心工具常驻注入；检索置信度低时回退到扩大 K 值或人工路由，避免“模型无工具可用”；
4. 建立回归评测集：沉淀“历史问题 + 正确工具”的标注样本，持续度量选择准确率，防止迁移后悄然退化；
5. 索引与工具同步：工具上下线要触发索引更新，否则会出现“新工具模型看不见”的隐性故障；
6. 补齐监控指标：工具命中率、误调用率、无工具可用率、平均注入 token 数，都应该有看板与告警；
7. 渐进式迁移：先在单个领域智能体内部替换为检索，验证稳定后再逐步合并智能体，避免一次性结构性改造；
8. 安全边界不放松：工具子集注入只是提示词层面的收敛，真正的权限校验必须保留在执行层强制执行，不能因为“模型没看见这个工具”就省略服务端鉴权。

九、总结

三种方案回答的其实是同一个问题：如何把对的工具、在对的时机、以对的开销交给模型。全量注入胜在简单，败在规模；手工拆分胜在确定可审计，败在路由维护与跨域短板；工具检索胜在扩展成本近似恒定，代价是引入检索质量这一新的不确定性。决策主线可以归纳为四问：工具规模会不会继续涨、领域边界是否清晰、对确定性的要求有多高、团队愿意承担多少自建维护成本。把这四问想清楚，选型自然浮出水面。