去年年底我在调试一个多轮信息收集 Agent 的时候碰到了一个非常典型的现象任务只进行了不到 20 轮模型就开始把用户前面提过的关键约束忘得干干净净回答里甚至出现前后矛盾。翻日志一看上下文窗口已经塞满了原始对话记录而真正重要的需求早就被挤到模型注意力够不到的位置。这个问题不是个例凡是跑过长程 Agent 的人大概都在某个时刻被“它明明答对了前面怎么后面就乱了”这句话击中过。这篇文章想把长程 Agent 上下文管理这件事一次性摊开说清楚。我会从场景倒推技术缺口再把现在社区里比较主流的方案按“压缩、检索、缓存、架构”四条线拆开讲结合 ICLR、ICML 2026 这个节点上大家正在争论的问题最后给出一套可以直接照抄的配置思路和排查清单。不管你是正在搭 Agent 产品的工程师还是准备做相关研究的同学这篇文章应该能帮你省下一大段自己踩坑的时间。1. 长程 Agent 为什么“记不住事”从场景倒推技术缺口1.1 长程任务到底包括哪些场景上下文在哪一环失效一说到长程 Agent很多人第一反应是“窗口够大就行”。但真去跑几个任务就会发现窗口长度只是最表面的一层。我实际接触到的长程场景大概有这么几类第一类是跨天甚至跨周的多轮助理对话。用户每天来问几句Agent 要记住前几天的偏好、决定、未完成事项。这类任务的难点在于不是所有历史都重要但模型不知道哪些重要只能把整段历史都塞进去。第二类是代码仓库级的重构任务。Agent 要浏览上百个文件理解模块之间的依赖然后在某个地方修改代码。这种任务里上下文里可能只有 5% 的信息和最终修改相关剩下 95% 都是背景噪声。第三类是数据分析类的长流程。Agent 要把取数、清洗、可视化、写结论串在一起中间的中间结果如果不落盘后续步骤就只能靠“猜”上一步做了什么。第四类是游戏或仿真环境里的探索型任务Agent 需要长期记住地图结构、资源位置、已经尝试过的失败路径。把这四类场景摆在一起上下文失效的位置其实很一致要么发生在输入阶段模型窗口被塞满导致截断要么发生在注意力阶段信息虽然在窗口里但模型根本没有关注到要么发生在推理链阶段早期的一个错误结论被后续步骤当成事实继续传播。这三层失效叠加起来就会出现“看起来模型什么都记得但回答就是不对劲”的诡异状态。1.2 上下文管理是“存储”问题还是“决策”问题很多团队遇到长程 Agent 记不住事第一个想法是换更大的窗口模型或者把所有历史不假思索地存进向量库。做过一轮之后会发现换大窗口只是把问题往后推塞向量库也只是从一个混乱变成另一个混乱。在我看来上下文管理本质上不是存储问题而是决策问题。你可以把 Agent 的上下文理解成一个打工人的工作台。桌面太大会让人把所有文件都摊开反而找不到最需要的那张桌子小一点反而会逼着你把重要文件放在手边把不重要的归档。长程 Agent 的上下文管理核心是回答四个问题什么信息必须留在桌面上什么信息应该被压缩成摘要什么信息要到归档里临时翻出来什么信息直接扔掉永远不回头。这每一个问题都是决策不是存储。理解了这一点再看现在各种方案就会很清楚压缩方案解决的是“哪些信息不值得占空间”检索方案解决的是“哪些信息应该被临时找回”缓存方案解决的是“哪些计算不应该重复做”架构方案解决的是“谁来负责做这些决策”。所以别急着堆工具先想清楚你的 Agent 在哪个环节最常犯错再选对应方案。2. 主流方案全景图把长上下文拆成四种武器2.1 压缩型方案摘要与层级记忆怎么选压缩是最直觉的思路。既然上下文太长那就把历史对话或历史观察用一个摘要替掉。但摘要怎么做差别非常大。最简单的是“滚动摘要”维护一个不断更新的 summary每轮对话结束后把新的内容合进去。我给一个客户做过类似系统最初方案就是每 10 轮对话触发一次摘要把旧对话替换成 summary。跑了一阵发现两个问题一是摘要模型本身会丢细节用户之前提过“周二之前必须交付”摘要里只剩下“尽快交付”二是摘要会累积错误如果某一轮摘要写错了后面所有轮次都沿着这个错误走而且非常难发现。后来我把方案改成了“层级记忆”。第一层是原始对话保留最近 20 轮第二层是把每 10 轮对话压成一段事件摘要保留最近 50 段第三层再按主题把事件摘要聚合成主题档案。模型每次推理时默认只加载第一层需要追溯早期信息时才按需访问第二层和第三层。这个结构有点像人类的记忆近事记得清旧事记大概重大事件单独存档。代价是实现复杂度高了不少但信息丢失率明显下降。还有一个容易被忽视的点摘要里要保留“关键实体清单”。单纯让摘要模型“压缩这段对话”往往会写出流畅但空洞的概括而如果你强制要求摘要输出时附带实体列表、数字和截止日期后续检索和推理的可用性会大幅提升。2.2 检索型方案RAG 之外Agent 记忆检索的技巧提到检索大家都会想到 RAG。但 Agent 的记忆检索和文档问答的 RAG 有本质区别文档 RAG 检索的是静态知识Agent 记忆检索的对象是动态的经历——对话、决策、结果、失败教训。这些记录之间有时间关系、因果关系单纯靠向量相似度是抓不住这层结构的。我在实践中比较常用的做法是“分桶存储加多路召回”。把记忆按类型分成几个桶用户偏好、任务状态、常识事实、过往错误。查询时不是只做一次向量检索而是针对当前意图分别从不同桶里取候选再做融合重排。举个例子Agent 发现用户这次说的需求和一个小时前说的一模一样那“用户偏好”桶里的记忆就应该比“常识事实”桶里的记忆加权更高。另外两个技巧很实用。第一个是时间衰减权重。记忆检索不能只看相似度时间越近的记忆应该默认加一点分除非当前任务明确要求找回很久以前的约定。第二个是“检索结果必须带着来源标识”。我在设计记忆条目时每条记录都会附上事件 ID 和时间戳这样模型拿到检索结果时能知道这段记忆发生在哪个阶段避免把旧状态当成当前状态。很多 Agent 出问题就是因为模型分不清“用户曾经说过”和“用户现在的要求”。2.3 缓存与 KV 优化降低重复计算成本的正确姿势长程 Agent 还有一个经常被忽略的问题——不只是“装不装得下”还有“算不算得起”。每次多轮对话如果都要重新计算整段上下文的 KVKey-Value缓存成本会随着轮次线性上涨。之前跑一个 50 轮的数据分析任务光 token 费用就让项目经理脸色发青。现在主流模型都支持 KV cache 复用前缀不变的情况下新的生成只需要计算增量部分。这就带来一个重要思路尽量让 prompt 的前缀保持稳定。我在设计 Agent 的 system prompt 时会把“模型总规则 工具定义 当前任务模板”放在最前面把动态内容尽量放在后面。这样每次调用只要能复用前缀缓存成本立刻降下来。针对更极端的长上下文场景社区里还有两类技巧值得关注一类是滑动窗口加 attention sink 的做法保持最近 N 个 token 的注意力完整更早的内容以压缩表示参与计算另一类是“关键 token 缓存”把历史中反复被引用的实体、数字单独存成一小段固定表示。这些做法在具体模型上有不同的实现方式和使用约束真要落地前务必先确认你用的模型 API 是否支持相关参数别在文档没细看的情况下直接上生产。缓存方案最大的坑是缓存失效prompt 任意一个前缀字节变动都会导致整段重算所以 prompt 模板的改动要极其谨慎。2.4 架构型方案从单 Agent 到多 Agent 的记忆分工单 Agent 负责所有事情遇到长程任务就像让一个人既当前台又当会计还当仓库管理员早晚要崩溃。多 Agent 架构把这些职责分开是目前处理超长程任务最稳健的方向。我在实际项目中用过一个三 Agent 结构一个 Planner 负责拆解任务和记录全局状态一个 Executor 负责执行当前步骤并返回结果一个 Memory Keeper 负责读写长期记忆。Planner 的上下文里永远只放“当前目标 已完成步骤列表 下一步计划”Executor 的上下文只放“当前步骤的输入”Memory Keeper 不和用户直接交互它只管把 Executor 返回的结果结构化地写进记忆仓库。这个分工让每个 Agent 的上下文都很短而且各司其职不会出现信息互相污染。多 Agent 结构还有一个好处可以给不同 Agent 配置不同的上下文管理策略。Planner 用压缩型方案就够了因为它只需要知道“做了哪些事”Executor 更适合检索型方案因为它需要具体的事实和参数Memory Keeper 则是纯粹的存储读写不用参与推理。这种“按角色分配记忆策略”的思路比让一个 Agent 什么都干要可控得多。3. 从论文到落地ICLR / ICML 2026 社区在关注什么3.1 几个值得关注的研究方向在 ICLR 和 ICML 这个方向上长程 Agent 的上下文管理并不是一个全新话题但 2026 这个节点上讨论的焦点明显更聚焦了。今年大家争论比较多的问题我梳理下来大概是这几个第一个是评估基准的问题。现在很多工作还在用“窗口长度”作为卖点但社区的共识正在转向“信息利用率”。也就是说给你 128K 窗口你能不能在这 128K 里准确定位那 3K 关键信息如果模型只是把窗口撑大但注意力还是集中在开头和结尾这种能力就没有意义。围绕这个问题ICLR 2026 有不少工作在做更细粒度的长程评测集包括长文档里的跨段落推理、长对话里的潜伏信息召回、长代码里的跨文件修改等。第二个是记忆结构的形式化。RAG 和向量检索更多是工程实践但学术界想搞清楚Agent 的记忆到底应该以什么粒度存储是对话回合、事件、还是实体关系不同的存储粒度对下游任务的成功率有什么影响目前已经有工作尝试把记忆建模成带时间戳的有向图让 Agent 在图上做条件检索这个方向我觉得比简单的向量库有前途。第三个是“上下文管理该前置还是后置”。换句话说是让模型自己学会从长上下文里挑重点还是在外围系统里先把重点挑好再喂给模型。前者是训模型的路线后者是搭系统的路线。2026 年的趋势明显偏向后者因为外围系统可控、可调试、可观测而且不依赖未知的模型能力。3.2 从 ICLR 流程看研究落地的话外音ICLR 的审稿流程这几年越来越规范但也越来越卷。如果你准备投稿相关方向我有几点从工程视角出发的建议不算学术方法论但非常实用。第一实验里一定要报告“上下文管理模块本身的成本”。很多论文只报最终任务的成功率完全不提为了管理上下文额外花了多少 token、多少延迟。审稿人现在很吃这一套因为你做了一个检索增强或压缩方案如果收益只有几个点而成本翻了一倍落地价值就要打问号。第二长程 Agent 工作最容易翻车的地方是“baseline 太弱”。你拿一个完全没有记忆管理的模型做对比证明自己的方案有效这没有说服力。基本盘至少要包含“原始长上下文直接塞入”“滚动摘要”“朴素向量检索”这三个 baseline不然审稿人会质疑你的增量。第三注意案例的可复现性。ICLR 现在要求代码和配置公开的比例越来越高。我在复现别人论文的时候最头疼的就是“记忆参数不公开”存什么、索引什么、检索几个、阈值多少这些不写清楚论文基本就废了一半。你要是做研究把这部分细节写透反而会成为加分项。4. 实操为你的长程 Agent 做一套上下文管理配置4.1 上下文预算清单怎么列不管用什么方案动手之前先列一份上下文预算清单。我一般把上下文分成五个部分系统提示、工具定义、用户输入、运行历史、瞬时输出。前两部分相对固定用户输入是硬要求真正能优化的是后两部分。以一个 128K 窗口的模型为例我会这样分配系统提示加工具定义控制在 4K 以内用户当前输入预留 8K瞬时输出比如工具返回的结果控制在 16K 以内剩下大约 100K 给历史。历史里再细分最近 20 轮完整对话占 40K滚动摘要占 8K关键实体清单占 2K其余 50K 留给按需检索注入的记忆。这个预算不是死的但它逼着你给每个模块设一个边界而不是“有多少塞多少”。做完预算清单之后你还需要一个“超限预案”。我惯用的做法是当历史超过预算的 80% 时先触发一次摘要合并把最老的 20% 历史压成摘要如果还是超再触发检索索引刷新如果仍然超才考虑截断。预案要写成代码逻辑不能靠模型临场发挥。4.2 参数选择的具体计算示例配置上下文管理不能靠感觉这里我给一个可复现的计算示例。假设你用的是 128K 窗口模型目标是跑一个 100 轮的长对话任务。每轮对话平均消耗 1.2K token那么 100 轮就是 120K超出窗口。你设滚动摘要策略每 5 轮触发一次将 5 轮原始对话约 6K压缩成一段事件摘要约 0.8K。那么 100 轮会产生 20 段事件摘要总计约 16K再加上保留最近的 5 轮原始对话6K总历史占用约 22K相比 120K 节省了超过 80% 的空间。检索参数怎么定假设记忆库里有 500 条历史事件你不能每次都把 500 条全部注入。我的经验是初次召回用 30 条候选经过重排后只注入 Top 5相似度阈值设为 0.72基于 embedding 模型的分布实测后调的。如果 Top 5 里的最高相似度都低于 0.6那就说明当前问题不适合检索历史宁可让模型只依靠当前窗口作答也不要强行塞入可能不相关的记忆。成本上也要会算。如果完整历史是 120K压缩后是 22K而缓存命中率是 70%那么每次请求的有效输入大概是 22K 加上少量系统 prompt相比不压缩的 120K成本大约能降到原来的五分之一到六分之一。这个账算明白之后你就知道上下文管理不只是“让效果变好”它同时是“让成本可控”。4.3 评估指标体系不该只看任务成功率给长程 Agent 做评估只盯着任务成功率远远不够。我建议至少拉一套多维度指标哪怕刚开始粗糙一点也要把各个模块的贡献拆开看。我习惯用这样一个表格来评估上下文管理模块维度指标观察方式信息覆盖关键约束召回率人工检查摘要和检索结果是否包含必要实体事实一致性答案与历史事实矛盾率对比模型输出与原始记录中的明确事实上下文效率有效信息密度关键信息 token 数 / 总输入 token 数延迟单轮响应时间从提交到返回的端到端耗时成本每任务 token 消耗统计输入加输出的总 token 数任务成功率是结果指标但长程 Agent 失败的原因可能出现在任何一个环节。比如任务失败是因为记忆检索没召回关键信息还是因为摘要把截止日期丢了这两种情况在成功率上看起来一样但修法完全不同。所以我会在每次失败时记录一条“失败归因”日志是截断、检索、摘要还是模型推理导致的。积累一段时间之后你就能看出自己的系统到底在哪一环最薄弱对应的优化也更有针对性。5. 常见问题与排查技巧实录5.1 漂移上下文逐渐偏离主题长程 Agent 最常遇到的问题就是“漂移”。一开始还在正确轨道上聊着聊着就跑偏了而且这种跑偏往往是渐变式的很难被及时发现。我排查过的一个案例里Agent 在前半段还严格遵守“只使用内部数据源”的约束后半段就开始自行上网搜索补充信息原因是早期对话里的系统约束被后续大量的工具调用记录稀释了模型渐渐忘了自己最初被赋予的边界。排查这类问题我建议加一个“主题对齐检查”步骤。每 N 轮对话后让模型用一句话总结当前正在做的事和最初任务目标做一次对比。如果偏差超过预设阈值就触发一次“回到主线的修正”动作把最新的目标摘要重新注入上下文。这个检查的成本很低但能有效止损。5.2 摘要失真核心信息被抹掉摘要模型把关键信息压缩没了是压缩方案的经典坑。尤其是数字和限定词“3 个候选方案”被压成“若干候选方案”“用户明确拒绝方案 B”被压成“讨论了方案 B”。这种失真在单层摘要里几乎无法避免。我的对策有两个。第一摘要 prompt 里强制要求保留所有数字、专有名词、否决性结论这些是最容易被压缩模型忽略却对下游最重要的信息类型。第二给摘要条目加“指针”。也就是说每段摘要后面附带对应原始记录的 ID 范围当模型需要知道更细的细节时可以通过指针回查原文。摘要不是替代原文而是索引这个思路非常关键。5.3 检索噪声把无关记忆拉回来检索模块比想象中更容易“召回一些看起来相关、实际无关”的内容。比如用户这次问“帮我整理一下上周的项目进度”向量检索很可能把一个月前跟这个项目相关但状态已经完全变化的旧记录拉回来模型如果不懂区分就会把旧状态当成当前状态。我给检索模块加了两层过滤第一层是时间窗口过滤除非查询里明确提到“历史”或“之前”否则默认只检索最近 N 天内的记录第二层是状态过滤记忆条目里如果包含“已完成”“已废弃”这类终结状态标签检索命中的时候要额外提醒模型“这是过期信息”。这两层过滤之后检索噪声引发的错误大幅下降。5.4 成本失控上下文越长越贵如果只追求效果不管成本长程 Agent 很容易变成一个烧钱机器。我见过最夸张的案例是某团队跑一个长文档分析任务单次任务的输入 token 接近百万成本高到完全无法产品化。成本失控背后往往是没有预算控制也没有缓存复用。解决办法是把预算控制写进代码而不是交给模型自觉。每次调用前算出当前上下文的 token 数超过预算就走压缩和降级流程。同时我强烈建议把成本监控做成可视化曲线按“每轮对话成本”和“每个任务总成本”两个维度看。当你看到成本曲线在某个轮次突然跳升大概率是某次检索注入的记忆太多这时候就需要限制检索条数或加大相似度阈值。结尾长程 Agent 的上下文管理做了这么久我最深的体会是它不是一个大一统的技术方案能解决的问题而是要在“理解任务特征、拆解失败原因、组合管理手段”这个循环里不断调优的过程。我见过有人花大价钱买了超长窗口模型结果任务成功率没涨多少也见过有人用一个简单的滚动摘要加检索组合把 100 轮任务的成本压到原来的四分之一成功率反而提升了十几个点。差别不在于工具多高级而在于是否理解自己的 Agent 到底在哪个环节丢信息。最后再分享一个小技巧项目上线初期给你的记忆读写模块加上详细日志记录每一次压缩、检索、缓存命中和失败。这些日志看起来不起眼但当你排查“模型怎么突然答错了”的时候它们就是唯一的破案线索。多数时候问题不是模型变笨了而是你的上下文管理策略在一处不起眼的细节上崩溃了。把这些细节看住长程 Agent 才能真正担得起“长程”这两个字。 
长河君 · 2026/11/4 3:41:45 · 阅读 1.2k 长程Agent上下文管理四板斧：压缩、检索、缓存与多Agent架构
去年年底我在调试一个多轮信息收集 Agent 的时候碰到了一个非常典型的现象任务只进行了不到 20 轮模型就开始把用户前面提过的关键约束忘得干干净净回答里甚至出现前后矛盾。翻日志一看上下文窗口已经塞满了原始对话记录而真正重要的需求早就被挤到模型注意力够不到的位置。这个问题不是个例凡是跑过长程 Agent 的人大概都在某个时刻被“它明明答对了前面怎么后面就乱了”这句话击中过。这篇文章想把长程 Agent 上下文管理这件事一次性摊开说清楚。我会从场景倒推技术缺口再把现在社区里比较主流的方案按“压缩、检索、缓存、架构”四条线拆开讲结合 ICLR、ICML 2026 这个节点上大家正在争论的问题最后给出一套可以直接照抄的配置思路和排查清单。不管你是正在搭 Agent 产品的工程师还是准备做相关研究的同学这篇文章应该能帮你省下一大段自己踩坑的时间。1. 长程 Agent 为什么“记不住事”从场景倒推技术缺口1.1 长程任务到底包括哪些场景上下文在哪一环失效一说到长程 Agent很多人第一反应是“窗口够大就行”。但真去跑几个任务就会发现窗口长度只是最表面的一层。我实际接触到的长程场景大概有这么几类第一类是跨天甚至跨周的多轮助理对话。用户每天来问几句Agent 要记住前几天的偏好、决定、未完成事项。这类任务的难点在于不是所有历史都重要但模型不知道哪些重要只能把整段历史都塞进去。第二类是代码仓库级的重构任务。Agent 要浏览上百个文件理解模块之间的依赖然后在某个地方修改代码。这种任务里上下文里可能只有 5% 的信息和最终修改相关剩下 95% 都是背景噪声。第三类是数据分析类的长流程。Agent 要把取数、清洗、可视化、写结论串在一起中间的中间结果如果不落盘后续步骤就只能靠“猜”上一步做了什么。第四类是游戏或仿真环境里的探索型任务Agent 需要长期记住地图结构、资源位置、已经尝试过的失败路径。把这四类场景摆在一起上下文失效的位置其实很一致要么发生在输入阶段模型窗口被塞满导致截断要么发生在注意力阶段信息虽然在窗口里但模型根本没有关注到要么发生在推理链阶段早期的一个错误结论被后续步骤当成事实继续传播。这三层失效叠加起来就会出现“看起来模型什么都记得但回答就是不对劲”的诡异状态。1.2 上下文管理是“存储”问题还是“决策”问题很多团队遇到长程 Agent 记不住事第一个想法是换更大的窗口模型或者把所有历史不假思索地存进向量库。做过一轮之后会发现换大窗口只是把问题往后推塞向量库也只是从一个混乱变成另一个混乱。在我看来上下文管理本质上不是存储问题而是决策问题。你可以把 Agent 的上下文理解成一个打工人的工作台。桌面太大会让人把所有文件都摊开反而找不到最需要的那张桌子小一点反而会逼着你把重要文件放在手边把不重要的归档。长程 Agent 的上下文管理核心是回答四个问题什么信息必须留在桌面上什么信息应该被压缩成摘要什么信息要到归档里临时翻出来什么信息直接扔掉永远不回头。这每一个问题都是决策不是存储。理解了这一点再看现在各种方案就会很清楚压缩方案解决的是“哪些信息不值得占空间”检索方案解决的是“哪些信息应该被临时找回”缓存方案解决的是“哪些计算不应该重复做”架构方案解决的是“谁来负责做这些决策”。所以别急着堆工具先想清楚你的 Agent 在哪个环节最常犯错再选对应方案。2. 主流方案全景图把长上下文拆成四种武器2.1 压缩型方案摘要与层级记忆怎么选压缩是最直觉的思路。既然上下文太长那就把历史对话或历史观察用一个摘要替掉。但摘要怎么做差别非常大。最简单的是“滚动摘要”维护一个不断更新的 summary每轮对话结束后把新的内容合进去。我给一个客户做过类似系统最初方案就是每 10 轮对话触发一次摘要把旧对话替换成 summary。跑了一阵发现两个问题一是摘要模型本身会丢细节用户之前提过“周二之前必须交付”摘要里只剩下“尽快交付”二是摘要会累积错误如果某一轮摘要写错了后面所有轮次都沿着这个错误走而且非常难发现。后来我把方案改成了“层级记忆”。第一层是原始对话保留最近 20 轮第二层是把每 10 轮对话压成一段事件摘要保留最近 50 段第三层再按主题把事件摘要聚合成主题档案。模型每次推理时默认只加载第一层需要追溯早期信息时才按需访问第二层和第三层。这个结构有点像人类的记忆近事记得清旧事记大概重大事件单独存档。代价是实现复杂度高了不少但信息丢失率明显下降。还有一个容易被忽视的点摘要里要保留“关键实体清单”。单纯让摘要模型“压缩这段对话”往往会写出流畅但空洞的概括而如果你强制要求摘要输出时附带实体列表、数字和截止日期后续检索和推理的可用性会大幅提升。2.2 检索型方案RAG 之外Agent 记忆检索的技巧提到检索大家都会想到 RAG。但 Agent 的记忆检索和文档问答的 RAG 有本质区别文档 RAG 检索的是静态知识Agent 记忆检索的对象是动态的经历——对话、决策、结果、失败教训。这些记录之间有时间关系、因果关系单纯靠向量相似度是抓不住这层结构的。我在实践中比较常用的做法是“分桶存储加多路召回”。把记忆按类型分成几个桶用户偏好、任务状态、常识事实、过往错误。查询时不是只做一次向量检索而是针对当前意图分别从不同桶里取候选再做融合重排。举个例子Agent 发现用户这次说的需求和一个小时前说的一模一样那“用户偏好”桶里的记忆就应该比“常识事实”桶里的记忆加权更高。另外两个技巧很实用。第一个是时间衰减权重。记忆检索不能只看相似度时间越近的记忆应该默认加一点分除非当前任务明确要求找回很久以前的约定。第二个是“检索结果必须带着来源标识”。我在设计记忆条目时每条记录都会附上事件 ID 和时间戳这样模型拿到检索结果时能知道这段记忆发生在哪个阶段避免把旧状态当成当前状态。很多 Agent 出问题就是因为模型分不清“用户曾经说过”和“用户现在的要求”。2.3 缓存与 KV 优化降低重复计算成本的正确姿势长程 Agent 还有一个经常被忽略的问题——不只是“装不装得下”还有“算不算得起”。每次多轮对话如果都要重新计算整段上下文的 KVKey-Value缓存成本会随着轮次线性上涨。之前跑一个 50 轮的数据分析任务光 token 费用就让项目经理脸色发青。现在主流模型都支持 KV cache 复用前缀不变的情况下新的生成只需要计算增量部分。这就带来一个重要思路尽量让 prompt 的前缀保持稳定。我在设计 Agent 的 system prompt 时会把“模型总规则 工具定义 当前任务模板”放在最前面把动态内容尽量放在后面。这样每次调用只要能复用前缀缓存成本立刻降下来。针对更极端的长上下文场景社区里还有两类技巧值得关注一类是滑动窗口加 attention sink 的做法保持最近 N 个 token 的注意力完整更早的内容以压缩表示参与计算另一类是“关键 token 缓存”把历史中反复被引用的实体、数字单独存成一小段固定表示。这些做法在具体模型上有不同的实现方式和使用约束真要落地前务必先确认你用的模型 API 是否支持相关参数别在文档没细看的情况下直接上生产。缓存方案最大的坑是缓存失效prompt 任意一个前缀字节变动都会导致整段重算所以 prompt 模板的改动要极其谨慎。2.4 架构型方案从单 Agent 到多 Agent 的记忆分工单 Agent 负责所有事情遇到长程任务就像让一个人既当前台又当会计还当仓库管理员早晚要崩溃。多 Agent 架构把这些职责分开是目前处理超长程任务最稳健的方向。我在实际项目中用过一个三 Agent 结构一个 Planner 负责拆解任务和记录全局状态一个 Executor 负责执行当前步骤并返回结果一个 Memory Keeper 负责读写长期记忆。Planner 的上下文里永远只放“当前目标 已完成步骤列表 下一步计划”Executor 的上下文只放“当前步骤的输入”Memory Keeper 不和用户直接交互它只管把 Executor 返回的结果结构化地写进记忆仓库。这个分工让每个 Agent 的上下文都很短而且各司其职不会出现信息互相污染。多 Agent 结构还有一个好处可以给不同 Agent 配置不同的上下文管理策略。Planner 用压缩型方案就够了因为它只需要知道“做了哪些事”Executor 更适合检索型方案因为它需要具体的事实和参数Memory Keeper 则是纯粹的存储读写不用参与推理。这种“按角色分配记忆策略”的思路比让一个 Agent 什么都干要可控得多。3. 从论文到落地ICLR / ICML 2026 社区在关注什么3.1 几个值得关注的研究方向在 ICLR 和 ICML 这个方向上长程 Agent 的上下文管理并不是一个全新话题但 2026 这个节点上讨论的焦点明显更聚焦了。今年大家争论比较多的问题我梳理下来大概是这几个第一个是评估基准的问题。现在很多工作还在用“窗口长度”作为卖点但社区的共识正在转向“信息利用率”。也就是说给你 128K 窗口你能不能在这 128K 里准确定位那 3K 关键信息如果模型只是把窗口撑大但注意力还是集中在开头和结尾这种能力就没有意义。围绕这个问题ICLR 2026 有不少工作在做更细粒度的长程评测集包括长文档里的跨段落推理、长对话里的潜伏信息召回、长代码里的跨文件修改等。第二个是记忆结构的形式化。RAG 和向量检索更多是工程实践但学术界想搞清楚Agent 的记忆到底应该以什么粒度存储是对话回合、事件、还是实体关系不同的存储粒度对下游任务的成功率有什么影响目前已经有工作尝试把记忆建模成带时间戳的有向图让 Agent 在图上做条件检索这个方向我觉得比简单的向量库有前途。第三个是“上下文管理该前置还是后置”。换句话说是让模型自己学会从长上下文里挑重点还是在外围系统里先把重点挑好再喂给模型。前者是训模型的路线后者是搭系统的路线。2026 年的趋势明显偏向后者因为外围系统可控、可调试、可观测而且不依赖未知的模型能力。3.2 从 ICLR 流程看研究落地的话外音ICLR 的审稿流程这几年越来越规范但也越来越卷。如果你准备投稿相关方向我有几点从工程视角出发的建议不算学术方法论但非常实用。第一实验里一定要报告“上下文管理模块本身的成本”。很多论文只报最终任务的成功率完全不提为了管理上下文额外花了多少 token、多少延迟。审稿人现在很吃这一套因为你做了一个检索增强或压缩方案如果收益只有几个点而成本翻了一倍落地价值就要打问号。第二长程 Agent 工作最容易翻车的地方是“baseline 太弱”。你拿一个完全没有记忆管理的模型做对比证明自己的方案有效这没有说服力。基本盘至少要包含“原始长上下文直接塞入”“滚动摘要”“朴素向量检索”这三个 baseline不然审稿人会质疑你的增量。第三注意案例的可复现性。ICLR 现在要求代码和配置公开的比例越来越高。我在复现别人论文的时候最头疼的就是“记忆参数不公开”存什么、索引什么、检索几个、阈值多少这些不写清楚论文基本就废了一半。你要是做研究把这部分细节写透反而会成为加分项。4. 实操为你的长程 Agent 做一套上下文管理配置4.1 上下文预算清单怎么列不管用什么方案动手之前先列一份上下文预算清单。我一般把上下文分成五个部分系统提示、工具定义、用户输入、运行历史、瞬时输出。前两部分相对固定用户输入是硬要求真正能优化的是后两部分。以一个 128K 窗口的模型为例我会这样分配系统提示加工具定义控制在 4K 以内用户当前输入预留 8K瞬时输出比如工具返回的结果控制在 16K 以内剩下大约 100K 给历史。历史里再细分最近 20 轮完整对话占 40K滚动摘要占 8K关键实体清单占 2K其余 50K 留给按需检索注入的记忆。这个预算不是死的但它逼着你给每个模块设一个边界而不是“有多少塞多少”。做完预算清单之后你还需要一个“超限预案”。我惯用的做法是当历史超过预算的 80% 时先触发一次摘要合并把最老的 20% 历史压成摘要如果还是超再触发检索索引刷新如果仍然超才考虑截断。预案要写成代码逻辑不能靠模型临场发挥。4.2 参数选择的具体计算示例配置上下文管理不能靠感觉这里我给一个可复现的计算示例。假设你用的是 128K 窗口模型目标是跑一个 100 轮的长对话任务。每轮对话平均消耗 1.2K token那么 100 轮就是 120K超出窗口。你设滚动摘要策略每 5 轮触发一次将 5 轮原始对话约 6K压缩成一段事件摘要约 0.8K。那么 100 轮会产生 20 段事件摘要总计约 16K再加上保留最近的 5 轮原始对话6K总历史占用约 22K相比 120K 节省了超过 80% 的空间。检索参数怎么定假设记忆库里有 500 条历史事件你不能每次都把 500 条全部注入。我的经验是初次召回用 30 条候选经过重排后只注入 Top 5相似度阈值设为 0.72基于 embedding 模型的分布实测后调的。如果 Top 5 里的最高相似度都低于 0.6那就说明当前问题不适合检索历史宁可让模型只依靠当前窗口作答也不要强行塞入可能不相关的记忆。成本上也要会算。如果完整历史是 120K压缩后是 22K而缓存命中率是 70%那么每次请求的有效输入大概是 22K 加上少量系统 prompt相比不压缩的 120K成本大约能降到原来的五分之一到六分之一。这个账算明白之后你就知道上下文管理不只是“让效果变好”它同时是“让成本可控”。4.3 评估指标体系不该只看任务成功率给长程 Agent 做评估只盯着任务成功率远远不够。我建议至少拉一套多维度指标哪怕刚开始粗糙一点也要把各个模块的贡献拆开看。我习惯用这样一个表格来评估上下文管理模块维度指标观察方式信息覆盖关键约束召回率人工检查摘要和检索结果是否包含必要实体事实一致性答案与历史事实矛盾率对比模型输出与原始记录中的明确事实上下文效率有效信息密度关键信息 token 数 / 总输入 token 数延迟单轮响应时间从提交到返回的端到端耗时成本每任务 token 消耗统计输入加输出的总 token 数任务成功率是结果指标但长程 Agent 失败的原因可能出现在任何一个环节。比如任务失败是因为记忆检索没召回关键信息还是因为摘要把截止日期丢了这两种情况在成功率上看起来一样但修法完全不同。所以我会在每次失败时记录一条“失败归因”日志是截断、检索、摘要还是模型推理导致的。积累一段时间之后你就能看出自己的系统到底在哪一环最薄弱对应的优化也更有针对性。5. 常见问题与排查技巧实录5.1 漂移上下文逐渐偏离主题长程 Agent 最常遇到的问题就是“漂移”。一开始还在正确轨道上聊着聊着就跑偏了而且这种跑偏往往是渐变式的很难被及时发现。我排查过的一个案例里Agent 在前半段还严格遵守“只使用内部数据源”的约束后半段就开始自行上网搜索补充信息原因是早期对话里的系统约束被后续大量的工具调用记录稀释了模型渐渐忘了自己最初被赋予的边界。排查这类问题我建议加一个“主题对齐检查”步骤。每 N 轮对话后让模型用一句话总结当前正在做的事和最初任务目标做一次对比。如果偏差超过预设阈值就触发一次“回到主线的修正”动作把最新的目标摘要重新注入上下文。这个检查的成本很低但能有效止损。5.2 摘要失真核心信息被抹掉摘要模型把关键信息压缩没了是压缩方案的经典坑。尤其是数字和限定词“3 个候选方案”被压成“若干候选方案”“用户明确拒绝方案 B”被压成“讨论了方案 B”。这种失真在单层摘要里几乎无法避免。我的对策有两个。第一摘要 prompt 里强制要求保留所有数字、专有名词、否决性结论这些是最容易被压缩模型忽略却对下游最重要的信息类型。第二给摘要条目加“指针”。也就是说每段摘要后面附带对应原始记录的 ID 范围当模型需要知道更细的细节时可以通过指针回查原文。摘要不是替代原文而是索引这个思路非常关键。5.3 检索噪声把无关记忆拉回来检索模块比想象中更容易“召回一些看起来相关、实际无关”的内容。比如用户这次问“帮我整理一下上周的项目进度”向量检索很可能把一个月前跟这个项目相关但状态已经完全变化的旧记录拉回来模型如果不懂区分就会把旧状态当成当前状态。我给检索模块加了两层过滤第一层是时间窗口过滤除非查询里明确提到“历史”或“之前”否则默认只检索最近 N 天内的记录第二层是状态过滤记忆条目里如果包含“已完成”“已废弃”这类终结状态标签检索命中的时候要额外提醒模型“这是过期信息”。这两层过滤之后检索噪声引发的错误大幅下降。5.4 成本失控上下文越长越贵如果只追求效果不管成本长程 Agent 很容易变成一个烧钱机器。我见过最夸张的案例是某团队跑一个长文档分析任务单次任务的输入 token 接近百万成本高到完全无法产品化。成本失控背后往往是没有预算控制也没有缓存复用。解决办法是把预算控制写进代码而不是交给模型自觉。每次调用前算出当前上下文的 token 数超过预算就走压缩和降级流程。同时我强烈建议把成本监控做成可视化曲线按“每轮对话成本”和“每个任务总成本”两个维度看。当你看到成本曲线在某个轮次突然跳升大概率是某次检索注入的记忆太多这时候就需要限制检索条数或加大相似度阈值。结尾长程 Agent 的上下文管理做了这么久我最深的体会是它不是一个大一统的技术方案能解决的问题而是要在“理解任务特征、拆解失败原因、组合管理手段”这个循环里不断调优的过程。我见过有人花大价钱买了超长窗口模型结果任务成功率没涨多少也见过有人用一个简单的滚动摘要加检索组合把 100 轮任务的成本压到原来的四分之一成功率反而提升了十几个点。差别不在于工具多高级而在于是否理解自己的 Agent 到底在哪个环节丢信息。最后再分享一个小技巧项目上线初期给你的记忆读写模块加上详细日志记录每一次压缩、检索、缓存命中和失败。这些日志看起来不起眼但当你排查“模型怎么突然答错了”的时候它们就是唯一的破案线索。多数时候问题不是模型变笨了而是你的上下文管理策略在一处不起眼的细节上崩溃了。把这些细节看住长程 Agent 才能真正担得起“长程”这两个字。