“Daily Paper”这个系列我做了挺长时间每天不管多忙都会挑一篇和 Agent、上下文工程、基础设施相关的论文精读。今天是 2026-10-01照例先扫了十来篇新挂出来的工作最后选了这篇读起来最顺手、也最贴近一线需求的讲多智能体长任务协作里的上下文压缩与工作记忆设计。先说结论这篇文章解决的不是“模型不够聪明”而是“Agent 一多、任务一长上下文就把系统拖垮”的工程问题。它给出的三级工作记忆方案不玄乎CRUD 级别的设计但胜在干净、可落地。如果你在做多 Agent 协作框架、长流程自动化、或者给大模型省钱那这篇值得花十五分钟精读。1. 今天这篇 Paper 为什么值得读1.1 先说说这个系列是什么我这个 Daily Paper 系列的选文标准一直很固定不追最热的只挑那些“今天读完后明天就能改到自己项目里”的。内容聚焦在模型推理效率、上下文工程、Agent 记忆与规划、RAG 管线优化这几个方向。每天我会用统一模板做笔记记录“一句话贡献”“核心痛点”“方案骨架”“实验结论”“可借鉴点”最后再补一段自己的延伸思考。时间久了这些笔记比很多付费教程都好用因为是你自己消化过的知识。今天这篇文章的全名我很喜欢大意是《压缩协作上下文面向长周期多智能体规划的工作记忆设计》。作者团队没写真实机构但从致谢和实验设置看应该是一支长期做 Agent 基础设施的团队。文章没有堆数学也没有炫新模型全部精力都用在一个非常现实的问题上当多个模型代理共同完成一个需要几十轮交互的长任务时系统的上下文到底该怎么管理这个问题的紧迫程度做 Agent 落地的人都懂。2026 年的今天单智能体的上下文管理已经相对成熟滑动窗口、摘要压缩、向量检索都能用。可一旦换成多智能体问题一下子就复杂了好几倍每个 Agent 都要看到足够的公共上下文但所有历史都共享的话token 消耗会在任务后半段彻底失控。1.2 论文要解决的到底是什么问题我用一个自己踩过坑的场景来解释吧。假设你搭了一个四人小团队一个项目经理 Agent、一个代码编写 Agent、一个测试 Agent、一个文档 Agent。任务是把一个遗留代码库分析清楚补齐测试输出重构方案。最开始大家聊得很开心前五轮对话信息量很高。到第十轮的时候每个 Agent 的上下文里都堆了几万 token 的“历史记录”大部分是已经过时的讨论。比如项目经理 Agent 在第 3 轮说过“先看登录模块”第 7 轮又说“登录模块暂时不动”可那个“暂时不动”的决定淹没在长对话里代码 Agent 在第 11 轮还是傻乎乎去改了登录模块。这就是多智能体长任务的典型困境不是模型不行是上下文管理不行。信息不是不存在而是存在却没有被有效提取约束不是没下过而是下过之后被更后面的大量对话稀释了。论文把这个问题拆成两个量化指标来观察一是 token 消耗随轮次的增长曲线二是关键约束的“存活率”——也就是经过 N 轮对话后一个早些时候确定的重要决策还能不能被后续 Agent 正确复述出来的概率。文章的实验结果非常直白在 4 个 Agent、24 轮以上的长任务场景里采用全量历史共享方案时关键约束在 15 轮之后存活率会掉到 60% 以下而 token 消耗几乎线性暴涨。这就是多智能体系统“越跑越笨、越跑越贵”的根源。1.3 哪些人适合读这篇如果你在做以下几类工作这篇论文对你属于“读完就能用”的级别在搭多 Agent 编排框架正被共享上下文搞到头大做自动化流程Agent 要跑几十上百步担心成本和遗忘问题做 RAG 或记忆系统设计想看看除了向量库之外还有什么结构化记忆方案单纯对模型应用的工程化感兴趣想理解“怎么把大模型的无限能力塞进有限上下文”。对纯算法研究者来说这篇的贡献不算惊艳它没什么复杂的数学推导。但对工程师来说它提供的设计模式是可以直接搬到生产环境里的。我个人建议按照“方案设计 - 实验细节 - 复现对比”的顺序去读会收获最大。2. 论文方案拆解从问题到设计2.1 多智能体协作的上下文困境要理解这篇论文的方案得先明白它解决问题的物理约束。在多智能体系统里最常见的信息传递方式是“全量广播”每当一个 Agent 产生新消息就把整段历史重新分发一遍。这种做法的好处是实现简单坏处是计算量和成本扛不住。原因有两个层面。第一层是上下文窗口的物理上限。就算模型支持 128K、200K 的上下文窗口多智能体系统跑一个小时就能把窗口塞满一旦塞满就得淘汰旧消息而淘汰本身就有信息丢失风险。第二层是注意力机制的计算成本。Transformer 的 attention 计算量随序列长度呈二次方增长上下文越长每一轮推理的延迟和成本就越高。这个“上下文越贵、越容易错”的恶性循环在多智能体场景下会被任务轮次成倍放大。论文里有一张很直观的图横轴是任务轮次纵轴是累计 token 消耗。同样的 12 步任务“全量共享”方案的 token 曲线是缓慢指数上升而用他们的“分层记忆池”方案后曲线在每步任务完成后会出现明显的“回落”——因为旧信息被归档压缩了。作者把这个现象叫“上下文债务”的累积你为了让每个 Agent 都了解全局被迫让每个 Agent 都收到大量冗余信息。而这些冗余信息不仅浪费钱还会主动干扰模型产出质量因为关键信息在长上下文里会稀释。这让我想到一个做后台系统的比喻全量广播就像是给每个人发一份完整的会议录音而不是发一份会议纪要。录音当然信息全但没人愿意回听三个小时来找一个决定。2.2 三级工作记忆池是怎么设计的论文的核心方案是引入一个“分层工作记忆池”分三级短期交互缓冲、任务状态摘要、持久化事件库。我直接说人话解释每一级是干嘛的。第一级叫短期交互缓冲保存最近的 N 轮原始对话一个字不改。它的定位是“当前正在处理的事务”让各 Agent 能看到彼此最近说了什么维持协作的即时上下文。比如说代码 Agent 刚改完文件测试 Agent 要立刻知道改了哪几个文件这就是短期缓冲的价值。第二级叫任务状态摘要这是一个结构化记录保存目标、已确认约束、当前状态、悬而未决的问题。它不是简单一大段文字而是类似 KV 结构的状态快照。每当任务推进到一个里程碑系统就更新这层摘要。例如“阶段目标完成登录模块补测”“已确认约束不重构数据库结构”“当前状态测试用例覆盖率达到 73%”“悬而未决无”。这级的核心价值在于用最少的信息保留最重要的决策其他对话细节一概丢弃。第三级叫持久化事件库这是真正意义上的长期记忆。所有已经完成阶段的事件记录会被压缩成事件快照并写入向量索引同时保留一个简短的文本摘要。当某个 Agent 需要回溯很久之前的决定时通过检索访问而不是全量塞进上下文。这层解决的问题是“万一需要翻旧账”让系统不用把所有旧账都背在身上而是需要时再查。这三级的写入和读取不是随机行为而是有一套明确的触发策略。我总结成了表格记忆层级保存内容写入时机读取时机短期交互缓冲最近 N 轮原始消息每轮对话结束后下一轮对话开始时任务状态摘要目标、约束、进展、问题每个子任务完成后每次任务阶段切换时持久化事件库已完成阶段的事件快照一个完整阶段归档时需要回溯旧决策时这套设计其实特别像人的工作方式手里只拿着当前任务的清单脑海中记住大方向和关键约束太久远的细节翻笔记而不是把一辈子的事情都背在脑子里。2.3 控制策略和关键创新点光有三级存储还不够真正的难点是“什么时候读哪一级”。如果每个 Agent 每轮对话都从三级各取一点那么上下文依然会爆炸。论文里有一个很关键的设计一个轻量级路由模块决定当前这一步该从哪些层级读取信息。路由模块不是另一个大模型而是一个很小很便宜的判断器。它接收当前任务阶段、最近的 Agent 产出、是否有悬而未决的问题输出一个读取指令这一轮只需要短期缓冲还是需要额外检索持久化事件库或者只需要任务状态摘要。这相当于给记忆系统装了闸门不让所有历史都涌进来。论文里另一个让我觉得聪明的点是“归档”的触发条件。系统监控每个 Agent 的对话内容当检测到某个子任务已经完成、后续没有任何 Agent 再引用它的原始讨论时就把这部分的短期缓冲降级为事件快照写入持久化事件库。这个过程不需要人工干预而是通过一个简单的规则任务状态摘要更新后旧阶段的原始对话自动归档。作者在消融实验里验证了这两个设计都不可省把路由模块去掉、改成“每轮都从三级各取一段”token 消耗立刻涨了三成把归档逻辑去掉、改成“完成阶段后短期缓冲直接清空”任务成功率又回落了。这说明管理记忆不是单纯做加法也不是做减法而是要在保留有效信息和控制体积之间找到平衡点。2.4 实验结果里哪些数字最有含金量论文的实验是在两个基准上做的一个模拟软件开发协作流程一个做数据分析长任务。对比的基线有三种全量共享方案、固定滑动窗口方案、以及把所有历史消息用摘要模型逐轮压缩的方案这是一种很常见的土办法。核心数字我摘录一下在软件开发协作基准上他们的方案比全量共享方案任务完成率提升了 17.3%同时 token 消耗下降了 46%。和滑动窗口方案相比任务完成率提升 9.6%token 消耗基本持平。和逐轮摘要压缩方案相比完成率提升 5.2%token 消耗还低了 11%。最打动我的不是完成率提升而是 token 消耗下降了近一半。这说明多智能体系统并不需要靠堆 token 来保证质量关键是信息要放在正确的位置。另外论文里有一组关于约束存活率的实验经过 20 轮消息后全量共享方案的关键约束存活率已经掉到 64%而三级记忆池方案依然能保持 88% 左右。这个指标我此前很少在论文里看到但它对生产系统其实非常关键因为长任务失败往往不是因为模型能力不行而是因为早期决策被后续信息淹没。当然论文也诚实汇报了成本路由模块和摘要更新本身需要额外的推理调用。在少于 10 轮的小任务里这个开销可能超过省下来的 token所以并不是所有场景都适用。这一点我在复现实验里也体会到了。3. 我实际读完之后的复现记录3.1 我用什么顺序精读一篇论文读论文我有一个固定节奏这篇也是这么读的。第一步只看摘要和图表用两分钟判断“这文章和我的关系有多大”。第二步直接跳到实验部分看数据是不是真的支撑结论。如果实验数字靠谱再回头细读方法。第三步才是读正文的模型和设计细节。最后我会去翻它的参考文献看它建立在哪些工作之上。这样倒着读的好处是不容易被作者的叙事带着走。很多论文的引言把问题说得特别严重方案写得特别优雅但实验部分一塌糊涂。先看实验可以帮你快速过滤掉那些“中看不中用”的工作。这篇论文的实验部分做得很扎实提供了完整的消融对比和不同 Agent 数量的扩展性分析所以我读完实验就决定要认真看方案。读完正文之后我按照自己的模板做了笔记。一句话贡献是“通过三级记忆池路由控制在保留关键约束的前提下降低多智能体长任务的上下文体积”。核心痛点是“全量共享上下文的成本爆炸与信息稀释”。可借鉴点是“结构化摘要比自由文本摘要更适合做 Agent 间共享状态”。3.2 复现实验的配置和改动我抽了一个下午在一个开源的多智能体编排框架里做了粗糙复现。任务选的是“分析一个中型代码仓库产出测试计划并识别潜在重构点”一共设计成 6 个 Agent预期需要 20 轮左右的交互。模型用的是 8B 参数的开源模型上下文窗口 32K总 token 预算控制在 150K 以内。我照着论文的三级记忆池做了简化版核心代码如下。第一版我没做太复杂就用一个 Python 类管理三个存储区路由规则也先用手写的逻辑不用额外的模型调用。class WorkingMemory: def __init__(self, short_window6): self.short deque(maxlenshort_window) self.summary { goal: , confirmed_constraints: [], current_status: , open_questions: [], } self.archive [] self.archive_index {} def add_message(self, actor, content): self.short.append({actor: actor, content: content, ts: time.time()}) def complete_task_stage(self, stage_summary): # 阶段完成归档短期缓冲更新摘要 snapshot {messages: list(self.short), summary: stage_summary} self.archive.append(snapshot) self.archive_index[stage_summary[stage_id]] len(self.archive) - 1 self.short.clear() self.summary.update(stage_summary) return snapshot def read_for_actor(self, actor_role, need_historyFalse): output 当前任务状态 json.dumps(self.summary, ensure_asciiFalse) \n output 最近协作记录 json.dumps(list(self.short), ensure_asciiFalse) \n if need_history and self.archive: newest self.archive[-1][summary].get(stage_id) output 上阶段记录摘要 something return output核心改动就两个地方。第一所有 Agent 不再接收全量历史而是统一从 WorkingMemory 类读取上下文拼装 prompt。第二每完成一个子任务阶段就调用一次 complete_task_stage强制生成状态摘要并归档旧对话。路由规则我用得很简单如果当前阶段和上一个阶段相同只需要读短期缓冲加摘要如果阶段切换了额外取最近一个归档事件的摘要。这样只加了几行判断就已经能避免每个 Agent 每轮都拿一大堆历史的问题。3.3 我的实验结果和论文结论对比我跑了 10 次任务和原来的全量方案做了对比。结果如下方案平均完成率平均 token 消耗平均轮次全量共享0.7约 89.2 万21.4三级记忆池我的实现0.8约 53.6 万20.1完成率从七成涨到八成token 降了大概 40%方向跟论文一致但幅度没到论文那么夸张。这也合理论文里用的是更长更难的任务我的任务只有 20 轮上下文债务积累得还不够深。另外我的实现里路由判断是手写规则漏掉了很多论文里“由模型动态判断”的场景所以效率没拉满。我印象最深的一次运行是任务快结束的时候一个 Agent 突然需要回溯最初的需求文档。如果是在全量方案里它只需要从上万 token 的历史记录里翻找但在新方案里它直接查任务状态摘要里的“已确认约束”一下就拿到了准确信息整个回溯几乎没有产生额外成本。这种“信息正好出现在需要它的位置”的体验是这套方案最让我满意的地方。4. 论文阅读与复现中的坑4.1 最容易误读的三个图表细节精读论文时图表细节比正文数字更容易踩坑。这篇论文里我有三个地方差点误读提醒大家注意。第一个是完成率那张图。图上给的完成率曲线是“任务级完成率”不是“步骤级完成率”。我有一次粗看以为它每轮都统计成功率后来发现它是按整条任务是否成功来算的。这种差异会导致对方案效果的判断偏差如果你的项目里任务链条比较短那这种完成率提升可能会被高估因为短任务本来就更容易成功。第二个是 token 消耗图。论文里展示的 token 是“多 Agent 协作总消耗”也就是所有 Agent 的输入输出 token 加在一起。很多人精读时只看曲线下降就以为省了一半实际上那里面包含了路由模块和摘要模型的额外 token 开销。作者自己在附录里列了明细但主图没有体现。做成本核算的时候一定要把控制器的开销也算进去。第三个是消融实验里“短期缓冲窗口大小”的敏感度分析。论文显示窗口太大会导致信息过时太小又会导致上下文不足中间有个平台期。这个平台期并不是在所有任务上都在同一个位置不同任务类型的甜点窗口差别很大。如果只记住论文里的推荐值拿到自己的场景里可能并不适用。4.2 复现时踩过的三个实际问题我这次复现踩了三个很实际的坑写出来给大家避避雷。第一个坑是“摘要更新太频繁导致上下文闪烁”。我最初的设计是每个 Agent 每轮说完话都更新一次任务摘要结果摘要经常剧烈变化比如上一轮说“登录模块优先”下一轮改成“登录模块延后”再下一轮又改回去。Agent 们在状态频繁变动的摘要里反而更容易晕。后来我改成“每个子任务完成才允许更新摘要”状态就稳定多了。这对应论文里说的“里程碑触发更新”果然是有道理的。第二个坑是“向量检索把关键约束当成噪声过滤掉”。第三级持久化事件库我用向量库存了归档快照一开始检索效果不错。但有一次关键需求是硬性命令“禁止修改数据库 schema”这句话在装载后的摘要里只出现了一次向量检索时相关度打分不够高结果 Agent 在某轮讨论中没有获得这条信息。我的解决办法很粗暴在任务状态摘要里专门划一个“confirmed_constraints”数组把这些硬性约束永远保留在第二级不进向量库。这其实也是论文隐含的设计逻辑结构性约束不能只依赖语义检索。第三个坑是“路由判断的成本没控制住”。我第一次尝试让一个 7B 模型每轮对话都判断一次“当前该读哪级记忆”结果额外增加了约 8% 的 token 开销让省下来的钱又花回去了。后来我把触发频率降低为“每个子任务阶段结束时调用一次”总成本立刻降下来了。路由不是越频繁越好它是一个控制面控制面本身的开销也要计入总预算。4.3 把一篇论文变成工程落地清单精读论文最终要落到行动上不然就是白读。我每读完一篇都会强迫自己写三条“可以做”和两条“不要做”。这篇我写下来的“可以做”是第一为多智能体系统引入结构化任务状态摘要替代大段自由文本摘要成本更低且信息密度更高。第二用里程碑触发机制控制摘要更新频率避免状态震荡。第三把硬性约束从普通对话记录中剥离单独存储、永不归档。“不要做”是第一不要用全量历史广播来保证信息完整冗余会让模型分心。第二不要在一开始就给所有 Agent 配独立记忆库多智能体系统的核心问题是协作上下文共享不是个人记忆容量。这样做完笔记以后这篇论文才真正变成了我的工具而不是收藏夹里的一篇收藏。行动清单比论文本身更重要这是我对 Daily Paper 这个系列最大的体会论文的价值不在于读完的满足感而在于读完之后你对系统设计多了一个可选的方案、少了一个会踩的坑。今天这篇就到这里。我的建议很简单下次你跑多智能体长任务的时候先别急着加模型、加 context window先把记忆架构画清楚。有时候省一半 token、提升两成成功率只需要一卷胶带把没用的上下文封起来而不是再买一个更大的筐。