Chapter 03
生产:会怎么坏、怎么选、怎么部署
02 章讲了机制怎么工作。这一章讲机制在生产里怎么坏——而且几乎每个失败模式都能挂回 02 的某个机制。然后是五类网关的横向选型、三种部署拓扑,以及截至 2026-06 的现状前沿。
本章你将建立的 schema
- 7 类生产失败模式,每类的症状、根因(回指 02 机制)、缓解
- 两起真实安全事件:tool poisoning(CVE-2025-54136)与 LiteLLM 供应链投毒
- 五类网关的横向对比,以及「给定场景选哪类」的决策树
- 三种部署拓扑(sidecar / 集中式 / K8s Gateway API)的取舍
- 截至 2026-06 的现状:什么稳定、什么在变、什么已被取代
3.17 类失败模式
这些不是「注意性能」式的泛泛提醒,而是具体到症状和根因的失败模式。关键观察:它们几乎都能挂回 02 章的某个机制阶段——机制决定了它会在哪坏。
| 失败模式 | 症状 | 根因(回指 02) | 缓解 |
|---|---|---|---|
| Streaming 缓冲 | 流式响应被攒成整块一次性返回,失去逐字效果 | 代理层缓冲了 SSE body(§2.1 流式返回) | 关闭 proxy buffering,逐 chunk flush |
| Usage 丢失 | token 计数对不上账单;流式下尤甚 | 消费者读到 finish_reason 就停,漏掉尾部 usage chunk(§2.4 ①) | 读到 [DONE] 为止;强制 include_usage |
| Token 计数绕过 | 限流被绕过,用量被低估 | 提前断开连接,usage 永不回来(§2.6 先放行后结算窗口) | 按字节兜底估算;断开也照扣 |
| 语义缓存误命中 | 200 OK 返回一个相似但错误的答案;跨用户串答 | 阈值过低 + 缓存键未隔离租户(§2.4 ③ locality/avalanche) | 阈值 ≥0.92;键混入租户/角色/模型 |
| MCP 工具名冲突 / 描述膨胀 | 模型调错工具;工具描述吃掉数万 token | 聚合多 server 未加前缀 / 全量加载工具定义(§2.3) | server 前缀;按需发现、只加载用到的工具 |
| Failover 不切 / retry 风暴 | 坏节点仍收流量;一次抖动放大成雪崩 | 只 429 才驱逐,5xx 不切;无全局重试预算(§2.4 ②) | 按错误率熔断;全局重试预算 5~15% + 退避抖动 |
| A2A 失控扇出 | 规划 agent 在重试循环里派生上万子任务 | agent 间无逐边限流(§1.2 A2A 流量) | 按 agent / caller / intent 设边级限流 |
有两类失败已经不是「会出错」,而是已经发生过的真实安全事件,单独拎出来。
MCP 工具的描述/schema 字段里可以藏命令式指令("SYSTEM OVERRIDE…"),模型读工具描述时会被它操纵。更阴的是会话中途调包(rug-pull):一个已被批准的 server,在会话进行中把工具 schema 换成投毒版本。根因接 §2.3——网关聚合工具时若不在每次动态变更后重新校验,投毒就混进来了。缓解:默认拒绝的工具注册表、对 server 做证书钉扎、剥离零宽 Unicode、对工具描述做 LLM 审查。
LiteLLM 的 PyPI 包 1.82.7 / 1.82.8 曾被植入恶意代码,窃取云凭据、SSH key、k8s secret。根因是网关的结构性弱点:它集中持有所有供应商密钥,一个坏依赖就能把全部 secret 一次性带走。这不是 LiteLLM 独有的问题,是「网关集中密钥」这一架构的固有风险。缓解:钉死并校验依赖、按团队切分 virtual key、密钥存储隔离。
网关多一跳的开销,在低负载下只有个位数毫秒——但它会悬崖式恶化:同一个 Python 网关在 500 RPS 时 P99 尚可,到 5k RPS 时 P99 冲到几十秒。Rust / Go 数据平面能把每跳压在 1ms 内。选型时别只看「平均延迟低」,要看高并发下的 P99 曲线。
表 3.1 里,「Usage 丢失」和「Token 计数绕过」根因不同,但都指向 §2.4 的同一个机制特性。是哪个特性?为什么它同时催生了一个意外 bug 和一个蓄意攻击?
展开答案(先停 10 秒)
同一个特性:token 用量只能在流结束时从 usage 块拿到(§2.4 ①,§2.6 的「先放行后结算」)。
意外 bug(usage 丢失):消费者读到 finish_reason 就停,没等到尾部那个独立的 usage chunk。蓄意攻击(计数绕过):攻击者故意提前断开,让 usage 永远不回来,从而不被计费。一个是「没等」,一个是「不让到」——都利用了「用量来得晚」这个时序特性。这就是为什么理解机制能预测失败:同一个机制特性,在粗心和恶意两种手里各开出一种花。
3.2选型:五类网关怎么挑
「agent 网关」这个词周围,挤着至少五类边界重叠的东西。会选型的前提是知道每类独特做什么、不做什么。
| 类别 | 独特能力 | 不做什么 | 何时选 |
|---|---|---|---|
| Agent-native 网关 agentgateway / Envoy AI GW / Kong |
一个数据平面同时治理 LLM + MCP + A2A + 普通 HTTP;MCP 联邦、工具级 RBAC、A2A 发现 | 不是托管计费层;不是开箱 SaaS UI;还年轻(v1.0 在 2026-03) | 平台有很多 agent,各自调很多工具、彼此对话,还混着普通 API |
| LLM / AI 网关 LiteLLM / Portkey / OpenRouter |
面向模型:多供应商路由/failover、OpenAI 兼容层、virtual key、成本与可观测 | 经典上无 A2A;MCP/工具治理较浅(正在补) | 单个应用调 N 个模型供应商,要快速拿到成本/可观测/密钥管理 |
| MCP 网关 / 工具代理 Docker MCP Gateway / MetaMCP |
面向工具:聚合多个 MCP server、沙箱隔离、注入 secret、有状态会话路由 | 无 LLM 路由/计费;无 A2A;不是通用 API 网关 | 暴露/消费很多 MCP server,要隔离 + 凭据注入 + 单一工具端点 |
| 经典 API 网关 Kong 经典 / Apigee / AWS |
成熟的南北向:authn/z、配额、生命周期、API 商业化 | 原生无 LLM 路由、无 MCP/A2A(部分在外挂) | 治理常规 REST API,AI 只是可以另接一层的小补充 |
| Service mesh Istio / Linkerd |
东西向服务间:mTLS、重试、流量切分、sidecar/ambient 可观测 | 无 API 产品治理,无 model/tool/agent 语义 | 保护内部微服务连通性;agent 网关可叠在它旁边 |
这张决策树有保质期。LLM 网关在加 MCP(LiteLLM、Portkey 已经在做),经典网关在加 AI(Apigee 能从 OpenAPI 自动生成 MCP server),agent-native 在吞并三者。今天「选哪类」的边界,一年后会移动。所以选型时除了看当下能力,还要看各家往哪个方向收敛——这正是下一节「现状前沿」要给的判断依据。
3.3部署拓扑
同一个 agent 网关,放在架构的哪个位置,有三种典型选择。
| 拓扑 | 形态 | 优势 / 代价 |
|---|---|---|
| 集中式(standalone) | 一个独立网关服务,所有 agent 流量汇入 | 简单、统一管控成本与策略 / 是单点,且每条流量多一跳 |
| Sidecar | 每个 workload 旁挂一个网关实例 | 细粒度、贴近东西向流量、故障域小 / 实例多、运维重 |
| K8s Gateway API | kgateway(控制平面)+ agentgateway(数据平面),声明式 CRD 驱动 | 云原生、声明式、与现有 Gateway API 一致 / 需要 K8s 与 Gateway API 心智 |
三种拓扑回到 §1.1 的两平面模型:集中式和 sidecar 是数据平面的不同摆法,K8s Gateway API 则把控制平面显式交给了 kgateway。选哪种,取决于你已有的运行时——已经在 K8s 上、已经用 Gateway API,第三种几乎是默认;否则集中式起步最省心。
3.4现状前沿(截至 2026-06)
这是个快速演进的品类。把已知事实按「稳定 / 在变 / 已弃用」分三档,每档带日期——这样你能判断手里的资料是不是过期的。
稳定(settled core)
- MCP 传输 = stdio(本地)+ Streamable HTTP(远程)。Streamable HTTP 自 2025-03-26 起为推荐远程传输,2025-12-19 由传输工作组重申。
- MCP 授权 = OAuth 2.1 + 受保护资源元数据(RFC 9728)发现,自 2025-06-18 修订起稳定。
- A2A 是真实采用的,不是雏形:2025-06-23 由 Google 捐给 Linux Foundation,v1.0 于 2026-01 发布、03 公布,150+ 组织采用。A2A 与 MCP 互补不竞争:MCP 管 agent↔工具,A2A 管 agent↔agent。
在变(近 6~12 个月)
- MCP 修订 2025-11-25(上一版 2025-06-18):新增实验性 Tasks(异步/持久请求)、URL 模式 elicitation、sampling 里带工具调用、OAuth Client ID Metadata Document、JSON Schema 2020-12 为默认。
- MCP Registry 自 2025-09-08 预览(registry.modelcontextprotocol.io),仍是 preview、未 GA。
- agentgateway:Solo.io 创建,2025-08-25 捐给 LF;v1.0.0 于 2026-03-12 发布,已独立。
- Envoy AI Gateway:MCP 支持落于 v0.4.0(2025-11-07);v0.6.0(2026-05-05)为首个生产级 API 面。
已弃用 / 被取代(别当现状学)
- 独立的 HTTP+SSE transport(协议 2024-11-05)——2025-03-26 弃用,仅向后兼容。别在新 server 上用它;用 Streamable HTTP(它内部仍可用 SSE 做流式)。
- 把「按 vendor 的纯 LLM 代理」当成「AI 网关」——这个定位已被取代;2026 年中的网关被期望能处理 MCP + A2A,而不只是 LLM 密钥分发。
容易过度解读:被弃用的是独立的 SSE 传输,不是 SSE 本身。SSE 仍活在 Streamable HTTP 内部用于流式。看到「SSE 已死」的说法要校准——死的是把它当独立 transport 的那种用法。
§本章 self-check
先合上教程作答,再展开对照。
- 「单个应用调 3 个 LLM 供应商」这个场景,该选哪类网关?为什么不是 agent-native?
- tool poisoning 的「rug-pull」具体指什么?它接 02 章哪个机制的薄弱处?
- 为什么说「网关多一跳的延迟」是悬崖式而非线性的?选型时该看哪个指标?
- 截至 2026-06,MCP 的远程标准传输是什么?哪个旧传输已被弃用、但又没完全消失?
答案(先做完再展开)
- 选 LLM / AI 网关(LiteLLM、Portkey 等)。这个场景只有「agent→模型」一类流量,没有 MCP 工具聚合、没有 A2A;agent-native 的统一治理能力用不上,反而引入更年轻、更重的依赖。决策树第一问「三类统一?」答「否」,就不该走 agent-native。
- rug-pull = 一个已被批准的 MCP server,在会话中途把工具 schema 换成投毒版本。它接 §2.3 MCP multiplexing 的薄弱处:网关聚合工具时,若不对动态变更(
tools/list_changed)后的工具重新校验,投毒 schema 就被信任了。 - 因为延迟不是来自固定的每跳处理,而是来自高并发下的排队/资源耗尽:低负载几乎无感,过了某个 RPS 阈值 P99 陡升到几十秒。选型该看高并发下的 P99 曲线(以及数据平面是不是 Rust/Go),而非平均延迟。
- 远程标准传输是 Streamable HTTP(2025-03-26 起)。被弃用的是独立的 HTTP+SSE transport(2024-11-05 协议),但 SSE 仍活在 Streamable HTTP 内部做流式——弃的是「独立 transport」这种用法,不是 SSE 本身。
给一个「平台型」场景排一份选型 + 部署方案
场景:你在 K8s 上运维一个内部 AI 平台,有 ~20 个 agent,每个 agent 调 3~5 个 MCP 工具、偶尔把任务委托给别的 agent,同时这些 agent 也对外暴露普通 REST API。用本章的决策树(图 3.2)和部署表(表 3.3)写出:选哪类网关、哪种拓扑、最先要防的两个失败模式各是什么。
提示(卡住再展开)
决策树第一问就答「是」(LLM+MCP+A2A 三类都有)→ agent-native。已在 K8s → K8s Gateway API 拓扑(kgateway + agentgateway)。20 个 agent × 多工具 → 最先防 MCP 描述膨胀(吃 token)与 A2A 失控扇出(委托循环)。把这三件串起来就是一份能讲给同事的方案。