评估与实现边界

用可复现的任务验证记忆质量、治理与失效传播，并区分设计和交付。

概念参考约 4 分钟

PersonOS 的评估目标包括记得是否正确、状态是否仍有效、证据能否核对，以及内容是否在允许的范围内使用。一次检索命中或一项问答分数，只能说明其中一部分能力。

本文档描述框架设计与契约，不表示所有机制已经在同一实现中完整交付。完整的 Fact/Event 归一化、双时间账本、场景维护、意图假设、离线巩固与运行时回滚，都需要对应实现和独立验证结果。

按机制核对实现范围#

设计文档说明问题与契约，代码说明某一版本采用了什么路径。不同实现可以共享概念而采用不同的组织和检索阶段。下表帮助阅读两者的对应关系，不是某个发行包的功能承诺。

已有实现中可见的机制	它解决的问题	仍需独立验证的设计要求
证据、情节与原子关联	保留原文，以细粒度线索找到完整材料。	每个结论的逐句证据精度、主体归属与语义完整性。
事项链与派生画像	关联前后陈述，整理便于当前使用的概览。	完整有效区间、历史知识查询、跨对象失效传播与回滚。
多路召回、材料组装和回答核对	寻找相关经历，检查结论是否得到材料支持。	全部用途、接收方、敏感范围与行动上限是否被实际执行。
后台画像更新	有界地更新派生视图。	覆盖全部对象的 Dream Cycle 变更审核、恢复与删除重建。

维度	需要检查的行为
内容与归属	是否保留重要条件，是否把第三方或助手内容误记为用户事实。
状态与时间	能否回答历史状态与当前状态，是否继续使用已失效前提。
证据	引用是否真实支持结论，是否能定位原文或媒体局部。
治理	是否遵守接收方、目的、敏感范围和行动上限。
纠错与删除	变更是否传播到索引、视图、上下文包和运行时投影。
消费效率	在准确性不被掩盖的前提下，记录上下文长度、延迟和补充询问。

评测材料应包含跨会话的新增、修正、取消和不确定状态。问题需要覆盖直接回忆、跨材料推理、当前状态判断，以及证据不足时的保留判断。测试集不能只由容易抽取的明确陈述组成。

例如一个虚构任务序列可以依次给出“计划学习一门课程”“暂缓报名”“改用另一项安排”，再询问当前计划及变化依据。系统既要保留历史，也要避免继续把最初计划当作待执行事项。

多模态评测应保留原始输入及正确锚点，分别检查转写、局部识别和记忆推理。若测试只使用人工整理的文字摘要，其结果不能被报告成原始图像或音频的端到端能力。

PersonOSBench 的设计把诊断拆成写入、维护与巩固、检索、使用与行动四个阶段。失败报告需要定位错误来自哪里，并检查应该使用时能否召回、不该使用时能否保持沉默。评测协议可以同时包含授权的私有轨、可公开的合成长期轨与后端适配轨，分别报告结果。

在输入、模型和预算可比的条件下，分别移除时间、证据、情境限定、治理或保留机制，观察对应错误是否增加。这样才能判断复杂结构是否带来可测量收益，而不只是增加字段。

比较摘要、向量检索、关系索引或组合方案时，应同时记录准确性、失效记忆使用率、治理违规、成本和延迟。框架的目标可以形成研究假设，但在实验完成前不能写成优越性结论。

可靠性测试还应包含写入后响应丢失、重复请求、来源在审核期间变化、授权撤回、索引尚未更新及外部删除结果未知。每个场景需要可观察的状态与明确判据，尤其要避免“排队成功”被当成“记忆已生成并验证”。

自动校验可以证明字段、引用位置或状态转换满足约束，不能单独证明叙述完整、归属正确或语义无损。语义审读和程序检查应分别报告；同一模型的再次复核也不等于独立于模型偏差的证明。

验证记录应说明使用的实现版本、输入来源、样本规模、是否为合成数据、模型与预算、通过判据和未覆盖项。模型替身测试、真实模型实验、服务联调、设备验收和生产部署分别回答不同问题，不应互相代替。

Context 等产品的可用能力以其版本、配置和部署结果为准。一个产品验证通过的流程可以作为框架实现案例，但不能推导其他平台、其他数据源或整个生命周期已经验证。