模型上下文是新型“稀缺资源”：我们如何设计分层缓存与摘要策略，将有效容量提升 5 倍-CSDN博客

在很多智能体项目的复盘会上，我经常听到类似的结论：

“模型不稳定，是因为上下文不够长。”

“只要换成 128K / 200K Context，就能解决问题。”

但在真实的工程和商业化环境中，这种判断往往是危险且昂贵的。在过去一年里，我参与过多个长流程 Agent、企业级 Copilot、复杂任务规划系统。一个反复验证成立的结论是：绝大多数上下文问题，并不是“长度不够”，而是“使用方式极度低效”。甚至可以说：Context，已经成为新一代 AI 系统中的“稀缺资源”。本文不讨论模型参数、不吹大 Context，而是从工程实践出发，聊一个更现实的问题：如何通过分层缓存与摘要策略，在不增加模型成本的前提下，把“有效上下文容量”提升 3–5 倍。

一、Context 正在变成系统瓶颈，而不是模型优势

从工程视角看，Context 至少同时扮演三种角色：

短期工作记忆（Working Memory）
任务状态载体（Task State）
隐式策略与历史约束

问题在于，大多数系统把这三类信息混在一起，线性堆叠。

典型做法是：

所有历史对话全部拼接
所有工具调用原样回放
所有中间思考、日志一起塞进 Prompt

短期看“模型还能跑”，长期一定出现以下问题：

成本线性上涨
延迟不可控
行为随历史增长而退化
新信息被旧噪声淹没

Context 并不是免费的。即便模型支持 128K，上下文仍然有三重隐性成本：

Token 成本
推理延迟
注意力稀释（Attention Dilution）

二、一个关键认知：不是所有上下文都“值得被记住”

在工程上，一个非常重要、但常被忽略的区分是：上下文 ≠ 记忆 。绝大多数 Context 内容，其实只属于以下几类：

已经完成的中间步骤
对最终决策无贡献的试错
临时工具调用结果
过期的用户偏好

但模型并不会“自动遗忘”。如果系统不主动管理，Context 只会无限累积。这直接导致一个结果：

Context 的增长速度，远快于其信息价值的增长速度。

三、从“上下文拼接”到“上下文架构”

成熟的智能体系统，一定会把 Context 当成架构资源来设计，而不是字符串。

我通常将 Context 按“时间价值”和“使用频率”拆成四层：

L0：即时上下文（当前回合） L1：短期状态（当前任务） L2：长期摘要（历史压缩） L3：外部记忆（可检索）

真正进入模型 Prompt 的，永远只是其中一部分。

四、L0：即时上下文（Immediate Context）

这是最容易理解的一层：

当前用户输入
当前 Agent 输出草稿
当前必须参考的指令

特点：

生命周期极短
信息密度最高
必须完整保留

原则：

L0 不做摘要，不做缓存，只做最小化。

五、L1：短期状态缓存（Task-Level Cache）

L1 是很多系统做得最差的一层。

它通常包含：

当前任务目标
已完成的关键步骤
约束条件（不能做什么 / 必须做什么）

错误做法是：把整个对话历史当成“任务状态”。正确做法是：抽象出结构化任务状态，用 JSON / Schema 表达，而不是自然语言流水账

示例（简化）：

{ 
"goal": "生成周报", 
"completed_steps": ["数据汇总", "异常分析"], 
"pending_steps": ["结论总结"], 
"constraints": ["不暴露个人数据"] 
}

任务状态应该是“可读结构”，而不是“语言回放”。

六、L2：历史摘要层

这是 Context 扩容的核心杠杆。一个成熟的系统一定会回答这个问题：哪些历史信息“未来可能有用”，但不值得逐字保留？工程实践中，我通常采用 滚动摘要（Rolling Summary）：

以任务 / 会话为单位
每 N 轮生成一次摘要
摘要本身也有版本

关键不是“压缩文字”，而是：

提取决策依据
提取用户偏好变化
提取失败模式

坏的摘要是“发生了什么”；好的摘要是“为什么这么做”。

七、L3：外部可检索记忆

当信息满足以下条件时，不应该进入 Context：

不是每轮都用
体量大
结构稳定

比如：用户历史行为；企业知识库；长文档；工具使用手册。这些内容更适合放在：

向量数据库，结构化存储，Feature Store。通过 按需检索 注入，而不是常驻 Prompt。Context 是热内存，不是仓库。

八、摘要不是 NLP 问题，而是系统策略问题

很多团队失败在“摘要效果不好”，但根因往往不是模型能力，而是：不知道摘要“给谁看”，不知道摘要“为谁服务”。一个有效的摘要，必须明确：

使用对象：模型 / 人 / 下游 Agent
使用场景：规划 / 执行 / 回顾
生命周期：一次性 / 长期

建议实践：

不同层使用不同摘要模板
摘要本身可再摘要
摘要必须可被替换，而不是永久追加

九、我们如何做到“有效 Context ×5”

在一个真实生产 Agent 中，我们做过一次对比：

指标	优化前	优化后
平均 Prompt Token	18k	4.2k
成功率	基线	0.12
推理延迟	基线	-35%
成本	基线	-60%

关键不是模型升级，而是：

引入分层 Context
强制摘要
禁止无界历史拼接

模型“记得更少”，反而做得更好。

结语：Context 管理，是下一代 Agent 的基本功

未来 Agent 的竞争力，不在于：

谁的模型 Context 更长
谁能塞进更多历史

重点在于：

谁更清楚什么该被记住
谁敢主动遗忘
谁能用更少的上下文，完成更稳定的决策

Context 不是越多越好，而是越“对”越好。当你开始像管理缓存、内存、状态机一样管理 Context，你会发现：Agent 更稳定了，成本更可预测了，系统真正“工程化”了。