Arbiter-K 論文閱讀分析：很多 agent 真正缺的，不是再多一道 guard，而是先有一個真的能執法的 kernel

論文基本資訊

• 論文標題：From Craft to Kernel: A Governance-First Execution Architecture and Semantic ISA for Agentic Computers
• 年份：2026
• 來源：arXiv:2604.18652
• 論文連結：https://arxiv.org/abs/2604.18652
• DOI：10.48550/arXiv.2604.18652
• 主題：Agentic Security、OpenClaw、Runtime Governance、Semantic ISA、Prompt Injection、Neuro-Symbolic Systems

很多 agent 系統真正缺的，可能不是再多一層 wrapper、再多一條 prompt 規則，甚至也不是再多一個「比較會抓風險」的 judge model；它們真正缺的，是一個像 kernel 一樣有執法權、而不是只會在旁邊勸人的執行層。

這篇 From Craft to Kernel: A Governance-First Execution Architecture and Semantic ISA for Agentic Computers 想打的，就是現在大多數 agent runtime 的核心假設：我們一直把 LLM 放在控制迴圈中央，然後再用各種 guardrails 去補它；但也許這個架構本身才是問題。

作者的答案非常硬派：把模型降級成 proposal generator，把真正有權決定「能不能做」的角色交給 deterministic kernel。 他們把這套設計叫做 Arbiter-K，核心不是再教模型更乖，而是把 agent execution 重新抽象成一種可審計、可攔截、可回滾的 microarchitecture。

這篇論文在做什麼？

作者主張，當前 agent framework 最大的 category error，是把一個本質上機率性、不可完全預期的模型，當成整個系統的主控制器。這會導致幾個老問題一直反覆出現：

• prompt injection 或語意偏移一進來，就會沿著整條 execution trace 往後傳
• policy 常常只能在最後工具呼叫那一下才跳出來
• runtime 看得到文字，卻看不到哪段資料影響了哪個高風險動作
• 一旦違規，很多系統只能整段 abort，浪費整條任務軌跡

所以這篇不是做一個新的 filter，而是想把 agent 系統重新拆成兩層：

• PPU（Probabilistic Processing Unit）：也就是 LLM，只負責推理、提案、產生下一步意圖
• Symbolic Kernel：負責檢查、攔截、追蹤資料流、執行權限決策，並在必要時觸發修正或回滾

這個思路的重點是：安全不再是附加元件，而是 execution architecture 本身的性質。

最重要的概念：Semantic ISA

整篇最值得記住的技術觀念，是作者把 agent runtime 類比成一台新型電腦，並提出 Semantic ISA（語意指令集架構）。

它要解的問題很實際：如果模型輸出永遠只是一串文字，那 runtime 幾乎不可能做細粒度治理。因為系統不知道哪一段是思考、哪一段是 memory 操作、哪一段是工具調用意圖、哪一段會觸發真實 side effect。

所以作者主張，要先把 opaque token stream reify 成可分類、可驗證的 semantic instructions，再讓 kernel 依照 instruction 類型套不同的治理規則。文中把 ISA 拆成五個邏輯 core，包含：

• Cognitive Core：機率式推理，預設不可信
• Memory Core：記憶載入、壓縮、寫入與脈絡治理
• Execution Core：會碰到外部世界的操作，必須先驗證
• Governance Core：執行 policy、budget、permission、taint checks
• Recovery / Control 類機制：在違規時做 correction、rollback、exception handling

換句話說，這篇真正不是在談「怎麼擋壞 prompt」，而是在談「怎麼讓 agent runtime 先有 instruction-level constitution」。

Arbiter-K 核心機制：把資料流 pedigree 變成可攔截的治理訊號

有了 Semantic ISA 之後，Arbiter-K 再往下做了兩個很關鍵的 runtime 結構：

• Security Context Registry：記錄當前執行所處的安全脈絡、資源邊界與權限狀態
• Instruction Dependency Graph（IDG）：把每個 reasoning node / action node 的資料依賴關係接起來

這樣一來，kernel 就不只是在工具邊界做一次 allow/deny，而是可以沿著 dependency graph 做 active taint propagation：某段不可信輸入、某個跨來源 context、某條可疑回應，到底後面影響了哪些 instruction，哪些 instruction 又會走到 deterministic sink，例如：

• 高風險 tool call
• 外部網路請求
• 跨 session delegation
• 可能造成 side effect 的 UI / calendar / communication actions

這裡我覺得它最有價值的一點，是它把「prompt injection 影響了系統」這件事，從語意猜測拉成了可被 runtime 結構化追溯的資料流問題。這個方向其實比單純做輸入偵測器更像 production-grade 安全設計。

這篇最強的一句話：不要再讓模型當 kernel

如果要用一句話總結 Arbiter-K，我會寫成：

真正該做的不是把 stochastic model 訓練得比較像 kernel，而是乾脆別讓它當 kernel。

這句話很重要，因為現在很多 agent 安全方案，本質上都還是在同一個舊前提下補丁：

• 模型先決定下一步
• 外面再包一層 policy / detector / verifier
• 如果違規，就 whole-session abort 或重跑

作者認為這種做法的問題不是不努力，而是 architectural wrongness：一個不可信的 probabilistic component 不應該主導系統控制流。 只要這個前提不改，後面的 guardrail 再精巧，也常常只能做局部修補。

評估怎麼做？

作者把 Arbiter-K 實作在 OpenClaw 和 NanoBot 上，並用多個 benchmark slice 做 replay evaluation。unsafe case 主要來自：

• AgentDojo
• Agent-SafetyBench

論文整理出的 unsafe replay case 有 1,914 筆，其中包含 539 筆 AgentDojo 與 1,375 筆 Agent-SafetyBench。評估重點主要看三件事：

• unsafe interception rate：危險操作攔得住多少
• safe pass rate：正常任務被誤擋多少
• trajectory-level block timing：是早期就攔下，還是等快造成結果才攔

這組設計比只看最後有沒有出事好很多，因為 agent 系統最麻煩的從來不只是 final answer，而是整條執行鏈何時開始被污染、何時開始越權。

最重要的結果：從 0–9% 攔截率，直接拉到 76–95%

這篇最醒目的結果，是 native host policies 幾乎沒什麼像樣的攔截能力。

作者在 Figure 7 總結：原生 host guardrails 對 unsafe operations 的攔截率只有 0% 到 9%；換上 Arbiter-K 之後，則能穩定拉到 76% 到 95%。

其中幾個最值得記的數字：

• OpenClaw 原生 policy：只攔下 6.17%（118 / 1,914）
• OpenClaw + Arbiter-K：攔下 92.95%（1,779 / 1,914）
• 絕對提升：+86.78 個百分點
• NanoBot 原生 policy：只攔下 1.41%
• Arbiter-K on NanoBot：93.16%
• 完整 NanoBot stack：94.20%

這些數字真正有殺傷力的地方在於：它不是從 70% 拉到 80%，而是從幾乎沒防住，直接拉到大多數危險流程都能被攔下。

代價高不高？有，但沒有高到不實用

只看攔截率還不夠，因為任何系統都可以靠瘋狂 overblock 來把 unsafe 攔很高。所以這篇另一個關鍵，是它有把 benign pass rate 一起攤開。

在 NanoBot 的可遷移 benign subset 上：

• Arbiter-K on NanoBot 維持 98.97%（192 / 194）的 benign pass rate
• 同時把 unsafe interception 從 1.41% 拉到 93.16%

在 OpenClaw 上，代價比較明顯，但也還算合理：

• aggregate benign pass rate 從 92.95%（290 / 312）
• 降到 88.78%（277 / 312）

而且作者有去看 false positives 集中在哪裡，結果不是亂槍打鳥，而是比較集中在：

• cross-session delegation
• calendar / UI side effects
• external communication actions

相反地，read-only browsing、文件分析、檔案處理、提醒、營運診斷 這些偏低副作用任務大多仍能正常通過。這點很重要，因為代表 Arbiter-K 不是單純把 agent 變成什麼都不能做，而是更有選擇性地卡在真正麻煩的 sink 周圍。

它不只會攔，還比較早攔

這篇還有一個我很喜歡的指標：first block onset。因為 production 裡最貴的，不只是「最後有沒有攔住」，而是你到底在第幾步才發現整條任務早就走偏。

在 OpenClaw end-to-end block summary 裡：

• Arbiter-K + OpenClaw 的 trajectory block rate：98.33%
• OpenClaw only：23.01%
• Arbiter-K 在 前 50% 軌跡內就出現 first block 的比例：52.88%
• OpenClaw only：6.12%
• OpenClaw 完全沒 block 的 unsafe trajectories：77.00%
• Arbiter-K：只剩 1.67%

這代表它不是只在最後一刻把結果擋掉，而是更常在危險語意還在長成 side effect 之前就先卡住。對 agent runtime 來說，這個差異非常大。

另一個很實際的點：不要整段重跑，應該儘量 reuse context

作者也抓到一個很務實的問題：很多 agent 一旦違規，就整段 session abort，然後從頭再跑。這在長任務上超浪費。

Arbiter-K 想把 violation 當成 architectural exception 來處理，也就是：

• 保留前面大部分可重用脈絡
• 只把政策回饋注入後續執行
• 避免每次都 full rollback

Table 6 的數字很漂亮：

• Agent-SafetyBench：平均可保留 73.8% 的完整軌跡 tokens，平均 feedback 只需 249.6 tokens
• AgentDojo：平均可保留 58.3% 的完整軌跡 tokens，平均 feedback 約 303.4 tokens

也就是說，這套架構不是只會說「不行」，而是開始有能力回答另一個 production 更重要的問題：不行之後，怎麼在不浪費整條任務的前提下繼續做。

這篇真正有價值的地方在哪？

我覺得這篇最強的地方不是數字本身，而是它把 agent security 的討論往前推了一層。

過去很多工作在問：

• 怎麼偵測 prompt injection？
• 怎麼把 tool call 包進 policy？
• 怎麼設計更好的 benchmark？

但 Arbiter-K 問的是更底層的問題：

如果 probabilistic reasoning 和 deterministic execution 之間沒有正式介面，那你其實根本還沒辦法談真正的 runtime governance。

這也是為什麼它特別值得跟最近幾篇 agent runtime / governance 文章一起看。它不是在補某一個 threat class，而是在補整個 execution substrate。

我怎麼看這篇的限制？

當然，這篇也不是沒風險。

• Semantic ISA 的抽象是否足夠通用：不同 agent framework、不同工具生態、不同 memory 模型，能不能都穩定映射進同一套 ISA，還需要時間驗證。
• 語意 reification 本身會不會成為新瓶頸：如果 instruction decoding 不穩，後面整個治理鏈也可能被污染。
• policy quality 仍然重要：kernel 再強，若 policy 本身對風險定義錯了，也只是更穩定地執行錯誤治理。
• 目前 benchmark 仍以 injection / unsafe tool-use 為主：對更長期的 memory drift、跨代理協作污染、經濟濫用等問題，還需要更多驗證。

但即便如此，這篇仍然有很高的參考價值，因為它至少把安全問題放回了一個比較對的位置：不是模型偶爾說錯話，而是整台 agent computer 到底要怎麼被治理。

一句話總結

這篇論文真正想提醒的，不是 agent 需要更多 guardrails，而是該停止把 guardrails 當成建築本體。

如果你讓 LLM 繼續站在控制流正中央，很多防線都只能是補丁；但如果你先承認它只是 PPU，再把 deterministic kernel、Semantic ISA、dependency tracking、taint propagation 與 rollback / feedback loop 補上，agent security 才比較像一個可以工程化、而不是只能祈禱的系統。

對 sectools.tw 這條線來說，Arbiter-K 的位置很清楚：它不是再證明 prompt injection 很危險，而是開始回答「那 production 級 agent computer 應該長成什麼架構」這個真正該被回答的問題。