「套殼」的最高境界：OpenAI揭秘Atlas瀏覽器架構OWL

機器之心報道

編輯：Panda

「又一個 Chromium 套殼？」

面對 OpenAI 上周發布的 AI 瀏覽器 Atlas，這可能是不少人的第一反應，參閱報道《剛剛，OpenAI 發布 AI 瀏覽器 ChatGPT Atlas，基于 Chromium》。但今天，OpenAI 官方用一篇技術博客「回懟」了這個說法：我們「套」了，但和別人完全不一樣。

盡管今天還有 Sora 角色客串功能和 GPT-5 查找和修復安全漏洞智能體的消息，但本文的重點是深扒 Atlas 背后的「靈魂」——OWL 架構?？纯?OpenAI 究竟是如何馴服 Chromium，把它從瀏覽器「換皮」玩成了「架構重組」的。

基礎是 Chromium

OpenAI 表示，要讓 ChatGPT 成為網頁瀏覽的真正副駕駛，必須徹底重構瀏覽器的底層架構：將 Atlas 與 Chromium 運行時剝離開來。這意味著要開發一種全新的 Chromium 集成方式，如此才能滿足以下三個關鍵目標：

• 秒級啟動速度
• 打開更多標簽頁時依舊流暢
• 為智能體（Agent）場景打下堅實基礎

OpenAI 強調，Chromium 是一個天然的構建基石。它能提供先進的網頁引擎、完善的安全模型、一流的性能，以及卓越的網頁兼容性；更重要的是，它由全球開發者社區持續改進。因此，它成為了現代桌面瀏覽器最常用的底層引擎。

重新定義瀏覽器體驗

雖然基于 Chromium，但 OpenAI 自然也會強調自己的設計，包括在「Agent 模式」等功能中引入豐富的動畫和視覺效果。

這要求工程團隊使用最現代的原生框架（如 SwiftUI、AppKit 和 Metal），而不是簡單地給開源的 Chromium 界面「換皮」。

結果，OpenAI 表示：「Atlas 的用戶界面幾乎是從零重建的一整套全新體驗。

另外，為了實現快速啟動和支持上百個標簽頁同時運行而不掉幀的目標。還需要對 Chromium 進行一些優化，畢竟其默認架構在啟動流程、線程模型、標簽管理等方面都非常「固執」。

OpenAI 說：「我們考慮過大幅修改 Chromium，但那樣會讓后續更新復雜且脆弱。為了保持開發速度，我們選擇了一條更巧妙的路 —— 重新設計 Chromium 的集成方式?！?/p>

他們的一個關鍵的技術標準是：不僅要加快功能實驗、迭代和上線的節奏，還要保留 OpenAI 的工程文化 —— 第一天就能上線代碼?！该课恍鹿こ處熑肼毜谝惶煜挛缇鸵峤徊⒑喜⒁粋€小改動。即便 Chromium 的源碼編譯要花幾個小時，我們也得保證這一傳統能延續?！?/p>

OpenAI 的解決方案：OWL

為了解決這些挑戰，OpenAI 構建了一個新的架構層，稱為OWL（OpenAI’s Web Layer）

OWL 是 OpenAI 整合 Chromium 的方式，其核心理念是：讓 Chromium 的瀏覽器進程獨立運行在 Atlas 主應用進程之外

可以這樣理解：Chromium 通過將每個標簽頁放入獨立進程來革新瀏覽器架構；而 OpenAI 更進一步 —— 把整個 Chromium 從主應用進程中分離出來，放入一個獨立的服務層。

如此方法好處多多：

• 更簡潔現代的應用：Atlas 主要使用 SwiftUI 和 AppKit 構建，統一語言、統一技術棧、代碼干凈。
• 更快啟動：Chromium 會在后臺異步加載，Atlas 幾乎瞬間顯示畫面。
• 隔離崩潰與卡頓：即使 Chromium 出問題，Atlas 也不會掛。
• 更少的合并沖突：OpenAI 修改的 Chromium 代碼極少，易于維護。
• 更快的開發節奏：大多數工程師無需本地編譯 Chromium，OWL 內部以預構建二進制形式分發，Atlas 構建只需幾分鐘。

因此，即使是新員工，也能在第一天下午輕松提交改動。

OWL 的工作方式

從高層來看，Atlas 瀏覽器是 OWL 客戶端，而 Chromium 瀏覽器進程是 OWL 主機（Host）。兩者通過 Mojo（Chromium 的進程間通信系統）進行通信。OpenAI 編寫了 Swift（甚至 TypeScript）的 Mojo 綁定，使 Swift 應用能直接調用主機端接口。

OWL 客戶端庫提供了一套簡潔的 Swift API，用于抽象主機層的關鍵功能：

• Session：全局配置與控制
• Profile：管理用戶瀏覽數據
• WebView：渲染、輸入、導航、縮放等
• WebContentRenderer：將輸入事件傳遞給渲染管線
• LayerHost/Client：在 UI 與 Chromium 之間交換合成信息

此外，還提供書簽、下載、擴展、自動填充等服務端點。

渲染：跨進程傳遞像素

WebView 在客戶端應用中共享一個合成容器，不同標簽頁的內容會動態交換顯示。在 Chromium 一側，這對應于一個 gfx::AcceleratedWidget，由底層的 CALayer 支撐。

OpenAI 的設計是將該層的上下文 ID 暴露給客戶端，由 NSView 通過私有的 CALayerHost API 嵌入。

諸如 下拉框或顏色選擇器等獨立彈窗，也采用相同機制。OWL 會保持視圖幾何與 Chromium 同步，確保 GPU 合成器輸出正確分辨率和比例的內容。 下拉框）會在標簽頁外單獨渲染。在 Agent 模式下，OpenAI 會將這些彈窗重新合成為主頁面的一部分，讓模型在一幀中看到完整的上下文。

OpenAI 也借用這種機制，將 Chromium 原生界面的一部分直接投射到 Atlas 中，比如權限提示框，從而快速實現功能原型而無需完全重寫。

輸入事件：捕獲與轉發

通常，Chromium UI 會將 macOS 的 NSEvent 轉換為 Blink 的 WebInputEvent，然后再傳遞給渲染器。

但由于 OWL 中 Chromium 在后臺運行，OpenAI 在 Swift 客戶端中自己完成事件轉譯，再將轉換后的事件發給 Chromium。

如果網頁未處理某個事件，系統會把事件返回客戶端，OpenAI 重新生成 NSEvent，讓 Atlas 其他部分接管輸入處理。

Agent 模式：特殊情況

Atlas 的智能體瀏覽對渲染、輸入和數據存儲提出了額外挑戰。OpenAI 的計算機使用（computer use）模型需要屏幕的完整圖像作為輸入。

但有些 UI（如

輸入事件同樣遵循安全原則：Agent 生成的事件直接傳給渲染器，不經過特權瀏覽器層，以確保沙箱隔離。例如，防止自動化事件觸發系統快捷鍵等非網頁行為。

此外，Agent 瀏覽可以在臨時「登出」上下文中運行。它不會使用用戶的隱私模式配置，而是借助 Chromium 的 StoragePartition 創建獨立的內存存儲。每個 Agent 會話都是全新的，結束后所有 cookie 和數據都會被清除。用戶可以同時運行多個互不干擾的「登出」 Agent 會話。

結語

OpenAI 最后再次重申了 Chromium 的作用：「如果沒有全球 Chromium 社區的卓越貢獻，這一切都無法實現。OWL 在此基礎上開辟了新的方向：將引擎與應用解耦，結合頂級網頁平臺與現代原生框架，打造更快、更靈活的架構。」

對此，你怎么看？

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