Chrome 144 与 MCP：修复断开的连接并突破 AI Agent 局限的方法

Anthropic 提出的 Model Context Protocol (MCP) 彻底改变了 AI Agent 与浏览器交互的方式。然而，一线的工程师们还没来得及庆祝就撞上了南墙。这是因为 Chrome 144 版本出于安全考虑，封锁了自动化的核心路径。

除了简单的连接错误，企业级 AI Agent 面临的真正挑战是安全与性能之间的平衡。我们需要的不仅是“能运行”的代码，而是能够经受住业务现场考验的架构。

---

安全阻断的自动化：Chrome 144 的变化

首先要解决的问题是消失的 API。Chrome 144 移除了原先自动化工具在寻找浏览器实例时使用的 HTTP 发现 API (/json/version)。这就是为什么 Agent 会抛出 404 错误并停止运行的原因。

现在，我们不能再指望自动获取路径，而必须直接构建 WebSocket URL。唯一的解决方案是通过读取 DevToolsActivePort 文件来强制指定端口的“手动连接”方式。此外，Google 在连接 MCP 服务器时强制要求用户确认弹窗。对于追求无人值守自动化的团队，必须从头开始重新设计权限方案。

---

防止会话劫持的设备绑定凭据 (DBSC)

让 AI Agent 直接继承用户的 Cookie 和认证会话是安全团队的噩梦。Agent 的漏洞可能直接导致全公司的数据泄露。

真正的解决方案在于 设备绑定会话凭据 (DBSC) 技术。这项技术将从 Chrome 145 (Windows) 和 147 (macOS) 开始正式引入，它将会话 Cookie 物理性地锁定在特定的硬件上。即使 AI 泄露了 Cookie，在其他设备上也是无效的。

实战隔离策略：

• 物理配置文件隔离： 通过 --user-data-dir 标志为每个 Agent 分配独立的存储空间。
• 构建会话注册表： 利用 chromectl 等工具集中管理各会话的端口，从源头上杜绝认证状态的相互干扰。

---

性能基准：为什么选择 Playwright MCP

在大规模部署环境下，MCP 服务器的资源占用率直接关系到成本。以 Antigravity IDE 为例，如果为每个工作区创建独立进程，会导致在闲置状态下也有数十个进程消耗数 GB 内存的进程爆炸现象。

工具选择	技术基础	Token 消耗效率 (基于 200k)	推荐用途
Playwright MCP	可访问性树 (Accessibility Tree)	消耗 ~6.8%	成本优化及高速自动化
Chrome DevTools MCP	CDP 全协议	消耗 ~9.5%	深度调试及 UI 测试

Playwright MCP 拥有压倒性效率的原因很明确：它不读取杂乱的完整 DOM，而是仅提取屏幕阅读器识别的核心信息。如果你想降低成本，请选择这种基于可访问性树的 Agent。

---

引入自愈 (Self-healing) 逻辑

网页就像生物一样。哪怕只是一个按钮 ID 发生变化，传统的脚本就会失效。必须让 Agent 学习 三层分级修复框架：

1. 基础定位器尝试： 首先尝试原有的 CSS 或 XPath。
2. 启发式搜索： 失败时不调用 LLM，而是通过文本相似度或父子关系推测，以零成本寻找元素。
3. 基于 AI 的重新识别： 仅在最后阶段将 DOM 快照传递给 Gemini，寻找符合意图的元素并生成自动更新代码的修复报告 (Healing Report)。

常见的错误是盲目地重复使用用户数据目录。在缓存膨胀到数十 GB 之前，请务必使用 --disk-cache-size=104857600 标志限制在 100MB，并配合在会话结束时删除追踪数据的脚本。

---

企业级部署最终检查清单

若要在组织内安全地运行 MCP，必须坚持权限最小化原则。请在 mcp_config.json 中管理白名单，而不是允许所有域名。

http://googleusercontent.com/immersive_entry_chip/0