企业真正要管的，已经不只是“谁调用了哪个接口”，而是“谁在替谁做事，又能做到哪一步”。

7月9日，Citrix 给 NetScaler 装上了 MCP Gateway。

过去，NetScaler 负责检查进出企业应用的流量，验证身份、控制访问量、转发请求。现在它要检查的，不仅有应用发来的请求，还有 AI Agent 替人发起的动作。

不止 Citrix。Kong 将 MCP、模型调用和 Agent 间通信纳入同一套网关体系，AWS 和微软也在6月陆续补齐了 MCP 管理能力。他们的产品路线不同，判断却很接近：

Agent 真正进入企业之后，工具前面还需要再加一道关卡。

这道关卡很像 API 网关，但它要管的，已经不只是 API。

一、从管理请求，到限制 Agent 的行动

API 网关解决的是个老问题。

企业内部接口多，每个应用都直接连后端的话，认证、限流和日志就会散在各系统里，既难管也容易漏掉。API 网关把请求集中到统一入口，统一做认证、限流和日志，再决定哪些放行、哪些拦截、哪些转发。

MCP 网关继承了这套能力。Citrix 的 MCP Gateway 将集中认证、工具级限流、MCP 服务器准入名单、会话保持和调用监控放进了同一个控制台。面对多个后端服务器，这类网关还需要识别服务状态，维持路由和会话稳定。

但 Agent 和普通应用有一个根本差别。应用调哪个接口，通常由开发者提前写进代码，按固定流程运行。在常见的工具调用模式中，模型或编排器会根据工具名称、用途和参数说明，从当前可用能力中选择下一步调用对象。一个任务还可能跨多个系统，连续调用邮件、文档、数据库、工单甚至付款工具。一次次接口请求，就这样串成了一条行动链。

以客服场景举例。用户让 Agent“整理客户退款”，过程会涉及查订单、读取客服记录、修改工单、发出退款通知等操作。这些操作串起来，退款流程才算走完。

传统 API 网关主要记录请求来自哪里、去了哪里、是否成功；面向 Agent 的网关还需要进一步识别，这次调用属于哪项任务、代表谁发起，又处在整条行动链的哪一步。

但网关自己看不到全部答案。它能记录工具、参数、结果、会话和身份，“这属于哪项任务”不会自动出现在日志里。要还原完整过程，得让 Agent 运行时和业务系统共用一套追踪标识，把任务 ID 一路传下去。微软内置的 MCP 遥测也是这个范围，Agent ID、业务任务 ID 要额外写入。

这种差别在 MCP 场景里被进一步放大。MCP 统一了客户端和工具服务之间的交互接口。在客户端和服务器都实现 MCP 的前提下，同一项工具能力更容易被不同 Agent 或 AI 应用复用，但认证方式、返回结构和具体适配并不会自动统一。

但问题也跟着来了。工具说明本身开始影响 Agent 的判断。

OWASP 列出的 MCP 风险里有一类叫“工具投毒”。2025年4月，Agent 安全公司 Invariant Labs 做过一次概念验证。他们做了一个看似普通的加法工具，却在工具说明里暗藏指令，要求 Cursor 读取 MCP 配置和 SSH 私钥，再塞进工具参数传出去。在这次受控实验中，Cursor 内的 Agent 按隐藏指令读取了相关文件，并把内容放进工具参数中传出。用户看到的确认窗口只展示了简化后的调用信息，没完整显示实际传出的参数。这次实验只能证明攻击路径存在，不能说明类似攻击已在真实环境大规模发生。

风险也不只藏在说明里，工具返回结果夹带恶意指令，同样能劫持 Agent 的下一步操作。权限过宽会放大这类风险。一个会议助手原本只需要读日历，却拿到修改和删除权限，一旦 Agent 判断失误，就会误删数据。

MCP 为基于 HTTP 的远程连接定义了 OAuth 授权规范，但这项能力并非强制启用。启用授权后，访问令牌需要绑定具体 MCP 服务器，不能在不同服务之间直接转交；客户端的每次受保护 HTTP 请求也必须携带授权信息。这套机制主要判断凭证是否合法、令牌能否正确使用。凭证合法，顶多说明 Agent 进得了系统；进去以后能干什么、不能干什么，它说了不算。而这部分，恰恰是企业要管的：

  • 这个 Agent 当前代表谁？
  • 它能看到哪些工具？
  • 哪些操作必须人工确认？
  • 工具说明变了之后，要不要重新审核？
  • 一次任务调用了五个系统，日志怎么串起来？

这些问题不是一个登录按钮能解决的。所以 MCP 网关不能只负责协议转发，还要承担工具目录管理、细粒度权限控制、凭证保管、会话追踪和审计。

API 网关守住的是系统入口，MCP 网关还要进一步限制 Agent 进去之后能做什么。

二、四家厂商，正在争夺同一个控制点

Kong 原本就是 API 管理厂商。2月2日，它在纽约证券交易所举行的 AI Connectivity 发布活动上推出 MCP Registry 技术预览版，把企业批准使用的 MCP 服务器和工具纳入统一目录。4月14日，Kong 又在 AI Gateway 3.14 中加入 Agent Gateway，将治理范围扩展到 Agent 间的 A2A 通信。

AWS 的路线更进一步。AgentCore Gateway 能把企业已有的 API 和 Lambda 函数转换成 MCP 工具。6月1日，AWS 又为 AgentCore Gateway 增加动态工具发现、流式响应、会话管理、elicitation 和 OAuth 代表用户令牌交换等能力。对于高风险操作，后端 MCP 服务器可以通过 elicitation 暂停当前调用，请求用户确认、补充信息或完成外部授权；网关负责保持会话，并把请求转给客户端。用户完成相应操作后，任务再继续。这套能力依赖流式响应和会话管理，目前只适用于 MCP 服务器目标。

微软选择改造现有的 Azure API Management。6月2日，微软在 Build 2026 期间发布 Unified Model API 预览版，并将内容安全检查扩展到 MCP 工具输入、工具返回结果和 A2A 通信内容。这还不足以彻底解决工具投毒，但工具返回结果里的恶意指令也进入了检查范围。6月9日，微软又宣布一批新增的 MCP 服务器管理能力进入 GA，包括将不同 MCP 服务器打包进 APIM Products，面向不同开发者、团队或 Agent 分配访问权限，查看工具级遥测并管理版本。自动化部署也能通过管理接口和 Bicep 模板完成。

Citrix 的思路类似，把 MCP Gateway 纳入 NetScaler AI Gateway，和模型路由、用量统计放在同一个控制台里管理。

这些功能大多刚推出，客户规模和收入贡献也还没公开，现在谈市场成熟还太早。但几家的方向一致，都在自己原有的平台上，向外扩出一层面向 Agent 的管理能力。

原因不复杂。企业不会因为 Agent 出现，就推翻原有的接口、安全和身份体系。谁掌握了 API、身份和流量入口，谁就更有机会接住这层新需求。

三、真正的新价值，是划定 Agent 的行动边界

如果 MCP 网关只是把请求从 A 转发到 B，很难形成新的商业价值。这类工作，传统反向代理和 API 网关早就很擅长了。MCP 网关的新价值，要看它能不能回答三个问题。

第一，Agent 能发现哪些工具。 企业内部接口成百上千，不可能全暴露给模型，工具太多会占用上下文，也更容易误选、误调用。网关可以按用户身份和所属部门缩小范围；客户端愿意传入任务上下文，还能进一步按当前任务筛选。

第二，Agent 能执行到哪一步。 读取库存可以自动完成，修改商品价格可能要二次确认，批量付款必须人工审批。网关如果能按操作风险插入不同级别的确认和审批，它管的就不再只是流量，而是业务权限。

第三，出了问题，能不能还原整个过程。 企业不仅要知道哪个接口报错，还需要尽可能还原 Agent 在什么任务背景下选择了这个工具、代表谁发起调用、读了哪些数据，之后又触发了什么操作。网关可以成为任务链的审计入口，但只看 MCP 流量仍串不起完整过程。Agent 框架、编排层和业务系统还得共用一套追踪标识，把任务 ID 一路传下去。

所以，成熟的 MCP 网关不会只是“支持 MCP 协议的 API 网关”，它更像 API 网关、身份系统、工具目录和 Agent 审计系统的组合。

这套体系足够重，可能形成新增预算，也可能被现有平台打包吸收。Citrix 已经表示，相关能力对部分现有许可证不额外收费。它能不能成为独立生意，还得看客户愿不愿意单独付费。

四、能撑起一门独立的生意吗？

模型可以换，Agent 框架也可以换。但工具权限、凭证和审计规则不一样，企业一旦把它们放进网关，这里就成了控制点。权限归它发，规则归它管，Agent 想干活，绕不开它。

前提是流量真的经过网关。MCP 同时支持本地 stdio 和远程 HTTP，Agent 也可能绕开 MCP，直接调用 API、SDK、浏览器或数据库，这些行动不会自动出现在网关里。只有企业把远程 MCP 调用统一收口到网关，同时管住本地工具和其他旁路，网关才谈得上“难以绕开”。

这么值钱的位置，能撑起一门独立的生意吗？未必。上一节提到的 Citrix 不额外收费，就是信号。API 网关厂商有现成客户，云厂商掌握算力、身份和托管环境，安全公司擅长策略控制和审计，它们都有能力把 MCP 网关吸收进原有产品。

创业公司的机会，更可能藏在这些大平台还没覆盖到的缝隙里。

第一是跨云管理。企业同时用 AWS、Azure 和自建系统，需要一套中立的策略层，别让权限规则散在各云平台里。

第二是工具供应链安全。谁能持续检查工具说明的变化、锁定可信版本、识别工具投毒，谁就可能补上现有网关还没覆盖的那一层。

第三是行动级审计。企业要追踪的不再是孤立的接口调用，而是完整的任务链，还要在付款、删数据、批量发邮件这些高风险操作前插入人工确认。

第四是效果和成本治理。网关知道 Agent 调了什么工具，不一定知道有没有真正解决问题。把工具调用、模型成本和业务结果连起来，才可能形成独立的产品价值。

这些方向比单纯转发 MCP 流量更难，护城河也可能更深。

**MCP 网关可能会成为 Agent 时代的新控制点，但它不是给 API 网关换一套协议这么简单。

API 网关解决的是“系统如何安全连接”，MCP 网关还要进一步解决“Agent 可以代表人做到哪一步”。前者管的是流量，后者触及的是企业内部的权限和责任。

Citrix 只是给产品菜单加了一个 MCP Gateway，这道新入口背后，企业真正要建的可能不是一台更聪明的路由器，而是一套为 Agent 划定边界、分配权限、追究责任的制度。

主要信源

信息截至2026年7月21日。各家产品还在快速更新。厂商功能描述不等于客户采用结果，文中已区分产品发布和市场判断。