文章目錄
2026 年 9 月 28 日 SAP 發表與 NVIDIA 深化合作，把開源的 OpenShell 嵌進 Joule Studio runtime；隔天 9 月 29 日 Oracle 發表 Fusion Claw，一個「受治理的代理執行環境」。兩家都用了「可稽核」這個詞，兩家都說人類設定目標與授權、代理負責執行。很多公司過去一年的態度是「等原廠內建治理再說」，現在原廠內建了，而且兩家把同一件事留成了空欄：代理能簽多大的金額、哪個流程可以全自動、出事誰負責。
這篇把兩家的架構放進同一張表比。比較的格子沿用本站〈AI 代理的內控框架〉的 AI 代理內控五支柱（身分與授權、風險分級、職能分離、軌跡與版本、監控與回測），每一格標三種狀態：原廠做了、原廠給欄位你填、兩家都沒碰。我們把這張表叫 五支柱選型格。今年 8 月我們在〈Fusion、SAP、鼎新的 AI 代理，各給了你多少內控〉用同一把尺量過三家代理當時的功能，這篇量的是 9 月底兩家新發表的治理架構與計價，是那張表的更新版。比較的軸有三條，剛好是財務長會問的三個問題：管到哪（適用範圍）、怎麼算錢（計價）、他們看到什麼（兩家為什麼這樣設計）。
這篇的原則，接在 8 月那篇的「原廠給你的是功能，不是內控——控制設計永遠是甲方的作業」後面。8 月講的是功能與內控的分工；這次兩家把治理做成了產品，分工線往前推到一個更具體的位置，推到核決權限表上那幾個欄位，以及用量計價下的成本上限：原廠把授權留成空欄，因為填空欄的人才是負責的人。 兩家都把「紀錄」那一半做成了產品，「授權依據」那一半，兩家都還給你。
一、管到哪：兩套架構的適用範圍
先平移一個內控的老觀念：寫制度的第一步是界定範圍，哪些系統、哪些交易在制度涵蓋內。對 AI 代理一樣，先問這套治理架構管得到哪些代理。
| Oracle Fusion Claw | SAP Joule Studio runtime＋OpenShell | |
|---|---|---|
| 誰用得到 | Fusion Cloud Applications（ERP、HCM、SCM、CX）的客戶，且須訂閱 Agentic Applications | SAP Business AI Platform 上的 Joule 代理，含 SAP 自家代理與客戶用 Joule Studio 自建的代理 |
| 管哪些代理 | 25 個 Claw-powered 應用（財務的叫 Ledger）；整個 Agentic Applications 系列 75 個；Agent Studio 自建的代理 | SAP 自家的 Joule 代理與助理（財務有 Autonomous Close Assistant、Financial Closing Assistant 等）；Joule Studio 自建代理 |
| 治理做在哪 | 一層，全在 Oracle 自家執行環境內：Operating Envelope 裝規則、Trust Harness 每次執行套控制、Outcome Receipt 事後出收據 | 兩層：OpenShell 管代理「能不能」執行（隔離、看得到什麼、推論送到哪）；Joule Studio runtime 管「該不該」執行（業務授權、角色政策、流程脈絡） |
| 兩層接起來了嗎 | 單一層，授權與執行寫在同一張收據上 | SAP 自己的路線圖寫著：把執行邊界接上授權模型、IAM 與稽核軌跡是「計畫中」 |
| 用的模型 | Gemini 與 OpenAI 的前沿模型，跑在 OCI，將再加其他模型 | 文章未列明模型 |
| 開放性 | 封閉，單一原廠負責 | OpenShell 是 Apache 2.0 開源，SAP 工程師直接貢獻程式碼；Sentry 是綁 BlueField-4 硬體的參考設計，不開源 |
兩套架構各自的細節，分別寫在〈Oracle Fusion Claw 篇〉與〈SAP 與 NVIDIA OpenShell 篇〉，這裡只放比較需要的部分。
這張表有一個 AI 特有的新課題，傳統的範圍界定沒遇過：治理的落點。Oracle 把治理放在執行環境裡面，好處是授權、執行、紀錄三件事在同一個地方，壞處是全部押在一家原廠身上。SAP 把「能不能」交給開源的執行環境、「該不該」留在自家業務層，好處是資安那一層可以被外界檢視，壞處是今天兩層的紀錄還是兩本，接起來的工作目前由客戶自己做。
另一個適用範圍的現實：OpenShell 開源，意思是用鼎新、Odoo 或自建系統的公司，理論上也可以拿它當自己代理的執行環境。但它只管「能不能」，「該不該」那一層在 SAP 架構裡歸 Joule Studio runtime，非 SAP 客戶要自己做。
二、怎麼算錢：兩套計價的結構
再平移一個財務長熟悉的概念：固定成本與變動成本。傳統軟體授權是固定費，一年多少錢寫在合約上，預算可預測。兩家的 AI 代理都走用量計價，變動成本，跑越多付越多。
| Oracle | SAP | |
|---|---|---|
| 計價單位 | AI Units。公式寫在服務說明：（輸入＋輸出 token）÷ 一萬、進位，再乘上動作係數 | AI Units。依官網定價頁，2026 年 SAP 自家的自主代理每個動作 0.02 個 AI Units |
| 每單位公開定價 | 有。價目表 10 萬個 AI Units 美元 1,000，換算一個一美分 | 沒有公開 |
| 平台費 | Agentic Applications 訂閱年費美元 50 萬（價目表定價），每月附 250 萬個共用池 AI Units | Joule Studio runtime 免費到 2026 年 10 月；設計階段存取與官網促銷到年底，之後成為 Premium AI 功能（消耗 AI Units） |
| 免費額度 | 10 月 1 日起每個正式環境每月 3 萬個不可累積的 AI Units | 基本 AI 功能不耗 AI Units；代理類屬 Premium，計量 |
| 代理動作的係數 | Fusion Claw 是獨立動作類型，係數 10 到 20 倍；一般動作 Balanced 模型 3 倍、Frontier 5 倍 | 每動作一價，依官網定價頁 |
| 額度失效 | 每月免費額度用不完歸零；買的共用池期末未用視為放棄 | 未用的 AI Units 12 個月後失效 |
| 預算上限機制 | 服務說明裡沒找到；只有用到負數時 Oracle「得限制、減少或封鎖」功能，以及 30 天前通知可修改係數表 | 公開文件裡沒找到 |
兩家的差別在透明度：Oracle 把公式、定價、免費額度全寫在可下載的服務說明與價目表裡，SAP 的每單位價格要問業務。兩家的共同點更重要：公開文件裡都找不到內建的預算上限。我們在〈AI 的核決權限表〉說過，AI 代理的額度要配「頻率上限」，因為它不累、不睡。放在用量計價的世界裡，這一欄同時變成成本控制：一個全自動、沒設頻率上限的代理，在內控上是風險，在財務上是一筆沒有上限的變動成本。核決權限表的 AI 章節，建議直接多一欄「月成本上限」，由誰監看、超過怎麼辦，寫清楚。
拿 Oracle 的公式粗估量感（示意，不是報價）：一次 Claw 任務吃掉 20 萬個 token、係數 20 倍，就是 400 個 AI Units，約美元 4 元。每月 3 萬個免費額度約跑 75 次；Agentic Applications 訂閱附的 250 萬共用池約跑 6,250 次。SAP 那邊沒有公開單價，同樣的算法算不出來，這本身就是選型時要向 SAP 業務要的第一份文件。
三、他們看到什麼：兩家為什麼這樣設計
比較架構不能只比功能表，要看兩家各自看到了什麼問題，才知道它們的設計會在哪裡強、哪裡弱。
Oracle 看到的是經濟學。 新聞稿把 Claw 的核心講得很直接：每個任務先由前沿模型推理、規劃，再交給確定性的企業運算執行，因為推理貴、執行便宜，把推理只用在需要判斷的地方才划算。這個觀點直接反映在計價上，Claw 的動作係數比一般動作高，用越多推理付越多。治理的設計則是「成果系統」（system of outcomes）：人定義目標、授權與責任，代理把流程跑到成果，事後用 Outcome Receipt 交帳。Oracle 看到的風險是「代理做了什麼說不清楚」，所以它的答案是一張收據。
SAP 看到的是事故。 NVIDIA 在同一天的公告裡把 OpenShell 的動機講得很白：近期的事故顯示代理會反覆繞過應用層的安全控制，所以要把管制放在模型與代理程式之外。SAP 接受這個前提，於是把資安那一層交給 OpenShell，自己守「該不該」那一層。SAP 看到的風險是「代理做了不該做的事」，所以它的答案是一道執行邊界，加一個硬體監看的保全。
兩家都看到同一件事：授權不是它們能填的。 Oracle 寫「在明確委派的授權範圍內全自動執行」，Envelope 裡裝的是「組織的」決策權與核准要求；SAP 寫 Joule Studio runtime 套用的是「業務授權、角色政策、流程脈絡」。兩家都把這一格留給客戶。
兩家都沒碰的三件事。 第一，頻率與成本上限：兩家的公開文件裡都找不到內建機制。第二，模型版本：Oracle 的 Outcome Receipt 列了授權、證據、決策、動作、結果五項，沒有明寫當時用的模型版本；SAP 的文章用了「自我演化的代理」這個詞，當優點講。五支柱說過：不是你改了系統，是系統自己變了，模型更新要比照變更管理。第三，兩本紀錄的接合：SAP 自己列在路線圖；Oracle 是單一層，但 Receipt 怎麼匯出給會計師、保存多久，新聞稿沒寫。
四、五支柱選型格
把以上三節收進一張表。每格三種狀態：✅ 原廠做了、⬜ 原廠給欄位你填、❌ 兩家都沒碰。
| 支柱 | Oracle Fusion Claw | SAP Joule＋OpenShell | 你要填的 |
|---|---|---|---|
| 一 身分與授權 | ⬜ Envelope 裝「組織的」決策權、核准要求；代理身分如何配置待問 | ⬜ Joule runtime 套業務授權與角色；SAP 教材寫「每個代理動作都帶著你的身分與存取權限」，自主代理用誰的身分要問 | 核決權限表的 AI 章節：每個代理一列，單筆上限、頻率上限、月成本上限、人類 owner |
| 二 風險分級 | ⬜ 自動化等級可選，從「快速協助」到「全自動」 | ⬜ 以授權物件與角色控制範圍 | 哪個流程上 L1、L2、L3，照金額重大性 × 可回復性 × 財報影響判；升級走〈AI 代理的駕照制度〉的路考 |
| 三 職能分離 | ✅⬜ Trust Harness 每次執行套身分、能力、資料、動作控制；代理鏈 SoD 要自己設計 | ✅⬜ OpenShell 隔離執行、Sentry 越界隔離；代理鏈 SoD 要自己設計 | 代理之間的觸發鏈上至少一個人類控制點（方法見〈代理鏈 SoD〉）；設定者與覆核者分離 |
| 四 軌跡與版本 | ✅❌ Outcome Receipt 記授權、證據、決策、動作、結果；模型版本未明寫 | ✅❌ 兩層各有紀錄；接合在路線圖；模型更新未提變更管理 | 五要素軌跡補齊版本；模型更新比照變更管理，更新後首期拉高覆核 |
| 五 監控與回測 | ✅⬜ Agent Studio 有可觀測性、ROI 衡量、安全控制；抽樣回測自己做 | ✅⬜ Sentry 毫秒隔離是 kill switch 的硬體版；抽樣回測自己做 | 例外佇列有人清、月抽樣回測、kill switch 誰按、多久演練 |
這張表的讀法：✅ 越多代表原廠替你搭了越多骨架，但沒有一列是全 ✅。每一列右欄的東西，兩家都沒有替你寫，因為它們寫不了。這就是為什麼兩套架構不管選哪一套，五支柱的工作量差不多，差的只是你從哪一格開始。
五、三種公司，三種起手
比較的目的是行動，看你用哪套系統，起手就不一樣，下表按三種公司分：
| 你是 | 先做這件事 | 再做 | 向原廠要的文件 |
|---|---|---|---|
| Fusion 客戶（有或準備買 Agentic Applications） | 問 Outcome Receipt 有沒有模型版本、能不能匯出 | 寫核決權限表 AI 章節，把自動化等級對到 L1 到 L3，設月成本上限 | AI Units 服務說明與價目表、用量報表的頻率 |
| SAP 客戶（Joule 代理在用或在評估） | 確認每個代理用誰的身分跑，獨立 technical user 還是人的帳號 | 用代理身分當對帳鍵，把 OpenShell 紀錄與 SAP 授權紀錄對成同一筆交易 | AI Units 單價與 Joule Studio 免費期結束後的計價、兩層紀錄的接合時程 |
| 用別家 ERP（鼎新、Odoo、自建） | 拿五支柱當檢查表，先補代理獨立身分與核決權限表 | 若用 OpenShell 一類的開源執行環境，自己補「該不該」那一層 | 你的 ERP 原廠對代理治理的路線圖，沒有就自己寫 |
第三種公司常以為這篇不關他們的事。相反，兩大原廠的架構剛好是現成的參考答案：營運範圍、每次執行套控制、事後一張收據，三件事你的系統沒有內建，就是制度要自己補的地方。
查核的視角：會計師會問的四題，兩家各怎麼答
把整張比較表折回查核桌上。會計師問的四題（內部稽核怎麼查，見〈AI 代理的查核實務〉），兩家架構各能替你答到哪：
授權依據在哪？ Oracle 會給你 Receipt 上的「authority applied」，SAP 會給你角色與授權物件。兩邊都只能證明「有套授權」，授權的內容合不合理、金額門檻誰核准的，要看你的核決權限表。
行為紀錄完整嗎？ Oracle 一張收據五項，缺版本；SAP 兩本紀錄，接合在路線圖。五要素軌跡兩家都差一到兩項，差的那幾項自己補記。
變更有管理嗎？ Oracle 用會更新的前沿模型，SAP 自稱代理會「自我演化」，兩家都沒在文件裡講更新怎麼通知客戶。這題目前兩家都答不了，由你的變更管理制度承認「原廠推送的模型更新」是一種變更。
準確性有人監控嗎？ Oracle 的 Agent Studio 有可觀測性與 ROI 儀表板，SAP 有 Sentry 的越界監看。這些監控盯的是越界和省錢，判斷對不對沒人在看。抽樣回測兩家都沒做，只有你能做。老規矩：軌跡才是真話，從代理啟用的第一天就開始留。
常見問題（FAQ）
Oracle 和 SAP 的架構，哪一套比較安全？
兩家的風險模型不同。Oracle 防的是「做了說不清」，所以強在收據；SAP 防的是「做了不該做的」，所以強在隔離。對內控來說，兩套都只做了紀錄與圍堵那一半，授權那一半都是空欄，安全程度取決於你填得多完整。
我不是 Oracle 或 SAP 客戶，這篇對我有用嗎？
有用，而且更急。兩大原廠至少替客戶搭了紀錄與圍堵的骨架，用別家系統的公司這些骨架都要自己搭。五支柱選型格的右欄就是你的待辦清單，從代理獨立身分與核決權限表 AI 章節開始。
用量計價會不會讓 AI 預算失控？
會，如果你只設額度不設頻率。兩家公開文件裡都找不到內建的預算上限，Oracle 的服務說明甚至寫了用到負數可以封鎖功能。解法在你這邊：核決權限表加「月成本上限」一欄，指定監看的人，用量報表每月看一次。
現在該先做哪一步？
順序固定：先確認每個代理的身分（獨立帳號還是繼承人的權限），再寫核決權限表的 AI 章節（金額、頻率、成本三個上限加一個 owner），然後補五要素軌跡裡原廠沒給的那幾項，最後才談放到哪個自動化等級。反過來做的公司，是在用真實交易替原廠的架構做測試。
五支柱選型格為本站提出之原創比較工具，依 Oracle 2026 年 9 月 29 日新聞稿、Oracle 價目表與服務說明、SAP 2026 年 9 月 28 日官方文章、NVIDIA 同日公告與截至撰稿的公開資料整理，將隨兩家架構與計價的變動持續迭代（建議每季回訪本文，兩家的計價文件都保留修改權）。計價以原廠正式合約為準，內控設計以簽證會計師意見為準。若需要協助把貴公司的代理場景放進五支柱選型格，歡迎與我們聯繫。
延伸閱讀
- NetSuite vs Oracle Fusion：同是 Oracle 雲端 ERP，差在哪？什麼時候該換？（2026）
- 地端 vs 雲端 ERP 的 TCO 怎麼算？5 年總持有成本模型完全解析（2026）
