Agent 最需要的不是 sandbox，是一台自己的计算机

现在不少公司在给 agent 提供「计算」。有的做隔离 sandbox，有的做轻量虚拟机，有的直接做出一台面向用户的数字员工，连 Cloudflare 也开始说 agent 需要的是 computer，不是 container。方向都对：agent 已经不只是聊天框里的一问一答，它要写代码、跑工具、改文件、连外部系统，有时还要跑很久。

但我觉得这里有一个被默认带过去的假设：给 agent 更好的盒子，就等于给了它计算环境。

我们的判断是反过来的。Agent 真正需要的，不是更快启动的 sandbox，也不是更像 Linux 的虚拟机，而是一台为 agent 重新设计的计算机：它能长期存在，有自己的身份和状态，权限可以被约束，行动历史可以核验，整机还能带走。

市场在造盒子

过去一年，agent 相关的计算产品进步很快。隔离 sandbox 用轻量虚拟机跑不可信代码；一类产品把暂停恢复、快照分叉做成常见能力；另一些把轻量虚拟机当长期 worker；Perplexity Computer 则直接站到最终用户面前，说自己是通用数字员工。

更近的一档信号来自 Cloudflare。他们发布 early preview 的 @cloudflare/computer，标题几乎就是同一句话：agent 需要 computer，不是 container。做法也清楚：在 isolate 和完整 Linux 容器之间按任务调度，再给一份跨后端共享的 durable filesystem，文件读写和 shell 操作可以 gated、audited、observed。这比「每个 agent 永远独占一个容器」更现实，也说明大厂已经承认：只给容器不够。

它们各自解决了真问题：隔离、启动、暂停、并发、浏览器或终端访问，以及「什么时候该用轻执行、什么时候才该起完整 Linux」。短期代码执行、评测、预览、一次性研究任务，sandbox 仍然是很合适的工具。你不需要为了一段 AI 生成的 Python 去重新发明计算机。

问题出在顶层对象。

大多数产品的顶层对象仍然是 sandbox、machine、session、container、workspace 或 task。你创建实例，注入凭据，跑完，销毁或暂停。根身份来自平台账号，密钥和审计日志也主要在平台后台里。状态可以快照，共享文件系统也可以很强，但它们通常还是某个云账户下的对象，不是一份你能整体带走、换运营商后身份仍然连续的机器。

Cloudflare 把词从 container 换成 computer，是有意义的进步。可它主要优化的仍是执行怎么选、文件系统怎么共享：isolate 负责轻活，容器负责重活，workspace 挂在 Durable Object 上。这解决「全球算力不够给每个 agent 永远挂一整台 Linux」的问题。它还不自动回答另一层问题：这台计算机的根身份、迁出权和可核验历史，是否属于你，而不是属于当前平台。

你可能会觉得：这不就是基础设施该有的样子吗？对无状态函数和短期任务，是的。可 agent 已经不是函数了。

想一个具体场景。你有一个 agent，连续几个月帮你管代码仓库、邮件、日程和知识库。它要读私有材料，偶尔替你发信、开 PR、改配置。某天你想换一家云，或者只是想搞清楚：上周那封发出去的邮件，到底是谁授权的、用了哪份材料、花了多少资源。

这时真正要回答的，不是「这次启动要多少毫秒」，而是：

这次行动代表谁？它为什么有这个权限？权限是不是从另一个 agent 衰减下来的？用了哪个模型、哪段代码、哪份输入？数据有没有离开你真正控制的边界？结果能不能被核验？换一家云，身份和历史还在不在？

单独的虚拟机回答不了这些问题。把答案拆到云账号权限、数据库、日志、密钥管理和应用代码里，又会留下很难审计的缝。Sandbox 解决了「不可信代码在哪里跑」；它还没有解决「一个长期自主行动者如何安全地拥有数据、权限、历史和可验证身份」。

反过来设计一台机器

我们做的东西叫 ARC：Agentic Realm Computer。名字里的 realm 不是装饰，是在强调：这台机器首先是可主权持有的，不是平台租给你的房间。

一句话：不要把 agent 塞进一台为人类应用和租户模型设计的旧电脑；把计算机重新定义为能承载 agent 身份、状态、权限和可验证历史的主权容器。

这台机器在我们这里有三层，顺序是刻意的。

最底下是 AFS（Agentic File System）。你可以把它理解成 agent 的统一工作面：数据库、API、本地文件、工具、记忆，都变成同一套路径里可以挂载和读写的东西。人和 agent 都是一等公民。我们已经写过 Small World：每个 agent 看到的不是全局世界，而是专门为它投影出来的小世界；墙外的东西不是「没权限」，是根本不存在。也写过 Context 不是 cognition：把材料组织清楚，不等于系统会自己思考。AFS 先解决 context 怎么成为系统问题，不假装 cognition 已经被解决。

中间是 AOS（Agentic Operating System）。这一层要解决的是执行、调度、权限约束、网络策略和生命周期——是目标设计，不是声称今天每一项都已完备。agent 的行为是概率性的，安全边界必须是确定性的。不能指望模型「自觉遵守」。权限也不该靠环境变量里塞一把长期有效的密钥，而应该像一张可衰减、可收回、带预算和用途的授权条：子 agent 只能拿到更少的权力，不能越拿越多。

最上面，这台计算机才以 ARC 的完整形态出现在人和 agent 面前：有身份、有工作空间、有迁移和治理。AFS 和 AOS 是它的内脏；ARC 是你真正「拥有一台机器」时面对的那一层。产品页上更落地的说法是：应用描述它自己要做什么，ARC 负责跑起来，AFS 表达它要接触的资源。三层分开，改的时候才知道该动哪一层。

顺序是刻意的：AFS 在下，AOS 居中，ARC 面向人与 agent。正文对 AOS 的表述是目标设计，不是声称今日完备。

我们做去中心化身份（DID）、可验证凭证和用户数据归属，做了很多年。self-sovereign 对我们不是口号，是从第一性原理推出来的结果：如果根密钥、审计历史和迁出权天然属于运营商，那你所谓的 agent 计算机，本质上还是别人机器上的租户。主权不等于必须把机器放在自己家里，也不等于拒绝云。更准确的定义是：无论跑在本地、托管服务器、公共云还是第三方 sandbox 上，所有者都能控制根身份和数据密钥，限制代理权限，导出全部状态，并在不改上层身份语义的前提下换运营商。

所以 sandbox 和轻量虚拟机在我们这里不是敌人，是可插拔的执行材料。高风险任务可以进更强的隔离环境，低风险任务可以更轻；但顶层对象始终是 agent 与工作空间，而不是某一家云的实例 ID。

我们现在能诚实说什么

写到这里必须把边界画清楚，不然判断会变成承诺。

已经能当真的部分，是方向和底座。AFS 不是 PPT 里的抽象：统一路径、小世界投影、把数据库和工具挂进同一工作面，这些已经写进实现，也能在我们站上读到具体文章。ARC 作为跑应用的运行环境，也是真实产品路径，不是换皮营销词。我们坚持把身份放在平台账号之前，把真正重要的状态和可以丢掉重建的运行时分开：实例可以重建，用户真正重要的数据和凭证不应跟着某次部署一起消失。

还不能写成「今天已经完备」的部分，也要说出来。完整的操作系统层能力模型、跨运营商无损迁移、对每次 agent 行动都可核验的来源记录、以及只有执行环境被证明可信后才打开敏感工作区，这些属于我们认定正确的架构方向，不等于每一项都已经以对外产品的形态交到你手里。设计完成但还没跑通的东西，写成现状是谎言；写成方向，才是诚实。

你可能会问：那短期我干嘛不直接用现成的 sandbox？很多时候就该用。如果你的任务是跑一段生成代码、做一次评测、起一个临时环境，现成的 sandbox 足够好，也更省事。ARC 真正开始拉开差距的地方，是 agent 要长期存在、跨工具行动、代表你产生外部影响，并且你在意身份、权限链和迁出权是否属于你。那是架构判断，不是一张已经打满的功能清单。

这也解释了我们为什么不愿把定位写成「启动更快、隔离更重的 sandbox」。比启动延迟，永远会有人比你快一截；比功能清单，明年又会有新的轻量虚拟机产品。更站得住的差异是：持久状态、用户主权、可约束的授权、可核验的执行，被合成同一台机器的语义，而不是散落在一堆平台对象里。

市场还会继续造更好的盒子。这件事本身没问题。Sandbox 会一直有用。

但标题里那句话，重音不在「计算机」三个字，而在「自己的」。

你可以给 agent 一台启动很快、文件系统很完整、还能在 isolate 和容器之间聪明调度的机器。如果根身份来自平台账号，密钥和历史走不开当前运营商，换云等于换人设——那它仍然是租来的房间。名字改成 computer，租户还是租户。

Agent 最需要的不是 sandbox，也不是把 sandbox 重新包装成 computer。它需要一台属于所有者、能带走、能核验、换执行后端之后仍是同一台机器的计算机。少了「自己的」，前面那些能力都只是更好的盒子。

我们把这件事叫 ARC。盒子可以一年换三代；机器语义不能漂。漂了，agent 就没有「自己」。