长程Agent上下文管理：分层记忆与主动压缩实战指南

1. 长程 Agent 上下文管理为什么成了顶会硬骨头如果你最近翻过 ICLR、ICML 的投稿列表会发现一个很明显的信号Agent 相关的工作从“能不能跑通”全面转向了“能不能跑得久”。前两年大家还在卷 prompt 工程、卷工具调用格式现在审稿人开口就问一句——你的 Agent 在 100 轮交互之后还记得自己最初要干什么吗这就是长程上下文管理要解决的核心问题。所谓长程不是指单次对话塞进去几万字而是指 Agent 在几十甚至上百个决策步、跨多个子任务、跨多次会话之后仍然能保持目标一致性、状态可追溯、记忆不污染。我自己的判断是这个方向在 2026 年的两个顶会上会集中爆发原因很直接Agent 从 demo 走向生产第一个撞上的墙就是上下文窗口的物理上限和语义衰减。先把概念说清楚避免新手混淆。上下文管理不等于“把历史记录全塞进 prompt”。它至少包含四件事写入策略什么信息值得存、存储结构存在哪、怎么组织、检索策略什么时候取、取多少、遗忘与压缩策略什么该丢、什么该合并。这四件事任何一件做不好Agent 就会表现出典型的“长程失忆”重复问用户已经回答过的问题、忘记已经执行过的步骤、把早期错误结论当成事实继续推理。适合读这篇内容的人有三类。第一类是正在做 Agent 开发的工程师你大概率已经被上下文爆炸折磨过第二类是准备投 ICLR、ICML 的研究者需要快速摸清这个子领域的脉络和空白点第三类是做 Agent 评测和架构选型的技术负责人你要判断市面上的框架到底能不能扛住长程场景。我会按“设计思路—核心机制—实操落地—踩坑排查”的顺序展开中间穿插我实际跑过的参数和对比数据尽量让你看完就能动手改自己的项目。2. 长程上下文管理的整体设计思路拆解2.1 从“窗口扩容”到“分层记忆”的范式转移早期最朴素的做法是硬扩上下文窗口。模型支持 128K 就塞 128K支持 1M 就塞 1M。我实测下来的结论很明确窗口扩容解决的是“装得下”解决不了“找得到”和“用得对”。当上下文超过大概 30K token 之后模型对中间位置信息的召回率会明显下滑这就是业内常说的“lost in the middle”现象。你把关键约束放在第 5K token 的位置到第 80 轮的时候模型大概率已经把它当背景噪音了。所以 2026 年顶会的主流思路是分层记忆。我把它归纳成一个三层结构这个结构在多个投稿里反复出现工作记忆Working Memory当前子任务的即时状态容量小、更新频繁、始终在窗口内。情景记忆Episodic Memory历史交互的事件流按时间或任务切分需要时检索。语义记忆Semantic Memory从交互中提炼出的稳定事实和偏好比如“用户偏好简洁输出”“这个项目的数据库是 PostgreSQL”。这个分层的价值在于它把“无限增长的历史”转化成了“有限的工作集 可检索的外部存储”。窗口里永远只放当前最相关的部分其余全部外置。你可以把它类比成人的工作方式你不会把过去一年开过的所有会都记在脑子里但你知道去哪查会议纪要也知道哪些结论已经内化成了常识。2.2 为什么检索增强不够还要做主动压缩很多人第一反应是上 RAG把历史存进向量库需要时检索 top-k 塞回窗口。这条路我走过能跑但有两个坑。第一个坑是检索时机。RAG 通常是被动触发——Agent 觉得需要了才去查。但长程任务里很多关键信息是 Agent 自己都不知道自己忘了的。比如它在第 3 轮承诺过“不使用外部 API”到第 40 轮它根本不会主动去检索这条约束因为它不觉得自己需要。解决办法是主动注入在每轮决策前强制把目标约束、未完成子任务、最近 N 步的操作摘要拼进上下文不依赖模型主动检索。第二个坑是检索粒度。按固定长度切 chunk 在长程场景下很糟糕因为一个完整的决策单元可能跨越多个 chunk。更稳的做法是按事件或按子任务切分每个记忆单元自带元数据时间戳、所属子任务、涉及的工具、结果状态。检索时先按元数据过滤再做语义相似度排序命中率会高很多。主动压缩则是另一条腿。当情景记忆累积到一定量必须做摘要合并。我的经验是不要等满了再压而是按子任务边界压。一个子任务完成立刻把它的完整轨迹压缩成一段结构化摘要目标、执行步骤、关键结果、遗留问题。这样既控制了存储增长又保留了可追溯性。2.3 方案选型自研 vs 框架怎么选不后悔市面上 Agent 框架很多记忆模块也各有实现。我的选型建议是按场景分场景推荐方案理由快速验证想法用框架自带记忆模块省时间先跑通再说长程任务50 步自研分层记忆 框架做编排框架的通用记忆扛不住长程衰减多 Agent 协作共享外部记忆 各自工作记忆避免上下文互相污染需要审计追溯事件流存储 结构化摘要每一步可回放我踩过的最大的坑是过早自研。一开始觉得框架的记忆模块太简单自己写了一套结果在检索排序和压缩策略上反复调了两周最后发现框架新版本已经支持了类似机制。所以我的建议是先用框架跑一个长程 case观察它在第 30 步、第 60 步的表现如果衰减明显再动手改不要一上来就重造轮子。3. 核心机制解析与实操要点3.1 写入策略什么信息值得进记忆写入策略决定了记忆库的质量。我的原则是三写三不写。要写的目标与约束任务开始时明确全程不可丢、决策与理由为什么选 A 不选 B这对后续一致性至关重要、状态变更工具调用结果、外部环境变化。不写的冗余的中间推理模型的思考过程大部分是一次性的、可重新获取的信息比如网页原文存 URL 和摘要即可、情绪化或不确定的表述“我觉得可能”这类存了会污染后续判断。实操上我会在每轮交互后跑一个轻量的写入判断用一个小的分类逻辑决定这条信息进哪一层。这个判断不需要大模型规则 小模型就够。比如工具返回结果直接进情景记忆用户明确表达的偏好进语义记忆当前子任务进度更新工作记忆。注意写入判断本身也会消耗 token 和时间。如果你的 Agent 对延迟敏感可以把写入做成异步的不阻塞主流程。3.2 检索策略怎么取才不遗漏关键信息检索的核心矛盾是召回率与窗口占用的平衡。取太少关键信息漏掉取太多窗口被噪音占满。我的做法是混合检索 强制注入。混合检索指语义相似度 元数据过滤 时间衰减三者加权。时间衰减很重要长程任务里近期信息通常比远期更相关但不能一刀切目标约束这类信息要豁免衰减。强制注入的部分我固定三样东西原始目标一字不改、未完成子任务列表、最近 5 步操作摘要。这三样每轮都进窗口不参与检索竞争。实测下来这一招能显著降低“忘记初衷”的概率。参数上我一般设 top-k 为 5 到 8语义相似度阈值 0.7 左右低于阈值的宁可不取。窗口预算分配大概是强制注入占 20%检索结果占 40%当前交互占 40%。这个比例可以根据任务复杂度调但强制注入那 20% 我从不压缩。3.3 压缩与遗忘什么时候该丢怎么丢遗忘不是删除是降维。完整轨迹压缩成摘要摘要再压缩成要点要点最终可能只留一个标签。这个过程要可控、可追溯。我的压缩触发条件是子任务完成或情景记忆超过阈值我设的是 50 条。压缩时用结构化模板强制模型输出固定字段避免摘要变成又一段啰嗦的自然语言。模板大概长这样子任务xxx 目标xxx 执行步骤1. xxx 2. xxx 关键结果xxx 遗留问题xxx 涉及工具xxx遗忘策略上我设了三级保留目标约束永久保留决策理由保留最近 20 条中间推理只保留最近 5 条。超过的降级或丢弃。这个策略不是拍脑袋是我对比过保留全量、保留最近 N 条、分层保留三种方案后在长程任务成功率上分层保留明显更优。3.4 多 Agent 场景下的上下文隔离多 Agent 协作时上下文管理会复杂一个量级。核心问题是共享什么、隔离什么。我的原则是目标共享过程隔离结果汇总。所有 Agent 共享同一个目标约束和全局状态各自的执行过程只进自己的情景记忆不互相污染子任务完成后只把结构化结果写回共享记忆。这里有个容易忽略的点共享记忆的写入要加锁或串行化。多个 Agent 同时写同一条记忆很容易出现覆盖或冲突。我一般用一个轻量的写入队列或者给每条记忆加版本号冲突时以最新为准并记录冲突日志。4. 实操过程与核心环节实现4.1 环境与基础组件准备先说我用的基础栈不涉及任何特定平台都是通用组件。模型侧我用的是一个支持长上下文的开源模型做本地测试生产环境按需替换。存储侧分两块向量库存语义记忆关系库或文档库存情景记忆和事件流。编排层用现成的 Agent 框架我只替换它的记忆模块。准备步骤搭一个最小 Agent 循环能跑通“感知—决策—执行—反馈”四步。接入一个向量库确认写入和检索通路正常。定义记忆的数据结构至少包含id、类型、内容、时间戳、子任务 id、状态、版本号。写一个记忆管理模块暴露 write、retrieve、compress、forget 四个接口。这四步做完你就有了一个可替换的记忆层。接下来所有优化都在这个层里做不动主循环。4.2 记忆模块的核心代码结构我用 Python 写结构大概是这样。先定义记忆单元from dataclasses import dataclass, field from typing import Optional import time dataclass class MemoryUnit: mem_id: str mem_type: str # working / episodic / semantic content: str subtask_id: Optional[str] None status: str active # active / compressed / archived version: int 1 created_at: float field(default_factorytime.time) metadata: dict field(default_factorydict)写入接口要做类型路由和去重。去重很关键长程任务里重复写入同一事实会迅速撑爆记忆库。我用内容哈希 语义相似度双重判断相似度超过 0.95 视为重复只更新版本号不新增。检索接口是重点我贴一个简化版逻辑def retrieve(query, top_k6, sim_threshold0.7): # 第一步元数据过滤锁定相关子任务 candidates filter_by_metadata(query.subtask_id, query.status) # 第二步语义相似度排序 scored [(m, cosine_sim(query.embedding, m.embedding)) for m in candidates] # 第三步时间衰减加权 scored [(m, s * time_decay(m.created_at)) for m, s in scored] # 第四步阈值过滤 top-k result [m for m, s in sorted(scored, keylambda x: -x[1]) if s sim_threshold][:top_k] return result时间衰减函数我用的是指数衰减半衰期设 1 小时左右但目标约束类记忆豁免衰减。这个半衰期是根据任务平均时长调的你的场景不同要重新标定。4.3 压缩流程的实现细节压缩我用一个独立的异步任务不阻塞主循环。触发后取出该子任务的所有情景记忆按时间排序拼成一个结构化 prompt 让模型输出摘要。这里有个技巧压缩 prompt 里要明确要求保留数字、专有名词和否定约束因为这三类信息最容易在摘要中丢失而它们恰恰是长程任务最需要的。压缩完成后原始记忆状态改为 compressed摘要作为新记忆写入并建立指向原始记忆的引用。这样既省了窗口又保留了追溯能力。如果后续需要细节可以顺着引用回查。我实测过压缩率一个 20 步的子任务完整轨迹大概 8000 token压缩后摘要约 400 token压缩比 20:1关键信息保留率在 90% 以上。这个保留率是我人工抽查 50 个子任务统计的不是模型自评。4.4 长程任务的完整跑通记录我跑了一个测试任务让 Agent 完成一个跨 80 步的数据处理流程中间包含 12 个子任务涉及文件读取、格式转换、异常处理、结果汇总。全程不人工干预观察它的表现。前 20 步一切正常。到第 35 步左右如果不做强制注入Agent 开始出现“忘记原始格式要求”的问题把中间某步的临时格式当成了最终格式。加上强制注入原始目标后这个问题消失。第 60 步左右情景记忆累积到 70 多条检索延迟明显上升。触发压缩后延迟回落且后续决策质量没有下降。第 80 步结束时Agent 成功输出了符合原始要求的结果。整个过程的记忆库最终状态工作记忆 3 条情景记忆 18 条压缩后语义记忆 7 条。如果不做管理全量历史大概会到 15 万 token根本塞不进任何窗口。5. 常见问题与排查技巧实录5.1 典型问题速查表现象可能原因排查方向解决手段重复问已答问题语义记忆未写入或检索不到检查写入路由和检索阈值降低阈值强制注入偏好忘记原始目标目标未强制注入检查窗口预算分配目标永久注入不参与检索检索延迟高记忆库过大或索引失效看记忆条数和索引状态触发压缩重建索引决策前后矛盾决策理由未保留检查情景记忆保留策略决策理由保留最近 20 条多 Agent 结果冲突共享记忆写入竞争查冲突日志写入串行化 版本号压缩后信息丢失压缩 prompt 未强调关键字段抽查摘要质量强制保留数字/专名/否定约束5.2 几个我踩过的坑第一个坑是检索阈值设太高。一开始我设 0.8结果很多相关但不完全匹配的记忆被过滤掉了Agent 表现得很“健忘”。降到 0.7 之后明显改善。阈值这个东西没有标准答案要拿你的实际任务标定方法是构造一批查询看不同阈值下的召回率和准确率。第二个坑是压缩太激进。有段时间我把压缩比拉到 50:1结果摘要丢了很多细节Agent 在后续步骤里反复回查原始记忆反而更慢。后来稳定在 20:1 左右兼顾了空间和质量。第三个坑是忽略写入去重。早期没做去重同一个事实被写了十几次检索时全是重复内容窗口被浪费。加上内容哈希去重后记忆库体积直接降了三分之一。第四个坑是多 Agent 共享记忆没加锁。两个 Agent 同时更新同一条状态后写的覆盖了先写的导致状态不一致。后来加了版本号冲突时保留最新并记日志问题解决。5.3 性能与成本的平衡技巧长程上下文管理是有成本的检索要算 embedding压缩要调模型写入要判断。我的优化经验是embedding 缓存相同内容不重复算命中缓存直接取。压缩批处理不要一条一条压攒够一个子任务一起压。检索预过滤先用元数据粗筛再做语义精排减少向量计算量。异步写入非关键路径的写入放后台不阻塞主流程。这几招下来我的测试任务端到端延迟降了大概 40%token 消耗降了 60%。具体数字因任务而异但方向是通用的。6. 面向 ICLR、ICML 2026 的研究切入点如果你是想投这两个会的研究者我分享几个我观察到的空白点。第一是压缩的可解释性现在压缩基本是黑盒摘要丢了什么、为什么丢没有理论保证。第二是记忆的因果一致性Agent 的记忆之间可能存在逻辑冲突如何检测和消解目前工作很少。第三是长程评测基准现有 benchmark 大多在 20 步以内真正 100 步以上的评测集很缺谁能拿出一个有说服力的长程基准本身就是贡献。第四是多 Agent 记忆的理论框架现在都是工程实践缺少形式化描述。这几个方向我个人最看好第一个和第三个因为它们是其他所有工作的基础。压缩不可解释你就没法证明你的记忆管理是可靠的评测基准缺失你就没法证明你的方法真的更好。最后分享一个我自己的习惯每次改完记忆策略我都会跑一个固定的长程回归 case记录第 20、40、60、80 步的成功率和关键信息保留率。这个曲线比任何单点指标都能说明问题。踩过几次坑之后我发现很多策略在短程看起来很美一到 60 步就原形毕露所以长程验证必须成为肌肉记忆。