很多企业的老 ERP 确实不够好用：界面老、流程长、数据查询不方便。但它也往往承载着最难替换的东西： 多年积累下来的交易记录、库存口径、财务规则和业务习惯。

所以，老 ERP 接 AI 的第一步，应该是先把接口、业务能力、自动化执行和人工审核的边界划清，项目才能走得稳。

老 ERP 要守住什么，AI 该做什么

先看一个常见场景。一张订单可能来自客户门户、邮件附件、Excel，甚至是一张聊天截图。文员需要识别客户、价格、交期，再去 ERP 里查库存、录单、提交审核。如果信息不完整，还得在销售、仓库和客户之间来回确认。

这类工作里同时混着四种事情：

• • 有人提出业务需求；
• • 系统里有现成数据和规则；
• • 有一些固定的点击和录入动作；
• • 有些异常必须由人判断并承担责任。

如果把它们都交给一个“万能 Agent”，风险会迅速积累。模型拿到过多数据、过大权限，出了问题也很难判断是规则错了、接口错了，还是页面操作错了。所以，划清职责很重要：谁负责判断，谁负责执行，谁负责兜底。

这三个问题分清后，技术选择才有意义。可以把整体架构理解为四层：

• ERP 继续担任交易、库存和财务的权威账本。

• AI Agent 处理人的表达、信息归类、流程选择和异常说明。

• 中间的MCP业务服务层，负责把权限、字段、规则和日志收住。

• 优先API，RPA 只覆盖那些没有接口、但页面和动作足够稳定的最后一公里。

老系统现代化，先改的是账本周围那些靠人搬运、解释和确认的动作。

先盘点接口，别急着把问题交给 RPA

可能有厂商 API、导入导出能力、报表视图或中间表。具体能不能用，要看版本、授权范围和维护状态。但做方案前，可以先瞄一下这四档盘点：

接口优先，因为接口更容易被追踪、测试和复用。

但是，此处要划清一条红线：没有接口，不等于可以绕过授权直接改生产数据库。

查询和分析可以使用受控的只读视图；涉及订单、库存、财务的写入，应走厂商支持的方式，或者封装成可审计的业务操作。

MCP 连的应该是业务能力，不是一张裸露的表

读者问“MCP 怎么连 ERP”，这个问题可以换成更实用的问法：你准备让 Agent 调用哪一项业务能力？

例如，管理者问：“今天还有多少待发货订单？”

一个受控的调用链可以是：

业务问题：今天有多少待发货订单？
        │
Agent 调用：query_pending_shipments
        │
校验：当前用户权限、查询时间范围、可返回字段
        │
ERP API  只读数据视图
        │
返回：订单数、异常数、必要的订单摘要

MCP 在这里像一个“有说明书的业务接口”：它知道谁能调用、能查什么、最多返回什么，以及调用过程如何留痕。

如果把整张订单表、历史聊天记录和系统日志一股脑交给模型，模型未必判断得更好，上下文和数据暴露面却会更大。对“待发货订单”这个问题，模型通常只需要订单号、客户、状态、计划发货时间和异常原因。

所以，一个能长期维护的 MCP 工具，建议有四个约束：

• • 一次只完成一件明确的业务动作；
• • 只返回判断所需的字段与摘要；
• • 写操作带业务单号、幂等键、执行结果和审计日志；
• • 权限沿用企业原有的组织和岗位边界。

例如“创建销售订单”这项能力，不能只接受一段自然语言就直接写入。它需要校验字段、识别重复提交、记录发起人和返回结果。AI 负责组织调用，业务规则仍放在可检查、可回溯的位置。

RPA 适合做手脚，别让它去当大脑

RPA 的价值很具体：在固定页面上完成登录、查询、填表、提交、下载、上传等重复动作。

它的局限也同样具体：按钮位置变了、字段名改了、登录状态失效、验证码出现、网络抖动，都可能让流程中断。尤其是跨客户系统时，每一家客户的页面、账号策略和异常提示都不同，维护成本会明显上升。

数据安全，要落到权限、字段和日志上

财务和订单数据能不能交给云端 AI，没有一句适用于所有企业的答案。数据分级、客户要求、部署方式和供应商能力不同，方案就不同。

但安全要落到架构与项目管理里，至少应检查以下几件事：

• • Agent 不持有 ERP 超级管理员账号；
• • 财务金额、客户身份、合同等敏感字段按需返回，必要时脱敏或摘要化；
• • MCP 按既有组织权限执行，不因接入 AI 扩大查询和操作范围；
• • 查询、调用和写入都保留审计记录。

因此，我从技术架构和项目管理的角度看，安全的关键在于让权限、数据流向和责任边界能够被检查、被追踪、被收回。做到这一点，团队才有条件逐步扩大自动化范围。

中小企业怎样开始，才不会变成一次大改造

最容易失控的做法，是一开始就提出“AI 改造 ERP”。范围大、角色多、依赖复杂，项目很快会陷入讨论，却迟迟没有可验证的结果。

更稳妥的路径是从一个高频、规则清楚、可回退的小流程开始：

1. 1. 先做只读场景。 例如经营查询、日报解释、库存或订单异常提示。先验证数据口径、权限和回答是否可靠。
2. 2. 再做半自动场景。 例如整理邮件或 Excel 订单，生成 ERP 导入草稿，由人确认。重点验证字段映射、异常类型和审核效率。
3. 3. 最后做受控写入。 对稳定 API 或稳定页面启用执行，设置调用额度、重试上限、失败告警和人工兜底。

每推进一步，都记录失败原因和人工介入点。运行一段时间后，团队才知道哪里值得补接口、哪里需要优化字段，哪些动作仍然应该留给人。

如果你正在评估这类项目，可以先做一个很小的动作：选一个流程，列出它的输入来源、关键字段、业务规则、最终执行系统、异常类型和负责角色。把这几项写出来，再讨论 AI、MCP 和 RPA 各自该放在哪里。

写在最后

不换 ERP，并不意味着不能AI提效。

老 ERP 继续守住账；API 和 MCP 负责把已沉淀的能力安全开放出来；AI Agent 负责理解和编排；RPA 覆盖没有接口但足够稳定的动作；人保留高风险判断和最终授权。

你们公司里最耗人的“伺候系统”动作是什么：录单、查数据、做报表，还是跨系统搬运？如果只能选一个先改，你会从哪一个开始？

阅读原文：点击这里​