今天,我仔细研究了一下TencentDB Agent Memory与CodeGraph对于图结构的设计,有几点感悟
腾讯的agent memory从“线性聊天历史”变成 Mermaid 任务结构,而CodeGraph从“文件树/源码文本”变成代码知识图
实际上前者使用了时间维度的图,后者使用了空间维度的图,也就是一个是过程图，一个是代码图
双方都在试图将“地图和原文分离”,按需再寻找原文,将短期上下文“从维护摘要历史变成维护任务结构”
在实际使用的过程中,TencentDB Agent Memory的benchmark重点是在某种任务情境下节约了多少token,这与这个项目是围绕openclaw消耗过多的token这个痛点所开发的有关
我们可以看到这两个项目在结构上的设计实际上都偏向于coding的场景
我突发奇想,一旦把这样的记忆系统移植到公司业务agent, "Mermaid 任务结构+ 软状态机质量门控+ refs 原始证据"会不会变得更加的适合于企业 Agent 场景
我按照这个思路搭了一个搭了一个新agent_memory_core,进行了Benchmark 测试,结果如图:
LongMemEval-S显著进步Evidence Source Coverage = 0.87, refs 原始证据这个模块起到了显著的作用,这对公司业务 Agent 特别关键
LoCoMo10 表现差也说明了这样的一个记忆架构更适合有明确 anchor 的任务,如order_id,ticket_id而不是某个人,某件事
BEAM-lite指标很好也说明了抗压能力很好,在 synthetic hard-anchor 场景下，refs + FTS/memory_items 能稳定召回
这些结果暗示这种图记忆系统的架构更适合硬 anchor、强流程、强证据的企业 Agent 场景
以牺牲开放式人物关系型长期记忆为代价显著提高了业务流程上的能力
我们也可以浅显的得到一个结论:符号化短期记忆不适用于openclaw,harness这种弱 anchor、高纠缠度的对话流产品
虽然token的消耗确实降低了,但是长期的效果不见得变好,CodeGraph也是同样的道理
而硬anchor 的任务,也就是企业agent这种场景的agent更适合于图记忆系统的架构
