「套壳」的最高境界：OpenAI揭秘Atlas浏览器架构OWL

机器之心报道

编辑：Panda

「又一个 Chromium 套壳？」

面对 OpenAI 上周发布的 AI 浏览器 Atlas，这可能是不少人的第一反应，参阅报道《刚刚，OpenAI 发布 AI 浏览器 ChatGPT Atlas，基于 Chromium》。但今天，OpenAI 官方用一篇技术博客「回怼」了这个说法：我们「套」了，但和别人完全不一样。

尽管今天还有 Sora 角色客串功能和 GPT-5 查找和修复安全漏洞智能体的消息，但本文的重点是深扒 Atlas 背后的「灵魂」——OWL 架构。看看 OpenAI 究竟是如何驯服 Chromium，把它从浏览器「换皮」玩成了「架构重组」的。

基础是 Chromium

OpenAI 表示，要让 ChatGPT 成为网页浏览的真正副驾驶，必须彻底重构浏览器的底层架构：将 Atlas 与 Chromium 运行时剥离开来。这意味着要开发一种全新的 Chromium 集成方式，如此才能满足以下三个关键目标：

• 秒级启动速度
• 打开更多标签页时依旧流畅
• 为智能体（Agent）场景打下坚实基础

OpenAI 强调，Chromium 是一个天然的构建基石。它能提供先进的网页引擎、完善的安全模型、一流的性能，以及卓越的网页兼容性；更重要的是，它由全球开发者社区持续改进。因此，它成为了现代桌面浏览器最常用的底层引擎。

重新定义浏览器体验

虽然基于 Chromium，但 OpenAI 自然也会强调自己的设计，包括在「Agent 模式」等功能中引入丰富的动画和视觉效果。

这要求工程团队使用最现代的原生框架（如 SwiftUI、AppKit 和 Metal），而不是简单地给开源的 Chromium 界面「换皮」。

结果，OpenAI 表示：「Atlas 的用户界面几乎是从零重建的一整套全新体验。

另外，为了实现快速启动和支持上百个标签页同时运行而不掉帧的目标。还需要对 Chromium 进行一些优化，毕竟其默认架构在启动流程、线程模型、标签管理等方面都非常「固执」。

OpenAI 说：「我们考虑过大幅修改 Chromium，但那样会让后续更新复杂且脆弱。为了保持开发速度，我们选择了一条更巧妙的路 —— 重新设计 Chromium 的集成方式。」

他们的一个关键的技术标准是：不仅要加快功能实验、迭代和上线的节奏，还要保留 OpenAI 的工程文化 —— 第一天就能上线代码。「每位新工程师入职第一天下午就要提交并合并一个小改动。即便 Chromium 的源码编译要花几个小时，我们也得保证这一传统能延续。」

OpenAI 的解决方案：OWL

为了解决这些挑战，OpenAI 构建了一个新的架构层，称为OWL（OpenAI’s Web Layer）

OWL 是 OpenAI 整合 Chromium 的方式，其核心理念是：让 Chromium 的浏览器进程独立运行在 Atlas 主应用进程之外

可以这样理解：Chromium 通过将每个标签页放入独立进程来革新浏览器架构；而 OpenAI 更进一步 —— 把整个 Chromium 从主应用进程中分离出来，放入一个独立的服务层。

如此方法好处多多：

• 更简洁现代的应用：Atlas 主要使用 SwiftUI 和 AppKit 构建，统一语言、统一技术栈、代码干净。
• 更快启动：Chromium 会在后台异步加载，Atlas 几乎瞬间显示画面。
• 隔离崩溃与卡顿：即使 Chromium 出问题，Atlas 也不会挂。
• 更少的合并冲突：OpenAI 修改的 Chromium 代码极少，易于维护。
• 更快的开发节奏：大多数工程师无需本地编译 Chromium，OWL 内部以预构建二进制形式分发，Atlas 构建只需几分钟。

因此，即使是新员工，也能在第一天下午轻松提交改动。

OWL 的工作方式

从高层来看，Atlas 浏览器是 OWL 客户端，而 Chromium 浏览器进程是 OWL 主机（Host）。两者通过 Mojo（Chromium 的进程间通信系统）进行通信。OpenAI 编写了 Swift（甚至 TypeScript）的 Mojo 绑定，使 Swift 应用能直接调用主机端接口。

OWL 客户端库提供了一套简洁的 Swift API，用于抽象主机层的关键功能：

• Session：全局配置与控制
• Profile：管理用户浏览数据
• WebView：渲染、输入、导航、缩放等
• WebContentRenderer：将输入事件传递给渲染管线
• LayerHost/Client：在 UI 与 Chromium 之间交换合成信息

此外，还提供书签、下载、扩展、自动填充等服务端点。

渲染：跨进程传递像素

WebView 在客户端应用中共享一个合成容器，不同标签页的内容会动态交换显示。在 Chromium 一侧，这对应于一个 gfx::AcceleratedWidget，由底层的 CALayer 支撑。

OpenAI 的设计是将该层的上下文 ID 暴露给客户端，由 NSView 通过私有的 CALayerHost API 嵌入。

诸如 下拉框或颜色选择器等独立弹窗，也采用相同机制。OWL 会保持视图几何与 Chromium 同步，确保 GPU 合成器输出正确分辨率和比例的内容。 下拉框）会在标签页外单独渲染。在 Agent 模式下，OpenAI 会将这些弹窗重新合成为主页面的一部分，让模型在一帧中看到完整的上下文。

OpenAI 也借用这种机制，将 Chromium 原生界面的一部分直接投射到 Atlas 中，比如权限提示框，从而快速实现功能原型而无需完全重写。

输入事件：捕获与转发

通常，Chromium UI 会将 macOS 的 NSEvent 转换为 Blink 的 WebInputEvent，然后再传递给渲染器。

但由于 OWL 中 Chromium 在后台运行，OpenAI 在 Swift 客户端中自己完成事件转译，再将转换后的事件发给 Chromium。

如果网页未处理某个事件，系统会把事件返回客户端，OpenAI 重新生成 NSEvent，让 Atlas 其他部分接管输入处理。

Agent 模式：特殊情况

Atlas 的智能体浏览对渲染、输入和数据存储提出了额外挑战。OpenAI 的计算机使用（computer use）模型需要屏幕的完整图像作为输入。

但有些 UI（如

输入事件同样遵循安全原则：Agent 生成的事件直接传给渲染器，不经过特权浏览器层，以确保沙箱隔离。例如，防止自动化事件触发系统快捷键等非网页行为。

此外，Agent 浏览可以在临时「登出」上下文中运行。它不会使用用户的隐私模式配置，而是借助 Chromium 的 StoragePartition 创建独立的内存存储。每个 Agent 会话都是全新的，结束后所有 cookie 和数据都会被清除。用户可以同时运行多个互不干扰的「登出」 Agent 会话。

结语

OpenAI 最后再次重申了 Chromium 的作用：「如果没有全球 Chromium 社区的卓越贡献，这一切都无法实现。OWL 在此基础上开辟了新的方向：将引擎与应用解耦，结合顶级网页平台与现代原生框架，打造更快、更灵活的架构。」

对此，你怎么看？

https://openai.com/index/building-chatgpt-atlas/