直觉上,百万 token 窗口已经足够大,但实际生产中,长链路智能体的上下文膨胀速度远超想象。典型场景:智能体调用 30+ 个外部 API,每个 API 返回 2-5 KB 数据;加上工具描述、系统提示词、历史对话、用户输入,上下文很容易突破 100K token。 更糟糕的是,上下文窗口大 ≠ 推理质量高。研究普遍表明,即便模型能"读"百万 token,实际"理解"和"引用"的有效范围仍是 50K-80K token 之内。超出这个范围,模型会出现"远期遗忘"——它"知道"前面有这段内容,但具体引用时常出错。 上下文膨胀的另一个隐性来源是"工具描述累积"。智能体每注册一个新工具,系统提示词里就要增加一段工具说明。当工具数量达到 50+ 时,工具描述本身就会占满 10K-30K token。这种"工具描述膨胀"在多智能体协作场景尤为严重。
二、滑动窗口:最基础也最简陋
滑动窗口是最朴素的压缩策略:保留最近 N 轮对话,丢弃更早的内容。优点是实现简单,工程开销低;缺点是"该丢的没丢、该留的没留"。
典型问题:某次关键的失败尝试发生在 50 轮前,被滑动窗口丢掉,后续推理重复犯同一个错误。或者,某次成功的决策依据(用户的特殊要求)在 80 轮前被丢弃,后续推理忘记这个要求。
生产环境的滑动窗口不是"机械按轮数",而是混合策略:对系统提示词和工具描述永远保留;对用户输入按时间窗口保留;对工具调用结果按重要性保留。这种混合策略能缓解"机械丢弃"的问题,但仍然治标不治本。
滑动窗口的另一个变体是"基于重要性的窗口":每次新内容进入上下文,模型评估其重要性,把重要性低的内容移出窗口。这种策略的效果比"机械按轮数"好,但代价是每次新内容都要做一次重要性评估,开销显著上升。
三、结构化摘要:从被动丢弃到主动提取
结构化摘要的核心思想是:不是"丢什么",而是"留下什么"。智能体在每个关键节点,主动把当前上下文压缩成结构化摘要——任务进度、已完成的子任务、关键决策、待解决问题——把摘要注入下一轮推理。
结构化摘要的关键设计:
第一,摘要要有固定 schema。任务进度用什么字段、关键决策用什么字段、待解决问题用什么字段,都要预先定义,而不是让模型自由发挥。固定 schema 让摘要可被后续代码消费,而不是"模型自言自语"。
第二,摘要要带版本号。每次压缩都生成新版本,旧版本也要保留。这看似浪费存储,但生产事故复盘时,"我之前的摘要是什么"至关重要——有时正是摘要失真导致决策偏移。
第三,摘要要可追溯。摘要是从原始内容压缩而来,必须能反查"这段摘要是从哪段原文压缩的"。常见做法是在摘要里嵌入原文的 ID 或 hash,便于"溯源回看"。摘要失真时,复盘工程师可以一键定位到原文段落,判断是哪一步压缩丢掉了关键信息。
第四,摘要要渐进式更新。不是每轮推理都重新压缩(成本高),而是"在关键节点压缩"。关键节点包括:完成一个子任务、遇到一次失败、做出一次重要决策、跨越某个时间阈值(例如每完成 10 轮推理或每消耗 20K token)。这种触发式压缩比定时压缩更经济,比实时压缩更可控。
结构化摘要与滑动窗口可以组合使用:滑动窗口保留最近若干轮的原文,更早的内容压缩成摘要;模型推理时,看到的是"原文 + 摘要"的混合上下文。这种组合既能保留近期细节,又能跨越长周期。在 LangChain 2026 年的报告里,这种组合被视为长链路 Agent 的事实标准——单独使用任何一种策略,要么丢细节,要么撑爆上下文。
四、长期记忆:外置存储 + 按需回灌
长期记忆是上下文管理的第二层。短期记忆(滑动窗口 + 结构化摘要)解决"当前任务内的上下文";长期记忆解决"跨任务的上下文"。
长期记忆的典型实现:智能体把关键信息写入外部存储(向量数据库、键值存储、文件),需要时按语义检索回灌。回灌策略可以是"每次都回灌全部",也可以是"按相关性回灌"。
长期记忆的几个工程要点:
1. 写入要经过校验。智能体不能"想写就写",必须经过规则校验或人工审批。否则 Agent 会把幻觉写进自己的记忆库,后续越用越偏。常见做法:写入前由规则引擎校验(检查字段类型、长度、敏感词),由人工抽检(每天抽样 10% 审核)。
2. 读取要做相关性过滤。不是把所有记忆都回灌,而是只回灌与当前任务相关的记忆。否则长期记忆会反过来"撑爆"短期上下文。常见做法:用向量检索 + 重排序,把记忆分成"必回灌"、"按需回灌"、"不回灌"三档。
3. 记忆要有生命周期。临时记忆(只在当前任务用)在任务结束时清理;短期记忆(跨会话用)按时间窗口保留(例如保留 7 天);长期记忆(永久用)经过人工审核后才归档。
4. 记忆的存储介质要选对。临时记忆用内存;短期记忆用 KV 存储(Redis);长期记忆用向量数据库(Weaviate、Qdrant)或文档数据库(MongoDB)。生产环境通常组合使用,而非单一介质承担全部职责。
5. 记忆分层之间的接口必须显式定义。短期记忆到长期记忆的归档接口、长期记忆到短期回灌的检索接口、临时记忆到短期记忆的同步接口——这些接口一旦模糊,就会出现"Agent 在不该记住的地方记住了,在该记住的地方忘记了"这类离奇故障。
五、压缩的副作用:信息丢失不可避免
任何压缩策略都会丢失信息。滑动窗口丢历史,结构化摘要丢细节,长期记忆过滤丢边缘信息。压缩的副作用是"看似没问题,实则关键信息缺失"。
缓解方法:压缩后做"回放校验"——把压缩后的上下文重新喂给模型,问"你记得 X 吗"。如果模型回答正确,说明压缩保留了关键信息;如果模型回答错误,说明压缩丢了关键内容,需要重新压缩或调整策略。
这种"回放校验"在生产环境通常是离线的(每天跑一次),而不是实时的(每轮都跑)。实时校验开销过大,离线校验足够发现大部分问题。
离线回放校验的另一个用途是 A/B 测试压缩策略:同一份原始上下文,用两种压缩策略处理,对比模型的回放准确率。准确率高的策略上线,准确率低的策略下线。这种数据驱动的策略选择,比经验判断更可靠。
值得注意的是,回放校验本身不能 100% 发现信息丢失——某些信息只有在特定任务语境下才会被引用,这类长尾信息在校验时可能"幸运地"没被问到,但在生产里却会被实际任务触发。因此,回放校验只能给出"下限保证",真正的安全网是当模型决策出现异常时,允许运维快速回退到更宽松的压缩策略,而不是继续在压缩后的上下文中推理。
六、与模型能力的协同
上下文压缩不是"独立工作",而是与模型能力协同。如果模型本身有较强的"理解-压缩"能力(Claude 4 / GPT-5 / Gemini 2 的高端版本),简单摘要就能保留大部分信息;如果模型能力较弱,需要更精细的压缩策略(分层压缩、按字段压缩、保留关键引用)。
另外,模型能力也会反过来影响压缩策略的选择:能力强的模型,可以承担更复杂的"主动决策"角色(决定什么该压缩、什么该保留);能力弱的模型,只能做"机械压缩"(按规则压缩)。
模型升级时,上下文压缩策略也需要重新评估。新模型可能用更少的 token 表达同样的信息,旧的压缩参数(摘要长度、滑动窗口大小)可能需要调整。这种调整通常通过"灰度对比"完成:新旧策略同时跑一周,对比回放准确率和推理延迟。
七、落地建议
对于正在做长链路智能体的团队,建议按以下顺序推进:
- 先把滑动窗口做好。明确"哪些永远保留"、"哪些按时间窗口保留"、"哪些按重要性保留"。这是基线,不要跳过。
- 引入结构化摘要。在关键节点(完成子任务、遇到失败、做出决策)自动生成结构化摘要。摘要有固定 schema,带版本号,可追溯。
- 接入长期记忆。短期记忆搞稳后再接长期记忆。长期记忆的写入必须有校验,读取必须做过滤,生命周期必须明确。
- 建立回放校验机制。每天离线跑一次"摘要回放",检验压缩质量。连续两周质量稳定后,可以延长校验周期到每周一次。
- 与模型升级协同。当模型升级时,重新评估压缩策略——新模型可能用更少的 token 表达同样的信息,旧的压缩参数可能需要调整。
- 数据驱动策略迭代。建立"压缩效果监控"看板:平均压缩率、回放准确率、长期记忆命中率。指标持续下降时,主动迭代策略。
结语
上下文压缩是长链路智能体的"看不见的基础设施"。看不见是因为它在底层默默工作;基础设施是因为它决定了智能体能否持续稳定运行。当滑动窗口、结构化摘要、长期记忆、回放校验协同起来,智能体才能从"短任务演示"走向"长链路生产"。
