news 2026/4/17 20:34:35

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

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
模型上下文是新型“稀缺资源”:我们如何设计分层缓存与摘要策略,将有效容量提升 5 倍

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

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

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

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

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

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

  1. 短期工作记忆Working Memory

  2. 任务状态载体(Task State)

  3. 隐式策略与历史约束

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

典型做法是:

  • 所有历史对话全部拼接

  • 所有工具调用原样回放

  • 所有中间思考、日志一起塞进 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 Token18k4.2k
成功率基线0.12
推理延迟基线-35%
成本基线-60%

关键不是模型升级,而是:

  • 引入分层 Context

  • 强制摘要

  • 禁止无界历史拼接

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

结语:Context 管理,是下一代 Agent 的基本功

未来 Agent 的竞争力,不在于:

  • 谁的模型 Context 更长

  • 谁能塞进更多历史

重点在于:

  • 谁更清楚什么该被记住

  • 谁敢主动遗忘

  • 谁能用更少的上下文,完成更稳定的决策

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

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/4/13 19:22:16

基于.Net 8创建 CAD勘测定界图(四)——填充及拉线标注

好的,之前的两篇文章大概介绍了一下关于做这个功能的背景和关于Aspose.CAD For .Net填充无效,转用ACadSharp创建红线、界址点符号、界址点标注以及边长标注的方法,具体看: 基于.Net 8创建 CAD勘测定界图(一&#xff09…

作者头像 李华
网站建设 2026/4/15 4:29:03

02. 缓存行

1.缓存行1.缓存行 CPU读取内存时, 并不是直接一个字节一个字节地读, 而是按照内存总线的位宽(比如64位, 即8字节)来传输数据; 但是CPU的缓存系统(Cache)在从内存中加载数据时, 是以缓存行(Cache Line)为单位的a.内存总线的传输单位: "每次内存读写操作通过总线传输的数据量…

作者头像 李华
网站建设 2026/4/16 13:50:37

32、深入探索vi编辑器:参数配置与命令缩写技巧

深入探索vi编辑器:参数配置与命令缩写技巧 在UNIX系统中,vi编辑器是一款功能强大且广泛使用的工具。它提供了丰富的配置选项和灵活的命令缩写功能,能够极大地提高编辑效率。本文将详细介绍vi编辑器的参数配置和命令缩写的相关知识和操作方法。 1. 配置vi参数 vi编辑器拥有…

作者头像 李华
网站建设 2026/4/15 15:07:06

46、UNIX相关知识与组织介绍

UNIX相关知识与组织介绍 1. 推荐组织 在UNIX相关领域,有许多专业组织发挥着重要作用,以下是一些推荐的组织: | 组织名称 | 简介 | 官网 | | ---- | ---- | ---- | | ACM | 世界上历史最悠久、规模最大的教育和科学计算协会。自1947年以来,ACM为信息、思想和发现的交流…

作者头像 李华