我们通常会在一家企业里看到这样一种情况：销售在CRM提交了客户申请，OA审批也已经结束，但ERP里还没有正式客户档案，后续订单、结算和财务流程因此卡住，只能再由人工把几套系统里的信息重新核一遍。
三套系统其实都在正常运行，问题出在流程没有真正连起来。客户资料在CRM里，审批结果在OA里，正式客户主数据又要落到ERP。过去，这些环节往往靠人来回切换系统，核对资料、确认审批、查重、建档，再把ERP生成的客户编码回填给销售。
企业级智能体进入这类场景，就是把这段原本由人维系的流程衔接起来。
ERP是企业资源计划系统，OA是办公自动化系统，CRM是客户关系管理系统。系统之间常用的连接方式主要有三种：API直接调用已经开放的接口，RPA负责网页和桌面客户端里的自动化操作，MCP则把已有接口和工具进一步整理成智能体可以调用的能力。具体到一笔客户建档，这三种方式往往会同时出现。
业务关联：决定跨系统流程能否成立
如果销售第一次提交客户资料后，因为材料不完整被退回，补充以后又发起第二次申请，CRM里已经更新成新版资料，OA里却同时保留着两次流程，此时，系统需要明确当前申请对应哪一次审批，审批通过的又是哪一版数据。
一条比较完整的客户建档链路，通常会持续保留几组关键关系：
1、CRM申请ID和版本，确认当前处理的是哪一版客户资料；
2、OA流程ID和审批结果，确认对应哪一次申请；
3、ERP客户编码，建档完成后再回写CRM，供订单、结算等后续业务使用。
OA流程本身也会存在处理中、退回、撤销、终止、正常结束等不同状态。系统查到"流程结束"以后，还需要继续读取具体审批结果，并核对是否对应当前这版客户申请。销售如果在第二次提交前修改了企业主体名称，CRM和OA的数据版本已经不一致，流程就需要停下来核对。
权限也贯穿整条链路，CRM接口通常继承企业原有的账号和应用授权，能够读取哪些客户、访问哪些字段、执行哪些操作，都受既有权限体系约束。未授权、权限不足、令牌失效、调用超限等情况，也需要在流程里分别处理。智能体接入以后，原来的权限边界并不会因此消失。
系统入口：决定API与RPA的组合方式
审批确认以后，流程继而进入ERP系统，已经开放客户查询和创建接口的系统，可以直接通过API传递客户名称、统一社会信用代码、所属组织、结算条件等结构化数据，再取得客户编码和处理状态。到了存量系统环境，接口覆盖通常没有这么完整，有些模块只能查询不能写入，有些附件仍要从客户端上传，还有一部分历史系统长期依赖页面操作。
企业现有系统的开放程度往往并不一致，常见情况主要有这几类：
| 系统条件 | 常见处理方式 | 客户建档中的应用 |
|---|---|---|
| 接口完整、权限明确 | API | 查询客户、创建档案、读取状态 |
| 无合适接口、界面稳定 | RPA | 上传附件、操作历史客户端 |
| 接口与页面并存 | API＋RPA | 接口写入基础数据，页面补充材料 |
| 已有成熟自动化流程 | 直接复用 | 调用现有查询、建档流程 |
比如客户查询和基础档案创建已经可以通过API完成，但营业执照等材料仍需要在客户端上传，那么前半段走接口，附件部分继续交给RPA，最后再查询ERP里的客户编码和业务状态。
RPA在这里承担的是具体系统操作，网页、桌面软件以及部分没有标准接口的旧系统，都可以通过控件识别、元素定位、视觉识别等方式完成查询、录入、上传和回填。对于已经运行多年的企业IT环境，这类能力依然很实用，因为很多系统短期内并不会为了接入Agent重新改造一遍。
数据映射：贯穿客户建档全流程
系统能够连接以后，CRM、OA和ERP里的数据还要能够对应，同一个"客户"，进入不同系统后往往不是同一套字段体系。
| CRM / OA中的信息 | ERP可能需要的形式 |
|---|---|
| 重点客户 | 客户分类代码 |
| 华南区 | 组织编号 |
| 月结30天 | 结算条件代码 |
| 企业简称 | 标准主体全称 |
| 销售填写的行业名称 | ERP行业分类 |
所以跨系统连接还会涉及数据转换、主数据同步和字段映射，系统入口已经打通，如果字段关系没有理顺，客户资料依然无法直接落到ERP。
查重也是客户建档里绕不开的一步，两个企业名称很接近，可能属于不同主体；名称略有差异，也可能实际上是同一家公司。统一社会信用代码、历史客户编码等字段能够明确判断时，可以按规则继续处理；旧数据不完整、多个主体同时命中，或者历史档案存在冲突，就需要人工确认。
AI可以帮助读取材料、比较文本和整理差异，但主数据最后怎么认定，仍然按照企业既有的数据治理规则执行。
结果校验：构成跨系统执行闭环
客户资料写入ERP以后，流程还需要确认最终结果。API已经发出创建请求，或者RPA已经完成页面提交，只能说明操作动作已经执行。ERP是否真正生成正式客户档案、客户编码是否有效、关键字段有没有正确写入，还需要继续读取系统返回或重新查询业务状态。
这里最容易出问题的是超时。
如果创建请求已经到达ERP，只是前端没有及时收到返回，后台可能已经完成写入。此时直接重新提交，就有可能多生成一份客户档案。比较常见的处理方式是先查询目标系统里的实际记录，再决定后续动作。
| 执行结果 | 后续处理 |
|---|---|
| ERP明确返回成功 | 获取客户编码并回写CRM |
| ERP明确返回失败 | 修正问题后按规则重试 |
| 请求超时但已生成记录 | 沿用第一次业务结果 |
| 无法确认是否成功 | 暂停任务并转人工核对 |
| 出现重复或主体冲突 | 停止写入并进入人工处理 |
因此，幂等、唯一约束、业务锁和失败续跑这些机制，在Agent进入流程以后依然重要。它们控制的是ERP最终留下什么结果，也决定任务中断之后能不能从正确的位置继续。
客户建档是否真正跑通，可以直接看几项业务结果：CRM申请和OA审批能否对应，ERP里是否只生成一份有效客户档案，客户编码有没有准确回写，失败任务是否留下明确原因，人工接管以后能不能沿用前面的处理记录继续办理。
资产复用 承接智能体执行能力
很多大型企业过去几年已经积累了大量API、RPA流程和系统集成能力。财务、人力、运营、IT等部门沉淀下来的查询、录入、核验和跨系统操作流程，并不会因为Agent出现而失去价值。现在不少企业级智能体产品的做法，是在这些既有执行能力之上增加任务理解、工具选择和流程编排。
以前需要由人发起的一条RPA流程，可以变成Agent按任务调用的工具，原来单独开放给某个系统的API，也可以继续接入智能体编排。这样一来，上层负责理解任务和选择工具，底层仍然由已经验证过的接口和自动化流程完成执行。
国内一些RPA厂商向企业级智能体延伸发展，也基本是沿着这条技术路径。已有接口继续作为系统入口，成熟RPA流程保留在执行层，再由上层Agent根据任务调用。国内老牌自动化厂商金智维早期在苏州高铁新城国控的业财融合项目中，已经采用业务梳理、RPA与OCR协同的方式处理跨系统数据传递和操作追溯；发展到企业级智能体后，企业已有API可以配置为插件，既有RPA流程也可以继续作为智能体工具调用，需要扫码登录等人工参与的节点则保留人工接管。
从企业实际建设角度看，前期积累的客户查询、审批读取、ERP录入等流程已经经过长期运行和调整，这些能力继续留在执行层，上层增加Agent后便可以重新组合成更长的业务链。对于自动化建设时间较长的组织，这种方式也能减少对现有IT体系的大规模改造。
工具治理 支撑MCP规模化接入
企业内部的API、RPA流程和业务服务逐渐增多以后，工具本身也需要形成统一的描述、参数和权限管理。Agent调用"查询客户""读取审批""创建ERP客户"等内部服务时，需要知道工具能完成什么任务、需要哪些输入，以及当前身份是否具有调用权限。
MCP提供了一种相对标准化的工具接入方式，已有HTTP接口可以进一步封装成智能体能够识别的工具，同时保留后端认证、调用授权和参数配置。这样做不会改变ERP、OA和CRM原来的业务规则，客户字段怎么映射、什么审批结果允许继续、哪个账号拥有ERP写入权限，依然按照企业自己的系统和治理体系执行。
客户申请从CRM发起，经过OA审批，再进入ERP完成建档，最后把客户编码回写到CRM。整条流程同时涉及业务关联、系统入口、字段映射、权限、回执和异常处理。API、RPA和MCP分别承担其中不同的连接和执行能力，人工保留在主体冲突、身份验证和结果无法确认等环节。
客户资料能够和审批准确对应，ERP只生成一份正确档案，客户编码顺利回到业务端，异常发生以后仍然能够沿着原有记录继续处理，这些结果都可以直接从业务系统里检查。企业级智能体连接ERP、OA和CRM之后，价值最终也落在这条业务链能否长期、稳定地运行。