Claude内置浏览器了！豆包工作已先行，Agent终将吞噬Chrome们？|agent|chrome|插件|浏览器|网络环境

北京时间8月27日，Anthropic终于给Claude加上了一项看起来很普通的功能——内置浏览器。

最新版本上，Claude Cowork遇到需要访问网站的任务，可以直接在桌面端侧边栏打开自己的浏览器，阅读网页、点击、输入、填写表单，不再依赖Claude in Chrome扩展。Anthropic对它的描述也很直接：

很多网页任务并不需要「你的浏览器」，Claude只需要「一台浏览器」。

图片来源：Anthropic

这句话其实挺有意思。因为在今天这批通用Agent桌面端里，浏览器远没有想象中普及。

ChatGPT是少数走得比较早的。Codex桌面端此前就内置了一套基于Chromium的浏览器，后来这套能力随着Codex并入新版ChatGPT桌面端被保留下来，包括标签页、下载、登录状态和常见设置基本齐全，最近甚至加入了网页注释，让用户可以直接在页面上圈选、批注，引导AI接着干活。

国内则是另一番景象。

我最近实际体验了几款通用Agent桌面端，千问办公和腾讯WorkBuddy至今都没有内置浏览器。需要处理网页时，它们可以搜索、抓取信息，也有自己的网页操作能力，但没有给Agent准备一块完整、持续存在的浏览器环境。千问办公还提供了浏览器插件，WorkBuddy甚至需要通过配置MCP，才能操控电脑上安装的浏览器。

豆包工作倒是已经把浏览器塞进去了，只是目前相当简陋，更接近一个供Agent打开网页的浏览窗口，离ChatGPT那套完整的浏览器体验还有明显距离。

图片来源：雷科技

Claude原本也属于前一类。过去Claude Cowork想真正操作网页，主要依靠Claude in Chrome浏览器插件，把控制能力伸进用户已经打开的Chrome。现在Anthropic干脆自己带了一台浏览器。

看起来，各家只是又补齐了一项功能。但如果把ChatGPT、Claude、千问办公、WorkBuddy和豆包工作摆在一起，会发现一个越来越难绕开的问题：一个想要真正接管电脑工作的通用Agent，是否一定需要自己的浏览器？

在ChatGPT之后，豆包和Claude也都给出了答案。

过去，Agent都靠「借用」本机浏览器

Agent操作浏览器「干活」已经不是什么新鲜事，但往往还需要「借」用户的浏览器。

Claude此前依赖Claude in Chrome。用户安装Chrome插件并授权之后，Claude Cowork或Claude Code就能进入正在使用的Chrome，读取页面、点击链接、输入文字、跨标签页工作，遇到需要登录的网站，也可以直接利用用户现成的登录状态。

千问办公也差不多。桌面端虽然没有自己的浏览器，但提供了浏览器插件。用户开启相关扩展并保持Chrome运行，千问就能调用浏览器完成点击、输入和信息采集。官方甚至明确建议，碰到网页任务时优先使用浏览器自动化，因为相比直接操控整台电脑，它更快、更精准。

图片来源：雷科技

WorkBuddy更「工程师」一点。它本身没有准备浏览器，连接外部工具主要依靠MCP。腾讯官方将WorkBuddy的连接器定义为MCP + CLI或Skill + CLI，用户也可以自行配置MCP Server。真要让它操作网页，其中一种常见做法，就是接入Playwright之类的浏览器自动化MCP，让Agent间接控制电脑上的浏览器。

思路其实差不多。Agent没有浏览器，就想办法借一台。

这种做法最直接的好处就是，可以复用用户已经使用的浏览器。账号登录好了，Cookie在，插件也装好了，网页就在眼前，Agent接手之后马上就能干活。尤其是企业后台、邮箱或者其他高度依赖登录状态的网站，重新在另一台浏览器里登录一次，本身就是额外成本。

用户也更容易监督。Agent点击了什么、填了什么，基本都发生在熟悉的Chrome里，发现不对随时可以接管。

MCP还有一个优势——开放。今天给WorkBuddy接Playwright，明天还可以继续接数据库、GitHub、Notion和内部系统，Agent不需要为每一种能力重新设计一套接口。这也是MCP速成为Agent基础设施的重要原因。

图片来源：雷科技

但到了真正高频使用的时候，「借浏览器」的问题也慢慢暴露出来。

首先是麻烦。Claude和千问至少还准备好了插件或连接器，WorkBuddy这类MCP方案往往还需要用户自己寻找、安装和配置工具。对于开发者，这几步算不上门槛；对普通办公用户，就已经偏离了「告诉Agent一句话，然后等结果」的产品逻辑。

此外，人的浏览器和Agent的浏览器，本来就有不同需求。

人类的Chrome里塞着几十个标签页、插件、历史记录和各种账号，随时还可能被本人拿回来继续工作。Agent执行一个半小时的任务，却更希望浏览器环境固定、状态可控，可以随时新建标签页、下载文件、维持登录，失败之后还能知道刚才进行到了哪里。

两个人抢一把方向盘，当然能开，体验很难做到稳定。

更现实的问题还有依赖。Chrome没启动、插件被禁用、权限没开、版本不兼容，Agent的网页能力都可能直接失效。千问办公的官方文档就特别提醒，浏览器自动化需要保持Chrome运行，登录状态过期后，定时任务也可能卡在登录页面。

所以在合并之前，Codex很早就换了一条思路，既然Agent天天都要用浏览器，那就自己带一台。

豆包工作、Claude也走到了这里。

内置浏览器之后，浏览器的版本、权限、标签页、下载、Cookie和任务状态都可以由Agent平台统一管理。用户不需要提前安装插件，也不用保证自己的Chrome正好处于合适状态。需要网页时，Agent自己拉起浏览器，干完再继续后面的任务。

就像Anthropic介绍这次Claude更新时说的：有些任务确实需要「你的浏览器」，但更多任务只需要「一台浏览器」。

当然，现阶段还不存在「非此即彼」。Claude加入内置浏览器的同一天，也正式扩大了Claude in Chrome的使用范围。ChatGPT已经有了完整的内置浏览器，同样继续保留Codex Chrome扩展。

插件负责接管「我的浏览器」，内置浏览器负责给Agent一台「自己的浏览器」。当通用Agent开始真正接手工作，后者迟早都会需要。

浏览器将被豆包工作们彻底「吞掉」？

Claude这一步早晚都会来。

就在上月，OpenAI宣布关停ChatGPT Atlas（AI浏览器），我们的判断是，AI浏览器这条产品路线正在遇到一个很尴尬的问题——Agent发展得太快，已经开始把浏览器本身「吞」进去。

Atlas就是最典型的例子。2025年10月，OpenAI发布Atlas，希望重新思考浏览器。不到十个月后，它就宣布停止服务，原本属于Atlas的浏览器智能体能力随后被转移到ChatGPT和Codex。

在Atlas时代，逻辑还是把Agent塞进浏览器：用户打开浏览器，Agent帮你理解网页、操作网页、完成任务。到了Codex，再到今天的ChatGPT桌面端，顺序已经反了过来：

用户先打开Agent，需要网页时，Agent再打开浏览器。

我最近使用ChatGPT桌面端时，这种感觉已经相当明显。内置的Chromium并不只是一个临时网页窗口，常见的标签页、刷新、下载、登录和基础设置基本都有，用户真有需要，完全可以把它当一台正常浏览器使用。

图片来源：雷科技

但大部分时候，我其实不需要。让ChatGPT找资料、进入网站、操作后台或者完成一项网页任务时，浏览器只是执行过程中的一个窗口。真正需要我介入的时候，再打开看看它做到哪一步，或者直接接管。

最近加入的网页注释更有意思。用户可以在页面里圈出某一块内容、留下指示，再让AI接着处理。浏览器在这里越来越像Agent的工作台和人与Agent之间的交接界面。

这和传统浏览器的使用逻辑已经有很大距离。

过去，我们自己搜索、打开网页、切换标签页、比较信息，再填写表格；Agent接手之后，这些动作开始被压进后台。用户看到的越来越多是任务和结果，网页只在必要的时候出现。

浏览器最自然的位置是在Agent平台内部，按需出现。

这并不意味着浏览器没有价值。恰恰相反，在API、MCP还没有覆盖整个互联网之前，浏览器可能是Agent最重要的基础设施之一。

现实中的大量网站仍然围绕人设计。登录、验证码、复杂后台、动态页面、上传下载、支付，都离不开完整浏览器环境。Agent可以优先调用API，可以走MCP，也可以直接获取结构化网页数据，但遇到这些「老互联网」留下来的界面，最后还是要打开Chromium，像人一样点击、输入和提交。

区别在于，浏览器越来越不需要人主动打开。

从这个角度看，国内几个通用Agent桌面端大概率逃不开同一条路。豆包工作其实已经先走了一步，内置了浏览器给Agent直接使用，也有一定的人工协助设计，只是功能还很初级，更多承担「把网页打开给Agent」的作用。大胆预测，接下来的更新中，都豆包还会进一步完善补齐浏览器的基础功能，以及更自然的人机协作。

千问办公和WorkBuddy的问题更加直接。浏览器插件和MCP完全可以让Agent操作网页，但随着任务变长、网页操作变多，Agent对一个稳定、独立、可以长期保持状态的浏览器环境的需求只会越来越强。