智能体的上下文管理：窗口限制与检索增强的博弈

智能体的上下文管理：窗口限制与检索增强的博弈

上下文窗口是智能体的工作台面，台面大小直接决定它一次能摊开多少材料。过去三年这个台面以惊人的速度扩张：GPT-3 时代还是 2K 到 4K token，GPT-4 初代 8K 与 32K，Claude 2 把百 K 变成标配，Gemini 1.5 Pro 捅到百万级，如今 200K 窗口在旗舰模型里已是常态，部分模型宣称支持 1M 甚至 2M。窗口变大引发了一个自然的疑问：既然能把整个代码库或一整本书塞进去，检索增强（RAG）是不是过时了？工程实践的答案恰恰相反——窗口越大，上下文管理反而越重要，"把什么都塞进去"是智能体工程里最昂贵的错误之一。

这篇文章观察这场窗口与检索之间的长期博弈：长窗口的真实能力边界、上下文腐烂现象、RAG 与长窗口各自的适用带，以及当前主流的上下文工程实践。

窗口军备竞赛及其物理边界

窗口扩张不是免费的。注意力机制的计算量随序列长度增长，百万级 token 的预填充即使有 FlashAttention 这类优化加持，一次调用也可能耗费数秒到数十秒，费用按 token 计价也线性水涨船高。更关键的问题是"标称容量"与"有效容量"的落差。2023 年斯坦福团队发表的 Lost in the Middle 研究揭示了长上下文的注意力分布问题：把关键信息放在上下文中段时，模型的召回率显著低于放在首尾——模型对开头和结尾敏感，中间的大段内容如同被雾遮住。此后 NVIDIA 的 RULER 基准进一步量化了这个落差：不少宣称支持 128K 的模型，在多针检索、聚合推理等复杂长文任务上的有效工作长度远低于标称值，性能随上下文增长的衰减曲线比厂商宣传陡峭得多。

工程上应当建立一个务实的认知：标称窗口是"能装下"的上限，有效窗口才是"能用好"的范围，两者之间通常隔着数倍的差距，且任务越复杂（从单针检索到跨段落聚合推理）差距越大。把关键约束放在 system prompt（开头）与最近几轮对话（结尾），把大块参考资料压在中间，是所有长上下文应用都该遵循的排布原则。

上下文腐烂：长窗口不等于长记忆

2025 年 Chroma 团队用"上下文腐烂"（Context Rot）概括了另一层现象：即使任务完全在窗口容量之内，随着输入 token 数量增加，模型在 seemingly 简单任务（如复述）上的表现也会系统性下滑，长窗口模型并不能免疫，只是衰减得更慢。这背后是注意力资源的稀释——上下文里堆的干扰信息越多，模型保持对关键信息聚焦的能力越差。

对智能体来说，腐烂的来源非常具体：工具返回的原始输出。一次网页抓取带回几万 token 的 HTML 噪声，一次 ls -R 返回几千行文件列表，它们进入上下文后就永远在那里，持续稀释后续每一轮的注意力。这解释了一个反直觉的工程经验：很多"模型变笨了"的案例，根因不是模型版本变化，而是上下文被工具结果塞爆。处置手段包括：工具输出在返回前于应用层做结构化过滤与摘要（抓取网页先提取正文与要点，原始 HTML 不进上下文）；大结果落盘为文件，只在上下文里留一个路径与摘要，模型需要时按行号区间再读；以及定期的上下文清扫，把陈旧工具结果替换为占位符。

flowchart TD
    Q["任务输入"] --> S{"上下文策略决策"}
    S -->|"小而确定"| F["直接全量放入<br/>约束放首尾"]
    S -->|"知识库大而静态"| RAG["RAG 检索<br/>粗召回 + 重排 + 精读"]
    S -->|"会话越滚越大"| CP["压缩 compaction<br/>摘要替换旧历史"]
    S -->|"子任务可拆分"| SUB["子智能体隔离<br/>只回传结论"]
    F & RAG & CP & SUB --> M["主上下文保持精瘦"]
    M --> MON["持续监控<br/>有效容量 / 干扰密度"]

RAG 与长窗口的博弈：互补而非替代

回到那个核心问题：长窗口杀死了 RAG 吗？没有，但改变了它的形态。算一笔账就清楚：面对一个 50 万 token 的知识库，全量塞入百万窗口的方案，单次调用成本是检索 1 万 token 方案的几十倍，首 token 延迟从几百毫秒劣化到数秒，而准确率反而可能更低——因为塞入的噪声会触发上下文腐烂。精准检索的 1 万 token 比全量的 100 万 token 信噪比高得多，"少而准"持续战胜"多而全"。

但长窗口确实重塑了 RAG 的设计参数。第一，chunk 可以切得更大：早期 256 到 512 token 的碎片化切片是为了迁就小窗口，如今粗粒度切块（2000 token 以上）保留更多语义完整性，配合窗口消化。第二，检索策略从"多路精挑"转向"粗召回加重排"：先用便宜的向量检索粗筛几十条，再用重排模型精排出三五条，最后大窗口把这几条连同足够多的周边上下文一起交给模型精读。第三，出现了"先检索定位、再全文精读"的混合模式——Claude Code 读代码就是典型：先语义搜索定位到相关文件，再完整读入整个文件而非片段，靠大窗口消化整读的成本。结论是长窗口与检索是分工而非替代：检索负责从海量知识里找位置，窗口负责在找到的位置附近深读。

上下文工程的三层实践

把主流实践收敛一下，可以归纳为三层。第一层是压缩：当上下文占用逼近有效容量的九成左右，把早期历史摘要化替换，Claude Code 的自动 compact、Anthropic 的上下文编辑能力都属于这一层，要点是保护关键约束不被摘要吞掉（约束清单单独维护、每轮重新注入）。第二层是隔离：把可拆分的子任务派发给子智能体，各自在独立的完整窗口里工作，只把结论（几百 token）回传主上下文——Claude Code 的 subagent 机制是范本，主 agent 只持有任务清单与各子任务的结论摘要，干净状态下可以连续工作数小时而不失焦。第三层是外置：把不需要常驻的知识放进文件系统或数据库这个"外存"，上下文里只保留索引，模型按需读取——这正是 Anthropic 把记忆工具设计成文件目录读写的原因，也是所有编码智能体共同的架构选择。

三层实践共同指向一个原则：上下文是稀缺资源，要像管理内存一样管理它——该压缩的压缩、该换页的换页、该隔离的隔离，而不是把它当作无限大的白板。2025 年以来"上下文工程"取代"提示词工程"成为行业热词，标志了这个认知的普及：上下文的质量决定智能体质量的上限，这个结论在可预见的未来不会因为窗口继续变大而失效。

上下文质量的度量：让管理变得可验证

上下文工程目前最大的短板是缺少度量：多数团队说不清自己的上下文利用状况，优化全凭直觉。可以落地的指标有三个。任务级 token 效率：完成任务消耗的总输入 token 与最终产出的比值，同类任务的横向对比立刻暴露哪些环节在浪费。干扰密度：抽样若干轮次，用评审模型标注"与当前决策无关的 token 占比"，高于四成就该做工具输出整形了。压缩损耗：对压缩功能做 A/B——压缩组与非压缩组的任务成功率差值就是压缩的真实代价，很多团队实测后发现压缩率超过一半时成功率明显下滑，于是把压缩阈值调得更保守。

工具输出整形应该写成团队规范强制执行，像代码规范一样。具体条款：抓取类工具返回前必须抽取正文，原始 HTML 不进上下文；长输出必须截断并附截断说明（"已显示前 200 行，共 3400 行，完整内容已存至文件"），给模型留继续读取的通道；结构化数据优先返回裁剪后的 JSON 字段而非原始文本；超过阈值的大结果落盘为文件，上下文里只留路径与摘要。这套规范的价值在于它把"上下文精瘦"从个人技艺变成团队基线——我们见过一个数据分析智能体在执行输出整形规范后，单任务输入消耗下降六成，任务成功率反而上升两个百分点，因为模型在干净的上下文里犯的注意力错误更少了。

压缩策略本身也有细节层次。滚动摘要是主流做法：保留最近若干轮的原文，更早的历史压成一段摘要，摘要随轮次滚动更新。它的问题在信息丢失不可控，改进方向是分层摘要——把旧摘要再压缩成更早期的极简版，形成"近期原文、中期摘要、远期梗概"的三层结构，越久远越浓缩，与人的记忆衰减曲线一致。无论哪种压缩，都必须配套关键信息保护清单：任务约束、用户明确偏好、已确认的关键决定这三类内容独立维护、永不参与压缩、每轮重新注入。压缩丢什么可以赌运气，丢掉约束条件一定是事故——这一条保护清单的成本不过几百 token，是上下文工程里回报率最高的保险。

还有两个正在变得重要的上下文议题。一是多模态上下文的成本：图片进入上下文的 token 代价不低，一张截图视分辨率折算约上千到两千 token，截图驱动的智能体（视觉定位、UI 自动化）一轮就能吃掉几千 token，音频转录同理。策略与文本一致：图片按需注入、降采样、能 OCR 提取文本就不保留原图，图像上下文同样需要"瘦身纪律"。二是上下文策略自身的变更治理：压缩阈值、工具输出整形规则、摘要模板的调整影响所有任务，属于高危变更，必须像改提示词一样过评测回归。更进一步，成熟的团队会把"上下文预算"写进任务规格——单任务的输入 token 上限、单轮工具输出的上限、压缩触发的阈值——预算超限触发审查而不是静默膨胀。上下文管理做到这一步，才真正从技艺变成了工程。

小结

窗口军备竞赛把智能体的台面从 4K 推到百万级 token，但 Lost in the Middle 与上下文腐烂研究共同揭示了标称容量与有效容量的巨大落差：塞得下不等于用得好，干扰密度才是真正的约束。因此长窗口没有杀死 RAG，反而重塑了它——粗粒度切片、粗召回加重排、检索定位后全文精读，"少而准"持续优于"多而全"。实践层面，压缩、隔离、外置三层上下文工程构成当前的主流范式，其精神内核与操作系统的内存管理如出一辙。窗口大小是模型的参数，上下文质量才是工程师的责任。