剝奪大模型執行權！港中文開源Agent治理內核，高危攔截率達92.95%

新智元報道

編輯：LRST

【新智元導讀】ArbiterOS是一種面向智能體的運行時治理系統，不依賴傳統安全手段，而是通過攔截、解析、治理、觀測四步流程，提升智能體在復雜環境中的安全性與可控性，適用于多種智能體框架，為高敏感領域提供可復用的治理底座。

隨著Scaling Law持續推進，Agent正在從「會回答」走向「會行動」。

當智能體開始自主調用API、執行多步工作流、訪問敏感數據，甚至連接物理設備時，僅依賴訓練階段的對齊，已越來越難以覆蓋真實環境中的系統級風險。問題的關鍵在于：訓練是離線的，而風險是實時的。

針對這一困境，香港中文大學CURE Lab團隊推出了ArbiterOS。它不是又一個外掛式安全補丁，也不只是一個附加在智能體鏈路外層的過濾器，而是面向智能體的治理內核（governance kernel）：在高風險動作真正執行之前，對模型輸出、工具調用與數據流進行結構化審查、策略裁決和運行時約束。

論文鏈接：https://arxiv.org/pdf/2604.18652

如果說傳統操作系統負責管理人類程序的資源訪問與運行邊界，那么在Agent時代，ArbiterOS 試圖補上的，正是自主行動智能體長期缺失的一層運行時治理能力。

在工程化測試中，ArbiterOS 展現出了顯著的安全增益。以主流智能體系統 OpenClaw 為例，在一組涉及私鑰泄露、敏感配置外發、文件誤刪等高風險任務中，原生系統的高危步驟攔截率僅為 6.17%；接入 ArbiterOS 后，這一指標提升至 92.95%。

與此同時，在Agent-SafetyBench與AgentDojo已驗證可以成功攻擊的攻擊的示例中，ArbiterOS的實時攔截率均超過94%；在WildClawBench的高風險工作流評測中，系統實現了100%的及時預警。

ArbiterOS并不依賴某一種特定智能體框架。除了在OpenClaw上完成系統驗證外，團隊還在近期快速適配了新近受到廣泛關注的HermesAgent，整個接入過程僅需數小時。

對于非Claw類Agent，ArbiterOS同樣可以支持。它真正依賴的，是開發者能否將智能體的動作語義、執行邊界和關鍵風險點清晰定義為可治理的policy。這也意味著，ArbiterOS的潛力并不止于一個特定生態插件，而是一層可遷移、可復用的Agent運行時治理內核。

項目網址：https://arbiteros.ai/

GitHub地址：https://github.com/cure-lab/ArbiterOS

為什么智能體需要運行時治理？

過去一段時間，圍繞OpenClaw等通用智能體框架，業界已經出現了大量安全增強方案，包括提示詞約束、附加式Guardrail、流程審批、安全監控和沙箱隔離等。

客觀地說，這些方法都具有現實價值。但如果把現有主流防護手段拆開來看，會發現它們大多要么在輸入端加限制，要么在輸出端做過濾，要么在運行環境外層做剛性約束。它們能緩解風險，卻還不足以構成一套真正面向智能體行動的治理架構。

問題至少體現在三個層面。

1. 提示詞約束與人工確認并不可靠

大模型底層并不能天然嚴格地區分「指令」和「數據」。這意味著攻擊者可以通過 Prompt Injection 等方式，把原本只是數據的一段內容重新偽裝成系統指令，繞過文本層的約束。與此同時，頻繁的彈窗確認也并不是理想解法，這樣用戶會疲于應對，并且普通用戶往往也并不具備判斷某個 API 調用、外部請求或系統操作背后真實風險的能力。系統看似「處處詢問」，實際卻未必真正更安全。

2. 語義過濾難以理解真實上下文

附加式 Guardrail 更擅長判斷單次輸入或輸出在語義上是否可疑，因此對于明顯的敏感信息泄露或違規表達，往往仍具備一定效果。但它通常并不掌握完整的系統狀態，也難以持續追蹤數據來源，所以容易漏掉另一類更隱蔽的風險：局部語義完全正常、但在全局上下文中不應發生的操作。例如，代理向外部服務發起了一次格式合法、參數普通的 HTTP 請求，請求中引用的資源標識或業務數據看上去都無異常；然而這些數據實際上來自前序步驟中的越權讀取，或屬于當前用戶無權訪問的上下文。由于缺乏跨步驟、跨來源的全鏈路感知，這類風險很容易繞過語義層面的單點語義護欄。

3. 沙箱隔離會陷入「安全—可用性」的權衡

傳統沙箱依賴的是剛性限制：限制目錄、限制網絡、限制設備訪問。但沙箱本身并不理解 Agent 的意圖，也無法判斷「這次修改配置到底是正常維護，還是惡意篡改」。如果過度隔離，Agent 的實際能力會被直接削弱；如果為了生產力而打開足夠多的權限，風險又會順著這些權限縫隙重新滲透回來。

綜合上述三個層面，我們可以發現問題不是「安全插件夠不夠多」，而是當前智能體系統仍然缺乏一層真正的運行時治理底座。當極其聰明、隨時準備執行動作的智能體，在沒有系統級權限約束的前提下運行時，風險并不會因為模型更強而自然消失。相反，越是面向金融、醫療、自動化運維等高敏感場景，越需要一種可審計、可復盤、可配置的執行前治理機制。對這些領域而言，不可控、不可審計，往往就等于不可用。

ArbiterOS在補什么缺口？

ArbiterOS 的核心主張可以概括為一句話：把安全從不穩定的語義博弈，推進到確定的動作治理。

它提出了一種「治理優先」的架構設想：無論上層 Agent 使用了多復雜的Prompt、多長的上下文、多步推理或多種工具，只要它最終準備執行一個高風險動作，例如寫本地文件、修改關鍵配置、對外發起網絡請求，這個動作都會先被ArbiterOS接管，轉換為機器可讀、可檢查的請求，再交由治理內核審查。只有當該動作滿足預先配置好的「數字契約」后，才會真正被放行。

這也是為什么 ArbiterOS 更適合被理解為 Agent Kernel / Agent OS 的雛形，而不只是一個外掛式的過濾網或安全組件。其核心在于向智能體領域首次引入了底層系統的黃金法則——「特權分離（Privilege Separation）」。

ArbiterOS 在物理架構上徹底剝奪了模型和上層應用的底層執行主權，把「想」和「做」進行了剛性切割。

它像一個系統層中間件那樣，站在「智能決策」和「真實執行」之間：模型只負責思考和提出動作候選，而 ArbiterOS 作為唯一掌握物理接口的內核，負責冷酷地決定哪些動作在當前上下文中可以真正落地執行。

ArbiterOS 生態架構總覽: AI 智能體 → 治理內核 → 模型提供方

從工程角度看，這種區別非常關鍵。它意味著 ArbiterOS 關心的不是「模型是不是說了一句看起來危險的話」，而是：

• 它準備做什么動作

• 這個動作對應的目標對象是什么

• 涉及的數據來自哪里

• 在當前的上下文中，這個動作是否應被允許執行

這使得智能體安全真正進入了動作級、狀態級、數據流級的治理層。

從模型輸出到動作治理

ArbiterOS的四步

為了實現這種運行時治理，ArbiterOS 將整個流程規范化為四個階段：攔截（Intercept）、解析（Parse）、治理（Govern）、觀測（Observe）。這四步構成了 Agent 運行時最關鍵的治理閉環。

ArbiterOS四步治理流程:從原始輸出到治理后輸出——攔截、解析、策略、觀測的完整鏈路

1. 攔截：在動作執行前先接管

當 Agent 讀完一份配置文件，接著準備向外部 API 發起請求時，ArbiterOS 的第一步不是判斷它「語氣危不危險」，而是先接管這個動作。這是整個系統成立的前提。因為在 Agent 場景里，許多高風險動作一旦發生就是瞬時且不可逆的：數據一旦外發，文件一旦刪除，事后再分析日志、寫事故報告，都已經太晚。真正的治理必須發生在動作執行之前，而不是事故發生之后。攔截解決的是第一個核心問題：不能讓系統進入「先做了再說」的狀態。

2. 解析：把自然語言動作轉成機器可讀的結構化指令

把動作攔下來以后，系統不能繼續拿自然語言去做風險匹配。相比于再用一層語言模型去「猜」意圖，ArbiterOS 的關鍵設計是在應用層與執行層之間建立強制的結構化通信接口。上層 Agent想的可能是「幫我把這段摘要發給數據平臺」，但在真正向下執行之前，它必須先將其封裝為機器可驗證的結構化指令，例如：

• Action: HTTP POST

• Target URL: api.external.com

• Payload: [摘要數據]

與此同時，系統還會自動掛載與該動作相關的上下文元數據，例如數據來源、路徑、調用對象與執行環境等。因此，這種新型治理是建立在機器可讀、強約束、可驗證的接口協議之上。只有先把動作表達清楚，系統才有可能在執行前真正進行可靠判斷。

3. 治理：用「結構化指令」對動作做安全判定

當拿到結構化指令與元數據之后，不同于依賴系統提示詞或自然語言約束的做法，ArbiterOS的治理引擎會采用類似于基于屬性的訪問控制（ABAC）的邏輯，對可疑的危險動作做安全判定：

• 主體（Subject）：是誰發起調用，屬于什么角色

• 動作（Action）：讀取、寫入、修改配置、外發請求等

• 客體（Object/Target）：訪問的是哪個文件、哪個域名、哪個資源

• 條件（Condition）：這個動作的數據來自哪里，是否包含敏感來源，是否處在允許上下文中

在前面的例子里，最關鍵的并不只是「誰發起了調用」，而是這段數據從哪里來，并會流向哪里。

為了解決這個問題，ArbiterOS在治理層引入了動態污點追蹤（Dynamic Taint Tracking）機制：當Agent在前序步驟讀取了本地敏感配置、密鑰文件或高風險上下文時，系統會為相關數據流附加污點標簽，并讓這些標簽沿后續步驟繼續傳播。

這樣一來，即使某個后續動作本身在語義上看起來是合法的，比如一次普通的HTTP POST，請求中只要攜帶了來自敏感來源的數據，策略引擎就能在高風險動作執行前識別危險并觸發阻斷、脫敏或用戶確認等治理動作。

也就是說，ArbiterOS關心的并不只是「當前動作危險與否」，而是當前動作所用到的數據，在整個執行鏈路中是否已經被高風險來源污染。

一旦系統識別出安全風險，治理引擎就會做出明確的治理動作，例如：

• 直接阻止

• 打碼或保護性處理后再放行

• 人工確認

需要強調的是，ArbiterOS并不會粗暴地阻斷系統運行。當某個動作被拒絕執行時，內核會向上層返回明確的結構化拒絕信息，說明觸發了哪類策略、違反了哪條執行邊界，以及當前動作為何不能被放行。

對于接入得當的智能體工作流而言，這類反饋可以進一步被上層狀態機、編排器或Agent本身用于選擇后續處理路徑，例如改寫請求、降級執行、等待人工確認，或進入備份流程。ArbiterOS會盡量保留工作流的可恢復性與工程可用性。

4. 觀測：把攔截行為變成可復盤的證據鏈

治理閉環的最后一步是觀測。

ArbiterOS會完整記錄每一次攔截的上下文：Agent準備操作什么對象，數據從哪里來，要流向哪里，觸發了哪條規則，最后又被如何處理。這一步的意義不只是「留日志」，而是把治理系統從一堆靜態規則，變成一個可以持續優化的工程系統。因為只有當攔截行為被轉化成可溯源、可復盤的證據鏈，開發者才能真正知道：

• 哪些規則在起作用

• 哪些規則誤傷了正常流程

• 哪些風險模式還沒有被覆蓋

從而用真實反饋不斷優化后續策略。

因此，觀測讓治理從「堆砌規則」變成「工程閉環」的關鍵一環。

ArbiterOS 與現有防護有何不同？

如果把現有Agent安全手段放到一個統一視角下，可以更清楚地看出ArbiterOS的位置。

• 沙箱隔離主要解決的是：代碼或智能體可以接觸哪些資源

• 運行時監控 / 審批主要解決的是：某一步當前看起來是否高風險

• 語義Guardrail主要解決的是：輸入輸出在文本語義上是否可疑

而ArbiterOS解決的是另一個更底層、更全局的問題：

智能體準備執行什么動作，這些動作涉及的數據從哪里來，以及在當前上下文中，這個動作到底應不應該被允許執行。

也正因為如此，它關注的不是單條文本，而是結構化指令、上下文狀態和跨步驟數據流。這使得它能夠下沉到真正的執行層上來處理，而不僅僅只是提示詞約束。

從這個意義上說，ArbiterOS的價值更接近一套可遷移的運行時治理方法：上層Agent可以變化，底層模型可以變化，具體框架也可以變化；只要開發者能夠把智能體的動作語義、敏感資源和可執行邊界清晰定義成policy，ArbiterOS就可以成為這些系統共享的一層治理底座。這也是它能在 OpenClaw 之外快速接入 Hermes，并具備支持更廣泛非Claw智能體的潛力的原因。

為什么這件事重要？

ArbiterOS的意義在于它驗證了一個更關鍵的方向：

AI治理并不必永遠停留在模糊的語義風險判斷層面，它可以被推進到確定的底層動作檢查層。

一旦風險邊界被收束到資源訪問、動作執行和數據流向，原本很多看起來「玄學」的防守問題，就開始轉化為可審計、可配置、可復盤的工程問題。

而這正是高敏感領域真正需要的東西。未來一個由大量智能體協同運行的「硅基」社會，能否長期穩定，不只取決于這些「硅基公民」有多聰明，更取決于底層是否存在一套剛性執行的數字規則與治理內核。

ArbiterOS邁出的，正是走向「數字規則」的一步：用確定性的規則，約束不確定的硅基智能，為金融、醫療、自動化運維等高風險場景中的AI應用建立最后一道可被信任的執行底座。

目前，ArbiterOS的官網、開源代碼和運行Demo已經發布。CURELab團隊也希望邀請更多開發者和研究者，共同探索這條面向Agent時代的「運行時治理」路徑。

參考資料：

https://arbiteros.ai/