如果一个平台真的能被多个 Agent 产品复用，接入后的产品是不是应该越来越像？
我的答案恰好相反。TraceWise 和 TeachFlow 接入 Agent Foundation 后，依然保留了完全不同的用户任务、领域模型、审核角色和页面结构。它们共享的是同一套能力目录与权威不变量，但通过各自的 Recipe 启用不同组合：TraceWise 的受控切片主要使用 Evidence、Graph Proposal、ReviewDecision 与独立执行，TeachFlow 则按 pilot 使用 Memory 或 Graph authority。
换句话说，Foundation 统一的是“谁有权写、依据什么写、写入如何审核和失效”，而不是“产品应该思考什么、如何解释、页面长什么样”。
查看 Agent Foundation 项目总览 · 打开本文交互图
先把三层所有权分开
一个高级 Agent adopter 至少有三层：
1. 产品业务层
这一层属于 adopter：
- prompt 与模型选择；
- ontology 与业务对象；
- reviewer 分配与业务理由；
- 产品 UI、报告和工作流；
- 谁是当前 actor，谁是 represented business owner；
- 哪个项目或班级应该 opt in。
2. 接线与能力编译层
Product Recipe 声明需要哪些 capability。编译结果、accepted Provider Claims 与唯一 Runtime component owner 共同派生能力；adopter 不能靠一个 boolean 或伪造 service claim 自己宣布“我已经拥有 Graph authority”。
Registration 则冻结实际启用的能力、provider fingerprint、policy、principal 与 scopes。Agent、reviewer、revalidator、executor 打开的都是同一个 Registration 下的受限 handle，而不是各自创建一套隐形身份。
3. Foundation 权威层
这一层负责可复用的生命周期：
- Evidence revision 与 receipt；
- Memory govern / review / recall / revalidation；
- Graph Proposal record / submit / review；
- durable outbox；
- 独立 executor；
- PostgreSQL 控制面状态；
- Neo4j mutation、operation marker 与 Graph revision；
- dependency-safe projection。
技术解释图：两个 adopter 都通过 Product Recipe 与 Registration 获得受限 handle；产品策略仍留在各自边界内，未 opt-in 项目不会被静默迁移。
TraceWise：采用的是受控 Graph 变更链
TraceWise 的核心任务是把复杂问题分析、Evidence 和人工审核组织成可解释的产品流程。它需要的不是通用聊天记忆，而是一条能约束 Graph 变更的权威链。
在受控 opt-in 项目中，TraceWise 将产品候选转换为 typed Graph Proposal：
- 绑定 exact Evidence revision；
- 绑定完整项目 Graph baseline；
- 冻结 ordered typed operations 与预算；
- submitter 只能提交；
- 实际 human reviewer 写入唯一可执行 ReviewDecision；
- reviewer 不直接修改 Neo4j；
- 独立 Foundation executor 消费 durable outbox；
- Neo4j 在同一 transaction 中写业务 mutation、operation marker 和 Graph revision；
- PostgreSQL 保存 apply receipt 与 reconciliation 状态。
TraceWise 仍然拥有分析 ontology、产品 case、reviewer 分配、业务理由和展示方式。Foundation 不会推断某条业务 relation 是否应该存在，也不会替产品决定 cascade。
正式采用证据限定为一个受控 opt-in pilot；其他项目继续使用 legacy authority。这个边界看似保守，实质上避免了平台升级时对所有历史项目进行不可见的语义迁移。
TeachFlow：Memory 个性化与客观学情 Graph 是两类权威
TeachFlow 的用户任务不同。教师关心题目、班级、作业和学情；学生关心练习、订正与个性化辅导。
第一个 Memory-first pilot 将 Foundation Memory 设为限定学生与班级的唯一个性化权威：
- 学生 Agent 作答形成 immutable Answer revision；
- Answer Evidence 进入 Foundation；
- Memory candidate 经教师审核后才可召回；
- Evidence successor 出现时旧 cue 立即 protected empty；
- 独立 revalidator 完成后才恢复新 revision 的 recall；
- Foundation 不可用时，产品明确显示个性化依据无法确认，而不是旁读旧
agent_memories。
Graph Analysis Agent 也只从 Foundation 读取 pilot 的个性化 cue，但 TeachFlow PostgreSQL/Neo4j 仍然拥有客观学习图结果。个性化解释不可用时，结构化 Graph 分析仍可返回。
后续的题目知识确认与 class Graph pilot 又采用了 Evidence、Graph Proposal、ReviewDecision 和独立执行链。Foundation 开始拥有这些受控 Graph authority 状态，但 TeachFlow 仍拥有：
- 班级和 enrollment；
- 课程与知识点 ontology；
- 教师/学生授权语义；
- 题目和作业业务事实；
- 最终教学工作台。
所以，“Foundation 是权威”并不意味着 Foundation 接管一切数据。更准确的说法是：对于明确启用的 capability，Foundation 是对应语义状态与变更生命周期的权威；adopter 仍是业务真相和产品策略的权威。
两种接入放在一起看
| 维度 | TraceWise | TeachFlow |
|---|---|---|
| 主要产品任务 | 复杂问题分析与人审 Graph 变更 | 教学练习、学情、班级与辅导 |
| 首要采用切片 | Evidence + Graph Proposal + ReviewDecision + executor | Memory-first 个性化；后续限定 Graph authority pilots |
| 产品仍拥有 | ontology、case、reviewer 分配、业务理由、UI | 课程、班级、actor、题目/作业语义、UI |
| Foundation 拥有 | 已启用项目的 Evidence/Proposal/Decision/Receipt 生命周期 | 已启用 pilot 的 Memory 或 Graph authority 生命周期 |
| 非 opt-in 范围 | 保持 legacy | 保持 legacy |
| 降级原则 | 不绕过 Proposal/ReviewDecision 直接写 Graph | 个性化失效时不旁读旧 Memory；客观结果可继续 |
两个 adopter 保留各自的产品策略，通过同一组权威约束接入平台。适配层因此需要表达策略差异，而不是统一成一套 CRUD。
Registration 为什么是关键，而不是又一层配置
如果每个 capability 都独立建立身份，系统会很快出现两套 Registration、两套 scope 和无法解释的权限组合。最终开发者不知道当前请求到底代表哪个项目、哪个 owner、哪个 policy lineage。
统一 composition 之后，底层只有一条权威链：
compose → assemble → register → open scoped handle
同一个实际 principal 在同一个 Registration 下获得精确 scopes。提案、审核、revalidation、执行彼此隔离，但都能追溯到同一编译结果和 provider ownership。普通 Recipe、personal-safe 或固定 Waku 不会因为系统安装了 Graph component 就自动获得 Graph/Review capability。
这使“平台支持 Graph”与“当前产品请求有权修改 Graph”成为两件不同、可验证的事实。
失败隔离比成功路径更能说明复用质量
两个 adopter 的接入都刻意验证了负向路径：
- 缺少 capability 或 scope 时 fail closed；
- product 不能注入假的 Foundation service claim；
- submit 与 reviewer 阶段 Graph 零写；
- reviewer 不能充当 executor；
- Evidence stale、revoked、missing 或 binding mismatch 时不能继续 apply；
- non-pilot 不被自动升级；
- Foundation authority 不可用时，不用 legacy fallback 假装成功。
这些边界不会直接让页面更漂亮或答案更聪明，却决定了平台是否真的可以被第二个产品采用，而不是只为第一个项目写了一组内部工具。
采用范围
Agent Foundation 在 TraceWise 与 TeachFlow 的限定切片中承担 Memory、Evidence 或 Graph Proposal 的权威生命周期。验证覆盖 scoped Registration、人工审核、独立执行和失效保护。
两个产品仍保留自己的业务数据库与未迁移流程。生产 IAM、TLS、HA/DR、模型和教学效果需要单独验证；第三方产品接入也需要重新检查能力映射和产品策略。
结论
真正可复用的 Agent 基础平台，不应该要求产品放弃自己的差异性。它应该提供一组足够稳定的底层不变量，让完全不同的产品都能回答：
- 当前能力从哪里编译出来；
- 谁能提出、谁能审核、谁能执行；
- 语义状态存在哪里；
- 依据失效后如何停止使用；
- 没有 opt in 的范围为什么不会被影响。
TraceWise 和 TeachFlow 仍然长得不同，正是这套平台边界成立的证据之一。它们复用的是权威基础设施，而不是被改造成同一种产品。