Agent Memory Evaluation / Semantic Contract
统一评测与选型
不同的 Memory 方法、Benchmark 和结果来源，都会以自己的方式记录事实。评测语义契约把这些事实组织成共同的阅读语言，让同一份运行证据既能用于评测，也能用于有条件的方法选择。
契约不是把方法做成一样，而是让不同方法产生的证据能够被放在同一张评测地图上理解、比较和复核。
契约如何把不同来源放到一起
来源可以不同，格式可以不同，实现也可以不同；统一的是这些内容在一次评测中扮演的角色，以及它们之间真实发生的关系。
保留方法自己的状态、Trace 和运行方式。
保留原始数据、案例身份和参考答案。
记录这份结果从哪里来、属于哪次运行。
Adapter 理解来源；它不替来源重写实现，也不凭空补造证据。
契约把原始事实翻译成工作台和评测流程都能读取的共同语义。
沿关系查看内容从哪里来、经过了什么步骤。
用同一份结构化证据执行评分、核对和复核。
在明确任务和运行条件下比较方法是否合适。
它在评测中是什么
区分 Context、Memory item、模型输入、回答、参考答案和评分。
它是哪一次运行中的什么对象
关联 Experiment、Attempt、Case 和具体结果来源。
这条记录到底记录到了什么程度
区分已记录、明确为空、未记录、失败和 partial。
事实从哪里取得
保留原始文件、调用、Trace、版本和 Adapter 解释。
内容如何被消费和产生
用轻量 PROV 表达 used 与 wasGeneratedBy，不凭字段并列自动连线。
同一份记录，先让评测变得可比较
最终分数只是结果的一部分。统一契约让评测能够同时看到回答表现、运行条件和形成结果的过程证据。
比较的对象不只是方法名称
一次可解释的比较需要同时记录 Benchmark、Memory 方法、回答模型、Prompt、上下文预算、检索深度、数据版本和评估协议。相同的名称，不代表相同的运行条件。
结果要能够沿链路回看
从原始 Context，到 Memory 的构造与检索，再到模型实际输入、回答和评分，使用者可以回到具体内容，而不是只接受一个汇总数字。
在明确的 Benchmark、模型、配置和评估协议下，这个方法表现如何？这条结论使用了哪些证据，又有哪些内容没有被记录？
从可比较的证据，走向有条件的选型
选型不是寻找脱离条件的“最佳方法”，而是根据任务需要、运行约束和可获得证据，判断哪个方法更适合当前场景。
需要长期记忆、简单检索，还是复杂的交互状态？
模型、Prompt、预算、检索设置和数据版本是否可比？
方法实际保存、检索和注入了什么，过程是否完整？
在当前条件下选择方法，并保留调整配置的依据。
理解机制
核验方法实际保存、更新、检索和进入模型输入的内容。
比较条件
确认不同结果是否在相同或明确可解释的运行条件下产生。
辅助迭代
把配置调整关联到过程证据，而不是只根据总分猜测原因。
数据生产和评测消费，各自保持清楚
统一语义不等于统一实现。MemoryData 在来源边界完成适配，让已有的 Runner、Harness、Memory 插件和 Benchmark 继续负责产生原生事实。
按照原生方式运行，并保存真实状态和 Trace。
读取统一契约，进行理解、比较、复核和选型。
接入新方法不再意味着重新制作一套页面；增加新的评测方式，也不需要重新猜测每个结果文件的含义。新的来源只需要说明：有哪些事实、它们扮演什么角色、由什么步骤产生、被什么步骤使用，以及哪些内容没有被记录。