這項由清華大學計算機科學與技術系主導的研究，以預印本形式發布于2026年6月，論文編號為arXiv:2606.03895，有興趣深入了解的讀者可通過該編號查詢完整論文。

當你叫一個助手幫你整理文件時，你當然希望它只動你允許它動的那一個文件夾，而不是在你毫不知情的情況下把整個硬盤翻了個底朝天。更重要的是，如果它準備刪掉某個重要文件，你希望它先來問你一聲，而不是直接動手。現在的AI智能體（Agent）正在被越來越多地用于處理復雜任務，比如幫程序員改代碼、幫分析師整理報告，甚至管理文件和發送消息。但問題是，現有的AI智能體框架在這方面做得很不夠——它們更像是一個沒有任何管制的員工，能做什么、被允許做什么，全靠自覺，沒有一套可靠的"規章制度"來約束。

清華大學的研究者們正是注意到了這個痛點，于是提出了一套名為"Agent libOS"的新型運行機制。這套機制的核心思路，是把計算機操作系統（比如Windows、Linux）里那些成熟的管理方法，搬到AI智能體的運行環境里來。就像操作系統管理著你電腦上運行的每一個程序——每個程序有自己的身份、權限、內存空間，不能隨意侵入別的程序——Agent libOS也要為AI智能體建立一套同樣嚴格的"運行規則"。

一、現有AI智能體框架的根本問題是什么

要理解這項研究解決了什么問題，先得弄清楚現有AI智能體是怎么工作的。目前絕大多數AI智能體框架的工作方式，可以用一個簡單的畫面來描述：AI模型坐在一張桌子旁邊，桌上擺著一套"工具箱"，每個工具都有一張說明卡，上面寫著"這個工具能幫你寫文件"、"那個工具能幫你運行命令"。AI模型看到任務，挑一個工具，調用它，拿到結果，再繼續。這個過程被稱為"對話循環"（chat loop），是ReAct、AutoGen、MetaGPT等主流框架的共同基礎。

這套方法的麻煩在于，工具說明卡上寫的"能幫你做什么"，和工具背后真正能觸碰哪些資源，往往是同一條線——中間沒有任何隔離。換句話說，如果AI模型能"看到"一個叫"寫文件"的工具，那么這個工具背后的代碼就可能直接往你的硬盤上隨便寫東西。這就好比你雇了一個保險柜管理員，告訴他"你可以開鎖"，結果他手里拿著的鑰匙能開整棟樓所有房間的鎖，而你以為他只能開那一間。

更嚴重的是，在一些攻擊場景下，惡意文件或網頁里的內容可以"注入"指令，欺騙AI模型去做它本不該做的事。這被稱為"間接提示注入攻擊"。如果AI智能體的工具權限沒有被嚴格限制，這種攻擊就能造成真實的危害。研究團隊明確指出，現有框架里，確認提示可能圍繞著工具包裝存在，但真正觸碰宿主資源的底層操作幾乎從來不是策略邊界——這一點在長期運行、權限隨時間變化的智能體場景下尤為脆弱。

二、用操作系統的思路重新設計AI智能體的"地基"

Agent libOS的核心思想，來自于一個非常經典的計算機系統概念——"庫操作系統"（library OS，libOS）。在傳統計算機世界里，庫操作系統的做法是：把操作系統的一部分功能，從系統內核里"搬"到應用程序自己的層面來管理，形成一道介于應用和底層硬件之間的保護層。Agent libOS借用了這個思路，但它保護的不是CPU核心或磁盤扇區，而是AI智能體特有的那些資源：內存對象、工具表、文件路徑、人類審批、檢查點記錄、外部副作用等等。

整個Agent libOS的架構分為五個層次，從上到下依次是：最頂層是智能體的"個性與應用"，也就是它的角色定義和任務策略；第二層是"技能與工具層"，這是AI模型能直接看到和調用的那些工具，研究者把它比作C語言里的標準庫（libc）——只是接口，不是權力的來源；第三層才是真正的核心，叫做"Agent libOS運行時"，所有關于"能不能做"的判斷都在這里發生；第四層是"資源提供者基底"，負責把運行時的抽象操作連接到具體的文件系統、時鐘、命令行等宿主服務；最底層則是實際的硬件和軟件環境，比如模型API、本地文件系統、Deno運行時等。

這套架構傳遞出一個非常清晰的設計原則，研究者把它總結為："工具是類libc的包裝器；運行時原語才是權力邊界。"用白話說就是：AI模型能看到什么工具，和它真正被允許做什么事，是兩件完全不同的事情。看到"寫文件"這個工具，不等于有權限往任何地方寫文件。

三、AgentProcess：給每個AI智能體一張"身份證"

在Agent libOS里，每一個運行中的AI智能體被稱為一個"AgentProcess"（智能體進程）。這個概念直接借用了操作系統里"進程"的設計——就像你的電腦上，每個打開的程序都是一個獨立的進程，有自己的編號、狀態和資源分配一樣。

一個AgentProcess擁有進程編號、父進程編號（誰啟動了它）、鏡像編號（它基于什么模板創建）、生命周期狀態、目標對象、內存視圖、能力集合、工具表、檢查點、資源預算、工作目錄，以及狀態消息這一整套屬性。每個進程從一個"AgentImage"（智能體鏡像）創建，鏡像固定了默認工具、系統提示、上下文策略、安全配置文件和所需能力。目前系統內置了基礎智能體、編程智能體、評審智能體和工具制作者智能體四種鏡像。

智能體進程支持一整套類似操作系統的生命周期操作。"spawn"（生成）會創建一個全新的子進程，這個子進程擁有自己獨立的命名空間，只繼承目標信息，而不是父進程的全部對話記錄。"fork"（分叉）則會縮減內存視圖和資源預算，而且，在原型系統里，除非明確授權，否則子進程不會自動繼承父進程的文件寫入權限——這一點非常關鍵，防止了權限通過進程樹悄悄擴散。"wait"（等待）是一個可恢復的阻塞操作：父進程進入等待狀態，當子進程退出時，等待會自然恢復，完全不需要AI模型再發出第二個等待指令。"exec"（替換執行）會保留進程編號，同時把鏡像和工具表換掉，但不會自動獲取新鏡像所要求的能力，因此無法借此提升權限。"exit"（退出）會釋放臨時的草稿對象，除非明確保留結果。

每個進程還有一個工作目錄，類似于命令行里的"當前目錄"。所有的文件路徑和命令行操作，都相對于這個工作目錄來解析，宿主Python進程本身不會因此改變自己的目錄，保持了進程級別的隔離。

四、對象內存：讓AI的"記憶"也有權限控制

在現有的AI智能體框架里，智能體的"記憶"通常就是一段不斷增長的對話文本——你說一句，模型回一句，結果追加一句，就這樣堆下去。這種方式既不安全，也不高效。Agent libOS里引入了一種叫做"對象內存"（Object Memory）的結構，把智能體的中間狀態表示為一個有類型的、受權限保護的對象圖。

每個對象代表一種具體的信息單元，比如目標、計劃、消息、工具結果、觀察記錄、錯誤追蹤、代碼補丁、摘要、技能或外部引用。每個對象都有對象編號、命名空間內的本地名稱、類型、載荷、元數據、來源記錄、版本號、不可變標志、創建者信息和時間戳。

一個關鍵的設計決策是：知道對象的名字，不等于有權限讀取它。這遵循了計算機安全領域一個經典原則——"發現"和"授權"必須分開。就像你知道銀行保險庫在哪棟樓，不等于你能走進去取錢一樣。系統的回歸測試專門覆蓋了"直接名稱查找"和"按名稱查詢"兩種方式，確保單純知道名字無法繞過對象讀取權限。

對象名稱是局部于命名空間的。如果進程在操作時不指定命名空間，系統就默認使用該進程私有的命名空間。不同進程的私有命名空間里可以有同名對象，但它們完全獨立，互不干擾——這讓對象內存更像是每個進程自己的"內存地址空間"，而不是一張人人都能查詢的全局表。

在技術實現上，對象的載荷存儲在運行時的內存堆里，而不是直接寫入數據庫。SQLite只保存目錄元數據和一個"載荷在內存中"的標記。這樣做的目的是明確區分運行時的臨時狀態和持久化的存儲：短暫的草稿不應該自動變成數據庫記錄，進程退出時也會自動清理屬于自己的臨時對象。

在每次向AI模型發起調用之前，一個"物化器"（materializer）會把進程的內存視圖轉換成有界限的文字上下文送給模型，模型自始至終看不到對象存儲本身。這種思路和麻省理工學院等機構提出的MemGPT（把LLM的上下文管理類比為虛擬內存）有相似之處，但區別在于，Agent libOS的分頁單位是帶有類型、來源記錄和權限的對象，而不是純粹的文本片段。

五、能力系統：每一步操作都要持"通行證"

Agent libOS的權限控制核心是一套"能力"（capability）系統。每一個能力綁定了：誰可以用（主體）、操作什么資源、有哪些權利、有哪些約束、是誰發放的、有效期多長、以及是否已被吊銷。受能力保護的資源包括對象編號、對象內存命名空間、工作區文件路徑、人類操作者、權限策略條目、命令行策略、鏡像注冊表條目和工具表條目。

每次執行底層原語操作時，系統都會在調用點實時檢查能力。這意味著一旦某個能力被撤銷，下一次調用就會立刻被攔截，工具包裝層完全無法繞過這道檢查。

文件寫入操作支持四種策略：始終允許、始終拒絕、每次詢問和一次性允許。在"每次詢問"策略下，底層原語會創建一個阻塞的人類審批請求，審批通過后獲得一個一次性能力，僅供這一次操作消費。審批被拒絕時，進程會收到一個結構化的"失敗"工具結果，可以繼續運行或者主動退出，而不是直接崩潰。

人類審批請求包含了極其詳細的信息：進程編號、原語類型、相對路徑、絕對路徑、授權范圍、覆蓋預測、字節數、內容的SHA-256哈希值、目標狀態、請求的一次性能力，以及經過安全轉義處理的內容預覽。內容預覽使用了repr轉義，這是一個安全決策——原始的不可信內容不應該能夠插入看起來像是可信審批指令的終端行。

命令行執行也被納入原語管理，而不是交給任意的包裝函數來處理。命令行接口接受參數數組而非命令字符串，從而避免了Shell展開帶來的意外執行風險。進程級別的命令行策略支持始終拒絕、白名單自動批準否則詢問、黑名單詢問否則自動批準，以及高風險的始終允許四種模式。匹配是基于分詞后的參數進行的，黑名單檢查還會檢測嵌套的可執行語法，比如解釋器鏈。超時和輸出截斷都在原語內部強制執行，因此無論是AI模型調用的工具還是即時生成的工具，都遵守同樣的邊界規則。

六、人類審批隊列：讓AI"等"人類，而不是讓人類"追"AI

在很多現有系統里，如果需要人類審批，往往是通過一個專門寫在演示腳本里的回調函數來處理的——這意味著審批邏輯和具體的應用代碼綁定在一起，換一個場景就要重新寫一套。Agent libOS把人類的參與提升為一等公民的運行時行為。

人類被建模為連接到隊列的運行時對象。進程可以向人類輸出消息、提問、請求權限，也可以接收中斷。當一個底層原語需要人類輸入時，進程進入"等待人類"（WAITING_HUMAN）狀態，LLM執行器記錄下待處理的動作，但不會返回一個錯誤的工具失敗結果。高級督導循環會清空人類隊列，應用決策，在適當時候喚醒進程，并恢復待處理的動作。

這種機制類似于操作系統里進程阻塞在終端設備的系統調用上——進程在等待鍵盤輸入時不會占用CPU，其他進程可以繼續運行，直到輸入到來再恢復。Agent libOS把同樣的結構用于人類審批和提問。類似地，sleep操作調用的是異步時鐘原語，一個進程休眠時不會阻塞其他進程。

系統提供了一個公開的高級API，會持續推進運行時，直到沒有可運行或可恢復的工作為止。測試時可以關閉隊列清空功能，以便檢查"等待人類"中間狀態，這把"運行直到空閑"和"單步可檢查"兩種調試需求清晰分開。

七、JIT工具：AI自己生成工具，但只能在沙箱里

Agent libOS支持一條非常有趣的"即時工具生成"（JIT tool）路徑，允許進程提議一個TypeScript工具候選項，包含接口定義、源代碼和測試。通過驗證的候選項會作為Deno模塊運行，導出一個run(args, libos)函數。

選擇Deno來運行這些即時生成的工具是經過認真考量的：Deno原生支持TypeScript，同時提供了一個"默認拒絕"的權限模型——不信任的模塊在沒有明確授權的情況下，無法訪問磁盤、網絡、環境變量、子進程或FFI（外部函數接口）。啟動時使用--no-prompt參數，防止運行時通過交互式提示獲得權限提升。

libos對象只暴露一個syscall(name, args)接口，不暴露Python運行時對象，也不暴露AI模型的工具注冊表。Python運行時和Deno進程之間通過stdin/stdout上的NDJSON協議通信。Deno以--no-prompt啟動，沒有宿主讀寫、網絡、環境變量、運行子進程或FFI的權限。靜態導入被限制在一個配置好的jsr:允許名單內，而npm:、node:、http(s):、file:、動態import、Deno全局對象、eval、Function、Worker和WebAssembly入口點在驗證階段就被拒絕。

即時生成的工具調用的每一個系統調用，都經過調用進程的原語能力檢查、策略狀態、人類審批規則和審計鉤子。TypeScript端只能看到最終的成功載荷或最終的系統調用錯誤。人類審批在系統調用內部是可等待的運行時行為，即時工具完全不接觸待處理請求協議、重試令牌或直接的授權/撤銷操作。進程退出和替換執行這類生命周期系統調用，其結果由運行時在Deno工具返回正常結果幀后才應用，超時、協議違規和異常退出都會被報告為失敗的工具調用。

八、檢查點與審計：讓每一步操作都"有據可查"

當AI智能體執行了一些無法撤銷的操作（比如發送了一封郵件、寫入了某個文件），如果后來出了問題，你需要能夠回溯："它當時做了什么？憑什么權限做的？是誰批準的？"這就是審計記錄存在的意義。

Agent libOS的檢查點會快照可重建的運行時狀態：進程元數據、對象目錄狀態、能力元數據和檢查點頭部。需要明確說明的是，檢查點不聲稱能回滾不可逆的外部操作，因為那些操作已經實際發生在了真實世界里。這類操作必須被表示為審計事件，在必要時通過明確的補償操作來處理。

審計記錄在所有會改變權限和產生副作用的邊界處發出，每條記錄能夠回答：哪個進程執行了操作、調用了哪個原語、影響了哪個資源、哪個權限或策略允許或拒絕了該操作，以及涉及了哪個人類決策。

九、原型實現與驗證：123個測試用例說話

這套系統的Python原型包名為agent_libos，包含以下模塊：能力管理（能力的授予、撤銷、檢查、對象句柄）、配置（默認預算、限制、沙箱、命令行和啟動策略）、外部接口（文件系統、命令行、時鐘/睡眠和提供者基底）、人類接口（審批、提問、輸出、中斷隊列）、鏡像管理（內置鏡像、注冊表原語、YAML加載器）、LLM接口（提示、模型客戶端、執行器、工具協議）、內存管理（對象內存、命名空間、句柄、視圖、物化）、運行時（調度器、進程管理器、系統調用、事件、審計）、存儲（SQLite元數據存儲）以及工具管理（工具代理、工具基類、Deno即時工具、內置工具）。

研究團隊設計了一個確定性演示場景，無需真實的AI模型即可運行：系統生成一個編程智能體進程，創建一個合成的測試失敗日志，分叉一個工作進程，使用解析工具，創建檢查點，嘗試一個因缺少權限而被拒絕的文件寫入操作，路由一個人類審批請求，在審批通過后寫入一個補丁預覽文件，創建最終報告對象，退出，并返回JSON摘要。整個演示場景被一個契約測試覆蓋。

此外還有多個煙霧測試腳本，覆蓋有權限的模型寫入、帶權限請求的摘要生成、通過命名對象內存的文件復制（不讓內容返回到工具結果里），以及兩個進程的異步睡眠交替執行。命令行界面提供了可復現的入口點，包括進程本地cd、YAML鏡像exec、顯式退出，以及一個可以掛載任意工作區的編程智能體啟動器——后者通過LocalResourceProviderSubstrate實現，不會改變宿主Python進程的工作目錄。啟動器預設提供了粗粒度的工作區權限（只讀、編輯、完全），以及從無命令行訪問到明確的高風險始終允許模式的命令行策略預設。

在驗證層面，研究團隊將整套系統的安全和執行屬性編碼為123個回歸測試用例，覆蓋了以下關鍵屬性：工具可見性不等于資源權限（可見的寫文件工具在沒有寫能力時被拒絕）；工作區包含（試圖逃出工作區根目錄的路徑被文件系統原語拒絕）；分叉/生成時的權限縮減（分叉子進程不繼承父進程文件寫權限，生成子進程從全新命名空間和僅目標內存視圖開始）；命名空間隔離（不同進程命名空間里相同的本地對象名獨立解析）；內存清理（進程退出釋放擁有的草稿對象同時保留顯式結果）；按次審批（ask_each_time在原語內部阻塞，授予一次，消耗授權，下次再詢問）；人類和等待恢復（人類審批和子進程等待恢復待處理運行時動作，而不是返回錯誤的工具失敗）；異步睡眠（兩個進程在合作睡眠時交替輸出時鐘信息）；Deno即時系統調用隔離（TypeScript工具可以調用libos.syscall但無法繞過原語能力或人類審批）；鏡像注冊權限（YAML加載和鏡像注冊需要文件系統和鏡像注冊表能力）；資源提供者基底可注入性（文件系統、時鐘/睡眠和命令行提供者可以注入而不改變工具接口）；以及包裝器純凈性（內置LLM工具不直接調用宿主邊界API）。全部123項測試均通過。

十、局限性與未來方向

研究者對這套系統的局限性非常坦誠。Deno/TypeScript即時工具路徑避免了默認的宿主文件系統、網絡、環境變量、子進程和FFI權限，但它不是一個正式的生產沙箱，更強的部署場景可能仍然需要Docker、WASM或Firecracker風格的微虛擬機。策略引擎有意保持簡單，能力約束、人類權限策略、命令行策略列表和鏡像/命名空間權限覆蓋了原型需求，而更豐富的策略語言、風險評分、配額、基于角色的人類權限和敏感標簽則留待未來工作。檢查點無法回滾外部操作。上下文管理還比較初步，工具結果壓縮、長文檔分頁、重復動作抑制和檢索策略尚未完全開發。審計日志目前只是一個記錄流，未來需要提供按進程、能力、原語、資源、人類請求和時間范圍的索引查詢。

未來工作還應形式化工具表、系統調用、能力、策略和分叉/替換執行之間的關系；把人類當作慢速的高權限設備來深入研究；通過更強的靜態分析、資源計量、權限配置加固、簽名注冊表和來源感知撤銷來強化即時工具；以及構建運行時基準，覆蓋拒絕正確性、未授權副作用、審計完整性、調度公平性、上下文增長和內存釋放正確性。在資源提供者層面，網絡、瀏覽器、數據庫、遠程執行、容器執行、WASM提供者、服務支撐文件系統、提供者級資源計量和跨提供者審計關聯也是未來需要拓展的方向。

研究者同樣明確說明了這套系統在安全性上的邊界：Agent libOS不聲稱能解決語義層面的提示注入問題——一個惡意文檔仍然可能欺騙AI模型去請求危險操作。系統的主張是：即便是這樣的請求，也仍然要經過原語級別的能力檢查、策略、人類審批（如果需要的話）和審計。系統同樣不聲稱內核級隔離、分布式調度、已驗證的訪問控制，或事務性回滾。

說到底，這項研究解決的是一個很樸素的問題：AI智能體越來越強大，但現在的大多數框架沒有給它們套上足夠可靠的"韁繩"。Agent libOS的貢獻不是讓AI更聰明，而是讓AI在系統層面更可信——它的每一個操作都有可查的來源，每一次越界都會被攔截，每一個需要人類確認的動作都會真正等待人類來確認，而不是自作主張。這套系統還是一個研究原型，距離真正的生產部署還有相當的距離，但它提供了一種嚴肅的思路：與其在AI模型的"大腦"里做文章，不如在AI智能體的"操作系統"層面建立真正的權限邊界。對于正在思考如何讓AI智能體在真實環境里更安全運行的工程師和研究者來說，這套設計值得認真參考。

Q&A

Q1：Agent libOS和普通的AI智能體框架（比如AutoGen、LangGraph）有什么本質區別？

A：普通AI智能體框架的工具可見性和資源權限往往是綁定在一起的，AI能"看到"某個工具基本等于能直接執行它。Agent libOS把這兩件事嚴格分開：工具只是接口，真正的權限檢查發生在底層原語層。這意味著即使AI模型被欺騙去調用危險工具，底層系統仍會按照能力和策略攔截，而不是直接放行。

Q2：Agent libOS能防止提示注入攻擊嗎？

A：不能完全防止。如果惡意內容欺騙了AI模型，讓它主動請求危險操作，Agent libOS無法阻止這個"誤判"的發生。但它能保證的是：這個被欺騙后的請求，在真正執行時仍然要通過能力檢查、策略審核、必要時的人類審批，以及完整的審計記錄。攻擊者欺騙了AI的判斷，但無法繞過系統的執行邊界。

Q3：Agent libOS的即時工具生成（JIT工具）是怎么保證安全的？

A：即時生成的TypeScript工具在Deno沙箱里運行，默認沒有磁盤讀寫、網絡、環境變量、子進程或FFI權限。工具只能通過一個叫libos.syscall的接口與運行時通信，而每一次系統調用都會經過調用進程的能力檢查和策略審核，無法繞過。同時，工具的import來源被限制在允許名單內，eval、動態import等危險入口點在驗證階段就被拒絕。