10 月 10 日提交 arXiv 的 SEPM（编号 2610.14515，Self-Evolving Procedural Memory）切入的是多智能体记忆的一个结构性缺口：现有记忆系统要么管信息共享，要么管程序复用，但「共享程序怎么演化」这件事，长期和智能体之间的任务依赖、执行状态割裂着。论文的判断是——长程协作里真正值得记住的不只是「做过什么」，还有「怎么配合着做成的」。
这个缺口有多具体？可以对照单智能体的处境。单个智能体的程序记忆已经相对成熟：把成功动作序列抽象成可复用技能，下次遇到类似任务直接调。但把这套方案搬进团队场景，丢掉的恰恰是配合结构——谁在什么依赖关系下等待、谁的结果被谁消费、偏差出现时怎么对齐。为个体设计的记忆，迁到团队里经常「步骤都对、协作全乱」。
执行中与执行后，两段机制
SEPM 的方案可以用一句话概括：让协调与记忆共用同一个表示——任务依赖图。
执行中，一个轻量共享黑板记录结构化证据，并与任务依赖写在一起。系统据此检测三类偏差：目标偏离、计划偏离、世界状态偏离，一旦发现就做循证再对齐。注意这里是「拿证据说话」而不是投票表决——多数智能体同意不等于事实正确，这是多智能体系统里很常见的设计误区。
执行后，验证过的动作连同它们的依赖关系一起被蒸馏成可复用程序，进入共享程序池；反复出现的失败则转化为警告与约束。程序池本身不是静态仓库，它经历创建、精修、专化、退役四种演化操作，由成功率与成本效用共同引导，同时受证据与安全需求约束。最后一点常被忽略：没有退役机制的池子只会越来越脏。
六项设置全优，以及一个符合直觉的梯度
论文在 ALFWorld、WebArena、OfficeBench 三个基准上，于 AutoGen 与 DyLAN 两种框架下做了评测，共六项设置，SEPM 的任务得分均为对比方法中最高。以 AutoGen 为例，相对「不加记忆」的基线，三项基准分别提升 29.85、25.86 与 13.00 个百分点。
提升幅度的递减顺序本身就是信息。三个基准的任务性质差异很大：室内导航、网页操作、办公流程。任务越长程、越依赖多智能体分工，程序性记忆的价值越高——这与论文的问题意识互相印证。如果某个场景下单智能体加记忆就能解决，SEPM 这类方案的必要性会大打折扣。
它真正补的位置
把这篇论文放回多智能体工程的语境，它补的是「经验沉淀」这一环，而不是「通信协议」那一环。已有的多智能体工作大量讨论拓扑结构、通信成本、角色分配，但一个团队跑完一百个任务之后，除了日志还剩下什么？SEPM 的答案是：剩下一个带适用条件的程序池，以及一份「什么条件下别这么干」的约束清单。
对做多智能体产品的团队，这提示了一个常被跳过的设计问题：你们的智能体协作是「每次从零开始」，还是「越用越熟练」？前者实现简单，但每个任务都在全额付学费；后者要操心演化治理——程序谁来审、退役标准是什么、专化会不会过拟合到某类任务的表面特征。
还没披露的部分
论文摘要未给出程序池的规模控制手段、演化触发的具体阈值，以及跨任务复用时「适用条件」的匹配机制——这些恰是落地时最容易出问题的工程细节。两个评测框架都属常见开源栈，商业多智能体产品不在评测范围内，结论的外推需谨慎。代码已开源，复现门槛相对可控。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。