工具候选数量很多时，如何筛选工具、保证选择准确并控制上下文开销？

核心回答

我会把工具选择拆成 权限与可用性过滤、候选召回、重排、完整定义加载、执行校验。工具注册表保存全部能力，但每一轮只把当前任务需要的少量工具定义交给模型；没有召回到正确工具时，再有界地扩大搜索范围。

1. 先缩小合法范围：依据调用者、租户、环境权限和服务状态，确定当前可用工具集合，不能让模型靠提示词自觉排除越权工具。
2. 按当前步骤召回：结合用户目标、任务阶段和上一步结果，按能力名称、关键词、语义和业务标签检索，分类允许重叠。
3. 区分相似能力并重排：比较适用条件、必需输入、读写性质和输出能力，选出能支持当前步骤的候选。
4. 按需加载完整 Schema：候选摘要用于找工具，真正生成调用前要提供完整参数约束，再让模型选择并构造参数。
5. 由执行层再次校验：核对工具身份、当前版本、参数、资源归属和业务状态。检索到一个工具、能看到它的描述，都不等于获得调用授权。

候选数 K、路由层数和是否需要独立重排，要通过召回质量、任务成功率、Token 与延迟预算确定，没有一个适用于所有模型和工具集的“最优工具数量”。

工具目录怎样组织，才能检索得准

工具目录至少要能回答：工具属于哪个服务、做什么、何时适用、需要哪些输入、返回什么、完整定义在哪里、当前版本是什么，以及哪些调用者可以使用。用于权限判断的信息应来自可信配置和服务端规则，不能直接相信工具描述里的“安全”“只读”等自我声明。

描述要保留能区分能力的条件。例如“查询订单状态”“查询物流轨迹”“取消订单”都可能匹配“订单”，但它们的输入、结果与副作用不同。只写“订单相关操作”，检索和最终选择都会变难；压缩描述时也不能删掉这些区别。参数单位、时间范围、枚举和前置条件，则应在完整定义中讲清楚。

以“查一下 O123 发货了吗”为示例：先在该用户有权使用的能力中找订单状态查询。如果返回承运商和运单号，下一步再找物流轨迹查询；不能因为都属于订单域，就把取消订单或创建出库单作为同等候选。下一轮的检索条件要随结果更新，不能只在会话开始时选一次工具。

关键词检索适合明确的系统名、接口名和业务术语，语义检索有助于处理用户措辞与工具描述不一致的情况；可以合并去重后重排。若工具很少、定义短且每次都可能使用，直接提供完整工具集也是合理基线，额外路由未必划算。

分层路由要保留跨类别和漏召回的出口

业务域可以减少搜索范围，但不应把每个工具强行放进唯一类别，也不应把模糊问题一次性锁死在一个域。一个“导出客户本月订单”的任务可能同时涉及客户查询、订单筛选和文件生成。

可以先选多个相关域，合并候选，再针对当前步骤重排。若候选无法提供所需能力、模型指出缺少接口，或调用结果暴露了新的依赖，应在同一授权范围内改写检索词、扩展相邻域或增加候选预算。低相似度本身只是一个信号，不能凭未经校准的分数直接断言“没有工具”。

扩展搜索仍要有次数、时间和 Token 上限。确认缺的是用户信息就澄清；确认缺的是已接入能力就说明限制。参数错误应修正参数，权限拒绝应遵守授权边界，不能把所有失败都当成继续扩大候选集的理由，更不能编造工具名或绕过权限调用其他接口。

按需加载发生在哪一轮

一种方式是 Host 在模型调用前筛选：应用先根据任务检索目录，把候选完整定义放进本轮请求。另一种方式是 模型先调用工具搜索或组管理能力：第一轮只看到少量基础工具和发现入口，找到相关能力后，运行时加载完整定义，再进入生成实际调用的决策轮。

AgentScope 的工具组提供按需暴露一组能力的实现；其 2.0.4 文档也把工具可见性与运行时权限检查分别定义。组开关主要控制模型看到哪些定义，不能代替业务系统的资源权限。AgentScope 官方文档

Claude Tool Search 的当前接口也展示了先搜索、再展开完整工具定义的方式。这里有一个容易混淆的细节：defer_loading 控制定义是否进入模型上下文，按该接口约定，完整定义仍需随请求提供给 API。因此，减少上下文 Token 不一定同时减少客户端请求体或目录同步成本；其他实现应核对各自约定。Tool Search 官方文档

无论哪种方式，都应在生成实际调用前加载完整参数定义。不能只给一句摘要就要求模型猜参数，再等未知工具名报错后才补 Schema。常用基础工具可以直接加载，其余按任务发现；已失去作用的定义也应从后续轮次的活动集合中移出。

接入很多 MCP 服务时，还要管理目录更新

原题包含“100 多个工具”“200 多个工具和 Skill”“数千个工具”，也有“100 个 MCP”的问法。这些数量不是同一种口径：一个 MCP 服务可以提供多个工具，Skill 通常还包含操作说明，不能都折算成一个可调用函数。

聚合多个服务时，Host 需要维护可检索目录，并为工具保留可靠的服务标识与工具标识，避免多个服务的同名 search 相互覆盖。MCP 的 tools/list 是工具发现接口，不能自动替代宿主侧的语义检索和路由。

工具定义不必每轮从全部服务重新拉取。可按协商版本和服务端能力处理分页、缓存与列表变化通知，并设置到期刷新兜底；目录缓存与检索索引更新后，再让新定义参与路由。当前规范对发现、调用和访问控制分别作出约定，具体通知机制需匹配实际协商的协议版本。MCP Tools 规范

缓存应包含服务身份、工具版本或目录版本、租户与权限作用域，防止复用其他用户可见的候选或已下线的 Schema。执行时仍需按当前授权和定义核验；在发现与调用之间，权限、业务状态或工具版本都可能变化。

怎样证明准确率提高，同时开销可控

先建立任务样本，覆盖常见工具、低频工具、相似描述、跨域多步任务、模糊请求、无需工具和越权请求。对每个任务标注当前步骤必需的能力，以及可以接受的替代工具，再比较全量加载、规则路由、检索与重排等方案。

观察指标可以分成四组：

• 召回：必要工具是否进入候选，按步骤计算 Recall@K，并检查多工具任务的必要能力是否全部覆盖。只看最终选中的那个工具，会掩盖前级漏召回。
• 选择与执行：选择是否匹配任务、参数是否正确、是否出现多余调用，以及最终任务是否完成。工具执行成功不等于选对了工具。
• 边界与恢复：越权调用是否被阻止，漏召回后扩展是否有效，信息不足时是否正确澄清。
• 总开销：工具定义占用的上下文 Token、路由与加载耗时、端到端 P95 延迟、额外模型费用和搜索重试次数。

优先在召回不明显下降的前提下压缩候选和定义。K 太小可能省了上下文却漏掉关键工具，K 太大又会增加开销与相似工具干扰。采用缓存或增加重排模型后，也要计算完整链路的收益，不能只报告“工具列表缩短了多少”。任务成功口径可继续看如何量化评估 Agent 输出质量或任务成功率。

追问：只压缩工具描述够不够？

不够。描述压缩能减小单个定义的体积，但不能解决工具之间语义重叠、候选漏召回和权限问题。应先把描述写准确，再结合任务筛选和分阶段加载。完整 Schema 中的类型、枚举、单位和必填约束不能为了省 Token 随意删除；参数与权限校验的职责见如何保证工具调用正确、安全地执行。

对应教程

参考资料