第 9 章 AI 网关与统一流量治理¶
API 网关（API Gateway）与服务网格（Service Mesh）为服务通信提供了认证、路由、流量控制和可观测能力。大语言模型（Large Language Model，LLM）、模型上下文协议（Model Context Protocol，MCP）与智能体（Agent）的普及，并没有使这些能力失效，而是引入了新的治理语义：响应可能持续流式输出，用量与费用需要按 token 核算，工具调用可能产生业务副作用，一项任务还可能跨越多轮交互、多个会话以及等待和恢复阶段。
AI Gateway 在模型、工具和 Agent 的访问路径上建立一致的策略执行点，并与任务执行系统协同。本章按治理对象讨论 LLM Gateway、MCP Gateway 和 Agent Gateway 三种可组合的语义，随后介绍统一治理与控制面联动。它们是本章采用的分析框架，不是行业统一的成熟度阶梯，也不要求企业依次建设三个独立产品。
本章以 Higress 为主要参考实现，并对照模型代理、托管服务和推理入口等路线。协议说明以 MCP 2026-07-28 版本为基线；Higress 实现以提交 f053bb08360d432a1226d4b61eb69871c74b9021 为核验基线。产品能力、协议要求和架构建议分别表述，配置示意不视为可直接部署的产品 Schema。通信章讨论协议的交互与恢复语义，本章重点讨论这些语义对网关准入、转发、计量与策略执行的要求。
9.1 AI Gateway 的边界：模型、工具、Agent 与流量治理入口¶
9.1.1 从接入模型到治理调用¶
单个应用接入一个模型时，通过软件开发工具包（Software Development Kit，SDK）直连往往已经足够。随着模型服务、使用团队和工具数量增加，接入问题会转化为共同的治理问题：调用者是谁，凭证由谁保管，模型故障时允许切换到哪里，哪些工具和参数可以使用，费用归属哪个项目，拒绝和重试又如何追溯。
这些问题适合在调用入口集中处理，但并非所有 Agent 问题都属于网关。任务成功标准、业务状态、检查点内容和恢复流程需要业务模型与执行系统共同定义；网关只保证准入、转发与记录的一致性，既不能仅凭请求成功断言任务完成，也不能替代执行系统保证状态恢复。
9.1.2 AI 流量增加了哪些约束¶
AI 流量并不全部是长连接或有状态流量。真正影响网关设计的是同一入口需要同时承接短请求、长流式响应、大上下文以及多步调用，并对不同类型选择合适的处理方式。
| 流量特征 | 工程影响 | 网关应提供的能力 |
|---|---|---|
| 长连接与流式输出 | HTTP 成功响应之后仍可能出现流内错误；首个响应字节不一定是首个有效 token | 区分连接、首字节、首 token、流式空闲及总时限，识别流内错误 |
| 大请求体与上下文 | 全量缓冲的内存成本随并发放大，内容解析可能成为数据面瓶颈 | 报文和事件大小限制、增量解析、按路由控制内容缓冲 |
| 按 token 或其他资源计费 | 准入时的估算与结束时的实际用量不同，并发调用可能同时消耗余额 | 速率限制、配额、严格预算分别建模，支持结算与对账 |
| 多轮交互与长程任务 | 亲和有助于缓存复用，但不能替代状态持久化和恢复 | 可信标识关联、路由亲和、分层观测，与执行系统协作 |
服务端发送事件（Server-Sent Events，SSE）只是传输形式，不能直接充当完整业务事件的边界。数据面收到的字节切片可能包含半个事件，也可能包含多个事件；首个 SSE 事件还可能只是心跳或元数据。因此，首 token 时延（Time to First Token，TTFT）的统计必须明确起止点，不能简单等同于 HTTP 首字节时延。
同样，键值缓存（Key-Value Cache，KV cache）的复用是推理性能优化，不是业务状态恢复。把相似上下文路由到同一推理实例可能减少重复预填充，但缓存未命中通常应表现为性能变化，而不应造成业务 Task 丢失。
9.1.3 三种可组合的治理语义¶
图 9-1 三种可组合的治理语义。这是本章按治理对象建立的分析框架，不表示线性的能力升级路径。
| 治理语义 | 直接治理对象 | 主要问题 | 不承担的责任 |
|---|---|---|---|
| LLM Gateway | 模型调用及其实际尝试 | 选择哪个模型或端点，如何限流、容灾和计量 | 判断模型输出是否满足业务成功标准 |
| MCP Gateway | MCP 请求及工具调用 | 如何代理协议，当前身份能否调用指定工具及参数 | 将工具可发现等同于已授权、健康或可执行 |
| Agent Gateway | Agent 接入及与任务关联的流量 | 如何做身份、路由、亲和、并发控制和跨调用关联 | 定义 Task、业务 State、Checkpoint 或恢复语义 |
三种语义可以部署在同一数据面，也可以由不同组件承接。统一的关键不是所有能力位于同一进程，而是身份映射一致、策略边界清晰、调用记录能够关联，且同一次上游调用不会因穿过多个组件而被重复计费。
把三种语义放进一次完整调用会更直观。以“客服 Agent 查询订单并申请退款”为例：任务先经 Agent 入口接入，网关校验任务委托身份，并按能力标签把它路由到具备订单与退款工具的运行时；该任务产生的模型调用经 LLM Gateway 完成模型路由与失败降级；订单查询属于只读工具调用，由 MCP Gateway 做工具鉴权后直接放行；申请退款属于资金操作，网关挂起它并进入审批，批准后按新的准入条件重新校验委托范围、参数摘要与预算预留，才执行退款调用；工具结果与用量随后回写任务账本，供业务系统判定这项任务的结果。整条链路可以压缩为：Agent 入口 → 模型路由 → 工具鉴权 → 审批后重新准入 → 结果回传。
9.1.4 与既有基础设施和执行系统的边界¶
| 组件 | 主要责任 | 与 AI Gateway 的关系 |
|---|---|---|
| API Gateway | 请求入口、认证、路由和通用流量策略 | 可以承载 AI 协议适配与治理插件 |
| Service Mesh | 服务身份、双向传输层安全认证（mutual TLS，mTLS）及服务间流量治理 | 为 AI 服务通信提供基础安全和发现能力 |
| Registry | 资源目录、端点、版本和声明能力的管理 | 被网关或控制面查询、集成，不因集成而成为网关的业务职责 |
| Harness / Orchestrator | 执行控制循环、步骤调度与协作编排 | 通过网关访问模型和工具，并上报执行关联信息 |
| Agent Runtime | 执行生命周期、资源管理、检查点持久化与基础设施恢复 | 接收路由流量，按业务恢复契约运行任务 |
| 业务应用 | Task 定义、成功标准与任务账本 | 保有业务权威，可授权 Verifier 判定 Outcome |
| 获授权 Verifier | 依据成功标准、State 与 Evidence 判定 Outcome | 消费执行结果与证据，不因评分或观察而自动获得判定权 |
Higress 将协议适配、限流、统计等能力组织为 WebAssembly（Wasm）插件，运行在 Envoy 数据面上，并通过基于 Istio 的控制面管理相关配置。这是一种可复用的实现路线，而不是所有 AI Gateway 必须遵循的架构。模型代理也可以通过应用层中间件提供类似能力，托管服务则可能同时承接模型采购、账户和计费。
生态比较需要对应到具体版本。原 Envoy AI Gateway 项目现称 Agent Router，其 v1.0.0 于 2026 年 6 月 23 日正式发布并标记为正式可用（General Availability，GA）；产品发布为 v1.0 不代表所有控制面 API 都已进入 v1。Kong、APISIX 等既有网关也提供 AI 相关能力，选型仍应落到具体版本、数据路径和运维边界，而不是只比较名称。
9.1.5 集中治理不等于集中所有执行¶
企业可以先统一凭证托管和模型入口，再建立用量归因与工具授权，最后逐步引入路由实验和评估回归。每一步都应有独立的验收目标，例如凭证是否不再分散到客户端、用量是否能归属到项目、拒绝是否有可追溯依据，而不是以插件数量衡量建设进度。
在既有网关上扩展可以复用证书、身份与运维体系，但 AI 长连接、内容缓冲和协议迭代可能影响其他业务。独立部署有利于容量和发布隔离，却增加了基础设施负担。常见折中是共享身份和策略管理，按流量类型隔离数据面。
网关自身也必须按关键基础设施设计。多副本解决实例故障，受控的共享状态支撑跨实例配额；共享存储、外部策略服务和内容检测服务的故障行为则需要逐项定义。不能因为网关是多副本，就认为其依赖已经没有单点，也不能因为状态写入了 Redis，就认为所有一致性要求自然成立。
9.2 LLM Gateway：模型路由、降级、容灾与成本控制¶
9.2.1 把选择、可靠性和成本放在同一条路径上¶
LLM Gateway 需要在一次调用中协调三个问题：选择满足要求的模型或端点，控制失败与重试的影响，并对所有实际消耗负责。便宜的模型如果导致大量返工，总任务成本可能更高；自动容灾如果忽略协议兼容和计费语义，也可能把可用性故障转化为质量或成本事故。
图 9-2 模型调用准入与预算结算。阈值检查与严格预算是两种不同承诺，后者要求调用前原子预留，而不仅是响应后扣减。
9.2.2 统一接口与能力差异¶
OpenAI 风格的 /v1/chat/completions 和 Anthropic 风格的 /v1/messages 是常见的接入契约。网关可以通过适配器转换请求和响应，但工具调用、图像输入、推理内容、缓存用量和停止原因等字段并不总能无损映射。统一接口首先应声明支持的能力子集，再约定不支持的参数如何返回错误，而不是静默忽略差异。
Higress 的 ai-proxy 支持多种模型服务和协议适配。参考提交的 provider 注册表包含厂商服务、自托管引擎、通用适配器和聚合服务，因此类型数量不能直接解释为独立模型厂商数量，应按实际接入所需的 provider 与字段进行验证。
统一契约的另一个价值，是让计量、限流和统计模块复用明确的字段语义。这个契约仍需要记录适配器版本、实际 provider 与模型、请求模型别名和原始用量来源，避免协议转换之后无法对账。客户端看到同一个模型名，不应意味着平台可以不经验证地替换其实际能力。
9.2.3 模型选择与端点选择应分开¶
| 路由方式 | 决策对象 | 适用条件 | 主要约束 |
|---|---|---|---|
| 静态映射与权重 | 模型别名、版本或服务 | 需要稳定、可解释的灰度和主备关系 | 映射变更必须做能力与质量回归 |
| 成本感知路由 | 满足能力门槛的候选模型 | 已有可验证的质量下限与价格口径 | 不只看单次价格，还要看重试和返工成本 |
| 语义路由 | 不同能力模型 | 请求分类器经过评估，且有明确回退路径 | 分类错误会改变输出质量，分类本身也有成本 |
| 推理端点选择 | 同一模型或兼容服务的实例 | 可取得队列、在途请求或缓存相关信号 | 信号时效、缓存局部性与负载均衡需要权衡 |
Gateway API Inference Extension 的 InferencePool 已有稳定 v1 API，用于描述推理后端集合等入口资源；端点选择器（Endpoint Picker，EPP）根据其具体实现进行调度。队列长度、KV cache 占用和前缀缓存感知属于实现或插件提供的调度信号，不是所有 v1 实现必备的算法，也不等同于按任务语义自动挑选模型。
该项目 v1.6.0 的职责进一步聚焦 API、符合性验证和轻量 EPP，完整 EPP 等实现迁往 llm-d。讨论具体调度机制时，应绑定实现版本；不能把 API 稳定性、扩展实现成熟度和算法效果合并为一个结论。
Higress ai-load-balancer 的参考实现提供全局在途请求、前缀关联及基于运行指标的选择方式。其可借鉴之处在于把跨网关实例的共享信息与数据面选址结合起来。但网关记录的前缀关联只是缓存可能可用的信号，不能证明推理引擎仍持有该缓存；缓存驱逐、实例重启或模型版本变化后都需要允许失配和重新选择。
9.2.4 可靠性：先判断能否重试，再选择重试目标¶
错误分类应先于重试。限流响应需要结合重置时间、账户配额和替代端点策略处理；服务端错误只有在调用语义允许时才适合重试；认证错误一般应终止并修复凭证。上下文超限也不应简单通过截断历史“解决”，因为这会改变任务输入，应由应用或 Harness 决定是否压缩上下文、切换到兼容的长上下文模型，或明确失败。
流式响应一旦向客户端提交，网关通常不能透明地重放整段结果。更重要的是，“尚未收到响应体”不等于“上游尚未执行”：请求可能已经被计费，甚至已经触发某些副作用。重试许可需要同时考虑接口幂等性、上游执行不确定性和客户端协议，而不能仅根据 HTTP 状态或是否收到首包决定。
每次实际尝试都应有独立的 attempt 标识，并受最大次数、总截止时间和成本额度约束。切换到另一 provider 前还要检查工具、结构化输出、数据地域和模型能力是否兼容。没有经过验证的兜底路径，应返回可解释的失败，而不是以“自动降级”为名改变业务契约。
凭证或端点摘除是另一类机制。连续失败达到阈值后，可以暂停选用该目标，并通过冷却或健康检查恢复；真实模型探活可能产生费用，应限制频率并避免多副本重复放大。
多层恢复叠加是这类机制最容易失控的地方。如果 SDK 客户端对一次逻辑调用最多尝试 3 次，网关对每次转发又最多重试 3 次，那么一次用户可见的调用最多会到达上游 9 次；供应商侧是否重投还不受控制。每一层都认为自己的上限是 3，端到端却没有 3 这个约束——重试次数、并发压力和费用会以乘积方式放大。
| 层级 | 允许重试的条件 | 必须持有或传递的预算 |
|---|---|---|
| SDK / 调用方 | 调用幂等，或确认尚未提交执行 | 总截止时间、业务级尝试上限与成本上限 |
| 网关 | 尚未向客户端提交响应，且调用语义允许 | 每次转发的尝试额度与绝对截止时间 |
| 上游 / 供应商 | 不可控 | 按“可能已执行、可能已计费”处理 |
因此尝试预算必须跨层传递，而不是每层各自解释一个超时值：总截止时间应是绝对时间，网关转发时只保留必要的传输与处理余量；剩余尝试额度可以由调用方给出，并由网关按 call_id 原子扣减，耗尽后返回明确的预算耗尽错误，而不是再试一次。每次实际尝试都要用稳定的 call_id 与 attempt_id 关联，让跨层观测能把多次尝试还原为一次逻辑调用；重试、摘除与模型切换也要分开记录，否则一次故障会被多层恢复机制反复放大，且无法归因。
9.2.5 超时与流式解析：明确测量边界¶
连接超时用于约束建连，首字节超时用于识别上游长时间无响应，TTFT 描述有效生成开始前的等待，流式空闲超时约束连续事件间隔，总截止时间控制整个调用的资源占用。它们可以同时存在，但不应互相代替。例如，持续发送心跳的流可以一直不触发空闲超时，却始终没有输出有效内容。
SSE 解析需要跨字节切片重组事件，并设置单事件长度、累计缓冲和解析时间上限。轻量计量模式可以只保存计数和有限解析状态，不保存完整问答；内容改写和审计则需要额外缓冲。所谓“不缓冲全文”不等于完全没有内存开销，应在目标并发下测量实际占用。
部分模型协议需要显式请求流式 usage，例如支持 stream_options.include_usage 的接口。网关应只对支持该字段的适配器注入，并识别正常流尾、异常中断和取消。缺少 usage 不能记录为零消耗，客户端取消也不能证明上游停止生成；这些记录需要保留估算或未结算状态，后续与服务商账单或执行记录对账。
9.2.6 预算语义：速率、配额与严格上限不是一回事¶
| 机制 | 控制目标 | 常见实现 | 可以承诺什么 |
|---|---|---|---|
| 请求速率限制 | 单位时间请求数量 | 每秒请求数（Queries per Second，QPS）或令牌桶 | 控制准入速度，不直接控制 token 总成本 |
| token 时间窗限制 | 一段时间的累计用量 | 请求前检查，结束后累计实际 token | 控制用量增长；存在在途消耗和并发超限窗口 |
| 余额型配额 | 主体可用额度 | 准入时查余额，结束后扣减 | 近实时额度控制，不天然是严格并发预算 |
| 严格预算 | 不超过授权额度 | 可证明的最大消耗、原子预留、结算与退款 | 在计费边界和执行约束均成立时提供上限保障 |
“请求前检查、响应后扣减”无法单独保证硬上限。假设余额为 100，两次最大消耗分别为 80 的请求同时通过余额检查，最终消耗就可能达到 160。响应后的原子扣减可以避免丢账，但不能撤销已经发生的消耗。
严格预算需要在准入时满足以下不变量：
检查和预留必须在同一原子操作或等效一致性事务中完成。调用结束后按实际消耗幂等结算，释放多余预留；如果实际消耗可能超过预留，说明所谓最大值并不可靠，此时只能声明有界超额或软预算，而不能继续承诺严格上限。
预留需要覆盖输入、受约束的最大输出及该接口的其他计费项，重试也必须单独占用额度。对流式中断或执行结果未知的请求，不能因租约到期就无条件退款，应先确认执行终止或按保守规则等待对账。仅限制并发只能缩小超支范围；只有在途调用的最坏消耗也受到约束，才可能形成严格上限。
多层预算同样需要一致性。组织、团队、项目和任务额度同时生效时，准入必须验证相关层级的可用额，并避免只预留一层、另一层失败后留下悬挂记录。token 配额与金额预算还应分开：相同 token 数在不同模型、缓存命中类型和价格版本下可能产生不同费用。
9.2.7 Higress 实现的可用范围与故障语义¶
参考提交中的 ai-token-ratelimit 在请求阶段检查窗口，响应结束后累计实际 token；ai-quota 按 consumer 检查余额并在响应结束后扣减。二者都不能仅凭现有检查与后结算机制宣称严格并发预算。
两者在 Redis 故障下的分支行为并不一致，也不能概括为统一的失败语义；部署前需要针对所选版本逐项验证读失败、写失败、超时与恢复后的对账，具体分支说明见本章实现说明。
预算策略需要表达的设计信息（账本范围、预留键、结算与对账等）见本章实现说明；它不是 Higress 插件字段，也不能直接提交给其控制面。
落地时应把上述要求映射到选定组件的真实 Schema 与测试用例；若现有插件仅支持阈值控制，就如实声明边界，或将严格预算交给具备一致性能力的预算服务。
9.2.8 缓存与方案选择：优化总成本，而非单次 token 数¶
语义缓存可以减少重复问题触发的上游生成，但缓存命中不代表整个请求零成本，向量计算、检索和缓存维护仍有开销。缓存键还必须区分租户、权限范围、模型版本、系统提示和知识版本，不能让语义相似绕过数据隔离。对含副作用的工具调用不应简单重放缓存结果；对强时效或创造性任务，应明确适用边界与失效策略。
模型代理、托管聚合服务和网关插件路线各有侧重。以 LiteLLM 为代表的代理路线便于在应用生态中集成，Portkey 等服务提供不同程度的托管控制与观测，OpenRouter 聚合模型访问，Higress 则强调与既有入口治理和数据面扩展结合。选型应验证实际协议覆盖、数据出域、费用口径、容量和故障行为，不能从部署形态直接推导“能力完整”或“性能更高”。
路由稳定性、缓存命中、失败恢复和任务返工需要共同评估。一个可解释、可回退的简单策略，往往比缺少测量依据的自动切换更容易建立可信的生产基线。
9.3 MCP Gateway：工具协议代理、资源发现与权限隔离¶
9.3.1 工具接通之后，还需要控制执行权¶
MCP 使用 JSON 远程过程调用（JSON Remote Procedure Call，JSON-RPC）表达客户端与服务端的交互，提供工具、资源和提示等能力。它降低了接入成本，却不会自动解决企业授权、凭证托管、工具健康或业务副作用问题。
一个工具出现在清单中，只能说明它被服务端通告；调用者是否有权执行、依赖系统是否可用、这次调用是否成功，仍需独立判断。MCP Gateway 因此应将协议代理、资源目录集成、授权和实际执行结果分开治理。
图 9-3 MCP 发现、授权与执行的分离。Registry 提供目录信息，网关执行入口策略，工具与后端系统负责实际操作；三者不能相互替代。
9.3.2 版本基线与兼容范围¶
MCP 不同版本在握手、会话、订阅和任务机制上存在差异。2025-03-26 引入 Streamable HTTP，2025-11-25 引入实验性 Tasks；2026-07-28 采用逐请求元数据与 server/discover，并将 Tasks 移到可选扩展。协议演进的完整脉络见分布式通信章，本节保留网关实现必须核验的差异。
采用 initialize 握手的 Legacy 端点与采用逐请求元数据的 Modern 端点，需要不同的代理处理。网关应声明支持的版本集合、桥接方向及能力子集，并分别验证发现、调用、订阅和扩展任务。支持核心工具调用，不等于支持所有扩展；协议无状态，也不等于后端业务无状态。
9.3.3 逐请求元数据：协议说明不是调用者身份证明¶
MCP 请求的准入可以按“认证—协议校验—授权—转发”四步理解：认证回答“谁在调用”，由独立于协议的凭据完成主体映射；协议校验按版本检查头部镜像、方法与报文约束；授权按主体、工具与参数决定是否放行；转发按声明策略重新构造上游请求。Modern 协议的逐请求元数据只服务于第二、四步——它们说明请求的协议形态与能力，不能替代第一、三步的身份和权限判断。
| 能力或元素 | 网关支持范围 | 说明与约束 |
|---|---|---|
| 协议代际识别 | Legacy 与 Modern 均可接入 | 按端点声明与配置识别，桥接方向必须显式声明 |
| 能力发现 | initialize（Legacy）与 server/discover（Modern） | 作为路由与可见清单的输入，不代表授权、健康或可执行 |
| 工具调用 | 两种代际均支持 | 鉴权通过后转发；Modern 请求按方法校验名称镜像 |
| 变更订阅 | subscriptions/listen（Modern） | 默认关闭，按路由显式开启 |
| 任务扩展 | tasks 扩展（Modern） | 默认关闭，双方显式支持后启用 |
| 协议桥接 | 仅 Modern 下游到 Legacy 上游（参考提交） | 反向路径未声明支持 |
逐请求元数据的字段级要求（哪些必需、哪些推荐、哪些镜像头适用于哪些方法）与完整报文示例，属于实现细节，见本章实现说明。网关只需把握一条边界：协议说明不是调用者身份证明。
网关不能对不需要名称的方法强制要求名称镜像，也不能把所有名称字段都解释为 params.name；头部可以辅助轻量分类和路由，但最终执行前仍需验证其与正文一致，避免头部鉴权和正文执行面对不同对象。
server/discover 提供的是端点当前通告的版本与能力，它不证明依赖健康、已获授权或必然成功；能力声明、权限检查与结果观测需要分别保留。
版本与弃用政策也应精确理解：核心规范功能的弃用窗口不等于实现必须长期接受所有旧版本，实际支持的版本集合需要明确声明，安全例外另有规则。
9.3.4 Registry、代理插件与服务发现配置的分工¶
Registry 属于资源和数据管理职责，维护服务端点、版本、声明能力、所有者及生命周期信息。控制面或网关可以查询它生成路由和可见清单，但目录本身不授予当前 Task 的执行权限，也不取代资源服务器的授权检查。
在 Higress 的参考提交中，mcp-server 提供工具托管、REST 到 MCP 的转换以及 MCP 代理等能力；mcp-router 插件可按 server/tool 前缀处理工具调用路由。这个事实不能进一步扩展为它独立实现了所有工具聚合、授权或注册管理能力。McpBridge 则是服务发现配置资源，不能与协议转换插件混称。
健康检查也应分层。连接成功回答的是端点可达，协议发现回答的是能否通告兼容能力，受控的业务探测才可能验证工具依赖。对写入、支付等工具，不应为了健康检查而执行真实副作用；应使用专用探测或只读路径，并单独记录权限和依赖状态。
9.3.5 安全边界：默认拒绝与不可绕过的部署条件¶
工具授权通常需要表达调用者、目标服务、工具和参数之间的关系。访问控制列表（Access Control List，ACL）可以从服务级白名单起步，再向高风险工具和参数细化；输入 Schema 校验只保证类型和结构合规，并不证明业务授权成立。
过滤 tools/list 可以减少模型误选无权工具，但 tools/call 仍必须再次鉴权。权限应取调用者原有授权、工作负载授权、任务委托范围和资源侧限制的交集，不能由模型声明的身份、工具描述或 clientInfo 扩大。
网关只有在凭证不下发、出口网络受控、服务发现和域名解析收敛、直连路径被禁止且旁路受到审计时，才有条件成为不可绕过的策略执行点。若 Agent 仍持有直连凭证和网络出口，网关只是集中入口，不能声称“天然不可绕过”。
代理认证还要尊重令牌的目标受众和委托关系。适用 MCP 授权规范的 HTTP 资源服务器应校验令牌受众、权限和生命周期；上游凭证应来自明确的凭证托管或委托机制，不能任意透传为网关签发的下游令牌。长期密钥应由受控秘密管理设施提供，避免进入客户端配置、明文日志和版本库。
Origin 校验、Content-Type 与 Accept 检查、报文大小限制、JSON-RPC 结构校验和出口地址约束共同构成入口边界。其中协议要求应按版本执行，实现额外设定的报文上限则需标明配置来源。某个实现使用 1 MiB 限制，不代表 MCP 规范对所有端点都规定这一上限。
9.3.6 协议桥接：支持方向和能力子集必须显式声明¶
跨代际桥接不是简单替换 HTTP 头。Modern 下游调用 Legacy 上游时，代理需要处理初始化、消息映射、会话标识以及上游响应语义。Higress 参考提交的 mcp-server 明确支持这一方向，并将上游 Legacy 握手隔离在单次交换内；Legacy 下游到 Modern-only 上游的反向路径未声明支持，图中因此只画单向桥接。
单次交换隔离可以避免网关长期持有上游协议会话，但也引入重复握手开销，并限制对跨请求能力的透明代理。支持工具发现和调用，不等于支持所有订阅、服务端主动请求或 Tasks 扩展。协议策略、桥接方向和能力范围应当是显式配置和验收项，不能靠隐式探测与重试掩盖不兼容。
出口请求应按上游 RPC 重新构造，默认不透传下游 Cookie、会话标识、内部路由头和不适用的参数头。认证信息仅按明确策略生成或委托；日志避免记录带密钥的地址与请求头。代理保留的是经过验证的协议语义，而不是下游报文的任意细节。
9.3.7 实践案例：REST-to-MCP 与参数级治理¶
把已有 REST API 暴露为 MCP 工具时，适配层需要定义工具描述、输入 Schema、请求构造和结果裁剪。以地址查询为例，调用者只需提供结构化地址和可选城市，服务端凭证由受控配置注入；响应可以裁剪为经纬度和必要的行政区信息，减少无关上下文。
请求模板必须进行正确的参数编码，并限制可变主机、路径和出站目标，避免把模板工具变成服务端请求伪造（Server-Side Request Forgery，SSRF）的入口。对数据库工具，使用字符串前缀判断“只读 SQL”并不可靠，应结合受限数据库账户、受支持的查询接口与资源端权限。
| 工具场景 | Schema 校验 | 业务策略还必须约束 |
|---|---|---|
| 数据查询 | 字段类型、分页参数 | 数据库或数据集范围、行级权限、可执行操作 |
| 支付 | 金额格式、收款方结构 | 金额阈值、收款方范围、审批和幂等键 |
| 集群管理 | 集群、命名空间、资源参数 | 允许的环境、资源种类、操作动词和临时授权 |
| 文件读取 | 路径或文件标识格式 | 允许目录、租户归属、符号链接与数据分级 |
自然语言可以帮助管理员表达治理意图，例如“生产环境只允许查询”，但它应先转化为结构化策略，经冲突检查、影响预览、回归验证和授权发布之后执行。运行时不宜临时依赖模型自由解释权限，相同身份、资源和参数应得到可解释的一致判定。
工具输出仍属于需要按来源和风险处理的数据，不能因为经过网关就自动升级为高可信指令。内容检测可以提供风险信号，但提示注入防护还依赖权限隔离、参数约束、Harness 的工具结果处理以及资源端最小权限，不能由单一检测插件包办。
9.3.8 集中入口是纵深防御的一层¶
工具数量少、边界清晰时，可以在应用或框架中完成接入和权限控制；当多个 Harness、团队和工具共享平台时，集中入口能够减少策略复制并收敛凭证。代价是网关成为高价值安全目标，需要保护配置、秘密、管理接口和审计数据。
框架、网关和资源服务器应各自保留必要检查。框架理解当前任务意图，网关执行跨框架的统一策略，资源服务器限制最终操作。三者协作提供的是纵深防御，而不是由任何一层宣称整个调用链已经绝对安全。
9.4 Agent Gateway：入口路由、任务关联、租户与配额¶
9.4.1 长程任务的入口治理¶
一个 Agent Task 可能包含多个 Session、多轮模型和工具调用，也可能因审批、人工补充信息或基础设施故障进入等待与恢复。成本分散在这些阶段，单次请求指标难以解释整体效率；反复重试和失控循环还可能挤占同租户的预算与并发资源。
Agent Gateway 的作用，是将可信身份和任务关联信息带入入口策略，为跨请求的路由、配额与观测提供统一接口。它可以拒绝新的调用、报告预算压力、将请求转到声明具备相应能力的 Runtime，但 Task 如何暂停、保存状态和恢复，应由业务任务模型与执行系统决定。
图 9-4 Task 账本与执行责任边界。任务关联信息可以穿过网关，业务状态与恢复语义不能因此转移到网关。
9.4.2 任务关联对象与责任来源¶
沿用构建篇的任务、状态与执行对象，本节只列出网关需要关联的标识及其权威来源。
| 对象 | 回答的问题 | 权威来源或责任 |
|---|---|---|
| Task | 要完成什么，成功标准是什么，当前处于哪个业务阶段 | 业务应用的任务模型；可通过父子关系表达分解 |
| Session | 哪一段交互或执行上下文属于同一会话 | 会话所属应用或执行系统；Task 可以跨多个 Session |
| Turn | 该会话中的哪一轮交互或控制循环 | Harness 定义并记录边界 |
| Call / Attempt | 哪次逻辑调用、哪次实际执行产生了用量 | 调用系统与实际执行点提供关联记录 |
| State | 已完成的业务事实、待处理事项及状态迁移规则 | 业务 Task / State 模型 |
| Checkpoint | 恢复时需要哪些状态、版本和引用 | 业务模型定义内容与恢复契约；Runtime 负责相应持久化和基础设施恢复 |
| Outcome | 是否达到业务成功标准 | 业务应用或获授权 Verifier 根据 State 与 Evidence 判定 |
状态持久化、检查点与副作用核对由业务模型、Harness 和 Runtime 共同完成，具体机制见状态存储与运行环境相关章节。网关需要保留关联信息，使入口故障和重试不会丢失调用与任务之间的关系。
网关可以保存路由亲和键、任务标识映射、在途计数、配额预留和观测关联信息。即使某种实现出于路由需要缓存了不透明的执行引用，也不应解释业务 State、定义 Checkpoint 结构或决定从哪个业务步骤恢复。入口实例重启不应成为任务真相丢失的原因。
9.4.3 Agent 路由：选择入口能力，而不是判断执行结果¶
Agent 路由可以依据租户、工作负载类型、能力标签、可用工具、环境要求和运行时健康选择目标。目录中的能力标签只提供候选集合，仍需验证版本兼容、授权和目标环境。亲和可以按可信 Session 或 Runtime 关联键实现一致性哈希或查表，但亲和失败后的行为必须由执行系统给出契约。
例如，Coding Agent 的会话请求可能需要回到能够访问工作区的运行时；目标不可用时，网关可以返回暂不可路由或转交受支持的恢复入口，却不能把请求任意转到一个空运行时后声称“已经续跑”。某次 429 也不必然意味着工作区丢失，真正的连续性取决于工作区持久化、检查点和重试边界。
Agent Client Protocol（ACP，智能体客户端协议）主要服务于编辑器、集成开发环境（Integrated Development Environment，IDE）等客户端与编码 Agent 的交互；截至核验日期，ACP v2 仍为 Draft。Agent2Agent Protocol（A2A，智能体间协议）面向 Agent 间通信与任务协作，其 v1.0.0 已正式发布。两者的适用范围和成熟状态不同，不应合称为“尚未定型的一类协议”。
当入口从数据中心移到开发者本机，任务路由的落点有了新的选择。业界已经出现把“想”与“做”分开的用法：前沿模型只负责读目标、拆解与评审，把有界的具体执行显式交给成本低得多的模型完成，整体花费可以相差一个数量级。开源项目 HiRoute 把这种分工做成产品机制，并向前推了一步——执行方不只是一个更便宜的模型，还可以是另一个完整的工作 Agent。
这些做法通常仍停留在同一个 Harness 内换模型；HiRoute 的委派目标是工作 Agent 本身：Codex、DeepSeek Harness、Claude Code 等工作 Harness 都可以被同一个主 Agent 调起，每个都带着自己的上下文管理、工具链、权限模式与原生登录。于是一个后端重构任务可以交给 Codex 的计划，一批机械性的小改动可以交给使用低成本模型的 DeepSeek 计划，两者由同一个主 Agent 分别发起；用户留在熟悉的工作界面里，被选中的工作 Agent 由 HiRoute 启动、隔离与管理，无需迁移账号，原配置保持不变。
这些选择都落在“计划”上：每个已发布的计划都有稳定调用名与用途，声明执行工作 Agent、候选模型与原生思考设置。主 Agent 按用途查询并以任务为单位显式提交——路由不依赖模型自动分类，落点可预测、可复核；任务有独立身份，可以等待、取结果、继续或取消，并保持受理时的计划版本执行，后续配置变化不会暗中改变进行中的工作。“什么活交给谁”由此从一次次手工切换，变成一条可查询、可委派、可复现的路由。
| 维度 | HiRoute 中的选择 |
|---|---|
| 执行 Agent（Harness） | Codex、DeepSeek Harness 等不同工作 Agent，各自保留原生工具链与登录 |
| 模型分工 | 每个计划独立声明候选模型与原生思考设置，与主 Agent 自己的模型互不影响 |
| 用途与身份 | 计划有稳定调用名与用途，按用途选择，不依赖模型自动分类 |
| 任务生命周期 | 提交、等待、取结果、继续、取消；task/run 独立身份，重复提交幂等 |
网关可以理解这些协议的身份、路由和关联字段，但应保持薄适配层。协议中的任务状态或完成通知是互操作信息，不天然等同于业务 Task 的最终 Outcome；从协议对象映射到业务任务，需要应用明确约定。
9.4.4 租户隔离：身份、财务归属与执行资源是不同维度¶
配额应绑定经过认证的主体和明确的财务归属，而不是客户端 IP 或连接数。人、工作负载、Agent 实例和 Task 描述不同身份或执行关系；组织、团队、项目则描述财务归属，两者是正交维度。一个 Agent 可以服务多个项目，一个项目也可以使用多个 Agent，不能将二者混成固定的单一层级。
并发隔离同样要区分入口在途请求与 Runtime 中的活动任务。HTTP 请求结束之后，异步任务可能继续运行；只有 Runtime 或相应调度系统能准确判断执行槽位是否释放。网关可以限制入口并发和发起速率，任务并发需要与执行系统的账本协同。
加权公平队列、租户槽位和优先级可以抑制长任务的资源挤占。借用空闲容量不意味着可以立即收回已经执行的操作或已经产生的费用；抢占策略需要明确取消、检查点和补偿行为。预算接近阈值时，平台可发出信号，由 Harness 根据任务模型停止新增步骤、保存进度或请求额外授权。
9.4.5 从 Session 分析扩展到 Task 分层账本¶
Session 聚合适合回答“一段交互花了多少成本”，Task 账本才适合回答“一项长程任务从发起到结束花了多少成本、恢复了几次、结果是什么”。本章采用以下归因链路：
这是一条分析下钻路径，不强制所有系统采用相同存储树。多 Agent 协作可以通过 parent_task_id 等明确的父子关系归集；Session 承载多个业务任务、并行 Turn 或共享调用时，需要关联表和明确分摊规则，不能任意重复归因。
task_id 应来自业务应用，session_id 和 turn_id 应来自其权威执行上下文，网关可以生成请求或尝试标识。入口收到客户端关联头时，需要绑定已认证主体并校验租户范围，防止通过伪造 Task 或项目标识转移费用、污染他人的账本。缺失可靠关联时可以记为待归因，但不应自行编造一个业务 Task。
| 账本层级 | 主要观测内容 | 能够回答的问题 |
|---|---|---|
| Attempt | 实际端点、计费模型、用量来源、状态、错误和耗时 | 哪次重试消耗了成本，是否存在未知执行结果 |
| Call / Turn | 多次尝试、工具交互、上下文变化 | 本轮为什么慢，成本集中在哪些调用 |
| Session | 一段交互的累计用量、等待与失败分布 | 某段会话是否出现重复调用或上下文膨胀 |
| Task | 跨会话归集、恢复阶段、工具与运行资源费用、Outcome 引用 | 长程任务总成本、完成效率和恢复成本如何 |
网关记录是调用账本的一部分，不应冒充完整任务账本。Runtime 资源费用、绕过网关的受控执行路径、审批等待和业务恢复事件需要由各责任系统补充。链路追踪（Trace）帮助关联调用路径，但采样、缺失 span 和跨恢复分段使其不能自动成为财务或 Task 的权威账本。
成本计算还应区分供应商原始 usage、平台估算、价格版本、缓存输入折扣、币种或内部 credits 换算。模型返回的工具调用意图只是模型输出，不代表工具已经执行；工具实际费用应以执行记录结算，并通过调用标识与模型记录关联。
9.4.6 Higress 的位置：提供计量与日志底座¶
Higress ai-quota 和 ai-statistics 可以分别提供按 consumer 的额度控制、模型用量及会话关联日志。它们有助于建立统一调用口径，但不能仅凭一个 Session 头就获得跨恢复的 Task 账本，也不自动拥有业务 Outcome。
生产日志应默认记录身份引用、Task / Session / Turn 关联、Call / Attempt 标识、实际模型、用量来源、状态、时延和策略版本。问题、回答和工具参数等内容字段按风险和需求开启，设置长度限制、采样、脱敏、访问控制和留存周期。记录模型生成的 tool_calls 与记录工具实际执行结果，应使用可区分的事件类型。
分析服务可以通过 API、命令行界面（Command-Line Interface，CLI）或 Skill 暴露 Task 列表、Session 详情和调用下钻能力。这些查询接口属于观测与分析服务，不必因此成为网关控制面的内置责任。分析 Agent 可以定位成本变化和形成优化假设，但结论应能回到原始记录复核，并区分相关性与已验证原因。
9.4.7 结果判定与设计权衡¶
网关的请求成功率与业务任务完成率分别统计。业务应用或获授权的验收组件依据成功标准、Task State 与 Evidence 提供 Outcome，网关只关联该结果；缺少 Outcome 或成本未结算的任务，应保留相应状态。验收流程由构建篇和协作章说明，网关侧的重点是避免把 HTTP 成功、会话结束或模型自述完成计入业务成功。
9.5 统一治理：身份、权限、预算、审计与审批¶
9.5.1 统一身份、策略与关联规则¶
统一身份与审批的通用模型见治理篇，本节只说明它们如何约束实际转发。如果模型、工具与 Agent 入口各自定义身份和成本维度，同一调用者就可能在不同路径受到不一致的授权与配额约束；共享主体映射、策略语义和关联标识，同时允许调用账本、财务账本、业务 Task 账本分别保有权威边界，是转发侧对统一治理的基本要求。
图 9-5 有拒绝与异步审批的治理流程。审批是持久化的业务状态，不是把 HTTP 请求无限挂在网关中的一个同步步骤。
9.5.2 身份到转发的映射：主体、委托与凭证¶
| 转发环节 | 需要的输入 | 网关的检查与动作 |
|---|---|---|
| 主体映射 | 认证结果（OAuth、mTLS、API Key 等） | 映射为稳定策略主体与财务归属，清除客户端伪造的内部身份头 |
| 委托核验 | 任务委托的范围、时效与受众 | 与调用者原有权限取交集，不因协议自述或客户端声明扩大 |
| 凭证处理 | 上游凭证的引用与用途 | 仅按显式策略生成或委托，默认不透传下游凭证 |
| 记录 | 主体、委托与判定依据 | 写入审计与账本，支持撤销、对账与追溯 |
身份类型、凭证生命周期与委托模型的通用设计见治理篇；对转发而言只有一条硬约束：Task 委托必须可验证、可撤销、范围清晰，且不能超出委托者原有权限，也不要求每个 Task 都签发独立令牌。
Higress 中的 consumer 是策略主体抽象。认证插件可以将不同凭证映射为 consumer，后续配额和统计插件共享这一标识。入口必须清除或覆盖客户端伪造的内部主体头，并为跨代理传递定义信任边界，不能直接信任外部传入的 x-mse-consumer 等字段。
9.5.3 策略执行：拒绝分支与结果分支同等重要¶
权限模型的建模方法（RBAC、ABAC 等）见治理篇；对转发而言，网关必须在放行前完成认证、鉴权与预算准入，并为每次判定记录命中的规则、版本和拒绝原因，避免权限矩阵变成不可解释的黑箱。
未通过认证、授权或预算准入的请求应终止并记录判定。需要审批的请求进入专门的审批工作流；无需审批的请求可以在完成必要的预算预留后执行。审计既记录准入依据，也记录实际执行结果，不能以“放行日志”代替“执行成功日志”。
预算沿用 9.2 节的分层语义。软阈值可以触发告警，严格上限需要原子预留和可验证的最大消耗。审批可以授权新的额度或预算变更，但该变更本身必须受治理并进入账本；不能只给调用加一个白名单标记，就跳过结算或隐去费用。
9.5.4 审批如何约束转发：挂起、重新准入与超时¶
审批的组织方式与建模见治理篇。落到转发路径上，约束只有一条：审批未决的请求不得转为实际执行。挂起期间网关不长时间持有 HTTP 连接，等待与通知由业务侧承接；审批记录需要包含调用者、工具及版本、参数摘要、风险与有效期，供执行前重新核对。
| 审批状态 | 转发侧的处理 | 必须记录的内容 |
|---|---|---|
| 待审批 | 不执行高风险操作，连接可结束，等待由业务侧承接 | 申请对象、参数摘要、风险与过期时间 |
| 批准 | 重新校验身份、委托、参数摘要与预算后才转发 | 批准者、批准范围与时效 |
| 拒绝 | 终止，不隐式替换工具或参数 | 拒绝依据 |
| 超时或撤销 | 终止，保持未执行状态；不自动降级为只读 | 超时或撤销事实 |
| 执行结果未知 | 不盲目重试，交由业务查询、对账或补偿 | 已提交事实与幂等键 |
批准不意味着后续必定放行。等待期间身份可能过期、参数可能改变、预算可能被其他调用占用，因此执行前必须重新准入。审批记录应绑定工具、版本、参数摘要和任务上下文，回调需要认证并防重放；重复回调和调用重试不能产生重复副作用。
也不应将“审批超时”自动解释为“改成只读执行”。这会改变原始请求含义，可能造成意外数据暴露；如需只读替代方案，应形成新的、可见的请求并重新授权。对于无幂等支持的外部操作，超时后的执行结果不确定必须交由业务查询或补偿流程处理，不能由网关盲目重试。
9.5.5 审计材料与业务 Evidence 的区别¶
结构化审计可以记录谁在何时申请了什么操作，命中哪条策略，审批如何决定，实际执行结果是什么。它为复盘提供可追溯材料，但并不天然构成业务判定需要的 Evidence。哪些来源、完整性保证和内容可以用于判断任务成功，应由成功标准与 Verifier 明确。
一条通用审计事件可以采用如下逻辑结构。字段为本章示意，不是某个插件的固定输出 Schema。
{
"event_type": "tool_execution_result",
"subject_ref": "subject-17",
"task_id": "task-42",
"call_id": "call-8",
"attempt_id": "attempt-1",
"policy_version": "policy-v3",
"approval_ref": "approval-9",
"decision": "allow",
"execution_status": "succeeded",
"usage_status": "pending_reconciliation"
}
示例中的执行成功只描述工具调用，不是 Task 的 Outcome；用量尚待对账也不能因执行成功而被省略。默认日志应以元数据为主，prompt、completion、工具参数和结果按需记录。需要对内容做截断、脱敏、权限隔离和留存治理，并防止密钥、带签名地址以及完整敏感数据进入日志。
数据防泄漏（Data Loss Prevention，DLP）和内容安全检测可以在应用、网关或专门服务中实现。入口统一检测便于覆盖多个调用方，但会让该位置接触明文；应用侧更接近业务语义，却需要防止漏配。检测失效时放行、拒绝或转人工，应按风险预先定义，而不是在故障时临时决策。
9.5.6 组合式实现与财务归因¶
Higress 的认证、限流、配额、统计和代理插件可以组成治理管道。部署时应验证请求阶段和响应阶段的实际执行顺序、共享属性以及版本兼容性，而不是把一组优先级数字当作跨版本固定契约。尤其应确认鉴权和预算发生在实际转发之前，最终用量能在正确生命周期结算，敏感内容不会因插件顺序失效而提前写日志。
AI 财务运营（FinOps）的基础是可核对的主体、用量和价格。组织、团队、项目映射需要保留历史有效期；实际模型、缓存 token 类别、价格版本、币种和账期共同决定费用。实时准入账与财务报表可以存在时延差异，但应有明确的对账规则，不能声称二者“天然一致”。
策略集中管理，执行分布在各入口与资源端，通过控制面发布。管理员应能看到命中规则、重置时间和适当的申诉渠道，但不能向调用者泄露其他租户信息或敏感的内部策略细节。可解释性需要与信息最小披露同时设计。
9.6 控制面联动：Gateway、执行端点、Observability 与 Evaluation¶
9.6.1 从运行数据到受控发布¶
数据面执行已发布策略，可观测系统记录运行事实，评估系统生成评分与诊断。持续优化需要连接这些环节，但 Evaluation 不天然拥有发布授权，也不应直接修改生产路由或预算。完整路径应是观测形成候选建议，建议进入构建与验证，再经过治理授权、发布门禁和灰度进入控制面。
图 9-6 评估经验证与授权进入生产。候选变更、配置下发、业务请求和观测回流是不同方向、不同权限的链路。
9.6.2 控制面、Registry 与执行端点的分工¶
控制面管理声明式配置、版本和发布状态，数据面依据生效配置处理请求。Registry 和服务发现提供端点及目录信息，健康信号帮助筛选可用目标。模型服务、MCP Server 和 Agent Runtime 是三种不同角色：前者提供推理接口，中者提供工具等协议能力，后者管理 Agent 执行生命周期；不能统称为一种 Runtime。
Higress 通过基于 Istio 的控制面向 Envoy 分发路由、集群及扩展配置。Envoy 动态发现 API（xDS）中的 Listener Discovery Service（LDS，监听器发现服务）和 Route Discovery Service（RDS，路由发现服务）描述入口与路由；Cluster Discovery Service（CDS，集群发现服务）和 Endpoint Discovery Service（EDS，端点发现服务）描述目标集群与端点。
AI 相关插件可以通过自定义资源定义（Custom Resource Definition，CRD）管理，并以开放容器倡议（Open Container Initiative，OCI）制品形式分发。热更新减少了数据面重启需求，却不意味着变更没有影响：插件初始化、配置兼容、在途流式请求和依赖变化仍需测试。
生产配置应同时记录策略版本、插件制品摘要、目标资源版本和发布批次。模型映射与基础路由可以分别管理，但二者存在依赖时仍要联合验证，不能承诺任意版本都可独立回滚。跨集群环境还需要掌握哪些实例已确认配置、哪些仍旧版本，以及部分失败时的处置方式。
9.6.3 可观测性：测量事实并保留不确定性¶
传统的请求速率、错误率和持续时间指标仍然必要，但不足以解释生成式负载。需要补充模型用量、生成时延、流内错误、预算预留和任务关联等信息。
| 数据类型 | 推荐内容 | 常见误区 |
|---|---|---|
| 用量与成本 | 输入、输出、缓存 token，估算或实际来源，价格版本和结算状态 | 将缺失 usage 当作零，或把 credits 当作统一货币 |
| 时延 | 建连、首字节、TTFT、流式空闲、总耗时 | 以 HTTP 首包代替首个有效 token |
| 可靠性 | HTTP 状态、流内错误、取消、重试、结果未知 | 只用 HTTP 200 判断成功 |
| 治理 | 命中策略、拒绝、审批、预算预留和结算 | 只记录放行，不记录最终结果 |
| 关联 | Task、Session、Turn、Call、Attempt 与 Trace 引用 | 将一条 Trace 或 Session 当作完整 Task |
指标维度需要控制基数。模型、路由和受控的服务维度适合指标聚合，Task、Session 和调用标识通常更适合日志、事件或 Trace；将所有动态标识都写为指标标签可能导致监控系统资源失控。平均时延也应从已确认的计数器或直方图计算，并与分位数一起观察，不能复制未经核验的指标名称或公式。
OpenTelemetry 的生成式 AI 语义约定提供了 gen_ai.* 等属性参考，但相关约定整体仍处于 Development 状态。采用时应固定版本，区分稳定通用属性与仍在演进的生成式字段，并为版本迁移保留映射，不应称其为已全部稳定的统一标准。
内容日志可以支持复核，却不保证可重放整个任务。外部系统状态、工具副作用、资源版本和缺失事件都可能影响重放；若需要可重复实验，应在受控环境中固定输入和依赖，并禁止对生产副作用进行无保护重演。
9.6.4 评估结果如何用于网关变更¶
网关策略的回归需要覆盖协议兼容、输出质量、费用、时延和故障路径。比较模型或路由时，应使用一致的任务输入与成功标准，关联实际模型、策略版本和已确认的业务结果。模型评分可以辅助诊断，但不能自动替代业务 Outcome。
数据集构建、评估方法和误差校准由治理与优化相关章节展开。网关侧负责提供可复核的调用记录，并让候选策略进入验证和发布流程。
9.6.5 候选变更进入生产的完整链路¶
| 阶段 | 产物 | 进入下一阶段的条件 |
|---|---|---|
| 观测与诊断 | 成本、质量或可靠性问题及可复核记录 | 数据来源、统计口径和不确定性明确 |
| 候选建议 | 模型映射、路由、提示、工具或预算变更 | 变更范围、预期收益和约束清楚 |
| 构建与验证 | 固定版本的配置或制品、回归与安全结果 | 协议、质量、授权、成本和故障测试达标 |
| 治理授权与发布门禁 | 获批的发布记录和责任人或预授权规则 | 具备相应权限，依赖检查通过，回滚方案有效 |
| 灰度与控制面发布 | 分批生效配置、实例确认和实验分组 | 监测指标达标；异常时暂停或回滚 |
| 运行反馈 | 新观测、异常样本和业务结果 | 回流数据集和下一轮候选优化 |
这条链路适用于模型映射、语义路由、工具 Schema 和预算策略等可能改变调用行为的配置。在线实验应使用稳定且经过授权的分组键；长程任务跨会话执行时，应避免在一次任务中无意混用不兼容策略。其他类型的 Agent 行为优化沿用构建、治理与优化篇的相应流程。
自动化可以缩短审批和发布时间，但不能消除授权边界。低风险调参可以在预先批准的范围、幅度和资源集合内自动进行，仍需留存版本、验证结果及回滚记录；超出范围的变化必须重新授权。缓存策略也可能影响数据隔离和新鲜度，不能仅凭“缓存阈值”这一名称就认定其低风险。
9.6.6 区分运行时自适应与治理策略变更¶
Higress ai-load-balancer 的 AdaptiveScore 在参考提交中使用指数加权移动平均（Exponentially Weighted Moving Average，EWMA）首包和总时延、在途请求及失败相关信号进行选择，并具有候选采样、失败冷却等机制；可选的 Redis 共享信息不可用时，相关路径退回本地评分。
这是已发布路由策略内部的在线端点选择，不是 Evaluation 直接获得生产发布权。算法只能在已授权的候选集合和约束内工作，不能自行扩大模型范围、数据地域、工具权限或预算。其效果需要在目标负载下测量，不能由存在自适应评分就推导出质量或成本必然改善。
9.6.7 让闭环可验证、可停止、可回滚¶
可靠的闭环既要收集收益，也要记录失败与未知状态。观测系统不可用时，是否继续执行取决于风险和审计要求；预算或授权系统不可用时，行为应由已定义策略决定。不同依赖不能共用一个未经验证的降级口号。
控制面需要暴露配置传播进度，数据面需要上报实际版本，评估需要识别样本使用了哪组策略。回滚不仅是恢复配置文本，还要考虑已执行的工具副作用、未结算额度和仍在运行的任务。网关可以回滚入口策略，业务系统仍需处理变更已经造成的业务结果。
运行数据形成优化建议，验证与授权决定是否发布，控制面记录版本并跟踪实际生效情况。这样的链路使每次网关变更都有可复核的依据，并能在效果不达预期时停止或回滚。
9.7 本章小结¶
AI Gateway 提供模型、工具和 Agent 流量的统一治理入口。LLM Gateway 聚焦协议、路由、可靠性与计量；MCP Gateway 聚焦协议代理、资源目录集成和工具授权；Agent Gateway 聚焦入口身份、配额、亲和与跨调用关联。三种语义可以组合，但都不因此获得业务 Task、State、Checkpoint、恢复语义或 Outcome 的权威所有权。
可信的成本治理需要区分时间窗限制、余额配额和严格预算，后者依赖可证明的最大消耗、原子预留与幂等结算。可信的任务分析需要从 Session 扩展到 Task—Session—Turn—Call—Attempt 的归因链路，并承认网关日志与 Trace 只是任务账本的数据来源之一。可信的安全治理需要在发现、授权、审批和实际执行之间保留独立检查，且以凭证和网络控制作为入口不可绕过的前提。
持续优化则依赖一条受控的变更链：Evaluation 产生评分、诊断和候选建议，构建与验证确认其效果，治理授权和发布门禁决定能否进入生产，控制面和数据面负责分发与执行。业务应用或获授权 Verifier 依据成功标准、State 与 Evidence 判定 Outcome。把这些边界设计清楚，比把更多功能集中到网关中更重要。
9.8 本章实现说明¶
本节收录版本敏感、可直接对照实现的细节，用于支撑正文结论，不属于架构主线。字段示例以 MCP 2026-07-28 为准；插件行为以提交 f053bb08360d432a1226d4b61eb69871c74b9021 为核验基线，部署前应按实际制品重新核验。
9.8.1 MCP 逐请求元数据¶
Modern RPC 请求必须在 params._meta 中携带协议版本和客户端能力，能力对象可以为空；客户端信息是推荐字段，而不是必需字段。HTTP 传输另有镜像要求。
| 字段 | 要求与含义 |
|---|---|
| io.modelcontextprotocol/protocolVersion | 请求元数据中的必需字段，声明协议版本 |
| io.modelcontextprotocol/clientCapabilities | 请求元数据中的必需字段，允许为空对象 |
| io.modelcontextprotocol/clientInfo | 推荐提供客户端名称和版本；不是认证凭据 |
| MCP-Protocol-Version | HTTP 请求头，与正文的协议版本一致 |
| Mcp-Method | RPC 请求头，与 JSON-RPC 方法一致 |
| Mcp-Name | 对 tools/call、resources/read、prompts/get 等规范指定的具名请求必需，分别镜像工具名、资源 URI 或提示名 |
一次 Modern 工具调用可以包含如下 HTTP 头与消息体。示例只展示协议相关字段，生产请求仍需要独立的认证、传输安全及部署策略。
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
Content-Type: application/json
Accept: application/json, text/event-stream
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientCapabilities": {},
"io.modelcontextprotocol/clientInfo": {
"name": "example-client",
"version": "1.0.0"
}
},
"name": "get_weather",
"arguments": {"location": "Hangzhou"}
}
}
网关需要按照对应方法校验镜像关系，不能对不需要名称的方法强制要求 Mcp-Name，也不能把所有名称字段都解释为 params.name；头部可以辅助轻量分类和路由，但最终执行前仍需验证其与正文一致，避免头部鉴权和执行面对不同对象。
协议的弃用政策也应精确理解：核心规范功能从标记 Deprecated 到移除，一般有至少十二个月的窗口；这不等于所有服务必须接受所有旧版本或旧 Schema 十二个月，安全例外和 SDK 生命周期另有规则。实现需要说明实际支持的版本集合，而不是从弃用窗口推导无限兼容。
9.8.2 Higress 预算插件的故障分支¶
ai-token-ratelimit 的相关读取错误路径允许请求继续；ai-quota 在异步读回错误、余额缺失或非正值时拒绝，但部分同步调用错误与扣减失败路径并未构成“任何 Redis 故障都可靠拒绝”的统一保证。部署时需要针对所选版本测试读失败、写失败、超时与恢复后的对账，而不能用一个“故障时放行”或“故障时拒绝”的标签覆盖全部分支。
下面展示的是预算策略需要表达的设计信息，不是 Higress 插件字段，也不能直接提交给其控制面。