两年前还要为「塞不塞得下」精打细算的上下文窗口，如今已经卷到百万 token。但一个反直觉的事实是：窗口越大，上下文工程越重要，而不是越省心。窗口变大解决的是「装得下」，解决不了「该不该装」。
之前写过上下文工程的基础篇，聊的是从写好提示词到管好整段输入的观念转变。这篇是进阶版：当智能体一跑几十轮、工具输出动辄几千行时，上下文该怎么设计。
一、长窗口的三张隐性账单
第一张账是注意力稀释。模型对超长输入的利用并不均匀：开头和结尾的内容被充分注意，中间的内容容易被忽略——所谓 lost in the middle 现象。把五十个文件全倒进窗口，模型未必比只给它五个相关文件时答得更好。上下文不是越全越好，而是越相关越好。
第二张账是真金白银。API 按 token 计费，多轮对话里每轮都重复计费整个历史；就算模型侧做了 KV Cache 优化，前缀复用也只对稳定不变的前缀生效——检索结果每轮都变、工具输出每轮都新，缓存帮不上忙。塞进窗口的每个 token 都在付钱，而且大头是重复付钱。
第三张账最隐蔽：错误放大。陈旧的工具输出、已被推翻的中间结论、早期轮次的过时计划，都会留在窗口里被模型继续当真。上下文里的垃圾不会自己降解，只会持续污染后续每一轮决策。
二、把上下文当缓存层级来设计
解决思路不新鲜，就是操作系统的老手艺：分层。内存不够用不是把磁盘全当内存使，而是设计好寄存器、内存、磁盘的层级和换入换出策略。上下文同理，业界实践大致收敛为四层：
- 工作层：当前任务必需的指令、工具定义、最近几轮对话——常驻窗口；
- 情景层：本次会话的历史事件——用摘要压缩后按需唤起；
- 语义层：跨会话的长期事实、用户偏好——检索注入，用完即走；
- 程序层：任务的操作规程（SOP）、工具使用范例——只在触发对应场景时放入。
这套思路的源头 MemGPT 后来演化成了 Letta，之前对比记忆层方案时聊过一嘴。分层的本质是：窗口是稀缺资源，其余层级是仓库；仓库里的东西只有在被需要的那一刻才配进入窗口。
三、工程落地：预算、压缩与结构化
分层是骨架，落地靠三件具体的活：
给每类内容定 token 预算。 比如：系统指令 2K、工具定义 3K、检索结果 4K、对话历史滚动保留 8K。预算的意义不是精确到 token，而是逼你在设计期就想清楚「什么最重要」——超预算时按层牺牲，而不是让新内容无差别挤掉旧内容。
压缩要做在写入前。 工具返回的原始 JSON 动辄几千 token，进窗口前先抽字段、截断、或者过一道小模型摘要；对话历史超过配额就滚动总结旧轮次。关键区别在于：有损压缩要发生在写入上下文之前，而不是让模型在满窗口里自己猜重点。
用结构对抗噪声。 检索到的文档别裸贴，先抽成「来源、要点、置信度」的固定格式；多轮规划用状态机式的短状态替代完整的思考过程复述。结构化信息占用的注意力更少，出错时也更容易定位是哪一层注入了坏数据。
小结
长窗口时代，上下文工程的核心从「怎么塞进去」变成了「怎么舍得扔掉」。会扔的智能体跑得久、花得少、错得少；舍不得扔的，窗口越大事故越壮观。分层设计、预算控制、写入前压缩——三件事都不性感，但它们决定了智能体在第 40 轮对话时还靠不靠谱。
说明：本文为公开资料的整理与评述，信息来源包括 MemGPT/Letta 的分层记忆论文与文档、主流智能体框架的上下文管理实践及公开工程博客，数据以各官方原文为准。本文由 AI 辅助整理，不构成技术选型或投资建议。
评论