# VM 平台层驱动 Mobile Agent:Instinct 与 Claude Code 隔离沙箱实测,以及企业 Agent 落地的虚拟化边界 过去这一个月,围绕"AI 智能体(Agent)从本地搬到云端、从电脑搬到手机"这个方向,工程社区里出现了两个值得仔细看的真实案例:一个是 Anthropic 自营的 Claude Code 在云端 VM 里跑的样子,另一个是新创公司 Instinct

# VM 平台层驱动 Mobile Agent:Instinct 与 Claude Code 隔离沙箱实测,以及企业 Agent 落地的虚拟化边界 过去这一个月,围绕"AI 智能体(Agent)从本地搬到云端、从电脑搬到手机"这个方向,工程社区里出现了两个值得仔细看的真实案例:一个是 Anthropic 自营的 Claude Code 在云端 VM 里跑的样子,另一个是新创公司 Instinct 把"记忆 + 工具调用 + 浏览器"整套活儿外包给 Firecracker microVM 的方式。前者由独立开发者 Rohan Adwankar 在 2026 年 9 月初的博客《The box an agent runs in》里做了一次深度的拆机式实测,后者则已经在 Hacker News 上引发了围绕"自营 fleet 还是租用第三方 sandbox"的多轮工程讨论。这篇文章把两份一手素材合并改写,目的不是复述具体命令行的每个输出,而是想回答一个更工程化的问题:一家企业如果真的要把 Agent 落到自己的业务流程里,平台层应该选哪条虚拟化的路,以及哪些边界是不能省的。 ## 一、问题的起源:Agent 为什么需要 VM 把 Agent 放到云端 VM 里跑,这件事最初的动机不是为了炫技。Agent 跟传统的 SaaS 后端不一样,它要在用户的真实环境里执行命令、读写文件、调用第三方服务,甚至在某些场景下代表用户去操作一个浏览器。一旦 Agent 拥有这种"代理执行"的权限,Prompt 注入、工具调用的边界失控、误删生产数据这几类风险的破坏力都会被放大。早期大家在本地直接跑 Agent,本质上是用"物理机不隔离"的代价换"开发方便";一旦 Agent 走向手机端、走向多用户共用,本地这条路就走不通了。 Rohan 的博客一开头就点出了这个转变的工程含义:Agent 离开本地电脑这件事,看起来只是"你能在手机上和它说话",实际上背后是平台公司必须为每个用户、每个会话提供一个隔离的执行环境。这件事如果做不好,轻则互相串数据,重则一个用户的 Prompt 把另一个用户的文件系统删掉。所以 VM 平台层的隔离,不是"加分项",而是底线。 ## 二、Claude Code 的隔离实现:自营 Firecracker + 内部 PID 1 Claude Code 的方案是 Anthropic 自己运营一个 Firecracker microVM 集群。Firecracker 是 AWS 在 2018 年开源的极简 hypervisor,特点是把虚拟机的启动时间压到几百毫秒级,把设备模型砍到只剩最必要的几样(virtio-net、virtio-block、console),从而可以在普通 Linux 主机上同时跑几千个 microVM。Claude Code 选它,核心是要"快开快关":用户发条消息,VM 启动;会话空闲,VM 回收;下次再来,VM 重新拉起。 具体到 VM 内部,Rohan 的拆机报告显示了几个值得记住的工程细节。第一,VM 里的 PID 1 不是 systemd,而是 Anthropic 自己用 Rust 写的一个叫 `process_api` 的二进制,这是这台 VM 的"控制平面"。它做几件事:挂载磁盘、监听 vsock 端口 2024 等宿主机下达命令、对外屏蔽掉 `/proc/1/mem` 这种敏感路径、并且把自己配置成不可被 dump(non-dumpable)。这一套组合拳的结果是:即便 Agent 在 VM 内部有 root,也无法把这台 VM 的控制平面进程搞崩或者把它的内存读出来。 第二,磁盘是分层挂载的。`/opt/claude-code` 这类系统目录是只读的 324 MB Bun 编译产物,跑 Agent 自己的 harness;`/mnt/skills/` 同样只读,放技能文件;只有 `vda` 这一块 256 GB 的 virtio-block 是属于用户会话的可写盘,持久化存在。这意味着模型、推理、第三方 API 的 token 跟用户的代码和工作目录在物理上就是分开的——即便 Agent 写文件写疯了,也只能写到自己的那块盘里。 第三,模型推理走的是 SSE over HTTPS/2,通过一个 443-only 的 egress gateway 出网。`/etc/hosts` 里 `api.anthropic.com` 被 pin 死,根本没有别的 DNS 解析路径。鉴权用 host-minted 的 OAuth token,根用户独占,每次重启轮换。这是一种典型的"模型跑在外面、计算留在里面"的拆分:Agent 不能主动去联外网抓任意东西,只能调用授权范围内的 `/v1/messages`,而且每次会话重启 token 就失效。 第四,生命周期是宿主机决定的。从冷启动到 init 完成大约 430 毫秒,到 harness 可以响应大约 6.4 秒,触发条件是收到第一条入站消息。空闲时的回收策略也是宿主机决定,而不是 VM 自己决定。回收后进程死了,但 `vda` 那块盘会解绑并在下次会话重新挂回去,所以用户感觉"对话是连续的",实际上计算是被销毁过的。 这一套设计带来的工程效果是:VM 内部出了任何问题,影响都被限制在单个会话、单块磁盘里;Agent 想越权写系统目录,写不动;Agent 想抓别的用户的 token,根本看不到。这对一家企业来说意味着:如果 Agent 真的出了一个事故,事故半径是"那一次会话",不是"整个生产系统"。 ## 三、Instinct 的隔离实现:租 E2B、记忆放 S3、模型在盒子外面 Instinct 走的则是完全不一样的路线。它自己既不运营 KVM 集群,也不写自己的 hypervisor,而是把执行环境完全外包给 E2B——一家做"沙箱即服务"的厂商,租给用户一个跑 Ubuntu 的 Firecracker microVM。Rohan 实测拿到的是一台 2 vCPU、1.9 GB 内存、29 GB 磁盘、寿命 30 分钟左右的 Ubuntu 22.04 sandbox,用户名是 sandbox(uid 1001)。这种"轻量短时"组合的目标是:每次任务开一台,任务结束就扔。 E2B 这一层从命令行看到的特征是典型的 Firecracker:内核命令行带 `pci=off`、`virtio_mmio.device=4K@...`、`i8042.noaux`、`clocksource=kvm-clock`、网络用 tap0;`/sys/class/dmi/id/product_name` 是空的(没有 SMBIOS 表),PID 1 是 systemd 而不是某种定制 init。从用户角度看,这是一台"完整的 Ubuntu 桌面机"——XFCE 都装了,冷启动 1.26 秒左右就到 graphical.target。但从平台角度看,它仍然是 microVM,只是把"内核 + 用户态"两套都交给租户使用,平台方不掺和。 Instinct 在这台租来的 VM 之上做了一件很有想法的事:它把 Agent 的"记忆"——也就是 Agent 跟用户对话积累的事实、人物关系、待办、决策依据——放在了 `/memory` 目录下,这个目录不是普通文件夹,而是一个 git 仓库。仓库的目录结构是:`timeline/` 按时间粗化(raw → hourly → daily → weekly,模拟人脑记忆的衰减模型)、`entities/` 放人物和项目实体、`comms/` 放聊天邮件会议等沟通记录、`workstreams/` 放进行中和已完成的工作流、`knowledge/` 放事实、流程、偏好、决策。文件全是 Markdown,实体之间用 `[[wiki-links]]` 互相引用,Agent 找东西的方式是 `grep`。 最有意思的一个工程细节是:这个 git 仓库的作者是 Agent 自己。日志里 `git -C /memory log --format='%an <%ae>' -1` 显示 `Instinct Agent `,也就是说 Agent 不是通过某个"记忆 API"去读写结构化数据,而是直接 `git commit` Markdown 文件。这是一种非常"朴素但有效"的做法:状态变更天然有版本,可以回滚,可以 diff;Agent 写错的某个事实,通过 checkout 直接恢复。 为了把这套记忆持久化,Instinct 把整个仓库作为一个 git bundle 上传到 S3,路径是 `s3://instinct-prod-agent-memory/filesystem-memory/user-/`,里面只有一个 `refs/heads/main/.bundle` 文件,看起来 S3 上几乎"是空的"——这种把整个仓库打成一个 bundle 的做法在 GitHub 备份、git-remote-s3 等场景里都用过,好处是写一次、拉一次的成本都很低,缺点是你不能像普通 S3 那样直接看到文件。 鉴权用的是短期 STS 凭据(`ASIA` 前缀 + session token),而不是长期 AccessKey。`/etc/instinct-aws-creds` 里 export 的是 role-scoped 临时凭据,role 是 `instinct-sandbox-observations-role`。这种设计有一个直接的安全收益:即便 sandbox 被攻破、凭据被泄漏,凭据也会在几分钟到几小时内自动失效,不需要人工 rotate。 更进一步看,Instinct 在 VM 内部几乎不放任何推理能力。Rohan 在 VM 里 `strings` 了所有二进制,没有发现任何 `anthropic`、`openai`、`/v1/messages`、`x-api-key` 这种字样——也就是说,这个 sandbox 根本不会从这台机器发任何模型调用。Agent 的"脑"完全在云端,VM 只是执行表面。具体来说,VM 内部跑两个二进制:`agent-exec-server`(Go 写的,负责执行后端通过 GraphQL 推过来的 bash 和代码)和 `tools`(Rust 写的 CLI,提供 50 多个 namespace 的工具调用入口,从 Gmail 到 Stripe 支付,从 Notion 到 Slack,从 vault 凭据管理到 cloud_browser)。每一条工具调用最终都通过 `tools ...` CLI 走 GraphQL 请求 `https://api.instinct.com/-/api/graphql/tool-execute`,由 Instinct 的服务端去执行真正的第三方 API 调用。 这套"模型在外面、记忆在 S3、执行在租来的 VM"的设计,等价于一种"沙箱 = 单纯执行"的边界声明:Agent 不能从 sandbox 内部去主动抓取外部 API,也不能把外部服务调用结果写进本地某个长期文件——所有的副作用都要经过 Instinct 自己控制的 GraphQL 层。这对一家要做 Agent 落地的企业来说,意义在于:你租 sandbox,你可以限制 sandbox 本身,但你不能限制 Agent 后端做了什么。所以 Instinct 这条路线本质上把信任全部放在了平台方,而不是放在 hypervisor 上。 ## 四、两条路线的对比:自营 fleet vs 租第三方 sandbox 把 Claude Code 和 Instinct 的差异列成一张表,Rohan 已经替我们做了: - **隔离原语**:两边都是 Firecracker microVM,都是 KVM guest。 - **谁运营 fleet**:Claude Code 由 Anthropic 自营,Instinct 租用 E2B 的第三方 fleet。 - **VM 内部跑什么**:Claude Code 是 stripped custom init(`process_api` 做 PID 1),Instinct 是完整 Ubuntu + systemd + XFCE 桌面。 - **冷启动时间**:Claude Code init 约 430 ms、到 harness 约 6.4 秒;Instinct 到 graphical desktop 约 1.26 秒。 - **持久层是什么**:Claude Code 是 VM 本身那块 256 GB `vda`,Instinct 是 S3 里的 git repo。 - **记忆模型**:Claude Code 是会话状态落盘,Instinct 是 Markdown vault + git 版本化 + Agent 自提交。 - **凭据**:Claude Code 是 host-minted OAuth(磁盘、每次启动轮换),Instinct 是 STS(role-scoped、临时)。 - **Harness 在哪**:Claude Code 在 VM 内部(324 MB Bun),Instinct 在 VM 外部(sandbox 只跑两个执行 shim)。 - **怎么调用模型**:Claude Code 通过 egress gateway 走 SSE 到 `/v1/messages`,Instinct 完全不在 sandbox 里调模型,所有调用都走 `api.instinct.com` 的 GraphQL 服务端。 两种方案的工程权衡非常清楚。Claude Code 的路子是把"控制平面"留在 sandbox 内部,通过 Rust init + vsock + 不可 dumpable 的 PID 1 把 hypervisor 的边界压到最紧,适合"我要完全控制我的执行环境"的企业。Instinct 的路子是把 sandbox 当作一次性的执行表面,把"记忆"和"工具调用"都外包给平台方,适合"我要快速上线、不想自己运维 KVM fleet"的团队。 ## 五、工程社区的真实分歧:Hacker News 上的几条争议 围绕这两条路线,Hacker News 的讨论里出现了几条值得记住的争议。 第一条争议是"自营 vs 第三方 sandbox"的商业可持续性。E2B 的 CEO 直接下场说明 Amp 的 Orbs 也跑在 E2B 上,E2B 是 Apache 2.0 开源的,跑在 GCP、AWS、Azure(预览)上,本地只要有 `/dev/kvm` 也能跑。但反过来,有用户提了一个尖锐的问题:Jason Calacanis 在最近的 All-In 节目里说过 Instinct 后面有人工操作员;还有用户直言 Instinct 那种"全方位授权"的玩法太吓人,作为 single point of failure 不能接受。这条讨论的实质是:第三方 sandbox 解决了"VM 隔离",但没解决"平台方对工具调用的最终控制权"——一旦用户把凭据交给 Instinct 的 Vault,Instinct 的服务端就拥有调任意 API 的能力,这不是任何 microVM 技术能挡得住的。 第二条争议是 Firecracker 是不是最佳选择。有人提到 Firecracker 著名的限制:不支持 PCI passthrough(没有 PCI 总线),所以像 GPU passthrough 之类的高级能力用不了。这对纯 CPU 推理的 Agent 不是问题,但一旦 Agent 跑本地模型或者要用 GPU 加速,这条路就要换。但反过来,另一位做 microVM 的工程师(来自 SlicerVM)反驳说,Firecracker 的极简性正是它能在消费级笔记本上跑起来的原因——Apple 的 Virtualization Framework 加 Firecracker 让 1500-7000 美元的 MacBook 直接变成本地 agent 主机,这在云端反而做不到。两边的结论是:Firecracker 在"短时、纯 CPU、面向大量并发"的场景里仍然是默认选择;一旦涉及 GPU passthrough 或者长期运行的复杂模型,要么换到 Cloud Hypervisor + 设备 passthrough,要么上完整的 QEMU/KVM。 第三条争议是关于"记忆"的形态。Rohan 在博客里特别强调他很喜欢 Instinct 把记忆存为 git repo 这件事:你用一段时间之后,可以去看 git history 看 Agent 是怎么"记住"你的——这等于给你的 Agent 一个版本化的传记。有评论直接说,"Instinct 就是一个披着 markdown 文件外衣的 Agent",数据库、图、向量库都没用,就靠 grep。但也有人指出,gpt 这样的纯 markdown 方案在规模化后会撞墙:几千个 entity 的时候 grep 还行,几万个的时候每次检索成本会上去。这条争议背后其实是一个更大的问题:Agent 的长期记忆到底是放在 git 仓库这种"工程友好"的载体里,还是放在向量数据库 + 知识图谱这种"语义友好"的载体里?目前没有标准答案。 ## 六、对企业 Agent 落地的三个边界判断 把这两条路线抽象成企业 Agent 落地时必须做的边界判断,有三条是绕不开的。 第一条边界是:**执行层的隔离不解决信任问题**。microVM 只能保证"一个 Agent 的崩溃不会影响另一个 Agent 的进程",但它不能保证"Agent 调用某个第三方 API 时的副作用是用户授权的"。如果你把 Agent 落到企业里,执行链路上只要有一个环节——比如支付、调工单、写正式合同——不在你自己的信任域里,那你必须有一个独立的人工二次确认或者审计层。这是 Claude Code 那种"控制平面留在 sandbox"的设计比 Instinct 更值得借鉴的地方:你必须能在某一步把 Agent 拦住,而不是只能事后追责。 第二条边界是:**记忆层不要绑死在单一载体**。git 仓库看起来美,但 git 是为源代码设计的,它不支持语义检索、不支持并发写、不支持 schema 约束。当 Agent 的记忆开始进入"几千个 entity、上万次 commit"的规模,纯 git 方案会首先在 grep 上撞墙,然后在 diff 上撞墙。一个工程上更稳的折中,是把"短期会话状态"放在 VM 本地盘,把"中期事实/任务/决策"放在 git 或者 KV,把"长期语义"放在向量数据库。三层划分,各管一段,不要把所有记忆都丢进一个 git repo 里。 第三条边界是:**平台层的可替换性必须从第一天就设计**。你今天可以选 E2B、可以选自营 Firecracker、可以选 Cloud Hypervisor、可以选 macOS 上的 Apple Virtualization Framework,但任何一个都不太可能五年后还在你当时签合同的那个版本。Rohan 实测出来的几个"区分性 feature"——Claude Code 的 vsock 2024、E2B 的 systemd PID 1、Instinct 的 `tools` CLI + GraphQL 桥——都是平台特定的能力,一旦绑定就难换。落地的时候,你必须有一个"平台适配层",把 Agent 的核心逻辑和具体的 sandbox 实现隔开。哪怕只是一个简单的 trait 抽象,也比把 `vsock 2024` 写死在代码里强得多。 ## 七、结论:虚拟化是基础设施,但不是 Agent 的全部 回到标题那个问题:VM 平台层驱动 Mobile Agent,这是 2026 年所有要做 Agent 落地的企业都必须正面回答的工程问题。Claude Code 和 Instinct 的两条路线给了我们两个不同方向的答案——前者把控制权收紧到自营 fleet 里,后者把执行外包给第三方 sandbox、把记忆外包给 S3、把工具调用外包给平台服务端——但它们都没有解决 Agent 落地里最本质的那个问题:**Agent 代替人类执行副作用操作时的责任归属与人工复核机制**。 虚拟化的边界很清楚:它能挡 sandbox 越狱、它能挡跨租户数据串、它能挡文件系统误删,但它挡不住 Agent 通过合法的工具调用往生产数据库里写错一行 SQL。下一次再有人告诉你"我们用 microVM 隔离了 Agent,所以很安全",你可以反问一句:**那 Agent 调用 Stripe 支付 100 万美元的时候,谁来按那个 Approve 按钮?** 参考资料: - Rohan Adwankar, *The box an agent runs in*, 2026-09-08, rohanadwankar.github.io/posts/platforms.html - Hacker News discussion, *The VMs Powering Mobile Agents (Instinct, Claude Code)*, 2026-09-08, news.ycombinator.com/item?id=49605644 - Anthropic Engineering, *Beyond permission prompts: making Claude Code more secure and autonomous with sandboxing*, 2025-10-20, anthropic.com/engineering/claude-code-sandboxing - jachris, *Show HN: Isolade, a local-first coding agent workbench with secretless microVMs*, 2026-08-04, github.com/isolade/isolade - E2B, *Infrastructure*, github.com/e2b-dev/infra