迈向代理操作系统——从经典操作系统和云操作系统中汲取的经验教训

# 迈向智能体操作系统  
来源：https://arxiv.org/html/2607.25076  

## 迈向智能体操作系统——来自经典操作系统与云操作系统的经验教训  

###### 摘要  

每一次平台软件的重大浪潮都遵循相同的轨迹：先是框架和临时性实现相互竞争的实验阶段，随后提炼出一小组语义定义清晰的稳定抽象，最后这些抽象整合成一个平台，应用程序可以可移植地部署其上。POSIX 为经典操作系统实现了这一点；Kubernetes 为云平台做到了。智能体 AI 系统——即由大语言模型驱动、能够规划、使用工具、保持记忆并协作的自主智能体——正处于第三次浪潮的实验阶段。虽然已有数十种框架和协议涌现，但社区尚未就核心抽象是什么、它们提供哪些保证达成共识。没有这种共识，智能体应用就无法可移植地编写，平台无法可靠地组合，整个领域也无法超越原型部署。我们认为，前进的道路是遵循前一波浪潮的方法论：将经典操作系统和云操作系统的原语扩展到随机性、自然语言中介的执行过程，从中推导出新的智能体抽象，精确指定其语义，并围绕它们进行整合——正如 POSIX 和 Kubernetes 分别在其所属浪潮中所做的那样。  

## I. 引言  

计算的历史可以被视为一系列平台转型，每一次都由软件构建和部署方式的根本性转变驱动。从最早的批处理大型机时代，到个人计算机与网络服务器时代，再到今天的分布式云时代，以及现在自主 AI 智能体的兴起，每个时代都带来了新的应用类别、新的工程挑战，最终都需要发明、完善并标准化一个新的操作环境，该时代才能充分发挥其潜力。回顾过去，可以说有两个主要浪潮塑造了计算实践。我们称之为经典服务器时代和云时代。每个时代都有其自己的编程模型、特有的故障模式以及自己的工具链。而这两个时代，在经过初期零散实验阶段后，最终都产生了规范化的平台——该时代的操作系统——为开发者提供了稳定、可移植的抽象来构建应用。我们现在正在进入第三个时代，即智能体时代，由 AI 的兴起驱动，我们认为这将导致一个新的规范化平台的创建。本文将这些平台分别称为 OS（经典服务器时代的平台）、Cloud-OS（云时代的平台）以及 Agent-OS（智能体时代所需但尚不存在的平台）。  

经典服务器时代（1950 年代至 1980 年代）的特征是程序竞争单台机器的 CPU、内存和 I/O 资源。核心挑战是安全、高效的多路复用：如何让运行在同一台机器上的多个程序拥有私有资源的假象，防止它们相互破坏，并且做到高效？OS 作为答案出现了。它阐述了一套小而稳定的抽象词汇，具有形式化指定的语义：进程（一个隔离的地址空间，带有安全主体和确定性行为函数）、虚拟内存（私有、统一可寻址空间的假象；驱逐由时间局部性控制）、系统调用（用户/内核边界的唯一合法跨越；二进制接口，完全指定的副作用）以及文件（持久、命名的存储，具有 POSIX 访问控制和日志化原子性）。这些语义是通过十年的操作系统研究获得的，并通过操作灾难锤炼而成。POSIX 将它们标准化，使程序能够在不同供应商的实现之间可移植，支撑了三十年无需替代的应用程序开发。  

云时代（1990 年代至 2010 年代）带来了一套不同的问题。应用分解为微服务；基础设施变成分布式、弹性且易故障；多租户要求在集群级别而非进程级别进行隔离。没有单一机器能承载一个应用；部署单元变成了一组副本，相关故障模式从段错误和死锁转向网络分区、Pod 驱逐和级联服务故障。Cloud-OS——Kubernetes、服务网格和云编排器——作为这些新问题的答案出现了。它阐述了一套明确建立在 OS 语义之上的新词汇：Pod（共享网络命名空间的协同调度容器；分布式基础设施中的进程组类比）、Service（临时 Pod 之上的稳定虚拟 IP；微服务的系统调用分发器类比）、健康检查和就绪探测（OS 信号/异常机制泛化为基础设施级故障检测）以及命名空间和网络策略（MMU 隔离模型泛化为多租户集群）。至关重要的一点是，Cloud-OS 扩展了 OS 而非取代它：Kubernetes Pod 运行在 Linux 命名空间内；RBAC 扩展了 POSIX 权限模型；服务网格的 mTLS 扩展了内核级认证。Kubernetes 成为了云时代的标准化里程碑，就像 POSIX 之于经典服务器时代那样。  

现在，智能体时代正在开始。AI 智能体——使用大语言模型来自动化流程的系统——正在从研究原型走向企业生产部署。它们代表了一类新的应用，特点是结果随机性增加、预期自主性提升以及以推理令牌形式出现的新资源需求。伴随这些特性而来的是新的工程挑战：如何实现可靠性、弹性、安全性和效率。如今，智能体工程正处于实验阶段，让人联想到前 POSIX 的 Unix 时代和前 Kubernetes 的云时代：已有数十种框架和协议出现，但尚不存在开发者可以构建、平台可以实现的稳定、可移植的抽象层。当今成功的智能体系统依赖于通常称为 harness 的定制代码层，这些层利用现有操作系统技术并针对 AI 领域进行了增强。尽管 harness 是领域和模型特定的，但从中可以观察到一些模式，我们可以从中推导出潜在的通用原语。我们认为，智能体系统的大规模采用将需要我们的领域阐述并标准化一个新的操作环境：Agent-OS。正如 OS 和 Cloud-OS 各自用了十年时间才得以阐述和标准化，Agent-OS 也需要相当长的时间才能成熟。本文进一步认为，前进的道路是遵循前几个时代所用的相同方法论——通过扩展经过验证的原语来推导新的抽象，精确指定其语义，并围绕它们进行合并——并提出了十三个我们认为构成 Agent-OS 核心的原语。  

近期一些系统已经涉及为智能体工作负载构建操作系统的概念，并构建了特定功能的原型：智能体内核 [37 (https://arxiv.org/html/2607.25076#bib.bib58)]、内存管理器 [42 (https://arxiv.org/html/2607.25076#bib.bib24)] 或资源管理器 [49 (https://arxiv.org/html/2607.25076#bib.bib44)]。这些是实现方面的贡献——它们原型化了 Agent-OS 组件的行为。本文做出了不同类型的贡献：它追问 Agent-OS 必须保证什么，并通过使用系统的语义鸿沟方法论，从第一性原理推导出答案。具体来说，本文：(1) 从历史视角动机化 Agent-OS（第二节 (https://arxiv.org/html/2607.25076#S2)）；(2) 精确刻画了 OS 和 Cloud-OS 语义在哪些方面以及为何对于随机性、自然语言中介、外部行动的智能体而言会失效（第三节 (https://arxiv.org/html/2607.25076#S3)）；(3) 提出了十二个 Agent-OS 原语，每一个都源自经过验证的 OS 和 Cloud-OS 抽象，通过追问三个问题：原抽象提供了什么保证，该保证对智能体是否成立，以及必须做什么改变（第四节 (https://arxiv.org/html/2607.25076#S4)）；(4) 识别了构成标准化议程的开放规范问题（第四节 (https://arxiv.org/html/2607.25076#S4)）；(5) 描述了 rossoctl 及其他开源项目的原型，实现了一部分 Agent-OS 原语，展示了这些原语可以在现有 Cloud-OS 基础上实现，而不需要替换（第五节 (https://arxiv.org/html/2607.25076#S5)）。Karpathy 的 LLM-OS 框架 [29 (https://arxiv.org/html/2607.25076#bib.bib54)] 和 AIOS [36 (https://arxiv.org/html/2607.25076#bib.bib53)] 确立了 OS 类比的有效性。本文的贡献是下一步：类比所要求的规范工作——足够精确地定义语义，以便平台能够强制执行它们，而应用程序能够可移植地依赖它们。贯穿这一切的还有企业级必要需求：Agent-OS 必须支持多环境运行——本地部署、私有云和混合云——将 OS 和 Cloud-OS 在其各自时代带来的可移植性保证扩展到智能体时代。第六节 (https://arxiv.org/html/2607.25076#S6) 讨论推导方法论。第七节 (https://arxiv.org/html/2607.25076#S7) 陈述研究议程。第八节 (https://arxiv.org/html/2607.25076#S8) 总结。  

## II. 智能体时代及其操作环境  

要理解为什么智能体时代需要一个新的操作环境，回顾执行单元的性质在三个时代的变化是很有帮助的。在经典服务器时代，单元是程序：一个确定性的指令序列，具有定义良好的输入和输出，可以完全从二进制中分析。在云时代，单元变成了服务：一个网络可访问的程序，在隔离状态下仍然是确定性的，但现在已经嵌入到动态集群中，其中故障、扩展和协调成为一等关注点。在智能体时代，单元是智能体：一个自主系统，使用大语言模型作为其推理引擎，感知环境，规划行动方案，调用外部工具，并且反复迭代——而无需程序员预先指定每一步。从服务到智能体的转变不仅仅是应用架构的变化，而是执行单元基本属性的改变。程序和服务的确定性不同，智能体是随机性的：相同的输入会产生行为分布，而不是固定输出。程序只对其自身内存操作，服务只对其自身状态操作，而智能体则对外部世界采取行动——调用 API、写入数据库、发送消息——这些行动往往具有不可逆的后果。服务通过精心编排和验证的路径进行 API 和消息交互，而智能体边走边设计自己的交互模式，使得预先验证变得不可能。此外，程序和服务忠实地报告其状态，而足够能力的智能体在压力下可能会表现出战略性行为：伪造成功、压制失败证据，或采取隐蔽行动以避免任务放弃 [38 (https://arxiv.org/html/2607.25076#bib.bib5),46 (https://arxiv.org/html/2607.25076#bib.bib32)]。这些属性中的每一个都打破了 OS 和 Cloud-OS 所依赖的假设，每一个都需要新的平台保证。  

#### II-1 Agent-OS 是什么  

从操作系统的角度来看，智能体是以循环形式实现的程序，在每次迭代中，模型决定下一步要采取的一组步骤。已经证明，模型不能依赖其识别和修复自身错误 [20 (https://arxiv.org/html/2607.25076#bib.bib57),11 (https://arxiv.org/html/2607.25076#bib.bib7)]。这些错误无论是对外部系统的影响还是资源消耗都可能是昂贵的。因此，弹性、安全和成本的保证不能仅由智能体自己实现——这是 Agent-OS 的责任 [11 (https://arxiv.org/html/2607.25076#bib.bib7),62 (https://arxiv.org/html/2607.25076#bib.bib56),49 (https://arxiv.org/html/2607.25076#bib.bib44)]。但孤立运行的单个智能体只是整体图景的一部分。现代部署组合了多个智能体：一个研究智能体收集信息，一个规划智能体分解目标，专用智能体执行单个任务，一个验证智能体检查输出，以及一个报告智能体沟通结果。Agent-OS 是协调这些组件的层——在智能体之间路由任务，强制执行谁可以调用什么，维护共享内存，跟踪已完成和出错的工作，并确保整个系统保持可审计且处于人类监督之下 [8 (https://arxiv.org/html/2607.25076#bib.bib6),31 (https://arxiv.org/html/2607.25076#bib.bib19),26 (https://arxiv.org/html/2607.25076#bib.bib55)]。  

因此，Agent-OS 不是 AI 模型，不是框架库，也不是一组 API 约定。它是基础设施：智能体应用之下的平台层，强制执行这些应用所依赖的保证，正如 OS 在用户进程之下强制执行内存隔离，Cloud-OS 在微服务之下强制执行 Pod 隔离和健康恢复一样。正如 OS 和 Cloud-OS 都不仅仅是实用库的集合——两者都施加架构、强制执行策略，并提供应用代码自身无法提供的保证——Agent-OS 也必须为智能体做同样的事情。  

#### II-2 智能体系统的结构  

图 1 (https://arxiv.org/html/2607.25076#S2.F1) 展示了自主智能体范式 [58 (https://arxiv.org/html/2607.25076#bib.bib35)]：单个基于 LLM 的智能体的典型架构。模型位于中心，作为策略核心——负责在可用上下文中推理、选择行动并生成响应的组件。四个子系统围绕它：  

- • 记忆（状态）——短期上下文窗口（保存当前对话、工具调用历史和检索到的文档的有限缓冲区）和长期存储（向量数据库、键值存储、在调用时通过检索访问的结构化数据库）。  
- • 规划（推理）——智能体将目标分解为步骤序列、根据中间结果修改计划并在每一步决定调用哪些工具的能力。这是 LLM 的一种涌现能力，在推理时以概率方式执行。  
- • 动作（工具）——智能体影响外部世界的手段：REST API 调用、CLI 命令、数据库查询、代码执行以及消息发送给其他智能体。每个动作可能具有真实世界且不可逆的后果。  
- • 感知（输入）——对环境状态的摄取：用户消息、工具结果、检索到的记忆、传感器数据以及来自对等智能体的输出，所有这些都竞争有限的上下文预算。  

参见图注  
图 1：自主智能体范式 [58 (https://arxiv.org/html/2607.25076#bib.bib35)]，以及实际的构建-部署-评估生命周期。图来自 arXiv:2601.01743，采用 CC BY 4.0 许可。  

智能体执行循环将这些组件连接成一个可识别的生命周期，该生命周期一直运行直到任务完成、资源限制耗尽或平台干预。该循环的一个关键属性是其长度、令牌成本和执行轨迹无法提前预知——它们取决于 LLM 在每一步的概率推理。在多智能体系统中，这个生命周期是 n