当一个AI智能体拥有1,000个MCP工具时：选择、上下文与技能问题
将智能体连接到众多MCP服务器会导致工具数量激增、上下文过于臃肿以及选择失误。为何发现机制、技能与网关可能比直接访问更为重要。
对于人工智能代理来说，更多的工具听起来显然是好处，直到工具数量达到1,000个为止。到了那个阶段，问题就发生了变化：不再是“代理能否完成这项任务？”，而是“代理能否找到合适的工具并正确使用它？”。正是在这里，MCP显得十分有趣。
MCP让工具的调用变得简单
Model Context Protocol 的一大优势在于，各种功能都能通过统一的接口传递给智能体。某个 SaaS 产品可能会提供 create_customer、get_customer、update_customer、create_invoice、refund_payment 和 search_orders 等功能；另一个 MCP 服务器可能用于处理 GitHub 的数据，第三个用于 Slack，第四个则用于内部数据库。单独来看，每个系统都没问题。但当一个智能体需要连接多个服务器，且数量迅速增加时，问题就出现了：10 个工具还算轻松，100 个就会开始带来困扰，而 1000 个则完全是另一回事。
工具数量激增
设身处地为拥有1,000种工具的智能体着想。你必须弄清楚每种工具的功能、它们之间的关联、该使用哪些工具、每种工具需要哪些参数、哪些工具应先运行，以及是否有几种工具能完成相同的工作。从技术上讲，智能体可以访问所有工具，但能够访问并不等同于能够实际使用。工具越多，能力越强，选择也越多，而过多的选择反而会让决策变得更加困难。
上下文信息的重要性
每种工具都需要有描述。对于某些工具，描述可能只是一个名称：
create_invoice
以及一个简短的定义：
Creates an invoice for a customer.Parameters:
- customer_id
- amount
- currency
- due_date
将其乘以1,000。即便只是简短的描述，累积起来也会形成大量的上下文信息，因此仅仅为了告诉模型它能做什么就需要消耗大量令牌，而那些工具大多与当前任务毫无关联。如果用户询问订单状态，客服人员完全没有必要去了解500种计费、GitHub、CRM以及部署工具的相关信息。
选择合适的工具才是真正的难题
假设客服人员看到了这些：
get_customer
get_customer_details
lookup_customer
search_customer
find_customer
它们的声音都差不多。应该调用哪一个呢？现在把这种情况扩展到数百种工具上。模型完全可以很好地调用这些工具，难点在于从庞大的工具箱中挑选一个。这就好比给开发者提供10,000个函数却只祝他们好运——虽然可行，但并不愉快。
工具越多，错误越多
选择往往并非非黑即白，因为可能有几种工具都能发挥作用：
search_orders
get_order
list_orders
find_order_by_customer
智能体可以选择有效的工具，但使用方式可能效率低下；有时本只需调用一个工具却会调用多个，或者调用顺序错误。整个流程从工具的可用性开始，经过选择、排序，最终执行。MCP主要帮助解决第一环节的问题，其余部分则取决于智能体本身及其所处的架构。
智能体应该拥有更少的工具吗？
不一定。其目的并非限制智能体的功能，而是避免让它同时理解所有内容。解决支付问题时，人们不会打开所有内部工具并阅读文档，只会使用与支付相关的工具。智能体也可以采用同样的方式。那种先加载所有工具再选择的模式，可以转变为发现、选择、加载和执行的过程，这样的设计更为合理。
Skills的适用场景
各项技能之间存在直接关联。某项技能可以为特定类型的任务提供背景信息。例如，客户账单处理技能会指示客服人员找到对应客户、查看订阅情况、检查未结发票、确定正确的账单处理方式、在必要时寻求批准，然后再使用相应的工具。
客服人员无需再考虑系统中的所有工具，只需针对当前任务获取更少但更相关的工具即可。不再是这样：
Agent
↓
1,000 tools
流程可能如下：
Agent
↓
Relevant Skill
↓
Relevant tools
↓
MCP
↓
API / System
技能无法替代MCP，因为它们解决的是不同的问题。MCP将智能体与各种能力相连，而技能则能教会它如何使用这些能力。以技能取代MCP的理念仍处于试验阶段且仍在发展，因此将其视为一种新兴方向会比视为成熟的架构更为合适。
网关也可能很重要
另一个发展方向是MCP网关。与其直接将智能体连接到数十个MCP服务器，不如使用网关作为中间环节：
Agent
↓
MCP Gateway
↓
MCP Servers
↓
APIs / Systems
网关可以承担身份验证、路由、访问控制、可观测性、工具发现以及多台服务器的管理等功能。随着MCP部署规模的扩大，其价值也会进一步提升。
真正的问题在于无关性
人们担心的并非有1000种工具本身，而是存在1000种无关的工具。如果某项任务确实需要1000种工具，那也没关系。但如果只需要12种，而代理却必须处理1000种工具才能找到它们，那就造成了不必要的复杂性。原则是：代理无需访问所有内容，只需访问当前重要的内容即可。
随着智能体连接到更多系统，这很可能会成为MCP架构中的核心问题。MCP已经解决了第一个问题，即如何让智能体以标准化方式访问工具。接下来的问题是如何智能地管理所有这些工具，而这看起来要困难得多。为智能体提供工具已经变得简单，而要在恰当的时间为它们提供合适的工具才是未来的任务。
相关阅读
- MCP如何改变AI智能体与业务软件的集成方式 ——模型上下文协议如何将智能体与CRM、ERP及内部API相连，需要保护哪些内容，以及企业应如何从小规模开始尝试。