夜雨聆风
你有没有遇到过这种情况——你让两个AI Agent合作完成一个任务，一个说"用户预算500万"，另一个说"用户预算300万"。
你去看它们共享的记忆库，里面只存了最后说话的那个Agent的记录。300万。
500万那条去哪了？被覆盖了。不声不响地消失了。
你甚至不知道它曾经存在过。
这不是你的Agent不靠谱。是你给它们设计的记忆系统，在帮倒忙。
上周，一篇叫StateFuse的论文把这个被所有人忽略的问题摆到了台面上。论文的结论很简单：当多个Agent产生冲突信息时，你不应该覆盖冲突——你应该保留它。
你的记忆系统在设计上就错了
现在几乎所有多Agent系统的记忆层，用的都是同一个套路：后来者覆盖先行者。
Agent A发了一条"客户预算500万"。Agent B后来发了一条"客户预算300万"。
系统说：好的，300万。
然后你的第三个Agent基于300万做决策，出了错。你排查半天，以为是Agent推理有问题。其实不是。是它的"眼睛"被蒙上了——它根本不知道曾经还有过500万这个可能性。
有个词叫"last-write-wins"。中文翻译过来就是"最后一个写的赢"。
这不叫记忆。这叫失忆。
StateFuse的三位作者在论文里说得更狠：坍缩冲突（collapse disagreement）的内存系统，会让Agent在"错误确定性"下做决策——它以为自己掌握了全部事实，其实掌握的是被阉割过的真相。
他们做了一个实验。50个任务，让Agent在冲突环境中做决策。用传统坍缩内存的Agent，验证后成功率只有60%。40%的动作带着错误确定性——它不知道自己在错。
而用StateFuse保留冲突的Agent，验证后成功率100%。因为它看到了所有矛盾，在不确定的时候选择了停下来确认。
错误的自信，比不确定更危险。
一个好用的笔记本，不是只记最后一笔
StateFuse的核心思路，用一句话就能讲清楚：把CRDT的思想从协同编辑搬到了Agent记忆。
CRDT是什么？如果你用过飞书文档或者Google Docs，你就在用CRDT。多人同时编辑同一行文字，系统不会让后来者覆盖先来者，而是保留每个人的修改，让你看到冲突，然后你来决定怎么合并。
StateFuse把这个思路用到了Agent记忆上。不是发明了什么新算法——它建在标准的OpSet/CRDT合并机制上——而是在上面加了一层"Agent能看懂"的语义层。
这一层不复杂。就四个东西：
Evidence（证据）：信息的来源记录。谁说的，什么时候说的。
Claim（主张）：每个Agent提交的认知原子。包含值、置信度、时间戳。每个Claim都有两个身份证——claim_id（精确的本地标识符）和claim_ref（语义句柄，跨副本稳定）。
Retraction（撤回）：定向失效某个之前的Claim。不是删除，是标记为"已撤回"。
Decision（决策）：计划和执行的元数据。永不改变真实状态。
你看，这套设计和你用的笔记本很像。
你在笔记本上写了一行"预算500万"。后来发现搞错了，你会在旁边补一行"错了，是300万"，然后在500万上画条横线。
你不会拿涂改液把500万完全涂掉。因为你需要知道：第一，你犯过这个错；第二，什么导致你犯了错；第三，下次怎么避免。
StateFuse做的事，就是让Agent的记忆也有这根横线。
关键不在存什么，在什么时候做决定
StateFuse有一个特别反直觉的设计：它不是在你写数据的时候解决冲突，而是在你读数据的时候。
传统内存系统在"写入时"就决定了一切——后来者覆盖先来者。冲突在写入那一刻就被消灭了。
StateFuse把冲突处理推迟到了"投影时"。你可以把它理解成：数据永远按原始形态存储（不可变历史），只在需要做决策的时候，由解析器（resolver）来看一遍所有冲突，选一个答案、或者选择"我不知道"。
这就好比你去医院做体检。
传统做法是：检验科直接给你一个"健康"的结论，所有异常指标都被自动化处理掉了。你什么都不知道。
StateFuse的做法是：检验科给你完整的报告，每一个异常项都标红。你的主治医生（解析器）看着报告做判断。有的指标医生说"没事"，有的医生说"这个得查查"，有的医生说"这个结论我还不敢下"。
保存所有数据，把选择权留给决策者。
论文里有一个数据把这个差别讲得很清楚。在282道题的标准Agent记忆测试中，冲突保留面（包括StateFuse）的冲突召回率是100%——所有矛盾都对Agent可见。而坍缩面和原始日志面的冲突召回率是0%——Agent完全不知道有过分歧。
不是准确率的问题。所有方法在不弃权的激进模式下准确率都差不多（97.5%）。
是"知道自己在不知道"的程度不同。
当你切换到保守模式（允许Agent说"我不确定"），区别就出来了：保留冲突的Agent准确率降到64.9%，因为它诚实地弃权了。坍缩面的Agent虽然表面还是97.5%，但这97.5%里有大量的"不知道自己在错"。
在错误上自信，比弃权本身更致命。
那个被忽略的双重身份证设计
StateFuse给每个Claim配了两个身份证这件事，很容易被人一眼扫过。但这是整篇论文最精妙的地方。
claim_id是精确的本地标识符。比如"A-001"。
claim_ref是语义句柄，从Claim的关键词和谓词合约推导出来的。比如"客户预算"。
为什么要两个？
因为在实际系统中，精确标识符经常不可用。你从一个Agent分支拿到一条数据，但不知道它的本地ID。你想撤回它，怎么办？
论文做了一个微妙的对比实验。在需要修正已写入信息的13个语义目标场景中：
用claim_id（精确标识符）去撤回——可恢复率0%。因为你拿不到原始ID。
用claim_ref（语义句柄）去撤回——可恢复率100%。因为语义句柄是从内容推导的，跨副本稳定。
给数据加一个从内容本身推导的身份证，比给数据加一个系统分配的数字ID，在分布式环境中靠谱得多。
这让我想起区块链的"内容寻址"。IPFS文件系统用文件内容的哈希值作为地址，而不是"第3号文件"。因为内容不变，地址就不变。
StateFuse的claim_ref用了同样的哲学：不是在外部给数据贴标签，而是让数据自己长出身份证。
这个思路能复制到哪些场景
StateFuse本身是个轻量级Python库，论文也交代得很清楚：它不是来拿准确率第一的，它是来提供一个更安全的内存合约。
但这个思路的价值远不止一个库。
第一，多Agent协作系统。 如果你在用CrewAI、AutoGPT或任何多Agent框架，你的Agent可能在同一个任务的不同分支上运行，收集到相互矛盾的信息。不要让它们互相覆盖。保留冲突，让最终决策的Agent来权衡。
第二，AI编程工具。 一个代码修复Agent可能在分支A上改了一个bug，另一个Agent在分支B上把同一个函数重构了。两个都合理，但冲突。现在的做法是让merge的人头大。保留冲突可以让merge的人清楚地看到：这里有两个冲突的主张，我需要仔细判断。
第三，AI辅助决策。 医疗诊断、金融风控、法律分析——这些场景里Agent之间的分歧不是bug，是最有价值的信息。两个Agent对一个CT片子给出了不同的判断——你不应该选一个覆盖另一个，你应该把两个都拿给医生看。
第四，Agent自我改进。 你的Agent越用越好不是因为记住了正确答案，而是因为记住了自己犯过的错误和矛盾。StateFuse的不可变历史 + 冲突保留，天然支持"从错误中学习"。
你现在就能做的三件事
第一，打开你现有的多Agent系统，看看记忆层是不是"后来者覆盖"。如果是，哪怕只是加一个简单的"保留最近N条冲突记录"的机制，都能让你看到以前看不到的问题。
第二，在Agent的决策输出里增加一个字段："我是否在不确定的前提下做了这个判断"。如果Agent知道自己看到了矛盾但选择了其中一边，让它明确告诉你。这个字段的价值，比你想象的大得多。
第三，去读一下StateFuse的论文原文和代码。论文不厚，GitHub上的库也很轻量。它的价值不在于你直接拿来用，而在于它给你一个思考Agent记忆的新框架：内存不是垃圾桶，是证据链。
好的记忆系统帮你做对的事。更好的记忆系统帮你避免做错事的时候还不知道自己错了。
