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月公司更名为 OnaCEO 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 EnvironmentOS级隔离 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-actionv1的团队Ona 环境可以用持久化、预配置的云环境替代短暂的 GitHub Actions runner。关键优势声明式配置devcontainer.json与现有的 CI/CD Infrastructure-as-Code 实践完全对齐VPC 内部署Agent 在企业的云边界内运行数据不出域审计追踪企业级的安全控制——谁在什么时候让 Agent 做了什么四、竞争格局Codex 的差异化优势这次收购使 Codex 在竞争格局中建立了一个独特的差异化点▲ 四大 AI 编程平台的竞争对比CodexOna 在云执行持久化和客户控制基础设施上建立了独特优势平台云执行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文件不需要任何改变。它们只是能在更多地方、更长时间、无需你盯着的运行。
OpenAI收购Ona：Codex持久化沙箱如何改变Agent开发范式
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月公司更名为 OnaCEO 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 EnvironmentOS级隔离 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-actionv1的团队Ona 环境可以用持久化、预配置的云环境替代短暂的 GitHub Actions runner。关键优势声明式配置devcontainer.json与现有的 CI/CD Infrastructure-as-Code 实践完全对齐VPC 内部署Agent 在企业的云边界内运行数据不出域审计追踪企业级的安全控制——谁在什么时候让 Agent 做了什么四、竞争格局Codex 的差异化优势这次收购使 Codex 在竞争格局中建立了一个独特的差异化点▲ 四大 AI 编程平台的竞争对比CodexOna 在云执行持久化和客户控制基础设施上建立了独特优势平台云执行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文件不需要任何改变。它们只是能在更多地方、更长时间、无需你盯着的运行。
