什麼時候不該用可執行業務本體？
五種今天不適合用可執行業務本體的工作負載：各自該用什麼、為什麼、選錯的代價，加一張每行帶出處的決策表和一份自檢清單。
先說結論：有五種工作負載不該用，而且是 ObjectStack 自己的文件點的名。 取代大企業的核心 ERP 或財務系統；價值主要在於整合大量現有系統的工作；資料湖上的分析；定價、排程這類演算法密集的領域——除非把演算法包成一個動作；以及任何必須跑在認證平台上的工作。每一種都有一個更合適的工具。這篇文章逐個說清該用哪一個、為什麼那是對的選擇、選錯了要付什麼代價。文末有一張每行都帶出處的決策表，還有一份十個問題的自檢清單，裝任何東西之前，先拿你自己的場景跑一遍。
一份誠實的「什麼情況下別用我」清單，是廠商能釋出的最有用的東西，因為這是買方從銷售材料裡唯一拿不到的資訊。ObjectStack 的一句話定位是「一份可執行的業務本體。AI 編寫它，執行環境執行它，Agent 操作它，你擁有它。」下面寫的全是這句話的邊界在哪裡，材料取自專案自己的什麼時候用它頁和它與其他方案的對比頁（標籤 @objectstack/[email protected]，2026 年 10 月 28 日讀取），以及邊界恰好就是一行程式碼的那些原始碼檔案。本站的對比頁已經把這五種工作負載和開工前的五個問題各用一行列過了；這篇是長版：每一種給一個具體場景、替代方案和它的道理、代價，以及一條起決定作用的事實。
六類測試
有一條測試能一次覆蓋五種情形，所以先講它。概念頁把可執行業務本體的核心定義為六類東西：物件與欄位、關係、動作、權限、流程、Agent 與工具定義。執行環境從這六類推匯出資料庫、API、介面和 Agent 工具，並在每一次呼叫上強制執行它們。程式碼不會消失，但它搬進了執行環境——鉤子、動作體、CEL 和受限 JSX——在六類東西劃出的圍欄之內執行。
於是對任何一個工作負載都可以問：它最難的那部分，是不是這六類之一？ 如果這項工作裡困難、值錢、有風險的部分，是在決定「有什麼、怎麼關聯、能做什麼、誰能做、什麼時候發生什麼」，那本體就是合適的工具，而且 Agent 寫得出來。如果最難的部分是別的東西——一項法定計算、與四十個系統的連線、對 PB 級資料的掃描、一個求解器、一張審計師簽發的證書——那這部分就不是一份定義能表達的，本體最多把它包起來，最糟是去模仿它。姑且把這叫作六類測試。下面五種工作負載各因為不同的原因過不了它，所以它們需要的是五個不同的替代方案，而不是一個。
一、
場景。 一家四千人的製造企業，總賬、合併報表和薪酬在一套套裝 ERP 上跑了十二年。編碼 Agent 看過會計科目表之後，提議把它重新宣告成物件：過賬規則寫成流程，稅寫成公式。演示很有說服力：憑證、試算平衡表、每一筆分錄都帶審批。
該用什麼，為什麼那是對的。 用套裝系統，並且圍繞它來建。「什麼時候用它」頁這樣寫：「總賬、合併、稅務和薪酬承載著套裝系統早已編碼進去的法規與邊角情況。圍繞這個核心建，而不是取而代之。」在那個市場裡，法規本身就是產品。一個薪酬引擎，是一座由稅收轄區、申報日曆和追溯調整組成的圖書館，由一群唯一工作就是保持它最新的人維護著；一個合併引擎，是多年積累的內部交易抵消和外幣折算的邊角情況。這些都不是「有什麼、誰能做什麼」，而是計算；它隨政府的變化而變，不隨你的業務而變。
選錯的代價。 第二本賬。你重新編碼的每一條規則，現在都是你要維護的 diff、你要通過的審計、換了稅務年度之後出的缺陷；而你為法定申報留下的那套套裝系統，每個季度都和你這份副本多差一點。一天就把規則寫完的 Agent，沒法替你讀稅法。
起決定作用的事實。 README 的能力表列出執行環境提供的十二項能力：物件與欄位、權限、自動化、審批、檢視、儀表盤與報表、動作、API 與 SDK、AI 工具、翻譯、種子資料、資料來源。總賬、稅務引擎、薪酬計算都不在其中，專案也沒有說它們在路上。
同一頁說適合的，是圍繞這個核心的長尾：「供應商准入、巡檢、內部申請」——那些追蹤 ERP 不管的事的表格和表單。每一個都變成一份型別化定義，而不是靠郵件傳來傳去的檔案；而且每一個都可以讀 ERP 的資料而不必擁有它。這就是下一種情形。
二、
場景。 一家銀行希望它的 Agent 能同時從核心銀行系統、CRM、卡平台和工單系統裡回答一個客戶的問題，並把一個狀態寫回其中兩個。這些系統一個都不會搬。任務是讓它們對 Agent 可讀，並且能跨系統行動。
該用什麼，為什麼。 架在這些系統之上的一層：讀的部分用語義層或上下文層，有回寫要治理時用 Palantir 那一類運營本體。對比頁直接承認這一點：「當資料已經住在一個數據倉庫、一個湖倉和十幾個業務系統裡時，它們從你所在的地方起步。」那些產品的前提假設就是記錄系統留在原地：它們的物件模型是一個檢視，它們的寫入是回寫，而它們的價值隨底下系統的數量增長。ObjectStack 建立在相反的假設上——本體就是系統，資料庫是從它推匯出來的。
選錯的代價。 這是最常選錯的一種，因為第一週會很順。ObjectStack 可以用 schemaMode: 'external' 把一個外部資料庫聯邦接入為資料來源，在一張遺留表上搭一個只讀模型，一個下午就夠。然後到了寫入。聯邦寫入預設關閉，而且關了兩道：資料來源必須宣告 external.allowWrites: true，物件必須宣告 external.writable: true，「任一道閘門關著，對聯邦物件的 insert/update/delete 都會被拒絕」。這道閘不是建議性的：assertWriteAllowed 在引擎的 insert 和 update 一開頭就跑，在預設值、鉤子和校驗之前。你逐個物件把兩道閘都開啟，於是你開始對一個你不掌控的 schema 負責寫入語義；而 schemaMode: 'external' 在 schema 不匹配時會讓啟動失敗，上游改一個列名，你的應用就停了。或者你轉而去寫同步任務——到那時你已經把本來不想買的那層整合層自己造了一遍，而且是造在一個連自己的文件都把聯邦稱為「早期」的工具裡。
起決定作用的事實。 兩道預設關閉的主動開啟：資料來源上的 allowWrites 和物件上的 writable（content/docs/data-modeling/external-datasources.mdx 講寫入的那一節），由 packages/objectql/src/engine.ts 裡的 assertWriteAllowed 強制執行。
誠實的路徑是存在的，但很窄：只讀接入，先測量，一個物件一個物件地開啟寫入，按物件切換。如何把內部系統遷到中繼資料走的就是這條路，包括那些正確答案是「根本不要遷」的情形。那條路是給你打算取代的系統走的。如果你打算留著四十個系統、跨著它們讀，那就走錯了路。
三、
場景。 一家零售商把三年的點選流和 POS 事件放在物件儲存裡，是 Parquet 和 Iceberg 表，品類團隊想要儀表盤。有人注意到這個平台有儀表盤、報表，還有一個文件裡稱為語義層的資料集層，於是提議把它指向資料湖。
該用什麼，為什麼。 數倉那一套：為列式掃描而生的查詢引擎，上面一層指標層或語義層，頂上一個 BI 工具。ObjectStack 的分析層，是面向應用自己那些行的指標層。它的文件把資料集定義為「一個基礎物件、要納入的關係，以及宣告出來的維度與度量」，連線從物件圖推導；schema 把這件事寫得很直白，資料集的 object 的描述就是「Base object name」（基礎物件名）。「什麼時候用它」頁一句話說完：分析層「在應用自己的物件上定義指標，供它的報表和儀表盤使用。它不是為查詢資料湖而建的。」數倉的語義層在資料湖之上做的是同一件事，本站的對比頁也說，認真做 BI 的公司仍然需要一個。
選錯的代價。 兩份副本選一份。要麼把資料湖裝進應用物件——於是你有了三年事件的第二份副本，帶著它自己的新鮮度和它自己的賬單，放在一個從業務定義推匯出來、而不是為掃描設計的行儲存裡；要麼聯邦接入一張數倉表，然後發現你在把分析型問題送進一個為應用回答行級查詢而建的引擎——有過濾下推，沒有任何東西認識列式檔案。儀表盤會渲染出來，但不會是品類團隊要的那些儀表盤。
起決定作用的事實。 README 列出的資料來源是 PostgreSQL、MySQL、SQLite、MongoDB 和記憶體；README 如今把包目錄交給了 CONTRIBUTING.md，那裡再加上 Turso 和 WebAssembly 裡的 SQLite。沒有資料湖格式，沒有列式引擎，沒有物件儲存驅動；而資料集層繫結的是一個物件，不是資料湖裡的一張表。
四、
場景。 一家物流公司的產品是路徑最佳化器：一個求解器，輸入一天的訂單和一支車隊，輸出一份計劃；再加一塊排程看板，排程員把站點在車輛之間拖來拖去，看著計劃重新求解。訂單、車輛、司機和計劃顯然都是物件；公司問，整個東西能不能做成一份可執行本體。
該用什麼，為什麼。 求解器和看板都用程式碼——而這裡替代方案最有力的論證，恰恰來自本體自己的文件。「什麼時候用它」頁說：本體「宣告能做什麼；它不表達最佳化器。」一個動作的 type 只能是 script、url、modal、flow、api、form 之一，而一個 script 動作的處理函式是程式碼，以應用的全部資料權限執行。定義擁有的是那扇門、門上的權限、以及誰走過這扇門的審計。門後面的演算法是你的，用什麼語言能解就用什麼。介面是同一個故事的另一個方向：對比頁說，Console「是由中繼資料驅動的服務端渲染，一個不像任何業務應用的介面，直接做反而更容易。」
選錯的代價。 把最要緊的部分，建在自由度最小的地方。求解器可以住在一個動作後面——對於一次由記錄觸發的排程執行，這正合適。排程看板不行：頁面裡的受限 JSX「被解析成一棵服務端驅動的 UI 樹，從不作為程式碼執行」，這是有意為之，於是排程員需要的每一個互動，都變成了和一個為列表、表單和看板而建的渲染器討價還價。半年之後，本體成了你真正賣的那個東西外面薄薄的一層殼。
起決定作用的事實。 packages/spec/src/ui/action.zod.ts 裡的 ActionType 是一個封閉集合：script | url | modal | flow | api | form。演算法永遠不是其中一項，它只是通往演算法的那條路。
行得通的切分是：業務那一半——訂單、車輛、司機、誰可以批准一份計劃、計劃釋出時發生什麼——做成本體，讓 Agent 能寫、能操作；求解器做成 script 動作後面的程式碼，於是權限、審計和 Agent 訪問像對待任何其他動作一樣適用於它；排程員的看板做成它自己的應用。如果看板就是產品，從看板開始。
五、
場景。 一家醫院集團想要一個入院登記流程，它的採購要求所承載的平台持有某項指定的鑑證。一份政務招標對 ISO 證書問同一個問題。這項工作本身——表單、流轉、審批、審計軌跡——是教科書式的適合。
該用什麼，為什麼。 要麼用一個持有證書的平台，要麼由你自己為部署做認證；這個決定取決於買方的日曆，不取決於廠商的路線圖。「什麼時候用它」頁寫道：「ObjectStack 是由你部署和運營的開源軟體，它自身不帶任何合規認證。當一項工作必須跑在認證平台上時，為你的部署做認證是你要承擔的工作。」這不是迴避，認證本來就是這樣運作的：一份鑑證覆蓋的是一個執行中的環境、它的控制措施和它的運營者，而一個 Apache-2.0 的程式碼倉庫哪一樣都不是。本站的安全頁對商業版說的是同一句話：認證取決於你執行中的部署，而不是一個二進位制檔案本身。
選錯的代價。 在採購階段而不是設計階段才發現這一點，而時間表早已預設平台會自帶證書。於是審計落到你的計劃裡，沒有預算，就在上線之前。
起決定作用的事實。 專案的術語表把它自己的協議一致性測試套件都列為「計劃中」，並寫明「程式碼庫裡今天不存在 TCK 專案或認證機制」。除了你的部署，沒有別的東西可以指給審計師看。
這項工作仍然適合；問題在於它跑在哪裡。誠實的順序是先把認證工作的成本算出來，再做決定。
另外
對比頁還承認了兩點，它們不在「今天不適合」的清單上，因為它們說的是一類問題而不是一類工作負載。兩者過六類測試的方式是一樣的。
對異構資料做推理。 如果問題是「從我們知道的一切能推出什麼」——類層級、推匯出的事實、跨詞彙表的一致性檢查——那是知識本體的工作，而 ObjectStack「沒有物件繼承、沒有公理、沒有推理器」。abstract 這個鍵是從 spec 裡刪掉的，而不是留作一個承諾。定義先校驗、再執行；執行環境不做任何推斷。那篇定義文章把這個「不是」講全了。
生態成熟度。 Salesforce、Odoo 和 ERPNext「帶來多年的生產使用、打包好的應用、應用市場和實施夥伴。ObjectStack 更年輕；要有更多東西自己建的準備。」如果你這個季度就需要一個打包好的應用、需要你所在城市裡有一家實施夥伴，那麼不管定義怎麼寫，一個更年輕的平台都是錯的賭注。
決策表
每一行：工作負載、今天是否適合與該用什麼，以及起決定作用的那一條事實和它的出處。「今天」是一個日期：出處是 objectstack 的標籤 @objectstack/[email protected]，即 npm view @objectstack/cli dist-tags 在 2026 年 10 月 28 日報告為 latest 的那個版本，當天讀取。出處按檔名寫：when-to-use、compare、ontology 是 content/docs/concepts/*.mdx；external-datasources 和 analytics 在 content/docs/data-modeling/ 下；glossary 在 content/docs/getting-started/ 下；engine.ts 是 packages/objectql/src/engine.ts；dataset.zod.ts 和 action.zod.ts 在 packages/spec/src/ui/ 下；README 和 CONTRIBUTING.md 在倉庫根目錄。
| 工作負載 | 今天適合嗎？該用什麼 | 起決定作用的事實（出處） |
|---|---|---|
| 大企業的核心 ERP 或財務 | 否：套裝系統；圍繞它建 | 法規和邊角情況就是產品；執行環境的十二項能力裡沒有總賬、稅務或薪酬引擎（when-to-use；README 能力表） |
| 整合大量現有系統 | 否：語義層或上下文層；有回寫時用運營本體 | 聯邦預設只讀，而且關了兩道：資料來源上的 allowWrites 和物件上的 writable（external-datasources；engine.ts 的 assertWriteAllowed） |
| 資料湖上的分析 | 否：數倉查詢引擎、指標層、BI | 資料集繫結到一個基礎物件；驅動都是行儲存，沒有資料湖格式（analytics；dataset.zod.ts；README 資料來源；CONTRIBUTING.md 驅動列表） |
| 演算法密集的領域 | 演算法本身不適合：程式碼；其餘是業務應用時，放在 script 動作後面 | ActionType 是 script、url、modal、flow、api、form；求解器永遠不是其中一種（action.zod.ts；when-to-use） |
| 必須跑在認證平台上 | 不自己承擔認證工作就不適合：一個認證平台，或者為你的部署做認證 | 自身不帶合規認證；連一致性測試套件都還是「計劃中」（when-to-use；glossary） |
| 對異構資料做推理 | 否：帶推理器的知識本體 | 沒有繼承、沒有公理、沒有推理器；abstract 按 ADR-0049 刪除（ontology；compare） |
| 現在就需要成熟生態 | 還不行：有打包應用和實施夥伴的中繼資料平台 | 「ObjectStack 更年輕；要有更多東西自己建的準備」（compare） |
| 新建業務應用：CRM、工單、審批、運營、內部工具 | 是 | 物件、關係、動作、權限和流程就是這些應用的大部分（when-to-use） |
| 圍繞核心 ERP 的長尾 | 是 | 小、具體、經常變；每個應用一份型別化定義，讀 ERP 的資料而不擁有它（when-to-use） |
| 從第一天起就由 Agent 操作的後臺 | 是 | 每一個部署都是一個 MCP 伺服器，預設開啟，在使用者自己的權限之下（when-to-use；README） |
跑一遍
十個問題，兩個階段，十分鐘。第一階段是排除清單；第二階段是「什麼時候用它」頁上「開工前的五個問題」。
第一階段。任一項答「是」，本體就不是這部分工作的工具。
- 這項工作最難的部分，是不是一項套裝系統早已編碼好的法定計算：總賬、合併、稅務、薪酬？
- 大部分價值是不是來自讀寫那些你會留著、但並不擁有的系統？
- 你想分析的資料，是不是靜置在資料湖或數倉裡，而不在應用自己的記錄裡？
- 產品的核心是不是一個求解器、最佳化器或模擬，或者一個不像任何業務應用的介面？
- 這項工作是不是必須跑在持有指定認證的平台上，而且沒有預算為自己的部署做認證？
第二階段。你的團隊今天能替業務回答這些嗎？
- 有什麼——物件及其欄位。
- 怎麼關聯——物件之間的查詢（lookup）與主從（master-detail）連結。
- 能做什麼——使用者或 Agent 可以對一條記錄發起的動作。
- 誰能做——權限集、行級與欄位級安全、共享。
- 什麼時候發生什麼——記錄觸發器、定時任務、審批、工作流。
五個「否」加五個答案：用那一頁的話說，本體「是一天的活，因為寫的是 Agent」。五個「否」但一個答案都沒有：「還沒有工具幫得上，這一個也不例外。第一筆投入是回答這五個問題，而不是安裝任何東西。」第一階段有一個「是」：沿著那條線把工作切開，留下通過的那部分，其餘按表裡的替代方案辦。
這份
它沒有說這些限制是永久的。那一頁的標題是「今天不適合」，聯邦被稱為「早期」，上面的錶帶著日期；決定之前，拿它對照一下當前的頁面。
它沒有說這些替代方案在一般意義上更好。語義層是跨四十個系統讀資料的正確工具，也是運營一個工單臺的錯誤工具——理由正是第二節反過來講的那些。每一行的替代方案，只對那一行是對的。
它也沒有說過不了一行就等於整個工作過不了。真實的情形多半是切開的：入院登記流程適合，承載平台是採購問題；排程這個領域適合，求解器是程式碼；圍繞 ERP 的部門應用適合，總賬留在原地。六類測試針對的是最難的那部分，不是專案的名字。
ObjectOS 在這份
上面說的一切不隨版本而變。ObjectOS 有三個版本：ObjectOS Community，開源、可免費自託管；ObjectOS Cloud，託管在瀏覽器中、無需安裝；ObjectOS Enterprise，自管部署在你自己的基礎設施上。你的本體是普通的 ObjectStack 中繼資料。從 ObjectOS Cloud 或 ObjectOS Enterprise 匯出本體、在開源的 ObjectStack 執行環境上執行，目前尚在計劃中。這五種工作負載說的是一份可執行本體能表達什麼，不是它跑在哪裡，所以這份清單在任何承載環境上讀起來都一樣。唯一一個和承載環境有關的問題是認證，安全頁對 ObjectOS 的回答和開源頁的措辭一致：取決於執行中的部署。
如果
那麼最快、也最誠實的下一步不是看演示，而是寫一份定義。把你的編碼 Agent 指向 ObjectStack——規則檔案、技能包和工具伺服器見如何把你的 Agent 指向 ObjectStack——然後向它要第一個物件：幾個欄位、一個關係、一個動作、一個權限集、一個觸發器。跑 npm run validate，先讀 diff，再看 Console。如果你能把整份 diff 讀完，而且它說的就是你的業務在做的事，那六類測試在實踐中就通過了，下一頁該交給 Agent 的是定義本身是什麼。如果讀不完，這篇文章本來也幫不了你，而你剛剛省下了一個專案。