ICLR、ICML 2026：一文汇总长程 Agent 上下文管理
大概从去年开始，我就在持续跟进长程 Agent 这个方向。原因很直接：现在大家做的 Agent 大多只能在"几轮对话"或者"单步工具调用"里表现良好，一旦把任务拉长到小时级、天级，上下文管理就成了真正的瓶颈。上下文一乱，Agent 就变成"金鱼脑"，前面记住后面忘，甚至开始胡言乱语。而 ICLR、ICML 2026 这两大顶会，今年恰好都把这个方向列进了重点讨论范畴，相关投稿肉眼可见地变多。我花了两三周把能找到的相关论文、开源项目和技术报告梳理了一遍，这篇就一次性汇总整理，把长程 Agent 上下文管理的核心问题、主流方案和工程落地经验都说清楚——适合正在做 Agent 应用、又想跟上学术前沿的工程师直接参考。
之所以把 ICLR 和 ICML 放在一起讲，是因为这两个会这几年在 Agent 方向上的侧重点已经开始分化：ICLR 更偏向记忆机制、表示学习和模型架构层面的创新，ICML 则更关注学习算法、优化策略和大规模部署中的鲁棒性问题。但到了"上下文管理"这个交叉点上，两边的工作其实经常互相引用、你中有我。所以我干脆按技术路线而不是按会议来拆解，这样对实际做系统的人更有参考价值。
1. 长程 Agent 上下文管理的核心痛点：先弄清楚到底在解决什么问题
1.1 上下文失控的典型场景
先说几个我在实际项目和论文里都反复看到的场景，这些是长程 Agent 上下文管理这个方向存在的根本原因。
第一个是长对话上下文的累积漂移。Agent 做一项需要持续一小时的复杂任务（比如从几十份网页信息里整理一份调研报告），前 20 分钟的对话中还戴着"用户偏好简洁输出"的指令，后 40 分钟这个约束已经被大量工具调用结果和中间分析给淹没。不是 Agent 不想遵守，而是上下文里相关度较高的指令已经被挤出了模型的有效注意力范围。这个在 Transformer 架构下几乎是必然的物理限制，不是靠简单加长窗口就能解决。
第二个是工具调用轨迹的重复累积。我很早就发现，当 Agent 连续调用工具超过 15 次之后，对话历史里充满了大量重复的 API 响应格式、JSON 字段、时间戳。这些内容对当前问题的判断毫无帮助，却实实在在占据了 token 预算。结果是：要么总 token 超限报错，要么上下文中有效决策依据的比例越来越低，模型的表现就像"在垃圾堆里找黄金"。
第三个是长期记忆的存取割裂。做完一个跨越多天的任务，Agent 得记住用户的核心偏好、之前确认过的关键决策、已经排除掉的错误方向。但大多数 Agent 框架在记忆方面只是简单把旧对话塞进一个"记忆库"，读出来的时候要么信息过时，要么和当前上下文格式完全不兼容。上下文管理在这里已经不是 token 压缩问题了，而是记忆的编码—存储—检索—融合这一整套机制。
1.2 为什么长窗口不能直接解决这个问题
很多人第一反应是：模型上下文窗口从 4K 涨到 128K、1M，上下文管理问题是不是就迎刃而解了？这个想法我在不止一个技术群里看到过，但实际做下来会发现没那么简单。
长窗口解决的是"能装多少"的问题，但上下文管理的核心矛盾是"模型到底关注什么"。即使给到 1M token 的窗口，注意力分布依然会趋向于集中在开头（primacy bias）和结尾（recency bias）的部分，中间的大段内容经常被模型"视而不见"。这是当前 Transformer 架构在某些基准上的内在倾向，单纯扩大窗口只会让"看起来都装下了"变成一种假象。
另外还有一个更实际的问题：单位推理成本。上下文里的每个 token 都会参与前向传播计算，窗口拉长意味着每步推理的延迟和成本都线性上升。在长程 Agent 的场景下，Agent 可能需要几十上百步决策，每一步都把全部历史塞进去的话，成本完全不可控。我之前做过一个粗略估算：如果每步请求都带 200K token 上下文，跑完一个百步任务，光是输入 token 开销就已经非常可观，这还没有算输出 token 和重试的次数。所以现在 ICLR、ICML 2026 投稿里大家一致认同的一个前提是：长程 Agent 必须主动管理上下文，而不是被动扩容。
注意：别把"上下文管理"和"窗口长度"混为一谈。窗口长度是模型侧的能力，上下文管理是 Agent 系统侧的工程和算法问题。前者决定你能塞多少，后者决定你应该怎么塞、塞什么、丢了还能不能找回来。
2. 主流技术路线全景：从上下文化的压缩、分层到检索与状态持久化
我梳理了 2025 年到现在在 ICLR、ICML 预印本、OpenReview 以及几个重要开源 Agent 框架里的工作，当前长程上下文管理基本可以拆成五条技术路线。它们解决的问题有重叠，但侧重点不同，实际系统里往往要组合使用。
2.1 上下文压缩与摘要
这条路线最直觉：既然上下文太长，那就把它变短。具体做法包括：
- 对话级摘要：每当对话进行到 N 轮，或者 token 数达到阈值，调用一次 LLM 把前面的对话总结成结构化摘要。这个方案最早在很多客服机器人里就有，但现在 Agent 场景下的摘要格式要复杂得多——不仅要总结用户说了什么，还要保留工具调用链、中间推断和已确认的关键决策。
- 工具轨迹压缩：只保留每次工具调用的输入输出关键字段，删掉响应头、耗时统计、调试日志等无关信息。我在实践中会把工具调用的 JSON 转成更紧凑的键值表示，有些原始响应能压缩 60%-80%。
- 句子级重要性过滤：用一个小模型对每一条历史消息做重要性打分，只保留超过阈值的消息。这类方法的优势是灵活，缺点是容易误删上下文微妙的衔接信息。
摘要做得好不好，直接决定后续任务执行的连贯性。我把摘要策略总结成三个最关键的问题：保留什么（事实性信息、用户约束、任务进度）、丢弃什么（无意义寒暄、重复的中间分析）、如何组织（结构化字段还是自由文本）。ICLR 2026 有多篇投稿在做"摘要质量对后续任务成功率影响"的消融实验，我自己的经验是：自由文本摘要的还原度远低于"结构化摘要+关键原始片段"的混合方案。
2.2 分层记忆架构
既然"一条上下文从头拿到尾"不现实，那就把信息拆成不同层级，按需加载。这个思路目前是 ICLR、ICML 2026 投稿中的绝对主流，几乎所有长程 Agent 框架都在往这个方向靠。
比较常见的分层是三层：
- 工作上下文（Working Memory）：当前正在处理的任务、最近的工具调用结果、尚未完成的子目标。这部分必须完整保留在当前 prompt 里，因为它直接驱动下一步决策。
- 情景记忆（Episodic Memory）：过去一段时间内完成的任务、关键事件、用户反馈。这些不需要一直留在上下文里，但随时可能被调出。
- 语义记忆（Semantic Memory）：用户长期偏好、领域知识、项目背景。这部分相对稳定，更新频率低，但影响全局决策。
分层架构的核心难点在于记忆的写入时机和检索策略。什么时候从工作上下文"冷却"到情景记忆？什么时候把情景记忆中的某个部分重新拉回工作上下文？这些如果全靠手动规则，Agent 一旦超出固定脚本，就会漏信息或者反复加载，导致 token 耗散。最近不少框架开始尝试让 Agent 自己根据当前任务决定需要加载哪些记忆，相当于加一层"元记忆控制"，效果不错，但也会带来额外的 LLM 调用成本。
2.3 检索增强生成（RAG）式的上下文选择
把 RAG 思路用进来，是长程 Agent 上下文管理中工程上最容易落地的一条路线。做法和常规的知识库问答 RAG 类似：把对话历史、工具调用记录、任务笔记切成 chunk，用 embedding 模型索引起来；在每步决策之前，根据当前问题向量检索出最相关的几段历史，拼接进上下文。
但这个方案在长程 Agent 场景里和常规 RAG 有几个重要差别：
- 检索对象不是静态文档，而是动态累积的对话和状态记录，会不断追加新内容；
- 检索相关性不能只看语义相似度，还要看时间衰减——太旧的信息可能已经过时，即使语义上很相似也不能直接用；
- 检索结果要按事件因果链组织，因为工具调用轨迹往往是链状的，单看一条消息很难理解。
我在工程实践里的做法是：对每一轮消息做双路编码，一路是语义向量，一路是包含时间戳和任务 ID 的结构化标签。检索时先按标签粗筛，再按语义排序，最后还要用一个 LLM 调用做去重和排序——纯 embedding 排序在复杂任务上下文里经常把过时信息排在前面，教训很深刻。
2.4 状态外置与工具化记忆
这条路线在工程社区里讨论很多，但在学术论文里却相对少，至少在 ICLR 2026 的投稿里还不算多。核心思想很简单：不要试图把记忆塞进模型的上下文窗口，而是把它放到 Agent 外部环境里，按需读取和更新。
具体实现一般是：为 Agent 维护一个外部状态库（结构化数据库或者键值存储），Agent 在执行步骤的过程中不断读写这个状态库。读写过程通过工具调用来完成，比如 write_note()、query_state()、update_task_status() 这样的函数。上下文里只保留最近几步操作的结果，更早的内容都在外部存储里躺好，需要的时候再精准取用。
这个思路对工程实现极其友好，因为大部分 Agent 框架本来就支持工具调用，加几个记忆工具几乎是零成本。问题是：Agent 必须"记得"自己有哪些记忆工具、里面存了什么。如果状态库越滚越大，Agent 自己在查询的时候也会面临"该查哪块"的元问题。所以这类系统往往还要配一个状态索引层。ICML 2026 有篇投稿专门分析了这种"元记忆负担"的度量，并提出了自动化的状态索引压缩策略，我和他们的实验结论基本一致：状态外置方案的关键瓶颈，已经从存储转移到了元记忆开销。
2.5 上下文持久化与会话恢复机制
最后一个容易被忽视的方面：进程崩溃、服务重启、网络超时之后，长程任务怎么接着跑。这个在演示 demo 里没人提，但生产环境里一定会碰到。上下文管理如果只做"在会话期间优化 token"，那还远远不够，因为长程 Agent 的定义本身隐含了"跨会话生存"的要求。
实践上需要做到：
- 每个历史消息都要有持久化 ID，用户会话、任务执行记录、Agent 内部状态三者之间有一致的外键引用；
- 每步决策的中间结果尽量以追加写方式落库，宁可多写不要少写；
- 恢复会话时要能重建"工作上下文"——把所有未完成子任务、进行中的工具链、最近约束一次性塞回模型面前。
我踩过最大的坑是在恢复会话时没有重建工作上下文，而是直接把所有持久化历史一股脑拉出来，结果 Agent 恢复后完全不知道当前进行到哪一步，把之前已经做完的调查又重新做了一遍。这事的根源在于：持久化消息和历史记录是两个层面——历史记录是"发生了什么"，工作上下文是"下一步该干什么"。很多框架只做了前者，后者完全没有。
3. 两个顶会的关注重心差异与典型论文方向
既然标题是 ICLR、ICML 2026 的汇总，就不能不提这两个会在长程 Agent 上下文管理上的研究视野差异。我和一些同行交流下来，大家普遍觉得这两个会现在的口味已经有明显分化的趋势。弄清楚这些差异，不管是选方向还是读论文都省力很多。
ICLR 这边更吃"机制创新"。OpenReview 上围绕上下文管理的投稿，大部分在讨论：怎么让模型在决策时自动判断该携带什么历史信息？能不能在训练阶段就教会模型"选择性遗忘"？有没有比纯文本摘要更优雅的压缩表征？也就是说，ICLR 更想做的是把上下文管理能力内化到模型或者记忆机制内部，而不是外层套一个工程管道。几个和记忆增强 Transformer、分层记忆状态空间、上下文稀疏注意力相关的工作都投在了这一阵营。
ICML 这边则更偏"方法论和鲁棒性"。比如：如何对长程 Agent 的上下文管理系统做系统性评估？压缩摘要丢失信息的量应该在哪个数量级才不影响最终任务成功率？多步决策下的错误累积和上下文信息失真之间的关系怎么建模？以及分布式框架下的共享记忆一致性。你如果去翻 ICML 2026 的投稿列表，会发现大量工作是带着 benchmark、消融实验、误差分析来的，方法论味比 ICLR 重不少。
我的建议是：如果你是在校学生或者研究员，想发文章，选 ICLR 还是 ICML 取决于你的优势。擅长搭框架、搞新机制的，ICLR 赢面大；擅长做实验、搞评测、能把自己方案和其他五个主流方法做严密对比的，ICML 更稳。如果是工程师想跟进前沿思路，那两边都得读——ICLR 给的是"未来 Agent 会变成什么样"的方向感，ICML 给的是"这些方案到底哪个更靠谱"的判断依据。
4. 从论文到工程：我在长程 Agent 上下文管理上的落地经验
理论框架梳理完之后，聊聊实际落地。毕竟两个顶会上的论文方法再好看，最后还是得跑在自己的系统里。我过去一年在两个不同的 Agent 项目上实践过上下文管理，一个是自动化调研 Agent，一个是长对话陪伴型助手，各有各的坑。这里挑最有代表性的经验分享。
4.1 混合上下文方案是当前性价比最优解
我最后采用的方案，并不依赖任何单一论文里的机制，而是一个工程上的混合策略：
- 短程（过去 10 轮内）全部保留，不压缩、不摘录；
- 中程（10-50 轮）做结构化摘要，按用户意图、决策点、约束条件、工具结果四个字段组织；
- 长程（50 轮以上）只保留语义记忆和关键事件，平时完全不进入上下文，按需通过 RAG 检索回来；
- 状态库永远单独维护，任务进度、完成标志、待办事项全部外置。
这套方案没有哪部分是特别创新的，但组合起来以后效果意外稳定。最关键的一个设计是中程摘要的字段化。自由文本摘要的问题在于后来检索的时候很难精确抽取"用户当时到底提了什么要求"，而四个字段的结构化摘要配合每个字段的向量索引，在检索命中率上明显好于纯文本。
具体参数我给个参考：我的基准模型是 128K 上下文窗口的模型，但我给 Agent 设的软上限是 20K token，超过这个值就开始压缩中程内容，这样留出足够余量给工具调用结果和模型输出。压缩触发不只看 token 总数，还看轮数——即使 token 没超、但对话超过 25 轮，也会触发中程摘要。因为长对话里的重复信息和话题漂移往往在 token 上体现不出来。
4.2 踩过的坑：摘要信息丢失与上下文拼接位置
先说摘要信息丢失的坑。有段时间我发现 Agent 在长任务后段频繁出现"用户没说过这个要求，但 Agent 以为用户说过"的情况。排查下来，问题出在我的摘要 prompt 太简单，只是让模型"总结对话"，没有告诉它"用户的所有硬性约束必须逐字保留"。模型自作聪明地做了提炼，把一些约束条件改成了自己的理解，结果后面的所有决策都建立在了错误前提上。
修复方案不复杂：摘要 prompt 里明确要求"约束条件字段中必须原样引用用户原话，不得转述；如果原话超过合理长度，至少保留完整关键词"。加上这个约束之后，这种错误明显减少。
再说上下文拼接位置。很多 Agent 框架默认把参考资料插在 System Prompt 后面，也就是尽量靠前的位置。但我在长程 Agent 场景里发现，把检索回来的历史记忆放在靠近末尾、也就是紧跟最近一轮用户消息的位置，效果反而更好。这和上面提到的 recency bias 有关系——模型对靠后的内容更敏感，决策时更容易参考到。所以如果一段历史记忆是和当前决策强相关的，放在后面比放在前面好。
提示：上下文拼接的位置不是一个可以随意对待的细节。同样一段关键约束，放在 System Prompt 末尾和放在对话历史末尾，实测对任务成功率的影响可以达到十几个百分点。建议你在自己的场景里分别测，不要照搬网上默认模板。
4.3 长期记忆写入的"事件化"处理
另一个在长程任务里很重要的实践：把记忆写入从"消息日志"转换成"事件记录"。普通对话日志天然是流水账，适合人看，但机器检索效果不好。我会额外维护一张事件表，每个事件记录四件事：事件类型、涉及对象、结论/状态、时间戳。比如：
- 事件类型：约束确认
- 涉及对象：用户偏好-报告篇幅
- 结论/状态：用户明确说控制在 3000 字以内
- 时间戳：2026-01-12 14:23
Agent 在后续决策里如果检索到这条事件，就能直接确认约束，不需要翻原始对话。这个做法的成本是写入时需要额外花一次 LLM 调用做事件抽取，但换来的是检索效率和准确率的双重提升。在我的自动化调研 Agent 里，事件化之后的记忆命中准确率从大概 70% 提升到了 90% 以上。
5. 关于 ICLR 2026 投稿流程：如果你也是第一次投
这个部分专门写给打算把自己长程 Agent 上下文管理工作投到 ICLR 2026 的朋友。很多人对 ICLR 的投稿流程会有偏差认知，我去年第一次投的时候也踩了流程上的坑。
5.1 ICLR 2026 的关键阶段划分
ICLR 的投稿流程最显著的特点是公开评审。这和大部分会议把评审意见藏起来不同，ICLR 从提交论文起，所有评审意见、作者的 rebuttal、评分、甚至最终录用决定都会在 OpenReview 平台上公开可见。这意味着不仅你要在截止时间前交论文，还要在评审期间持续跟进意见并回复。
以 2026 届为例，完整周期大概是：
- 摘要截止：一般是正式投稿截止前一周左右，需要先提交论文标题和摘要，这时候可以不传全文；
- 全文提交：摘要截止后一周，提交完整论文 PDF 和补充材料；
- 评审期：提交过后大概一个月，会有至少三位评审给出初步评分和意见；
- 作者回应期：评审意见公开后，作者有一次机会写 rebuttal，针对评审的质疑做解释、补充实验或承诺后续补充；
- 评审讨论期：评审之间会讨论，然后调整评分；这个阶段作者不能参与；
- 录用决策：最终由 Area Chair 根据评审讨论结果决定是否接收。
有一个很常见的新手误区：以为投完稿就完事了，等结果就行。实际上 ICLR 的录用概率和 rebuttal 质量高度相关。我自己那篇论文初评有两个 5 分（borderline）一个 6 分，后来 rebuttal 里补充了一组针对性的消融实验，把其中 5 分拉到了 6 分才险过。ICLR 评审里"看 rebuttal 态度"的成分比想象中大。
5.2 长程 Agent 方向投稿的评审偏好
从今年各大工作区的情况看，长程 Agent 上下文管理方向的评审普遍看重三件事：
一是评测是否足够硬核。如果你只是在一个自建的简单 benchmark 上报告成功率，评审很容易认为说服力不足。大家都在用更复杂的多人交互、跨天持续性、工具调用链深度等更严苛的基准做测评。建议至少覆盖 6 小时以上的任务跨度。
二是是否有消融实验。上下文管理方案通常由多个模块组成——摘要、检索、分层存储、状态库。评审想知道每一块到底贡献了多少提升。我在自己的论文里把完整模型和去掉检索、去掉摘要、去掉事件化的三个变体做了对比，这组实验几乎是最后的救命稻草。
三是能否说清和你对比的 baselines 的差异。ICLR 评审特别喜欢问"你这个和现有框架（比如 LangMem 或 Mem0）有什么区别"。如果你不做直接对比，解释起来会非常被动。我建议在论文里至少和两个开源记忆框架做公平对比，这一条也能帮你在 rebuttal 阶段赢得信任。
5.3 投稿前一定要做的自查
最后列一个我自己的投稿前自查清单，仅供参考，但我这两年每次投都会过一遍：
- 相关工作是否完整：ICLR 评审对 related work 的缺失非常敏感。长程上下文管理涉及 NLP、Agent、系统设计多个子领域，建议至少系统性读过三四十篇相关论文再动笔；
- 基准是否足够复杂：如果只用了短程任务，评审很容易质疑你的方案能否泛化到真正长程场景。至少加一个跨越多轮的、带工具调用的任务；
- 可复现性：代码、数据、 prompt 模板是否齐全。ICLR 近年趋势越来越看重可复现性，代码链接缺失是直接掉分项；
- 成本分析：如果论文只报效果提升，不报告 token 用量和延迟开销，评审基本会追问。上下文管理方案向来是效果和成本之间找平衡，一张成本-效果折线图会很有说服力。
6. 几个值得继续关注的方向与我的判断
把目前的阅读和实践总结一下，我判断长程 Agent 上下文管理这一块，接下来一两年会在下面几个方向上出现比较密集的突破。
首先是从被动压缩走向主动遗忘。现在的方案多是"上下文太长就压缩"的被动响应。但 ICLR 2026 已经有一些投稿在探讨：Agent 能不能在学习过程中就形成"哪些信息不值得记"的判断力？这有点像人类记忆的遗忘机制——适当遗忘反而提高决策质量。这个方向如果跑通，会根本改变上下文管理模块在 Agent 架构中的位置，它会从外挂工具变成 Agent 能力的一部分。
其次是分层记忆的元控制层。前面提到了 Agent 得自己决定"该加载哪部分记忆"，这需要一种元认知能力。目前解决方法都还很初级，主要靠每步多调一次 LLM 来判断，成本偏高。一旦有人能训练出专门的元控制模型——输入是当前状态和记忆索引，输出是"该加载哪几条记忆"，整个分层记忆方案的效率和可靠性都会上一个台阶。ICML 2026 的工作区里已经能看到这类工作的雏形。
还有多模态长程上下文。现在讨论的大多是纯文本，但真实 Agent 迟早要处理工具输出里的图片截图、UI 界面截图、语音转录、表格等复杂信息。多模态上下文的压缩和管理，目前几乎是空白，谁先做出来谁就是学术和工程的双重山头。
我的个人意见是，做工程的同行别等论文都发了再起步，现在就可以在项目里把上面说的混合方案用起来——结构化摘要加状态外置加按需检索，这套组合看起来务实，其实就是当前最前沿方案在工程上的投影。等那些学术框架成熟了，你手上的实践经验会反过来帮你更容易地读懂论文、评估取舍。
另外还有一点想提，ICLR 2026 的摘要截止时间通常在前一年的秋天，如果你真想投这一届，现在时间就很紧了。早动手准备实验和基准，比纠结选题重要得多。长程 Agent 上下文管理这个方向还远没有到"被做烂"的程度，现在进去，既出得了学术成果，也解决得了实际问题，两头都有价值。