很多团队发现 agent 在多来源知识里表现不稳时，第一反应是“文档还不够全”。他们继续补 FAQ、补 SOP、补案例、补字段说明，结果系统还是会在一些关键术语上反复摇摆。真正的问题往往不是知识量，而是知识口径。采购系统里的“已提交”和客服系统里的“待审核”并不完全等价；运营团队说的“生效”，法务文档里也许指的是另一层批准状态；一个字段在旧系统叫 status，在新表里已经拆成 approval_state 和 execution_state。这些差异对人来说可能靠经验能补上，对 agent 来说却是在强迫它用概率去猜业务语义。
这就是 Canonical Fact Registry 的价值。它不是再做一套百科全书，而是给 Knowledge Plane 增加一层语义基座，让不同来源对同一业务事实的表达可以先被系统统一，再被 retrieval 和 runtime 消费。没有这一层，团队往往会不断误判：以为自己缺的是更多文档，其实真正缺的是一个能告诉系统“这些词在不同来源里到底是不是同一个东西”的统一事实表。
Canonical registry 最重要的，不是命名规范本身，而是让 agent 不再把关键状态、金额、责任归属和时间边界交给语言模型自由猜测。只要系统还在靠“这两个词大概差不多吧”去串业务流程，后面任何更复杂的检索和推理都会建立在摇晃的地基上。
建议配合 AI agent Knowledge Source Onboarding Contract、AI agent Evidence Conflict Resolution、AI agent Retrieval Policy Router 和 AI agent Tool Result Normalization 一起看。
先给结论：Canonical registry 不是术语表，而是运行时用来对齐业务现实的一张事实映射网
| 对象 | 看起来像什么 | 真正要解决什么 |
|---|---|---|
| 术语表 | 同义词、缩写、别名清单 | 只解决“怎么叫” |
| 字段映射表 | old field -> new field | 只解决“怎么取” |
| Canonical Fact Registry | 术语、状态、字段、作用域、owner、有效期一起建模 | 解决“这到底是不是同一个业务事实” |
团队最容易走偏的地方，是把 canonical registry 做成一份文档化词汇表。那对人可能有帮助，对 runtime 却帮助有限。真正可用的 registry 应该让系统知道：某个术语属于哪个 domain，它映射到哪一个 canonical fact，它和哪些字段、状态转换、权限条件绑在一起，以及何时不应该被强行归并。
哪些事实最值得优先 canonicalize，不是按出现频率，而是按误判代价
| 事实类型 | 为什么优先级高 | 一旦混淆会发生什么 |
|---|---|---|
| 流程状态 | 直接决定下一步动作 | agent 会错走流程或错误升级 |
| 金额 / 阈值 | 影响审批、报价、预算 | 系统会在金额边界上持续出错 |
| 时间边界 | 影响 SLA、履约和新鲜度 | 把过期信息当成当前承诺 |
| 责任归属 | 影响 owner 和升级路径 | 故障与审批都找错人 |
也就是说，canonical registry 不是为了让所有术语都更整齐，而是为了把那些一旦被模型误解就会直接产生后果的业务事实，先从“语言相似度问题”升级成“系统事实问题”。
一个可执行的 canonical fact entry，至少要有这些字段
| 字段 | 用途 |
|---|---|
| canonicalName | 系统内部统一引用的名字 |
| aliases | 各系统、各团队、各文档里的历史称呼 |
| domainScope | 这个事实适用于哪条业务域、哪类流程 |
| fieldMappings | 它在不同 source / tool 里的字段承载方式 |
| stateSemantics | 如果是状态，它到底代表哪个生命周期节点 |
| owner | 口径变更时谁能拍板更新 |
很多团队只建了 aliases 和 fieldMappings，结果系统能“勉强对齐名字”，却仍然不知道两个名称相近的状态是不是同一个生命周期节点。对 agent 而言，这种缺口非常致命。因为它会让模型在没有充分证据的情况下自行补完语义，而模型在业务状态机边界上最不该被这样信任。
Canonicalization 不是把所有差异抹平，而是明确哪些差异必须保留
真正成熟的 registry，除了做归并，还要学会拒绝错误归并。因为现实里很多词看起来相近，实际上就是不同的事实。比如“待审核”和“已提交”在某些团队里会混着说，但在另一些流程里，一个代表已经进入审批队列，一个仅代表用户完成了填写，还没被系统接受。
一个可用的决策框架通常是：
| 情况 | 建议动作 |
|---|---|
| 只是同义称呼，生命周期含义相同 | 合并到同一个 canonical fact |
| 字段不同但业务语义一致 | 保留映射关系，统一到同一个 canonical fact |
| 名称相似但状态转换含义不同 | 绝不强行归并，必须拆成两个 canonical fact |
| 语义仍在变动或无人负责 | 暂不 canonicalize，只允许在低风险场景引用 |
这张表的重要性在于，它迫使团队承认：不是所有差异都该被自动“智能理解”。有些差异正是业务逻辑本身，不应该被语义近似度抹掉。
失败案例：同样叫“已提交”，两个系统表达的是完全不同的流程阶段，agent 却把它们当成一个状态继续执行
某团队把采购申请系统和合同审核系统接进同一套 agent。两个系统里都有“已提交”这个状态，团队起初也觉得这很方便，索性在 prompt 里统一解释成“用户已发起流程”。结果上线后出问题了：在采购系统里，“已提交”意味着进入审批前校验；在合同系统里，“已提交”意味着文档已冻结，不允许继续修改。agent 因为把两个状态强行视为同义，开始在合同流里执行后续补充动作，直接违背了真实流程边界。
根因并不在模型“理解差”，而在于系统根本没有 canonical registry。它只看见两个相似词，就把它们压成了同一个概念。后来团队修的不是更多 prompt 说明，而是把状态层单独抽成 canonical fact registry：每个状态都绑定 domain scope、allowed transitions 和 owner；只有语义完全一致的状态才允许共享 canonicalName。修完之后，agent 终于不再把“词像”误当成“事实相同”。
Canonical registry 最有价值的地方，是把人脑里的组织默契从支持现场拿出来
很多平台一开始会觉得这类问题靠资深同学就能兜住。确实，在小范围里，业务 owner 知道哪个词在自己团队是什么意思，工程同学也知道某个字段在旧系统里其实是另一个概念。但只要系统开始跨租户、跨团队、跨流程复用，这种默契一定会迅速失效。那时 agent 看到的是一堆文字和字段，不会继承组织里那些“你懂我懂”的默会知识。
registry 的意义，就是把这层默契显式化。它看起来不如模型和向量检索酷，但它是真正让平台在扩大规模时不至于每接一个新域就重新学一遍业务语言的关键资产。
如果你现在只能先补一层，先把所有会改变流程走向的状态词做 canonicalization
很多团队会先想补全所有术语，这是自然的。但更值得优先做的，是先抓那些会直接改变 agent 下一步动作的状态词和关键事实。因为这类词一旦被误解，不会只造成措辞问题，而会直接导致流程推进错误、审批错误、回滚错误和升级错误。
AI agent 真正稳定的一个标志，不是它知道更多词，而是它已经不再靠概率去猜那些最不该猜的业务事实。Canonical registry 把这件事做对了，后面的 knowledge plane 才真正有业务语义可依赖。
Checklist
- 是否识别出会直接改变流程、审批或责任边界的关键事实类型
- 每个 canonical fact 是否包含 aliases、domainScope、fieldMappings 和 owner
- 是否明确哪些相似术语绝不能强行归并
- retrieval 和 tool normalization 是否都消费同一套 canonical registry
- 术语或状态变更时，registry 是否有显式 owner 和更新流程
- 高风险场景是否禁止使用未 canonicalize 的临时语义直接推动动作
延伸阅读：
