OpenAI收购Ona：Codex持久化沙箱如何改变Agent开发范式

AI Horizon

109人浏览 · 2026-06-25 15:06:28

AI Horizon · 2026-06-25 15:06:28 发布

2026年6月11日，OpenAI 在估值 8520 亿美元的 IPO 前夜投下了一颗重磅炸弹——正式宣布收购 Ona（前身为 Gitpod）。同一天，OpenAI 还宣布了与 Oracle OCI 的云基础设施合作。如果把这颗棋子和前一天 Oracle 合作的消息放在一起看，一幅完整的图景浮出水面：OpenAI 正在将 Codex 从一个「运行在你电脑上的编程助手」，升级为一个「运行在你云里的 Agent 平台」。

对于超过 500 万周活跃的 Codex 用户来说，这次收购的意义远超一次普通的并购——它宣告了 AI Agent 开发范式的根本性转变。

一、Ona 是谁：从 Gitpod 到「Agent 控制中心」

Ona 的故事是一个典型的「从工具到平台」的转型。它最初的身份是 Gitpod——一个基于浏览器的云端开发环境（CDE），让开发者无需在本地配置就能在浏览器中写代码。2025年9月，公司更名为 Ona，CEO Johannes Landgraf 给出了一个全新的定位：「你的软件工程 Agent 团队的任务控制中心」。

这不是一个简单的营销话术变化，而是一次完整的架构重构。Ona 现在的平台由三个组件构成：

Ona Environments——API 优先的云端沙箱环境，提供 OS 级别的隔离，通过 devcontainer.json 声明式配置
Ona Agents——能独立生成代码、运行命令、创建 Pull Request、响应 Review 反馈的自主 AI 协作者
Ona Guardrails——企业级安全控制，包括审计追踪、RBAC、SSO/OIDC、VPC 部署

一组数据说明 Ona 平台的成熟度：其平台上 Agent 已合著了 60% 的已合并 Pull Request，贡献了 72% 的合并代码。其客户包括主流金融机构、欧洲制药企业和亚洲主权财富基金——这些可不是拿 AI 做玩具的尝鲜者。

▲ Codex + Ona 持久化沙箱架构：Agent 运行在客户自有 VPC 的云环境中，具备 OS 级隔离和持久化能力

二、持久化沙箱：从「会话绑定」到「多日持续执行」

理解这次收购，首先要理解 Codex 当前架构的一个根本性限制。

今天，Codex CLI 的沙箱是绑定在启动它的那台机器上的。macOS 上的 Seatbelt、Linux 上的 Landlock + seccomp——这些隔离机制虽然强大，但一个致命的缺陷是：关上笔记本电脑，Agent 就停了。

OpenAI 在收购公告中把这个问题的严重性讲得很直白：

"随着 Codex 能力越来越强，它最有价值的工作正在从分钟级扩展到小时甚至天级。用户应该能够委派更雄心勃勃的任务，而不必被束缚在任务开始的那台机器前。"

这揭示了一个关键的工程瓶颈：Codex 的周活用户已超过 500 万（较年初增长 400%），但会话绑定模型让用户无法真正「委派」工作——你不能让 Codex 在晚上执行一次跨仓库的重构，不能在周末让它跑一轮完整的测试套件扩展，不能在手机上查看一个正在执行的长时间任务。

Ona 的云端环境在 Codex 现有的三层沙箱模式之上，叠加了第四个维度——基础设施级隔离：

沙箱层级	隔离范围	持久性
read-only	仅检查，无写入	会话绑定
workspace-write	工作区可写，网络需审批	会话绑定
danger-full-access	完全访问	会话绑定
Ona Cloud Environment	OS级隔离 + VPC部署	跨会话持久化

关键区别在于最后一行的「客户控制的执行模型」。Agent 运行在组织自己拥有和控制的云基础设施内，而非 OpenAI 的服务器上。这个设计一举解决了数据主权和合规审计两个企业部署的最大阻碍。

▲ Agent 开发范式的转变：从会话绑定的本地执行（左），到跨设备的持久化云端执行（右）

三、Agent 开发范式的三大变化

3.1 变化一：跨设备恢复与分叉

Codex 已经支持 codex resume 和 codex fork 命令用于会话连续性。Ona 的持久化环境使这些命令具备了跨设备能力——

在工作站上启动一个 session，在手机上通过 Codex 移动端恢复它，第二天早上在另一台机器上查看结果。所有这些操作都指向同一个正在运行的云端环境。

这不是简单的状态同步——environment、filesystem、进程树、网络状态全部持续存在。对于一个正在执行多仓库迁移的 Agent 来说，这意味着零状态损耗的上下文切换。

3.2 变化二：长周期任务从「可以想」到「可以跑」

目前用 codex exec 执行长时间任务，需要开发者保持终端活跃，或者把它丢到 CI runner 上。但 CI runner 是无状态的——每次运行从零开始，无法积累跨运行的项目上下文。

Ona 持久化环境改变了这个假设。一个需要 8 小时的跨仓库迁移不再需要开发者守着终端，也不再需要 CI runner 在无状态下强行执行。Agent 可以：

在环境中持续运行数天
积累项目上下文（依赖版本、构建缓存、配置状态）
在失败时从断点恢复而非从头开始

3.3 变化三：企业级部署模式

对已经在 CI 中使用 openai/codex-action@v1 的团队，Ona 环境可以用持久化、预配置的云环境替代短暂的 GitHub Actions runner。关键优势：

声明式配置：devcontainer.json 与现有的 CI/CD Infrastructure-as-Code 实践完全对齐
VPC 内部署：Agent 在企业的云边界内运行，数据不出域
审计追踪：企业级的安全控制——谁在什么时候让 Agent 做了什么

四、竞争格局：Codex 的差异化优势

这次收购使 Codex 在竞争格局中建立了一个独特的差异化点：

▲ 四大 AI 编程平台的竞争对比：Codex+Ona 在云执行持久化和客户控制基础设施上建立了独特优势

平台	云执行	Agent持久化	客户控制基础设施
Codex + Ona	✅ Ona Environments	✅ 小时/天级（已宣布）	✅ VPC 部署
Claude Code	✅ Anthropic 云沙箱	❌ 会话绑定	❌ 平台托管
GitHub Copilot	✅ Codespaces	❌ 会话绑定	❌ GitHub 托管
Devin	✅ Devin 云沙箱	✅ 多小时任务	❌ Devin 托管

Devin 是持久化 Agent 执行领域最接近的竞争者，但其沙箱是平台托管而非客户控制的。Ona 的 VPC 部署模型为 Codex 在受监管行业（金融、医疗、政府）建立了一个竞品短期内难以复制的护城河——在这些行业里，「数据不能离开组织的云边界」是一个硬约束，不是可选项。

五、现在该做什么

收购尚未完成，OpenAI 和 Ona 在法律上仍是两家独立公司。但开发者可以提前准备：

审计你的 session 时长。运行 codex history，检查有多少次高效 session 因硬件限制被中断。如果这个比例很高，持久化环境对你至关重要。
检查沙箱配置的可移植性。确保 config.toml 的 profile 和 AGENTS.md 指令在本地和云端环境下行为一致。
为项目添加 devcontainer.json。Ona 环境使用声明式配置。如果项目还没有 .devcontainer/devcontainer.json，现在是创建它的最佳时机。
关注 Changelog。订阅 GitHub Releases 和 OpenAI 开发者文档的更新，新的 Ona 相关 CLI 功能会首先在这里出现。

{
  "name": "codex-ready",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/devcontainers/features/node:1": {},
    "ghcr.io/devcontainers/features/rust:1": {}
  },
  "postCreateCommand": "npm install && cargo build"
}

收购的更大意义在于：OpenAI 的布局策略已经非常清晰。Oracle OCI 合作（6月10日）扩展了云提供商覆盖，Ona 收购（6月11日）增加了执行层。两者叠加，Codex 正在从一个「运行在你机器上的工具」变成一个「运行在你云里的 Agent 平台」——基础设施在下面，composability 在上面，你的 codex exec 一行命令和 AGENTS.md 文件不需要任何改变。它们只是能在更多地方、更长时间、无需你盯着的运行。