把每个 API 操作映射为单独的 MCP 工具，在企业规模下会难以为继。一种称为“代码模式”的工具使用模式，以及一个受治理的上下文层，为平台团队提供了更好的路径。

　　过去十年，企业一直在建设 API 体系。一个大型组织如今运行着数千个内部 API，每个 API 都有规范、所有者、身份验证方案，以及在网关上执行的访问策略。随着代理进入生产环境，这些 API 是代理所需上下文的明显来源：客户记录、订单状态、库存、定价和支持工单。

　　现在更难的问题是：代理如何大规模地访问这些系统。模型上下文协议（MCP）为行业提供了将代理连接到工具的标准方式。但团队通过 MCP 暴露 API 的最常见方式——每个 API 操作一个工具——在代理触及企业 API 资产中有意义的一部分之前，就已经开始失灵。

　　下面说明为什么会发生这种情况、更好的模式是什么样，以及平台团队如何构建一个复用既有治理能力的上下文层。

　　为什么“每个端点一个工具”无法扩展

　　把 API 转换为 MCP 服务器的默认方法是：使用其 OpenAPI 规范，为每个操作生成一个工具。这对小型 API 有效。然而，一个典型的企业 CRM 或 ERP API 可能有数百个操作，而一个需要其中几个 API 的代理很快就会面对数百个工具定义。

　　采用这种方法时，三件事会迅速出问题。

　　成本。 在代理开始任何工作之前，每个工具定义都会加载到模型上下文中，每个中间结果也会流回模型。像查找客户、提取其未结订单、检查发货状态这样的常规工作流，每一步都要为 token 付费。

　　准确性。 一旦工具列表超出模型能够推理的范围，工具选择就会退化。代理会从一组看起来相似的工具中选错，或者发起三次调用。

　　延迟。 更多上下文处理，以及模型与工具之间更多往返，会拖慢代理。早在任何人看到 token 账单之前，用户就已经注意到了。

　　团队通常通过筛选来应对。他们精简工具列表，并把大型 API 拆成许多小型 MCP 服务器。这有帮助，但现在每个代理用例都需要自己手动维护的集成。这造成了与 API 体系原本要消除的相同的集成蔓延。

　　代码模式：让代理针对 API 编写代码

　　行业已经趋同于一种更好的模式，通常称为“代码模式”。代码模式服务器把 API 作为单个类似 SDK 的接口暴露出来，而不是一个扁平的工具列表。代理针对该接口编写短代码片段，代码在沙盒中运行，只有最终结果返回模型上下文。

　　在实践中，模式是搜索、理解和执行。代理在 API 接口面上搜索所需操作，按需获取该操作的 schema（模式），然后运行它。完整 API 仍然可用，但只有代理实际使用的部分才会进入其上下文。

　　这利用了模型已经擅长的事情。大语言模型在训练中见过大量代码，而工具调用语法相对较少。在 SDK 层面，代理可以使用它从未训练过的大型 API，因为它像开发者一样阅读接口。

　　效率提升是巨大的。由于代理在代码中工作，一个片段可以使用循环、条件和错误处理来串联多个 API 调用。因此，上述多步骤工作流减少了往返次数。中间结果不会进入上下文窗口。在我们的测试中，一个通过标准工具调用消耗约 12 万个 token 的工作流，在代码模式下只使用了约 1200 个 token。

　　说白了，代码模式也有自身成本。运行代理编写的代码，意味着你既需要一个可信的沙盒，也需要对代码实际调用的完整可观测性。采用该模式的平台团队应该从第一天起就把这两者视为硬性要求。

　　通过你已经在运行的网关路由代理流量

　　代码模式解决了上下文窗口问题，但治理问题仍然存在。调用生产 API 的代理需要任何其他客户端所需的一切：身份验证、授权、速率限制和审计日志。

　　许多团队在构建代理集成时，会为每个 MCP 服务器重新实现这些控制措施。凭据最终散落在服务器配置里。访问规则由编写集成的人重新定义。代理流量绕过网关，因此永远不会出现在安全团队已经关注的日志中。

　　更好的方法是将上下文层视为 API 平台的扩展。每个 API 的规范、schema、身份验证要求和访问策略，已经存在于管理 API 的地方。从这一单一事实来源生成面向代理的接口，并通过管理其他消费者的同一网关路由代理调用。这样，现有策略会自动应用于代理，代理也就成为又一个受监管的客户端。

　　可发现性也很重要。在中央目录中注册每个面向代理的接口，这样下一个构建代理的团队就能找到并复用它，而不是构建到同一 CRM 的第四个集成。

　　为每个代理组合一个上下文界面

　　API 只是画面的一部分。大多数企业已经在运行 MCP 服务器，有些来自 SaaS 供应商，有些由内部团队构建。代理还需要访问企业数据源。一个有用的代理会利用所有这些资源。

　　上下文层应该允许平台团队组合来源。选取几个内部 API 和几个现有 MCP 服务器，把它们作为一个代码模式接口一起暴露给特定代理的工作范围。客户支持代理获得工单、CRM 和运输能力，但拿不到工资单。

　　这个范围同时起两个作用。它是安全控制，因为代理只能触达其任务所需的范围；它也是性能控制，因为更小、更相关的接口能让模型保持专注。

　　筛选是关键。更多上下文并不自动等于更好的上下文。目标是向代理提供企业的广度，同时让进入模型的内容规模小且相关。　

　　在 Kong，我们把这些原则构建进了 Kong Context Mesh，它现已作为 Kong AI Management 的一部分正式可用。它们扩展了我们在 2026 年早些时候在 Kong Context Mesh 中引入的方法。

　　平台团队将他们的 API、现有 MCP 服务器和企业数据源汇集在一起，Kong AI Gateway 生成代理用于访问这些资源的代码模式 MCP 接口。由于网关生成并提供这些接口，代理访问就落在团队已经用于管理其 API 和 AI 流量的同一平台上。

　　代理的能力取决于它能触达的上下文。有效的代理需要广泛访问企业系统，但要有选择地按需交付。行动最快的企业会把这种上下文环境视为基础设施。它们会从已经管理的系统中生成它，用已经执行的政策治理它，并把它限定到每个代理需要完成的工作。

　　API 之所以成为数字业务的支柱，是因为平台团队让它们可发现、安全且可治理。代理也需要同样的纪律。好消息是，大多数企业已经奠定了基础。