为什么模型不能直接写 Graph：Proposal、人工审核与独立执行的分权设计

让模型直接生成 Cypher 并写入 Neo4j，是最短的 Graph Agent 路径，也是最难审计和恢复的路径。

问题不只是模型会不会写错语句。真正危险的是：谁批准了这个业务事实、它依赖哪一版 Evidence、提交后进程崩溃时到底有没有写成功、重试会不会重复创建关系，以及一个 node delete 是否会悄悄级联删除其他产品数据。

Agent Foundation 对 Graph 写入采取的原则很明确：

模型和产品调用方可以提交有边界的 Graph Proposal，但不能直接拥有 Graph effect authority。审批与执行分离，真实 mutation 由独立 executor 完成。

技术解释图：record、submit 和 review 阶段保持 Graph 零写；独立 executor 才能执行，并通过 exact marker 处理未知结果。

查看 Agent Foundation 项目总览 · 打开本文交互图

第一步：把自然语言变成有上限的 typed operations

Graph Proposal 不是任意 Cypher 文本，而是一组有序、类型化、受预算约束的 operations，例如 node create/update/delete 和 relation create/delete。Registration 冻结：

• operation 数量上限；
• 单 operation 字节上限；
• proposal 总字节上限；
• 允许的 operation kinds；
• proposal_only 或 review_required policy；
• exact Evidence 和 Graph baseline 要求。

这样做的目的不是限制表达能力，而是让系统可以在执行前确定性验证影响范围、排序和幂等 identity。Foundation 不接管产品 ontology；每个 operation 的业务意义仍由 adopter 决定。

第二步：绑定 Evidence 和完整 Graph baseline

一个 proposal 必须绑定精确 Evidence revision，而不是“某份文档的最新版”。它还需要记录当前项目 Graph baseline，包括 Registration、Provider、policy fingerprint 和 Graph revision。

submit 时，Authority 会重新读取 Evidence 和 Graph binding。如果 Evidence 已 superseded、revoked，或者 baseline 已漂移，proposal 不能继续进入可执行状态。

这一阶段的关键证据是：record 与 submit 都不写 Neo4j。 它们只形成 Proposal authority 内的审计事实和状态转换。

第三步：审批人与执行人不是同一角色

在 review_required 模式中，实际 human reviewer 通过认证 principal 审批冻结 action。请求体不能自报 reviewer 覆盖认证身份；reviewer 与 represented business owner 可以不同，但二者都会进入审计事实。

ReviewDecision 是不可变且唯一可执行的。后来的否定、过期或重新评估不会原地改写旧决定，而是形成新的生命周期事实。

更重要的是，reviewer 的操作只会：

1. 写入 immutable ReviewDecision；
2. 把批准的 frozen proposal 放入 durable outbox；
3. 返回 approved; not applied。

reviewer 不持有 Neo4j 写权限，也不会在 HTTP 审批请求中同步执行 Graph mutation。

第四步：独立 executor 承担真实副作用

Executor 使用独立 effect scope，从 PostgreSQL outbox claim 一条可执行 proposal。普通 Python SDK 不暴露 apply()，产品 Agent 也不能把自己升级为 executor。

执行时，Neo4j adapter 在一个 transaction 中完成：

• 写入 exact operation marker；
• 执行全部业务 mutations；
• 更新 degree projection；
• 推进 Graph revision。

任一 operation 失败，整个 Neo4j transaction 回滚，marker 也不会残留。node.delete 不做隐藏 cascade；相关 relation 必须在 proposal 中显式删除，否则操作被拒绝。

两种原子性，而不是虚构跨存储 ACID

Graph Proposal 同时使用 PostgreSQL 与 Neo4j，二者之间没有跨存储 ACID transaction。

它真正提供的是两种本地原子性：

两者之间的未知结果由 reconciliation 处理，而不是靠分布式事务的口号掩盖。

如果 Neo4j 已提交，但 executor 崩溃了怎么办

这是 Graph 写入最容易被普通重试逻辑破坏的场景：Neo4j 可能已经提交，但 PostgreSQL receipt 尚未写入。此时如果直接重试，可能重复创建实体或关系。

Foundation 会让 proposal 进入明确的 recovery 状态，并检查 exact operation marker：

• marker 存在：说明 Graph transaction 已提交，reconciler 补写 PostgreSQL receipt；
• marker 不存在，且 Graph baseline 未变化：可以使用原 proposal identity 安全重试；
• marker 不存在，但 baseline 已变化：标记 stale 或需要重新规划，不能盲目重放。

Executor lease 也可以被回收。一个进程在 durable applying 状态后退出，替代 executor 会先执行 lease sweep，再按同一 identity 收敛，而不是创建第二个 proposal。

Evidence 后来失效，已经应用的 Graph 怎么办

Evidence revoke 不等于自动删除 Graph 历史。自动 inverse、级联删除或“恢复到模型认为的上一个状态”都可能制造更大破坏。

Foundation 把 Graph element 的存在与安全投影分开：Evidence 失效会关闭依赖该证据的当前安全投影，并阻止新的相关效果；已经应用的 element 和历史 marker 保持可审计。恢复需要新的 Evidence 和显式 remediation decision，例如在 owner/reviewer 确认后保留当前 revision。

这条路径不自动重放 Neo4j，也不把旧 ReviewDecision 改成“从未批准”。它用新的审计事实表达后续判断。

一个真实 adopter 为什么仍然需要业务适配器

Foundation 只理解公共 operation contract，不拥有 TraceWise 或 TeachFlow 的 ontology。采用方仍需把产品内的业务候选转换为：

• 稳定 entity/relation identity；
• 合法 operation 顺序；
• no-hidden-cascade 的删除集合；
• exact Evidence revision；
• 当前 Graph baseline；
• actual actor 与 represented owner。

TraceWise 的 Stage A 适配器就承担这层确定性转换，同时切断 future opt-in Graph 的 legacy direct apply、产品侧 ReviewDecision execute、旧 sync retry 和 direct rollback。Foundation 提供权威机制，产品负责业务语义，两者缺一不可。

当前验证到了哪里

当前本地证据包括：真实 PostgreSQL 16 + Neo4j 5.26 的 outbox → apply → receipt 路径；Graph 已提交但结果未知后的 marker receipt 修复；Neo4j 中途失败时 mutation 与 marker 同时回滚；immutable ReviewDecision 数据库守卫；executor 进程退出后的 lease sweep 与安全重试。

这些结果证明了机制在限定环境中可执行。它们不证明跨存储 ACID、生产 IAM/TLS、HA/DR、生产容量、大型 Graph 性能，也不证明模型提出的 Graph 变更在业务上一定正确。

最后的判断

“模型能生成 Graph 变更”只是候选生成能力；“产品可以长期信任这次变更”则需要来源、基线、审批、执行、回执和恢复共同成立。

submitter、reviewer 和 executor 分别承担提案、业务判断和真实副作用执行。权威层保存各阶段记录，供后续追溯和恢复使用。