AI 原生架构：LLM 时代的系统重构Latency budgets, token billing, uncertain

原文发布于 quant67.com，转载请保留出处。

上一篇讨论的是全球边缘网络如何把 Anycast、同构软件栈和 V8 Isolate 压成一套统一哲学。那篇文章的隐含前提是：请求路径上的每个组件行为相对确定——DNS 解析、TLS 终止、Workers 隔离边界，都可以用传统 SRE 的指标和超时模型描述。下一篇边缘计算架构将继续讨论算力下沉后的一致性与本地状态。夹在两者之间的，是一个正在改变「依赖」含义的组件：大语言模型（Large Language Model, LLM）不再只是离线训练产物或批处理任务，而是长驻在线路径上的运行时依赖。

一个客服系统把用户问题发给 GPT‑4o，期望 3 秒内返回；一个研究 Agent 在后台并行 spawn 十几个子 Agent 搜网页、读 Slack、写报告，单次任务可能跑 20 分钟；一个代码审查流水线在 CI 里调用 Claude 分析 diff。三种场景共享同一个事实：调用方不再控制下游的执行路径、输出形态和最终账单。这和调用一个 gRPC 库存服务有本质不同——库存服务返回固定 schema 的 protobuf，延迟分布虽宽但可建模；LLM 返回的是概率采样结果，延迟与输入输出 token 数、排队深度、是否流式、是否触发工具循环全部耦合。

本文讨论的是 AI 原生架构（AI-Native Architecture）：当 LLM 进入生产调用链，超时、成本、不确定输出、编排与可观测应如何成为架构决策的一等公民。本文不讨论训练并行、显存切分或万卡集群调度——那属于大模型基础设施工程的范畴；Agent 身份委托、MCP 供应链与工具级授权的细节见 Agent 身份与安全，本篇只点到分工边界；用类型系统与契约约束 AI 生成代码破坏半径的「深度防御」见本系列 Part XV · 101 防御性架构。

一、从「模型 API」到「运行时组件」

1.1 三种接入深度

把 LLM 接进现有系统，工程上常见三条路径，架构约束逐级加重：

接入深度	典型形态	架构关注点
单次补全	翻译、摘要、分类	超时、token 上限、结构化输出校验
RAG 增强	文档问答、知识库助手	检索链路 SLA、引用 grounding、向量库边界
Agent 循环	研究助手、运维 Copilot、多工具工作流	编排、checkpoint、成本爆炸、人审闸门

单次补全最接近传统 RPC：一次请求、一次响应（或一条 SSE 流）。RAG 在调用链上多了检索与重排，但主路径仍是「检索 → 拼装 prompt → 生成」。Agent 循环则把 LLM 变成有状态的控制器：模型决定何时调工具、调哪个工具、是否 spawn 子任务、何时结束——调用图在运行时才确定。

Anthropic 在 2025 年 6 月发布的 multi-agent Research 系统工程文中描述的模式属于第三层：LeadResearcher 分解任务、并行 Subagent 搜索、CitationAgent 后处理引用；单次复杂查询的 token 消耗可达普通聊天的约 15 倍，Agent 单次交互约为 4 倍[1]（B 级，Anthropic Engineering Blog）。这不是可以当作「又一个微服务」忽略的边际成本，而是架构容量与预算模型的输入参数。

1.2 本文要回答的核心问题

依赖语义：LLM 调用与传统 RPC/gRPC 在超时、重试、熔断上差在哪？
预算传播：用户-facing deadline 如何贯穿检索、多轮生成与工具调用？
成本治理：按 token 计费时，网关层与租户配额如何设计？
不确定输出：schema 校验、工具边界、人审与可回放追踪如何组合？
编排与恢复：同步 vs 异步 Agent、checkpoint/resume 的生产要求是什么？
可观测边界：不记录对话正文时，还能追踪什么？
与 RAG/向量引擎的分工：应用架构层该管什么，不该管什么？

二、LLM 作为依赖：与传统 RPC 的差异

2.1 对比框架

传统微服务依赖（HTTP/gRPC）与 LLM 依赖在架构质量属性上的差异，可以用下表概括。表中「传统 RPC」指行为良好的内部服务；LLM 行指通过商业 API 或自建 vLLM/SGLang 集群的在线推理，不包含离线批处理。

维度	传统 RPC	LLM 依赖
输出确定性	相同输入 + 相同服务版本 → 近似确定性（忽略浮点与缓存）	相同输入 → 不同输出（temperature、采样、并发 batch 均影响）
延迟构成	网络 RTT + 服务处理 + 排队	排队 + Prefill（与 prompt token 数相关）+ Decode（与 output token 数相关）
延迟尾部	多为依赖慢查询、GC、锁竞争	额外受生成长度、工具循环轮次、上下文接近窗口上限时的截断/压缩影响
计费单位	常按 QPS、实例、CPU 核时	按 input/output/cached token 分档计价
有效「超时」	单次 HTTP/gRPC deadline	单次 completion 超时 ≠ 整段 Agent 任务超时
失败语义	4xx/5xx、业务错误码	HTTP 200 但内容幻觉、格式错误、工具参数 JSON 非法
重试收益	transient 故障重试常有效	重试可能得到不同答案、双倍 token 账单、放大下游工具副作用
上下文约束	请求体大小上限（MB 级）	上下文窗口（token 级），超长需截断、摘要或外部 memory
状态	无状态服务为主	Agent 多轮对话天然有状态；状态在网关、checkpointer 或模型上下文里

这张表说明：不能把 LLM 网关后面接的 HTTP 200 等同于「依赖成功」。架构上需要把「传输成功」与「业务可接受输出」拆成两层 SLA。

2.2 延迟尾部：Prefill、Decode 与 Agent 乘法

推理引擎把一次生成拆成 Prefill（处理 prompt）和 Decode（逐 token 自回归）。对用户感知而言：

TTFT（Time To First Token） 主要由 Prefill 与排队决定；
TPOT（Time Per Output Token） 决定流式输出的「打字速度」；
E2E $\approx \mathrm{TTFT} + \mathrm{TPOT} \times N_{\mathrm{out}}$ 。

Agent 循环把上述延迟按轮次相乘：每一轮「模型推理 → 解析 tool call → 执行工具 → 结果写回上下文」都是一次新的 Prefill（上下文变长）加可能的多次工具 RTT。Anthropic Research 系统通过 Lead Agent 并行 spawn 3–5 个 Subagent、Subagent 内并行 3+ 工具调用，把 wall-clock 时间显著压缩，但** token 与工具调用次数仍随并行度上升**[1]。

因此，LLM 依赖的 P99 往往不是「比 P50 慢一点」，而是生成了更多 token、多跑了几轮工具、或触发了长上下文压缩——这与延迟分析里讨论的「尾部由不同机制主导」一致，但机制换成了 token 与轮次。

用一个具体例子固定直觉：假设某次 Agent 任务共 8 轮 loop，每轮平均输入 4k token、输出 400 token，TTFT 为 800ms、TPOT 为 40ms。则单轮 E2E 约为 $0.8 + 0.04 \times 400 = 16.8$ 秒，8 轮串行 wall-clock 约为 134 秒——尚未计入工具 RTT。若其中两轮因检索慢各增加 5 秒，P99 与 P50 的差距主要来自轮次数与工具，而非单次网络抖动。架构师在定 SLA 时，应把「P99 响应 < 3s」类传统目标拆成：单轮 chat < 3s 与 Agent 任务 < 5min 两类，不可混用。

推理侧排队深度对 TTFT 的影响，与连接池耗尽导致排队延迟在结构上等价：都是「请求到达速率超过服务处理速率」后的 M/M/k 或 G/G/k 排队。不同之处在于 LLM 服务的「服务时间」与 prompt 长度、decode 长度强相关，同队列里短 prompt 与长 Agent 上下文共存时，短请求可能被长尾拖慢——continuous batching 缓解但未消除这一问题，见 PagedAttention 与 Continuous Batching。

2.3 非确定性与幂等

幂等性设计假设：重复执行同一操作，系统状态不变或可检测重复。LLM 调用天然破坏这一假设：

重试同一 prompt 可能得到不同文本；
若输出驱动写库（「把摘要写入字段 X」），重试可能导致不一致；
若输出驱动工具调用（「删除 id=123 的记录」），重试可能导致非幂等副作用。

工程应对不是简单禁止重试，而是分层：

只读推理（分类、提取）：可重试，但需接受答案漂移；关键路径用 temperature=0 与固定 seed（若后端支持）降低方差。
结构化输出驱动状态变更：先校验 schema，再在应用层用确定性 idempotency key 执行副作用，不把 LLM 放进事务边界。
Agent 工具链：工具本身必须幂等或可检测重复；LLM 只产生「意图」，执行层负责 dedup。

2.4 按 token 计费与上下文窗口

成本与延迟共享同一个变量：token 数。一次调用的账单近似：

C \approx p_{\mathrm{in}} \cdot T_{\mathrm{in}} + p_{\mathrm{out}} \cdot T_{\mathrm{out}} + p_{\mathrm{cached}} \cdot T_{\mathrm{cached}}

其中 $p$ 为单价， $T$ 为 token 数。Agent 把 $T_{\mathrm{in}}$ 随对话轮次累积；多 Agent 并行时，各子上下文独立计费，总成本是加性的。

上下文窗口 $W$ （如 128k、200k token）是硬约束。超过 $W$ 时，系统必须截断、滑动窗口、摘要压缩，或把状态外置到 memory/store——Anthropic Research 在 Lead Agent 接近 200k token 时会截断上下文，因此要求把研究计划写入 Memory 以保留关键状态[1]。这是架构级状态管理，不是 prompt 技巧。

2.5 与弹性模式的关系：出站视角

从调用方看，LLM 是出站依赖，弹性设计模式中的熔断、舱壁、超时、重试都适用，但参数含义变了：

熔断：连续超时或 429/5xx 率上升时打开；需注意供应商限流（429）与模型过载在观测上类似，但恢复策略不同——429 常应退避而非立刻半开探测。
舱壁：为「LLM 调用」单独划线程池/连接池/并发槽，避免 Agent 占满 Web 请求线程（与 Nygard 在 Release It! 中讨论的 graceful degradation 前置条件同构）。
超时：单次 completion 超时必须小于用户 deadline；Agent 总超时需单独配置。
重试：仅对网络错误、429、明确可重试的 5xx；对「输出格式错误」应走修复 prompt 或降级，而非 blind retry。

Google SRE 一书在讨论过载时强调：在依赖已经变慢时，上游应快速失败并 load shedding，而不是排队等待[2]（B 级，Site Reliability Engineering）。类比到 LLM：当推理集群排队深度飙升、TTFT 恶化时，继续接受新 Agent 任务会把 token 预算和队列一起耗尽——这与限流与过载保护的入站视角互补：出站看 LLM 供应商/集群健康，入站看本服务是否还能承接新的 AI 功能流量。

下表把 Google SRE 过载处理模式类比到 LLM 场景。注意这是工程类比，不是 SRE 原文直接讨论 LLM：

SRE 过载模式[2]	传统依赖场景	LLM 场景类比
请求排队（Queueing）	线程池排队等待下游	推理引擎 continuous batch 排队，TTFT 上升
负载脱落（Load shedding）	返回 503，丢弃低优先级	关闭「深度研究」、拒绝新 Agent、强制短上下文
降级（Degraded mode）	返回缓存/简化结果	切换更小模型、跳过 rerank、仅返回检索摘要
客户端 throttling	上游限制并发	网关 token-rate limit、租户并发上限
重试风暴	下游故障时重试放大	429 时 blind retry 导致双倍 token 与队列恶化

类比的价值在于：LLM 集群「变慢」时，症状与「健康但过载的服务」相同——429、排队、TTFT 上升——而不是典型的 5xx 宕机。运维 playbook 应同时包含熔断（供应商故障）与限流（自身过载），不可只配其一。

2.6 失败模式清单

现象	可能被误判为	实际根因	架构手段
HTTP 200 但业务报错	模型幻觉	JSON schema 失败、tool 参数类型错误	终态校验 + repair 上限
延迟 P99 飙升	网络问题	生成长报告、context 接近 $W$ 触发压缩	输出 token 上限、任务分级
成本日环比 3×	流量攻击	多 Agent fan-out、repair loop	Subagent 上限、预算硬顶
间歇性 429	下游宕机	租户配额或供应商 RPM 触顶	退避 + 租户级 token rate limit
工具「偶发失败」	工具服务 bug	模型选错工具或编造参数	工具描述治理 + 执行前 schema 校验

三、超时与预算：deadline 传播、流式与非流式

3.1 两级超时模型

LLM 系统至少需要两级超时：

级别	作用域	典型触发	用户可见结果
L1：单次 completion	一次 API 调用或一条 SSE 流	TTFT/E2E 超限	截断输出、返回 504、或切换备用模型
L2：任务/会话	整段 Agent 工作流	总 wall-clock 或总 token 超限	保存 checkpoint、返回部分结果、转异步

L1 对应传统 RPC timeout；L2 是 Agent 架构新增。只配 L1 会导致 Agent 永远跑不完；只配 L2 会导致单轮生成占满整个 budget。

3.2 Deadline 传播

级联超时预算的原则是：从外向内分配剩余时间。gRPC 的 deadline propagation 在 LLM 链路上的映射如下：

sequenceDiagram
    participant U as Client
    participant G as API Gateway
    participant O as Orchestrator
    participant L as LLM Provider
    participant T as Tool Service

    U->>G: request (deadline=30s)
    G->>O: forward (remaining=29s)
    O->>L: completion (remaining=25s)
    L-->>O: tool_calls
    O->>T: invoke tool (remaining=20s)
    T-->>O: result
    O->>L: next turn (remaining=15s)
    Note over O,L: abort if remaining less than min_prefill_budget

传播规则建议：

入口（网关或 BFF）写入 X-Request-Deadline 或 W3C traceparent 携带的 baggage。
编排器在每一轮 LLM 调用前计算 $\mathrm{remaining} = deadline - now$ ；若 $\mathrm{remaining} < \mathrm{TTFT}_{\mathrm{p99}} + \mathrm{min\_decode}$ ，不再发起新 completion，进入 winding-down。
工具调用使用 $\min(\mathrm{remaining}, tool\_timeout)$ ；工具超时必须短于 LLM 轮次剩余时间，留出至少一次「用工具结果修复答案」的 decode 预算。
并行 Subagent（若存在）共享父 deadline，而非各拿满额 30s——否则 wall-clock 由最慢子任务决定，与 Anthropic 当前「Lead 同步等待 Subagent 集合」的模式一致[1]。

3.3 流式 vs 非流式

模式	协议	超时语义	适用
非流式	单次 HTTP JSON	E2E 超时 = 整段生成完成	短输出、批处理、结构化 JSON
流式	SSE / chunked	首 token 超时 + inter-chunk 空闲超时	聊天 UI、长报告、提前取消

流式输出的架构收益：

更早反馈：TTFT 到达即可渲染，用户容忍更长总时间；
更早取消：用户离开页面时 abort SSE，节省 output token（需网关与推理引擎支持 disconnect 检测）；
分级超时：idle_timeout（两 token 之间）与 total_timeout 分开配置，避免生成卡住占满连接。

流式的代价是中间态不可校验：在最后一个 chunk 之前，无法对完整 JSON 做 schema validate。架构上常见两种策略：

流式展示 + 终态校验：UI 先展示 markdown，后台在 \``json` 闭合后 parse；失败则展示「生成未完成，请重试」且不执行工具。
非流式关键路径：凡驱动工具或写库的步骤，强制非流式或 buffered stream。

OpenAI 的 Responses API 与 Agents SDK 将 tool loop 与 trace 纳入同一调用会话[3]（B 级，OpenAI 开发者文档，2025），本质上把 L1 多次 completion 包装成一次「逻辑请求」，但 deadline 仍须在应用层贯穿——SDK 不会替你做租户级总预算。

3.4 预算分配算例

设用户-facing deadline 为 $D=30$ s，入口网关消耗 $g=0.5$ s，最小保留给最终聚合与返回 $r=2$ s，则编排器可用预算 $B = D - g - r = 27.5$ s。

串行 Agent 共 $n$ 轮，每轮含 LLM 与可选工具。记第 $i$ 轮 LLM 预期耗时 $L_i$ ，工具耗时 $T_i$ 。简单策略：

\sum_{i=1}^{n} (L_i + T_i) \leq B

启动第 $k$ 轮前，若 $\mathrm{remaining} < L_k^{\mathrm{p99}} + T_k^{\mathrm{p99}} + r$ ，应停止新轮次，进入 satisficing（返回已有 partial result 或提示「时间不足，已保存进度」）。 $L_k^{\mathrm{p99}}$ 应来自按 当前上下文 token 数分桶 的历史统计，而非全局单一常数——context 从 2k 涨到 80k 时，Prefill 时间非线性上升。

并行 Subagent 时，父任务 wall-clock 约为 $\max_j W_j$ （ $W_j$ 为第 $j$ 个子任务耗时），但 token 成本为 $\sum_j C_j$ 。预算检查应同时约束 wall-clock 与 token：

$\max_j W_j \leq \mathrm{remaining}$ （同步等待模式）；
$\sum_j C_j \leq \mathrm{token\_budget\_remaining}$ 。

Anthropic 在 prompt 中为不同复杂度档位规定 subagent 数量与 tool call 次数[1]，可理解为 heuristic budget allocator——尚未有开源的等价物，多数团队应在编排器硬编码 tier 规则。

3.5 取消与部分结果

用户取消（关闭页面、点击 stop）时，架构应：

传播 cancel：网关 abort 下游 SSE；编排器收到 cancel 后不再发起新 LLM 轮次；
结算已消耗 token：取消不等于退款，成本归因仍记录；
持久化 partial：长任务应把已完成 Subagent artifact 写入 store，用户稍后通过 task_id 取回；
工具副作用：若 cancel 发生在 tool 执行中，依赖 tool 的幂等与 compensating action——不能假设「用户取消了就不会写库」。

3.6 与站内弹性三篇的衔接

三篇的分工在 AI 场景下的映射：

flowchart LR
    subgraph outbound[&#34;Outbound (24)&#34;]
        CB[Circuit breaker on LLM 429/5xx]
        BH[Bulkhead: AI thread pool]
        TO[Per-completion timeout]
    end
    subgraph inbound[&#34;Inbound (25)&#34;]
        RL[Rate limit AI endpoints]
        Q[Queue depth shed]
    end
    subgraph degrade[&#34;Degrade (26)&#34;]
        FB[Fallback: cheaper model / cache]
        FF[Feature flag: disable Agent]
    end
    outbound --> inbound --> degrade

24 弹性：LLM 供应商切换（fallback model）、对 embedding 服务的熔断、Agent 工具调用的舱壁。
25 过载：按租户/功能限制 Agent 并发、限制「深度研究」类高 token 功能的 QPS。
26 降级：关闭「多 Agent 研究」、降级到单轮 RAG、返回缓存答案——须预先定义，不能等 429 才临时决定。

四、成本治理：网关预算、配额与错误处理

4.1 为何成本是架构问题

传统 API 的成本与 QPS 近似线性；LLM 成本与** prompt 长度 × 轮次 × 模型单价 × 并行 Agent 数**耦合。Anthropic 工程文给出数量级：multi-agent 相对聊天约 15× token，且「只有任务价值足够高才经济可行」[1]。这意味着：

不能把模型调用散落到各业务服务而无汇总；
不能把「用户点击一次研究」当成一次 HTTP 请求计费；
必须在架构上定义 budget envelope（预算包络）。

4.2 网关层预算

大模型网关是企业级 LLM 调用的统一入口：virtual key、团队配额、模型路由、fallback、审计。AI 原生架构在网关之上还需三层预算：

预算类型	粒度	enforcement 点	超限行为
租户/团队日预算	$/day 或 token/day	网关	拒绝新请求或强制 cheap model
单次请求 token 上限	$T_{\mathrm{in}}, T_{\mathrm{out}}$	网关 + 编排器	截断 prompt / 停止 decode
Agent 任务预算	max tokens 或 max $ per task	编排器	checkpoint 后优雅结束

网关适合 enforcement 硬顶（没有预算就不转发）；编排器适合 enforcement 软顶（接近预算时压缩策略：减少 Subagent 数、缩短工具调用、切换小模型）。Anthropic 在 prompt 里嵌入「按查询复杂度 scale effort」的规则——简单查询 1 个 agent、复杂研究 10+ subagent——本质是把成本策略写进控制平面[1]。

4.3 按请求与租户配额

与 25 限流的 QPS 限流并列，LLM 需要 token-rate limit 与 concurrency limit：

Token rate：每分钟每租户最多消耗 $N$ input token，防止单租户拖垮共享集群；
Agent concurrency：每租户最多 $K$ 个并行 Agent 任务，防止 fan-out；
Tool fan-out：单次 Lead Agent 最多 spawn $M$ 个 Subagent（Anthropic 早期失败模式是 spawn 50 个子 agent[1]）。

429 语义：网关返回 429 时，客户端应指数退避，且不应与「模型输出格式错误」共用同一 retry 策略——否则重试风暴叠加 token 双倍计费，复现 24 中的放大效应。

4.4 成本与错误处理的联合设计

Anthropic 文强调 errors compound in agentic systems：小故障导致 Agent 换轨迹，浪费已消耗 token[1]。架构应对：

可恢复 checkpoint：错误时从上一稳定点 resume，而非从头重跑（见第六节）。
工具失败显式反馈给模型：让 Agent adapt，而不是 silent fail 后空转。
确定性重试层：网络/429 由 SDK/网关重试；逻辑错误由编排器决定是否重试同一 prompt。
成本归因 trace：每次 tool/LLM 调用带 tenant_id、feature、task_id，便于事后分析「哪类 Agent 最烧钱」——与 LLM 可观测性的成本层对齐。

五、不确定输出：schema 校验、工具边界、人审与回放

5.1 两层「正确」

LLM 输出需区分：

传输正确：HTTP 200，finish_reason 非 error；
契约正确：JSON 符合 schema、枚举值合法、数值在范围内；
业务正确：事实准确、操作授权、符合政策——后两者无法单靠 schema 保证。

架构上应把 contract validation 做成硬闸门，business validation 做成软闸门（LLM-as-judge、规则引擎、人审）。

Contract validation 失败时：不执行工具、不写库、返回可重试错误。Business validation 失败时：可触发人审、二次检索、或降级回答「无法确认」。混淆两者会导致：schema 通过但业务荒谬的请求被执行（如负数退款金额若 schema 仅约束为 integer 而未设 minimum）。

5.2 Schema 校验

主流 API 提供 Structured Outputs / JSON mode / tool schema，将生成约束到 JSON Schema 子集。工程要点：

Validate after generate：即使用 structured output，也应在应用层用同一 schema 再校验一次（防御 SDK/模型版本差异）。
Repair loop 有上限：解析失败时，把错误信息喂回模型修复，最多 $R$ 次（通常 $R \leq 2$ ）；超过则 fail fast，避免 token 黑洞。
Schema 稳定性：schema 变更走契约测试流程；Agent 工具定义版本化。

from pydantic import BaseModel, ValidationError

class RefundIntent(BaseModel):
    order_id: str
    amount_cents: int
    reason: str

def parse_intent(raw: str, max_repairs: int = 1) -> RefundIntent:
    for attempt in range(max_repairs + 1):
        try:
            return RefundIntent.model_validate_json(raw)
        except ValidationError as e:
            if attempt == max_repairs:
                raise
            raw = repair_with_llm(raw, errors=e.errors())
    raise RuntimeError("unreachable")

示例仅为架构说明；生产环境应固定 repair prompt 模板并记录 repair 次数指标。

Structured output 与 JSON mode 的差异在于约束强度：前者通常保证输出符合 schema 子集；后者仅要求合法 JSON，字段仍可能缺失。架构上应优先 structured output 用于驱动副作用的路径；JSON mode 适合探索性分析。

多工具并行返回时（Anthropic parallel tool use、OpenAI parallel function calls），执行顺序在架构上应视为未定义，除非业务显式串行化。并行 tool 的 partial failure 处理：

All-or-nothing：任一 tool 失败则整轮作废（适合强一致读）；
Best-effort merge：成功结果写回上下文，失败 tool 错误信息供下轮 LLM 修复（Research 类任务常用[1]）；
Compensating：写操作 tool 失败时调用 undo tool（需工具层支持 Saga）。

5.3 工具调用边界

Agent 通过 function calling / MCP 触达外部系统。架构边界：

层级	职责	详见
工具 schema	参数类型、必填字段	本篇
授权	该 Agent 能否调此工具、行级 scope	Agent 身份
执行沙箱	SQL 只读、路径白名单、网络 egress	agent-identity / 后续 Part XV
副作用闸门	写操作需 HITL 或二次确认	下文 5.4

原则：LLM 不应持有长期凭证；工具执行器用短期 token、委托链（Token Exchange）或代理账号，见 agent-identity 系列第 2–4 篇。

Anthropic 强调 tool design is as critical as HCI：错误工具描述会把 Agent 引向完全错误路径；MCP 工具描述质量参差不齐时问题更严重[1]。架构上应把工具注册纳入 平台治理：描述审查、版本、集成测试（tool-testing agent 思路[1]）。

5.4 人审闸门（Human-in-the-Loop）

高风险操作（转账、删库、对外发邮件、批量改权限）在架构上应为显式状态，而非 prompt 里写「请谨慎」：

stateDiagram-v2
    [*] --> Planning
    Planning --> AwaitingApproval : action exceeds risk tier
    Planning --> Executing : low risk auto
    AwaitingApproval --> Executing : human approve
    AwaitingApproval --> Rejected : human reject
    Executing --> Done
    Rejected --> [*]
    Done --> [*]

触发条件应确定性（金额阈值、资源类型、租户策略），不应完全交给模型自判。审批状态持久化、超时、审计日志与 agent-identity 第 5 篇 Human-in-the-Loop 一致；本篇不展开 OAuth 细节。

5.5 可回放追踪（Replayable Tracing）

调试非确定性系统需要 replay bundle，至少包含：

模型 ID 与版本（含权重快照标识，若自建）；
完整 prompt 模板版本、变量、tool definitions 版本；
采样参数（temperature、top_p、seed）；
工具调用输入输出（脱敏后）；
检索结果 snapshot（若 RAG）。

OpenTelemetry GenAI 语义约定（2025 稳定版）为 gen_ai.operation.name、gen_ai.request.model 等 span 属性提供了跨工具标准[4]（A 级，OpenTelemetry 规范）。回放不等于重放生产流量：在 staging 用同一 bundle 复现，对比输出漂移，用于回归 eval。

隐私约束：许多团队不能长期存完整 prompt/completion。此时 replay bundle 拆为：

热存储（7 天）：全文，加密，严格 ACL；
冷存储（90 天）：hash + 结构化决策轨迹；
合规删除：用户删号时按 trace_id 级联删除。

六、编排：同步 Agent、异步 Agent 与 checkpoint/resume

6.1 编排模式谱系

模式	协调方式	优点	缺点
单 Agent 循环	单上下文 tool loop	简单、易 trace	长任务上下文爆炸
同步 orchestrator-worker	Lead 等待 Subagent 批次	协调简单、结果易合并	Lead 阻塞、并行度受限
异步 orchestrator-worker	Lead 继续执行、Subagent 回调	更高并行、更短 wall-clock	状态一致性与错误传播难
显式状态图	LangGraph / 自研 DAG	checkpoint 一等公民	建模与运维成本高

Anthropic Research 采用 orchestrator-worker，且 Lead 同步等待 Subagent 集合完成；文内指出异步 execution 能进一步并行，但带来 result coordination、state consistency、error propagation 挑战，预期模型能力增强后 worth the complexity[1]。这是当前（2025）工程上的活跃权衡，不是「异步一定更好」。

OpenAI Agents SDK 用 handoff 把路由交给模型，配合 Responses API 的内置 trace[3]（B 级）；LangGraph 等框架把 checkpointer 作为持久化原语[5]（B 级，框架文档）。架构选型应看：任务是否长时、是否需人审中断、是否需跨部署升级不断话——而非框架流行度。

6.2 同步 vs 异步的架构决策

选同步当：

用户在线等待完整答案；
Subagent 数量有硬上限（如 ≤5）；
合并逻辑简单（列表拼接、投票）。

选异步当：

任务 > 1–2 分钟或 token 预算 > 单次上下文；
Subagent 可独立交付 artifact（报告章节、代码 patch）；
需要「先返回 task_id，完成后通知」。

异步必须配套：任务状态 API、Webhook/SSE 进度、取消语义、partial result 存储。

6.3 Checkpoint 与 resume

Anthropic 生产经验：agents are stateful and errors compound；minor failures 不应 full restart；系统应从错误发生点 resume[1]。Checkpoint 应记录：

编排状态（当前节点、已完成 Subagent 列表）；
外部 memory 指针（研究计划、artifact URI）；
已消耗 token / 成本；
模型与 prompt 版本（升级时决定是否 migrate）。

部署协调：Agent 长任务与 rainbow deployment 类似——新旧版本并存，在途任务跑旧版，新任务进新版[1]。这与部署架构的金丝雀一致，但 Agent 的 stateful web 要求更严格的版本兼容策略。

LangGraph 的 checkpointer 模式：每 super-step 持久化 graph state；resume 时从 last checkpoint 继续。无论用何种框架，checkpoint 间隔应在「太稀疏丢太多进度」与「太频繁写放大」之间折中——典型每完成一个 Subagent 或每 N 轮 tool loop 一次。

Checkpoint 存储最低字段建议：

{
  "task_id": "uuid",
  "checkpoint_seq": 12,
  "orchestrator_version": "2026.07.29-a",
  "model_routes": {"lead": "claude-sonnet-4-20250514"},
  "state_ref": "s3://artifacts/task_id/state.json",
  "token_consumed": {"input": 84200, "output": 12100},
  "deadline_at": "2026-07-29T14:30:00Z",
  "status": "running"
}

state_ref 指向完整 graph state 或 message list，不应塞进 metrics 系统。Resume 时校验 orchestrator_version：不兼容则 fork 新 task 或只读打开 artifact，避免 silent behavior change。

Anthropic 还提到 Subagent output to filesystem：子 Agent 将大段结果写入外部系统，仅向 Lead 返回轻量引用，避免「电话游戏」式在多 Agent 间复制大文本导致 token 浪费与信息失真[1]。架构上应对 artifact 设 TTL 与 tenant 隔离，与对象存储生命周期策略一致。

6.4 上下文管理与 Memory 外置

长时 Agent 不能无限堆 message history。Anthropic 做法：

Lead 将 plan 写入 Memory；
接近 context 上限时 summarize 已完成阶段；
必要时 spawn fresh subagent 带干净上下文，通过 artifact 引用传递结果[1]。

架构组件：

组件	存储	用途
Working context	模型上下文	当前轮 prompt
Session memory	Redis / DB	计划、摘要、用户偏好
Artifact store	S3 / 文件系统	大段输出、子 Agent 报告
Vector memory	向量库	可选；见第八节

七、可观测：不记录对话内容时的决策模式追踪

7.1 观测目标

LLM 可观测性常见三难：

需要足够细节以 debug；
不能长期存 PII/商业秘密；
Agent 路径动态，固定 span 名不够。

Anthropic 的做法：full production tracing 诊断失败原因，但不监控 individual conversation contents；转而 monitor agent decision patterns and interaction structures[1]。

7.2 可记录的「非内容」信号

信号类别	示例字段	用途
拓扑	agent_role, parent_span_id, parallel_branch_index	理解决策树
工具	tool_name, tool_version, latency_ms, status	发现错误工具选择
模型	model_id, input_tokens, output_tokens, finish_reason	成本与异常 finish
策略	effort_tier, subagent_count, repair_attempts	成本治理
质量 proxy	schema_valid, citation_count, user_feedback	无正文的质量趋势

OpenTelemetry GenAI spans 可表达 gen_ai.tool.name、gen_ai.usage.input_tokens 等[4]；Agent 框架应把 tool loop 每一轮 作为 child span，而非整段 Agent 一个 span。

7.3 决策模式 vs 内容

Decision pattern tracing 关注：

Subagent 数量分布是否长尾（spawn 过多）；
工具调用序列是否重复（死循环搜索）；
同一 query class 的 token 消耗漂移；
从「broad query」到「narrow query」的迭代次数（搜索策略是否生效）。

这些指标可在 不存 prompt 明文 的情况下告警。需要下钻时，通过 采样 + 临时 elevated logging（带审批）打开内容记录。

与 67 分布式追踪的衔接：trace_id 从网关进入，贯穿 orchestrator、LLM SDK、tool executor；** baggage 携带 tenant、feature、budget_id**，便于与 metrics 关联。

7.4 Eval 与生产观测闭环

Anthropic 建议 start small evals（~20 条真实 query）即可感知 prompt 改动的大幅影响[1]；生产上用 LLM-as-judge 按 rubric 打分，但 human evaluation catches what automation misses（如 SEO 农场 vs 权威 PDF 的源选择偏差[1]）。

架构上应分离：

在线：决策模式 metrics + 采样 judge；
离线：固定 golden set + 阻塞发布的 regression gate。

详见 LLM 可观测性质量层；本篇强调 architecture 层要把 eval hook 留接口，而不是事后补 dashboard。

7.5 告警规则示例（不含正文）

以下阈值均为架构设计示意，须按租户规模校准，非本站实测：

告警	条件	可能含义
`subagent_spawn_p99 > 8`	5min 窗口	Lead prompt 失控或缺少 effort scaling
`tool_call_loop_count > 20`	单 trace	搜索死循环或工具失败重试
`schema_repair_rate > 15%`	1h 窗口	schema 变更未同步或模型版本漂移
`token_per_successful_task p99`	较 7d 前 +100%	多 Agent 默认开启或检索返回过长
`hitl_queue_age p99 > 10min`	—	人审成为瓶颈，需扩审批人或降级

告警应链到 trace_id 采样面板（可临时开启内容记录），而非把 prompt 打进 Slack。

7.6 与 SLO 工程的关系

28 SLO 工程为传统服务定义 availability 与 latency SLO。LLM 功能建议拆三条 SLO：

Availability SLO：网关 + 推理集群返回非 5xx/非持续 429 的比例；
Latency SLO：按功能分——聊天 TTFT、RAG E2E、Agent 任务 wall-clock；
Quality SLO（error budget 慎用）：eval pass rate 或用户 thumbs-down 率——应用慢燃指标，避免与 latency SLO 混在一个 error budget 里。

Agent 的 quality SLO 下降时，优先减 feature（26 降级）而非盲目加模型能力——否则成本 SLO 也会失守。

八、与 RAG、向量引擎的边界

8.1 分层

flowchart TB
    subgraph app[&#34;Application / Orchestration (this article)&#34;]
        AG[Agent orchestrator]
        BUD[Budget / timeout / HITL]
        VAL[Schema validation]
    end
    subgraph rag[&#34;RAG pipeline (llm-infra)&#34;]
        CH[Chunking / embedding]
        RET[Retrieve / rerank]
        CTX[Context assembly]
    end
    subgraph vec[&#34;Vector engine (db/vector-engine)&#34;]
        IDX[Index / segment / WAL]
        SRCH[ANN search / hybrid filter]
    end
    subgraph infer[&#34;Inference (llm-infra)&#34;]
        GW[LLM gateway]
        ENG[vLLM / SGLang]
    end
    AG --> BUD
    AG --> RET
    RET --> SRCH
    RET --> CTX
    CTX --> GW
    GW --> ENG
    AG --> VAL

本篇负责：编排、预算、校验、人审、trace 语义、Agent 生命周期。

llm-infra RAG 工程负责：文档解析、切片、embedding 选型、混合检索、GraphRAG、RAG 评测——效果差时逐层排查，不在应用层重复实现。

向量检索引擎负责：Milvus Segment 状态机、Knowhere 索引、Growing/Sealed 路径、标量过滤与召回——不把 ANN 算法与 Segment 运维塞进应用服务。

llm-infra 推理服务化负责：PD 分离、continuous batching、KV cache——应用层只消费 SLA（TTFT、TPOT、max concurrency）。

8.2 接口契约

应用层与 RAG/向量层之间应固定 检索 API 契约：

query, top_k, filters, tenant_id；
返回：chunk_id, score, content_hash（不一定返回全文若权限敏感）；
SLA：p99_latency_ms, recall@k 来自离线 eval，非线上硬保证。

Agent 不应直接嵌 SQL 访问向量库；通过 retriever service 统一审计与缓存（语义缓存见 llm-infra 网关篇）。

8.3 权限与多租户

RAG 链路中的 tenant_id 必须在检索层强制过滤，不能仅靠 prompt 告诉模型「只看本租户数据」。向量库侧标量过滤、row-level security 与向量引擎混合过滤篇讨论的 post-filter 召回陷阱，都属于数据平面职责。应用编排层只传递 tenant_id 与 query，不实现 ANN。

Embedding 模型版本变更时，re-embed 与双写策略在 llm-infra 与 vector-engine 系列讨论；应用层 Agent 应感知 embedding_model_version 并在检索请求中携带，避免混索引。

8.4 何时 RAG 不够、需要 Agent

RAG 适合 静态 corpus 上的单次或少数轮问答；需要 多步搜索、动态源选择、跨工具整合 时进入 Agent 域——Anthropic Research 明确区分 static RAG retrieval vs multi-step dynamic search[1]。架构上不要用「加个 Agent」弥补烂 RAG；反之，不要用复杂 Agent 替代本应固定的 retrieval pipeline。

九、控制流与参考架构

9.1 端到端控制流

flowchart TD
    REQ[Client request] --> GW[API Gateway]
    GW --> AUTH[AuthN / tenant quota]
    AUTH -->|reject| R429[429 / budget exceeded]
    AUTH --> ORCH[Orchestrator]
    ORCH --> BUD{Budget OK?}
    BUD -->|no| DEG[Degraded path / cheap model]
    BUD -->|yes| RET{Need retrieval?}
    RET -->|yes| RAG[RAG service]
    RAG --> LLM[LLM call]
    RET -->|no| LLM
    LLM --> PARSE{Schema / tool parse OK?}
    PARSE -->|repair| LLM
    PARSE -->|fail| ERR[Structured error]
    PARSE -->|tools| POL{Policy / HITL}
    POL -->|approve| TOOL[Tool executor]
    POL -->|reject| ERR
    TOOL --> CKPT[Checkpoint]
    CKPT --> ORCH
    LLM -->|done| OUT[Response]
    DEG --> OUT

9.2 组件职责表

组件	输入	输出	关键 SLA
API Gateway	HTTP	路由 + 配额	拒绝超限、trace 起点
Orchestrator	任务描述	多轮 LLM+tool	任务 deadline、checkpoint
LLM Gateway	OpenAI-compatible	completion	token 计费、fallback
RAG Service	query	context blocks	retrieval p99
Tool Executor	validated tool call	side effect / read	幂等、授权
Observability	spans	metrics/logs	无正文决策追踪

9.3 部署拓扑变体

集中式（默认）：Orchestrator 与 Retriever 同 VPC，LLM 走网关到云端或自建集群。适合多数 SaaS。

边缘辅助：轻量分类/embedding 在边缘，重 Agent 回源——与 Cloudflare 案例的 Workers 哲学相关，细节在 96 边缘计算。架构约束是 checkpoint 与 artifact 仍在中心 store，边缘只无状态预处理。

VPC 内私有化：金融/政务场景模型与向量库均在客户 VPC；网关负责审计不出域。Agent 编排逻辑不变，budget 与 HITL 更严格。

9.4 与 Part XV 的分工

主题	本篇（95）	Part XV（101+）
超时/成本/编排	运行时架构	—
Agent 身份/MCP	边界点到为止	agent-identity 系列
AI 生成代码的破坏半径	不展开	101 防御性架构
CI/评测兜底	eval hook	102 工程基础设施
ADR/C4 作 Agent 上下文	不展开	103 架构即上下文
人机开发与变更门禁	不展开	104 AI 原生开发流程

十、学术谱系、争论与开放问题

10.1 谱系：从 RPC 到 Agent 控制流

经典 RPC / 超时预算：分布式系统把远程调用当作本地调用的失败版本；deadline propagation 是 Google gRPC 与 SRE 实践的标配[2][6]。
ReAct（Yao et al., ICLR 2023）：交错生成 reasoning 与 action，奠定 tool loop 范式[7]（A 级，定义 Agent 控制流）。
Toolformer（Schick et al., NeurIPS 2023）：模型自监督学习何时调用 API[8]（A 级，工具调用作为生成的一部分）。
生产 multi-agent（Anthropic, 2025）：orchestrator-worker、parallel tool call、memory 外置与 rainbow 部署[1]（B 级，工程化延伸）。

分叉点在于：论文中的单 Agent loop 在 production 中因成本、可靠性、隐私演化为 网关 + 编排器 + 专用 retriever + 策略引擎 的分层——这与 microservices 从「单体 RPC」演进的路径类似，但非确定性与 token 计费是新的质量属性。

10.2 争论：结构化输出 vs 灵活生成

一派主张 强 schema（Structured Outputs、Pydantic、OpenAPI tool schema）：降低解析失败、便于静态分析。另一派指出过严 schema 限制模型推理空间，复杂任务需要自由文本 intermediate steps。工程上常见折中是 「自由思考 + 终态 structured block」（chain-of-thought 不直接执行，仅 final_answer JSON 驱动副作用）——与 Anthropic extended thinking 把 planning 放在可控 scratchpad 的思路同构[1]。

尚无跨任务的最优解；高风险写操作应偏向强 schema + HITL，只读研究可偏向自由文本 + 终态 citation agent（Anthropic CitationAgent[1]）。

10.3 开放问题

跨 Agent 异步协调的标准语义：错误传播、partial failure 补偿、Exactly-once tool side effect 在 multi-agent 下尚无广泛接受的协议（对比 Saga / 2PC 在 microservices 中的成熟度）。
Budget-aware planning 的形式化：如何在 deadline 与 token 预算约束下最优分解任务，论文多关注 single-agent RL，生产系统多用 prompt heuristics[1]——缺少可验证的代价模型。
无正文 observability 的充分性边界：决策模式追踪能否替代内容审计满足合规（金融、医疗）——取决于 jurisdiction 与 retention 规则，工程上无统一答案。
Eval 与生产分布漂移：BrowseComp 类 benchmark 显示 token 用量解释大量方差[1]，但生产 query 分布持续变化，阻塞发布的 eval set 如何保鲜——开放于 MLOps / LLMOps 交界。
上下文压缩的可信度：长对话 summarize 后信息损失如何量化、何时必须人审——与 RAG chunking 信息损失同类，跨 Agent memory 与 vector store 的统一理论仍少。

可读入口：OpenTelemetry GenAI SIG 对 span 模型的持续演进[4]；Anthropic Cookbook 中的 multi-agent prompt 样例[1]；本站 db-frontier 向量索引对 retrieval 假设的讨论。

十一、小结

LLM 成为运行时组件后，架构师面对的不是「多调一个 API」，而是一组新的质量属性：非确定性、token 计费、双级超时、Agent 状态、成本 fan-out、契约校验与隐私友好的观测。这些议题与弹性、过载、降级直接衔接，但必须在 网关、编排器、工具执行器 三层分别落地。

可操作的优先级建议：

入口：网关 virtual key + 租户 token 预算 + AI 功能舱壁；
路径：deadline propagation + 流式 idle timeout + 单次/任务双超时；
输出：schema 硬闸门 + 工具授权分离 + 高风险 HITL；
长任务：checkpoint/resume + rainbow 部署 + artifact 外置；
观测：OpenTelemetry GenAI span + 决策模式 metrics，正文采样；
边界：RAG/向量/推理下沉到 llm-infra 与 vector-engine，身份与 MCP 深入见 agent-identity。

AI 原生架构仍在快速演进；multi-agent 的异步化、budget-aware planner、以及与 edge（下一篇 96）结合的本地小模型兜底，都是 2026 年值得持续跟踪的方向。

参考资料

规范与标准

OpenTelemetry, Semantic Conventions for Generative AI, GenAI tracing stable conventions, 2025.（A 级）
gRPC Authors, Deadline propagation, gRPC Concepts documentation.（A 级）

官方设计与工程博客

Hadfield, J. et al., "How we built our multi-agent research system," Anthropic Engineering Blog, 2025-06-13.（B 级）[1]
OpenAI, "Introducing the Responses API and Agents SDK," OpenAI Developers Blog, 2025.（B 级）[3]
Beyer, B. et al., Site Reliability Engineering, O'Reilly, 2016 — Ch. 22 "Addressing Cascading Failures"; Ch. "Handling Overload".（B 级）[2]
Humble, J., interview on Release It! graceful degradation, InfoQ, 2007.（B 级）

论文

Yao, S. et al., "ReAct: Synergizing Reasoning and Acting in Language Models," ICLR 2023.（A 级）[7]
Schick, T. et al., "Toolformer: Language Models Can Teach Themselves to Use Tools," NeurIPS 2023.（A 级）[8]
Turner, J., "New Directions in Communications," IEEE Communications Magazine, 1986 — leaky bucket traffic shaping 起源；与限流算法谱系相关。（A 级）

源码与框架文档

LangGraph Documentation, Persistence and Checkpoints, LangChain AI, 2025.（B 级）[5]
LiteLLM Proxy Documentation, budget and rate limit, BerriAI.（B 级）

实验与工具

本站 LLM 可观测性：TTFT/TPOT、GenAI trace 口径。（站内）
本站大模型网关：virtual key、语义缓存、fallback。（站内）

核心论文（本主题）

论文	年份	本文引用点
Yao et al., ReAct	2023	Agent tool loop 范式
Schick et al., Toolformer	2023	API 调用作为生成动作
Anthropic multi-agent engineering post	2025	生产 checkpoint、成本数量级、同步/异步权衡

系列导航：← Cloudflare 案例 · 系统架构设计索引 · 边缘计算架构 →