Palantir 的 Action 是一筆交易：驗證、副作用、寫回、稽核綁在同一個定義裡

Palantir 官方文件對 action 下的定義只有一句話：“An action is a single transaction that changes the properties of one or more objects, based on a user-defined logic.”（Palantir 官方文件，2026 年 8 月查閱，action-types overview 頁）——一個 action 是一筆交易。讀者最容易把這句話簡化成「action 就是表單寫回」，但官方頁面自己舉的例子拆穿了這個簡化：一個叫 Assign Employee 的 action type，同時綁了讓使用者輸入新角色的參數、自動把員工與新主管建立關聯的規則、通知新舊主管異動的副作用，以及限定只有人資才能操作的驗證。這一整包東西，才是一個 action type。

這篇接續系列第一篇。第一篇拆了 Ontology 的四層——語意、動作、權限、血緣，動作層那節只講到 action type 定義本身；這篇只談動作層這一件事：一個 action 從被定義到被送出、寫到哪、留下什麼、被誰觸發，整條路徑長什麼樣，以及官方文件自己列出的限制在哪裡。

Palantir 把 action type 定義為五個部分綁在一起的規則

官方文件裡另一句對 action type 的定義是：一個 action type 是使用者一次可以對物件、屬性值、關聯做的一組變更或編輯的定義，也包含送出時觸發的副作用行為——這句話比第一篇引過的 core-concepts 頁版本少了「schema」兩個字，出處是 action-types overview 頁，兩頁措辭不完全一致。

組成這個定義的五個部分各自有專屬機制：parameters 是 action type 的輸入，“Parameters are the inputs of an action type”（parameters 頁），每個參數都有型別，甚至可以直接是一個 object type；rules 能做的事只有五類——建立物件、修改物件、刪除物件、建立多對多關聯、刪除關聯；submission criteria 決定送不送得出去；side effects 讓資料被送出 Foundry、對接既有組織流程；當 rules 不夠複雜時，可以改用 function 驅動整個邏輯——官方原話是”In some cases, however, simple rules are not sufficient to describe the changes that you want to make.”（function-backed actions 頁）。官方也強調同一套 action 邏輯與驗證能跨所有使用者應用一致地使用，確保 Ontology 的編輯彼此一致。

官方的入門教學先建一個叫 Demo Ticket 的 object type，再定義 action type，而且定義完之後使用者要能真的送出，還需要額外一步：“If running Object Storage v2, the user must enable edits with a toggle. If running Object Storage v1 (Phonograph), a writeback dataset must be created.”（getting-started 頁）光把 action type 存起來還不夠，開關要另外打開。

送出前有三道關卡：權限、submission criteria、validate-only

第一道關是看得到才改得到：“the user submitting the action must be able to view the edited object types and link types and their datasources, and pass the submission criteria”（permissions 頁）若 object type 只允許經 action 編輯，看得到就能改；若允許其他方式編輯，還得另外持有 writeback dataset 的 Edit 權限。建立新物件時，看不到 input datasource 會直接失敗。

第二道關是 submission criteria——能不能送出的條件（定義見第一篇），能拿參數值組合判斷，把業務邏輯編碼進編輯權限裡。

第三道關是 API 層的 Validate Action：“For performance reasons, validations will not consider existing objects or other data in Foundry.”（Validate Action API 頁）——只驗參數與規則合不合法，不看現有資料，凡是要查現有物件才能判斷的檢查都不在這一關。OSDK 端另有限制：“It is not possible to return edits and validateOnly at the same time.”（TypeScript OSDK migration 頁）Workshop 表單全部參數過驗證才會顯示送出按鈕，OSDK 的 applyAction 則直接回傳這次呼叫有效或無效。

送出後的 edits 只進 Funnel 佇列，不寫回原始資料集

一個 action 被送出之後，Actions 服務把修改指令送進 Funnel 管理的佇列；官方保證是，只要一次讀取發生在使用者修改指令送出之後，這次讀取一定含這次編輯。Object Storage v2 的版本檢查比 v1 少，官方自己說明這是取捨：檢查少了，StaleObject 衝突變少，但代價是保證變弱（how-edits-applied 頁）——官方自己承認的取捨，不是外部批評。

同一個物件如果同時收到資料源更新和使用者編輯，官方文件列了兩種衝突策略。預設策略是”Strategy 1: Apply user edits (default)“（how-edits-applied 頁），意思是編輯永遠贏，不管資料源之後怎麼更新那個屬性；另一種策略是比時間戳，只有編輯時間比資料源時間新才生效。刪除不算一次編輯，物件被刪之後即使重建也不會繼承舊的編輯。即使資料源完全沒有新資料，只要偵測到有編輯，Funnel 的持久化流程還是會照排程跑：“live pipelines will run every six hours regardless of any explicit backing dataset update”（funnel-batch-pipelines 頁）。

兩件常被混在一起講的事要分開：使用者對 Ontology 物件做的編輯，永遠不會寫進物件類型背後的 backing dataset，只能選擇性地物化成另一份資料集；對外部系統的寫回，走的是完全不同的機制——webhook，下一節再拆。兩件事走兩條路。

Materialization 在 Object Storage v2 是可選項

Object Storage v2 底下，materialization（把資料源加編輯的最新狀態物化成一份資料集）不是必要條件，使用者只要在 Ontology Manager 切一個開關就能啟用編輯，不一定要建物化資料集；官方列的主要用途是讓下游 Foundry pipeline 讀到最新狀態。物化的傳播方式有兩種：即時傳播，延遲幾分鐘；或跟著排程，最慢每 6 小時重建一次。不管哪一種，官方文件都明講：“only the latest snapshot is guaranteed to be available”（materializations 頁）——歷史版本不保留，要保留就得自己再接一個 transform。streaming 資料源目前也不支援 action 與使用者編輯，Object Storage v1（Phonograph）已進入淘汰階段，官方寫明 2026 年 6 月 30 日之後停用。

Webhook 分成兩種模式，失敗處理完全相反

Side effects 分兩大類：notification 與 webhook。notification 用來通知使用者，通知內容讀取的是編輯套用之前的 Ontology 狀態，收件人看不到的資料不會進通知；如果預設要求全部收件人都有權限而有人沒有，官方的說法是資料不改、通知也不發。收件人上限是 500 人，內容由 function 產生時降到 50 人。

Webhook 才是「寫回外部系統」真正發生的地方，而且官方文件把它切成兩種模式，行為完全相反。Writeback 模式在物件變更之前執行，失敗會直接顯示給使用者，且其他變更都不會發生；官方的說法是”This behavior enables some degree of transactionality between Foundry and the external system.”（webhooks 頁）——只到「某種程度」，因為外部請求成功、Ontology 這邊卻失敗的情況仍然可能發生，也因此一個 action 只能設一個 writeback webhook。Side effect 模式則相反：“By default, the newly added webhook is configured as a side effect”（set-up-a-webhook 頁），在物件已經改完之後才跑，失敗不會顯示給使用者，使用者甚至可能已經看到成功訊息了才失敗；一個 action 可以設多個 side effect webhook，執行順序不保證，官方直接建議這個模式用在「best-effort 通知」或同時寫回多個外部系統。

Action revert 常被誤會成能撤銷這一整包東西，官方文件寫得很清楚：“An action revert only reverts the edits to the object instance, but it will not revert side effects, such as notifications or webhooks, nor will it call them in the same way that the applied action would have.”（action-reverts 頁）revert 只還原物件本身的編輯，不撤 side effect；而且一旦物件在這之後又被別的編輯動過，即使動的是不同屬性，這個 action 也不能再被 revert 了；revert 只支援 Object Storage v2。官方用的字是 revert，不是 rollback，而且只鎖定在物件 edits 這一層。

Action log 預設只記主鍵，不記屬性值的變化

每次送出一個 action，都會自動生成一筆 action log 紀錄，記下送出者的 Multipass 使用者 ID、時間戳、被改動物件的主鍵。但有一條限制，官方文件明講”Note that storing properties of edited objects other than the primary key is not supported.”（action-log 頁）——被編輯物件除了主鍵以外的屬性值，預設不會自動記錄；但這不等於「稽核只留得住主鍵」，因為 action log 可以另外設定收 Summary、參數值、甚至未被編輯物件的屬性，只是「改前改後的值」不在預設欄位裡。

要看逐筆的編輯歷史，得另外打開 user edit history 這個功能，而且官方寫明”Any changes prior to the activation of this feature will not be tracked.”（user-edit-history 頁）——開關之前發生的變更不會被追溯。從 Object Storage v1 遷移到 v2 時，除了 Action Logs，其他編輯歷史不會被保留。Palantir 2025 財年 10-K 的 Oversight and Auditability 段落也提到平台維護 audit logs，方便授權使用者調查過去的濫用或主動標記可疑活動——但這句話講的是整個平台的 audit logs，不是 Actions 這個機制本身。

Workshop、OSDK、Automate、AIP Logic 都能觸發 action，但機制各自不同

人可以透過 Workshop 按鈕觸發 action，也可以透過 OSDK 或 REST API 呼叫；API 端有一個容易被忽略的細節：“Note that a 200 HTTP status code only indicates that the request was received and processed by the server.”（Apply Action API 頁）200 不代表 action 成功，要看回應內容裡的 validation 結果。

Automate 的 action effect 能在條件觸發時自動跑 action，“This means that the action will be run on behalf of the owner of the automation.”（Automate 的 action-effects 頁）以 automation owner 身分執行，submission criteria 對 owner 驗，edit history 與 audit logs 也記 owner，owner 可以是第三方應用的服務帳號。Automate 的效果是 at-least-once 不是 exactly-once：“Effects follow at-least-once execution semantics rather than exactly-once guarantees.”（effect-settings 頁）同一效果可能重複執行，官方建議設計成冪等操作。

AI 相關的三個入口，官方文件各自寫了不同的句子。AIP Logic 的 Apply action block 可以不透過 LLM 直接呼叫 action，但”The Ontology will not be edited unless the Logic function is executed from an action, even if the function contains an Apply action block.”（AIP Logic 的 blocks 頁）——沒有被 action 呼叫，就算 function 裡有這個 block 也不會寫入。Chatbot Studio（原 Agent Studio）的 Action 工具給聊天機器人執行 Ontology 編輯的能力，“This can be configured to run automatically or to run after confirmation from the user.”（Chatbot Studio 的 tools 頁）可以設自動、也可以設使用者確認後才執行，不是固定要人審。why-ontology 頁用一個虛構公司 Onyx 當示例：預設情況下 AI 觸發的 action 只能暫存待人審，同一段接著寫”Onyx is able to carefully choose whether any trusted, well-tested AI processes can automatically close the action loop without human review.”（why-ontology 頁）——暫存是預設情境（default case），官方文件同一句話也寫明可以讓經過充分測試的信任流程自動關閉這個迴圈，不是鐵律。

官方文件自己列出 action 的規模上限

單次送出最多能編輯 50 種 object type、10,000 個物件；單筆編輯的大小上限，Object Storage v1 是 32KB、v2 是 3MB。批次呼叫方面，“An action can be called a maximum of 10,000 times in a batch. This limit is reduced to 20 when the action is function-backed and the function is not configured to use batched execution”（scale-and-property-limits 頁）API 的 batch 端點另有自己的上限：“Up to 20 actions may be applied in one call.”（Apply Action Batch API 頁）而且這個端點不支援參數預設值與通知。

Branch 只能用來測試，官方寫明”Action edits on a branch are for testing only and will not be merged back into main”（branching-action-types 頁）；webhook 在 branch 上預設不執行，官方給的理由是避免在測試環境誤寫外部系統，要另外開啟才會跑。開發者社群有兩則貼文可以對照到這些限制的實際使用體感：一則社群論壇匿名帳號在 2026 年 6 月 24 日的貼文寫”Being not able to run actions in the branch.”，在 branch 裡跑不了 action 是貼文者遇到的問題；另一則社群論壇匿名帳號在 2026 年 4 月 5 日的貼文抱怨參數設計，原文（含原始拼字）是”to complicated for Non Technical User”，意思是 Object Reference 與 Object Set 這兩種參數的區分對非技術使用者太複雜。這兩則都是單一使用者的貼文，不代表使用者普遍抱怨。

六款寫回工具的官方頁面各自寫了什麼

拿 Hightouch、Fivetran Activations（前身 Census）、Looker Action Hub、Retool Workflows、Temporal、Microsoft Dataverse 這六款做寫回或工作流的產品，對照它們官方頁面有沒有講到五件事：①寫回外部系統②送出前驗證③副作用（通知或 webhook）④原始資料與編輯的分層⑤逐筆稽核。表格裡的值只有「官方頁有」或「官方頁沒找到」兩種，不代表這些平台做不到，只代表官方定義頁面裡沒有對應的句子。

Dataverse 把驗證、副作用、稽核分放在三個不同頁面、三個元件裡；Palantir 把它們綁進同一個 action type 定義，這是最後一列五格都填得出來的原因。Looker 有寫回，不能一概說語意層完全沒有寫回動作。

Action type 綁住四件事，交易邊界只包物件 edits 與 writeback webhook

難的不是前置條件、副作用、寫回、稽核這四件事分別做得到，而是綁進同一個定義、同一次送出。而 Palantir 自己的文件把交易的邊界畫得很清楚：物件 edits 在交易裡面，副作用在交易外面——writeback webhook 是這裡面唯一被拉進交易邊界的例外，因為失敗會擋下整個送出；side effect webhook 與 notification 都是非同步、best-effort 的。稽核自動記的只有主鍵，屬性值的改前改後要另外設定；自動化的執行是 at-least-once，不是 exactly-once。這是這篇的判斷，官方文件沒有自稱 Actions 是差異化或核心能力。

HASH 在自己的公司部落格裡從另一個角度批評 Palantir，講的是鎖定而不是 Actions 這個機制本身：資料以專有格式存在 Palantir 裡，“any migration would be long and expensive”（HASH 公司部落格，2025 年 4 月 3 日）。這句話對應的是換平台的成本，不是本文拆的交易機制。

回到開頭那句「a single transaction」：交易的邊界，就是物件 edits 在裡面、writeback webhook 在裡面，其他副作用在外面——這正是官方 webhook 比較表裡「Before object changes」與「After object changes」兩列的差別。本系列下一篇：沒有 Palantir，語意層與動作層各能自己做到什麼程度。

常見問題

Q：Palantir 的 Action 送出後，資料會寫回原始資料集嗎？ 不會。使用者編輯永遠寫進 writeback dataset 或 Object Storage v2 的索引層，不會寫回物件類型背後的 backing dataset；要看到「資料源加編輯」的最新狀態，得另外設定 materialization，這是可選的，而且只保證留住最新一版。

Q：Action 的 webhook 失敗，Foundry 的修改會取消嗎？ 看模式。Writeback 模式的 webhook 在物件變更之前執行，失敗就整個 action 不生效；side effect 模式的 webhook 在物件已經改完之後才執行，官方形容是 best-effort，使用者可能已經看到成功訊息，webhook 才失敗。

Q：AI agent 可以直接送出 Action 嗎？ 三個介面各自有自己的規則，官方文件沒有統一成一句「AI 一定要人審」：why-ontology 頁的虛構示例裡，預設情況下 AI 觸發的 action 只能暫存待人審，但也寫明可以讓信任度夠的流程自動關閉迴圈；Chatbot Studio 的 Action 工具可以設定自動執行或需要使用者確認；AIP Logic 的 Apply action block 則明講如果沒有透過 action 執行，Ontology 不會被寫入。

Q：一個 Action 一次最多改多少物件？ 官方文件列出的數字是單次送出最多改 50 種物件類型、10,000 個物件，單筆編輯上限是 32KB（Object Storage v1）或 3MB（Object Storage v2）；批次呼叫上限是 10,000 次，如果是靠 function 執行且沒設定 batched execution，這個上限降到 20 次。