AI agent 团队最常被业务催的一句话，不是“效果还不够好”，而是“能不能把这个库也一起接进去”。产品手册想接、销售材料想接、CRM 备注想接、客服 SOP 想接、历史工单也想接。表面上看，这只是多打一条 ingestion pipeline；真正做过的人都知道，风险从来不在接入动作本身，而在于你根本不知道这批资料是否配得上被系统当成事实来源。
很多知识接入事故，不是因为向量检索不准，而是因为 source 自己就没有准备好。文档没人负责、更新节奏不稳定、权限边界靠人工默契、旧版本从不下线、例外口径散落在聊天记录里。这样的来源一旦被 agent 消费，平台不是“多了一份知识”，而是“多了一份不可控输入”。
所以 Knowledge Source Onboarding Contract 真正要解决的，不是让接入流程更官僚，而是让平台在 source 进入知识层之前，先能回答清楚：这是谁负责的、它有多新、它能给谁看、它代表官方还是工作草稿、出了问题时该怎么撤下来。没有这份 contract，后面任何 retrieval 效果优化都只是在帮不稳定来源放大影响力。
建议配合 AI agent Knowledge Plane Architecture、AI agent Corpus Freshness SLA、AI agent Access-Controlled Retrieval 和 AI agent Domain Onboarding Contract 一起看。
先别问“能不能接”，先问“它凭什么被接”
| 来源类型 | 演示时看起来为什么很有用 | 生产里最常见的隐患 |
|---|---|---|
| 官方制度与 SOP | 结构稳定、信息权威 | 更新不及时就会把错误放大成规则性回答 |
| 销售 deck 与培训材料 | 覆盖业务语境、写得通俗 | 过期率高，且常混有试点口径 |
| CRM / 工单备注 | 贴近真实现场 | 权限复杂、文本噪音大、事实与猜测混杂 |
| 数据表与业务系统字段 | 可结构化、可联动工具 | 字段语义容易漂移，且依赖 owner 持续维护 |
这一张表的重点，不是把某类 source 一票否决，而是提醒团队：不同来源进入 Knowledge Plane 前，必须先以不同方式证明自己“值得被消费”。对官方制度类，重点是 freshness 和 owner；对 CRM 备注类，重点是 ACL 和 truth labeling；对业务系统字段，重点则是语义稳定性和 schema 变更通知。
一个可执行的 onboarding contract，至少要绑定六类信息
| 字段 | 它回答什么问题 | 缺了会怎样 |
|---|---|---|
| source owner | 谁对内容质量和更新负责 | 出现错误时没人能拍板修正或下线 |
| truth level | 这份来源是官方规则、经验说明还是工作草稿 | agent 会把不同权重的内容混成同等级证据 |
| freshness tier | 多久必须同步、失效后如何处理 | 系统无法区分“略旧可接受”和“过旧必须停下” |
| ACL model | 哪些租户、角色、环境能看到 | 检索层会先天带上越权风险 |
| deletion / sunset contract | 来源撤下后如何传播删除和回收索引 | 旧内容会在索引里长期残留 |
| failure fallback | 同步失败、权限异常或来源冻结时系统怎么退化 | 平台会在 source 不可信时继续硬答 |
很多接入流程失败，正是因为团队只填了前三分之一：知道库在哪、格式是什么、能不能抓下来，却完全没有把 source 当成运行时依赖去建模。Knowledge Plane 一旦进入生产，这种“内容已经接了，治理以后再补”的顺序几乎总会倒过来把团队拖住。
Truth level 不清，agent 迟早会把草稿当规则，把经验当承诺
知识源最容易被忽略的一层，不是 owner，而是 truth level。因为很多内容看起来都很像“业务知识”，可它们对系统的意义完全不同。法务审批规则、客服常见问答草稿、销售培训案例和用户口头总结，不能被检索层一视同仁。
一个实用做法是先把 source 至少分成三档：
- canonical：正式规则、官方产品定义、平台认可的最终说明
- operational：部门 SOP、流程说明、经过 owner 承认但仍可能变化的执行材料
- provisional：培训材料、试点方案、会议纪要、经验总结
这不是为了做语义洁癖，而是为了让 retrieval runtime 在冲突发生时有基础判断。没有 truth level，系统面对相互矛盾的来源时，只能退化成相似度更高就先上屏，这种行为在高风险场景里几乎注定会出事故。
Onboarding review 最该挡住的，不是技术接不通，而是“来源还不配上生产”
一个成熟的 onboarding 流程，通常至少要过三道门：
- 来源门：owner、truth level、freshness、ACL 是否定义完整。
- 内容门：字段稳定性、结构化程度、术语一致性、删除传播能力是否达标。
- 运行门：同步失败后是否有 fallback，source 暂停后是否能让 runtime 进入保守模式。
这三道门里，真正最容易被跳过的是第三道。团队往往会觉得“先接进来再观察”，可知识源一旦被 runtime 消费，它就不再只是内容资产，而是实时决策的一部分。没有运行门，平台等于默认 source 永远稳定、永远可读、永远可解释，这在现实里几乎从不成立。
失败案例：销售培训 deck 被当成正式价格规则，agent 连续两周都在回答旧折扣
某团队为了加快售前辅助，把内部培训 deck、活动物料和正式价格政策一起接进了同一个知识索引。演示阶段效果很好，因为 deck 里写得更口语，模型也更容易找到“看起来像答案”的句子。可两周后，销售政策更新了正式折扣，培训 deck 却没有同步下线，agent 依然按旧活动报价回答客户。
表面上看，这是一次 freshness 事故；更深的根因是 source onboarding contract 根本没成立。团队没有标 truth level，也没有要求培训材料在进入索引前声明 sunset 条件，更没有让 runtime 在 canonical source 缺失 freshness proof 时拒绝引用低级来源。于是 agent 做的不是“知识增强”，而是“把历史草稿包装成了实时事实”。
后来他们修的第一步不是调 embedding，而是把所有来源拉回 source registry：官方价格库被标成 canonical，培训 सामग्री改为 provisional，活动 deck 统一带过期时间；与此同时，报价类问题必须优先引用 canonical source，没有 freshness proof 时直接进入人工确认。之后系统的“自由发挥”少了很多，但真正可用性反而变高了。
如果你现在只能先补一层，先让任何 source 都不可能“无 owner、无 truth level、无退出条件”
很多团队会觉得 onboarding contract 太重，想先把更多来源接进来再慢慢整理。更务实也更有效的顺序恰恰相反：先把最容易出事故的三个字段卡死。因为只要一个 source 没有 owner、truth level 和 sunset/deletion contract，它就几乎注定会在未来某个时刻变成“大家都觉得不太对，但谁也不敢直接删”的历史知识债务。
Knowledge Plane 成熟的标志，不是接入数量越来越多，而是每个来源都能清楚回答自己为什么存在、还能服务谁、什么时候应该退出。source 先有合同，后面才谈得上稳定地被 agent 使用。
Checklist
- 每个 source 是否都有明确 owner，而不是只有接入工程师
- 是否为来源标记 canonical、operational、provisional 等 truth level
- freshness tier、同步方式和失效后的 fallback 是否被写清
- ACL model 是否能表达租户、角色和环境边界
- source 下线、删除和 sunset 是否能传播到索引与派生缓存
- onboarding review 是否包含运行门，而不只是格式和接入门
延伸阅读：
