最近发布的 Chrome 146 浏览器版本（Google Chrome 第146个主版本更新）带来了一项看似不起眼、但可能深刻影响 AI Agent 发展的能力：
浏览器开始原生支持通过 MCP 接口控制当前浏览器会话。
简单来说，这意味着 AI 可以直接操作你正在使用的 Chrome 浏览器，而不需要再启动专门的自动化浏览器或重新登录账户。
对于很多开发 AI Agent、自动化助手或 AI 浏览器工具的人来说，这可能是一个非常重要的变化。
在 Chrome 146 之前，如果开发者希望 AI 自动操作网页，一般只能用两种办法。
Headless 浏览器就是 没有界面的浏览器，常见工具包括 Puppeteer、Playwright 等。
AI 可以控制这些浏览器访问网页、点击按钮、填写表单等。
但问题是：
因此这种方式在很多真实业务场景里并不好用。
另一种办法是把 用户真实浏览器里的 Cookie、Token 复制到自动化浏览器里。
这样 AI 可以假装已经登录。
但这个方案也很麻烦：
很多开发者为了解决这些问题，还专门写插件或中继服务来桥接浏览器能力，但稳定性一直不理想。
Chrome 146 带来的变化是：
AI Agent 可以直接连接你正在使用的 Chrome 浏览器，并操作当前会话。
开发者只需要打开浏览器里的一个调试开关：
chrome://inspect/#remote-debugging
开启之后，AI Agent 就可以通过 Chrome DevTools Protocol（CDP） 或 MCP 接口控制浏览器。
关键区别在于：
这意味着 AI 可以：
开发者 Petr Baudis 做了一个很直观的演示。
他让 Claude AI 连接自己的 Chrome 浏览器，然后执行一个任务：
清理 LinkedIn 上那些推销产品的连接邀请。
AI 的操作流程是：
整个过程使用的是 他已经登录的 LinkedIn 会话，不需要任何额外认证。
Chrome 146 的这个能力，实际上解决了 AI 浏览器自动化的几个核心问题。
AI 可以直接使用你当前浏览器里的登录状态。
比如：
都可以直接操作。
因为 AI 操作的是 真实浏览器，不是自动化工具。
很多网站原本会检测：
现在这些检测更难触发。
很多以前难做的任务现在变得更容易，例如：
这些场景过去经常被登录、验证或反自动化机制卡住。
让 AI 操作真实浏览器，其实也有风险。
例如：
因此很多人认为未来必须有：
否则 Agent 权限过大会带来安全隐患。
目前有开发者已经为这一能力做了优化工具，例如：
chrome-cdp-skill
https://github.com/pasky/chrome-cdp-skill
安装方法：
npx skills add https://github.com/pasky/chrome-cdp-skill
一些 AI Agent 框架也在跟进支持，例如 OpenClaw。
如果浏览器操作能力变得更高效，未来 AI 执行网页任务的 token 消耗也可能明显下降。
对大语言模型来说，使用浏览器一直是最重要的能力之一。
很多真实任务都离不开网页操作，例如：
Chrome 146 的这个更新，让 AI 第一次可以比较自然地接管真实浏览器环境。
对于 AI Agent、自动化助手以及 AI 浏览器产品来说，这可能是一个非常重要的基础设施变化。