OpenAI 公开 Atlas 架构：为 Agent 重新发明浏览器

今天，OpenAI 公开 Atlas 的核心技术实现，这是一个专门为 Agent 开发的浏览器，让 AI 能够看到完整的界面渲染，而不是需要像人一样，挨个的点击所有元素，才能获得所有信息

这也是OpenAI 首次在工程领域，进行的官方发布

Atlas 看起来就是个 Chromium 套壳，毕竟...你还能看到 Chrome 应用商店，能装 Chrome 插件

Edge、Brave、Arc 也都是这样，看起来都是 Chromium 套壳

但底层架构完全不同

Atlas 把 Chromium 整个搬出去了

传统浏览器里，Chromium 挂了，整个浏览器挂

Chromium 卡了，浏览器界面跟着卡

有用户反馈，在 Sora 这种复杂网页，别的 AI 浏览器会卡住，Atlas 是正常的

Atlas 主应用是独立的 Swift 应用，Chromium 作为独立进程在后台运行，两者通过 IPC 通信

这套架构叫OWL（OpenAI's Web Layer）

按 OpenAI 的说法，这种方式

在项目开发上，也能做到足够的解耦，新员工第一天下午就能提交代码

Atlas 和 Chromium 之间通过 Mojo 通信，这是 Chromium 自己的 IPC 系统

OpenAI 写了自定义的 Swift 绑定，让 Swift 应用能直接调用 Chromium 的接口

这里有几个核心概念：

Session：全局控制 Chromium

Profile：管理用户配置

WebView：控制单个网页的渲染、输入、导航

LayerHost/Client：在 Atlas 和 Chromium 之间交换渲染信息

网页内容怎么显示？

Chromium 渲染好的 layer 通过CALayerHost传给 Atlas

Atlas 用NSView把这个 layer 嵌进界面

输入事件怎么处理？

Atlas 收到用户输入（鼠标、键盘），翻译成 Chromium 能理解的WebInputEvent格式，发给 Chromium

如果网页没处理这个事件，Chromium 会把事件退回来，Atlas 重新合成NSEvent，给应用的其他部分处理

这里的思路很牛逼

computer use model 需要一张完整的屏幕截图

问题来了，浏览器里有些元素是独立渲染的

下拉菜单、颜色选择器、日期选择器，这些在 Chromium 里是单独的弹窗

AI 只看主页面，看不到这些弹出元素

OpenAI 的做法：强行把所有弹窗合成回主页面

这些弹窗虽然是独立窗口，但有自己的RenderWidgetHostView和AcceleratedWidget

OWL 用跟主页面一样的 delegated rendering 模型，把这些弹窗的 layer 抓出来，按正确的坐标位置合成回主页面

AI 拿到的就是一张完整的截图

还有个细节

Agent 生成的输入事件，直接发给 renderer，不走 browser 层

这样能保持沙箱边界，Agent 不能通过快捷键触发浏览器的特权操作

相关的任务，也进行了隔离

Agent browsing 可以跑在 ephemeral context 里，不共享用户的 Incognito profile

每个 agent session 用独立的StoragePartition，完全隔离

session 结束，所有 cookies 和站点数据全部丢弃

你可以同时开多个 agent session，每个都在独立的 tab 里，互相隔离

Chromium 代码库太大

checkout 要很久，编译要几个小时

OWL 把 Chromium 编译成预构建的 binary，内部分发

大部分做 Atlas 的工程师，只编译 Swift 代码，几分钟完事

OpenAI 有个工程文化：新员工第一天下午就能提交代码

对 Chromium 这种项目，这几乎做不到

但 OWL 做到了

而且因为 UI 层完全重写，对上游 Chromium 的改动很少，升级版本也容易

传统浏览器是为人设计的，Agent 浏览器要解决的问题不一样

人需要各种交互，进行辅助认知，可以点击菜单然后弹出阅读

AI 则不同，需要在一张图里看到所有元素，需要快速响应

新的浏览器架构，很有必要