单智能体记忆基准，量不到协作里的「该说不该说」
九月二十六日提交的 arXiv 论文 CoMemBench（编号 2609.32192）指向一个被现有基准漏掉的角度：多智能体工作流里的协作记忆边界。现有的记忆基准大多停留在「能不能回忆起某条事实」，多智能体基准又偏向协调与端到端完成度，两者都没怎么量过——在由多个智能体串起来的工作流里，哪些任务相关信息该共享、哪些陈旧、未核验或不兼容的信息必须被隔离。CoMemBench 的做法是从源端依赖图出发，构造八百个跨四个领域的复合工作流，每个节点带本地规范、可核验的工件交接、原生评估器和与之匹配的隔离挑战，把「共享与隔离」这一对矛盾放到多智能体拓扑上系统性地量。
共享与隔离，是一道随拓扑翻转的权衡
论文实验里最值得记住的结论，是一条反直觉的权衡：更宽的上下文确实提升了信息可用性，却会削弱隔离；而系统在不同拓扑下的排名会发生翻转，工件违规也随结构变化。换句话说，多智能体里「上下文越宽越好」是错的——在 A 类拓扑里把信息敞开可能正中要害，换到 B 类拓扑里同样的敞开却会酿成泄露或相互污染。这也解释了为什么很多团队在真实项目里会有这种体感：给智能体更多上下文，有时候它更聪明，有时候它更乱，差别往往不在模型，而在工作流是怎么连的。
把抽象权衡落到真实工作流里
这些权衡不是论文里的玩具，它在真实项目里以很具体的姿态出现。设想一条客服到账单的链路：客服智能体在对话里拿到了用户的私密身份信息，如果这些都毫无保留地灌进共享记忆，下游账单智能体在生成对账单时可能把不该出现的字段带出去，酿成泄露；反过来，若把记忆切得太碎，账单智能体又拿不到前序已核验的优惠资格，只能重新向用户要一遍，体验掉档。CoMemBench 量化的正是这种「传多传少」的边界——它用可核验的工件交接去判定，哪些信息在该节点是必需、哪些在该节点是禁忌，而不是笼统地「都记住」或「都清空」。
为什么这条线值得单独量
把视角拉到真实的长程任务，失败常常不是因为某个智能体「笨」，而是因为信息在交接边界上要么漏了、要么灌爆了。CoMemBench 测量的几个轴——已验证的节点推进、必需交接的可靠性、隔离鲁棒性，以及 Token 成本——恰好对应了工程上最该盯的薄弱环节。对企业而言，一个由十个智能体编成的工作流，其边界面是一智能体的十倍，记忆治理本质上就是拓扑治理：你不仅要决定每个 Agent 记得什么，还要决定它在哪一环把什么传给谁、又不把什么暴露给谁。这条线单独拎出来评，比只报一个召回率有用得多。
它和「共享向量库」思路的根本分歧
这条线还顺手戳破了一个常见的工程错觉：很多人把「多智能体记忆」等同于「丢进一个共享向量库」，谁需要谁去检索。CoMemBench 的拓扑视角提醒，记忆的可见性必须随工作流结构而变，而不是一个全局平铺的池子。同样的工件，在串行链里该顺传，在并行扇出里该各自隔离，在带回环的依赖图里又该按版本收敛；用一把尺子的共享库去套所有拓扑，等于主动放弃了对隔离失效的防护。这也是为什么论文强调「按拓扑治理」——它把记忆从存储问题重新定义成了编排问题。
局限与跟进
当然，CoMemBench 仍是起步：八百个工作流、四个领域只是初版规模，测试模型有限，隔离挑战按匹配方式构造，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。但它把「协作记忆边界」从一句含糊的工程直觉，变成了一个可构造、可评分的对象。和它差不多同期出现的多智能体长程协作、协作增益诊断等基准一起，正在把多智能体评测从「个体强不强」推向「连起来对不对」——后者才是企业真正敢把一整条流程交给智能体的前提。