10 月 26 日，Oracle AI World，拉斯维加斯。一家叫 Pythian 的数据与 AI 咨询公司，和 Google Cloud 一起，干了一件对"遗留 ERP"用户极其解气的事：他们把 Oracle E-Business Suite（EBS）、JD Edwards 9.2、PeopleSoft 这三套最"老古董"的企业系统，用一套开源的 Terraform 部署脚本 + MCP（模型上下文协议）连接器，把迁移到 Google Cloud 的时间压缩到了约 3 小时——并且让 Gemini 智能体可以直接对这些系统的采购、库存、应付、总账、制造模块"说话"和"办事"。
这不是又一家厂商在发布会上画饼。开源代码当天就挂在 Google Cloud Architecture Center Samples 的 GitHub 仓库里，任何人都能看、能改、能审计。
一、Oracle AI World 上的一记"开源重锤"：遗留 ERP 现代化被重新定义
过去二十年，"ERP 太老、想用 AI"的企业只有两条路：要么花数月做 lift-and-shift 整体搬迁，要么花大钱买专有集成平台把数据抽出来。两条路的共同点是——慢、贵、且把企业锁死在某一家的工具链里。Pythian 这次发布的，是开源的部署资产 + MCP 连接器，直接面向 EBS、JD Edwards、PeopleSoft 三大遗留套件，把"现代化"从"咨询项目"变成了"可复用的工程脚本"。
| 维度 | 传统 lift-and-shift | 开源 MCP 方案（Pythian×Google） |
|---|---|---|
| 迁移周期 | 数月（硬件更新 + 数据搬运） | Terraform 脚本约 3 小时 |
| 接口性质 | 专有 ETL / 中间件 | 开源 MCP（API 集成 + SQLcl/APEX 只读） |
| 智能体能力 | 基本无 | Gemini 直连采购 / 库存 / 应付 / 总账 / 制造 |
| 安全审计 | 黑盒 | DBA 可审计 SQL 执行与 schema 访问 |
很多企业被"老 ERP 拖后腿、又不敢大换血"困住，本质不是系统老了，而是没人敢动、也不知道怎么低成本地把它接上 AI。开源 MCP 给出的答案是：先打开接口，再谈换不换系统。
二、双层 MCP 架构：把封闭 ERP 拆成"可读可写"的开放接口
这套方案的技术核心是一个多层的 MCP 框架。第一层是"API 集成层"，直接对接 Oracle Integrated Service Gateway、JD Edwards Orchestrator 等应用 API，做安全的事务处理和业务逻辑执行；第二层是"数据库只读层"，用 MCP 包住 Oracle SQLcl 和 APEX REST 服务，做高性能的只读分析和数据检索。两层分工明确：写走 API（业务规则由 ERP 把关），读走数据库（分析不污染事务）。
更关键的是"领域技能（Domain-Specific Skills）"——开箱即用的智能体技能模板，直接映射到核心业务模块：Procurement（采购）、Inventory（库存）、Payables（应付）、General Ledger（总账）、Manufacturing（制造）。这意味着 Gemini 智能体能自动跑采购工作流、拉库存记录、做对话式分析，而不再需要人把数据导出来再喂给 AI。
安全上也没偷工：严格遵循企业安全标准，支持 Google Cloud IAM（OIDC 身份令牌）、凭证库（credential vaulting）、身份联邦（兼容 OCI Identity Gateway）。开源架构的好处之一，就是 DBA 能完全透明地审计每一次 SQL 执行和 schema 访问。
三、为什么是"开源"而不是"专有连接器"——这是 AI 时代解锁遗留系统的关键
很多 CIO 会问：这不就是个连接器吗，SAP、Oracle 自己也有集成工具，何必强调"开源"？答案藏在 AI 时代的两条铁律里。
第一，智能体要"干活"，前提是系统得把动作暴露成开放、可组合的接口。MCP 现在已经是智能体连接企业系统的准标准（10-25 我们聊过微软给 D365 加语义索引 MCP、10-15 Workday 用 MCP 接 Claude/Gemini、10-11 SAP 推 Business AI Framework）。如果连接器是某家专有的、不透明的，智能体就被锁死在那个生态里，企业数据主权也跟着失守。
第二，呼应监管现实。10-21 我们写过《智能体安全强制国标》——计划号 20263116-Q-252，要求可控性、全流程留痕、数字护照三道硬约束。开源意味着代码可审、行为可验、风险可查，恰恰是"可控"和"留痕"的工程化前提。而 10-23 那篇讲的智能体供应链攻击，根源之一就是闭源组件不可审计。把 ERP 接口做成开源 MCP，等于给智能体的"手"装上了透明手套。
但也要泼盆冷水：开源 MCP 解决的是"接口与编排"，不解决"数据质量"和"流程治理"。如果 EBS 里的物料编码、供应商主数据本身就是脏的，3 小时搬上云、接上 Gemini，只会让 AI 更快地给出错误结论。接口是高速公路，数据才是车上的货——这一点，和 08-07 那篇"94% 采用率 vs 2% 规模化"的结论一脉相承。
四、给 CIO 的实操建议：先开接口，再谈换系统
开源 Terraform 把 Oracle EBS / JD Edwards / PeopleSoft 迁移到 Google Cloud 的实测目标周期
落到实操，给正在被"老 ERP 拖后腿、又不敢大换血"的 CIO 三条建议：
- 先做"遗留资产盘点"，而不是急着立项换系统。把还在跑 EBS/JDE/PeopleSoft 的模块、数据量、接口依赖列清楚——很多时候，问题不是系统老，而是没人敢动。
- 用开源 MCP 做"最小可行试点"。选一个数据相对干净、流程标准的高频模块（比如应付发票匹配、库存查询），接上智能体跑通"对话式检索 + 自动执行"，用 3 小时迁移的轻量成本验证价值。
- 把"智能体治理"前置。接口开源了，权限和留痕必须同步上桌：谁能调用写接口、每次执行是否留痕、异常是否可回滚——这些要在试点第一天就定规则，别等出事再补。
写到最后想说一句：AI 时代，遗留 ERP 不一定要"被替换"，但一定要"被打开"。Pythian 和 Google 这记开源重锤说明了一件事——企业最值钱的不是那套跑了很多年的老系统，而是它肚子里几十年的业务数据与流程；谁能把这些用开放接口交给智能体编排，谁就先把 AI 落了地。先开接口，再谈换系统，这个顺序，绕不过去。
本文基于公开信息整理分析：Pythian 官方新闻稿《Integration with Gemini to Help Accelerate Cloud Migration for Oracle Applications》（2026-10-26，Oracle AI World 拉斯维加斯）；Google Cloud Architecture Center Samples（GitHub 开源仓库）；关联 10-25 微软 D365 语义索引 MCP、10-15 Workday Lawful by Design、10-21 智能体安全强制国标、10-23 智能体供应链攻击。数据截至 2026-10-30。
众谛信息 · 专注 Odoo 与企业管理数字化解决方案
