为什么工具数量会影响 Agent
接入 MCP（Model Context Protocol）时，工具不仅是一个名称，还包括用途说明、参数类型、必填字段、枚举值和嵌套 JSON Schema。只要宿主把工具暴露给模型，这些定义通常就会成为本轮模型输入的一部分。
当工具只有几个时，全量注入比较简单；当商城、CRM 或 SaaS 后台积累了几十乃至数百个接口，问题会逐渐显现：
- 无关 Schema 占用输入 Token，也挤压对话历史、业务规则和检索内容；
- 名称和参数相似的工具更容易被混淆，例如“申请退款”和“审批退款”；
- 每个多步任务都要重复在全量工具中选择，延迟和调试成本随之增加；
- 工具描述如果没有清楚区分副作用和权限，误调用的风险会扩大。
因此，问题的核心通常不是 MCP 能不能承载很多工具，而是每一轮应该向模型展示多少工具。更大的上下文窗口只能延后压力，不能替代工具治理。
先区分四个概念：目录、授权、活动工具和执行
设计按需加载前，建议把工具生命周期拆成四层：
- 能力目录：系统登记的完整工具集合，包含名称、描述、参数和版本信息。它服务于治理，不等于本轮要交给模型的列表。
- 授权能力面：经过租户、用户身份、角色、路由和 scope 裁剪后，当前请求理论上可以使用的集合。检索只能在这里进行。
- 活动工具集：本轮根据用户意图筛出的少量工具，模型可以直接看到完整 Schema。
- 实际执行：模型提出调用后，服务端再次做参数校验、业务鉴权、审批、限流和审计。
这四层不能合并。尤其要注意：搜索到某个工具，不代表用户已获授权；工具出现在活动列表中，也不代表可以跳过执行侧的最终校验。
一套可落地的按需加载流程
第一步：按场景收窄路由
不要让每个 Agent 默认连接整个后台。可以先按工作区或业务场景划分工具源，例如客服工作区只开放客户、订单和工单相关能力，财务工作区再增加发票和对账能力。路由层使用明确的 allow scope，先去掉场景外的工具。
这一步适合做确定性过滤，优点是容易审计，也能在请求进入模型前减少暴露面。
第二步：建立轻量目录
在完整 Schema 之外维护一份轻量索引，至少包含：
- 稳定的工具 ID、业务域和动作类型；
- 面向用户意图的简短描述；
- 读/写/删除等副作用等级；
- 所需 scope、租户范围和审批要求；
- 参数摘要、版本和废弃状态。
轻量目录用于候选发现，完整 Schema 只在工具入选后加载。规模较小、命名规范的系统可以从关键词和字段检索开始；当用户表达与工具名称差异较大时，再增加语义检索，并保留可解释的文本回退。
第三步：先给模型少量活动工具
首轮只注入与当前任务最相关的一小组工具，而不是固定截取列表前几项。候选排序可以综合业务域、用户意图、权限、读写风险、工具版本和历史调用结果。
这里的目标不是追求一个固定数字，而是让模型在足够完成当前步骤的前提下，面对更小、更互斥的选择空间。对于可能产生写入、扣款或删除的工具，发现阶段可以只返回摘要，待用户明确意图或审批通过后再开放完整定义。
第四步：任务中途允许继续发现
如果首轮工具不足，不要回到全量注入。让 Agent 在当前授权能力面内发起下一次搜索，返回新的少量候选，再按需加载 Schema。这样既保留长流程的扩展性，也避免一开始承担所有工具的上下文成本。
典型链路可以表示为：
业务系统登记工具
-> 路由按场景和 scope 过滤
-> 身份形成授权能力面
-> 轻量目录检索
-> 加载少量完整 Schema
-> Agent 规划与调用
-> 服务端鉴权、审批、审计MCP 工具设计要同时关注检索和安全
工具描述要能区分边界
工具名称不要只写 update、query 这类宽泛词。应体现业务对象、动作和关键边界，例如 order_update_internal_note 比 order_update 更容易被正确选择。描述中还应说明适用条件、不可处理的情况、是否产生副作用，以及参数的业务含义。
工具拆分也不是越细越好：过粗会把多个动作和副作用混在一起，过细则会制造大量相似候选。应围绕稳定的业务动作拆分，并保持命名和参数语义一致。
发现与执行必须分离
MCP 的工具规范包含工具列表发现和工具调用等能力；但协议层的发现并不等于业务系统授权。生产环境仍应在执行入口校验租户、资源归属、字段白名单、幂等键和审批状态。
对于写操作，建议采用更谨慎的路径：先展示将要执行的动作和关键参数，再由用户确认或策略引擎审批；执行结果写入审计日志，失败时返回可定位的错误，而不是让模型自行猜测下一步。
观测指标要覆盖整条链路
不要只看模型最终是否回答成功，还应记录：
- 首轮注入的工具数量和 Schema Token；
- 工具搜索命中率、空结果率和二次搜索率；
- 工具选择失败、参数校验失败和业务拒绝次数；
- 从用户请求到工具执行的延迟；
- 不同工具集策略下的输入成本与任务完成率。
这些数据能帮助团队判断瓶颈究竟在目录检索、描述质量、模型推理还是后端权限，而不是简单地继续增加模型或上下文窗口。
适合谁采用这种架构
如果系统只有几个稳定的只读工具，全量注入可能足够，先把命名、参数校验和错误处理做好即可。
以下情况更适合引入按需加载：
- 工具来自多个业务系统，数量持续增长；
- 同一 Agent 需要跨租户、跨角色处理请求；
- 对话中同时包含知识库片段、历史消息和页面上下文；
- 存在退款、改价、删除、发消息等高风险写操作；
- 团队已经遇到首轮延迟、Token 费用或误选工具上升。
落地时可以从最小闭环开始：先做场景路由和权限过滤，再建立轻量目录；随后只为命中的工具加载 Schema，最后补齐审批、审计和指标。这样比一次性改造所有 MCP Server 更容易验证收益，也更便于回滚。
结语
Agent 不需要在每次对话开始时“背下”整个企业后台。更可扩展的方案是让业务系统维护完整目录，让路由和身份先形成授权边界，再根据任务检索少量候选，最后由执行侧完成实时鉴权。
这种 MCP 工具按需加载模式同时解决了上下文成本、工具选择和治理问题：能力目录可以持续扩展，但模型当前看到的工作台保持足够小。对于准备把 AI Agent 部署到 CRM、ERP、客服或 SaaS 场景的团队，这是一项值得优先设计的基础能力。