11 月 2 日 diginomica 发了篇访谈，主角是液压元件厂商 Brennan Industries 的 CIO Ryan King。他说自己用 Claude Code 和 OpenAI Codex，在 NetSuite 里写了一个销售询价屏，一个下午做完。
这屏幕干的事不复杂：客服接电话时，一边查价格和交期、一边把这次沟通的背景顺手写回 CRM。过去这些对话细节经常就丢了，因为要额外跳好几个页面去补录。现在录入变成了接电话这个动作本身的一部分。
让我停下来的不是「一下午做完」，是他给的理由之一——控制 token 消耗。他没让智能体每次替客服跑一遍操作，而是让 AI 帮着把工具写出来，工具固化成 SuiteScript 留在 ERP 里，之后反复运行的只是普通代码。
这是个很务实的判断。同一周，几家大厂在讲几百个智能体、AI 原生工作台；另一边，一个制造业 CIO 在算每次调用要不要花钱。两边都对，只是把 AI 放在了系统的不同层。
一、造工具，还是跑操作
把这两条路线摆开看，差别挺清楚。
AI 跑操作
每次业务发生都请模型判断一次，灵活、覆盖长尾，但成本随交易量走，且每次输出都要复核
AI 造工具
模型参与一次性开发，产物是确定性的脚本或模块，之后按既有权限运行，边际成本几乎为零
我没有要否定前一条。像供应商确认、异常对账这类长尾流程，规则写不全，让智能体边读边判断确实更合适。但把高频、稳定、每天跑几千次的动作也交给模型，账就不一定划算了，而且每次都多一个需要人盯的不确定点。
King 还提了一句，指挥这些编码工具仍然需要非常具体的 NetSuite 流程知识。这话我特别有共鸣。生成一个能跑的界面和交付一个能维护的应用，中间隔着一串没人能替你答的问题：这个脚本能改哪些记录、输入怎么校验、谁能用它、下次版本升级怎么回归测试。Oracle 现在给 SuiteCloud 插件同时配了 Codex 和 Claude Code 的支持，文档里也把权限、安全编码、部署串起来讲，恰恰说明「写得快」不等于「能上线」。
Workday 11 月 5 日那份 Gartner 服务型企业云 ERP 魔力象限（连续第五年领导者）里有个说法我很喜欢，叫 agents lawful by design：智能体继承组织里已经在跑的策略、权限和审批链，动作发生在既有业务控制之内，不是另起一套。这跟 King 把脚本放进 SuiteScript、由 NetSuite 既有角色管着，其实是同一个思路——AI 的产物要落在原来的权力结构里。
做了几年实施，我越来越觉得判断一个 AI 功能靠不靠谱，先看它出问题时能不能被原来的权限体系拦住。拦得住，是功能；拦不住，是另一个系统。
二、把业务逻辑从界面里拆出来
11 月 5 日 Epicor 宣布进了《IDC MarketScape: Worldwide AI-Enabled Manufacturing ERP 2026 Vendor Assessment》（编号 US54115426，10 月发布）的领导者类别。IDC 的评语是「垂直广度配子行业深度」，这类话我一般扫过就算，但它的产品构成值得拆一下。
Kinetic 是打底的云 ERP；Prism 把行业智能体嵌进工作流，能做自然语言查询、异常检测和自动动作；Lux 是一套受治理的智能体设计系统；Agent Foundry 让客户和伙伴自建、验证、共享智能体。真正有意思的是最后一项：headless ERP，把业务逻辑和界面解耦，外部 AI 工具可以经开放的 MCP 连接，直接碰到 ERP 的数据与规则。
为什么这件事比多几个智能体重要？过去外部 AI 想接 ERP，要么模拟人点界面，要么为每个场景做定制接口，而大量业务规则其实藏在 UI 的操作顺序里，接口根本够不着。解耦之后，规则本身成了可被调用的东西，智能体不用再靠「看屏幕」去猜企业怎么做事。
Ascend with Epicor 让合格客户的核心业务流程最快跑起来的周期；约 87% 新客户选择云部署
另外两组数字也别跳过：82% 的存量本地客户已经转到云，伙伴约 1,800 家。它们说明一件事——架构讲得再漂亮，交付能力还是靠实施网络撑着。AI 没有让这部分变轻，只是把难点从「配表单」挪到了「理规则」。
规则暴露得越彻底，权限越不能含糊。MCP 这类开放连接把读能力交出去的同时，也把「谁能读哪张表、哪个字段」变成必须逐条落地的配置。别用一个全权限的服务账号图省事，那等于给所有外部智能体配了一把万能钥匙。
三、长在核心里，和外挂上去，差在哪
微软这一周的动作给了个很好的对照。Dynamics 365 Supply Chain Management 的租赁管理进入公开预览，从报价、合同、车队调度、检修，到按合同周期开票、过总账、固定资产折旧，整条资产生命周期都在 ERP 核心里。Copilot Cowork 的插件能从客户邮件里识别设备、查可用性、起草回复并发起租赁报价，然后交给人复核。用他们 AI ERP 负责人 Georg Glantschnig 的话说：协调员保持控制，智能体负责装配。
他还有一句更该被记住：智能体的用处，取决于它够得着的流程和数据。设备可用性在一个应用、费率在另一个、资产台账在第三个，智能体连一份报价都拼不出来。
| 路径 | 代表做法 | 对智能体的直接影响 |
|---|---|---|
| 流程原生在核心 | 微软把租赁做进 Dynamics 365；Odoo 用 Studio / 模块 / MCP 把规则留在同一库 | 一次调用可读到完整上下文，动作落在既有事务与权限里 |
| 靠伙伴插件补齐 | SAP 的 FIT-Rent、BearingPoint Lease & Rent；Oracle 靠订阅、服务、资产管理拼装 | 多 vendor、多合同、多集成与升级节奏，上下文容易断在接口处 |
| 并购补齐版图 | Priority Software 11-05 收购 Fireberry，把 CRM / 营销 / 客服并进云 ERP | 目标是客户与业务数据的单一真相源，但主数据合并仍是工程活 |
Priority 那笔收购值得多说一句。它在 11 月 5 日的公告里反复强调「single source of truth for customer and business data」，说白了就是承认：客户在 CRM 里叫 A、在 ERP 里叫 B，模型再强也只能给出互相打架的答案。这跟微软把租赁做进核心，动机是同一个——先把数据和流程放对地方，再谈智能。
顺带说 Odoo。它在这条线上位置比较特别：开源、同库、模块化和 Studio 让业务规则本来就长在数据库这一侧，加上原生 MCP，外部工具接进来不需要另建一套数据副本。这不是说它开箱就能替你跑智能体，而是「让智能体够得着」这件事的改造量小很多。做选型的时候，这一条比功能清单里多几行 AI 更值得问。
四、边界划在哪：实施前要答的三个问题
一、哪些流程长在系统里？把要交给智能体的流程列出来，逐个确认它的规则、数据和事务边界是不是在同一个系统里。凡是靠插件、Excel 或人工口传补齐的环节，就是智能体会断掉的地方。先补流程，别先补模型。
二、哪些动作交给智能体，哪些写成代码？高频、稳定、规则清楚的动作写成脚本或模块，按既有权限跑；长尾、例外多、需要判断的再交给智能体。Brennan 那个下午的价值，不在生成速度，在这道分层做对了。
三、边界之外的数据往哪走？开放连接越方便，越要把「谁持密钥、按什么身份读、上下文发到哪、日志留在哪」写成可核查的配置。规则和权限是同一件事的两面，拆开谈迟早出事。
还有一个常被漏掉的边界：版本。Odoo 19 的 agent 用 Topics，20 用 Skills，配置模型变了；升级之后 AI 工作流要像财务流程一样重新验收，而不是看界面能打开就算迁移成功。同理，任何把规则暴露给外部工具的架构，版本升级都得回归一遍调用方。
给 CIO 和做实施的同行的落地建议，我倾向从小处起手：挑一个高频、规则相对清楚、又确实让一线烦的流程，先判断它该写成确定性代码还是交给智能体；把权限、日志、回滚配齐，跑满一个月再决定要不要扩到第二条。比起动辄铺几百个智能体，这种节奏更容易在季度复盘时拿得出证据。
这一周厂商讲了很多关于模型的事，但真正决定项目结果的，还是那些不太上发布会的东西：流程长在哪一层，规则能不能被调用，权限拦不拦得住，升级之后还在不在。
智能体不会比它够得着的流程更聪明。先把系统里的路修通，再放它进来跑。
资料来源：ERP News / diginomica 对 Brennan Industries CIO Ryan King 的访谈（2026-11-02）、BusinessWire / Morningstar（Epicor IDC MarketScape #US54115426，2026-11-05）、Agent & Copilot 关于 Dynamics 365 租赁管理与 Georg Glantschnig 表述的报道（2026-11 上旬）、PR Newswire（Priority Software 收购 Fireberry，2026-11-05）、Workday / PR Newswire 2026 Gartner 服务型企业云 ERP 魔力象限（2026-11-05）、Wavect 关于 Odoo 19→20 AI 工作流验收的分析（2026-11-05）。
本文由广州众谛信息科技整理撰写，供企业数字化负责人与实施团队参考，不构成采购建议。配图为 AI 生成。
