AI 的三个浏览器，用哪个比较好：in-app Browser、DevTools MCP、真实 Chrome

持续分享 AI Engineering 学习笔记与实践经验，涵盖 AI Coding、AI Agents、MCP、工作流、开源工具及开发实战。

https://github.com/gdutxiaoxu/ai-engineering-learning

让 AI 帮你开浏览器，你大概碰到过这三个：Codex 自带的 in-app Browser、Chrome DevTools MCP、还有"连上你自己的 Chrome"。

名字都带浏览器，干的事可完全不一样。很多人把它们当成一个东西的三个版本，其实不是。

最常见的翻车：让 in-app Browser 去开你登录过的后台，开半天打不开，还以为是工具坏了——其实是用错了。用错工具，轻则白忙活，重则把账号搭进去。

我挨个把它们过了一遍，最大的感受：别拿一个工具去干仨工具的活。

先看一张表

工具	最擅长	最大限制	风险	token
in-app Browser	本地预览、免登录页验证	登不进去	低	活儿轻，偏少
Chrome DevTools MCP	看报错 / 网络 / 性能	默认隔离，不碰你日常 Chrome	中	全家桶偏多，--slim 少
连上真实 Chrome	已登录页面、内网、扩展	风险最高	高	看你怎么用

差别不在强弱，在分工。

一样的地方

先说一样的地方，省得你以为它仨没关系。

都是给 AI 用的，都能让 AI 看见页面、动页面。

最基础的几样都会：开页面、跑段脚本、截图。

还有一条一样的：能力越大，token 烧得越多、风险也越大。

它仨长得像，脾气可完全不同。光看"能不能打开网页"，分不清谁是谁。不一样的地方，才是重点。

in-app Browser：就是给你和 AI 一块儿看页面的

说白了，它是一个内置的、干净的预览窗口。你在本地起个服务，比如 localhost:3000，让它看页面长啥样，最合适。

它跟你平时那个 Chrome 是隔开的，不碰你的账号、不碰你的历史，所以拿它跑本地页面，心里踏实。

但它有个硬伤，也是它跟另外两个最大的不同：登不进去。

你 Chrome 里的登录状态、cookie、扩展、开着的标签页，它一概没有。我翻过官方 issue，说得很清楚：登录态、profile、扩展，in-app browser 现在都不支持。

所以别指望用它进你已登录的 Gmail、公司后台，那不是它该干的。

Chrome DevTools MCP：别拿它当"更强的点击器"

这个被误解最深。很多人以为它是"更会点页面的浏览器"，拿它去填表单、点点点。

它真正能干的，是把 Chrome 那套调试工具交给 AI：看 console 报错、看网络请求、看性能、跑 Lighthouse、查内存。

做前端的都懂，这些以前得自己按 F12 一项一项翻；现在能让 AI 替你翻，还翻得比你快。

举个例子，页面白屏了，它能直接帮你扒出来：是哪个请求挂了、哪段 JS 报错了、首屏卡在哪——这些靠"点"是点不出来的。

跟另外两个比：比 in-app Browser 强，是它能看见页面内部；比真实 Chrome 克制，是它默认用一个干净的隔离 profile，不碰你平时那个 Chrome。

两个小细节：默认就是隔离的临时 profile，除非你指定 --userDataDir；要是只让它干点最基础的活（开页面、跑脚本、截图），别用全家桶，加个 --slim，只留 3 个工具，省 token。这个开关挺值，知道的人不多。

连上真实 Chrome：唯一能登进去的，也最危险

有些活，前两个都干不了：进你已登录的 SaaS、公司内网、用你的某个扩展、或者你和 AI 接力操作同一个页面。

这时候才轮到真实 Chrome。

两条路：一条是 Codex 的 Chrome 扩展，能用你的登录状态，还能设白名单黑名单、审批能访问哪些站；另一条是用 --autoConnect、--browser-url 或者远程调试端口，接上你正在用的 Chrome。

代价就是风险最高，下面说。

两个容易忽略的地方：token 和安全

光看能力还不够。有两个点，三个工具差很多，但特别容易被忽略。

token

• in-app Browser：活儿轻，token 也少。
• Chrome DevTools MCP：全家桶的工具说明都塞进上下文，费 token；换 --slim 只留 3 个工具就省。
• 真实 Chrome：完全看你怎么用。

但有个通用的省法：像查数据库一样，只取你要的字段，别一股脑全捞。

让 AI 跑个 evaluate，只返回一个"是/否"、一个数字，最省；读一小段文字也还行。反过来，让它把整页的 DOM、innerHTML 全捞回来，光这一下就比只回一个"有/没有"贵得多——一个复杂页面上万个节点，全塞进上下文，直接爆；截图最贵还忽高忽低，别动不动就截。

我的习惯：先 evaluate 拿关键值，再读局部文字，不行才上 snapshot，最后才截图。

安全

• in-app Browser：隔离的，风险低。
• Chrome DevTools MCP：默认隔离 profile，中等。
• 真实 Chrome：风险最高。

真实 Chrome 这层最容易让人大意，尤其是那个远程调试端口。

记住一句话：远程调试端口，不是普通的网页权限，是能彻底控制浏览器的级别。 它本身不查你是谁，谁连上谁就能读你的 cookie、读你的密码、往页面里塞代码。

你想啊，你浏览器里登着邮箱、网银、公司系统，这个口子要是被别的程序接上，等于把整台浏览器连账号一起交出去了。

别以为只绑了 127.0.0.1 就没事，你电脑上随便哪个程序都能连上去接管你的浏览器。能用 --remote-debugging-pipe（走管道、不开网络口）就别老开着 9222。

扩展也一样，别图省事一直点"允许"，按网站、按任务来授权。宁可每次多确认一下，也别图一时省事。

那到底用哪个

说了这么多，落到实际就三条线：

• 本地预览、不用登录的页面：in-app Browser。
• 排错、看网络、看性能：Chrome DevTools MCP。
• 要登录、进内网、用扩展：真实 Chrome。

会用 AI 开浏览器，不是找出最强的那个，是知道每个能干啥、不能干啥。

参考来源：

• Codex in-app Browser：https://developers.openai.com/codex/app/browser
• Codex Chrome extension：https://developers.openai.com/codex/app/chrome-extension
• Chrome DevTools MCP：https://github.com/ChromeDevTools/chrome-devtools-mcp
• Chrome 远程调试安全更新：https://developer.chrome.com/blog/remote-debugging-port