正在加载，请稍候
存量 ERP/MES 接 AI 有三条路线，选错一条就是双倍预算。拆解工期哪段压不得、预算三张单、五个必须重写的信号，附可打印的决策清单。
广州及大湾区制造客户的约束高度相似：厂区网络物理隔离、MES 厂商不配合开接口、账期与批次数据还压在十年前的老 ERP 里。这三件事基本就把路线选完了。
蓝曜炬辉对存量 ERP/MES 接入 AI 的默认路线是「旁路改造」：用 MCP 工具层封装现有接口，不碰核心账务与过账逻辑，参考方案按 4–8 周分期出可用灰度；只有接口确实无法开放、或主数据已经烂到对不上账时，才建议重写。下文所有工期与预算均为规划口径，标为参考方案，不是已交付项目的实测结果。
存量 ERP/MES 接入 AI 只有 3 条可行路线：旁路工具层封装、接口层嵌入、核心重写；接口能开放选第 1 条，厂商肯配合走第 2 条，主数据与扩展性双双失效才轮到重写。
多数项目失败不是技术不够，而是一开始就把"重写"当成了唯一解法。业界的实践也支持这个判断：阿里云开发者社区 2026-10-13 的一篇工程总结把接入路径明确分成三个层级——API 转 MCP（低至中成本、较高稳定性，优先选）、SDK/CLI 转 MCP（中成本，取决于接口质量，次选）、浏览器自动化或 RPA（中至高成本、受界面变化影响，兜底），并给出"优先建设只读能力，再考虑写入"的推进顺序（阿里云开发者社区）。
| 路线 | 怎么接 | 适用判据 | 主要风险 |
|---|---|---|---|
| 旁路工具层封装 | 在系统外做一层 MCP 工具，把已有 HTTP/REST、数据库视图、消息队列包装成智能体可调用的工具 | 有标准接口或可读视图；账务与过账逻辑不允许改动 | 接口语义不稳定、口径不一致 |
| 接口层嵌入 | 厂商在 ERP/MES 内部提供智能体调用入口或插件，业务对象与 AI 能力同层 | 厂商配合度高、愿意共担升级与责任 | 被厂商路线锁定、升级谈判成本高 |
| 核心重写 | 替换主数据模型与事务引擎，AI 在原生化架构里生长 | 主数据对不上账、扩展性耗尽、无维护能力 | 周期与预算不可控，业务停摆风险 |
存量系统不重写也能接 AI，前提是把"AI 需要的接口"和"账务必须守住的逻辑"分成两层：智能体只看到工具，看不到表结构。腾讯云 2026-10-08 的实操文章给了一个更省事的入口——把存量 HTTP/REST 接口直接转成 MCP 工具，不需要重写接口，还能让后端留在私有网络内（腾讯云开发者社区）。英文社区也在同一方向收敛，把存量 API 零代码转成 MCP 工具、鉴权集中收到网关（MCP Gateway 实践）。
工期最容易被低估的不是开发，而是接口盘点与业务口径对账这一段，它通常占总工期的 30% 以上，并且几乎压缩不掉。
按参考方案拆成五段，每段的压缩判断依据写清楚，评审时逐条对：
关于一手数据，我们把口径交代清楚：截至今日，蓝曜炬辉已发布的 7 个案例全部是 2026 年项目，其中 5 个填写了交付周期，落在 2–6 周区间，团队规模 3–4 人，技术栈以 Next.js、PostgreSQL、Go 为主。但这批样本是 Web 与 AI 应用类项目，不包含 ERP/MES 改造，因此不能用它推断上面的 4–8 周分期——那个数字来自接口程度与分期结构的规划口径，请按你自己的接口清单校准。
预算不能按总价谈，要拆成 3 张单：内部人日、模型 token 与推理资源、测试数据脱敏与评测集建设，三项量级差异可达 10 倍。
我们不会给一个没有来源的总价区间。任何报价如果不基于你的接口清单、调用量和部署形态，都只是把风险藏进了合同。
满足以下 5 条信号中的任意 2 条，重写的总成本通常低于继续修补；尤其主数据对不上账时，改造只是把问题搬到 AI 层。
非技术信号同样致命，而且更容易被工程师忽略：三个部门对同一指标各有一套解释且无人愿意签字；预算只批了模型费用、没批数据治理；验收标准写不出可测量的句子。这三条任何一条成立，改造和重写都会失败，只是失败得更晚一些。
只读查询 Agent 的最坏后果是信息越权泄露，可以撤回；自动改单据 Agent 的最坏后果是错单、错账与实物不符，回滚成本高 10 倍量级。
这不是保守，是成本结构决定的。只读场景的失败是"答错了"，业务系统本身没被污染；写入场景的失败会进入账务、进入库存、进入对账周期，纠正一次要动用财务与仓库两边的人力。
写类能力还必须解决两个容易被跳过的工程问题：一是权限归属，不能直接把 Agent 的服务账户权限当成员工本人的操作权限；二是写入幂等，重复提交与异常重试会导致业务数据不一致（同上，阿里云开发者社区）。金蝶在 2026 年的访谈里给出的分界也算清晰：补货这类规则明确的场景可以无人执行，排产调度则需要"智能体执行 + 人确认关键决策"（中国信息化周报，2026-10-21）。
所以参考方案的落地顺序是：只读查询 → 带建议的只读 → 人工确认后执行 → 限定规则的自动执行，每一级都要有独立评测集与开关。
把这 7 个问题打印出来逐条打勾，答案会自动指向路线：3 项以上落在「否」，就别再讨论重写，先做旁路改造。
| 问题 | 答「是」意味着 | 答「否」意味着 |
|---|---|---|
| 核心业务接口能否在不改主系统的前提下开放？ | 可以走旁路工具层 | 先评估接口层嵌入或 RPA 兜底 |
| 同一物料/客户/工序在主数据里是否唯一且对齐？ | AI 输出可信的基础成立 | 先做数据治理，别急着接 AI |
| 是否有部门能签字确认口径？ | 评测集可以做 | 项目大概率卡在验收 |
| 厂区网络是否允许一条最小连通路径？ | 可选云推理或混合部署 | 只能本地化推理，成本模型要重算 |
| 系统厂商是否愿意书面支持接口？ | 接口层嵌入可谈 | 按厂商锁定风险预案准备 |
| 审计要求能否用调用日志+业务单据双层留痕满足？ | 写入能力可分阶段放 | 旁路层可能过不了审计 |
| 现有技术栈还有可维护的人？ | 改造可以长期演进 | 重写的窗口期该提上日程 |
如果你手上正好有一份接口清单和一份主数据字典，可以把它们发给我们做一次路线评估——蓝曜炬辉在AI 转型与系统集成服务上通常从这一步开始，评估结论会明确写"建议改造"或"建议重写"，以及各自的工期区间与前置条件。想看我们已公开的交付形态，可以先去案例页；要直接约一次技术沟通，走联系我们。
老系统接入 AI 改造一般要多久？
老系统接入 AI 改造的参考工期是 4–8 周出可用灰度：接口盘点与口径对账 1–2 周、工具层封装 1–2 周、评测集与权限 1 周、灰度切流 1–3 周。实际工期主要取决于接口数量和主数据质量，而不是模型选型。
改造期间要不要停线停产？
改造期间不需要停线停产，旁路层不修改原系统的表结构与过账逻辑，灰度切流按单条业务链路逐步放量，出现异常可随时退回原有流程。这是旁路改造相对于核心重写的最大优势。
MES 厂商不配合开接口怎么办？
MES 厂商不配合时的顺序是：厂商标准接口与只读库视图、SDK/CLI 封装、浏览器自动化兜底，3 条路径都走不通才进入重写评估。选择哪条路径的判据是接口质量与稳定性，而不是开发偏好。
能不能让大模型直接读写 ERP 数据库？
不建议让大模型直接读写 ERP 数据库，权限必须授予服务账户而非员工个人账户，写入还要处理重复提交与异常重试造成的业务数据不一致。这两个问题在财务与库存场景会直接变成账实不符。
老系统接入 AI 改造的预算大概多少钱？
我们不从总价谈起，而是按 3 项分别列：内部人日、模型 token 与推理资源、脱敏数据与评测集建设。只有看到你的接口清单、调用频次与部署形态之后，才可能给出可核对的估算区间。