Evidence 失效之后：Agent Foundation 如何让 Memory、Relation 与 Graph 安全收敛

多数 Agent 系统在“写入”时很谨慎，却很少回答另一个更难的问题：支撑一条 Memory、Relation 或 Graph 结论的 Evidence 后来失效了，系统应该怎么办？

如果只是把 Evidence 标记为 revoked，而下游仍然继续召回旧 Memory、展示旧 Relation、执行依赖旧证据的 Graph 操作，那么撤销只是数据库里的一行状态，并没有改变产品行为。反过来，如果一收到撤销就删除所有下游内容，又会破坏审计历史、误伤仍有其他证据支持的结论，也无法处理 PostgreSQL 与 Neo4j 之间的未知结果。

Agent Foundation 对这个问题的处理原则是：

Evidence 的生命周期变化，必须先让依赖它的效果停止被当作当前可信结果消费；历史记录保持不可变，恢复则通过新的、显式的审计事实完成。

这篇文章聚焦这一条机制。它不讨论模型是否更聪明，也不把 Foundation 描述成接管产品业务的通用 Agent 框架。

查看 Agent Foundation 项目总览 · 打开完整交互图集

先把四种状态分开

根因往往不是“少写了一个 revoke handler”，而是系统把四种不同状态揉成了一个布尔值：

1. Evidence lifecycle：某个精确 revision 是 active、superseded 还是 revoked。
2. Target lifecycle：Memory、Relation、Graph Proposal 或 Graph element 自己处于什么业务状态。
3. Support projection：当前证据集合是否仍满足目标所绑定的 policy。
4. Review / execution lifecycle：一个已经审批或执行过的动作，后来是否需要重新确认。

Evidence 被撤销，并不等于目标历史不存在；一个 Graph element 仍然存在于 Neo4j，也不等于它仍然可以作为安全投影返回。Agent Foundation 因此没有把“撤销 Evidence”实现成“级联删除所有目标”，而是单独计算支持状态，再决定读取与效果型操作是否可继续。

交互技术解释图：Evidence 生命周期、目标生命周期、支持投影和恢复动作彼此独立；图片不是产品运行截图。点击可缩放、切换主题并导出。

依赖不是一个外键，而是一份可执行合同

每条依赖绑定精确的 Evidence revision，而不是只记一个文档 ID 或内容哈希。它还包含 role、policy、目标类型和目标 generation。这样，系统才能区分“这条证据消失后结论必然失效”和“它只是上下文，消失后仍可继续”。

当前合同定义了四种角色：

这里有一个容易忽略的边界：调用方提交的 confidence 或 weight 不是 Foundation 的最终权威。支持资格由冻结 policy 与精确 Evidence 状态计算，避免 adopter 临时调高权重绕过治理。

从 AF-ER03 开始，这份合同进一步变成 target-scoped profile：Memory、Relation、Graph 分别绑定允许的 policy、target kinds 和真实 Foundation adapter。一个 Graph-only Recipe 不会因为需要 Evidence dependency，就顺带获得 Observation、Memory 或 Relation 权限。

关键顺序：先同步保护，再异步收敛

如果撤销事件只投递到队列，而队列消费前旧 Memory 仍能被召回，就会留下一个真实的安全窗口。Agent Foundation 因此把保护动作拆成两个时序不同的部分。

第一步是同步完成：Evidence supersede 或 revoke 与 lifecycle event、dependency fence、durable outbox 在同一个控制面事务中形成。读路径和效果型路径会先看 fence 与最新支持投影，而不是等待后台 worker 跑完。

第二步才是异步收敛：outbox 分页列出 dependent，Memory、Relation、Graph 各自的 revalidator 读取精确依赖集，使用 CAS 更新支持投影和 receipt。扇出有明确上限，失败任务可以重放、租约可以回收，但不能跳过同步保护门。

交互技术解释图：同事务围栏先关闭不安全消费，持久化任务随后让不同目标权威有界收敛。点击可查看完整路径并导出。

这也解释了为什么系统需要区分读和写：

protected empty 不是普通的“没有记忆”。它表达的是：系统知道存在候选内容，但当前证据不足，因而有意不返回。这使采用方可以向用户展示准确状态，而不是偷偷回退到 legacy store。

Memory：立即停止召回，恢复必须是显式动作

在 Memory 路径中，最重要的验收不是“后台任务最终把状态改对”，而是 Evidence supersede 后的下一次 recall 已经看不到旧 cue。

已验证的 installed-package 流程包括：注册 Product Runtime、录入精确 Evidence、治理并审核 Memory、成功召回、supersede Evidence、同步阻断旧召回、worker 收敛、提交同 lineage successor、CAS revalidation，以及恢复召回。

恢复有三条硬边界：

• successor 必须属于同一个 Evidence lineage，并且是当前 active 的精确 revision；
• revalidator 必须提交预期 support projection version，避免并发覆盖；
• 不同 lineage 的新证据不能自动继承旧治理结果，必须形成新的 governance。

这比“把旧 Memory 重新设为 active”多了一些步骤，但换来了可解释性：恢复是谁触发的、使用了哪条 successor、基于哪个旧投影、是否发生并发冲突，都能进入 receipt，而不是隐藏在一次数据库更新里。

Relation：时间投影与证据投影不能混为一谈

Relation 自身可能是 current、upcoming 或 historical；Evidence 支持状态则可能是 eligible、partially supported、blocked 或 pending revalidation。这两个维度必须正交。

例如，一条未来关系即使经过 owner review，仍然只是 active + upcoming，不会出现在默认 current projection。它后来失去 required Evidence 时，Foundation 关闭的是安全投影，不会把原始 candidate、ReviewDecision 或时间历史改写掉。提交明确 successor 后，Relation revalidator 才能生成新的支持投影。

同样，Relation dependency 不会隐式升级为 Graph 权限。是否进入 Graph Proposal，仍取决于 Registration 中显式选择的 capability 和独立治理流程。

Graph：保护的不是抽象 proposal，而是每个已应用元素 revision

Graph 的难点在于：proposal 已经审批，Neo4j 也可能已经写入；这时 Evidence 才被撤销。简单回滚既可能删错数据，也可能在跨存储未知结果下制造第二次错误。

Agent Foundation 把依赖追踪到多个层级：proposal generation、每个 operation、applied operation，以及最终 graph element revision。每项被保护的操作都需要能够映射到 exact marker、resulting Graph revision 和 Evidence bindings。一个 proposal 批次在 record、review 和 apply gate 上保持全有或全无，避免只放行其中一部分操作。

Evidence 失效后，已应用 Graph 历史仍保留，但当前安全投影关闭，并生成 owner-action remediation。恢复不是自动写 Neo4j，而是重新确认“当前这个 element revision 是否可以在 successor Evidence 下继续保留”。

如果 reviewer 选择 retain_current_revision，Foundation 会验证 exact successor dependency set，并追加新的审计事实；当图本身无需变化时，不产生新的 Neo4j mutation。若业务语义确实需要变化，则进入新的 Graph Proposal，而不是让 revalidator 擅自推导 inverse operation 或 cascade delete。

为什么不直接删除

“Evidence 已撤销，所以删除所有内容”看起来最彻底，实际上混淆了合规处置、业务历史和当前可用性。

第一，目标可能仍被其他 supporting Evidence 支持。第二，ReviewDecision、apply receipt 和 Graph marker 是解释“系统曾经为什么这么做”的审计事实，原地改写会破坏可追溯性。第三，PostgreSQL 控制面与 Neo4j 数据面不具备跨存储 ACID；未知结果需要通过 exact marker 和 baseline reconciliation 收敛，而不是盲目补偿。第四，dependency revalidator 的权限只覆盖支持状态收敛，不能越权决定内容处置。

Evidence 内容本身的删除或脱敏不属于 dependency revalidator 的职责，需要独立的处置授权与合同；当前基线也没有实现自动擦除。因此这里采用的是“停止继续持有不安全效果，保留不可变历史，并以显式新事实恢复”。它比物理删除更保守，也更符合多权威系统的真实失败模式。

证据到哪里，结论就说到哪里

当前正式基线是 AF-RA01，包线为 agent-foundation==0.1.0a20.post16 与 tracewise-memory==0.1.95。当前源码回归记录为 305 passed, 9 skipped。Evidence dependency 的关键切片还完成了：

• fresh、non-editable、无 PYTHONPATH 的 installed-package Memory 全流程；
• PostgreSQL 16 中 event/fence/outbox 原子回滚、并发 successor/revoke、SKIP LOCKED job claim 和 lease reclaim；
• SQLite Relation/Graph 垂直链路；
• 真实 PostgreSQL 16 控制面与 Neo4j 5.26 数据面的 Relation/Graph 垂直链路；
• applied Graph element 的保护、successor remediation 和无 Neo4j mutation 的 retain_current_revision。

这些证据支持“本地、已版本化 developer preview 的机制可运行”，不支持以下更强结论：

• 不代表 production IAM、TLS、Secret custody、tenant isolation、HA/DR 已完成；
• 不声称 PostgreSQL 与 Neo4j 跨存储 ACID；
• 不包含任意 legacy 数据的自动迁移或 Evidence 内容自动擦除；
• 不证明模型答案、教学效果或业务指标得到提升；
• 不代表所有采用方已经完成切换或包已经公开发布。

结语

Evidence governance 的价值，不是多保存一张来源表，而是让“证据发生变化”真正改变下游行为。Agent Foundation 的选择可以概括为三步：精确绑定、同步保护、显式恢复。

这套设计牺牲了“一键撤销后自动修好一切”的表面简洁，换来的是更清晰的权威边界：Memory 不再召回失去支持的 cue，Relation 不再把失效关系当作当前投影，Graph 不再用自动回滚掩盖跨存储不确定性。对需要长期记忆、人工审核和可解释图谱的 Agent 产品来说，这种保守不是额外负担，而是系统能被信任的前提。