不是所有聊天都该变成记忆：Agent Foundation 的 Memory 治理边界 / YM

很多 Agent 的“长期记忆”实现，看起来只差一个写接口：模型抽取出一句偏好，然后存进数据库。真正危险的地方恰好也在这里——模型生成的候选、用户真实表达过的内容，以及系统有权在未来继续使用的记忆，并不是同一件事。

我在 Agent Foundation 里把这三件事拆开了：

模型可以提出候选；
治理层必须重新证明候选来自哪一次完整表达；
只有满足策略或经过 owner review 的 Formation，才能变成后续可召回的 Memory。

这个设计没有提高模型智力。它解决的是另一个更基础的问题：谁有权把什么内容，按什么期限，写成未来会影响模型行为的语义状态。

第一条原则：`after_model` 不等于“允许写入”

Agent 的一次普通调用分为两类动作。

after_model(...) 只把 typed Observation 送入确定性 representation planning。它可以判断候选可能属于 preference、fact 或 Relation proposal，却不会调用 Memory admission、ReviewDecision 或 Graph apply。这里的副作用报告必须为零。

真正的首个语义权威写入边界是：

runtime.govern_memory(turn, *, observation, route)

这个接口不会直接相信调用者传入的 route。它会从 Observation、Registration、scope、policy lineage 等持久化事实重新计算规划结果，并要求 fingerprint 精确一致。只要形成路径发生漂移，系统就 fail closed。

这一步很重要，因为它把“模型觉得应该记住”与“系统已经获得写入授权”隔离开了。调用模型本身不再隐含数据库写权限。

技术解释图：生产候选默认进入 owner review；本地自动应用只是满足全部安全谓词后的受限短路。交互版可按治理主链、安全短路和拒绝边界逐层查看。

“来自用户”必须精确到完整表达

最小反例是：

I do not prefer dark mode.

如果候选抽取器只做子串匹配，它可能从中截出 “I prefer dark mode”，然后把否定句变成正向偏好。这不是普通的抽取误差，而是来源权威被破坏：系统记录了用户没有表达过、甚至明确否定的内容。

因此，personal-safe 的自动路径要求候选由完整、精确的 owner utterance 支撑。允许规范化空白或稳定格式，但不允许：

子串截取；
改写或摘要；
截断；
从多个句子拼接出新语义；
在 lineage 不完整时猜测来源。

同样，uncertain future plan、普通事实、冲突内容、敏感内容和模型自行扩写的结论都不会进入自动应用。

为什么生产环境一律 review required

本地开发环境确实存在一个自动应用分支，但它不是“模型置信度足够高就自动写”。必须同时满足：

sealed、single-owner 的 local_development；
新的 preference，来源为 user_statement；
asserted、current、cross-session；
normal sensitivity；
owner-explicit；
完整精确的 owner utterance；
Registration、scope、policy 与 formation route 全部一致。

缺一项都不会自动应用。

production_bootstrap 则更简单：所有候选都进入 owner review。 即使模型把健康、位置或联系方式错误标成 normal preference，也不能越过审核门。这不是因为模型永远不可信，而是因为生产环境中“是否允许长期持有并继续使用”必须由业务 owner 的明确决定承担。

ReviewDecision 审批的是冻结 Formation

审核不是对一段可变化的自然语言说“同意”。reviewer 的目标是持久化的 memory_formation：它冻结 action、target generation、candidate identity 和相关 lineage。

审批时，FormationApplication 会重新读取持久化 run 与 draft，再执行已经冻结的 action。这样可以避免两个常见问题：

reviewer 看到的是 A，执行时却应用了后来变化的 B；
调用者伪造一个新的 payload，借已有 ReviewDecision 写入不同内容。

提案者与 reviewer 的 scope 也被分离：

memory:propose 只能提交候选；
memory:review 只能审核 Memory Formation 并读取对应治理状态；
reviewer 不能因此获得 raw Memory write、Relation 审批或通用 ReviewDecision 执行能力。

幂等不是“什么都不记录”

治理系统需要区分两种重放：

exact replay：返回稳定 receipt，不产生任何新增写入；
新的 semantic duplicate：可以保留新的 Observation/Formation 审计，但不能新增或修改 Memory。

这是一个容易被忽略的边界。完全不记录新的输入，会失去审计线索；每次都重写 Memory，又会把幂等变成伪命题。receipt 因此分别报告 Observation、Formation 和 Memory 的副作用，而不是用一个笼统的 write_performed 掩盖差异。

等待审核的 submission receipt 也不会被原地修改。后续状态通过稳定 governance_id 返回新的 linked projection，其中包含 prior receipt fingerprint 和 ReviewDecision receipt。历史证据保持不可变，当前状态通过投影表达。

被撤销的 Evidence 不能继续支撑 Memory

一条 Memory 被批准并不意味着它永远有效。后续的 Evidence dependency safety 把 exact Evidence revision 与 target generation 绑定起来：

Evidence supersede 或 revoke 后，读取路径立即进入 protected empty；
旧 Memory 不会继续进入 before_model；
durable revalidation worker 负责收敛依赖状态；
只有显式 exact successor revalidation 通过后，新的 revision 才能恢复 recall。

这里没有级联删除，也没有把旧 ReviewDecision 原地改写。历史上“当时为什么批准”仍然可审计；当前是否还能使用，由 dependency projection 决定。

真实验证覆盖了什么

这条链路不是只写在 ADR 里。accepted developer baseline 的相关验收包括：

source regression：285 passed, 9 conditional skips；
真实 PostgreSQL 16：12 passed, 3 deselected；
fresh、non-editable、无 PYTHONPATH 的 installed-wheel vertical workflow；
Registration 与 scoped handle；
Evidence admission；
Memory govern / review / recall；
supersede 后立即保护；
durable worker convergence；
exact successor revalidation 后恢复 recall；
503 authority outage 与负向 principal 边界。

这些结果证明的是本地、受限、可复现的治理机制，不是生产 IAM、TLS、HA/DR 或模型质量证明。

我最终保留的设计判断

长期记忆不是一个更方便的 prompt cache。它是一种会跨会话影响未来行为的语义权威，因此需要比普通日志更严格的来源、身份、审核与失效语义。

Agent Foundation 的做法可以概括为四句话：

模型只提出候选，不自动获得写权限；
候选必须重新绑定完整、精确的来源；
生产环境默认由 owner review 决定是否应用；
Evidence 一旦失效，旧 Memory 立即停止进入后续上下文。

这套机制的价值不在于“记得更多”，而在于系统能解释：为什么记、谁批准、依赖什么，以及什么时候必须停止使用。

边界

抽取覆盖与最终答案质量需要独立数据评测。本地 auto-apply 不用于生产；生产 IAM、密钥托管、TLS、HA/DR 与容量仍需接入和验证。Memory review 的授权范围限于 Memory，不授予 Relation、Graph Proposal 或 Graph apply 权限。

第一条原则：after_model 不等于“允许写入”