Claude 终于内置浏览器，通用 Agent 为何需要「自己的浏览器」？

8 月 27 日，Anthropic 为 Claude Cowork 加入了一项此前被认为「迟早会来」的能力——内置浏览器。更新后，Claude 在桌面端侧边栏可以直接打开自己的浏览器，阅读网页、点击链接、填写表单，不再依赖 Claude in Chrome 扩展。Anthropic 对此的概括是：「很多网页任务并不需要『你的浏览器』，Claude 只需要『一台浏览器』。」

这一变化看似只是补齐一项基础功能，但若把 ChatGPT、Claude、豆包工作、千问办公、腾讯 WorkBuddy 放在一起比较，会发现一个越来越清晰的方向：真正能接管电脑工作的通用 Agent，几乎都绕不开一台「自己的浏览器」。

各家通用 Agent 的网页操作路线

目前主流通用 Agent 桌面端在浏览器能力上大致分为三条路线：

• 内置浏览器：ChatGPT 桌面端基于 Chromium 自带完整浏览器，标签页、下载、登录状态、网页注释等功能齐全；豆包工作也已内置浏览器，但目前更接近一个供 Agent 打开网页的窗口，功能尚处于初级阶段；Claude Cowork 本次更新后正式加入这一阵营。
• 浏览器插件：千问办公没有内置浏览器，但提供 Chrome 插件，需用户保持 Chrome 运行并授权后调用，官方建议网页任务优先使用浏览器自动化。
• MCP 间接控制：腾讯 WorkBuddy 本身不准备浏览器，主要通过 MCP + CLI 或 Skill + CLI 连接外部工具，常见做法是接入 Playwright 等浏览器自动化 MCP，由 Agent 间接控制本机浏览器。

三条路线背后共享一个判断：Agent 需要操作网页，但又不愿与用户争夺同一台浏览器的控制权。

为什么 Agent 需要「自己的浏览器」

插件和 MCP 方案都能让 Agent 操作网页，优势在于可以直接复用用户现有的浏览器环境——账号已登录、Cookie 有效、插件已安装，Agent 接手即可执行，同时用户也能在熟悉的 Chrome 里监督操作过程。MCP 还具备开放性，同一套接口可以连接数据库、GitHub、Notion 等内部系统。

但这种「借用」方式在高频使用中逐渐暴露出问题：

• 配置门槛：MCP 方案要求用户自行寻找、安装并配置工具，对普通办公用户而言偏离了「说一句话、等结果」的产品逻辑。
• 环境冲突：用户浏览器里通常有几十个标签页、插件和各类账号，而 Agent 更需要一个状态固定、可新建标签页、可保存任务进度的独立环境。两者抢占同一窗口时体验难以稳定。
• 依赖脆弱：Chrome 未启动、插件被禁用、权限变更、版本不兼容都可能导致 Agent 网页能力失效。千问办公官方文档即提示，浏览器自动化需要保持 Chrome 运行，登录状态过期后定时任务可能卡在登录页。

内置浏览器则把版本、权限、标签页、下载、Cookie 和任务状态交由 Agent 平台统一管理，用户无需提前安装插件，也不必确保自己的 Chrome 处于合适状态。

从「把 Agent 塞进浏览器」到「把浏览器塞进 Agent」

这一趋势的另一个参照系是 ChatGPT Atlas 的命运。2025 年 10 月，OpenAI 推出 Atlas，希望以「AI 浏览器」形态重新定义浏览器入口；不到十个月后该项目宣布停止服务，相关能力被并入 ChatGPT 与 Codex。Atlas 时代的产品逻辑是「用户打开浏览器，Agent 帮你操作网页」，而 ChatGPT 桌面端当前的逻辑已经反过来：「用户先打开 Agent，需要网页时 Agent 再打开浏览器」。

在这一逻辑下，浏览器不再是用户进入互联网的入口，而越来越成为 Agent 进入互联网的入口。

国内 Agent 的下一步

按这一逻辑推断，国内通用 Agent 桌面端大概率会走向同一条路：

• 豆包工作已先行一步，内置了供 Agent 使用的浏览器，并设计了部分人工协助机制，但基础功能仍有待完善。
• 千问办公和 WorkBuddy 当前依赖插件或 MCP 间接操控浏览器，随着任务时长和网页操作比例上升，对独立、稳定、可长期保持状态的浏览器环境的需求会越来越强，补齐内置浏览器更多是节奏问题。

更宏观地看，浏览器并不会消失，Agent 反而可能打开比人类更多的网页实例。对用户而言，浏览器会越来越像文件系统或数据库一样，藏进 Agent 的执行过程里，由 Agent 按需调用。而人类要做的，只是告诉它想完成什么。