上一篇文章讨论了 Agent 的核心组件------RAG、向量库、Function Calling 与 Skill 体系。但把这些组件拼起来之后，更棘手的问题浮出水面：多轮对话怎么管？重复请求怎么省？上游挂了怎么办？
这三个问题对应的正是大模型后端设计的三大支柱：上下文管理、缓存策略和降级容错。如果说 Agent 的组件决定了系统"能做什么"，那这三大支柱决定了系统"能不能活下来"。
一、先理解核心矛盾：大模型的"无状态"特性
所有后端架构决策，都源于大模型的一个基本事实：每一次 LLM 调用都是无状态的。模型读上下文窗口，生成响应，然后忘掉一切。
这意味着：
所有记忆能力必须由应用侧实现。模型不会主动存储对话记录，如果两次请求之间不手动拼接历史内容，模型无法识别两次提问的关联。
每次请求都在重复"购买"上下文。用户的历史对话、系统提示、检索结果、工具定义------每一次调用都要重新传入，Token 成本随对话轮次加速增长。
模型的"健康状态"不可预测。延迟波动大、可能限流、可能超时，传统后端的健康检查机制在这里完全不够用。
理解了这三个约束，上下文管理、缓存、降级的设计就有了统一的出发点。
大模型后端 vs 传统后端的本质差异
维度 传统 Web 后端 大模型后端
响应耗时 10--100ms 1--20s（流式更长）
状态模型 无状态为主 强状态关联（上下文依赖）
资源瓶颈 CPU/内存/带宽 GPU 显存/算力
故障模式 快速失败 长时间阻塞→雪崩
降级方式 直接返回错误码 需要柔性兜底（缓存/小模型/静态答案）
大模型推理高度依赖 GPU 显存和算力，单卡能承载的并发数极其有限，贸然扩容还会产生极高的硬件成本，这是大模型后端必须做精细化流量管控的核心原因。同时，大模型推理是非确定性的，相同输入可能产生不同输出，这使得传统缓存的"精确匹配"策略在很多场景下失效。
二、上下文管理：从"什么都塞"到"精准投喂"
2.1 为什么上下文管理是后端设计的核心
上下文工程已经成为 Agentic 系统的独立基础设施层。Agent 失败最常见的原因不是模型能力不足，而是上下文设计失误：给得太少导致模型凭空猜测，给得太多导致上下文窗口溢出或触发"上下文腐化"，切割方式不对导致任务边界不清。
一个完整的 200K 上下文窗口，理想的分层结构应该是这样的：
text
┌─────────────────────────────────────────────┐
│ Layer 1: System Prompt 预算: 2,000--8,000 │
│ · 角色定义 / 能力边界 / 行为约束 / 输出格式 │
├─────────────────────────────────────────────┤
│ Layer 2: Injected Memory 预算: 3,000--10,000 │
│ · 长期记忆(压缩后) / 用户偏好 / 跨轮摘要 │
├─────────────────────────────────────────────┤
│ Layer 3: Retrieved Context 预算: 10,000--40,000│
│ · RAG检索结果 / 代码片段 / 架构决策文件 │
├─────────────────────────────────────────────┤
│ Layer 4: Conversation History 动态预算 │
│ · 近期对话原文 / 工具调用记录 │
├─────────────────────────────────────────────┤
│ Layer 5: Current Task 动态 │
│ · 当前问题 / 临时指令 / 结构化输出要求 │
└─────────────────────────────────────────────┘
关键原则：让模型在任意时刻看到的上下文窗口，恰好包含完成当前步骤所需的全部信息，且不多也不少。
2.2 四种上下文压缩策略的取舍
生产环境中最常用的四种上下文管理策略，各自适合不同场景：
策略 原理 成本 信息保留度 适用场景
滑动窗口 保留最近N轮对话，丢弃更早的 零成本，~0ms延迟 低（远期信息完全丢失） 高频短会话、客服机器人
摘要压缩 用LLM将旧对话压缩为摘要 高（额外LLM调用） 中（关键信息保留，细节丢失） 长对话Agent、代码助手
优先级截断 按消息重要性评分，保留高分消息 零成本 中（依赖评分准确性） 信息密度不均的场景
向量记忆 将历史存入向量库，按需检索 中（需向量化+检索） 高（按相关性召回） 跨会话、用户画像场景
滑动窗口保留最近几轮对话，最近几轮信息密度最高、最不该失真，用滑动窗口原样保留是成本最低的选择。而摘要压缩则适合更长的场景------生产系统如 Anthropic 的 Claude Code 和 OpenAI 的 Codex，以及 LangChain 和 LlamaIndex 等框架，都依赖 LLM 摘要调用来在接近窗口限制时压缩上下文。
实践中，最有效的方案是"滑动窗口 + 滚动摘要"的混合策略：维护一个会话级摘要，捕捉关键讨论点和用户目标；同时保留最近3--5轮对话的滑动窗口，用于维持语气和上下文连续性。
一个关键工程陷阱：滑动窗口虽然零成本，但可能破坏前缀缓存的连续性。如果每次请求的 system prompt 和工具定义都不同，前缀缓存永远无法命中。最佳实践是：一旦系统提示和工具定义确定，不要更改它们；动态信息（时间戳、用户状态）始终追加到对话末尾，而不是修改系统提示。
2.3 上下文持久化：四层架构
大模型本身无记忆能力，所有的上下文关联、对话记忆、用户会话状态，都需要业务层手动进行存储、裁剪、拼接、分发与销毁。一套完整的会话状态由四大模块组成：
对话上下文状态：系统角色设定、历史问答、临时指令，直接参与 Prompt 拼接，消耗 Token 最多
会话基础属性状态：会话ID、用户标识、创建时间、过期时长、状态标记（正常/冻结/归档/删除），用于会话隔离与生命周期管控
业务临时状态：工具调用记录、函数执行结果、中间计算数据、用户偏好配置
全局配置状态：单会话独立的模型参数（温度系数、最大生成长度、知识库绑定范围）
在存储层面，实践中可以按记忆寿命分层------寿命长的放前面不动（保证缓存复用），寿命短的放后面随时覆盖（状态栏），寿命已过的压缩或删除。
2.4 生产级记忆系统的五阶段流水线
更完整的方案是构建持久化记忆系统。LLM Agent 需要持久化记忆来支撑连续对话、用户画像、知识沉淀与崩溃恢复，但满上下文方案成本高、延迟大、易出错。
核心流水线是五阶段：抽取 → 整合 → 存储 → 检索 → 遗忘。同时区分四种记忆类型：
记忆类型 存放什么 存储位置 生命周期 典型失效模式
工作记忆 当前对话、工具结果 上下文窗口(prompt) 仅当前会话 窗口填满，模型跟丢早期指令
情景记忆 过往会话记录 向量数据库 数周到数月 检索到不相关旧情景、时间混淆
语义记忆 蒸馏出的事实、用户偏好 向量库/知识图谱 持久化 知识冲突、过时未更新
过程记忆 可复用的操作流程 结构化存储 持久化 流程变更后未同步更新
成本数据很能说明问题：满上下文方案在 LOCOMO 基准上能拿到 72.9% 的准确率，代价是 p95 延迟 17.12 秒、Token 开销翻 14 倍。一个中等规模 SaaS 若每月 1000 万次 Agent 调用，走满上下文仅 LLM Token 就约 100 万美元；同样的工作负载换成选择性记忆会降到约 10 万美元。这就是"demo 与能摆到付费用户面前的系统之间的分界线"。
三、缓存策略：AI 应用成本优化的最高杠杆
3.1 五层缓存架构
缓存是 AI 应用成本与延迟优化的最高杠杆手段------一次缓存命中可以节省 100% 的 LLM 调用成本与 95% 的延迟。但 AI 缓存比传统 Web 缓存复杂得多，需要语义匹配、TTL 与失效策略、以及多层分级。
完整的多层缓存架构如下：
text
请求 → L1:精确缓存 → L2:语义缓存 → L3:前缀缓存(KV) → LLM调用
↓命中 ↓命中 ↓命中(仅decode)
直接返回 直接返回 部分复用
各层的关键参数：
层级 匹配方式 目标命中率 延迟节省 TTL 存储
L1 精确缓存 query 完全匹配 15% 100% 1h Redis
L2 语义缓存 向量相似度>0.95 25% 95% 1h 向量库
L3 前缀缓存 系统提示 KV 复用 40% 70% 永久 GPU显存
L4 嵌入缓存 query 嵌入结果 30% 90% 24h Redis
L5 检索缓存 RAG 检索结果 20% 85% 5min Redis
这五层并非都要同时实现。建议按优先级逐步建设：先做 L1 精确缓存和 L3 前缀缓存（实现简单、收益高），再考虑 L2 语义缓存（复杂度较高），最后补上 L4/L5。
3.2 语义缓存：生产环境的分层设计
语义缓存是最有"AI特色"的一层。生产部署通常采用分层静态-动态设计：静态缓存存储经过离线审核的精选响应，动态缓存在线填充。
但实践中的一个硬约束是：两类缓存通常共用一个嵌入相似度阈值，这导致了硬性权衡------保守阈值会错过安全复用机会，激进阈值可能返回语义不正确的响应。
一个前沿方案是异步 LLM 裁判机制：当最近邻相似度略低于阈值时，异步调用 LLM 判断缓存响应是否可接受，通过验证的匹配被晋升到动态缓存。在模拟测试中，这种方法在对话流量上提升缓存命中率至 2.4 倍，在搜索型查询上提升 3.9 倍。
实现建议：对于已经使用 Redis 的团队，Redis 的向量搜索功能提供了生产就绪的语义缓存方案，无需引入新服务。语义缓存的阈值调优建议从 0.95 起步，逐步根据误命中率调整。
3.3 前缀缓存：最被低估的优化手段
前缀缓存（Prefix Caching）的机制是：当后续调用与之前的调用共享前缀时，推理引擎可以直接复用缓存的 KV 状态，而不需要重新计算整个 prefill。
但它的效果高度依赖严格的 Prompt 结构化。前缀缓存要求逐字节完全匹配，即使是微小的格式差异也会破坏缓存命中。工程上的应对策略是：
系统提示和工具定义一旦确定，不要随意更改。任何修改都会使所有缓存的 KV 状态失效。
动态信息追加到末尾。时间戳、用户状态等变化内容应作为新消息追加到对话末尾，而不是修改系统提示。
确定性的排序规则。对于检索结果等动态注入的内容，使用确定性的排序（如字母序）而非相似度分数排序，以保证相同内容集的前缀一致。
vLLM 与 Mooncake 的集成实践表明，通过将分布式 KV 缓存存储集成到 vLLM 中，可实现 3.8 倍吞吐量提升、首字延迟降低 46 倍、端到端延迟降低 8.6 倍。
3.4 缓存的失效与一致性
大模型缓存比传统缓存多了一层复杂性：知识更新后缓存需要失效。工程上的应对策略包括：
TTL 分层：精确缓存和语义缓存设 1 小时 TTL，检索缓存设 5 分钟，嵌入缓存设 24 小时（嵌入结果变化小）
版本化缓存键：当知识库或模型版本变更时，通过修改缓存键前缀使旧缓存自动失效
命中率监控：如果某一层的命中率持续低于预期，说明缓存策略或阈值需要调整
四、降级策略：保障系统不雪崩的最后防线
4.1 限流、熔断、降级的关系
在大模型高可用架构中，限流、熔断、降级是三大核心容错策略，三者是协同互补、层层防护的关系：
限流：事前防御，控制流量规模。通过限制单位时间内的请求数量防止 GPU 算力过载。
熔断：事中保护，隔离故障。当下游服务连续异常、错误率超标时，自动切断上游对故障服务的持续调用，快速失败防止资源耗尽。
降级：事后兜底，保障体验。上游不可用时提供低成本、高稳定的替代方案，确保核心业务可用。
三者的协同关系可以用一句话概括：限流挡流量、熔断断故障、降级给兜底。
4.2 大模型熔断的特殊设计
大模型推理服务有独特运行特性，传统熔断机制无法直接适配：
单次推理链路长，超时判定阈值需要远高于传统接口
GPU 显存与算力资源占用极高，并发承载能力有限
流式输出链路易中断，半开状态探测策略需要重新设计
第三方模型接口存在网络波动与配额限制
一个关键的工程洞察：限流的模型是健康的，不是故障的。将 429 限流视为"暂时降速"而非"失败"，不要触发熔断器，可以显著提升可用性。
生产中的错误分类处理策略：
错误类型 熔断器行为 降级动作
限流(429) 不计入失败，defer 路由到下一个候选模型
瞬时错误(5xx/超时) 计入失败 触发failover，可选重试
终端错误(auth/参数) 不计入失败（请求级问题） 返回明确错误，failover
熔断器采用三态流转模型：CLOSED（正常通行）→ OPEN（快速断连）→ HALF_OPEN（渐进放行）。
4.3 降级的四个层次
大模型服务降级需要覆盖模型推理层、向量检索层、知识库服务层、缓存层全链路，而非单一节点降级。按代价递增排列的四层降级策略：
L1 缓存兜底（代价最低） ：当模型推理超时或不可用时，直接返回缓存的历史回答。适合高频标准化问答场景。
L2 模型降配：从千亿参数模型快速切流至百亿参数模型以保底输出，牺牲部分推理精度换取响应速度。实测中，按意图复杂度自动选择模型档位后，日均 Token 成本降低 64%，同时复杂问题解决率不降。
L3 检索降级：当向量数据库故障时，跳过语义检索，直接使用关键词匹配或静态知识库。
L4 静态答案兜底（代价最高，体验最差） ：返回预置的标准话术，如"系统正在维护，请稍后重试"。这是最后的安全网。
在多模型 fallback 的路由策略上，推荐按可靠性排序的备用链：
第一回退：同供应商小模型------应对主模型并发限流
第二回退：备用供应商对应模型------应对主供应商网络或 API 错误
最终兜底：静态答案或缓存响应
4.4 降级的可观测性
降级必须埋点监控，统计各类降级发生频次。如果某一类降级大量触发，代表上游链路存在隐患，需要优化 Prompt、路由策略或者扩容模型资源。
关键 SLO 指标建议：成功率 ≥ 99.5%、P95 延迟、降级率 < 1%。每次降级事件都应记录：触发原因（超时/限流/错误）、降级层级、用户影响范围、恢复时间。
五、三大模块的协同：一个完整的请求生命周期
把上下文管理、缓存和降级串起来看，一个生产级大模型请求的完整链路是：
text
用户请求
│
├── 1. 网关层
│ ├── 限流检查（令牌桶/滑动窗口）
│ └── 上下文长度预检（ai-context-limit插件可在网关层提前拦截超限请求）
│
├── 2. 缓存层
│ ├── L1 精确缓存命中？→ 返回
│ ├── L2 语义缓存命中？→ 返回
│ └── 未命中 → 继续
│
├── 3. 上下文组装
│ ├── 加载会话状态（Redis/DB）
│ ├── 选择压缩策略（滑动窗口/摘要/向量检索）
│ ├── 注入记忆和检索结果
│ └── 拼接 Prompt（前缀缓存友好的结构）
│
├── 4. 模型调用
│ ├── 熔断器状态检查（CLOSED？OPEN？HALF_OPEN？）
│ ├── 路由选择（按复杂度/成本/可用性）
│ ├── 调用主模型
│ └── 失败？→ Fallback链：小模型 → 备供应商 → 静态兜底
│
├── 5. 响应处理
│ ├── 写入缓存（精确+语义）
│ ├── 更新会话状态
│ └── 记录可观测性数据（延迟/Token/降级标记）
│
└── 返回用户
这个链路中，网关层是承上启下的关键。现代 AI Gateway 不只是反向代理，而是集成了上下文限制检查、语义缓存、多模型路由和降级策略的治理层。
六、关键工程决策速查
决策点 推荐方案 核心理由
上下文压缩策略 滑动窗口(3-5轮) + 滚动摘要 兼顾近期精度和远期信息保留
上下文存储 Redis(热数据) + 向量库(冷数据) 按访问频率分层，降低延迟
缓存优先级 精确缓存 → 前缀缓存 → 语义缓存 按实现复杂度递增，收益递减
语义缓存阈值 0.95起步，逐步调优 保守阈值优先保证正确性
前缀缓存 系统提示固定不变，动态内容追加末尾 任何前缀变更都会使缓存失效
熔断阈值 错误率>50%持续30s触发 大模型场景需比传统服务更宽容
降级链路 缓存→小模型→备供应商→静态答案 按代价递增，优先保体验
可观测性 全链路追踪+降级埋点 没有数据就无法优化
七、写在最后
大模型后端的核心挑战，可以归结为一个根本矛盾：模型是无状态的、昂贵的、不稳定的，但用户需要的是有记忆的、经济的、可靠的体验。
上下文管理解决"记忆"问题------通过分层预算、压缩策略和持久化架构，在有限的窗口内精准投喂模型所需的信息。缓存策略解决"成本"问题------通过五层分级缓存，把高频、重复的请求拦截在 LLM 调用之前。降级策略解决"可靠性"问题------通过限流、熔断、降级的协同，在部分组件故障时仍能提供可接受的用户体验。
这三个模块不是独立的优化点，而是相互制约的系统工程。上下文压缩可能破坏前缀缓存，缓存策略可能影响降级判断，降级路由可能改变上下文长度------每一个决策都需要在全局视角下权衡。
正如一位一线工程师所说："这个问题的答案必须在出事之前写好，因为出事的当下你没有时间设计它。" 上下文管理、缓存和降级，都是需要在系统设计阶段就纳入架构的基础设施，而不是事后补救的补丁。