智能体时代AI原生ERP与MES的创业机会(2)

AI原生初创企业对SAP“洁净内核”的解耦重构

在开发企业级智能体ERP或MES时，创业者最常犯的错误是允许智能体直接对底层的业务数据库（关系型数据库中的核心表单）进行写操作。

这种无保护的系统耦合在面临模型幻觉、 prompt 注入攻击或业务流异常时，会导致企业核心账目的灾难性混乱。

为了解决这一痛点，初创企业必须借鉴SAP在2025/2026年全面推行的“洁净内核”（Clean Core）设计思想。

洁净内核的核心原则是保持ERP/MES标准核心系统的标准化与免修改性，将所有客制化的开发、流程扩展及AI智能体的自主逻辑移至核心系统之外。

在这一思想的指导下，SAP将系统扩展分为四个合规等级，初创企业在设计智能体交互时应当对其进行深度参考。

表3：SAP 洁净内核（Clean Core）可扩展性合规评级与智能体适配模型

合规评级	技术定义与扩展边界	系统升级与维护影响	智能体（Agent）对接与安全执行策略
Level A (最洁净扩展)	仅使用官方发布的云优化APIs（如ABAP Cloud）和旁路式应用（Side-by-Side Extensions，部署于BTP等平台）	升级无感，技术债为零，年度系统维护费用可降低25%-35%	唯一推荐的AI执行级别。智能体在独立的轻量级沙箱中运行，通过发布的安全API与核心交易引擎交互，杜绝数据越权与系统破坏。
Level B (合规传统API)	允许利用经典的、但已被官方标记为稳定的SAP标准API及接口框架	升级风险处于可控范围，需要轻量级的自动化兼容性测试	限制性使用。智能体必须经由标准网关调用此类API，且系统需配置流量控制与操作行为审计。
Level C (受条件限制级)	使用了非公开的系统内部对象，但建立了严格的变化变更日志（Changelog）与前置监测机制	升级存在阻碍风险，必须使用ABAP测试 cockpit（ATC）工具在每次发布前运行全量回归	极不推荐。智能体的调用可能由于核心库版本的微小变更而发生意外阻断。
Level D (非标准修改级)	直接对系统底层表进行物理写入，或者修改了系统交付的标准事务代码	导致系统版本锁定，系统验证和代码重组需要3-6个月，技术债高企	完全禁止。智能体绝对不允许触及该级别，否则系统将丧失最基本的交易安全与数据一致性。

为了将上述等级制度转化为具体的、可落地的初创系统架构，创业者在进行系统研发时，需要推行两套确定性的技术方案。

首先是采用旁路式（Side-by-Side）开发范式。

初创企业应当将所有的智能体推理、规划、Token消费及外部API路由逻辑，全部放置在独立的微服务容器内（如基于Node.js或Python的运行环境），这类似于SAP Business Technology Platform（BTP）的隔离定位。

标准ERP/MES核心则充当一个“无知觉的事务执行引擎” 。

例如，当智能体通过分析供应链数据决定修改某张工单的上线时间时，它不能直接去Update数据库中的工单时间字段，而必须构造一条标准的OData或JSON-RPC请求，投递给核心系统的API关口。

核心系统在收到请求后，会在其自身的事务安全边界内运行逻辑校验（如检查物料锁、工艺路线冲突等），验证通过后才执行写入。

其次是构建“Live Sandbox”（实时沙箱）验证机制。

在高度客制化的企业场景中，用户往往会用自然语言要求系统修改业务流，例如“当设备报警超过三次时，自动挂起工单并给物料智能体发件询价” 。

此时，系统底层的AI工程师（如Tangle的Milo，或Everest的AiSpecify）会在镜像生产环境的沙箱中动态生成并测试这段新工作流。

在沙箱环境中，系统会自动模拟运行该规则，检测其是否会造成死锁、权限越界或逻辑冲突。

只有在沙箱中完全通过测试，并且触发了人类管理员的物理审批（Human-in-the-Loop门禁）之后，该扩展逻辑才会被安全地编译并推送到Level A生产环境。

这既给予了企业用户无限定制系统的灵活性，又保全了系统核心的安全完整。

极简化的单一数据源：借鉴SAP“万能日记账”重塑底层账合一设计

在传统的ERP设计中，由于底层硬件算力的局限性，软件架构不得不采用高度碎片化的表单结构。

例如，在老一代的SAP ECC系统或传统的国产财务ERP中，一个简单的销售记账事务会同时写入总账表（GLT0/FAGLFLEXA）、明细账表（BSEG）、控制会计表（COEP）、资产折旧表（ANEP）以及物料分类账表（MLIT）。

这种设计模式带来了一个致命缺陷：系统内部充斥着物理冗余和各模块间的临时中间表，月末结账时，财务团队需要花费几天甚至几周时间进行海量的跨模块对账和差额调整。

SAP S/4HANA最核心的突破之一，就是通过HANA内存数据库的强劲算力，彻底废除了这些碎片化的物理汇总表，引入了万能日记账（Universal Journal，技术表名为 ACDOCA）。

对于AI原生企业软件的创业者而言，这一设计具有极高的借鉴价值。

在智能体运行环境中，如果底层数据模型高度割裂，智能体在试图回答一个跨域问题（如“分析本季度因为高精度曲轴质量问题导致的财务毛利波动”）时，需要跨越财务、质检、采购等多张物理表进行多级Join关联，这不仅耗费极高的Token，更会因长上下文链条导致智能体产生严重幻觉与推理中断。

因此，初创企业应借鉴ACDOCA的哲学，重塑底层数据底座。

表4：传统企业数据库与AI原生数据库架构演进对比

架构特征维度	传统企业数据库架构 (如 SAP ECC)	SAP S/4HANA 架构 (ACDOCA 万能表)	AI原生ERP/MES账合一架构 (如 Rillet/Flow)
底层持久化表结构	GSEG、COEP、BSIS、ANEP等数十张物理子表并存	统一的物理行项目明细表（ACDOCA）作为单一真实数据源	极简行项目宽表，原生嵌入JSON型多模态元数据元组
对账与数据冗余度	存在大量中间 totals 汇总表，数据冗余，月末需手工对账	依靠数据库即时压缩，零物理冗余，对账机制在设计上被消除	物理零冗余，由AI智能体执行流式实时对账与连续核销（Continuous Close）
核心计算处理模式	批处理（Batch），每天或每夜定时刷新索引与报表	HANA内存计算，行明细数据即时聚合（On-the-Fly Aggregation）	连续流处理，利用列式存储实现微秒级全局明细拉取
AI/智能体对账友好度	极低。智能体难以在复杂的跨表关联中定位数据血缘	中。单表提供极细颗粒度，但缺乏语义图谱支撑	极高。AI直接面向统一宽表，数据天然结构化，查询路径最短

在具体的工程落地中，初创企业应当取消所有独立的应收、应付、固定资产、物料、成本控制子模块表，将所有的商业凭证统一抽象为“事件流明细表”（类似于ACDOCA明细行）。

每个商业事件进入系统时，仅写入 BKPF（凭证头信息）和包含了所有分析维度（公司代码、业务流、物料号、利润中心、客户标签等）的单一张明细行记录表中。

当需要生成任何层级的管理报表或财务披露时，系统不进行任何预先物理计算，而是通过列式数据库的高速检索，由AI智能体直接调用底层明细数据进行即时计算（On-the-Fly Calculation）。

同时，系统应当采用账户制（Account-based）盈利分析，使得任意一笔采购订单或工单的执行状态，能够瞬时呈现在财务损益明细中。

这种“单一真实数据源”的数据底座，不仅消除了对账的技术债，更为AI智能体进行实时归因分析、异常账务自动冲销和自动化关账打下了极其坚实的数据管道。