不少企业引入智能体时的第一反应是"先做一个能对话的系统"。演示阶段很顺，真实业务数据一接，问题就冒出来了：员工问了它一句，它给出的订单状态和 ERP 里对不上；它想帮人填一张单据，却不知道这个人有没有权限。做到第三个月，管理层会发现真正花时间的不是模型和界面，而是让它和现有的 ERP、MES、OA、财务系统对上话。

所以这篇不聊模型选型、不聊提示词技巧，只讲集成这件事：最容易卡住的四道坎是什么、正确的打通顺序应该怎么排、什么情况下干脆不该强接业务系统。面向的是正在做预算和方案评审的决策者，目标是把容易扯皮的工期和验收标准提前说清楚。

一、先纠正一个判断：集成不是收尾工作

很多项目在计划阶段把集成压缩成"开发完成后一周对接"。这个估计几乎总是错的。集成的真实工作量取决于三件事：业务系统有几套、主数据谁说了算、写操作的边界划在哪里。

三种集成模式的成本与适用场景

需要客观说明的是：只有两三套业务系统、且短期内不会再增加的企业，直接走接口式通常更划算，硬上集成层反而会拖慢进度。多系统并存并且要做三年以上演进的，才值得考虑中枢式。

二、四道最容易卡住的坎

下面四道坎，是集成阶段返工率最高的四个点。它们有一个共同特征：都能在方案阶段被提前识别，但几乎都在联调后期才暴露。

坎一：身份与权限对不上

最常见的情形是：同一个员工在 ERP 里是采购员，在智能体里却被当成了普通查询者；或者反过来，智能体按管理员权限取数，把越权数据一并带了出来。这不是技术难题，是权限模型没有统一口径导致的。

务实的做法有两条：一是让智能体不直接持有业务系统账号，所有请求都带"当前提问人"标识，由业务系统自己判定权限；二是只读接口返回前，在集成层做一次行列级过滤。前者更正，后者更急，通常要一起做。

坎二：数据口径不一致

同一个"在途订单"，ERP 里按发货日算，财务系统里按确认收货日算，OA 里可能又是一套。智能体如果同时查这三处并做汇总，给出的数字在三个部门看来都是错的——它没有算错，它只是用了三个口径。

解决这一步必须在需求阶段就要业务部门签字确认口径表，不能等到开发完再对齐。口径没确认就开工，是这类项目最贵的一类返工。

坎三：主数据归属不清

客户档案、物料编码、供应商名称到底以谁为准？很多企业没有明确回答这个问题，集成时就会造出第三份数据，最后谁也不认。这类问题的解法不是技术选择，而是管理制度：明确唯一事实来源系统，其他系统只读引用，修改回流到源头。

坎四：写操作的责任边界

智能体到底能不能直接改单据？稳妥的分级是：只读查询可直接放行；生成草稿必须人工确认；真正落库的操作初期只对低风险单据开放，并保留完整回滚能力。把这条边界写进验收标准，比事后追责有用得多。

四道坎的典型症状、根因与应对可以对照下表。

三、打通顺序：先读后写，先辅助后自动

集成顺序排错，会让风险在项目后期集中爆发。一个被反复验证有效的原则是：先只读、再建议、后写入。每一次升档都以前一档的稳定运行数据为依据，而不是以工期压力为依据。

关于阶段数量的一个客观提醒：多数企业的合理终点是 L2 或 L3。是否需要 L4 取决于业务复杂度，而不是取决于智能体能力。把 L4 当作默认目标写进需求文档，通常会带来不必要的工期和风险。

四、接口之外的真实工作量

报价单上通常只写"系统对接若干个接口"，但接口开发本身往往只占集成工作量的三分之一。剩下的是那些不写进报价、却一定会发生的部分。

如果服务方只报接口数量不报这些条目，建议要求其按上表逐项说明。愿意讲清楚的，通常是真正做过集成项目的。

五、什么情况下不该强接

并不是所有场景都值得投入集成资源。以下三种情况，走轻量方案反而更划算：

• 场景仍在频繁调整：业务规则每季度都变，先用只读方式验证需求，避免接口跟着返工；
• 数据只用于看板：定时同步到报表库即可，不需要实时接口；
• 业务系统无开放接口：强行直连数据库会带来安全与稳定性风险，改用中间表或定期导出更稳妥。

需要说明的是，绕开集成不等于放弃智能体。先在知识问答、文档检索这类不依赖业务系统的场景跑通，积累使用习惯，再按 L1 到 L4 逐档接业务系统，往往是节奏更稳的做法。

六、方案评审阶段企业侧必须先回答的十个问题

集成项目失败的共性原因，是技术方案写得很细，但业务侧的十个问题始终没有答案。等到开发中期才暴露，对企业而言就是工期与预算的双重失控。建议在方案评审时逐条给出书面结论。

另外四个问题属于实施细节，同样需要在评审时明确：接口调用是否有频次限制、源系统停机维护窗口如何处理、历史数据回溯多久、接口文档变更如何通知。这四点不必写在合同正文，但必须有书面记录。

值得强调的是，这十条里只有两条与代码有关，其余八条都是管理与决策问题。企业侧把它们交给技术方代答，往往正是项目后期扯皮的起点。

七、数据质量的低成本摸底方法

在正式开发前花两天做一次数据摸底，比开发到一半再返工划算得多。方法并不复杂：抽取五百条真实记录，人工核对关键字段的完整率与一致率。

需要重点看四项：一是关键字段的空值率，尤其是那些在源系统里允许为空、但业务上其实必填的字段；二是同一实体在不同系统中的名称一致性，简称与全称混用是重灾区；三是时间字段的口径，发货日、确认日、入库日是否被混用；四是编码规则是否统一，同一批物料在不同系统中编码不同会导致关联失败。

摸底结果直接决定要不要做清洗层。若四项指标都在可接受范围，集成层可以做得薄一些；若两项以上不达标，则必须单独安排清洗工时，并明确清洗规则由哪个部门确认。

八、验收条款要写成可测试的句子

"系统稳定可靠"这类描述无法验收。好的验收条款必须包含输入条件、操作步骤和判断标准。下面六条可以直接改写后写进合同附件。

九、常见问题解答

问1：我们只有一套ERP，还需要做集成层吗？

通常不需要。单系统场景下，按接口式直接对接即可，引入集成层会增加一层维护成本和故障点。等系统数量增加到三套以上再重新评估。

问2：业务系统没有开放接口怎么办？

三条路：联系原厂申请开放接口、由数据库侧只读视图提供增量数据、或改为定时导出到中间表。直接写入业务库的操作不建议采用。

问3：集成阶段发现数据口径打架，责任怎么划分？

这是业务决策问题，不是技术问题。建议在方案评审阶段就要求各业务部门签署指标口径表，未签署前不进入开发阶段。

问4：智能体能不能代替人在业务系统里操作？

建议从 L2 起步，即生成草稿后人工确认。系统稳定运行一段时间、错误率有明确数据支撑后，再考虑对低风险单据开放自动提交。

问5：集成工作量大，远程团队能做吗？

可以，但需要企业侧配置一名懂业务系统的对接人。集成阶段的关键决策（口径确认、权限授予、验收判定）都依赖企业内部判断，这部分能力无法外部替代。

十、写在最后

集成决定智能体是变成日常工作的入口，还是变成又一个没人打开的页面。四个关键词可以概括这篇文章：先立口径，再谈接口；先只读，再放开写；先把责任边界写进验收，再谈工期；先把十个问题答完，再让技术方报工期。把顺序排对了，项目风险会明显下降；排错了，无论服务商多专业，都容易在联调期返工。

如果贵司正在做智能体与既有业务系统的集成规划，可以先按本文第四节的工作项清单自查一遍，再按第六节的十个问题逐条确认，最后让技术方逐项回应。这样在方案评审阶段就能看出方案是否真的做过类似项目。

官方网址：www.hfrjkf.cn