11 月 2 日 diginomica 發了篇訪談，主角是液壓元件廠商 Brennan Industries 的 CIO Ryan King。他說自己用 Claude Code 和 OpenAI Codex，在 NetSuite 裡寫了一個銷售詢價屏，一個下午做完。
這螢幕幹的事不複雜：客服接電話時，一邊查價格和交期、一邊把這次溝通的背景順手寫回 CRM。過去這些對話細節經常就丟了，因為要額外跳好幾個頁面去補錄。現在錄入變成了接電話這個動作本身的一部分。
讓我停下來的不是「一下午做完」，而是他給的理由之一——控制 token 消耗。他沒讓 AI 代理每次替客服跑一遍操作，而是讓 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 靠訂閱、服務、資產管理拼裝 | 多供應商、多合約、多整合與升級節奏，上下文容易斷在介面處 |
| 併購補齊版圖 | 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 生成。
