从 Atlas 关停复盘：AI 应用的三种载体形态怎么选（独立应用 / 浏览器扩展 / 桌面宿主）

OpenAI 的 ChatGPT Atlas 将在2026 年 8 月 9 日正式停服。这款 2025 年 10 月 21 日登陆 macOS 的「AI 原生浏览器」，总共活了 292 天。

对开发者来说，这件事的价值不在八卦，而在于它把一个长期含糊的技术选型问题摆到了台面上：做一个 AI 应用，载体到底该选什么？

这篇把三种主流载体的工程代价拆开算一遍，最后给一份选型 checklist。

一、先看 OpenAI 自己给的答案

Atlas 停服公告里，OpenAI 提供了三条替代路径，这三条恰好就是当下 AI 应用的三种典型载体：

载体	OpenAI 的实现	官方推荐场景
浏览器扩展	ChatGPT Chrome 扩展 + 侧边栏	需要复用已有 Chrome 配置、登录态、已打开标签页、其他插件时
桌面宿主应用	新版 ChatGPT 桌面应用内置浏览窗口	轻量浏览，支持多标签页、下载、自动登录、密码管理、扩展安装
系统级控制	桌面应用的「计算机使用」能力	授权后直接控制 Safari，做自动化

注意官方措辞：桌面应用「并不是纯粹的浏览器优先体验，更像是智能助手自带的联网窗口」。这是一个很诚实的定位说明------它承认自己不打算跟 Chrome 正面竞争。

同期 Anthropic 的做法几乎一致：Claude Code 内置沙盒化的应用内浏览器（对应「桌面宿主」），同时提供 Chrome 扩展复用已登录会话（对应「浏览器扩展」）。

三家头部同时收敛到「扩展 + 宿主」双轨，这个信号对选型有参考价值。

二、三种载体的工程代价对比

2.1 独立应用（Atlas 走的路）

要自己扛的东西：

浏览器内核维护。基于 Chromium 二次开发，要跟上上游安全补丁节奏。停止维护即产生 CVE 暴露窗口------OpenAI 公告里明确写了「停止支持的浏览器产品可能会随时间暴露出漏洞」。
全套基础能力重建：书签、历史、密码管理、同步、扩展兼容层、下载管理、证书处理。
跨平台适配。Atlas 只做了 macOS，这本身就说明了投入门槛。

用户侧的迁移成本（真正的杀手）：

复制代码

用户切换成本 = 书签迁移 + 插件重装 + 登录态重建 + 密码库导入 + 同步配置

Atlas 的迁移文档暴露了这套成本有多重：

书签、历史不自动迁移 → 需导出 HTML 再手动导入 Chrome
Cookies 无法导出 → 迁移后所有站点重新登录
ChatGPT 对话记录单独存储，不受影响（唯一没坑的一项）

Cookies 导不出这一条特别关键。它意味着用户的登录态资产完全无法转移，这是独立浏览器最难跨过的那道坎------不只是搬走难，搬进来同样难。

2.2 浏览器扩展

要写的代码量最小，能力边界也最清晰。

Manifest V3 下的核心能力与限制：

javascript 复制代码

// manifest.json 关键权限声明
{
  "manifest_version": 3,
  "permissions": ["activeTab", "scripting", "storage", "sidePanel"],
  "host_permissions": ["<all_urls>"],   // 审核重点，尽量收窄
  "background": { "service_worker": "sw.js" },
  "side_panel": { "default_path": "panel.html" }
}

优势：

零迁移成本。用户现有的 profile、登录态、插件、密码库全部原样保留。
天然复用登录会话。这是 AI Agent 做网页任务时最值钱的一项------不需要用户再走一遍 OAuth。
分发走应用商店，更新是静默的。

约束：

Service Worker 会被浏览器主动回收，长任务需要靠 chrome.alarms 或外部服务续命，不能假设常驻。
无法访问本地文件系统（除非用 File System Access API 且需用户手动授权）。
跨标签页协调要靠 message passing，状态管理比桌面应用复杂。
商店审核对 <all_urls> 这类宽泛权限越来越严。

2.3 桌面宿主应用（Electron / Tauri + WebView）

定位是「AI 助手自带一个联网窗口」，不是「浏览器」。

这个区分很重要。它不追求成为默认浏览器，只需要在助手需要联网时提供一个可控环境。因此：

不需要维护完整内核，用系统 WebView（Tauri）或打包 Chromium（Electron）都行。
可以做沙盒隔离------Claude Code 的应用内浏览器就是沙盒化的，任务在隔离环境里跑，不污染用户主 profile。
能拿到本地文件系统、系统 API、剪贴板，这是扩展做不到的。
可以叠加「计算机使用」类能力，直接驱动系统上已有的浏览器。

代价：

安装包体积（Electron 通常 80MB+，Tauri 可压到 10MB 以内）。
自动更新链路要自己搭。
沙盒环境里没有用户登录态，需要任务时现登录，或者引导用户走扩展路径。

三、选型 checklist

按下面几个问题依次判断，基本能定下来：

Q1：你的功能需不需要用户已有的登录态？

需要 → 浏览器扩展（唯一能零成本复用会话的形态）
不需要 → 继续

Q2：需不需要访问本地文件、系统 API、长时间后台任务？

需要 → 桌面宿主应用
不需要 → 扩展够用

Q3：你的产品能不能创造一个 Chrome 之外的新场景？

不能 → 不要做独立浏览器
能（新设备、新交互范式、强合规隔离要求）→ 才考虑独立应用

Q4：目标用户的迁移成本谁来承担？

用户承担 → 大概率失败（Atlas 的教训）
你承担（提供完整自动迁移，含 Cookies）→ 才有戏

四、一个容易被忽略的现实约束

企业内网场景下，扩展这条路可能走不通------很多公司用组策略（Chrome ADMX）锁死了扩展白名单，ExtensionInstallAllowlist 里没有你的 ID 就装不上。这种情况下桌面宿主应用反而是唯一可行路径。

选型前先确认目标客户的 IT 管控策略，比技术对比更重要。

五、小结

Atlas 的 292 天，本质上验证了一条工程常识：在一个已经饱和的品类里做重建，成本由用户承担；在已有载体上做增量，成本由你承担。 前者听起来更有想象力，后者的成功率高一个数量级。

三家头部厂商目前的收敛结论是「扩展为主 + 宿主为辅」。这个组合不是终点，但至少是当下经过验证的最优解。