OpenAI 首次公开工程领域成果 Atlas 浏览器，其核心突破在于专为 AI Agent 重构底层架构，解决了传统浏览器无法适配 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）
Atlas 的 OWL 结构
按 OpenAI 的说法，这种方式
在项目开发上，也能做到足够的解耦，新员工第一天下午就能提交代码
Atlas 和 Chromium 之间通过 Mojo 通信，这是 Chromium 自己的 IPC 系统
OpenAI 写了自定义的 Swift 绑定，让 Swift 应用能直接调用 Chromium 的接口
这里有几个核心概念：
OWL 工作示意
网页内容怎么显示？
Chromium 渲染好的 layer 通过 CALayerHost 传给 Atlas
Atlas 用 NSView 把这个 layer 嵌进界面
输入事件怎么处理？
event 的处理
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 则不同，需要在一张图里看到所有元素，需要快速响应
新的浏览器架构，很有必要
本文由人人都是产品经理作者【赛博禅心】，微信公众号：【赛博禅心】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。