Agent网关为什么成了企业标配？

当公司里只有一个 AI Agent、接三五个工具时，一切都好说。但当 Uber、Amazon 这样的公司把成千上万个内部接口都开放给 Agent 使用时，问题就来了：谁有权调用哪个工具？调用记录怎么审计？出事了怎么追责？

2026 年，行业给出的答案高度一致——在 Agent 和工具之间，架一层「网关」。

MCP 解决了连接，没解决治理

先回顾概念。MCP（模型上下文协议）像 USB-C，让 AI 能统一地连上各种工具。它极大降低了「接工具」的成本，但它 deliberately 不管一件事：治理。工具定义会直接喂给模型，工具服务谁都能部署，中间没有一个「执行前的检查点」。

加载链接预览…

在小规模下这没问题。可一旦你有几十上百个 MCP 服务、多个团队、还有合规要求，问题就集中爆发：凭证散落各处（每个服务一套 auth）、工具太多塞爆模型的上下文窗口、没有统一的权限和审计。这时候，「网关 + 注册表」就成了必然。

网关做什么：Agent 世界的「控制平面」

把网关理解成所有 Agent 流量的统一入口和守门人。它通常和一个「注册表」（Registry，记录有哪些工具可用）配合，构成控制平面：

• 鉴权与最小权限：在网关层判断「这个 Agent 能不能在此刻、用这些参数、调这个工具」，而不是在每个应用边界各写一遍。
• 审计：所有调用留痕，可追溯、可回放。
• 脱敏：请求发往外部模型前，先在网关抹掉 PII（个人信息）和内部标识。
• 按需暴露工具：只把当前 Agent 真正需要的工具喂给它，缓解上下文膨胀。

Uber 的做法很典型：他们建了 MCP 网关和注册表作为控制平面，把成千上万个内部接口自动暴露成 MCP 工具，所有 Agent 流量都走一个 Go 写的代理，先做 PII 脱敏再放行，每周有数万次 Agent 执行经过它。

关键设计原则：写操作要「确定性」

一个反复被强调的原则是：推理层和动作层要分开。大模型负责「想」（reasoning），但真正有副作用的「做」（mutation、写操作）必须放在确定性的基础设施里，由网关做鉴权和控制，而不是任由模型的概率性输出直接触发。

一个最小示意的策略配置

网关的核心是「策略」。用伪配置表达「只有客服 Agent 能查订单，且必须带租户 ID」大致是这样：

policies:
  - agent: "support-agent"
    allow_tools: ["order.read"]
    require_params: ["tenant_id"]     # 缺少则拒绝
    redact: ["customer.phone", "customer.email"]  # 出网关前脱敏
  - agent: "*"
    deny_tools: ["payment.refund"]    # 退款一律禁止 Agent 自主执行

思路是「默认拒绝、显式放行」，把危险的写操作（如退款）从 Agent 自主能力里彻底拿掉。

取舍与边界

• 网关是额外一跳，会带来一点延迟和运维成本，但换来的是可控和可审计，对企业几乎是必需的。
• 幂等性很重要：Agent 会重试，写操作要用幂等键，避免「重试导致重复退款」这类事故。
• 别把治理逻辑塞进提示词：靠 prompt 让模型「自觉守规矩」不可靠，规则要落在确定性的网关里。
• 小团队、个人项目未必需要完整网关，但「有副作用的动作要有检查点」这个原则任何规模都适用。

Tips

• 工具超过一把、或有多团队/合规要求时，就该考虑引入网关 + 注册表。
• 把鉴权、审计、脱敏统一收敛到网关层，别在每个应用里各写一套。
• 严格区分「读」和「写」：读可以放开些，写必须过网关、带幂等键、可审计。
• 用「默认拒绝、显式放行」的策略模型，危险操作直接从 Agent 能力里移除。
• 记住这条准则：让模型负责思考，让确定性基础设施负责执行。