新智元報道

編輯：LRST

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

隨著Scaling Law持續(xù)推進(jìn)，Agent正在從「會回答」走向「會行動」。

當(dāng)智能體開始自主調(diào)用API、執(zhí)行多步工作流、訪問敏感數(shù)據(jù)，甚至連接物理設(shè)備時，僅依賴訓(xùn)練階段的對齊，已越來越難以覆蓋真實(shí)環(huán)境中的系統(tǒng)級風(fēng)險。問題的關(guān)鍵在于：訓(xùn)練是離線的，而風(fēng)險是實(shí)時的。

針對這一困境，香港中文大學(xué)CURE Lab團(tuán)隊(duì)推出了ArbiterOS。它不是又一個外掛式安全補(bǔ)丁，也不只是一個附加在智能體鏈路外層的過濾器，而是面向智能體的治理內(nèi)核（governance kernel）：在高風(fēng)險動作真正執(zhí)行之前，對模型輸出、工具調(diào)用與數(shù)據(jù)流進(jìn)行結(jié)構(gòu)化審查、策略裁決和運(yùn)行時約束。

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

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

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

與此同時，在Agent-SafetyBench與AgentDojo已驗(yàn)證可以成功攻擊的攻擊的示例中，ArbiterOS的實(shí)時攔截率均超過94%；在WildClawBench的高風(fēng)險工作流評測中，系統(tǒng)實(shí)現(xiàn)了100%的及時預(yù)警。

ArbiterOS并不依賴某一種特定智能體框架。除了在OpenClaw上完成系統(tǒng)驗(yàn)證外，團(tuán)隊(duì)還在近期快速適配了新近受到廣泛關(guān)注的HermesAgent，整個接入過程僅需數(shù)小時。

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

項(xiàng)目網(wǎng)址：https://arbiteros.ai/

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

為什么智能體需要運(yùn)行時治理？

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

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

問題至少體現(xiàn)在三個層面。

1. 提示詞約束與人工確認(rèn)并不可靠

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

2. 語義過濾難以理解真實(shí)上下文

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

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

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

綜合上述三個層面，我們可以發(fā)現(xiàn)問題不是「安全插件夠不夠多」，而是當(dāng)前智能體系統(tǒng)仍然缺乏一層真正的運(yùn)行時治理底座。當(dāng)極其聰明、隨時準(zhǔn)備執(zhí)行動作的智能體，在沒有系統(tǒng)級權(quán)限約束的前提下運(yùn)行時，風(fēng)險并不會因?yàn)槟Ｐ透鼜?qiáng)而自然消失。相反，越是面向金融、醫(yī)療、自動化運(yùn)維等高敏感場景，越需要一種可審計、可復(fù)盤、可配置的執(zhí)行前治理機(jī)制。對這些領(lǐng)域而言，不可控、不可審計，往往就等于不可用。

ArbiterOS在補(bǔ)什么缺口？

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

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

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

ArbiterOS 在物理架構(gòu)上徹底剝奪了模型和上層應(yīng)用的底層執(zhí)行主權(quán)，把「想」和「做」進(jìn)行了剛性切割。

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

ArbiterOS 生態(tài)架構(gòu)總覽: AI 智能體 → 治理內(nèi)核 → 模型提供方

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

• 它準(zhǔn)備做什么動作

• 這個動作對應(yīng)的目標(biāo)對象是什么

• 涉及的數(shù)據(jù)來自哪里

• 在當(dāng)前的上下文中，這個動作是否應(yīng)被允許執(zhí)行

這使得智能體安全真正進(jìn)入了動作級、狀態(tài)級、數(shù)據(jù)流級的治理層。

從模型輸出到動作治理

ArbiterOS的四步

為了實(shí)現(xiàn)這種運(yùn)行時治理，ArbiterOS 將整個流程規(guī)范化為四個階段：攔截（Intercept）、解析（Parse）、治理（Govern）、觀測（Observe）。這四步構(gòu)成了 Agent 運(yùn)行時最關(guān)鍵的治理閉環(huán)。

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

1. 攔截：在動作執(zhí)行前先接管

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

2. 解析：把自然語言動作轉(zhuǎn)成機(jī)器可讀的結(jié)構(gòu)化指令

把動作攔下來以后，系統(tǒng)不能繼續(xù)拿自然語言去做風(fēng)險匹配。相比于再用一層語言模型去「猜」意圖，ArbiterOS 的關(guān)鍵設(shè)計是在應(yīng)用層與執(zhí)行層之間建立強(qiáng)制的結(jié)構(gòu)化通信接口。上層 Agent想的可能是「幫我把這段摘要發(fā)給數(shù)據(jù)平臺」，但在真正向下執(zhí)行之前，它必須先將其封裝為機(jī)器可驗(yàn)證的結(jié)構(gòu)化指令，例如：

• Action: HTTP POST

• Target URL: api.external.com

• Payload: [摘要數(shù)據(jù)]

與此同時，系統(tǒng)還會自動掛載與該動作相關(guān)的上下文元數(shù)據(jù)，例如數(shù)據(jù)來源、路徑、調(diào)用對象與執(zhí)行環(huán)境等。因此，這種新型治理是建立在機(jī)器可讀、強(qiáng)約束、可驗(yàn)證的接口協(xié)議之上。只有先把動作表達(dá)清楚，系統(tǒng)才有可能在執(zhí)行前真正進(jìn)行可靠判斷。

3. 治理：用「結(jié)構(gòu)化指令」對動作做安全判定

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

• 主體（Subject）：是誰發(fā)起調(diào)用，屬于什么角色

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

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

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

在前面的例子里，最關(guān)鍵的并不只是「誰發(fā)起了調(diào)用」，而是這段數(shù)據(jù)從哪里來，并會流向哪里。

為了解決這個問題，ArbiterOS在治理層引入了動態(tài)污點(diǎn)追蹤（Dynamic Taint Tracking）機(jī)制：當(dāng)Agent在前序步驟讀取了本地敏感配置、密鑰文件或高風(fēng)險上下文時，系統(tǒng)會為相關(guān)數(shù)據(jù)流附加污點(diǎn)標(biāo)簽，并讓這些標(biāo)簽沿后續(xù)步驟繼續(xù)傳播。

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

也就是說，ArbiterOS關(guān)心的并不只是「當(dāng)前動作危險與否」，而是當(dāng)前動作所用到的數(shù)據(jù)，在整個執(zhí)行鏈路中是否已經(jīng)被高風(fēng)險來源污染。

一旦系統(tǒng)識別出安全風(fēng)險，治理引擎就會做出明確的治理動作，例如：

• 直接阻止

• 打碼或保護(hù)性處理后再放行

• 人工確認(rèn)

需要強(qiáng)調(diào)的是，ArbiterOS并不會粗暴地阻斷系統(tǒng)運(yùn)行。當(dāng)某個動作被拒絕執(zhí)行時，內(nèi)核會向上層返回明確的結(jié)構(gòu)化拒絕信息，說明觸發(fā)了哪類策略、違反了哪條執(zhí)行邊界，以及當(dāng)前動作為何不能被放行。

對于接入得當(dāng)?shù)闹悄荏w工作流而言，這類反饋可以進(jìn)一步被上層狀態(tài)機(jī)、編排器或Agent本身用于選擇后續(xù)處理路徑，例如改寫請求、降級執(zhí)行、等待人工確認(rèn)，或進(jìn)入備份流程。ArbiterOS會盡量保留工作流的可恢復(fù)性與工程可用性。

4. 觀測：把攔截行為變成可復(fù)盤的證據(jù)鏈

治理閉環(huán)的最后一步是觀測。

ArbiterOS會完整記錄每一次攔截的上下文：Agent準(zhǔn)備操作什么對象，數(shù)據(jù)從哪里來，要流向哪里，觸發(fā)了哪條規(guī)則，最后又被如何處理。這一步的意義不只是「留日志」，而是把治理系統(tǒng)從一堆靜態(tài)規(guī)則，變成一個可以持續(xù)優(yōu)化的工程系統(tǒng)。因?yàn)橹挥挟?dāng)攔截行為被轉(zhuǎn)化成可溯源、可復(fù)盤的證據(jù)鏈，開發(fā)者才能真正知道：

• 哪些規(guī)則在起作用

• 哪些規(guī)則誤傷了正常流程

• 哪些風(fēng)險模式還沒有被覆蓋

從而用真實(shí)反饋不斷優(yōu)化后續(xù)策略。

因此，觀測讓治理從「堆砌規(guī)則」變成「工程閉環(huán)」的關(guān)鍵一環(huán)。

ArbiterOS 與現(xiàn)有防護(hù)有何不同？

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

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

• 運(yùn)行時監(jiān)控 / 審批主要解決的是：某一步當(dāng)前看起來是否高風(fēng)險

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

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

智能體準(zhǔn)備執(zhí)行什么動作，這些動作涉及的數(shù)據(jù)從哪里來，以及在當(dāng)前上下文中，這個動作到底應(yīng)不應(yīng)該被允許執(zhí)行。

也正因?yàn)槿绱?，它關(guān)注的不是單條文本，而是結(jié)構(gòu)化指令、上下文狀態(tài)和跨步驟數(shù)據(jù)流。這使得它能夠下沉到真正的執(zhí)行層上來處理，而不僅僅只是提示詞約束。

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

為什么這件事重要？

ArbiterOS的意義在于它驗(yàn)證了一個更關(guān)鍵的方向：

AI治理并不必永遠(yuǎn)停留在模糊的語義風(fēng)險判斷層面，它可以被推進(jìn)到確定的底層動作檢查層。

一旦風(fēng)險邊界被收束到資源訪問、動作執(zhí)行和數(shù)據(jù)流向，原本很多看起來「玄學(xué)」的防守問題，就開始轉(zhuǎn)化為可審計、可配置、可復(fù)盤的工程問題。

而這正是高敏感領(lǐng)域真正需要的東西。未來一個由大量智能體協(xié)同運(yùn)行的「硅基」社會，能否長期穩(wěn)定，不只取決于這些「硅基公民」有多聰明，更取決于底層是否存在一套剛性執(zhí)行的數(shù)字規(guī)則與治理內(nèi)核。

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

目前，ArbiterOS的官網(wǎng)、開源代碼和運(yùn)行Demo已經(jīng)發(fā)布。CURELab團(tuán)隊(duì)也希望邀請更多開發(fā)者和研究者，共同探索這條面向Agent時代的「運(yùn)行時治理」路徑。

參考資料：

https://arbiteros.ai/