多智能体系统跑完一项任务，留下的协作轨迹里其实藏着可复用的经验：谁规划、谁验证、谁修复、彼此怎么交接。问题在于，这些经验怎么存、怎么取，直接决定下一次任务是踩在肩膀上还是重蹈覆辙。一篇 2026 年 9 月提交的 arXiv 论文（编号 2609.21533）提出 MACE，一套面向 LLM 多智能体系统的记忆—智能体协同进化框架，核心想法是：记忆不该只增不减，而要随执行反馈不断重组。
MACE 的做法是把协作轨迹里的依赖关系打包成「函数记忆单元」，再用自适应记忆图（论文称 MemGoG）把这些单元组织起来——哪些单元相互支持、哪些彼此冲突、哪些专门用于修复，都被连成图结构。和传统把对话片段或文档整块塞进向量库的做法不同，它强调的是把「一个动作为什么能成立、它产出什么、下游谁要用」这三件套绑在一起存。这样当后续任务需要复用某段经验时，取出来的是一整组彼此咬合的依赖，而不是零散的一句话。论文作者观察到，把依赖分组后，这些单元的留存率与联合检索率都更好。
记忆组织，随每次执行一起进化
MACE 更关键的一点是闭环。它不只把经验存起来，还把「这次选了哪些单元、用什么格式呈现、智能体产出如何、任务结果怎样」一并记下，再据此给单元和关系打分、更新检索优先级。换句话说，组织记忆的方式本身，会随每次执行的结果一起变：被证明有用的组合被抬高，被证明带偏的组合被压低。论文把这种机制称为记忆—智能体协同进化，因为它让记忆的「形态」和「用法」都成了可被反馈优化的对象，而不是上线时定死、之后只增不减的仓库。
在八个基准上，MACE 平均得分 81.11，高于此前较强基线 SAGE 的 78.97，高出约两个百分点。在密集基线区里，这样的差距算不上碾压，但方向值得留意：它暗示比起单纯堆记忆容量，怎么组织与调用记忆，可能更影响多智能体系统的稳定表现。论文也做了组件消融，把记忆、策略或版本化功能单独拿掉，性能就会掉到只满足少量测试的水平，说明各部分是协同生效，而非某一项单兵突进。
把这类方法放回日常构建，它的启发比分数更实用：如果你的多智能体系统每次都从头检索一大坨记忆，不妨先问「我存的是片段，还是存的是带依赖的单元」。不少团队花力气扩记忆容量，却没花力气组织记忆结构，结果检索越做越慢、噪声越灌越多。MACE 给出的思路是，先把「一个动作成立需要什么」绑成一组，再用执行结果去给这组打分，往往比无脑扩容更划算。
当然要留几分清醒。这类方法的地基是协作轨迹本身真实可信——如果记下来的「经验」来自带着错误假设的运行，那么组织得再漂亮，也只是把偏差更高效地带进下次任务。MACE 侧重的是记忆组织机制，至于轨迹从哪来、怎么保证可信，是另一层面的工程问题。对构建者而言，它的启发是：做多智能体记忆时，与其纠结存多少，不如先想清楚存成什么结构、用什么反馈去更新。把依赖关系打包、让检索优先级随结果流动，往往是比「越大越全」更划算的改进方向。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
总体看，MACE 把「记忆该怎么长」这个问题摆到了台面：与其让经验只增不减地堆积，不如让它在每次执行后重组。两个百分点的领先不算惊人，但它指出的方向——记忆组织比记忆容量更关键——值得多智能体系统的设计者认真掂量。对构建者，最实在的落地点是先检查自家记忆是按片段存还是按依赖存，再决定要不要扩容——往往重组结构比堆容量更划算。