云砺 AI 网关方案（公司版）

版本：v1.0 · 2026-09-10 · 评审稿　作者：Claude Code（樊国柱会话） 读者：技术管理层、平台与基础设施团队、AI 应用与 Agent 开发团队、交付与售前 定位：在《企业 AI Gateway 方案设计》（v1.0 · 2026-09-07，下称"前序方案"）基础上，按公司口径重组为一份面向全员的总体方案：整体架构与架构图、权限管理与认证全流程、技术选型、多环境。前序方案中的现状盘点、需求接纳矩阵、契约字段与工程量明细不再重复，只在需要处引用。 配套：前序方案（01–04）、汇报页与架构图页（Cloudflare Pages）、飞书画板文档。

证据等级沿用前序方案：实测证实（POC S1–S7 / 49 项检查）、文档取证（agentgateway v1.5.0、Higress v2.2.4 的文档与发布说明，2026-09-10 查阅）、湖仓取证、源码取证、需自建、未取证。未标注等级的判断均为设计判断。

0. 一页结论

1. 一个产品、四类能力、一把 Key。 AI 网关 = LLM 网关 + MCP 网关 + Skill 中心 + A2A 网关（低优先级），由同一个管理中心（门户 / 控制台）管理。内部每人一把个人 Key，同时用于模型、MCP 和 Skill；使用方只需配置网关地址与 Key，不再单独申请权限或凭证。
2. 身份汇聚到一个 AI IdP。 我司 SaaS 用户中心是客户身份的权威源；内部员工以飞书登录为主；企微、钉钉、客户自建 IdP 以联邦方式接入 AI IdP（Keycloak）。AI IdP 不复制用户目录、不持有用户中心的签名密钥，只做登录桥、协议适配和逐跳换发。
3. 权限是配置资产，不写在业务代码里。 模型按"别名白名单 + 套餐 / 预算 + 速率 + 守卫"管；MCP 按"登记表 + server / 工具 / 参数三级授权 + 逐跳换发 + 审批"管；Skill 按"审核 + 签名 + 可见性"管。三类策略统一编译成网关配置，带版本、可回滚。
4. 数据面选 agentgateway，不引入 Higress。 agentgateway（Linux Foundation，Rust 单二进制）原生覆盖 LLM / MCP / A2A，v1.5.0 已具备每 Key 的 Token 与美元预算、Key 管理界面、PostgreSQL 持久化（文档取证）。公司没有 Higress 存量，南北向已有 APISIX / Kong / ingress-nginx；Higress 的长处（南北向一体化、控制台、MCP 市场）与我们的缺口重叠度低，代价却是新增 Envoy / Istio / Wasm 技术栈。
5. 自研集中在控制面。 管理中心（门户 / 控制台 / 注册中心 / Key 服务）、登录桥与三方登录适配、策略仓与编译流水线、策略处理器（ExtMCP）、Skill 中心、计量对账与看板。不改 agentgateway 源码，只用它的扩展点。
6. 多环境五种形态、一套模板。 云砺托管三套：内部 1 套、外部 SIT、外部 PROD（生产集群跨可用区）；客户侧两种：客户云上单开、客户属地化离线包。同一 Helm / Compose 模板与策略格式，凭据不跨环境。
7. 工程量约 24–30 人周。 较前序方案的 18–24 人周增加了 Skill 中心、Key 服务、三方登录适配与多环境打包；3 人并行约 10–12 周到内部试点，外部 SIT / PROD 随首个客户项目上线。
8. 需要和需求方澄清 9 项（§6）。影响最大的两项：业务人员使用的 SaaS 型 Work 工具（ChatGPT Work、Claude Work）的模型调用无法经我司网关，只能以远程 MCP 连接器与 Skill 方式接入；客户云上单开的控制面归属与计费口径。

1. 整体架构说明和架构图

1.1 使用场景

公司内部场景

公司外部场景（服务客户）

1.2 组件构成与职责

1.3 架构图

读图顺序：左栏是四类使用方与其凭据（个人 Key、个人 Key 或 OAuth、应用凭据加用户 JWT、公网入口）；中栏是本项目交付的 AI 网关——顶部身份接入与管理中心，中部 agentgateway 数据面的四类能力与策略处理器，下部每环境独立的控制面与数据；右栏是网关范围外的能力供给（模型厂商、自托管模型、公司统一 MCP server、Skill 技能库、SaaS 业务 API、A2A Agent、数据平台）。前序方案的 agentgateway 风格图与部署图见架构图页。

1.4 身份接入：多种认证方式如何汇聚

所有来源在 AI IdP 汇聚为同一种 AI 令牌：非对称签名（RS256 / ES256）、受众 aud=ai-gateway、稳定主体 sub、tenant、roles_ref、channel；短期有效并可刷新；用户中心侧登出或禁用通过事件与短 TTL 传播，撤权目标只读 60 秒内、高风险写操作每次在线复核。

1.5 一把 Key：个人 Key 的设计

1.6 请求路径总览

使用方 → 入口（内网直达或公网 DNS → WAF → ALB → APISIX，存量） → 认证（个人 Key / 应用凭据 / 用户 JWT） → 授权（CEL 规则 + 策略处理器） → 路由（模型别名 / MCP 工具 / Skill 包 / A2A Agent） → 出站（厂商、自托管模型、MCP server、技能库、业务 API） → 计量（用量与工具事件） → 看板与对账。每一跳一个受众：使用方的凭据止于网关，厂商 Key 与下游令牌只在网关。

1.7 与存量的关系（摘要）

• 现有统一代理（new-api）先作为 LLM 网关的一个 provider，6 个月内退出代理职责；直连厂商的 8 个服务改配置接入业务池，厂商 Key 上收。
• xagent、智能助手等 Agent 运行时是网关的客户端，网关不做 Harness；网关只看协议（OpenAI / Anthropic / MCP / A2A）。
• 南北向网关（APISIX / Kong / ingress-nginx / ALB + WAF）不动，外部流量经它们进入；agentgateway 不直接暴露公网。
• 详见前序方案 §2、§3。

2. 权限管理

2.1 权限模型总览

权限沿四个轴定义：主体（谁）、客体（对什么）、策略（允许什么、有什么义务）、环境（在哪个实例）。策略以配置资产（三类 IR）表达并编译进网关，业务代码与 MCP server 代码里不写权限逻辑。

主体与凭据

客体与策略要素

角色与操作

决策点

2.2 LLM 网关的权限管理

配置示意（字段名以 v1.5.0 文档为准，真实 Key 由 PostgreSQL 持久化、不进配置文件）：

llm:
  policies:
    apiKey:
      mode: strict
      keys:
        - key: "<由管理中心写入 PostgreSQL，此处仅示意>"
          metadata: { sub: "u-1024", dept: "platform", plan: "coding-pro", channel: "personal" }
          budgets:
            - { type: dollars, limit: 60, window: 7d }
    authorization:
      rules:
        - 'apiKey.metadata.plan == "coding-pro" && llm.requestModel in ["coding-sota", "coding-fast", "general"]'
        - 'apiKey.metadata.plan == "standard" && llm.requestModel in ["coding-fast", "general"]'

预算分三层：个人套餐（编程池，挂在 Key 上）、应用预算（业务池，挂在应用 × 租户上）、租户总预算（数据平台按用量回写阈值，网关执行）。提额走门户申请与飞书审批，审批通过后由编译流水线改预算对象并发布，无需改业务代码。

2.3 MCP 网关的权限管理

聚合端点。 网关暴露 /mcp（本人有权访问的全部 server 聚合）与 /mcp/{server}（单个 server）两种地址；工具名前缀取 conditional（仅冲突时加前缀，访问控制与用量按原始工具名）；tools/list 缓存键包含主体、授权摘要、登记表版本与策略版本，任一变化即失效。

配置示意：

mcp:
  policies:
    mcpAuthentication: { mode: strict, issuer: "https://<AI IdP>/realms/ai", audiences: [ai-gateway] }   # OAuth 路径
    apiKey: { mode: strict }                                                                             # 个人 Key 路径（同一 Key 存储）
    mcpAuthorization:
      rules:
        - 'mcp.tool.target == "invoice-query"'                                                          # 全员可见的只读 server
        - 'mcp.tool.target == "receipt-archive" && mcp.tool.name.startsWith("archive_")'                # 归档类工具
        - 'mcp.tool.target == "apollo-ops" && ("sre" in jwt.roles || apiKey.metadata.dept == "devops")'  # 运维写工具限角色

2.4 Skill 中心的权限管理

审核不是形式：对公开市场 31,132 个 Skill 的审计发现 26.1% 至少含一处漏洞（SkillProbe，2026，文档取证）；公开市场规模已达数万至数十万条目。公司技能库只收审核过的版本。

2.5 认证的全流程示例（结合场景演示）

以下八个场景覆盖 §1.1 的全部使用场景。图中 AI IdP 指 Keycloak；未特别说明时环境为内部 1 套。每个场景给出时序图、各跳校验点与失败处理。

场景 A · 首次接入：飞书登录管理中心，生成个人 Key

sequenceDiagram
    autonumber
    participant U as 员工
    participant P as 管理中心门户
    participant IdP as AI IdP（Keycloak）
    participant FS as 飞书开放平台
    participant KS as Key 服务
    participant DB as 网关 Key 存储（PostgreSQL）
    U->>P: 打开门户
    P->>IdP: OIDC 授权码 + PKCE
    IdP->>FS: 联邦登录（扫码或免登）
    FS-->>IdP: 用户信息（open_id、部门）
    IdP-->>P: id_token + access_token（sub = 内部稳定 id）
    P->>P: 自动建档：角色 = 内部开发者，套餐 = 默认档
    U->>P: 生成 Key（命名：笔记本）
    P->>KS: 申请签发（sub、dept、plan、channel=personal）
    KS->>DB: 写入 Key 哈希 + 元数据 + 预算对象
    KS-->>P: 明文 Key（仅此一次）
    P-->>U: 展示 Key 与一键配置片段

校验点：飞书侧校验企业成员身份；建档幂等（同一 sub 只建一次）；Key 明文只展示一次，服务端只存哈希；预算对象与 Key 同时创建；全部操作写审计。门户给出的配置片段：

# Claude Code（Anthropic Messages 入口）
export ANTHROPIC_BASE_URL=https://<网关地址>
export ANTHROPIC_AUTH_TOKEN=xf-ak-...
# Codex / pi agent / 其他 OpenAI 兼容工具
export OPENAI_BASE_URL=https://<网关地址>/v1
export OPENAI_API_KEY=xf-ak-...
# 公司 MCP 聚合端点（Claude Code，一次添加）
claude mcp add --transport http company https://<网关地址>/mcp --header "Authorization: Bearer xf-ak-..."
# Skill 插件市场（Claude Code，一次添加）
/plugin marketplace add https://<网关地址>/skills/marketplace.json

场景 B · Claude Code 调模型：Key 认证、别名授权、预算、故障转移、计量

sequenceDiagram
    autonumber
    participant CC as Claude Code
    participant GW as LLM 网关（编程池）
    participant DB as Key / 预算存储
    participant P1 as 厂商 A（priority 0）
    participant P2 as 厂商 B（priority 1）
    participant DP as 数据平台
    CC->>GW: POST /v1/messages model=coding-sota + Bearer 个人 Key
    GW->>DB: 查 Key（缓存未命中时）→ 元数据 + 预算余量
    GW->>GW: CEL：套餐允许 coding-sota？速率？预算余量？注入检测
    GW->>P1: 别名 → 虚拟模型 → 厂商 A（厂商 Key 只在网关）
    P1-->>GW: 503
    GW->>GW: 标记厂商 A 不健康（驱逐）· 重试选不同后端
    GW->>P2: 同一请求
    P2-->>GW: 流式响应 + usage（结束帧）
    GW-->>CC: 流式响应（头：actual_model、route_version）
    GW->>DB: 预算扣减（美元 / Token）
    GW->>DP: UsageRecord（sub、dept、actual_model、provider=B、failover_hop=1、tokens、cost、price_version）

校验点与失败处理：

Codex 走同一网关的 /v1/responses，pi agent 走 /v1/chat/completions，策略相同。

场景 C · 同一把 Key 接入公司 MCP：聚合、裁剪、参数策略、逐跳换发、业务 API

sequenceDiagram
    autonumber
    participant CC as Claude Code
    participant GW as MCP 网关（聚合端点 /mcp）
    participant PI as 策略处理器（ExtMCP）
    participant IdP as AI IdP
    participant M as 发票查验 MCP server
    participant XG as 业务网关（xforce-gateway）
    participant API as 发票查验业务 API
    CC->>GW: tools/list + Bearer 个人 Key
    GW->>GW: Key 校验 → 主体（sub、dept、channel=personal）
    GW->>GW: CEL 裁剪：登记表 ∩ 本人授权 ∩ 渠道；聚合多 server
    GW-->>CC: 本人可见工具列表
    CC->>GW: tools/call invoice_verify{files:[2]}
    GW->>PI: 参数校验 · 注入 tenant · 约束 · 决策记录
    PI->>IdP: 以网关客户端凭据申请代表该用户的短期令牌（aud=invoice-mcp，缓存）
    IdP-->>PI: 本跳令牌
    GW->>M: tools/call（本跳令牌；server 只接受来自网关的连接）
    M->>GW: 出向路由：调用业务 API（server 自己的令牌）
    GW->>IdP: 过渡桥：按用户代签用户中心令牌（仅 IdP 客户端可调、短 TTL、全量审计）
    GW->>XG: 携用户中心令牌
    XG->>API: 注入租户与用户头
    API-->>M: 结果
    M-->>GW: 结果 + _meta.billableUnits=2
    GW->>PI: ToolCallEvent 持久化（decision、policy_version、billable_units）
    GW-->>CC: 结果

校验点：Key 与 OAuth 两条路径在第 2 步汇聚为同一主体；tools/list 与健康检查不产生用量事件；第 7 步"Key 主体换用户令牌"是本方案新增的一跳（POC 只验证过 JWT 到 JWT 的换发），A-1 阶段验证 Keycloak 配置；阶段 1 的降级方案是集群内可信头 + mTLS，只用于只读工具。用户的原始用户中心令牌不进入任何下游。

场景 D · 业务人员在 Work 工具中接入：远程 MCP 连接器 + OAuth 授权页

sequenceDiagram
    autonumber
    participant W as Work 工具（Claude Work / ChatGPT Work / WorkBuddy）
    participant Pub as 公网入口（WAF / ALB / APISIX）
    participant GW as MCP 网关
    participant IdP as AI IdP（授权页）
    participant FS as 飞书 / 用户中心
    W->>Pub: 连接远程 MCP（无令牌）
    Pub->>GW: 转发
    GW-->>W: 401 + 受保护资源元数据（指向 AI IdP）
    W->>IdP: 动态注册或预注册客户端 → 授权码 + PKCE
    IdP->>FS: 用户飞书扫码（内部）或用户中心登录（客户）
    FS-->>IdP: 身份
    IdP-->>W: access_token（aud=ai-gateway、sub、channel=work-tool）
    W->>GW: tools/list（Bearer 令牌）
    GW-->>W: 该渠道可见工具（例如不含运维写工具）
    W->>GW: tools/call …
    GW-->>W: 结果（后续同场景 C）

说明：模型内置的 SaaS 型 Work 工具（Claude Work、ChatGPT Work）的模型调用不经我司网关，网关能管的是它们连接的远程 MCP 与安装的 Skill；WorkBuddy 若支持自定义模型端点与请求头，则模型调用同场景 B、MCP 同场景 C。渠道 work-tool 的工具面默认只含只读与低风险工具。

场景 E · 检索并安装 Skill：门户、插件市场、命令行、MCP 工具

sequenceDiagram
    autonumber
    participant U as 开发者 / 业务人员
    participant CC as Claude Code / Codex
    participant SC as Skill 中心（网关路由 /skills）
    participant IDX as 索引与签名服务
    participant Git as 技能库（GitLab）
    U->>CC: 添加公司插件市场（一次）
    CC->>SC: GET /skills/marketplace.json + Bearer 个人 Key
    SC->>IDX: 按主体可见性生成清单（名称、描述、版本、签名）
    SC-->>CC: 清单
    U->>CC: 安装 invoice-audit
    CC->>SC: GET /skills/invoice-audit/1.3.0.tar.gz
    SC->>Git: 拉取已审核版本（网关持有只读凭据）
    SC-->>CC: 包 + 签名清单
    CC->>CC: 校验签名 · 安装到本地技能目录
    SC->>SC: 审计：谁在何时安装了什么版本

四种入口共用同一套检索 API 与 Key 校验：门户网页检索；Claude Code 插件市场清单；命令行安装脚本（适配 Codex、Cursor 等按 Agent Skills 标准读取本地技能目录的工具）；MCP 工具 skill_search 与 skill_get（Agent 在对话中自助发现与安装，走场景 C 的授权链）。

场景 F · 外部：注册项目与应用，配置可用模型与 MCP，应用调用，SIT 晋级 PROD

sequenceDiagram
    autonumber
    participant Dev as 我司开发者
    participant P as 管理中心（SIT）
    participant FA as 飞书审批
    participant Repo as 策略仓 / 编译流水线
    participant IdP as AI IdP（SIT）
    participant App as 客户项目应用
    participant GW as 业务 LLM 池 / MCP 网关（SIT）
    Dev->>P: 新建 Project（客户、负责人、成本中心）→ 新建 Application（类型、代码仓）
    Dev->>P: 勾选可用模型别名、MCP server 与工具、预算、速率
    P->>FA: 发起审批（应用管理员 / 全局管理员）
    FA-->>P: 通过
    P->>Repo: 生成 RegistryEntry + 授权 IR → 编译 → 校验 → 发布到 SIT
    P->>IdP: 创建 OAuth 客户端（client_credentials）或应用 Key
    P-->>Dev: 应用凭据（SIT）
    App->>IdP: client_credentials → JWT（aud=ai-gateway、azp=app-id、env=sit）
    App->>GW: /v1/chat/completions model=ocr-multipage + JWT
    GW->>GW: CEL：别名 ∈ 应用授权集？预算（应用 × 租户）？
    GW-->>App: 响应 + 用量记录
    Dev->>P: 申请晋级 PROD（同一 IR，PROD 凭据另发）

晋级规则：同一份 IR 经 SIT 验证后，策略仓合并到 PROD 分支并再次审批；PROD 的应用凭据由 PROD 环境的 AI IdP 单独签发，SIT 凭据在 PROD 无效；应用的模型与 MCP 授权变更只改 IR，不改应用代码。

场景 G · 客户用户经我司 SaaS 功能调用：登录桥 + 应用代表用户

sequenceDiagram
    autonumber
    participant CU as 客户用户
    participant SaaS as SaaS 应用（前端 + 后端）
    participant UC as 用户中心
    participant IdP as AI IdP（登录桥）
    participant GW as 业务 LLM 池 / MCP 网关（PROD）
    CU->>SaaS: 登录（用户中心，租户 SSO 可用）
    SaaS->>UC: 用户中心令牌（对称密钥 JWT，8 小时）
    SaaS->>IdP: 服务端换发：携用户中心令牌 + 应用凭据
    IdP->>UC: 校验令牌与用户信息
    IdP-->>SaaS: AI 令牌（sub = 用户中心 userId、tenant、azp=app、aud=ai-gateway）
    SaaS->>GW: 调模型 / MCP（AI 令牌）
    GW->>GW: CEL：应用授权 ∩ 租户预算 ∩ 用户权限快照（授权适配器）
    GW-->>SaaS: 结果 + 用量（按租户 × 应用 × 商品）

场景 H · 撤销与轮换

• 离职：飞书通讯录事件或用户中心禁用 → 管理中心禁用该用户全部 Key、撤销 AI IdP 会话；网关 Key 缓存 TTL 不超过 60 秒，令牌短期有效，撤权目标只读 60 秒内生效、高风险写操作每次在线复核。
• 应用负责人变更或凭据疑似泄露：管理中心轮换应用凭据（新旧并行 24 小时），策略不变。
• 厂商 Key 轮换：只改密钥管理与网关 provider 配置，应用无感。
• 所有撤销与轮换写审计，含操作人、对象、原因、生效时间。

3. 技术选型

3.1 候选与评估口径

前序报告已横向评估过 LiteLLM、Kong AI Gateway、Envoy AI Gateway、new-api 等，本章只回答公司提出的问题：agentgateway 还是 Higress，以及哪些必须自研。评估依据是 §1、§2 的需求（一把 Key、MCP 三级授权与逐跳换发、Skill 中心、A2A、五种环境形态、私有化交付）与公司存量（无 Higress，南北向已有 APISIX / Kong / ingress-nginx，POC 已在 agentgateway 上验证 49 项检查）。

版本口径：agentgateway v1.5.0（2026-08-27 发布）、Higress v2.2.4（2026-08-13 发布），均以官方发布说明与文档为准，标注"文档取证"；未在文档中查到的能力标注"未取证"。

一个背景事实：2026 年独立商业 AI 网关正在被收编——Portkey 被 Palo Alto Networks 收购（5 月）、TensorZero 归档仓库（6 月）、Helicone 被 Mintlify 收购（3 月）（文档取证，awesome-ai-gateway 汇总）。选型偏向基金会治理的开源项目，并把策略资产与网关解耦，是对这类风险的对冲。

3.2 agentgateway 与 Higress 对比

3.3 选型结论与适用条件

结论：AI 策略执行点用 agentgateway；Higress 不引入。 五条理由：

1. 需求核心是"一把 Key 的元数据驱动授权 + MCP 三级授权与逐跳换发 + 计量字段"，agentgateway 原生覆盖；Higress 这三项要靠 Wasm 插件补。
2. 公司没有 Higress 存量，南北向不会因 AI 网关而重构；Higress 最大的优势在此用不上。
3. 五种环境形态里三种在客户侧，交付包越轻越好；agentgateway 单二进制、无 Nacos / Redis 依赖。
4. POC 已在 agentgateway 上跑通 49 项检查，团队已有踩坑记录；换 Higress 意味着重做验证。
5. A2A 后置但不需要另选组件。

什么情况下应重新评估 Higress： 公司决定把南北向统一到 Envoy 体系并替换 ingress-nginx；或要求"开箱即用控制台 + MCP 市场"且接受 Nacos / Redis 依赖并放弃自研管理中心；或团队具备 Go / Wasm 插件能力并愿意承担插件维护。三者目前都不成立。

风险对冲： 锁定 agentgateway 版本、只用扩展点不改源码；策略 IR 与网关配置解耦（编译器可换目标，例如 Envoy AI Gateway）；用量事件模型独立于网关日志格式。

3.4 自研功能清单

3.5 明确不做

不做 Harness（xagent、智能助手、客户 harness 都是客户端）；不改 agentgateway 源码；不自研限流、路由、协议转换、守卫；不做模型评测平台（只做评测路由与标签）；不复制用户目录、不持有用户中心签名密钥；不做 WAF 与南北向网关；不自建模型市场（Skill 中心只管公司技能库）。

4. 多环境

4.1 环境矩阵

内部 1 套落在生产主集群而不是 FAT 集群，原因是开发者每天依赖它，可用性要求接近生产；网关自身的配置与版本变更用外部 SIT 验证后再发布到内部与 PROD。

4.2 部署架构图

4.3 配置晋级与凭据隔离

• 策略仓三条分支（main 内部、sit、prod），同一份 IR 通过合并请求晋级：编译校验 → SIT 验证 → 审批 → PROD 发布；每次发布产生 config_version、policy_version、price_version，写进每条用量记录；可回滚。
• 凭据不跨环境：每个环境的 AI IdP 独立签发；个人 Key 只在内部环境有效；SIT 与 PROD 的应用凭据各自签发；厂商 Key 按环境分账号。
• 客户环境按版本号导入策略包，导入前校验签名与兼容版本；模式 A 的客户云上网关通过只读 GitOps 拉取自己的配置分支。

4.4 客户云上单开的两种模式

4.5 客户属地化交付包

交付包 = Helm 或 Compose 模板 + 镜像：agentgateway、策略处理器、轻量 IdP（Keycloak）、PostgreSQL、精简管理中心（本地账户、本地审批、用量查看）；本地模型引擎由客户或交付团队按 GPU 资源部署（vLLM / Ollama / TGI 已验证 OpenAI 兼容，MindIE 未取证）。同一策略格式与用量事件模型：策略包离线导入、用量记录签名与可验真导出、出境字段策略按路由与字段声明、单任务 Token 硬顶与超时熔断。MCP 两档：轻量内嵌只调产品自带工具；独立档对客户内网系统默认只读，写操作逐类声明并可人工暂停。

4.6 网络、隔离与 SLO

• 出站：迁移完成后应用容器出站只允许到网关与登记的 MCP server（NetworkPolicy）；厂商 Key 与下游令牌只在网关；MCP server 只接受来自网关的连接。
• 隔离：环境独立实例；模型与 MCP 独立发布单元、独立限流与连接池；编程池与业务池按计费模型与故障域拆池。
• SLO（沿用前序方案两档）：不含处理器路径 P95 不超过 30 毫秒；含参数覆写或 step-up 路径 P95 不超过 100 毫秒；配置收敛 P95 不超过 60 秒；审计完整率不低于 99.9%；凭据原值泄露为零。压测与热更新形态在内部试点期实测。

5. 实施路线与工程量

工程量合计约 27.5 人周（§3.4），3 人并行约 10–12 周到阶段 2 结束；阶段 3 起与客户项目节奏对齐。前序方案的 18–24 人周估算在此基础上增加了 Skill 中心（3.0）、Key 服务（约 1.5）、三方登录适配（约 0.5）、多环境打包（约 1.0）。

6. 待澄清问题

附录 A · 术语

附录 B · 与前序文档的关系

附录 C · 参考资料（2026-09-10 查阅）

• agentgateway 发布说明（v1.4.0、v1.4.1、v1.5.0）：https://github.com/agentgateway/agentgateway/releases
• agentgateway 文档：https://agentgateway.dev/docs/
• agentgateway 实践文章（LLM、MCP、A2A 一个数据面，Key 元数据与预算配置）：https://mehdihadeli.com/blog/agentgateway-ai-gateway
• Higress 仓库与发布说明（v2.2.0–v2.2.4）：https://github.com/higress-group/higress 、https://github.com/higress-group/higress/releases
• Higress 加入 CNCF（2026-03）：https://www.cncf.io/blog/2026/03/25/higress-joins-cncf-delivering-an-enterprise-grade-ai-gateway-and-a-seamless-path-from-nginx-ingress/
• awesome-ai-gateway（160 余个网关的汇总与 2026 年整合观察）：https://github.com/cuihuan/awesome-ai-gateway
• Agent Skills 开放标准与市场现状：https://blog.agentailor.com/posts/top-ai-agent-standards-2026 、https://skills-hub.ai/glossary/agent-skills-marketplace
• SkillProbe：对公开 Skill 市场的安全审计（31,132 个 Skill，26.1% 含漏洞）：https://arxiv.org/pdf/2603.21019