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 的说法，这种方式实现了：
- 启动快：Chromium 在后台慢慢加载，Atlas 界面瞬间显示；
- 不崩溃：Chromium 挂了，Atlas 不受影响；
- 开发快：大部分工程师不用编译 Chromium，构建从小时级降到分钟级；
- Agent 能看清屏幕：强行把所有弹窗合成回主页面。
在项目开发上，也能做到足够的解耦，新员工第一天下午就能提交代码。
OWL 怎么做的
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，给应用的其他部分处理。
Agent mode 的特殊处理
这里的思路很巧妙。
computer use model 需要一张完整的屏幕截图。
问题来了，浏览器里有些元素是独立渲染的。
<select>下拉菜单、颜色选择器、日期选择器，这些在 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 则不同，需要在一张图里看到所有元素，需要快速响应。
新的浏览器架构，很有必要。
