Palantir Ontology：讓 AI Agent 不只會「說」、而是能「做決策」的企業架構
企業 AI 不是在資料不足，而是「沒有決策語意」。Palantir 將 Ontology 當作 AIP 的中枢神經，把資料、邏輯、行動、權限織成一個中關層，讓 AI Agent 與人類站在同一個「決策世界」裡協作。
2026/4/29
TL;DR 企業 AI 大多數都卡在同一個地方：能查資料、能生成內容，卻無法真正「動手」。 Palantir 認為這是架構問題不是模型問題：傳統資料湖 / 仓儲只裝「事實」，不裝「決策邏輯」。 「Ontology」是 Palantir AIP 的中枢神經，把資料（Data）、邏輯（Logic）、行動（Action）、權限（Security）織成企業运作的語意模型。 AI Agent 在 Ontology 裡不只是「聊天助手」，而是與人類操作員共享同一套物件、工具與治理規則的決策參與者。 Palantir 近期推出 Ontology MCP，用 Model Context Protocol 把 Ontology 開放給 LangChain、CrewAI 等外部 Agent 框架，同時保留自己的語意與治理層。
為什麼大部分企業 AI 最後都「吃火鍋」？
大多數企業 AI 專案都共享同一種失敗模式： 接上 LLM，接上內部資料。 讓模型生出看起來合理的內容。 這些內容被丟進某個 Slack 頻道或 Notion 頁面裡，然後「沒有下文」。 模型可以檢索、可以摘要，卻不能「行動」。因為「行動」需要的不只是資訊，還需要：
- 決策是「怎麼被做出來」的：有哪些規則、限制、審核流程。
- 決策一旦做了，「會落到哪裡」：ERP、排程系統、倉管、生產線……
- 不同語境下，「誰能採取什麼行動」。
沒有這些上下文，AI 就只是一個「說話很漂亮的虛擬同事」，而不是一個能參與企業運作的 agent。
Palantir 的診斷：這是架構問題，不是模型問題
傳統企業資料架構的思路是「集中、清洗、入倉」：建 Data Lake / Warehouse，治理起來，讓分析師查詢。這套雖然適合「報表」，卻不適合「決策」。原因是這類架構只拍下了「事實」，卻沒有拍下：
- 連接事實與結果的推論邏輯：「這類狀況該怎麼處理？」
- 決策一旦被採納後該被觸發的行動。
- 決策隨時間的譜系（lineage），讓 AI 有辦法從「什麼有效 / 無效」中學習。
Ontology 的選擇是反過來的：不要為了分析而將企業複雜度拍平，而是完整保留「企業怎麼運作」這件事。物件、屬性、關係即時演進，「行動」是一等公民，權限與治理被織進每一層。
決策的四個支柱：Data / Logic / Action / Security
Palantir 把「每一個企業決策」拆成四個要素：
- Data（資料）：結構化資料庫、IoT 串流、文件庫、影像，以及使用者與 agent 在流程中產生的「決策資料」。→「考慮了哪些選項、看了哪些資訊、最後選了什麼」這類上下文，才是持續改進的燃料。
- Logic（邏輯）：預測模型、最佳化演算法、業務規則，甚至資深同仁腦裡的「部落知識」。→ Ontology 把這些都包裝成人類與 AI agent 都能呼叫的工具。
- Action（行動）：狀況 staging、審核、提交、同步回原生系統。→ 與傳統分析平台最大的不同，關鍵在「關上洞察與執行之間的迴圈」。
- Security（權限）：角色、標記、用途三重動態計算的治理策略。→ 面對 agent 時尤其重要：哪些工具可用、哪些只能 staging、哪些可以自主執行。
這四者任一存在不是重點，「它們的整合」才是重點。
Agent 在 Ontology 裡到底在做什麼？
多數企業 agent 其實只是「RAG 加了一層聊天介面」：能回答問題，卻不能執行決策。Palantir 的野心大一些：在 AIP 裡，agent 不是另外一個世界。它與人類操作員踏入同一個 Ontology，使用同一組物件、同一組邏輯、同一組行動原語。
以製造業供應鏈為例：某供應商出狀況、所有下游訂單都受到影響。傳統分析平台會告訴你「出事了」。但 Ontology-driven agent 可以進一步：順著關係圖找出各個受影響的客戶訂單，呼叫最佳化模型評估不同原料調配策略，在場景沙盒（scenario sandbox）裡模擬調度結果讓人類審核。一旦審核通過，變更會被同步回 WMS / ERP / 排程系統，並保留完整決策譜系。
生產現場裡在發生什麼事？
- Novartis（Data42）：在 Palantir Foundry 上整合 7 億位病人的真實世界資料、約 3,000 個臨床試驗、約 100 萬位病人的資料。進行「人體劑量預測」的時間，從一週縮短到每個化合物約 2 小時。
- 美國航空：用自家 ontology 進行 AI 輔助的航線規劃。
- Lumen（電信）：打造網路運營上的 AIP 使用場景，一年內釋出數千萬美元價值。
- MaineHealth、Tampa General Hospital：處理保險拒賠與優化病人照護路徑。
- Lowe’s + NVIDIA：結合 GPU 加速與 Ontology，建立全球供應鏈的數位双生與持續優化。
AIP Bootcamp：五天裝出一個可用 Agent
Palantir 的銷售模式也跟著技術一起進化：從傳統長月的企業銷售週期，轉為五天密集的「AIP Bootcamp」：潛在客戶帶自己公司資料來現場部署一個可用 agent。轉換率據說約 75%。原本要走數個月的 PoC，被壓縮到幾天內看到結果。
戰略位置：「企業決策層」而不是另一個 SaaS
Palantir 不試著取代 ERP、MES、CRM，而是把自己定位成「坐在這些系統之上的決策層」：縱向上，接設計工具、ERP、排程、供應鏈、感測器網路。橫向上，進一步與 NVIDIA 合作，將 GPU 加速計算與最佳化函式庫接進 Ontology。
Ontology MCP：把中枢神經打開給外部 Agent
Palantir 近期推出 Ontology MCP，重點是：透過 Model Context Protocol 這個開放標準，將 Developer Console 裡的應用曝露給 AI agent。LangChain、CrewAI、自製 Python agent 都可以不寫特定整合，直接與 Ontology 對話。但這些外部 agent 一旦接入，仍然是「在 Palantir 的規則上跳舞」：語意模型、治理、審計路徑都仍由 Ontology 掌控。
企業買家該怎麼看？
對 CIO / 技術主管來說，Ontology 帶來的考驗是：一旦將「公司怎麼思考」這件事織進一個外部平台，未來幾年的議價能力與轉換成本該怎麼評估。實務上，穩健的企業可以先在「某些高價值、高複雜度的流程（供應鏈、金融風控、藥物研發）」驗證 Ontology 路線，同時保持本身資料與規則的可携出性。
對 Agentic AI 社群的啟示
大部分人還在問：「怎麼把 LLM 接上內部資料？」Palantir 已經在問：「怎麼把 agent 接進決策邏輯與行動中？」這個思考路徑值得被放進 agent / multi-agent 架構的設計清單裡：
- 你的 agent 是在查資料，還是在對企業語意進行推理與行動？
- 你是否有一個「一等公民的 Action 原語」，包含 staging、審核、同步回原生系統、完整譜系？
- 你的治理是被「事後補」，還是在架構裡就設計好？
參考資料
- Glitchwire：Palantir Ontology — The Architecture That Turns AI Agents Into Decision-Making Systems