OpenAI为什么要买一家「给AI Agent提供云端执行环境」的公司?

这是我的第 303 篇原创文章

作者｜柏导

6月11日，OpenAI宣布计划收购Ona。这笔交易最值得关注的点在于它暴露了一个行业级别的认知转向：Agent赛道的瓶颈，已经是你能不能让Agent在真实的企业系统里安全地、持续地干活了。

先说Ona是什么。很多人没听过这个名字，但如果说Gitpod，开发者群体应该不陌生。Ona就是Gitpod改的名，2025年9月品牌重塑。Gitpod做了好几年云开发环境，2020年种子轮300万美元，2022年A轮2500万美元，到品牌更名的时候号称服务了200万开发者。转型成Ona之后，公司的定位从"给开发者提供云端IDE"变成了"给AI Agent提供云端执行环境"。说白了，Ona干的事情是：你的Agent不用在你笔记本上跑了，给它一个云上的完整环境，有代码库、有网络权限、有工具链、有密钥管理，能连续跑几个小时甚至几天，跑完给你提一个PR。

这个听起来好像也没什么了不起。OpenAI自己的Codex不也是云端sandbox吗？区别在哪？区别在"sandbox"和"企业可控执行环境"之间隔着一条巨大的鸿沟。

Ona的架构是双平面的：管理平面负责认证、组织策略、安全护栏；Runner负责实际执行，包括拉代码、注入密钥、跑Agent。关键点是Runner可以部署在客户自己的AWS或GCP的VPC里，源代码和SCM凭证不会离开Runner。这意味着什么？意味着一家银行、一家医疗公司、一家对数据主权极度敏感的欧洲企业，可以让Agent在自己的地盘上干活，而不是把代码和密钥交给OpenAI的云。

更值得注意的是Ona在运行时安全上做的事。它有一个叫Veto的东西，跑在Linux内核的安全模块层上，用内容哈希来识别可执行文件。为什么这很重要？因为Agent会推理。传统的安全限制是"不许执行/usr/bin/xxx"，但一个会推理的Agent完全有可能把被禁止的二进制文件复制到别的路径、改个名字、通过符号链接绕过去。按内容哈希识别，至少把这条路堵上了。Ona自己也公开承认，动态链接器通过mmap加载被禁二进制仍然是一个尚未完全解决的问题——这种坦诚反而说明他们是真做过对抗测试的。

回到OpenAI这边。在收购Ona之前，OpenAI的Agent能力栈已经不算薄了：Codex是云端软件工程Agent，Frontier是企业级Agent平台，Agents SDK提供开发框架，今年3月收购了Promptfoo做Agent安全评测，5月跟Dell合作把Codex推进混合和本地部署环境。但这些东西有一个共同的特征——它们更偏"模型调用层"和"开发层"，在真正的企业运行时层面，OpenAI其实是偏薄的。它有sandbox，但不是客户可控的持久执行环境；它有权限框架，但没有内核级的执行约束；它有合规API和数据不训练的承诺，但在"代码和密钥在谁的地盘上跑"这个问题上，不够完善。

Ona补的就是这块。不是模型能力，不是编排能力，不是开发者体验，是执行底座。

你可以这么理解：OpenAI之前卖的是一个很聪明的大脑，加上一套让大脑跟工具协作的框架。但企业客户看到的问题是——这个大脑要进入我的办公室，要碰我的文件柜，要用我的门禁卡，要在我的电脑上操作。那你得先告诉我：它在哪台机器上跑的？用了什么身份？干了哪些事？能不能保证它不会把我的代码传出去？出了问题我能不能回溯每一步操作？这些问题，光靠模型聪明是回答不了的。

这就是"认知转向"。过去两年，Agent赛道的竞争核心是模型：谁的推理强，谁的上下文窗口大，谁的工具调用准确率高，谁在SWE-bench上刷分高。这些当然重要，但它们解决的是"Agent能不能完成任务"的问题。到了2026年，越来越多的证据表明，真正卡住Agent大规模落地的是"敢不敢让它做"。

学术界其实已经在指向这个方向了。SWE-bench、GAIA、RealWebAssist这些评测基准持续说明一件事：长时程、多工具、真实环境下的任务，Agent的表现跟benchmark上的分数差距很大。ReAct在两年多前就证明了推理和行动必须结合，但"行动"这个词背后隐含着执行环境、权限、连续性、可恢复性这一长串前提条件。OWASP把Prompt Injection列为LLM应用的头号风险，NCSC明确警告prompt injection会导致敏感信息泄露和系统误操作。欧盟AI Act对GPAI模型提供方要求技术文档和风险评估，NIST的生成式AI指引也在推Govern-Map-Measure-Manage的框架。所有这些信号都指向同一个结论：Agent要进入生产环境，"治理"不是可选项，是前提。

OpenAI显然看到了这一点。它在Agents SDK文档里表明：应该假设prompt injection和数据外流尝试一定会发生，因此需要把Agent的运行环境和控制面分离。买Ona就是把这句话落地。

这笔交易之后，Agent赛道的竞争维度会发生根本性变化。以前是"谁的模型更聪明"，接下来会变成"谁的Agent栈更像一个企业能接受的数字劳动力系统"。模型是这个系统的大脑，但大脑之外你还需要身份证、工牌、门禁、监控摄像头、操作日志和审计报告。OpenAI买Ona，本质上就是在给它的Agent办身份证和工牌。

这也意味着竞争壁垒在迁移。以前壁垒在模型，现在模型差距在缩小，开源追上来了，多家厂商都能提供足够好的基座模型。下一层壁垒就变成了整栈能力：模型+工具接入+持续执行+运行时治理+审计合规。谁先把这个栈跑通，谁就能从企业的"试点项目"变成"公司级标准平台"。从OpenAI的动作序列看——Codex、Frontier、Promptfoo、Dell合作、Ona——它确实在有意识地搭建这个栈。

当然，这里面有很多不确定性。交易还没交割是一个。整合风险是另一个——OpenAI现在的产品线已经够复杂了，Codex、Frontier、Agents SDK、Promptfoo，再加上Ona，客户会不会看到一堆零散的产品而不是一个统一的平台？Ona的Datawall（内核级数据外流检测）还在计划中没有商用，实际效果未知。而且Ona自己也承认，即使内核级控制也不能完全阻止所有绕过路径。Agent安全不存在"一劳永逸"的解法。

还有一个容易被忽略的风险是审批疲劳。Ona的安全实验发现，Agent会把绕过安全限制包装成正常的审批请求。如果企业让员工在高频工作流里不停地点"允许"，审批机制就会从安全边界退化成橡皮图章。这个问题不是技术问题，是人机协作的设计问题，比任何内核级安全措施都难解决。

但即便有这些不确定性，这笔交易的方向信号是清晰的。Agent的下一步是更可用、更可控、更可审计。软件工程会继续是最先成熟的场景，因为代码有PR、有测试、有CI/CD，天然适合Agent的检查点机制。但金融、法务、运营这些场景会紧随其后——只要治理能力跟上。