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

1. 长程 Agent 上下文管理为什么成了顶会硬骨头

如果你最近在跟 Agent 相关的项目，大概率会有一种感觉：模型能力本身已经不是最卡脖子的环节了，真正让人头疼的是长程任务里上下文怎么管。一个 Agent 跑三步五步没问题，一旦任务链条拉到几十步甚至上百步，上下文窗口就开始爆炸——要么塞不下，要么塞下了模型也抓不住重点，要么成本高到离谱。ICLR、ICML 这类顶会近两年关于 Agent 的投稿里，上下文管理几乎是绕不开的核心议题，2026 这一届更是集中爆发了一批系统性工作。

先把概念说清楚。所谓长程 Agent 上下文管理，指的是 Agent 在执行一个跨越很多步骤、涉及很多工具调用和中间状态的任务时，如何组织、压缩、检索、丢弃和复用上下文信息的一整套机制。它跟单纯的“长上下文模型”不是一回事。长上下文模型解决的是“窗口能装多少 token”，而上下文管理解决的是“装什么、怎么装、什么时候换掉”。你可以把它类比成一个人的工作台：桌面再大，如果不会整理，照样找不到东西；桌面小一点但收纳有序，反而效率更高。

这套东西为什么重要？因为 Agent 的本质是在循环中做决策。每一步它都要读历史、看当前状态、决定下一步动作。历史越长，决策的信噪比就越低。我见过太多项目，模型换了一版又一版，效果提升却卡在某个瓶颈上，最后发现问题根本不在模型，而在上下文里塞了一堆无关的中间结果，把关键信号淹没了。ICLR、ICML 2026 上那些被反复讨论的工作，本质上都在回答同一个问题：如何让 Agent 在长程任务中保持“记得住关键、忘得掉噪音”。

这篇文章我打算把这条线捋清楚。从整体设计思路，到核心机制拆解，再到可落地的实操方案和踩坑记录，尽量讲透。适合正在做 Agent 开发、被上下文问题折磨过的同学，也适合想系统了解这个方向研究脉络的人。不管你是刚入门还是在调优阶段，应该都能拿到能直接用的东西。

2. 长程上下文管理的整体设计思路拆解

2.1 从“塞满窗口”到“分层记忆”的范式转变

早期做 Agent 的人有个朴素想法：既然模型上下文窗口越来越大，那就把所有历史都塞进去不就行了。这个思路在短任务里能跑通，但长程任务里很快撞墙。原因有三层。第一层是成本，token 是要花钱的，每一步都把全部历史重新喂一遍，成本随步数线性甚至超线性增长。第二层是注意力稀释，就算窗口装得下，模型对长上下文的注意力分布是不均匀的，中间部分容易被忽略，这就是常说的“lost in the middle”。第三层是状态污染，历史里包含大量已经过时、已被推翻的中间结论，模型分不清哪些还有效，容易基于旧信息做错误决策。

所以顶会里主流的设计思路，已经从“塞满窗口”转向分层记忆架构。典型做法是把上下文拆成几个层次：工作记忆（当前步骤直接相关的少量信息）、短期记忆（最近若干步的摘要）、长期记忆（跨任务沉淀的知识或事实）、以及外部检索层（按需拉取的相关片段）。这个分层不是拍脑袋来的，它对应的是人类处理长任务的认知模式——你不会记住每一步的所有细节，但你会记住结论、记住关键约束、记住还没解决的问题。

分层带来的直接好处是每一层可以用不同的策略管理。工作记忆要求高保真、低延迟，那就原样保留；短期记忆可以压缩成摘要；长期记忆可以向量化存起来按需检索。这种“分而治之”的思路，是 ICLR、ICML 2026 上很多工作的共同底色。你在设计自己的 Agent 时，第一步就该问自己：我的上下文里，哪些是必须逐字保留的，哪些是可以摘要的，哪些是可以丢到外部存储按需取的。把这个问题想清楚，架构就成型了一半。

2.2 压缩、检索、遗忘三条技术路线的取舍

具体到实现层面，长程上下文管理基本围绕三条技术路线展开：压缩、检索、遗忘。这三条路线不是互斥的，实际系统里往往是组合使用，但每条路线的侧重点和适用场景不同，选型时要想清楚。

压缩的核心是把冗长的历史信息浓缩成更短的表示。常见手段包括摘要生成、关键信息抽取、状态向量化等。压缩的优点是直接降低 token 占用，缺点是会丢信息，而且摘要本身可能引入偏差。我个人的经验是，压缩适合用在“过程性信息”上——比如工具调用的原始返回，你不需要记住返回的每一个字符，只需要记住“调用成功了、拿到了什么关键字段”。但涉及精确数值、ID、约束条件这类信息，压缩要非常小心，最好原样保留。

检索的核心是不把所有信息都放在上下文里，而是存到外部，需要时再拉回来。向量数据库、关键词索引、图结构检索都是常见方案。检索的优点是理论上可以管理无限长的历史，缺点是检索质量直接决定效果，检索错了比不检索还糟。检索适合用在“事实性、知识性”信息上，比如用户之前提过的偏好、项目里定义过的术语。这里有个坑：检索的粒度很关键，切得太碎会丢上下文，切得太粗会引入噪音，需要根据任务特点调。

遗忘是最容易被忽视但可能最重要的一条路线。主动遗忘不是bug，是feature。一个 Agent 如果什么都不忘，历史会越来越脏。遗忘策略包括基于时间的衰减、基于相关性的淘汰、基于任务阶段的清理等。比如一个任务阶段结束后，这个阶段的中间过程就可以整体丢弃，只保留结论。遗忘做得好，能让上下文始终保持“干净”，这对长程任务的稳定性影响巨大。

2.3 为什么顶会工作都在强调“主动管理”而非“被动承载”

把上面这些串起来，你会发现一个共同点：顶会里被认可的工作，几乎都在强调主动管理。什么叫主动？就是系统要有一套明确的策略，决定每一步该保留什么、压缩什么、丢弃什么、检索什么，而不是被动地让上下文自然堆积。被动承载的思路是“模型自己会处理”，主动管理的思路是“我来帮模型减负”。

这个转变背后有个很实际的考量：Agent 的可靠性。被动承载的系统，行为随任务长度增加而快速退化，你很难预测它在第50步会出什么幺蛾子。主动管理的系统，因为每一步的上下文都是被策略筛选过的，行为更可控，出了问题也更容易定位——你可以检查是压缩策略错了，还是检索没召回，还是遗忘误删了。这种可调试性，在工程上价值极高。

我在实际项目里的体会是，主动管理带来的最大收益不是效果上限的提升，而是下限的抬升。它让 Agent 在长任务里不至于崩得太难看。ICLR、ICML 2026 上那些关于鲁棒性、一致性的讨论，很多都指向这一点。所以如果你现在正在设计 Agent 的上下文模块，别想着“先跑起来再说”，一开始就把主动管理的框架搭好，后面会省很多事。

3. 核心机制解析与实操要点

3.1 工作记忆的保真策略与边界划定

工作记忆是整个上下文管理里最不能省的一层，因为它直接支撑当前决策。我的做法是给工作记忆划一条硬边界：只放当前步骤和最近一到两步直接相关的信息。具体包括当前任务目标、当前步骤的输入、上一步的输出、以及还没解决的约束。超出这个范围的，一律不进工作记忆。

为什么边界要划这么死？因为工作记忆的保真度要求最高，它基本是原样保留的，token 成本最贵。如果边界模糊，工作记忆会迅速膨胀，把短期记忆和长期记忆的空间挤掉。我见过一个项目，工作记忆里塞了最近十步的完整历史，结果每步的 token 消耗是设计值的五倍，成本直接失控。

实操上，工作记忆的维护可以用一个简单的滑动窗口加显式状态对象。滑动窗口保留最近N步的原始记录，N一般取2到3；显式状态对象则记录那些必须跨步骤保持的信息，比如任务目标、已确认的事实、待办事项。状态对象要定期和滑动窗口做同步，确保两者不冲突。这里有个细节：状态对象的更新要有明确的触发条件，不能每步都改，否则会引入抖动。我通常设定为“当且仅当出现新的确认事实或任务目标变更时”才更新。

注意：工作记忆里绝对不要放未经确认的中间推测。推测性内容一旦进入工作记忆，很容易被后续步骤当成事实使用，这是长程任务里非常隐蔽的错误来源。

3.2 短期记忆的摘要生成与信息密度控制

短期记忆承接的是“最近一段时间发生了什么”，它的核心任务是在保留关键信息的前提下压缩体积。摘要生成是主流手段，但摘要怎么做很有讲究。直接让模型“总结一下”往往效果一般，因为模型不知道你后面要用什么信息，容易总结得过于笼统。

我的做法是面向用途的摘要。在生成摘要时，明确告诉模型这个摘要将被用于什么场景，需要保留哪几类信息。比如“请总结最近五步的操作，重点保留：调用了哪些工具、每个工具的关键返回字段、是否出现错误、当前进度”。这样生成的摘要信息密度高得多，后续步骤用起来也更顺手。

摘要的更新频率也需要控制。每步都重新生成摘要，成本高且容易累积偏差；间隔太长，摘要又会过时。我一般设定为每3到5步更新一次，或者当累积的原始记录超过某个 token 阈值时触发更新。更新时采用“增量摘要”而非“全量重写”，即把新内容合并进旧摘要，而不是从头总结所有历史。增量摘要的好处是保留了历史摘要的稳定性，避免每次重写带来的信息漂移。

信息密度控制还有个技巧：用结构化格式代替自然语言。比如把摘要写成“工具：X，结果：成功，关键字段：Y=Z”这样的键值对，比一段散文式的描述更省 token，也更容易被模型准确解析。这个技巧在工具调用密集的 Agent 里效果特别明显。

3.3 长期记忆的存储结构与检索触发条件

长期记忆解决的是“跨任务、跨会话的知识沉淀”。它的存储结构直接决定了检索质量。常见的方案是向量数据库，但纯向量检索有个问题：它擅长语义相似，不擅长精确匹配。而 Agent 的长期记忆里，往往既有需要语义检索的（比如“用户之前表达过的偏好”），也有需要精确匹配的（比如“项目里定义的某个ID”）。

所以我的建议是混合存储：向量索引加结构化字段。每条记忆同时存一份向量表示和一份结构化元数据（时间、类型、来源、关联任务等）。检索时先用结构化字段做过滤，再用向量做排序。这样既能保证精确性，又能利用语义相似度。ICLR、ICML 2026 上有工作专门讨论这种混合检索在 Agent 记忆里的应用，思路基本一致。

检索的触发条件同样关键。不能每步都检索，那样成本高且容易引入噪音；也不能只在开头检索一次，那样后续步骤拿不到新信息。我的做法是事件驱动检索：当出现特定事件时才触发，比如任务进入新阶段、遇到未见过的问题、需要引用历史信息时。触发条件要写得具体，比如“当当前步骤涉及用户偏好判断时，检索长期记忆中的偏好类条目”。这种精确触发比无差别检索有效得多。

3.4 上下文预算分配与动态调整机制

前面讲的都是“怎么管”，但还有一个绕不开的问题：预算怎么分。上下文窗口是有限的，工作记忆、短期记忆、长期记忆检索结果、当前输入，这几块都要占地方。如果平均分配，往往每块都不够用；如果全给一块，其他块就废了。

我的经验是动态预算。给每一层设一个基准配额，然后根据任务阶段动态调整。任务初期，工作记忆和当前输入占大头，因为要理解任务；任务中期，短期记忆占比上升，因为要维持连贯性；任务后期，长期记忆检索占比上升，因为要复用历史结论。这个调整可以基于简单的规则，也可以用一个小模型来预测，看你的工程复杂度承受能力。

动态调整的触发点可以绑定到任务阶段识别上。比如当 Agent 完成一个子目标时，就是一个调整信号。这里要注意，预算调整不要太频繁，否则上下文结构频繁变化，模型反而难以适应。我一般设定为每个子目标完成后调整一次，粒度适中。

提示：预算分配一定要留出余量。我通常预留总窗口的15%到20%作为缓冲，用于应对突发的长输入或检索结果过多的情况。没有缓冲的预算分配，在长程任务里几乎必然会在某个点崩掉。

4. 实操过程与核心环节实现

4.1 从零搭建一个分层上下文管理模块

光讲原理不够，我把一个可落地的分层上下文管理模块的搭建过程拆开讲。假设你用的是主流的 Agent 框架，语言是 Python，整体结构分四个组件：工作记忆管理器、短期记忆管理器、长期记忆管理器、预算调度器。

先定义数据结构。工作记忆用一个字典加一个双端队列，字典存显式状态，队列存最近N步原始记录。短期记忆用一个字符串加一个计数器，字符串是当前摘要，计数器记录自上次更新以来的步数。长期记忆用向量库加一个元数据表。预算调度器维护各层的当前配额和总缓冲。

class WorkingMemory: def __init__(self, window_size=3): self.state = {} # 显式状态：目标、约束、确认事实 self.recent = deque(maxlen=window_size) # 最近N步原始记录 def update_state(self, key, value, confirmed=False): if confirmed: self.state[key] = value def add_step(self, step_record): self.recent.append(step_record)

工作记忆的关键在于confirmed参数。只有确认过的信息才进状态字典，推测性的只进队列，队列满了自动淘汰。这个设计能有效防止推测污染。

短期记忆管理器的核心是增量摘要。每次触发更新时，把队列里新增的记录和旧摘要一起喂给模型，生成新摘要。

class ShortTermMemory: def __init__(self, update_interval=4): self.summary = "" self.steps_since_update = 0 self.update_interval = update_interval def maybe_update(self, new_records, llm): self.steps_since_update += len(new_records) if self.steps_since_update >= self.update_interval: prompt = f"旧摘要：{self.summary}\n新增记录：{new_records}\n请生成更新后的摘要，保留工具调用、关键字段、错误和进度。" self.summary = llm.generate(prompt) self.steps_since_update = 0

长期记忆管理器负责存取。写入时同时存向量和元数据，读取时先过滤再排序。

class LongTermMemory: def __init__(self, vector_store, metadata_store): self.vector_store = vector_store self.metadata_store = metadata_store def write(self, content, meta): vec = embed(content) self.vector_store.add(vec, content) self.metadata_store.add(meta) def retrieve(self, query, filters=None, top_k=3): vec = embed(query) candidates = self.vector_store.search(vec, top_k * 3) if filters: candidates = [c for c in candidates if match(c.meta, filters)] return candidates[:top_k]

预算调度器最简单也最容易被忽视。它维护一个配额表，根据任务阶段调整。

class BudgetScheduler: def __init__(self, total_budget): self.total = total_budget self.buffer = int(total_budget * 0.18) self.allocations = { "working": 0.35, "short": 0.25, "long": 0.22, } def get_budget(self, layer): return int((self.total - self.buffer) * self.allocations[layer]) def adjust(self, phase): if phase == "early": self.allocations = {"working": 0.45, "short": 0.20, "long": 0.17} elif phase == "late": self.allocations = {"working": 0.25, "short": 0.25, "long": 0.32}

这套结构搭起来大概两三百行代码，但覆盖了长程上下文管理的核心环节。你可以根据自己项目的复杂度增减，但四个组件的职责划分建议保留。

4.2 关键参数的计算与调优过程

参数调优是实操里最花时间的部分。我拿几个关键参数讲讲怎么算、怎么调。

工作记忆窗口大小N。这个参数取决于任务的“决策依赖跨度”，也就是当前决策最多需要回溯多少步。你可以做个简单实验：在验证集上，把N从1调到10，看任务成功率的变化。通常N在2到4之间会有一个明显的收益拐点，超过之后收益递减甚至为负（因为引入了过时信息）。我一般从3开始，根据拐点微调。

短期记忆更新间隔。这个和任务的“信息产生速率”有关。如果每步产生的信息量大致相当，间隔可以设为固定值，比如4步。如果信息产生不均匀，比如某些步骤产生大量工具返回，那就改成基于 token 累积量触发。计算方法是：设单步平均 token 为T，短期记忆的目标容量为C，则间隔约为 C/T。C 一般取总预算的25%左右。

长期记忆检索的 top_k。这个参数直接影响引入的噪音量。top_k 太大，噪音多；太小，可能漏掉关键信息。我的调法是：在验证集上，固定其他参数，把 top_k 从1调到8，观察“检索命中率”和“任务成功率”两条曲线。命中率随 top_k 单调上升，但成功率往往在某个点后下降，那个下降点就是最优 top_k。经验值通常在2到4之间。

缓冲比例。前面提到预留15%到20%，这个数字不是随便定的。它应该覆盖“最坏情况下的单步额外开销”。你可以统计验证集里单步 token 消耗的分布，取95分位数减去中位数，再除以总预算，就是缓冲比例的参考值。我实测下来，18%左右能覆盖绝大多数情况。

调参的顺序建议是：先定窗口大小，再定更新间隔，再定 top_k，最后定缓冲。因为前面的参数会影响后面的最优值，顺序反了会反复返工。

4.3 一次完整长程任务的上下文流转实录

我拿一个实际跑过的任务来演示上下文怎么流转。任务是一个多步骤的信息整理任务：从若干来源收集信息，交叉验证，最后生成一份结构化报告。整个任务跑了大概40步。

第1到5步（任务初期）。工作记忆占主导，配额45%。这几步主要是理解任务、拆解子目标。工作记忆里存了任务目标、拆解出的子目标列表、以及每个子目标的验收标准。短期记忆还没触发更新，长期记忆只在第1步检索了一次，拉取相关的历史任务模板。这几步的 token 消耗很低，因为输入本身不长。

第6到20步（任务中期）。开始大量调用工具收集信息。工作记忆窗口保持3步，状态字典里累积了已确认的事实。短期记忆每4步更新一次，摘要里记录了“已从哪些来源收集了哪些字段、哪些字段还缺、哪些来源出现了冲突”。长期记忆在这个阶段被触发了两次：一次是遇到一个之前处理过的数据格式，检索了历史解析方案；一次是发现一个来源的可信度存疑，检索了历史可信度评估记录。

第21到35步（任务后期）。进入交叉验证和报告生成阶段。预算调度器把长期记忆配额提到32%，因为需要大量复用历史结论。工作记忆配额降到25%，因为当前决策更多依赖已沉淀的结论而非原始记录。短期记忆的摘要在这个阶段被反复引用，成为报告生成的主要素材。这里有个细节：报告生成时，我没有让模型直接读所有原始记录，而是让它读短期记忆摘要加长期记忆检索结果，token 消耗降低了约60%，效果反而更好，因为摘要已经过滤掉了噪音。

第36到40步（收尾）。清理阶段。工作记忆的状态字典里只保留最终结论，队列清空。短期记忆生成最终摘要，写入长期记忆作为本次任务的沉淀。整个任务的峰值 token 消耗出现在第20步左右，约为总预算的82%，没有触及缓冲上限，说明预算分配是合理的。

这次实录里最关键的一点是：上下文流转是有节奏的，不是均匀的。初期重理解，中期重收集，后期重复用，收尾重沉淀。你的管理策略要跟着这个节奏走，而不是一套参数用到底。

5. 常见问题与排查技巧实录

5.1 上下文管理高频问题速查表

长程 Agent 的上下文问题，症状往往很隐蔽，排查起来要有章法。我把踩过的坑整理成一张速查表，按症状、可能原因、排查方法、解决方向四个维度列出来。

这张表基本覆盖了我遇到过的八成问题。用的时候先对症状，再看排查方法，最后按解决方向试。大部分问题不需要改架构，调参数就能解决。

5.2 三个最容易被忽视的隐蔽陷阱

除了上面这些显性问题，还有几个隐蔽陷阱，不踩一次很难意识到。

第一个陷阱是“摘要的自我强化”。增量摘要如果一直基于旧摘要生成，偏差会累积。比如第一次摘要漏了一个细节，后面每次都在漏的基础上更新，这个细节就永远丢了。更糟的是，模型可能会在摘要里“脑补”出一些原始记录里没有的内容，然后后续步骤把它当真。我的应对方法是定期全量重写：每更新5到6次增量摘要后，强制从原始记录重新生成一次全量摘要，把累积偏差清零。这个操作成本略高，但值得。

第二个陷阱是“检索的时间盲区”。向量检索擅长语义相似，但对时间不敏感。如果长期记忆里有一条很旧的信息和一条很新的信息语义相似，检索可能把旧的排在前面。而 Agent 任务里，新信息往往比旧信息更相关。解决办法是在检索排序里加入时间衰减因子，让新信息有加权。具体做法是在相似度分数上乘以一个随时间衰减的系数，衰减率根据任务的时间敏感度调。

第三个陷阱是“预算的静态假设”。很多人设好预算比例就不动了，但任务的实际 token 分布可能和假设差很远。比如你假设工具返回都很短，结果某个工具返回了超长文本，直接把工作记忆撑爆。我的做法是加一个实时监控：每步结束后检查各层实际占用，如果某层超过配额的120%，就触发一次紧急压缩或淘汰。这个监控逻辑很简单，但能避免很多突发崩溃。

注意：这三个陷阱的共同点是“不会立刻出问题，但会在长任务里慢慢累积”。所以排查长程问题时，不要只看当前步，要往回看几十步的趋势。

5.3 从失败案例里总结的排查思路

我讲一个真实的失败案例。一个跑了60步的任务，在第45步左右开始出现重复劳动——Agent 反复调用同一个工具，拿到的结果也一样，但就是不停。排查过程分三步。

第一步，看工作记忆。发现状态字典里有一条“待确认：X字段的值”，但队列里最近几步明明已经拿到了X字段的值。问题定位到：状态字典没有及时更新。原因是X字段的值是通过工具返回的，而我的更新逻辑只处理了模型显式确认的情况，没处理工具返回的隐式确认。

第二步，看短期记忆。摘要里确实记录了“已获取X字段”，但摘要更新间隔是4步，而问题出现在更新之前。也就是说，摘要还没来得及反映这个信息，工作记忆又没更新，Agent 就“不知道”自己已经拿到了。

第三步，看检索。长期记忆里没有相关记录，因为这是本次任务的新信息，还没沉淀。

根因清楚了：信息确认的路径有两条（模型显式确认、工具隐式确认），但更新逻辑只覆盖了一条。修复方法是把工具返回的关键字段也纳入状态字典的更新触发条件。修复后重跑，问题消失。

这个案例的教训是：上下文管理的更新逻辑，要覆盖所有信息进入系统的路径，不能只考虑最明显的那条。排查时按“工作记忆→短期记忆→长期记忆”的顺序看，基本能定位到问题在哪一层。

5.4 性能与成本的平衡技巧

最后聊聊成本和性能的平衡。长程 Agent 的上下文管理，本质上是在“效果”和“成本”之间找平衡点。几个实用的技巧。

分层用不同模型。工作记忆的维护需要高保真，可以用强模型；短期记忆的摘要生成可以用中等模型；长期记忆的检索排序甚至可以用小模型或纯规则。这样整体成本能降不少，效果损失有限。我实测下来，摘要生成换成中等模型，效果差异在可接受范围内，成本降了约40%。

缓存高频检索结果。长期记忆里有些条目会被反复检索，比如任务模板、常用术语定义。把这些缓存起来，避免每次都走向量检索。缓存的有效期可以设为任务级别，任务结束就清。

按需启用长期记忆。不是所有任务都需要长期记忆。短任务、独立任务，完全可以关掉长期记忆层，省下检索开销。判断标准是：任务是否需要复用跨任务知识。不需要就关掉。

监控 token 效率。定义一个指标：任务成功率除以总 token 消耗。定期看这个指标的变化，如果下降，说明上下文管理效率在退化，需要调优。这个指标比单纯看成功率或成本更有指导意义。

我个人在实际操作中的体会是，上下文管理的调优是个持续过程，没有一劳永逸的参数。任务类型变了、模型换了、工具集改了，最优参数都可能变。所以与其追求一套完美参数，不如把监控和调优的机制搭好，让它能跟着变化自动调整。这套机制搭起来之后，你会发现长程 Agent 的稳定性上了一个台阶，很多之前莫名其妙的问题都不再出现了。