📢 转载信息
原文链接：https://openai.com/index/building-chatgpt-atlas
原文作者：Ken Rockot, Member of the Technical Staff and Ben Goodger, Head of Engineering, ChatGPT Atlas
上周，我们发布了ChatGPT Atlas，这是一种将ChatGPT作为您的网络伴侣的全新浏览方式。除了作为功能齐全的网络浏览器外，Atlas还为未来提供了一瞥：一个您可以随身携带ChatGPT浏览互联网、提出问题、给出建议并为您完成任务的世界。在这篇文章中，我们将深入探讨该产品最复杂的工程方面之一：我们如何将ChatGPT变成一个随着您使用而变得越来越有用的浏览器。
要让ChatGPT成为真正的网络副驾驶，意味着需要重新构想浏览器的整个架构：将Atlas与Chromium运行时分离。这需要开发一种集成Chromium的新方法，使我们能够实现产品目标：即时启动，即使打开更多标签页也能保持响应速度，并为智能体用例创建坚实的基础。
Chromium是一个天然的构建模块。它提供了一个最先进的Web引擎，具有强大的安全模型、既定的性能认证和无与伦比的Web兼容性。此外，它由一个持续改进它的全球社区开发。它是现代桌面网络浏览器的一个常用选择。
重新思考浏览器体验
我们才华横溢的设计团队对用户体验有着宏伟的目标，包括Agent模式等功能的丰富动画和视觉效果。这要求我们的工程团队利用最现代的原生框架（SwiftUI、AppKit和Metal）来构建用户界面，而不是简单地修改开源Chromium的用户体验。因此，Atlas的用户界面是对整个应用程序用户体验的一次全面重建。
我们还有其他产品目标，例如快速启动时间和支持数百个标签页而不牺牲性能。这些目标对于开箱即用的Chromium来说是难以实现的，因为它在启动顺序、线程模型和标签模型等许多细节上都有自己的既定观点。我们考虑在这里进行重大更改，但我们希望将我们对Chromium的补丁集保持在有针对性的范围，以便我们能够快速集成新版本。为了确保我们的开发速度最大化，我们需要找到一种不同的方法来集成和驱动Chromium运行时。
我们技术投入的试金石不仅在于它能否实现更快的实验、迭代和新功能交付，还在于它能否使我们维护OpenAI工程文化的核心部分：首日就交付成果。每位新工程师都能在入职的第一天下午完成并合并一小段更改。我们需要确保即使Chromium签出和构建可能需要数小时，这种情况仍然可行。
我们的解决方案：OWL
我们应对这些挑战的答案是构建了一个新的架构层，我们称之为OWL：OpenAI’s Web Layer（OpenAI的Web层）。OWL是我们对Chromium的集成，它包括让Chromium的浏览器进程运行在Atlas主应用进程的外部。
可以这样理解：Chromium通过将标签页移动到单独的进程中彻底改变了浏览器。我们更进一步，将Chromium本身从主应用进程中移出，放入一个隔离的服务层中。这一转变带来了一系列好处：
- 更简单、更现代的应用： Atlas几乎完全使用SwiftUI和AppKit构建。一种语言，一个技术栈，一个干净的代码库。
- 更快的启动速度： Chromium在后台异步启动。Atlas不必等待——屏幕上的像素几乎瞬间出现。
- 与卡顿和崩溃隔离： Chromium是一个强大而复杂的Web引擎。如果它的主线程挂起，Atlas不会受到影响。如果它崩溃，Atlas会保持运行。
- 更少的合并难题： 由于我们没有构建在太多的Chromium开源UI之上，我们与上游Chromium的差异更小，更容易维护。
- 更快的迭代速度： 大多数工程师不需要在本地构建Chromium。OWL作为一个预构建的二进制文件内部发布，因此Atlas的构建只需几分钟而不是几小时。
由于我们团队的大多数工程师不需要定期从源代码构建Chromium，开发速度可以快得多——即使是新团队成员也可以在他们入职的第一天下午合并简单的更改。
OWL的工作原理
从高层次上看，Atlas浏览器是OWL客户端，而Chromium浏览器进程是OWL主机。它们通过IPC进行通信，特别是Chromium自己的消息传递系统Mojo（在新窗口中打开）。我们为Mojo编写了自定义的Swift（甚至是TypeScript）绑定，因此我们的Swift应用可以直接调用主机端的接口。
OWL客户端库公开了一个简单的公共Swift API，它抽象了主机服务层公开的几个关键概念：
- Session（会话）： 全局配置和控制主机
- Profile（配置）： 管理特定用户配置的浏览器状态
- WebView（Web视图）： 控制和嵌入单个Web内容（例如渲染、输入、导航、缩放等）
- WebContentRenderer（Web内容渲染器）： 将输入事件转发到Chromium的渲染管道并接收来自渲染器的反馈
- LayerHost/Client（层主机/客户端）： 在UI和Chromium之间交换合成信息
此外，还有广泛的服务端点用于管理书签、下载、扩展和自动填充等高级功能。
渲染：将像素传递到进程边界之外
WebView在客户端应用中共享一个互斥的显示空间，它们在共享的合成容器中被交换进出。例如，浏览器窗口通常有一个单一的共享容器可见，选择标签栏中的一个标签会将该标签的WebView交换到容器中。在Chromium端，这个容器对应于一个gfx::AcceleratedWidget，它最终由一个CALayer提供支持。我们将该层的上下文ID暴露给客户端，客户端中的一个NSView使用私有的CALayerHost API来嵌入它。
像<select>下拉菜单或颜色选择器这样的特殊情况，它们在单独的弹出窗口中渲染在标签页边界之外，也使用了相同的方法。它们没有content::WebContents，但它们确实有一个content::RenderWidgetHostView，其中包含它们自己的gfx::AcceleratedWidget，因此适用了相同的委托渲染模型。
OWL在内部保持视图几何形状与Chromium端同步，以便GPU合成器可以相应地更新，并始终能够生成正确大小和设备比例的图层内容。
我们还重复使用此技术将Chromium自己的原生Views UI元素选择性地投射到Atlas中（这对于快速引导权限提示等功能也很有用，而无需在SwiftUI中从头开始构建替代品）。此技术很大程度上借鉴了Chromium现有的macOS可安装Web应用的基础设施。
输入事件：解析和转发
Chromium UI将平台事件（如macOS NSEvents）转换为Blink的WebInputEvent模型，然后转发给渲染器。但是，由于OWL在一个隐藏的进程中运行Chromium，我们自己在Swift客户端库中完成了该转换，并将已经转换的事件转发给Chromium。
从那里开始，它们遵循与真实输入事件通常遵循的生命周期相同的路径。这包括在页面指示未处理事件时将事件返回给客户端。当发生这种情况时，我们重新合成一个NSEvent并将剩余的应用机会给它处理输入。
Agent模式：特殊情况
Atlas的代理式浏览功能在我们的渲染、输入事件转发和数据存储方法上带来了一些独特的挑战。我们的计算机使用模型期望屏幕的单个图像作为输入。但是某些UI元素，例如<select>下拉菜单，会在单独的窗口中渲染在标签页边界之外。在Agent模式下，我们将这些弹出窗口重新合成到主页面图像的正确坐标上，以便模型在一个帧中看到完整的上下文。
对于输入，我们应用相同的原则：Agent生成的事件直接路由到渲染器，而不是通过特权浏览器层。这在自动化控制下也保持了沙箱边界。例如，我们不希望这类事件合成键盘快捷键，导致浏览器执行与所显示的Web内容无关的操作。
Agent浏览也可以在一个短暂的“登出”上下文中运行。我们没有共享用户现有的隐身配置文件（这可能会泄露状态），而是使用Chromium的StoragePartition基础设施来启动隔离的、内存中的存储。每个Agent会话都从头开始，当它结束时，所有cookie和站点数据都会被丢弃。您可以运行多个“登出”的Agent会话，每个会话都在自己的浏览器标签页中，并且每个会话都与其他会话完全隔离。
使用网络的新方式
如果没有全球Chromium社区及其在构建现代网络基础方面所做的惊人工作，这一切都是不可能实现的。OWL以一种新的方式建立在这一基础之上：将引擎与应用解耦，将世界一流的Web平台与现代原生框架相结合，并解锁一个更快、更灵活的架构。
通过重新思考浏览器如何容纳Chromium，我们为新型体验创造了空间：更流畅的启动、更丰富的UI、与操作系统其余部分的更紧密集成，以及以创意速度移动的开发循环。如果您认为这听起来像您喜欢的那种挑战，请查看我们的职位空缺，成为Atlas的软件工程师，Atlas、软件工程师，iOS，以及更多职位。
在chatgpt.com/atlas体验Atlas。
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区