本地、VM、容器，哪一种会成为 AI 执行层的主战场？

过去大家讨论 Agent，讨论的是模型会不会更聪明；但到了今天，更决定 Agent 能不能进生产环境的，已经不是“会不会想”，而是“跑在哪里、拿什么权限、出了事怎么隔离”。OpenAI 已经把 computer use 放进官方 built-in tools，而且明确说明它和普通内建工具不同：模型给出动作后，动作必须在“虚拟电脑或浏览器”上执行，再把截图回传；与此同时，ChatGPT agent 已经被官方定义为能用“自己的虚拟电脑”替用户完成任务；Anthropic 的 computer use 也把截图、鼠标、键盘、桌面自动化做成了标准能力。执行环境因此不再是边缘问题，而是 Agent 产品定义的一部分。

截至 2026 年 3 月，从头部产品的公开设计看，路线其实已经明显分化：OpenAI 的 Codex 云端任务运行在隔离容器里；Anthropic 的 Claude Code 同时覆盖 terminal、IDE、desktop app 和 browser，并专门给出 devcontainer 方案；AWS 的 AgentCore Browser 提供容器化、隔离的远程浏览器环境，而 AgentCore Runtime 的会话则直接落在 dedicated microVM 上；E2B 则把按需创建的 Linux VM 和 Firecracker microVM 明确放到自己的执行底座叙事里。OXYZ资本认为，这个问题真正该问的，不是“本地、VM、容器谁会赢”，而是：AI 执行层到底会如何分工。

先把三个概念说清楚。本地，争的不是“更先进”，而是最短的信任半径：最靠近用户身份、最靠近真实操作系统、最靠近本地文件和最终确认权。容器，争的不是“最安全”，而是把依赖、工具链和运行环境打包成标准化 workload 的能力：它最适合复制、编排、扩缩容和工程化。VM，尤其是 microVM，真正卖点也不是“更重”，而是隔离边界更强，适合不可信代码、多租户、长任务和高风险执行。

如果只看哪里会先成为最热闹的主战场，答案几乎是容器。原因很简单：最先规模化的，不会是“通用电脑使用”，而是编码、脚本、工具调用、CI/CD、数据处理这类标准化执行任务。OpenAI 明确写到，Codex agent 在云端“entirely within a secure, isolated container”运行；Codex cloud 的安全文档又补了一层，两阶段运行模型里只有 setup 阶段能按配置联网安装依赖，agent phase 默认离线。Anthropic 则直接给了 Claude Code 的 devcontainer 参考实现，并强调 isolation 和 firewall rules；Daytona 的执行环境也明显是容器世界的工程语言：OCI 镜像、snapshot、Linux namespaces，以及每个 sandbox 的独立 CPU、内存和磁盘资源。容器不是因为“绝对安全”而先赢，而是因为它最符合今天开发者对可复现、可编排、可工程化的默认想象。

但如果问，哪一种会拿走最贵的安全预算，答案更像 VM，尤其是 microVM。E2B 在文档里把 Sandbox 定义成“按需创建的安全 Linux VM”，在自己的案例和技术文章里又明确把 Firecracker microVM 作为运行不可信代码的底层选择；AWS 更直接，AgentCore Runtime 的官方文档写明，每个 session 都运行在 dedicated microVM 中，CPU、内存、文件系统完全隔离，会话最长可持续 8 小时，终止后整个 microVM 会被销毁并清理内存。越靠近生产系统、越靠近敏感权限、越靠近多租户和不可信输入，隔离失败的代价就越高于冷启动和资源开销，这时安全边界自然会向 VM 化倾斜。OXYZ资本观点是，容器会先吃到开发者流量，但 VM / microVM 更可能吃到企业最贵的那部分放行预算。

真正把这场战争推复杂的，是浏览器和电脑使用。因为浏览器型 Agent 并不是“再跑一个脚本”，而是在云里托管一台可被模型操控的半电脑。OpenAI 的 computer use 官方说明已经说得很清楚：模型给出动作参数后，需要你在“虚拟电脑或浏览器”里执行，再把截图送回去；ChatGPT agent 则进一步把这个概念产品化成“自己的虚拟电脑”；Anthropic 的 computer use 直接提供 screenshot capture、mouse control、keyboard input 和 desktop automation。AWS 的 AgentCore Browser 也不是简单的网页抓取工具，而是一个 containerized、secure、isolated 的 browser environment，并自带 session isolation、CloudTrail、live view 和 replay。与此同时，Browserbase 从浏览器基础设施角度指出，Chromium 一旦从开发者本机搬进容器和共享 cloud runner，运行时本身就会变成新的运维问题，这也是“serverless browser”开始独立成层的原因。换句话说，浏览器型 Agent 往往既不像普通容器任务，也不完全等于一台传统 VM，它更像“被平台托管的浏览器计算单元”。

这也是为什么本地不会消失。很多人把“本地”理解成落后路线，其实恰恰相反：本地会越来越像高信任入口。Claude Code 之所以同时覆盖 terminal、IDE、desktop app 和 browser，不是因为 Anthropic 没选云，而是因为人机接力必须发生在最接近用户的地方；它默认严格只读，执行 bash 等高风险动作需要显式许可。OpenAI 的 Codex app 也没有把答案写成纯云：它明确给出 Local、Worktree、Cloud 三种模式，其中 Local 和 Worktree 都运行在用户自己的电脑上；worktree 用来隔离改动，automations 也可以在本地 app 里以后台 worktree 方式持续运行。这里最有价值的，不是本地那点算力，而是用户身份、本地文件、本地应用、最终审批权和随时接管能力。OXYZ资本内部认为，本地不会是唯一主战场，但它会成为 Agent 最重要的信任前台。

真正的分水岭，不是技术偏好，而是任务类型。代码与工具链任务——依赖标准、命令标准、结果可复现、适合并发调度——天然更偏容器；浏览器与桌面任务——有 GUI、有会话状态、有真实账户、有审计与回放要求——更偏远程浏览器、VM 或强隔离沙箱；个人助手和高隐私任务——涉及本地文件、本地 app、即时交互和用户接管——则更偏本地。不是哪一种执行层会统一世界，而是哪一类任务会把哪一种执行层推成默认选项。

所以，如果非要押一个答案，我更愿意给出一个三层分工而不是三选一。表层答案是容器，因为它最符合今天开发者的工作流，也最容易与镜像、CI、K8s、Dev Containers、snapshot 和已有工程体系接轨；深层答案是 VM / microVM，因为真正决定企业敢不敢把 Agent 放进生产的，是更强的隔离边界和更低的越界后果；真实答案则是本地 + 容器 + VM 的复合栈：本地做入口、审批、接管，容器做默认 workload，VM 做高风险包裹层。OXYZ资本在这个问题上的判断是：AI 执行层真正的主战场，表面看是容器，深处看是 VM，入口看是本地。

更值得警惕的是，未来真正值钱的未必不是 runtime 本身，而是 runtime 之上的控制面。AWS AgentCore 已经把 Runtime、Browser、Identity、Memory、Policy、Observability 做成平台化组合，其中 Policy 明确支持用自然语言或 Cedar 写细粒度规则，并在工具调用前拦截；Browser 的 session replay 则把审计、调试和训练闭环补上。OpenAI Codex 的安全设计也不只是“起个容器”而已，而是把 setup/agent 两阶段、网络边界、secret 生命周期和 approvals 一起纳入运行模型。行业真正有壁垒的，不是谁能起一台 VM，谁能拉一个容器，而是谁能把快照、恢复、长会话状态、权限编排、网络边界、日志、回放和多 Agent 并发管理这些事情管起来。

这也是创业者和投资人真正该盯的方向。不要只盯“我们也能跑容器”“我们也能起 VM”“我们也支持本地”，更该盯的是：执行环境切换成本高不高，会话状态能不能持久化，风险任务能不能安全隔离，浏览器/代码/本地工具三类执行能不能被统一抽象，以及 observability、policy、identity、replay 这一层是不是已经成形。执行层的机会，不在算力盒子本身，而在“可信执行 + 可控运行 + 可审计放权”这一整层。

OXYZ资本认为，本地会成为 Agent 的高信任入口，容器会成为最显性的执行 workload 格式，VM——尤其 microVM——会成为高风险、高价值场景下的默认安全边界。最终赢家不是某一种形态，而是能把三者编排成一个可信执行体系的那一方。