如果一个 Agent 能调用模型、搜索资料、记住用户偏好，还能更新产品 Graph，它是不是就已经“具备自治能力”了？
我的结论是：还没有。模型可以提出候选，工具可以执行动作，但产品仍然需要回答三件更基础的问题：谁有权把候选变成事实，事实失效后谁负责收敛，真实副作用由谁执行并留下可恢复的回执？
Agent Foundation 就是围绕这三个问题建立的。它不是一个负责分配 Planner、Verifier、Persona 的 Multi-Agent 编排框架，也不接管产品的 Prompt、模型、业务 ontology 或界面。更准确的一句话是：
Agent Foundation 是面向 Agent 产品的受控治理与权威基础层，把 Context、Memory、Evidence、Relation、Graph Proposal 和人工审批组织成可审计、可恢复的生命周期。
查看 Agent Foundation 项目总览 · 打开本文交互图
第一性问题：智能不等于权威
语言模型擅长生成可能正确的内容，却天然不具备产品数据的写入权。即使模型输出了结构化 JSON，也仍然存在四类风险：
- 来源可能已经过期、被撤销，或根本无法证明；
- 同一句自然语言可能被错误分类为偏好、事实、计划或敏感信息；
- Graph mutation 可能影响多个实体和关系，失败后不能靠“再试一次”恢复；
- 调用模型的身份、被代表的业务 owner、审批人和执行人可能不是同一个主体。
因此，Foundation 的核心不是“再封装一个 LLM SDK”，而是把推理和权威拆开：模型负责产生候选，Foundation 负责验证、治理、审批、执行和回执，产品仍然负责业务语义。
技术解释图：这是 Foundation 的完整能力目录，不表示每个 adopter 或 Registration 都会启用全部模块。上层是 Context、Memory 与 Relation 的读取和治理路径；下层是 Evidence、Graph Proposal、ReviewDecision 与独立执行路径。图片不是产品运行截图。
Foundation 实际拥有六类能力
1. Context Runtime：只返回有边界的上下文
Context 不是“把数据库全部塞进 Prompt”。Runtime 根据 Registration、principal 和 capability 读取有界上下文；可选 provider 失败时可以返回 typed degraded，但身份或权限失败不会被伪装成普通降级。
2. Memory：治理生命周期，而不是保存聊天全文
Memory 候选来自 Observation 与 Formation。安全的低风险偏好可以按冻结策略自动应用，敏感、冲突、不确定或生产环境候选进入 owner review。批准后的 Memory 才能进入后续 recall；拒绝的候选保留审计事实，但不会成为可召回记忆。
3. Evidence：记录可追溯来源，而不是可变附件
Evidence 使用稳定 lineage 和不可变 revision。新事实通过 successor 表达，旧 revision 可以 supersede 或 revoke，但不会原地改写。这样，Memory、Relation 与 Graph 才能绑定到一个精确来源，并在来源失效后停止继续消费旧结论。
4. Relation：把生命周期和时间投影分开
Relation 可以处于 active，同时因为生效时间在未来而只出现在 upcoming projection。Evidence 支持状态又是另一条正交维度。Foundation 不用一个 active=true 同时表达“历史存在”“当前可信”和“现在可见”。
5. Graph Proposal：模型只能提案，不能直接改图
Graph 写入先被表达为有上限的 typed operations，并绑定 exact Evidence revision 和当前 Graph baseline。提交和审批阶段都不写 Neo4j；独立 executor 才能消费 durable outbox，在一个 Neo4j transaction 中写入 operation marker、业务 mutation 与 Graph revision。
6. Product Recipe 与 Registration：能力必须先被证明再开放
产品通过 Recipe 声明需要什么能力，但声明本身不授予权限。Compiler、accepted Provider Claims 和唯一 Runtime component owner 必须共同成立，Registration Authority 才会形成正式 receipt，并按 actual principal 打开 Agent、reviewer、revalidator 或 executor 的最小权限句柄。
产品与 Foundation 的边界
这条边界决定了平台能否复用，也决定了它会不会变成另一个庞大的业务单体。
| Foundation 拥有 | Adopter 产品保留 |
|---|---|
| Context、Memory、Evidence、Relation、Graph Proposal 公共合同 | 模型、Prompt、业务策略与答案生成 |
| Registration、capability、scope 与 principal 校验 | 业务角色、审批人分配与产品 UI |
| ReviewDecision 生命周期、outbox、receipt 与恢复语义 | 领域 ontology、Graph 业务含义与呈现 |
| PostgreSQL 控制面与 Neo4j Graph authority adapter | 何时提出候选、如何解释结果 |
Foundation 不会因为一个采用方需要 Graph，就自动获得该产品全部 Graph 语义；也不会因为模型“很有把握”，就跳过 Evidence 或人审。
两个真实采用方分别证明了什么
TraceWise 验证的是高级 Graph adopter 路径：产品可以保留自己的复杂分析与业务策略，同时把 Evidence、Graph Proposal、ReviewDecision 和独立执行交给 Foundation 的公共合同。这里证明的是权威分离和可恢复链路，不是模型分析质量提升。
TeachFlow 验证的是 Memory-first 路径：学生作答形成精确 Evidence，学情 Memory 经治理后进入 Tutor 与 Graph Analysis Agent 的个性化输入；Evidence 失效或 successor 尚未重验证时，旧 cue 会立即停止召回，产品不会偷偷回退 legacy Memory。
两者的价值不在于“接入了同一个 SDK”，而在于不同产品策略能够复用同一套权威不变量，同时保留各自业务语义。
为什么采用 PostgreSQL 控制面与 Neo4j 数据面
审批、outbox、lease、receipt 和 reconciliation 需要强约束的控制面；图元素与关系查询则适合图数据面。Foundation 因此没有假装两套存储天然具备跨库事务，而是分别建立两种原子性：
- PostgreSQL 原子保存 decision、outbox、intent 与 receipt；
- Neo4j 原子保存 operation marker、业务 mutation 与 Graph revision。
当 Graph 已提交但 executor 没拿到结果时，reconciliation 读取 exact marker：marker 存在则补 receipt，marker 不存在且 baseline 仍一致时，才允许用原 identity 安全重试。PostgreSQL 与 Neo4j 没有统一事务，恢复依赖 marker、基线检查与幂等身份。
当前证据与明确边界
当前正式基线是本地版本化的 bounded developer preview。源码回归记录为 305 passed、9 skipped，并且已有 fresh installed-package、PostgreSQL 16、Neo4j 5.26、Waku、OpenClaw、TraceWise 与 TeachFlow 的限定切片证据。
这些证据足以说明公共合同和本地机制可运行，但不等于 production-ready。仍未证明的包括生产 IAM、TLS、Secret custody/rotation、HA/DR、生产容量、大型 Graph 性能和真实发布运维。它也没有证明任何模型更准确、答案更好或教学效果提升。
最后的判断
Agent 产品真正困难的部分，不只是“模型能不能做”，而是“模型做出的候选如何成为可以被产品长期信任的事实”。
Agent Foundation 的价值就在这里：它让产品可以自由选择模型和业务策略，却不能绕过 Evidence、权限、人工审批、独立执行和恢复边界。智能可以变化，权威链必须稳定。