概念插图：产品保持独立控制面，Foundation 只通过明确连接提供共享能力；这张图用于解释设计意图，不是产品运行截图。
当多个 AI 产品都需要 Context、Memory、Evidence、Relation 和人工审核时，最直接的做法似乎是把这些能力塞进一个统一框架。但平台一旦继续持有模型、提示词、角色、会话和审核界面，就不再是基础能力，而是在悄悄接管产品。
Agent Foundation 解决的不是“如何做一个更大的 Agent”，而是另一个问题：哪些能力可以复用，哪些决定必须留在产品内部。
查看 Agent Foundation 项目总览 · 打开完整交互图集
先决定谁拥有业务事实
平台边界不是组件清单，而是一组所有权判断。
| 责任方 | 持有内容 |
|---|---|
| Foundation | 公共 API、Python SDK、Context 组装、Evidence 校验、Memory 与 Relation 治理，以及显式启用的 Graph Proposal 生命周期 |
| Host Agent | 模型和工具执行、提示词、会话循环、任务与运行标识，以及结果处理 |
| 采用方控制面 | 产品注册、角色映射、凭证管理、产品本体、提案策略、审核界面和业务理由 |
这条边界意味着 Foundation 可以判断一条 Evidence 是否仍然有效，却不能替 TraceWise 决定一次分析任务的业务结论；它可以记录 Graph Proposal 的审核和执行收据，却不能替 TeachFlow 定义课堂事实。
交互架构图：权威数据沿明确方向流动，产品控制面、平台契约和持久化责任不会被混成一层。点击图片可缩放、切换主题并导出。
注册不是交出控制权
一个产品接入 Foundation 时，注册过程只应该冻结它明确选择的能力、依赖策略和权限上限。当前 AF-RA01 基线返回的是能力中性的 ProductRegistrationReceiptV2：调用者能获得什么权限，由已经封存的 capability binding set 决定，而不是从一个过宽的管理角色中继承。
这项设计修正了一个容易被忽略的问题：如果 Memory 管理权限还能顺便管理 Registration、Evidence 或 Graph，那么“复用能力”会退化成跨领域的隐式授权。现在 Registration 拥有独立的读写 Scope，Graph-only 的采用方也不会因此获得 Observation、Memory 或 Relation 权限。
用采用方证明平台，而不是只展示平台
抽象接口只有被真实产品采用后才有意义。目前能够证明边界的不是一张 Foundation 自我介绍图，而是 TraceWise 与 TeachFlow 的受限采用路径。
TraceWise 只让一个真实 opt-in 项目进入 Foundation 持有的 Evidence、Graph Proposal、ReviewDecision 与 Graph authority 路径；没有 opt-in 的项目继续保留声明过的原有路径。TeachFlow 的采用同样被限制在具体 Pilot 中：Foundation 可以持有 Pilot 所需的 Memory 或 Graph 治理能力，但课堂、学生、课程本体和 UI 策略仍属于 TeachFlow。
交互边界图：两个产品复用同一平台契约，但模型、角色、审核界面和产品状态仍由各自控制面持有。
失败时也不能吞掉产品主路径
平台的价值不只体现在成功调用。Foundation 不可用时，采用方的基础上下文、治理与持久化主路径不能因此被整个阻断。哪些请求可以降级、哪些结果必须拒绝、哪些决定需要稍后恢复，都应当由显式契约约束。
同样的原则也适用于证据失效：旧 Evidence 被撤销或替代后，相关 Memory 或 Graph 结果不能静默继续生效。新的同血缘证据需要由独立的 revalidator 明确确认，系统才允许恢复使用。
当前证据成立到哪里
这篇文章对应的接受基线是 AF-RA01：agent-foundation==0.1.0a20.post16、Python SDK tracewise-memory==0.1.95，以及当前受限采用方证据。注册修正通过了新安装包的公共工作流和 305 passed, 9 skipped 的源码回归。
这里的“已验证”仍然只表示本地、版本化安装包和任务隔离的 PostgreSQL/Neo4j 切片。它不能推出生产 IAM、TLS、密钥轮换、租户隔离、HA/DR、容量、大规模图性能、广泛迁移，或模型与业务效果已经成立。
采用平台时，先明确三个问题：谁拥有事实，谁有权改变它，失败后由谁恢复。 这些归属决定接入接口、授权与恢复步骤。