ERP、CRM 接了 AI 仍不好用，通常不是模型不够强，而是业务系统还没有成为 Agent 可可靠读写的事实源。“有 API”只解决接得上；字段含义、对象关联、当前状态、权限和写回证据不清，AI 仍然会答错人、用错版本，或者操作后无法确认是否成功。
适合先补事实源的企业，往往已有 ERP、CRM、MES 或 Excel 台账，但跨系统任务总要人工核对；如果系统数据本身完整、主键稳定、权限清楚，且 AI 只做单表查询，则不必额外改造。
五种症状，说明问题不在模型
| AI 使用症状 | 常见事实源根因 | 应补的能力 |
|---|---|---|
| 同一客户出现两套答案 | 客户名当主键、别名未合并 | 稳定 ID 与实体解析 |
| 订单状态和群里说法冲突 | 没定义哪个系统裁定当前态 | 按字段登记权威来源 |
| 回款金额算不对 | 作废、退款、时间窗口径不清 | 指标定义与过滤规则 |
| 销售查到不该看的客户 | 接口账号权限过大 | 请求人到字段、对象、动作的权限映射 |
| Agent 说已更新，系统却没有 | 写入无幂等、无回执、无回读 | 动作回执与写后独立核验 |
这也是为什么“把数据库表全开放给 AI”不是捷径。表越多、字段越杂、历史例外越多，模型越容易把看似相似的数据拼成一个错误结论。
事实源改造不是重做 ERP/CRM
现有系统能用就继续用。改造目标是让人和 Agent 共用同一套业务事实，优先补以下五件事：
- 业务对象拆清楚：客户、联系人、商机、合同、订单、回款、发票和项目不要压成一个“大单据”；
- 稳定业务键：系统 ID 是身份，客户名称和项目标题只能作为别名；
- 字段权威性：按企业规则区分可流转的当前归属与应固化的事件归属；合同金额回合同，回款事实回财务；
- 双时间与版本：记录事实何时生效、系统何时知道，迟到补录不能抹掉历史；
- 读写分权：能查询不等于能修改，付款、审批、合同变更等动作单独授权和人审。
例如销售主管问“哪些客户需要本周跟进”，Agent 需要从 CRM 取负责人和最近动作，从订单与回款系统判断交易状态，再按公司规则生成待办。若 CRM 没有“下一动作”和“完成定义”，接口再快也只能生成一份漂亮但不可执行的名单。
用这张清单做系统体检
在接模型前，让业务、IT、财务和项目负责人共同回答：
- 每个核心对象是否有唯一 ID，而不是靠名称模糊匹配？
- 每个关键字段以哪个系统为准，谁负责维护？
- 作废、退款、重开、改绑等历史例外是否有确定规则？
- 接口能否按员工角色限制客户、项目和字段？
- 数据更新时间、同步水位和失败状态是否可见？
- 写操作是否有幂等键，重复执行会不会生成两条记录？
- 执行成功后，能否重新读取目标系统确认最终状态？
- 缺字段或发生冲突时，Agent 是明确停下，还是自行猜一个答案？
只要其中三项答不上来，建议把第一阶段预算放在事实源治理，不要继续堆提示词。关于多系统接口的基本边界，可先读什么是系统集成；涉及知识资料与交易数据的分工，可看什么是 RAG。
第一阶段怎么落地
选一条短闭环，而不是改造全系统。比如“发现逾期订单 → 找到责任销售 → 生成催收待办 → 人工确认 → 写回 CRM → 回读确认”。
项目经理负责范围和验收，销售主管确认负责人及催收规则，财务确认应收口径，IT 提供接口与权限，Agent 只在这条明确链路里工作。正常数据、缺失数据、无权限、重复提交和接口超时都要测试。验收标准不是页面回答得像不像人，而是源字段、动作回执和原系统终态能否逐项对上。
这类建设位于企业级 Agent 的事实源层：定制开发不是另起一条旧系统业务，而是补齐 Agent 缺少的字段、接口、权限和流程。可以从企业 AI 落地工程了解完整路径，并用AI Agent 项目验收清单核对执行链；需要统一 Agent 入口时，再看开沿 Agent。
模型决定 Agent 能理解多复杂的任务，事实源决定它在企业里能不能说真话、做对事。先把业务事实变得可识别、可授权、可追溯，AI 才有稳定发挥的地基。
