Chapter 04

自测:你能不能选对

前三章建立了概念、机制、生产判断。这一章不教新东西——它把这些知识从「读过」逼成「能调取」。重点是最后的应用判别层:给场景、让你选网关,这是检验你是否真懂的地方。

怎么用这一章

  • 三层梯度:概念层(回忆)→ 原理层(理解)→ 应用判别层(选对)
  • 所有答案集中在文末一个折叠块里——做完一整层再展开,别逐题瞄
  • 应用判别层是重点:每题都要你在多个章节的方案之间做选择
  • 中间有一处「亲手画图」,别跳过——画一遍胜过看十遍

先看这一章的题目难度是怎么递进的。

应用判别层 判别 · 选对方案 原理层 理解 · 解释机制 概念层 回忆 · 命名零件 ↔ 01+02+03 ↔ 02 章 ↔ 01 章
图 4.0越往上越难,题量越少。 注意:朱红的顶层(应用判别层)综合三章——它检验的不是「记没记住」,而是「换个场景会不会选」。这是 transfer,也是面试真正考的东西。

A概念层(对应 01 章)

回忆为主。卡住先翻 01 章对应小节,别直接看答案。

  1. data plane 和 control plane 各负责什么?哪个在请求热路径上?(§1.1)
  2. 三类 agent 流量分别是「agent → 谁」?各自大致用什么协议?(§1.2)
  3. 请求路径四件套是哪四个、什么顺序?(§1.3)
  4. 是什么决定网关「用 LLM 还是 MCP 语义来解析这段 body」——配置,还是 body 的内容?(§1.4)
  5. 为什么 guardrails 被归为「横切」policy,而不是某个 backend 的内部功能?(§1.5)

B原理层(对应 02 章)

理解为主。答案要能讲出「为什么」,不只是「是什么」。

  1. 「body-aware 而非 header-aware」连带改变了经典网关哪三个底层假设?(§2.2)
  2. 为什么选 Rust 从零重写,而不是在 Envoy 上加插件?给两个技术原因。(§2.2)
  3. MCP 工具名前缀同时承担哪两个作用?(§2.3)
  4. 语义缓存的「locality 与 avalanche 矛盾」是什么?为什么它把缓存从性能问题变成了安全问题?(§2.4)
  5. agentgateway 默认只在什么故障下驱逐供应商节点?这给「以为 failover 会自动切 5xx」的人留了什么坑?(§2.4)
  6. token usage 为什么只能在流结束时拿到?它和「入口要先放行」凑在一起,造成了什么时序窗口?(§2.6)

C应用判别层(综合 01 + 02 + 03)

这一层是重点。每题都要你在不同章节的方案之间做选择,并讲清「为什么不是另一个」。

  1. 选型 ①:一个应用调 3 个 LLM 供应商,没有工具调用、没有 agent 间协作。选哪类网关?为什么不上 agent-native?(综合 §1.2 + §3.2)
  2. 缓存判别:一个多租户客服 agent,想开语义缓存省钱。该不该开?如果开,缓存键里必须混入什么,否则会出什么事?(综合 §2.4 + §3.1)
  3. 故障归因:某 LLM 供应商连续返回 503,但网关流量没切走。根因在哪个机制?为什么默认行为不够?怎么修?(综合 §2.4 + §3.1)
  4. 上下文爆掉:一个 agent 聚合了 15 个 MCP server,第一条用户消息还没发,上下文已被工具定义占掉 4 万 token。根因接哪两章?两条缓解各是什么?(综合 §2.3 + §3.1)
  5. 平台选型 + 部署:K8s 上的内部 AI 平台,~20 个 agent,各调多个 MCP 工具、偶尔互相委托、还对外暴露 REST API。选哪类网关、哪种拓扑、最先要防的两个失败模式是什么?(综合全书)
亲手画一张图

合上教程,在纸上或 Excalidraw 里画一条「带工具调用的流式 LLM 请求」穿过 agent 网关的生命周期——只画 5 个阶段 + 一条返回箭头就行(参考 §2.1 的形状,但别翻回去)。

画完回到图 2.1 对照,问自己两件事:① 你把 解析 body 画在最前了吗?② 你把 提取 token usage 画在返回路径上、而不是去程上吗?这两点画对,说明你抓住了本教程时序部分的核心。

§答案

做完整整三层再展开。逐题瞄答案,等于把自测变成又一次阅读。

展开全部答案(确认做完再点)

A · 概念层

  1. 数据平面处理每一条真实流量(在请求热路径上);控制平面只翻译并下发配置/策略,不碰流量。在热路径上的是数据平面。
  2. LLM = agent → 模型(OpenAI/Anthropic 风格,一问一答,无状态);MCP = agent → 工具(JSON-RPC,有状态 session,Streamable HTTP / stdio);A2A = agent → 另一个 agent(JSON-RPC over HTTPS,靠 Agent Card 发现)。
  3. bind(端口)→ listener(入口)→ route(按 path/header 匹配)→ backend(选上游)。
  4. 配置决定。route 在配置里被声明指向哪种 kind 的 backend(ai/mcp/a2a),网关就用那套协议语义解析 body——不是去猜 body 内容。
  5. 因为鉴权/限流/guardrails 对三类流量都适用,写进单个 backend 会重复三遍;抽成横切 policy 挂在路径固定点上,一处定义、三类复用。

B · 原理层

  1. ① 计量单位:请求数 → token 数(且 token 流结束才知道);② 连接形态:短暂独立的请求-响应 → 有状态双向长连接;③ 解析位置:body 解析/数 token/跑 guardrails 落在每条请求的延迟热路径上。
  2. 两个即可:① body 解析与有状态双向是外挂在 Envoy 无状态内核上,延迟与脆弱性叠加;② 托管语言 GC 暂停会卡住流式响应,Rust 无 GC 暂停;③ 复用 Envoy/service mesh 把 body-blind、按请求计量这些核心问题留着没解决。
  3. ① 防冲突命名(两个 server 都有 search 时不致调错);② 回程路由依据(网关靠前缀把 tools/call 送回正确的源 server)。
  4. 语义缓存靠「相似输入 → 相邻向量」的局部性命中,而抗碰撞的键要「输入微变 → 输出剧变」的雪崩效应——两者结构对立。后果不止误命中(性能),还让攻击者能构造落在阈值内的不同输入、读到别人的缓存回答(安全)。所以缓存键必须混入租户 ID/角色/模型等。
  5. 只在收到带 Retry-After 的 429 时驱逐节点;5xx / 超时 / DNS 失败只降健康分、不移出轮转。坑:以为 5xx 会自动切走,实际坏节点仍持续收流量——要让 5xx 也切,得显式配按错误率的熔断。
  6. 因为真实 token 用量在响应流结束时才从 usage 块到达,而限流闸必须在放行前决定。一个只能「后」、一个必须「先」,中间就是「先放行、后结算」窗口——可被提前断开连接(让 usage 永不回来)利用来绕过限流。

C · 应用判别层

  1. 选型 ①:选 LLM / AI 网关(LiteLLM、Portkey 等)。只有「agent→模型」一类流量,没有 MCP 工具聚合、没有 A2A——决策树第一问「三类统一?」答「否」。上 agent-native 等于为用不上的统一性,引入更年轻、更重的依赖。
  2. 缓存判别:能不能开取决于业务能否容忍「偶尔返回相似但不对的答案」。若开,缓存键必须混入租户 ID(以及角色、模型、温度、system prompt);否则不同租户的 prompt 向量相近时会跨用户串答——一个用户读到另一个用户的缓存回答,是越权泄露。阈值也要抬到 ≥0.92 减少误命中。
  3. 故障归因:根因在 §2.4 的 failover 驱逐条件——默认只有带 Retry-After 的 429 触发驱逐,503 只降健康分、不移出轮转,所以坏节点仍收流量。默认不够是因为它只覆盖了「限流」这一种故障。修:显式配置基于错误率的熔断,让连续 5xx 也能把节点切走;并配合全局重试预算 + 退避抖动,防 retry 风暴叠加。
  4. 上下文爆掉:接 §2.3(MCP multiplexing:所有工具定义在对话开始时一次性进上下文)+ §3.1(描述膨胀失败模式)。两条缓解:① 按需发现——只加载当前用得到的少量工具,而非全量;② 精简/约束工具描述长度(每个工具的描述能占几百到上千 token)。
  5. 平台选型 + 部署:三类流量都有(LLM + MCP + A2A)→ 决策树第一问答「是」→ agent-native 网关。已在 K8s → K8s Gateway API 拓扑(kgateway 控制平面 + agentgateway 数据平面)。20 个 agent × 多工具 → 最先防 MCP 描述膨胀(吃 token)与 A2A 失控扇出(委托循环派生大量子任务)。
洞察 · 全书收束在一句话

如果这一章只留一句话:Agent 网关把请求 body 当一等公民,并用一个数据平面同时讲 LLM、MCP、A2A 三种协议。「为什么是新品类」「为什么这么多失败模式」「该怎么选型」——所有答案都从这句话长出来。它能讲给同事听,你就真的拿到了。