首次公开！奥特曼重新发明了浏览器

【导读】OpenAI首个浏览器Atlas，背后技术秘密终于公开了！借用了谷歌Chromium，但关键创新在于全新架构OWL。据称，新入职员工一个下午就能交代码。

OpenAI浏览器Atlas核心架构，终于揭秘！

今天一早，Atlas负责人Ben Goodger公开一篇博文，背后OWL架构首次亮相。

上一周，OpenAI酝酿已久的终极浏览器ChatGPT Atlas⁠终于现世。它开启了一种全新的网页浏览方式，全程还可以和ChatGPT交互。

为了让ChatGPT成为得力的「领航员」，团队重构了浏览器的架构OWL。

OWL架构自画像

其中，最关键的一步在于：将Atlas应用与Chromium运行时，进行分离。

为此，他们开发了一种全新的Chromium集成方式，由此一来，Atlas可以做到——

• 即时启动

• 在打开大量标签页时，仍能保持流畅响应

• 为AI智能体用例奠定基础

原生框架OWL，重构UI体验

为何要用谷歌Chromium去做「套壳」？

OpenAI给出了解释，Chromium是一个理想的构件基础。

它提供了一流的网页引擎，拥有强大的安全模型、久经考验的性能表现和无与伦比的网页兼容性。

此外，它由一个全球化的社区持续开发和改进，是现代桌面网页浏览器的首选方案。

另一方面，OpenAI设计团队为「用户体验」设立了宏伟目标，比如为「智能体模式」等功能实现丰富的动画和视觉效果。

这就要求，工程团队必须采用最现代化的原生框架（如SwiftUI、AppKit和Metal）来构建UI，而非简单地为开源的Chromium UX「换皮」。

因此，Atlas的UI是对整个应用用户体验的一次彻底重建。

此外，OpenAI团队还有其他产品目标，比如快速启动、支持数百个标签页同开等。

仅靠开箱即用的Chromium，是无法实现的。

因为它对启动序列、线程模型和标签页模型等许多细节，都有其固定的实现方式。

为了最大限度地提高开发速度，OpenAI必须找到一种不同的方式来集成和驱动Chromium运行。

衡量这项技术投资成功的关键，不仅在于它能否支持更快的实验迭代和新功能交付，还在于它能否坚守OpenAI工程文化的核心：

入职第一天就提交代码。

每一位新工程师都会在入职第一天的下午，就能完成并合并一个小改动。

即便检出和构建Chromium可能需要数小时之久，这一点也必须实现。

为此，OpenAI给出的解决方案是：OWL。

为应对这些挑战，OpenAI构建了一个新的架构层，称之为OWL：OpenAI Web Layer。

OWL是集成Chromium的方案，它将Chromium的浏览器进程，运行在主应用Atlas的进程之外。

第一天提交代码，数分钟造Atlas

你可以这样理解：Chromium通过将标签页移至独立进程，彻底改变了浏览器。

OpenAI将这一理念推向了新的高度，即把Chromium本身从主应用进程中剥离出来，置于一个隔离的服务层中。

这种设计方式，带来了一系列优势：

• 更简洁、现代化的应用：Atlas几乎完全由SwiftUI和AppKit构建。单一语言、单一技术栈、纯净的代码库。

• 更快的启动速度：Chromium在后台异步启动，Atlas无需等待，界面几乎瞬间就能呈现在用户眼前。

• 与卡顿和崩溃隔离：Chromium是一个强大而复杂的网页引擎。即便其主线程卡死，Atlas依然流畅；即便它崩溃，Atlas也能保持运行。

• 更少的合并烦恼：由于团队并未大量基于Chromium开源UI进行构建，Atlas与上游Chromium的代码差异更小，维护也更容易。

• 更快的迭代速度：大多数工程师完全无需在本地构建Chromium。OWL在内部以预构建二进制文件的形式分发，因此构建Atlas只需几分钟，而非数小时。

因为工程师无需频繁地从源码构建Chromium，开发速度得以大幅提升——即便是新成员也能在入职第一天下午，就合并简单的代码改动。

从顶层来看，Atlas浏览器是OWL客户端，而Chromium的浏览器进程是OWL主机。

它们之间通过IPC（进程间通信）进行通信，具体使用的是Mojo⁠（在新窗口中打开）——Chromium自有的消息传递系统。

OpenAI为Mojo编写了自定义的Swift（甚至TypeScript）绑定，使得Swift应用能够直接调用主机端的接口。

OWL客户端库提供了一个简洁的公共Swift API，抽象了主机服务层暴露的几个关键概念：

• Session：全局配置和控制主机

• Profile：为特定用户配置文件管理浏览器状态

• WebView：控制和嵌入单个网页内容（如渲染、输入、导航、缩放等）

• WebContentRenderer：将输入事件转发至Chromium的渲染管线，并接收来自渲染器的反馈

• LayerHost/Client：在UI和Chromium之间交换图形合成信息

此外，还有一系列广泛的服务端点，用于管理书签、下载、扩展和自动填充等高级功能。

渲染：跨进程边界传递像素

在客户端应用中，多个WebView共享一个互斥的显示空间，它们会在一个共享的合成容器中被换入换出。

例如，一个浏览器窗口通常只有一个可见的共享容器，当用户在标签栏中选择一个标签页时，该标签页对应的WebView就会被换入这个容器。

在Chromium端，这个容器对应一个gfx::AcceleratedWidget，其底层由一个CALayer支持。

OpenAI将该CALayer的上下文ID暴露给客户端，客户端中的NSView再通过私有的CALayerHost API将其嵌入。

对于一些特殊情况，如 下拉菜单或颜色选择器，Chromium会在独立的弹出窗口中进行渲染，但仍采用相同的方法。 这些弹出窗口没有content::WebContents，但它们有自己的content::RenderWidgetHostView和gfx::AcceleratedWidget，因此同样的委托渲染模型依然适用。 OWL内部会保持视图几何信息与Chromium端同步，以便GPU合成器能够相应地更新，并始终生成尺寸和设备缩放比例正确的图层内容。 OpenAI还利用这项技术，有选择地将Chromium自身原生Views UI的元素投射到Atlas中。 这对于快速实现权限提示等功能非常有用，无需在SwiftUI中从零开始构建替代品。 这项技术大量借鉴了Chromium现有的在macOS上安装PWA（可安装网页应用）的基础设施。 输入事件：解析与转发 在将平台事件（如macOS的NSEvents）转发给渲染器之前，Chromium UI会先将其转换为Blink的WebInputEvent模型。 但由于OWL在一个隐藏的进程中运行Chromium，OpenAI在Swift客户端库中自行完成了这一转换，并将转换后的事件直接转发给Chromium。 此后，这些事件将遵循与真实输入事件在网页内容中相同的生命周期。 这包括当页面表示未处理某个事件时，将该事件返回给客户端。此时，OpenAI会重新合成一个NSEvent，让应用的其他部分有机会处理该输入。 智能体模式：特殊处理 Atlas AI智能体浏览功能，对渲染、输入事件转发、数据存储方案，提出了一些独特的挑战。 计算机视觉模型需要将整个屏幕的单张图像作为输入。但某些UI元素（如下拉菜单）会渲染在标签页边界之外的独立窗口中。

在智能体模式下，OpenAI会将这些弹出窗口，以正确的坐标合成回主页面图像中，确保模型能在单个画面中看到完整的上下文。

对于输入，他们采用相同的原则：由智能体生成的事件直接路由到渲染器，绝不经过拥有特权的浏览器层。

这确保了即使在自动化控制下，沙箱边界依然得以维持。

比如，OpenAI不希望这类事件合成出键盘快捷键，从而导致浏览器执行与当前网页内容无关的操作。

智能体浏览还可以在一个临时的「已登出」的上下文中运行。

同时，OpenAI不会共享用户现有的无痕模式配置文件，而是利用Chromium的StoragePartition基础设施，来启动隔离的、内存中的存储空间。

每个智能体会话都从一个全新的状态开始，会话结束时，所有的cookie和网站数据都会被丢弃。

任何人可以同时运行多个「已登出」的智能体对话，每个都位于独立的浏览器标签页中，并与其他会话完全隔离。

丝滑解锁下一代AI浏览器

如果没有全球Chromium社区以及他们为构建现代网络基石所付出的卓越努力，这一切都无从谈起。

OWL正是在这一基石上，以一种全新的方式进行构建：

将引擎与应用解耦，将世界级的网络平台与现代化的原生框架相融合，从而解锁了一个更快、更灵活的架构。

通过重塑浏览器承载Chromium的方式，OpenAI为创造新型体验开辟了空间：更流畅的启动、更丰富的 UI、与操作系统更深度的集成，以及一个能跟上创意速度的开发循环。

所以，Atlas远不止是Chromium一个简单的外壳。

参考资料：

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