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:23Agent 在后续决策里如果检索到这条事件就能直接确认约束不需要翻原始对话。这个做法的成本是写入时需要额外花一次 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 上下文管理这个方向还远没有到被做烂的程度现在进去既出得了学术成果也解决得了实际问题两头都有价值。