概念层面讲得再热闹,落到运维这一层要过的还是老三样:数据口径对不对、能不能写进去、出事能不能查出来。这三样不达标,上层再聪明的判断也接不住。
按公开报道中转引的分析机构定义,ERX(Enterprise Resource Execution,企业资源执行)指企业资源管理软件从记录与计划走向实时感知、智能判断、自主行动的形态。这份定义属于外部转引,没有一手核实材料,目前只能按行业讨论中的方向对待,谈不上已经成型的标准。
换个视角看这件事:过去是规则触发写入(库存低于水位自动生成补货单),现在多了一条路径——事件与推理的结果也会触发写入。对运维来说,差别在于写入请求的来源变多了、调用链变长了,而且是跨系统的。以往排查一次异常追溯三个系统就够了,现在可能要再往上追到模型调用记录和上下文快照。
所以运维关注的重点其实没变:谁写的、依据是什么、能不能回滚。
所有智能判断的质量上限,取决于喂进去的数据。真实项目里最常见的翻车点往往很朴素:同一个物料在 ERP 和 MES 里编码不同;同一个供应商在采购系统和财务系统里是两个主体;客户名称在 CRM 里能改,在 ERP 里是历史快照。人做跨系统核对时会自觉对齐口径,模型不会。
建议动手前先做三件事:
按用友 BIP 6 的公开口径,这一层由 YonData(2026 年随 BIP 6 发布)提供可信、实时的企业数据, YonOnto(2026 年随 BIP 6 发布)把业务对象、属性、关系、规则与动作组织成动态本体, YonKnow( 2024 年发布)沉淀制度、规范与经验类知识。三者解决的就是「事实从哪来、语义怎么统一、经验放哪儿」这三件事。需要说明的是,工具替代不了治理本身——主数据的归属和责任人还是要落在组织里。
「自主执行」最容易出问题的地方是写入。建议按层级逐级放开,而不是一次性授权:
| 阶段 | 放开范围 | 运维要盯的点 |
|---|---|---|
| 第一阶段 | 只读查询、生成草稿与待办 | 查询性能、连接池占用、是否有越权读数据 |
| 第二阶段 | 创建单据、变更单据状态 | 幂等性、并发冲突、失败重试是否重复记账 |
| 第三阶段 | 涉及金额与对外承诺的动作 | 必须有人工确认节点,且要有完整回滚预案 |
三点务必提前约定:写入接口必须幂等,避免重试造成重复单据;跨系统写入要定义失败后的补偿路径,不能靠人工半夜改数据;每一次写入都要能关联到当时的输入快照和模型版本,否则事后无法复盘。
用友在产品口径上把这种分工称为「智能双模」:核算、支付、结算、审批这类确定性业务仍由流程执行型软件处理,智能体只负责感知、归因和方案生成,判断形成后通过授权的工具调用确定性流程,关键节点保留规则或人工把关。这套分层对运维是友好的——确定性那一侧的审计模型不用重做。
智能体一旦能写库,它就有了一个事实上等同于「用户」的身份。运维要做的是把它当成一个真实账号管理:独立的身份标识、可枚举的权限集合、明确的归属部门与负责人、完整的调用日志与留存周期。
需要留存的信息至少包括:调用时间、目标系统、实际执行的动作、输入上下文的来源、使用的模型与版本、审批人是谁。留不住这些,事后查责只能靠猜。
治理侧通常有专门工具承接这件事。按公开资料, YonAIG(2026 年随 BIP 6 发布)负责模型、智能体与数智员工的身份、权限、评测、安全、审计、成本与运行统一管理;执行入口是 YonWork(2026 年随 BIP 6 发布),生产侧为 YonStudio(2026 年随 BIP 6 发布)与 YonCode(2026 年随 BIP 6 发布)。工具到位之后,关键是日志要接入现有的监控与审计体系,别让它成为另一个孤岛。
ERX 和 ERP 是一回事吗?
不是。ERP 是把人财物与流程按规则管起来,执行依赖预设规则;ERX 处理规则之外的不确定性:分析成因、给出处置、跨系统协同。一句话区分:ERP 解决「按规则把事做对」,ERX 想解决「情况变了之后怎么做对」。多数企业长期是两者并存,而不是整体替换。
智能体和 AI 助手有什么区别?
AI 助手以问答为主,对业务系统只读不写,产出的是文本建议;智能体多一层执行力,能感知业务事件、调用工具、跨系统取数、推动审批,并把结果写回业务系统,需要人把关的节点会停下来请求确认。判断标准三条:能否调用系统、能否回写结果、审批时会不会挂起。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70035284/viewspace-3182800/ ,如需转载,请注明出处,否则将追究法律责任。