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 / 排程系統，並保留完整決策譜系。
這才是 Palantir 口中「把 agent 接到決策」的意思。Agent 不是生文字，而是與人類共享同一套企業語意、同一套工具、同一套規範。
生產現場裡在發生什麼事？
Palantir 的实際部署給了這個架構一些具體點位：
- Novartis （Data42）：在 Palantir Foundry 上整合 7 億位病人的真實世界資料、約 3,000 個臨床試驗、約 100 萬位病人的資料。譯型模型者進行「人體劑量預測」的時間，從一週縮短到每個化合物約 2 小時。
- 美國航空：用自家 ontology 進行 AI 輔助的航線規劃。
- Lumen（電信）：打造網路運營上的 AIP 使用場景，一年內釋出數千萬美元價值。
- MaineHealth、Tampa General Hospital：處理保險拒賠與優化病人照護路徑。
- Lowe’s + NVIDIA：結合 GPU 加速與 Ontology，建立全球供應鏈的數位双生與持續優化。
一個共同模式是：組織不只是「用 AI 分析過去資料」，而是讓 AI 參與运作流程，提出行動、推薦決策，甚至在定義好的邊界內自主執行。
AIP Bootcamp：五天裝出一個可用 Agent
Palantir 的銷售模式也跟著技術一起進化：從傳統長月的企業銷售週期，轉為五天密集的「AIP Bootcamp」：潛在客戶帶自己公司資料來現場部署一個可用 agent。
- 轉換率話說約 75%。
- 原本要走數個月的 PoC，被壓縮到幾天內看到結果。
這背後的邏輯其實不難：如果一個組織肯花五天把自己的 ontology 建起來，這個語意模型就會逐漸變成決策流程的一部分。一旦被嵌入，切換成本並不低。
戰略位置：「企業決策層」而不是另一個 SaaS
Palantir 不試著取代 ERP、MES、CRM，而是把自己定位成「坐在這些系統之上的決策層」：
- 縱向上，接設計工具、ERP、排程、供應鏈、感測器網路。
- 橫向上，進一步與 NVIDIA 合作，將 GPU 加速計算與最佳化函式庫接進 Ontology。
在這個位置上，它不鋪 agent 語言模型是誰、不鋪資料仓儲是誰，而鋪「誰定義企業思考與行動的語意」。
Ontology MCP：把中枢神經打開給外部 Agent
Palantir 近期推出 Ontology MCP，重點是：
- 透過 Model Context Protocol 這個開放標準，將 Developer Console 里的應用曝露給 AI agent。
- LangChain、CrewAI、自製 Python agent……都可以不寫特定整合，直接與 Ontology 對話。
- 但這些外部 agent 一旦接入，仍然是「在 Palantir 的規則上跳舞」：語意模型、治理、審計路徑都仍由 Ontology 掌控。
這是一個非常典型的平台策略：開放接口，但保留語意與治理的掌控權。
企業買家該怎麼看？
對 CIO / 二號位來說，Ontology 帶來的測試題並不是「這個架構有沒有用」，而是一連串「多長期的依賴才合理」的問題：
- 股东 / 老闆關心的是決策速度與運作智能的提升，這點 Ontology 在多個實際案例裡已經證明。
- 但 IT / Architecture 需要關心的是：一旦將「公司怎麼思考」這件事織進一個外部平台，未來几年的議價能力與轉換成本該怎麼評估。
- 實務上，豐足的企業可以先在**某些高價值、高複雜度的流程（供應鏈、金融風控、藥物研發）**驗證 Ontology 路線，同時保持本身資料與規則的可携出性。
對 Agentic AI 社群的添加
如果你長期關注 Agentic AI，這篇文章的重點其實不是 Palantir 本身股價，而是一個架構信號：
- 大部分人還在問：「怎麼把 LLM 接上內部資料？」
- Palantir 已經在問：「怎麼把 agent 接進決策邏輯與行動中？」
不明講你肯不肯用 Palantir，這個思考路徑本身都值得被拌進你自己設計 agent / multi-agent 架構的清單裡：
- 你的 agent 是在查資料，還是在對企業語意進行推理與行動？
- 你是否有一個「一等公民的 Action 原語」，包含 staging、審核、同步回原生系統、完整譜系？
- 你的治理是被「事後補」，還是在架構裡就設計好？
這些問題，才是讓企業 AI 跨出「PoC 奇蹟」的關鍵。