Chrome DevTools for Agents：为编码智能体构建闭环反馈

在 Google I/O Connect 的一场演讲中，Chrome 团队的 Matthias 深度拆解了 Chrome DevTools for Agents 这一新工具。它的核心命题很直接：过去二十年，人类开发者靠 DevTools 建立起「检查—调试—修复」的闭环反馈，而编码智能体（coding agent）却几乎从未碰过这套工具。Chrome 团队认为，把 DevTools 的能力开放给智能体，能让它们享受到人类开发者一直依赖的同一套反馈循环。

为什么智能体需要 DevTools

演讲用一个具体案例点明了问题所在。假设有一个使用内部认证服务 Showtime 的注册表单，注册失败时只返回类似「app error 1003」的模糊报错。这个服务没有公开文档，任何模型的训练数据里都不会有它。

此时普通的编码智能体会陷入死胡同：它依赖你手动定位问题，即便你直接提示「修复 signup form 里的 app error 1003」，它也只能在代码库里搜索这个错误码，然后大概率开始「打转」（spiral）——运气好的话找到一句「TODO：处理特定错误码」的注释，仅此而已。

真正的答案既不在训练数据，也不在源代码，而在运行时数据里。当表单提交时会向 API 发出请求，而所有网络请求都会在 DevTools 的 Network 面板中呈现。检查那个失败请求的响应预览，就能看到一条可以用来给用户更明确提示的附加信息。DevTools for Agents 做的，就是把这类运行时信息开放给智能体。

改一下提示词——不再让智能体去看具体文件，而是让它去看运行时。由于 DevTools for Agents 能访问 source map，它会打开一个真实的 Chrome 实例、尝试登录、捕获控制台日志和网络请求，再把这些线索组合起来，完成一次端到端的自动修复。这就是闭环反馈的价值。

底层架构：站在 Puppeteer 和 Chrome for Testing 的肩膀上

DevTools for Agents 虽是新面孔，底层却建立在 Chrome 团队多年维护的成熟工具之上——Chrome for Testing 与 Puppeteer。

它本质上是一个 NPM 包，可以安装在任何装有较新 Node.js 版本的机器上。你的智能体（无论是 Antigravity、Claude Code、Codex 还是其他）可以通过两种方式调用它：MCP server 或 CLI，二者都随同一个 NPM 包发布。其中 CLI 允许智能体对 DevTools 进行脚本化操作，相比 MCP server 更节省 token。

把这一切串起来的第三个关键，是一套 skills，用于教会智能体「何时」以及「如何」使用 DevTools for Agents。目前共内置六个 skill，大致分两类：一类（如 Chrome DevTools、CLI skill）讲解核心概念和通用用法；另一类（无障碍调试、内存泄漏调试、LCP 优化）则封装了特定领域的专家知识，让智能体在该领域也具备专家水平。

真正与 Chrome 通信的层是 Puppeteer。了解这一层还有助于评估安全边界。演讲特别澄清了一个常见疑问：DevTools for Agents 不能访问 Chrome 密码管理器里保存的密码——因为它不像人类用户那样使用 Chrome，而只调用经过验证的 Puppeteer skill，而 Puppeteer 并不暴露密码管理器；此外它默认使用一个独立的匿名浏览器配置文件，本身就没有保存任何密码。

Puppeteer 是 Chrome 团队维护的 Node.js 库，通过 Chrome DevTools Protocol（CDP）以编程方式控制 Chrome 或 Chromium 浏览器，常用于自动化测试、爬虫和截图生成。Chrome for Testing 则是 Chrome 团队专门为自动化场景发布的独立 Chrome 构建版本，与用户日常使用的 Chrome 分开维护，保证版本固定、行为可预期，避免自动更新破坏测试流程。Source map 是一种将经过压缩、打包或转译的生产代码映射回原始源代码的文件，DevTools for Agents 借助它能在运行时定位到真实的源文件行号，而不是面对一堆混淆后的变量名。MCP（Model Context Protocol） 是 Anthropic 提出的开放协议，允许 AI 模型以标准化方式调用外部工具和数据源；以 MCP server 形式暴露能力，意味着任何兼容该协议的智能体都可以直接接入，无需针对每个智能体单独适配。

三类典型用例

智能体并不直接调用 Puppeteer API，Chrome 团队把关键能力包装成一组描述清晰、易于智能体消费的工具，共分六类。演讲展示了三个跨类别组合的用例。

第一个是前述的表单调试与自我验证，结合了输入自动化、网络与导航自动化工具——智能体导航到页面、填写表单、修复底层错误，并验证自己的修复。

第二个是一次性 bug 验证，结合模拟工具（改变视口尺寸）和调试工具（截图）。比如收到「并非所有导航项在各屏幕都显示」的报告时，可以提示智能体在桌面、平板、移动三种视口下检查导航项是否都可见。智能体会打开 Chrome，逐一切换视口、截图、在移动端点开汉堡菜单交互，最后返回一份完整答案——把三种视口和嵌套菜单的测试流程完全自动化。

第三个用例是扩展你的专业能力。如果你对性能、无障碍或 SEO 不熟悉，泛泛地提示「改进这个项目的性能」，智能体往往只会缓慢地通读项目文件、烧掉 token，随机修复一些未必影响性能的问题。而借助 DevTools for Agents 专门的性能 trace、无障碍、最佳实践、SEO 审计工具，它可以实测已知问题，而非从源代码里猜测——例如「跑一次性能 trace，针对所有发现采取行动」，从真正重要的地方入手。

此外，演讲还提到与调试互补的 Modern Web Guidance：一套涵盖 Chrome 现代 Web 最佳实践的 skill。演示中同一个明暗模式切换组件，不用它时 AI 会用 JavaScript 处理状态、动画和定位；用它时，智能体会选用 CSS starting styles、anchor positioning、light-dark() 等现代原语，最终产物仅 2.6KB 且零 JavaScript。

PAIR 的 10 倍效率案例

零散的一次性提示已经很有用，但 DevTools for Agents 真正发光是在被默认纳入工作流之后。来自德国汉堡的合作伙伴公司 PAIR 就是范例——他们把交付速度提升了 10 倍，从原来每周一次发布变为每天多次为客户项目部署。

他们的做法是打造了 14 个高度专门化的 skill。例如 review code skill 指示智能体做极其严格的本地代码审查；Figma validate skill 让智能体迭代地将实现与 Figma 原稿对齐；GitHub issue test skill 则教智能体如何验证 GitHub issue 中记录的工作。

以 GitHub issue test skill 为例，它在定义任务与角色（资深软件工程师）后，把测试流程拆成四个阶段：问题分析与状态检测、制定计划、在真实浏览器中执行、最后汇报。这个 skill 长达 120 多行，其中第三阶段还预设了三种情景——A：Chrome DevTools MCP 可用；B：不可用；C：需要更省 token。通过显式给出后备方案，智能体在计划 A 失败时能退回 B 或 C，而不至于「跑偏」乱做一通。

从中可以提炼三条最佳实践：精确引导（明确说明要做什么、怎么做，甚至点名具体工具）、简化执行（为智能体铺好路，比如提供绕过登录屏障的快捷 JS 工具，避免它每次重复搜索或实现同一件事）、要求验证（指示智能体不跳步、通过反复快照检查自己的工作，否则容易半途而废）。

PAIR 案例展示的本质是把「反馈回路」制度化：与其每次临时提示智能体「检查一下浏览器里有没有问题」，不如把检查标准和执行路径固化到 skill 文件里，让智能体每次都按同一套高标准行事。这与软件工程中 CI/CD 流水线的理念一脉相承——把人工判断转化为可重复执行的自动化检查。14 个专门化 skill 还体现了「职责分离」原则：代码审查、视觉对齐、issue 验证各自独立，智能体在每个环节都有明确的成功标准，避免了通用提示词导致的目标模糊问题。值得注意的是，skill 中显式预设多条执行路径（A/B/C fallback）本质上是在用结构化提示工程（structured prompt engineering）弥补大语言模型的脆弱性——模型在工具不可用时若没有明确后备指令，往往会静默失败或产生幻觉式输出。

配置与 AutoConnect

DevTools for Agents 开箱即用，但也提供配置项。MCP server 用户在对应的配置文件（Gemini CLI 通常是 .gemini/settings.json，Claude 可能在项目根目录的 .mcp.json）的 args 数组中添加选项即可；CLI 用户则需在提示里显式包含选项。你可以指定连接非 stable 的 Chrome 通道，或开启诸如第三方工具支持这类实验性功能。

最值得关注的是 AutoConnect——可以理解为「把屏幕共享给智能体」。它允许智能体连接到一个已经运行的 Chrome 实例，从你当前所在的状态直接接手。回到最初的注册例子：如果错误已经明晃晃地摆在你面前，何必再写一段提示让智能体重现同样的状态，甚至手动复制粘贴控制台报错？开启方式很简单：进入 Chrome Inspect，在侧栏选 Remote Debugging，勾选「允许远程调试」，再在配置或提示中启用 AutoConnect。

但演讲反复强调同一条安全告诫：谨慎决定给智能体的访问权限。使用 AutoConnect 时，若连接的是你的个人 Chrome 配置文件而非默认匿名文件，个人数据将面临风险——一句「去 google.com shopping 下单 999 个气球」很可能真的成功执行并产生意外费用。

如何上手

Chrome 团队提供了面向 20 多个编码智能体的安装说明与深度文档（developer.chrome.com），以及 YouTube 上的设置教程（google/DTA-setup）。作为开源项目，欢迎在 GitHub（google/DTA-repo）贡献。此外，DevTools UI 内的 AI 辅助面板也升级为 Gemini 3 Flash 驱动，提供更结构化的可视化输出，调查结束后可通过「复制到编码智能体」按钮把成果直接导出。

演讲最后给出三点行动建议：动手安装并试用 DevTools for Agents；借鉴 PAIR 的经验把这些能力融入自己的日常工作流；关注每月的 release notes 持续跟进。核心理念始终如一——让编码智能体也拥有人类开发者受益了整个职业生涯的那套闭环反馈。