Palantir Agent Engine 的重點，不是更聰明的 agent
Palantir 在 DevCon 6 發表 Agent Engine 與 Agent SDK，主張以 context items、events 與 effects 組成可持久運作的 agent。它最值得研究的地方不是產品名詞，而是把 agent 視為需要狀態、權限與復原機制的系統。
目錄+
如果你的 agent 只會在單一對話裡呼叫兩個工具，它最需要的可能是更好的提示與評估。若它會等人核准、讀寫企業資料、失敗後必須繼續執行，問題就變了：你其實在營運一個有狀態的分散式系統。
Palantir 在 DevCon 6 發表的 Agent Engine 與 Agent SDK，值得注意的正是這個取向。官方把核心拆成 context items、events 與 effects，並將 agent loop 描述為一種「分散式狀態機」。這不是已被第三方大規模驗證的標準答案，但它提供了一個很實用的設計檢查表。
先把產品說法翻成工程問題
Palantir 的用語可以很快翻譯成三個熟悉的系統元件：
- Context items：這次工作有哪些已知事實、任務資料與權限範圍。
- Events：哪些外部變化會令工作重新評估，例如資料更新、人工核准或逾時。
- Effects：agent 最終對外做了什麼，例如寫回資料、送出通知或呼叫另一個系統。
把這三者分開的價值，不在於名詞變多，而在於它讓團隊能回答原本常被忽略的問題：目前狀態存在哪裡？誰能改？這個動作有沒有真的執行過？如果服務中斷，重新啟動會不會重複寄信、重複下單，或把資料覆寫兩次？
什麼時候你真的需要這種架構
不是所有 agent 都需要 durable execution。對單次摘要、內部查詢或低風險草稿而言，簡單的 request-response 流程通常更快、更便宜，也更容易除錯。
複雜度在這些條件出現後才值得引入：
- 工作會跨越人類時間。 agent 要等一位主管、客戶或醫護人員回覆，而不是幾秒內完成。
- 外部事件會改變答案。 等待期間，訂單狀態、庫存、文件或資料庫記錄可能已經變了。
- 副作用不能重複。 寄出一封草稿信與送出付款、修改權限的風險完全不同。
- 同一流程有多個參與者。 人、agent 與其他服務同時讀寫同一份任務資料時，沒有權威狀態就很容易互相覆蓋。
Palantir 選擇以企業流程作為示範，正好點出這個差異：企業要的往往不是一次看起來聰明的回答，而是一個能被追溯、暫停、恢復與審核的工作流程。
動手前，先畫出這四件事
即使用的不是 Palantir，也可以拿同一套思路檢查自己的 agent。
第一，畫狀態，而不是只畫 prompt。 把「等待資料」「等待人工核准」「執行完成」「需要重試」寫成明確狀態。若團隊無法從紀錄判斷任務停在哪裡，系統就還不能可靠地恢復。
第二，替每個外部動作設定冪等鍵。 建立付款、寄送通知、修改紀錄等操作，都應能辨識「這件事是否已經做過」。模型重試是正常情況，重複副作用不是。
第三，將人工核准視為產品功能。 不要把人工介入當例外。決定哪些操作必須停下來、由誰核准、核准後是否要重新讀取最新資料，這些規則比多加一個工具更影響信任。
第四，保留可稽核的歷史。 對高風險流程，至少要能查到當時用了哪些資料、誰核准、agent 執行了哪個 effect，以及失敗後如何處理。
需要保留的疑問
DevCon 的展示與官方說法，不能直接等同於真實企業導入的成本或可靠性。Palantir 的模式深度連結 Ontology，這能帶來資料模型、權限與工作流的一致性，也會讓遷移、整合與供應商依賴成為採購時必須評估的問題。
此外，「幾行程式碼就能建立 agent」通常描述的是開發介面，而不是整個營運成本。權限設計、測試資料、異常處理、觀測性與人工流程，仍然需要工程投入。這些工作不會因為模型更強而消失。
給正在做 agent 的一個結論
下次 agent 出錯時，先不要急著換模型。先問：它的狀態在哪裡？事件從哪裡來？它能做出的外部動作如何避免重複？誰能在必要時接手？
Palantir 的產品是否適合你，要看你的資料環境與流程複雜度；但「把 agent 當成需要被營運的系統」這個觀點，對任何團隊都適用。