版本：v1.0 · 2026-09-13 · 评审稿 作者：Claude Code（樊国柱会话）
回答的问题：《企业 AI Gateway 选型调研与 POC · 2026》（下称"原报告"）第 03 章的加权评分里 Higress 8.7 分高于 agentgateway 8.5 分，而第 10 章与后续方案都选了 agentgateway。这是不是矛盾？依据是什么？
输入：原报告第 02–11 章与附录 A；POC 实测（7 场景 49 项检查、Higress 对照组、8 个坑）；需求评估（顾磊 4 条、翟保延 38 条、我的思考 16 条）；阶段 0 现状盘点；《云砺 AI 网关方案（公司版）》。
配套：01–05 文档；本报告的评分表由 diagrams/gen_selection_score.py 生成，可复算。
证据等级沿用原报告：实测证实（POC）、文档取证（官方文档与发布说明）、湖仓取证（研发本体湖仓）、源码取证、需自建、未取证。未标注者为设计判断。
0. 一页结论
- 不矛盾：8.7 与 8.5 不是选型排名。 原报告第 03 章的加权分测的是"文档记载的能力 × 立项九项诉求的权重"，附录 A 明确写着"评级不是排名，同档内产品定位不同，不可直接比较"；结论二把 Higress 与 agentgateway 定义为"定位互斥而非竞争"的两个首选。0.14 分的差距全部来自 ③ Skill 管理一项（Higress 靠独立组件 HiMarket 得 4 分，agentgateway 0 分，贡献 +0.64），而 ④ 权限、⑤ 可观测、⑦ A2A、⑨ 性能四项 agentgateway 反超。
- 评分之后发生的三件事改变了输入。 POC 实测证明"权限统一注入"只有 agentgateway 不写网关插件就能落地，Higress 对照组的 MCP 数据路径在时间盒内没有跑通；需求评估把权重从"立项诉求"换成"公司需求"，个人 Key 与预算、别名路由与故障转移、计量字段、MCP 三级授权、身份适配、私有化上调，Skill 与管理面变成自研项；现状盘点证实公司没有 Higress 存量，南北向是 APISIX、Kong、ingress-nginx 与 ALB + WAF。
- 只改一处实测能改的分，原口径下 agentgateway 已经反超。 把 Higress 的 ② MCP 网关从 5 分改为 3 分（对照组事实），其余不动，原报告口径的结果变成 agentgateway 8.52、Higress 8.06。
- 按公司需求重新打分，差距扩大到 2.4 分。 13 维、权重按需求强度设定：agentgateway 8.76，Higress 6.36。差距最大的三项是 MCP 治理、个人 Key 与预算、身份接入与私有化体积。
- Higress 只有在三个前提同时成立时才是更优解。 公司决定把南北向统一到 Envoy 体系并替换 ingress-nginx；Skill 与管理面直接用 HiMarket 与 Higress 控制台而不自研；接受 Envoy、Istio、Wasm 技术栈并自己写插件补 MCP 授权。反事实打分下 Higress 7.72 比 agentgateway 7.32。这三个前提今天都不成立。
- 决策：AI 策略执行点用 agentgateway，Higress 不引入。 退路是策略 IR 与网关解耦（POC 已同时编译出 Envoy AI Gateway 的路由片段）；复评触发条件写在 §4。原报告需要修订的表述列在 §5，主要是第 06 章"方案 A 主推"改为条件方案，第 10 章"存量 Higress"改为"对标候选"。
1. 问题：8.7 对 8.5，与"选 agentgateway"矛盾吗
1.1 原报告的评分在测什么
原报告第 03 章对 17 款产品按九个维度打 0–5 分，维度直接对应立项时的九项诉求，权重按诉求表述强度设定：① LLM 接入 15%、② MCP 网关 15%、③ Skill 管理 8%、④ 权限统一管控 15%、⑤ 可观测性 12%、⑥ 自身 API / CLI / MCP 10%、⑦ A2A 等企业能力 8%、⑧ 可扩展性 9%、⑨ 高性能 8%。三个前提值得重读：
- 能力按文档判断。 附录 A："能力评估以文档为准，第 01–08 章未做实机验证……'MCP 工具级 ACL''逐跳令牌换发''A2A 支持'这三项各家表述粒度差异很大，PoC 阶段必须逐项实测，不要按本表直接下单。"
- 评级不是排名。 附录 A："五档反映的是'是否可以现在进生产'与'在组合中扮演什么角色'，同档内产品定位不同，不可直接比较。"结论一更进一步：不存在一款网关吃下九项诉求，企业必须按"模型网关 + MCP 网关 + 资产注册中心"三件套选型。
- 两者被定义为互斥定位。 结论二：Higress 胜在中文生态、公开采用名单与 HiMarket；agentgateway 胜在协议纵深（LLM、MCP、A2A 一个策略面）、Rust 数据面与中立治理，并已被 kgateway、Istio ambient、llm-d 采用为数据面。
1.2 0.14 分差从哪里来
把每一维的加权贡献差（Higress 分减 agentgateway 分，乘权重，折算到 10 分制）拆开：
| 维度 | 权重 | agentgateway | Higress | 加权贡献差（Higress − agentgateway，10 分制） |
|---|---|---|---|---|
| ① LLM 接入 | 15% | 4 | 5 | +0.30 |
| ② MCP 网关 | 15% | 5 | 5 | +0.00 |
| ③ Skill 管理 | 8% | 0 | 4 | +0.64 |
| ④ 权限统一管控 | 15% | 5 | 4 | -0.30 |
| ⑤ 可观测性 | 12% | 5 | 4 | -0.24 |
| ⑥ 自身 API/CLI/MCP | 10% | 4 | 5 | +0.20 |
| ⑦ A2A 等企业能力 | 8% | 5 | 2 | -0.48 |
| ⑧ 可扩展性 | 9% | 4 | 5 | +0.18 |
| ⑨ 高性能 | 8% | 5 | 4 | -0.16 |
| 合计（10 分制） | 100% | 8.52 | 8.66 | +0.14 |
三点观察：
- Higress 领先的四项里，③ Skill 一项就贡献了 0.64 分，超过总差距的四倍。而这 4 分来自 HiMarket，原报告自己写明它是"独立部署的 Java 服务，依赖 Nacos，等于运维两套系统"，评估时要按两个产品计算成本。
- ⑥ 管理面与 ⑧ 可扩展性合计 0.38 分，测的是"产品自带控制台与 Wasm 插件生态"，不是"我们要不要自研管理中心、要不要写插件"。
- agentgateway 领先的四项（权限、可观测、A2A、性能）合计 1.18 分，恰好是后来 POC 与需求评估反复验证的方向。
1.3 原报告自己的两次改口
原报告不是在第 03 章之后就停住的。结论八与第 10 章写道："第 06 章给了三套组合并主推 Higress 生态一体化，前提是'能力按文档判断'。第 09 章的实测改变了一个变量：权限统一注入这件事，今天只有 agentgateway（以及未实测的 Envoy AI Gateway）能不写网关插件就落地；Higress 在 REST→MCP 与市场上仍是最快的，但做不了策略执行点。于是方案从'选一款网关'变成'分两层'。"第 11 章又把"存量 API 网关保留"标注为待盘点的假设，并把 E1 / E4（私有化与嵌入）列为选 agentgateway 的额外支撑。
换句话说，"评分 Higress 高、选型 agentgateway"在原报告内部已经是一条有证据链的推理，只是散落在第 03、09、10、11 章。本报告把它收拢并用新证据重新打分。
2. 评分之后发生的三件事
2.1 POC 实测：把文档判断换成实测判断
| 事实 | 证据 | 对评分的影响 |
|---|---|---|
| agentgateway 主线一份 YAML 配好认证、裁剪、守卫、两跳换发与 LLM 路由，加一个 457 行的处理器，一天跑通七个场景 49 项检查；部署到内网测试机后 48 / 49（唯一失败是 Claude Code CIMD 检查，因服务器出口访问 claude.ai 受地区限制） | 实测证实（原报告 9.2；POC 仓库 results/） |
④ 权限 5 分成立；② MCP 网关 5 分成立 |
| 参数覆写不再是全场缺口：ExtMCP 处理器可整体替换 JSON-RPC 参数（传 T-999 只能拿到自己租户的数据） | 实测证实（9.6 修正 7.6 表） | agentgateway 自建项从三件缩为两件半 |
| 逐跳换发实测两跳：每跳一个受众，绕行直连全部 401；换发 p50 22–33 毫秒，缓存后摊平 | 实测证实（9.2 S4、9.4） | ④ 权限与 ⑤ 可观测的分数有实测支撑 |
| Higress 对照组：控制台 API 8 步、12 秒完成 REST→MCP 转换与消费者鉴权；但权限模型是消费者级，没有工具级、参数级判定，没有 RFC 9728 元数据代发，没有逐跳换发 | 实测证实（9.3 Q1） | ② MCP 网关不应得 5 分：托管与转换强，治理弱 |
| Higress 对照组 MCP 数据路径在时间盒内未跑通：转换器生成的配置被 mcp-server 插件自己拒绝（security 字段数组与对象不一致），插件解析失败让同一监听器上的 key-auth 失效（LLM 路由无凭据也 200）；打开 mcpServer 后依赖 Redis，配上 Redis 后 Envoy 仍停在 INITIALIZING | 实测证实（9.5 坑 07、坑 08） | 运维成本项：状态依赖（Redis）与插件配置错误的爆炸半径 |
| 体积：agentgateway 镜像 103 MB，Keycloak 477 MB，Higress all-in-one 1.57 GB；POC 稳态内存约 2.0 GB，其中 Higress 0.9 GB | 实测证实（9.1；POC 记录） | 私有化与客户云上单开偏好小体积 |
| MRTR 审批网关层做不了，改为"拒绝 + 审批回执 + 同动作重试"；这一点对两家都成立 | 实测证实（坑 04） | 不影响两者相对分数 |
结论：POC 没有证明 Higress"不可用"，证明的是它"到达不了第 07 章要求的粒度"，而且在 MCP 路径上工程摩擦显著。原报告 10.4 已把"Higress 对照未跑通 MCP 路径"列为未决项，措辞是"结论限于工程摩擦显著，不是不可用"。本报告沿用这个口径。
2.2 需求评估：权重从"立项诉求"换成"公司需求"
原报告的权重按立项九项诉求设定。之后收到的需求把重心明显移动了：
| 需求来源 | 要求 | 落到哪个维度 | 对两家的影响 |
|---|---|---|---|
| 顾磊需求三：逐次 token / 费用 / 延迟记录与可视化，Token 套餐余量与刷新时间 | 每 Key 的预算与余量查询、每请求成本字段 | 个人 Key 与预算；计量字段 | agentgateway v1.5.0 原生：每 Key 美元与 Token 预算、滚动窗口、SQLite / PostgreSQL 持久化、管理 API 查余量（文档取证）；Higress 有 Token 限流与配额插件（需 Redis），美元成本与余量需自建 |
| 顾磊需求一、二、四与翟保延 A2 / A9：编程与业务分池、同模型跨厂商故障转移、别名版本化、价目版本 | 虚拟模型优先级组、健康驱逐、价目目录 | 别名路由 · 故障转移 · 成本 | agentgateway 的 failover 优先级组 + 健康驱逐 + 价目目录成本计算（文档取证）；Higress 的负载均衡与 fallback 可用，价目与成本口径需自建 |
| 翟保延 B1–B7：用户本人令牌按受众换发、发现与访问控制、参数校验与剥离、登记表、默认拒绝 | 工具级与参数级授权、逐跳换发、RFC 9728 | MCP 治理 | agentgateway 实测；Higress 需 Wasm 插件与提案中的 OAuth 资源服务器行为 |
| 翟保延 I2、B8 与用户中心源码取证：身份由凭据承载；第三方入口需授权页；用户中心令牌是对称密钥 JWT、无 PKCE / JWKS / 换发 | OAuth 2.1 受保护资源元数据、JWT 校验、IdP 适配、Cross App Access | 身份接入 | agentgateway 实测代发元数据、Keycloak 适配、换发；v1.4.0 加入 Cross App Access（文档取证）；Higress 的 JWT / OIDC 插件面向 HTTP，MCP 侧为提案 |
| 翟保延 E1–E6 与公司版方案的客户云上单开、属地化 | 同一策略格式跑中心与嵌入两种形态；离线包体积与依赖 | 部署形态与私有化体积 | agentgateway 单二进制、可选 PostgreSQL；Higress 需 Envoy + Istio + 控制台，MCP 会话层依赖 Redis |
| 公司版方案 I-5"一把 Key"：个人 Key 同时用于 LLM / MCP / Skill，使用方零配置 | Key 元数据进入授权、限流、预算、日志 | 个人 Key 与预算 | agentgateway 的 apiKey 策略元数据可进 CEL、指标、日志、限流、预算（文档取证）；Higress 的 consumer 模型不携带可编程元数据 |
| 公司版方案 Skill 中心：公司技能库、审核、签名、可见性、市场清单 | 自研 Skill 中心，不采用公开市场产品 | Skill 中心 | HiMarket 的市场能力不再是加分项：它是面向订阅与计费的市场，公司需要的是审核与签名的技能库；且是独立 Java + Nacos 系统 |
| 公司版方案管理中心：项目 / 应用注册、Key 自助、授权配置、审批联动 | 自研业务控制台 | 管理面 | Higress 控制台与 hgctl 更成熟，但两家的控制台都替代不了自研管理中心；权重下调 |
2.3 现状盘点：没有 Higress 存量
阶段 0 用研发本体湖仓与部署源码盘点（04-现状盘点与证据索引.md），三条事实直接影响选型：
- 公司没有 Higress。 南北向是 APISIX（自研管理端）、Kong 3.9 与旧版 Kong、ingress-nginx / ACK / TKE、istio-ingressgateway、traefik，公网接入是阿里云 DNS + WAF + ALB / SLB（湖仓取证）。原报告第 10 章"存量 Higress / APISIX 留在南北向"里的 Higress 是假设；2026-09-10 用户已明确纠正：Higress 是对标候选，不是存量系统。引入 Higress 意味着新增第四套南北向栈，而不是复用。
- 全部内部 AI 流量今天经一个统一代理（new-api）转发，另有 8 个服务直连厂商（湖仓取证）。选型要解决的是"把这些流量收到一个带身份、预算、计量与策略的执行点后面"，与南北向无关。
- 用户中心令牌是对称密钥 JWT，无 PKCE / JWKS / 换发（源码取证）。AI 侧必须有标准 OAuth 2.1 与换发能力，这是网关与 IdP 的组合能力，agentgateway 与 Keycloak 的组合已在 POC 验证。
3. 按公司需求重新打分
3.1 新口径：13 维与权重
维度从公司版方案 §1–§4 的需求推导，权重按需求强度设定，来源写在表中；Skill 中心与管理面因已定为自研项而降权，南北向因存量不换而只保留"契合度"一项。
3.2 打分表
分数 0–5，口径与原报告一致（5 = 一等公民且有产品化实现；4 = 完整可用但有边界；3 = 基本可用需补齐；2 = 半成品或路线图；1 = 边缘支持；0 = 无）。证据等级见"依据"列。
| 维度 | 权重 | agentgateway | Higress | 加权贡献差（Higress − agentgateway，10 分制） | 需求来源 |
|---|---|---|---|---|---|
| 模型入口与协议互转 | 10% | 5 | 4 | -0.20 | A1 · I-1 |
| 别名路由 · 故障转移 · 成本 | 9% | 4 | 3 | -0.18 | A2 · A9 · 顾磊二 / 四 |
| 个人 Key 与预算 / 套餐 | 10% | 5 | 3 | -0.40 | 顾磊三 · I-5 · A4 |
| MCP 治理（登记 · 裁剪 · 工具级 / 参数级 · 换发） | 15% | 5 | 2 | -0.90 | B1–B7 · 第 07 章 |
| 身份接入（OAuth 2.1 元数据 · JWT · IdP 适配） | 8% | 5 | 3 | -0.32 | I2 · B8 · 用户中心取证 |
| 计量与可观测字段 | 7% | 5 | 4 | -0.14 | A4 · A10 · C3 · C4 |
| 扩展方式与自研成本 | 8% | 4 | 3 | -0.16 | 策略处理器 · 不改源码 |
| 部署形态与私有化体积 | 8% | 5 | 3 | -0.32 | E1–E6 · 客户云上 / 属地化 |
| 与存量南北向的契合 | 5% | 4 | 2 | -0.20 | 阶段 0 盘点 |
| Skill 中心 | 5% | 1 | 3 | +0.20 | I-4 · 公司技能库 |
| A2A | 3% | 5 | 2 | -0.18 | 公司版 §1.2（低优先级） |
| 管理面（控制台 / CLI / ops MCP） | 4% | 4 | 5 | +0.08 | 管理中心自研 |
| 成熟度 · 生态 · 团队技能 | 8% | 3 | 5 | +0.32 | 第 02 章硬数据 |
| 合计（10 分制） | 100% | 8.76 | 6.36 | -2.40 |
每一维的依据：
| 维度 | agentgateway 依据 | Higress 依据 |
|---|---|---|
| 模型入口与协议互转 | OpenAI Chat / Responses、Anthropic Messages、Gemini 原生入口自动互转（v1.5.0 文档取证）；POC S5 实测流式与加权路由 | ai-proxy 覆盖约 35 家厂商，v2.2.0 加入 Claude Code 模式（文档取证，未实测）；厂商覆盖更广，入口协议互转弱于前者 |
| 别名路由 · 故障转移 · 成本 | 虚拟模型权重 / 优先级 failover / 条件（CEL）路由、健康驱逐、重试、价目目录（文档取证）；无按价选路 | ai-load-balancer、fallback、模型映射（文档取证）；无价目目录与成本计算 |
| 个人 Key 与预算 / 套餐 | 虚拟 Key + 任意元数据进入 CEL / 指标 / 日志 / 限流 / 预算；每 Key 美元与 Token 预算、滚动窗口、SQLite / PostgreSQL 持久化；界面生成、掩码、吊销（v1.5.0 文档取证） | key-auth 消费者、ai-token-ratelimit、ai-quota（需 Redis）（文档取证）；无美元预算与可编程元数据 |
| MCP 治理 | S1 裁剪、S2 参数覆写、S3 step-up 与审批回执、S4 逐跳换发全部实测；MCP 2026-07-28、Tasks、多 server 聚合与工具前缀（文档取证） | 对照组实测：消费者级鉴权，无工具级 / 参数级，无元数据代发与换发；MCP 数据路径未跑通（坑 07、08）；MCP 2026-07-28 与 openapi-to-mcp（文档取证） |
| 身份接入 | RFC 9728 元数据代发与 Keycloak 适配、CIMD、RFC 8693 换发实测；Entra 原生 MCP 认证、Cross App Access（v1.4.0 文档取证） | jwt-auth / OIDC 插件面向 HTTP（文档取证）；MCP 的 OAuth 资源服务器行为为独立提案 |
| 计量与可观测字段 | 每请求 token 分项（含缓存、推理、图像）、首字延迟、成本与价目、OTel 日志 / 指标 / 链路（文档取证）；流式结束帧 usage 完整性未实测 | ai-statistics、Prometheus / OTel（文档取证）；美元成本与价目版本需自建 |
| 扩展方式与自研成本 | CEL 策略、ExtMCP / ExtProc / webhook 守卫，不写插件；处理器仍需自建（POC 457 行 Python，一天） | Wasm 插件（Go / Rust / C++）生态最完整（文档取证）；本方案的工具级 / 参数级授权需自写插件；插件配置错误会拖垮同一监听器（坑 07 实测） |
| 部署形态与私有化体积 | 单二进制 103 MB 镜像，可选 SQLite / PostgreSQL；docker / 独立二进制 / Kubernetes（实测） | all-in-one 1.57 GB；生产形态 Envoy + Istio + 控制台，MCP 会话层依赖 Redis（实测） |
| 与存量南北向的契合 | 作为 AI 策略执行点与 APISIX / Kong / ingress 并存，不承接公网、不替换任何存量 | 与存量南北向职责重叠；ingress-nginx 迁移工具存在（文档取证）但公司无替换计划 |
| Skill 中心 | 无 Skill 能力；只能为自研 Skill 中心提供路由与 Key 校验 | HiMarket 提供 Skill 市场（上传、订阅、安装）；独立 Java 服务、依赖 Nacos；治理模型是市场而非审核签名的技能库 |
| A2A | 原生 A2A 路由与 JWT（文档取证） | JSON-RPC 转换插件；Agent Card 管理在路线图（文档取证） |
| 管理面 | 管理界面（引导、虚拟 Key、日志）、agctl、数据库存储配置（文档取证） | 控制台、hgctl、higress-ops MCP Server（文档取证） |
| 成熟度 · 生态 · 团队技能 | 2025-03 创建；LF / AAIF；4.7k star、234 贡献者、近 12 月 43 次发版；被 kgateway、Istio ambient、llm-d 采用；无公开采用名单；Rust 排障门槛、中文资料少（第 02 章硬数据） | CNCF Sandbox（2026-03）；9.3k star、197 贡献者、Top3 占 59%；20 家公开采用；中文社区最完整；Envoy 运维经验易招募（第 02 章硬数据） |
3.3 结果与敏感性分析
| 口径 | 说明 | agentgateway | Higress | 差 |
|---|---|---|---|---|
| S0 原报告口径 | 第 03 章 9 维、文档判断 | 8.52 | 8.66 | +0.14 |
| S1 原口径 + POC 修正 | 只把 Higress ② MCP 网关从 5 改为 3，其余不动 | 8.52 | 8.06 | -0.46 |
| S2 公司需求口径 | 本报告 13 维 | 8.76 | 6.36 | -2.40 |
| S3 反事实 | 南北向统一到 Envoy 并替换 ingress-nginx（权重 15%，Higress 5 分）；Skill 用 HiMarket、管理面用 Higress 控制台不自研（权重 10% 与 8%）；接受写 Wasm 插件补 MCP 授权（MCP 治理降到 8%，Higress 3 分）；私有化降到 4% | 7.32 | 7.72 | +0.40 |
读法：
- S0 到 S1 只动了一个实测能改的分，结论已经翻转。这就是原报告结论八说的"实测改变了一个变量"。
- S2 是本方案的正式口径。差距最大的三项（MCP 治理 0.90、个人 Key 与预算 0.40、身份接入与私有化各 0.32）都对应公司需求里的 P0 项。
- S3 给出 Higress 反超的条件：三个前提同时成立。任何一个不成立，Higress 都回到 7 分以下。这三个前提今天都不成立，但它们是可以被组织决策改变的，因此写进 §4 的复评触发条件。
4. 结论与决策记录
决策：AI 策略执行点（LLM 网关、MCP 网关、A2A 网关的数据面）采用 agentgateway v1.5.x；Higress 不引入；南北向沿用 APISIX / Kong / ingress-nginx / ALB + WAF。状态：建议（待评审）。
理由（按权重）：
- 公司需求的核心是"一把 Key 的元数据驱动授权 + MCP 三级授权与逐跳换发 + 每请求计量字段 + 每 Key 预算"，agentgateway 原生覆盖并经 POC 实测；Higress 这四项要靠 Wasm 插件、Redis 与提案中的能力补齐。
- 公司没有 Higress 存量，南北向不因 AI 网关而重构；Higress 最大的优势（南北向一体化、ingress-nginx 迁移路径）用不上。
- 五种环境形态里三种在客户侧，交付包越轻越好；agentgateway 单二进制、无 Nacos / Redis 依赖。
- POC 已在 agentgateway 上跑通 49 项检查并积累了 8 个坑的绕法；换 Higress 意味着重做验证。
- A2A 虽后置，但不需要另选组件。
Higress 的正确位置：它仍是原报告结论二里的首选之一，胜在南北向一体化、中文生态、公开采用名单与 HiMarket。它适合"没有南北向网关、需要开箱即用控制台与市场、团队有 Envoy 经验"的企业；公司不是这种情况。
退路：
- 策略 IR（ToolPermissionSet、ModelRouteSet、RegistryEntry）与网关配置解耦，编译器可换目标；POC 已同时输出 Envoy AI Gateway 的 MCPRoute 片段，原报告 10.3 Week 11–12 预留了对照实测。
- 锁定 agentgateway 版本、只用扩展点不改源码；用量事件模型独立于网关日志格式。
- 若组织决定南北向统一到 Envoy 体系，Higress 与 kgateway 都可作为南北向层与 agentgateway 串联（原报告第 06 章方案 B 的形态）。
复评触发条件（任一成立即重新打分）：
- 公司决定替换 ingress-nginx / APISIX，把南北向统一到 Envoy 体系。
- 管理中心与 Skill 中心决定不自研，改用现成控制台与市场产品。
- 团队具备并愿意维护 Go / Wasm 插件能力。
- agentgateway 出现治理或维护风险（发版停滞、基金会状态变化、关键能力闭源）。
- Higress 的 MCP OAuth 资源服务器行为、工具级 / 参数级授权与逐跳换发以内置能力发布并可实测。
5. 对原报告的修订建议
| 位置 | 现有表述 | 建议 | 原因 |
|---|---|---|---|
| 结论二 | Higress、agentgateway、Envoy AI Gateway 三个首选，定位互斥 | 保留，补一句"就本公司需求而言，策略执行点已收敛到 agentgateway，见第 10 章与选型复评" | 结论本身正确，缺少指向 |
| 结论三 | "主报告写'从 Higress 起步'，方向对但要补两句" | 改为"'从 Higress 起步'的前提是存量有 Higress 或需要南北向一体化；公司两者都不具备，起步点是 agentgateway" | 阶段 0 盘点证否了前提 |
| 第 03 章加权表 | Higress 8.7、agentgateway 8.5 | 表下加注："② MCP 网关一项按 POC 实测应为 3 分（治理能力），修正后 Higress 8.1；加权分不是选型排名，见附录 A 与选型复评" | 让读者不再把 8.7 与 8.5 当结论 |
| 第 06 章方案 A"主推" | Higress 生态一体化 · 最快见效 | 改为"条件方案：适用于无南北向存量或计划统一到 Envoy 的企业"；主推改为第 10 章两层方案 | 与第 10 章一致 |
| 10.1 目标架构 | "L3a · 南北向 API 网关（存量复用）Higress / APISIX / Kong" | 改为"APISIX / Kong / ingress-nginx（存量）；Higress 为对标候选，非存量" | 用户 2026-09-10 纠正；湖仓取证 |
| 10.4 未决项 | Higress 对照未跑通 MCP 路径，需社区或 K8s 形态再验证 | 保留；补充"本轮选型不依赖该验证结果，触发条件见选型复评 §4 第 5 条" | 避免被读成"等验证后再定" |
| 附录 A 证据缺口一 | agentgateway 评级建立在治理与技术证据而非采用证据 | 保留；补充"POC 与内网测试机部署为其增加了实测证据，但公开采用名单仍缺" | 如实更新证据等级 |
以上修订不改变原报告的数据与方法，只改变指向与前提说明。是否回写原报告由评审决定。
6. 常见疑问
评分表还有用吗？ 有。它回答"在开源市场里各家能做什么、成熟到什么程度"，用于筛选候选池与识别出局产品（TensorZero 归档、Portkey 停更、Kong OSS 闭源、APIPark 停更）。它不回答"公司该买哪一个"，因为权重来自立项诉求而不是公司需求，分数来自文档而不是实测。
为什么不两个都用，Higress 做南北向、agentgateway 做策略执行点？ 这正是原报告第 10 章的形态，前提是"存量有 Higress"。公司没有，南北向已有 APISIX、Kong 与 ingress-nginx；为 AI 网关再引入一套 Envoy + Istio 栈没有收益。
Higress 的 MCP 能力不是也实现了 2026-07-28 规范吗？ 是，v2.2.4 的发布说明如此（文档取证）。规范一致性与治理粒度是两回事：公司需要的是工具级与参数级授权、RFC 9728 元数据代发、逐跳换发，这些在 Higress 上要靠插件与提案，在 agentgateway 上已实测。
agentgateway 太年轻，风险怎么办？ 用三件事对冲：策略 IR 与网关解耦（可编译到 Envoy AI Gateway）、锁版本只用扩展点、用量事件模型独立于网关。它的治理在 Linux Foundation，下游被 kgateway、Istio ambient、llm-d 采用，近 12 个月 43 次发版；这些比 star 数更能说明存续性。
如果以后要 Skill 市场怎么办？ 公司版方案的 Skill 中心是审核与签名的技能库，不是市场；若将来需要面向客户的市场形态，HiMarket 可以作为独立组件评估，与网关选型无关。
附录 A · 评分明细与复算
评分表由 diagrams/gen_selection_score.py 生成：四组口径的维度、权重与分数写在脚本顶部，运行即输出 Markdown 表与 diagrams/selection-score-delta.svg。修改任一分数或权重后重新运行即可复算；建议评审时先对 §3.2 的每一格给出异议，再看总分。
附录 B · 证据清单
- 原报告：《企业 AI Gateway 选型调研与 POC · 2026》第 02 章硬数据（GitHub API，口径 2026-09-04）、第 03 章九维矩阵、第 06 章三套方案、第 07 章权限统一注入层、第 09 章 POC 实测（9.2 场景表、9.3 Q1、9.4 数字表、9.5 八个坑、9.6 修正）、第 10 章方案确定、第 11 章需求评估、附录 A 评分口径。
- POC 仓库与结果：
ai-gateway-poc（scenarios/run.py、results/）；内网测试机部署记录。 - 需求：顾磊《AI Gateway 需求说明》；翟保延《对公司 AI 网关的需求 · 2026-09-04》；《AI网关验证场景》；接纳矩阵
02-需求评估与接纳矩阵.md。 - 现状：
04-现状盘点与证据索引.md（湖仓 SQL 与结果、用户中心源码 file:line）。 - 产品文档（2026-09-10 查阅）：agentgateway 发布说明 v1.4.0 / v1.4.1 / v1.5.0；Higress 发布说明 v2.2.0–v2.2.4；Higress 加入 CNCF 公告（2026-03-25）；awesome-ai-gateway 汇总。
- 公司版方案：
05-公司AI网关方案.md§1–§4、§3.2 对比矩阵。