不换 ERP,我们给老系统配了一个 AI 搭档
文章介绍某电子厂在不替换原有 ERP 系统前提下,通过 WorkBuddy(AI Agent)、MCP 数据服务与 RPA 的三层协作架构,实现订单自动整理录入、出货单一键生成、移动端业务看板等落地场景。核心逻辑是将‘伺候 ERP’的重复劳动拆解为 AI 编排、接口调用、界面自动化与人工兜底四类分工。
ERP 是底盘,WorkBuddy 是大脑,RPA 是手脚
我们的架构,用一句话讲就是:ERP 是底盘,WorkBuddy 是大脑,RPA 是手脚。
ERP 继续管交易和账目。WorkBuddy 作为 AI Agent,负责业务分析、数据整理和流程编排。ERP 已经开放的数据接口,我们封装成 MCP 服务,交给 WorkBuddy 调用。那些没有接口、只能靠界面操作的动作,再交给 RPA 去执行,比如登录系统、点击按钮、录入表单、导出数据。
WorkBuddy 不替代 ERP,也不重写 ERP。它做的是在 ERP 外面加一层会编排的业务层。人说需求,WorkBuddy 判断要处理什么业务、整理哪些数据、该调用哪个 MCP 服务查数据、该调用哪条 RPA 流程做录入。遇到异常,再把问题抛给人确认。
这里有一个关键分工:WorkBuddy 负责想清楚怎么干,RPA 负责具体动手。如果只上 RPA,很容易变成把人的点击录成脚本。短期能跑,但一遇到字段变化、业务规则变化、异常订单,就会卡住。如果只讲 AI,不接 ERP、不接 RPA,也只是一个会聊天的入口,落不到业务动作里。这个项目真正要解决的,是把分析、编排、执行和人工兜底串起来。

第一步:订单先被整理,再被录入 ERP
上篇讲过,这个厂最头疼的第一道关,是客户下单方式太乱。
客户 A 有自己的订单系统,给了工厂一个账号。以前文员每天要登录进去看单子,再手工抄。现在 WorkBuddy 编排 RPA 流程,自动登录客户 A 的系统,按设定时间去巡单,有新订单就抓回来。客户 B 发邮件,附件是 Excel。WorkBuddy 的订单处理能力会先分析和整理订单数据:识别客户、读取 Excel、做字段映射,把客户自己的表格转换成 ERP 能接收的订单格式。客户 C 最随性,微信群里甩截图。WorkBuddy 调用 OCR 能力,把截图里的表格识别成结构化数据,再交给订单处理能力做字段校验和格式整理。
三种渠道先被整理成统一订单数据,再由 WorkBuddy 调用 RPA 流程录入 ERP。录完之后,WorkBuddy 推一条消息给文员:“今天新增 32 笔订单,已自动录入,请你逐笔审核确认。” 文员的角色变了,她不再是录单机器,而是审核确认的人。自动化不是把人完全拿掉,而是让人站到更该出现的位置。
第二步:打单从 15 步变成一句话
订单进来的问题解决后,下一道关是流程运转。
打一张出货单,原来要点 15 下。这个痛点的解法更直接:让 WorkBuddy 判断要走哪条业务流程,再编排 RPA 去替人执行。操作员对 WorkBuddy 说一句话:“打今天下午要发的这批出货单。” WorkBuddy 先分析这批出货单对应哪些订单,要走哪些流程节点,有没有异常条件。确认流程后,再调用 RPA 自动登录 ERP、选模块、查询订单、填表单、提交审核、打印、归档。
原来 15 步,现在变成 1 句话。以前 80% 的时间在机械点击,20% 的时间在处理异常,比如客户临时改数量、规格特殊需要确认。现在 AI 和 RPA 替你干掉那 80%,你正好可以把精力放在那 20% 真正需要判断的事情上。
RPA 也不是一劳永逸。RPA 操作 ERP 界面,本质上还是模拟人的点击。如果 ERP 界面突然改版,按钮位置变了,弹窗逻辑变了,RPA 就会失灵。我们的做法是:WorkBuddy 在 RPA 失败时自动通知,人工介入处理,同时记录失败原因,定期维护 RPA 脚本。维护成本仍然存在,但远低于每天人工重复点击的成本。
第三步:老板手机上长出了看板
前两步解决的是订单进来和流程转起来。第三步解决的是老板最痛的事:数据看不见,出差就失联。
这里我们没有简单做一个“移动版 ERP 报表”,因为老板真正想看的,不是 ERP 原始报表,而是业务问题的答案。
第一步,把 ERP 已经开放的数据接口封装成 MCP 服务。你可以把 MCP 理解成一组给 AI 用的数据接口。ERP 里已经开放出来的数据,不再让人导表,而是封装成服务,让 WorkBuddy 按业务问题去查。产量、出库、库存周转、排产进度、订单执行状态,这些数据可以直接查询。
第二步,把常用报表移动化、个性化。过去老板看到的是 ERP 里的标准报表。现在看到的是按他关心的问题重组后的看板:产线日产量、订单执行进度、库存周转、今日出货,这是把 ERP 数据变成管理者真正看得懂的问题答案。
第三步,WorkBuddy 通过 MCP 服务接入这些数据,负责分析业务口径、组织回答。管理者可以用自然语言直接问。接口查不到、还得从老界面导出的数据,再由 WorkBuddy 编排 RPA 去补。前提是先把订单状态、产量口径、换线记录这些数据接口和规则梳理清楚。否则自然语言查询只会变成一本正经地胡说。
这一步落地后,有一个场景我印象很深:有次工厂老板去外地出差,在机场候机。以前这个时候,他想知道工厂情况,得打三个电话,等十五分钟。这次他打开 WorkBuddy,问了一句:
“今天产线产出怎么样?”
WorkBuddy 直接回答:
“今天截至下午两点,A 产线产出 1200 件,完成日计划的 75%;B 产线产出 860 件,完成日计划的 62%,比昨天同期低 8%。主要原因是 B 产线上午换线花了 40 分钟。”
我把这个段子讲给我听的时候,我感受到了他的满足感。不是因为技术多厉害,而是因为他突然意识到:过去十年,他每次想知道这些数据,都要麻烦别人。麻烦文员导表,麻烦财务查系统,麻烦车间主任汇报。现在,他不用麻烦任何人,直接问就行,技术本身不感人。真正有价值的是,一个老板第一次觉得自己重新掌控了工厂。

不是换系统,而是先接管“伺候系统”的工作
这个电子厂的案例,给我的最大启发是:ERP 不会马上消失,但伺候 ERP 的人会越来越少。
过去十年,ERP 是工厂信息化的核心。所有数据都进 ERP,所有流程都走 ERP。问题是,ERP 擅长记录,不擅长交互。
于是企业里出现了大量人伺候 ERP 的工作:录单、打单、导数据、做报表、传 Excel。这些工作不创造多少新价值,只是为了让 ERP 能用起来,不得不付出的代价。
- 业务分析、数据整理、流程编排交给 WorkBuddy。
- 接口查询交给 MCP 服务。
- 界面操作交给 RPA。
- 异常判断和最终确认交给人。
这套分工,比单纯“上一个机器人”更稳,也比一上来换 ERP 更轻。
对很多企业来说,下一步未必是立刻换系统。更现实的动作,是先盘点一下:公司里有多少岗位,每天不是在创造价值,而是在伺候系统?这些动作里,哪些可以通过接口查数据,哪些可以通过 RPA 执行,哪些必须保留人工判断?把这张表列出来,很多 AI + RPA 项目的入口就清楚了。
如果你也遇到过类似的老系统问题,可以先从这三个问题自查:
- 订单是不是还靠人抄?
- 流程是不是还靠人点?
- 老板看数据是不是还靠别人导表?
这三个问题回答清楚,比先讨论换不换 ERP 更有价值。
JOTO 企业落地观察
- 这类系统对企业部署意味着:不必等待 ERP 升级窗口期,可基于现有系统接口与界面现状,分阶段引入 AI 编排能力。关键取舍在于优先识别哪些‘人肉中转’环节具备稳定输入输出结构,而非追求全链路自动化。
- 在智能体工程中,WorkBuddy 的角色定位揭示了一种务实路径:AI Agent 不必从零构建业务逻辑,而是作为协调层,聚合已有系统能力(MCP/RPA)并承担决策编排。这对团队的技术栈选型提出明确要求——需同时具备服务封装、界面自动化与自然语言理解的集成能力。
- RAG 知识工程在此案例中未被显式提及,但隐含关键约束:自然语言查询的有效性高度依赖业务口径的预先梳理与结构化。若订单状态、产量定义等规则未对齐,AI 回答将脱离实际。这意味着知识治理必须前置,而非仅依赖后期语义增强。
- AI 安全治理的实践锚点由此浮现:人工兜底机制不是功能冗余,而是风险控制边界。当 RPA 因界面变更失效或 AI 编排出现逻辑偏差时,系统必须确保异常可追溯、干预可即时、责任可归属,这对审计日志与权限分级提出刚性要求。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务,帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们


