Agent长程记忆与MoE路由耦合设计：ICLR 2026中稿工作解析

1. 从“记不住”到“记得住”Agent长程记忆到底卡在哪做过Agent应用的人都有一个共同体会短对话里模型表现得像个聪明人一旦任务链条拉长到几十步甚至上百步它就开始“失忆”——前面确认过的约束条件后面自己推翻了中间查到的关键数据最后总结时张冠李戴。这不是模型不够聪明而是长程记忆这个环节没有设计好。所谓长程记忆指的是Agent在跨越多个推理步骤、多次工具调用、多轮环境交互之后仍然能够准确调用早期信息的能力。它和传统大模型的“上下文窗口”不是一回事。上下文窗口是物理容量长程记忆是信息调度策略。你可以把上下文窗口理解成一张桌子长程记忆是你在这张桌子上怎么摆文件、怎么贴标签、什么时候该翻哪一页。桌子再大摆得乱七八糟照样找不到东西。这次ICLR 2026中稿的工作里有一批围绕Agent长程记忆的改进方案核心思路可以归纳为三个方向分层压缩、结构化索引、动态遗忘。分层压缩解决的是“信息太多塞不下”的问题把原始交互记录压缩成不同粒度的摘要粗粒度用于快速定位细粒度用于精确回溯。结构化索引解决的是“找不准”的问题把记忆按实体、时间、因果关系建索引而不是靠向量相似度一把梭。动态遗忘解决的是“旧信息干扰新决策”的问题让Agent学会主动丢弃已经失效的约束而不是把所有历史都当成同等重要。我实测过一个简化版的对比同一个多步推理任务用纯上下文窗口硬扛到第40步左右准确率开始明显下滑加上分层摘要之后能撑到80步左右再叠加结构化索引120步以内的关键信息召回率还能保持在可接受范围。当然这只是个人实验环境下的粗略观察不代表论文里的严格结论但方向是清楚的——长程记忆不是靠堆容量解决的是靠调度策略解决的。还有一个容易被忽略的点长程记忆的评估本身就很困难。短任务看最终答案对不对就行长任务里Agent可能中间某一步记错了但最终答案碰巧对了这种“假阳性”在评测里非常常见。所以看这类工作时我会特别关注它的评测集是怎么设计的有没有专门构造“必须依赖早期信息才能做对”的对抗样本。没有这种设计的记忆方案说服力要打折扣。2. 混合专家模型在Agent场景下的真实收益与隐藏成本混合专家模型MoE这两年热度很高但很多人对它的理解停留在“参数量大但激活少所以又快又省”这个层面。放到Agent场景里事情没这么简单。MoE的核心机制是模型里有一组“专家”子网络每次前向计算时由一个路由网络决定激活哪几个专家。这样总参数量可以做得很大但单次计算量可控。在Agent场景下这个特性理论上很有吸引力因为Agent的任务类型变化很大——有时候需要强推理有时候需要强检索有时候需要强工具调用。如果不同专家能 specialization 到不同能力上路由就能按需调度。但实际落地时我观察到几个隐藏成本。第一是路由抖动。Agent的多步推理里相邻两步的任务类型可能很接近但路由网络因为输入微小变化选了不同专家导致输出风格或推理路径突然跳变。这在长程任务里是致命的因为Agent自己都“前后不一致”了。第二是专家负载不均。训练时如果没有好的负载均衡策略少数专家被反复激活其余专家欠训练实际有效容量远小于理论容量。第三是微调困难。MoE的微调比稠密模型麻烦得多Agent场景又偏偏需要针对特定工具集和任务分布做微调这两者叠在一起工程复杂度直线上升。这次中稿的工作里有专门针对Agent场景做MoE路由优化的。一个比较有意思的思路是按任务阶段路由而不是按单步输入路由。也就是说先把Agent的交互过程切成“规划段”“执行段”“校验段”每个段内保持专家选择相对稳定段间才允许切换。这样做的好处是减少了路由抖动代价是灵活性下降需要提前定义阶段划分。另一个思路是引入记忆感知的路由让路由网络不仅看当前输入还看长程记忆的摘要向量从而做出更全局一致的选择。从实操角度如果你现在要用MoE做Agent我的建议是先不要一上来就追求超大参数量。用一个中等规模的MoE把路由策略和记忆模块调通比直接上大模型然后发现路由一团糟要划算得多。另外监控路由熵值是个很实用的手段——熵值突然飙升往往意味着Agent遇到了分布外输入这时候要么降级到保守策略要么触发人工兜底。对比维度稠密模型混合专家模型单步计算成本与总参数成正比与激活参数成正比Agent多任务适配靠微调容量有限靠路由理论容量大长程一致性相对稳定受路由抖动影响微调复杂度较低较高需处理专家负载工程监控重点输出质量路由熵值、专家利用率3. 记忆模块与MoE路由的耦合设计这次中稿工作的关键突破把长程记忆和混合专家模型放在一起看会发现它们其实在解决同一个问题的两面记忆解决“信息存哪里、怎么取”MoE解决“取出来之后用哪部分能力处理”。如果这两者各自为政就会出现“记忆里存了正确信息但路由到了不擅长处理这类信息的专家”这种尴尬情况。这次ICLR 2026中稿的工作里我比较关注的一个方向是记忆感知的路由机制。具体来说路由网络的输入不再只是当前token的隐状态而是拼接了从长程记忆里检索出来的相关摘要向量。这样路由决策就带上了历史上下文专家选择更可能和任务的整体需求对齐。另一个方向是专家级别的记忆缓存。每个专家维护一份自己的轻量级记忆记录“我最近处理过哪些类型的子任务、效果如何”。当路由网络做决策时会参考各专家的历史表现优先选择在当前任务类型上表现稳定的专家。这有点像给每个专家加了一个“近期绩效档案”路由不只是看“谁适合”还看“谁最近靠谱”。还有一个更激进的思路是记忆驱动的专家合并与分裂。当某个专家被频繁激活且处理的任务类型高度一致时可以考虑把它分裂成更细粒度的专家当某些专家长期不被激活或表现不佳时考虑合并或裁剪。这种动态结构调整在训练阶段可以做在推理阶段做则风险较高需要非常谨慎的验证。从工程实现角度这些耦合设计带来的最大挑战是延迟。记忆检索本身有开销路由决策多了记忆输入也有开销两者叠加可能让单步延迟翻倍。所以实际部署时通常需要做几件事记忆检索用近似最近邻而不是精确检索路由网络做量化或蒸馏对延迟不敏感的阶段用完整版对延迟敏感的阶段用简化版。这些取舍没有标准答案得根据具体业务场景来定。提示如果你在复现这类工作时发现路由效果不稳定先检查记忆摘要的维度和路由网络输入的拼接方式。很多时候问题出在维度不匹配或归一化没做好而不是算法本身。4. 复现这类工作的实操路径从数据构造到评测设计想复现这次中稿工作里的思路最难的往往不是模型结构而是数据构造和评测设计。长程记忆和MoE路由的效果在短样本上根本看不出来必须构造足够长的交互序列而且序列里要埋设“必须依赖早期信息”的关键点。我的做法是分三步走。第一步构造基础交互序列。用模拟环境生成多步任务每一步都有明确的输入输出和状态变化。任务类型要覆盖规划、执行、校验、修正这几个阶段确保MoE路由有足够的切换机会。第二步埋设记忆锚点。在序列的早期位置插入一些关键约束或数据这些信息在后续步骤中必须被正确引用才能完成任务。锚点的位置要分散不能全挤在前面否则测不出长程衰减。第三步设计对抗样本。故意在中间步骤插入干扰信息看Agent会不会被带偏。干扰信息和真实锚点要在表面上相似但语义上不同这样才能测出记忆检索的精度。评测指标方面除了最终任务成功率我还会看几个中间指标早期信息召回率在后续步骤中正确引用早期锚点的比例、路由一致性相邻步骤专家选择的变化频率、记忆检索命中率检索出的记忆片段中真正相关的比例。这些指标能帮你定位问题到底出在记忆模块还是路由模块。评测指标衡量对象健康范围个人经验异常时的排查方向早期信息召回率长程记忆80%以上检查摘要粒度、索引结构路由一致性MoE路由相邻步骤切换率低于30%检查路由输入、阶段划分记忆检索命中率检索模块70%以上检查嵌入模型、相似度阈值最终任务成功率整体视任务难度而定结合中间指标定位还有一个实操心得不要一次性把记忆长度拉到最大。先从短序列开始确认记忆和路由的基本逻辑跑通再逐步加长。我见过不少人一上来就构造几百步的序列结果调试时根本不知道问题出在哪一步。逐步加长虽然慢但定位问题快得多。5. 落地时的取舍什么时候该用长程记忆什么时候该用MoE不是所有Agent场景都需要长程记忆也不是所有场景都适合上MoE。这两个技术都有明确的适用边界用错了地方反而增加复杂度和成本。长程记忆的适用场景有几个特征任务步骤多且步骤间有强依赖早期信息在后期仍然有效任务类型相对固定记忆内容可以结构化。反过来如果任务本身就是短平快、每步独立、不需要回溯历史那长程记忆就是过度设计。我见过一些客服机器人场景用户问题平均就两三步硬上长程记忆模块结果延迟增加了一倍效果没提升。MoE的适用场景则是任务类型多样且差异大有足够的训练数据让不同专家 specialization推理成本敏感需要控制单步计算量。如果任务类型单一或者训练数据不足MoE的优势发挥不出来反而引入路由不稳定的风险。小团队做垂直场景Agent我通常建议先用稠密模型把流程跑通等任务类型确实变多了再考虑MoE。两者结合的场景就更窄了需要长程记忆且记忆内容需要不同类型的能力来处理且有能力承担额外的工程复杂度。这次中稿的工作之所以有价值正是因为它在这些约束下找到了可行的设计路径。但对大多数团队来说先把记忆做好再考虑MoE是更稳妥的路线。注意MoE的路由网络在训练初期非常不稳定建议先用稠密模型预热再逐步引入专家分支。直接从头训练MoE收敛难度会大很多。6. 个人实操中的几个教训第一个教训是关于记忆摘要的粒度。我一开始把摘要做得太粗结果检索出来的记忆片段丢失了关键细节Agent拿着摘要去执行方向对了但参数错了。后来改成多级摘要粗粒度用于路由和规划细粒度用于执行和校验效果明显改善。粒度选择没有理论最优解得根据任务的信息密度来试。第二个教训是关于路由的冷启动。MoE刚初始化时路由网络基本是随机的这时候如果直接跑长程任务路由抖动会非常严重Agent的行为完全不可预测。我的做法是先用一批短任务做路由预热让路由网络至少学会区分几个大类任务再上长程任务。预热数据不需要很多几百条就够但效果立竿见影。第三个教训是关于评测的“假阳性”。前面提过长任务里Agent可能中间记错了但最终答案对了。我后来在评测里加了一步不仅看最终答案还检查中间步骤是否引用了正确的记忆锚点。这一步加进去之后发现之前很多“成功”的案例其实是蒙对的真实成功率比表面数字低不少。评测设计上多花点时间比模型调参的收益还大。第四个教训是关于延迟监控。记忆检索和路由决策的开销在单步看不出来但长任务里累积起来很可观。我后来在每一步都记录记忆检索耗时和路由耗时发现某些步骤的检索耗时异常高排查后发现是索引结构在特定查询模式下退化了。如果没有细粒度的延迟监控这个问题很难被发现。这些教训说起来都不复杂但都是在实际跑通之后才意识到的。看论文时觉得设计很优雅自己动手才发现每个环节都有坑。这也是为什么我建议看这类工作时除了看方法本身还要多关注作者有没有开源实现、有没有详细的实验配置说明。有这些信息的复现成功率会高很多。