这项由清华大学计算机科学与技术系主导的研究，以预印本形式发布于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等危险入口点在验证阶段就被拒绝。