生产级Agent网关如何组织身份与人工审批

Agent 一旦能调模型、用工具、再委托其他 Agent，权限和审计就很难靠各处零散的判断维持。作者以 TrueFoundry 为例，拆解了一套 Agent Gateway 架构：把身份、调用权限、人工审批和能力复用放到统一的治理体系里。

它最有参考价值的地方，是解释了这些组件为什么需要共享身份。但原文是一篇架构说明，没有性能实测或方案对比。读的时候，要把设计目标与已经验证的效果分开。

网关为什么要分成三层，两种平面

原文里的 AI Gateway 不是一个包办所有请求的代理，而是三个职责不同的组件：

• Agent Gateway 管理 Agent 之间的调用。
• LLM Gateway 管理语言模型调用。
• MCP Gateway 管理工具调用。

三类请求处理的对象不同，却需要回答相同的问题：谁发起的，有没有权限，出了问题能不能追查。因此，它们共享身份和策略基础，但分别处理流量。

部署上，作者又把配置管理和请求执行拆开。中央控制平面（Control Plane）保存 Agent 注册信息、身份、访问策略、审批规则和 Skill 定义；区域数据平面（Data Plane）位于实际请求路径中，按这些配置检查并放行请求。

大白话解释：总部定规则，各区域的入口执行规则。

这种拆分有两个合理目标。数据平面靠近 Agent 和模型，可以减少治理环节引入的网络开销；敏感请求和响应也可以留在指定区域，配置则集中管理。不过，「延迟低」在原文中是设计推断，没有增加多少毫秒的测试数据。

作者还将这种架构与 SaaS、自托管、完全隔离网络部署，以及 SOC 2、HIPAA、GDPR、ITAR 等合规要求联系起来。这里需要收住一步：架构可以为数据驻留和访问控制提供条件，但采用这种部署方式，并不等于自动满足这些框架的全部要求。

身份为什么比一把 API Key 更重要

整套设计的起点，是每次请求都解析两个信息：哪个 Agent 在操作，以及它代表谁操作。

例如，同一个工单 Agent 可能分别替不同用户处理请求。只知道调用来自这个 Agent，还不足以判断它能访问哪些数据。必须继续知道背后的委托主体，才能把操作归到具体责任人或服务身份上。

Agent 身份需要同时表达执行者与委托关系。

原文把它与普通 API Key 作了区分：Key 首先证明某个凭证被使用了，身份体系则需要进一步确定责任主体。两者并不互斥，API Key 可以是认证入口，但不能仅凭共享密钥就假定委托关系已经解决。

身份可以由网关自己管理，也可以对接已有身份提供方。随后，身份上下文继续传到 LLM Gateway 和 MCP Gateway，让一次任务产生的模型、工具和 Agent 调用能够关联起来。

共享 Agent Registry 则在此基础上提供一个带权限的目录。Agent A 能否发现、调用 Agent B，由策略决定。它针对的是多 Agent 系统中常见的点对点连接：代码里接上了，组织里却没人完整掌握依赖关系。

另一个目录是 Skills Registry。它保存带版本、受访问控制的可复用能力，让多个 Agent 可以挂载同一份 Skill。两个目录管理的对象不同：Agent Registry 管谁能调用谁，Skills Registry 管有哪些能力、谁能挂载。

这对重复建设有帮助，但原文没有解释 Skill 的具体格式、版本兼容规则和发布回滚机制，不能直接把它当作一套完整的包管理方案。

人工审批怎样才能真正挡住敏感操作

作者建议把敏感工具的审批放在网关执行。Agent 请求使用工具时，网关暂停操作，等待明确的人类批准；批准还带有有效期，过期后不能继续使用。

下面这段策略表达了退款工具的审批意图，原文明确说明它只是示例，并非真实 API Schema：

{ "// note": "illustrative policy, not a literal API schema", "tool": "payments.issue_refund", "sensitivity": "high", "approval": { "required": true, "approvers": ["role:finance-reviewer"], "validity_window_minutes": 15 } }

要看的是 validity_window_minutes：payments.issue_refund 被标为高敏感操作，需要 role:finance-reviewer 审批，批准后授权有效期为 15 分钟。

把检查放到网关，优势是不同 Agent 框架都能受到同一套约束，开发者漏写一次检查也不会直接放行。但这个结论有一个关键前提：敏感操作必须经过网关。若 Agent 仍能拿着下游凭证直连退款服务，单靠入口审批就无法保证覆盖。

原文也没说明，批准究竟绑定一次调用、一组参数，还是有效期内的多次操作。退款对象、金额变化后能否沿用批准，这些都会影响实际安全边界。

模型调用的接入示例则非常轻：

from openai import OpenAI

client = OpenAI( api_key="your_truefoundry_api_key", base_url="https://gateway.truefoundry.ai", )

response = client.chat.completions.create( model="your-model", messages=[{"role": "user", "content": "Summarize this ticket."}], )

这里要看 base_url：OpenAI 客户端通过 client.chat.completions.create 请求网关，由网关承接身份检查、策略判断和追踪。

这个例子证明的是模型请求可以通过兼容接口切换入口。它没有演示委托身份如何传递，也没有展示工具和 Agent 之间的接入过程。把模型客户端地址改掉，与完成整套治理接入之间，还有工作要做。

我的判断

这套架构最值得借鉴的，是把身份、权限和审计贯穿调用链。对于已经出现多个 Agent、多个工具入口、跨团队能力复用的系统，统一治理能减少各处规则不一致的问题。

人工审批放在执行入口，也比只在提示词里写「执行前请确认」更有约束力。提示词影响模型行为，网关则决定请求能否到达工具。但要让这个边界成立，还得限制绕行路径，并明确审批与操作参数的绑定关系。

相比在每个 Agent 内部实现校验，网关便于集中修改策略；代价是它也成为共同依赖，需要处理可用性、配置同步和故障时是否放行等问题。原文没有展开这些内容。

对只有一个 Agent、少量工具的团队，现有后端里的身份认证、工具权限检查和操作日志，可能已经够用。是否需要再引入 Agent Registry 和 Skills Registry，应当由跨 Agent 协作与复用需求推动。

原文提供了清晰的职责划分，但没有提供足以证明收益大小的对照数据。

因此，可以借它检查架构缺口，暂时不宜据此判断接入成本、性能收益，或认定某个产品已经替团队解决了治理问题。

能拿来做什么

• 给现有 AI 应用梳理一次调用路径，逐项列出模型请求、工具请求和 Agent 之间的请求，确认每个入口分别在哪里做身份校验、权限判断和日志记录。
• 如果正在用 Node 或其他后端承接 AI 请求，可以检查日志是否同时保留 Agent 身份、委托用户和调用关联信息，让一次任务产生的下游操作能够被串起来。
• 对退款等敏感工具，把审批检查放在实际执行入口，并明确批准绑定的操作、参数和有效期；原文的 15 分钟仅是示例，不应直接作为默认策略。
• 当多个 Agent 开始复制同一份能力时，再考虑为 Skill 增加版本与挂载权限，并为 Agent 建立可发现、受权限约束的目录。