Chrome DevTools for agents

如果你最近还在把 AI 编程助手当成“会补全代码的聊天框”，那真的有点亏。

2026 年的开发者工具热点，已经从“让 AI 写函数”变成了“让 AI 看到真实运行环境、读到项目上下文、调用外部工具，然后自己验证结果”。简单说：AI 编程助手正在从副驾驶，变成能干活的实习同事。

这篇就聊一个特别实用的方向：把 AI coding agent 接上浏览器、MCP 和项目规范，让它不只是写代码，还能帮你调试、审查、跑测试、查文档。

先说结论：这套工作流适合谁？

如果你有下面任意一种场景，就很值得试：

  • 经常改前端页面，但反复截图、刷新、查控制台很烦；
  • 项目文档、数据库、云服务、Issue 分散在不同地方；
  • 想让 AI 帮你改代码，但又怕它胡写、瞎猜 API；
  • 你维护的是个人博客、小工具、Docker 服务、管理面板这类“东西不大，但杂活很多”的项目；
  • 希望 AI 帮你做重复任务，比如写测试、整理 PR、查日志、补文档。

核心思路只有一句话：

不要只给 AI 一个问题，要给它工具、上下文和验收标准。

最近为什么突然火？

1. 浏览器调试终于能交给 Agent 了

Chrome DevTools for agents 1.0 已经发布。它的重点不是“又多了一个聊天助手”，而是把浏览器调试能力开放给 AI coding agent：看页面、查 DOM、跑 Lighthouse、做设备模拟、定位内存泄漏。

这对前端和全栈开发特别关键。以前 AI 写完页面，只能靠你描述“这里歪了、那里不对”。现在它可以自己打开页面、观察结果、再回去改代码。

2. MCP 变成 AI 工具接入的通用插座

MCP，全名 Model Context Protocol，可以理解成 AI 连接外部工具和数据源的一套开放协议。Anthropic 最早开源后，现在越来越多工具围绕 MCP 做集成。

你可以把它想成 USB-C：

  • GitHub、Postgres、浏览器、文件系统、云服务，都可以做成 MCP Server；
  • AI 客户端作为 MCP Client，按权限调用这些工具；
  • 你不用为每个 AI 工具重复写一套私有插件。

Model Context Protocol illustration

3. 云厂商也开始给 Agent 准备“安全栏杆”

AWS 最近发布 Agent Toolkit for AWS，把 MCP Server、Agent Skills、插件和 IAM 权限边界放到一起。这个信号很重要：企业不是不想用 AI Agent，而是怕它乱动生产环境。

所以未来真正好用的 AI 开发工作流，一定不是“给 root 权限让它随便跑”，而是：

  • 能查文档；
  • 能读日志；
  • 能在沙箱里执行；
  • 能跑测试；
  • 能被权限和审计限制住。

一套个人开发者也能落地的配置清单

下面这套不追求玄学，适合个人项目、小服务器、博客、Docker 应用。

第一步：给项目写一份 AGENTS.md

很多 AI coding agent 都会读取项目里的说明文件。你可以在项目根目录放一个：

# AGENTS.md

## 项目说明
这是一个 Typecho + Docker Compose 部署的个人博客。

## 常用命令
- 查看容器：docker ps
- 查看日志：docker logs --tail=100 <container>
- 检查 Compose：docker compose config

## 修改规则
- 修改数据库前必须备份
- 不要在生产服务器安装新软件
- 所有文章发布前检查标题、slug、分类关系

## 验收标准
- 页面 HTTP 200
- 首页能看到新内容
- 图片和 iframe 不被过滤

这东西看起来朴素，但非常有用。它能把你的偏好和安全边界变成 Agent 每次都会参考的“项目说明书”。

第二步：把浏览器接进调试流程

如果你做前端，建议至少准备一个能让 AI 观察页面的环境。

官方示例里，Chrome DevTools for agents 支持 MCP Server、CLI 和 Agent Skills。它能让 Agent 做这些事：

  • 打开页面并截图；
  • 检查控制台报错；
  • 模拟移动端窗口；
  • 跑 Lighthouse；
  • 检查可访问性和 SEO；
  • 调试复杂的浏览器状态。

这一步的价值很大：AI 不再只听你说页面错了，它能自己看。

第三步：只开放必要工具，不要一上来给全权限

这是很多人会踩的坑。

别为了省事直接给 AI：

sudo su
chmod -R 777 /opt
把生产数据库直接给它随便改

更推荐这样拆：

# 只读观察
ssh myserver "docker ps && docker logs --tail=80 app"

# 修改前备份
cp data.db data.db-before-change-$(date +%Y%m%d-%H%M%S)

# 改完验证
curl -I https://example.com

让 Agent 有能力，但不要让它没有边界。

第四步：把任务写成“可验收”的小块

坏提示词：

帮我优化一下网站。

好提示词：

帮我检查首页移动端布局。要求：打开本地页面，截图确认没有文字重叠；如果改 CSS，改完跑一次构建；最后给我列出改了哪些文件。

这就是 AI Agent 的正确打开方式：任务越具体，它越像同事；任务越玄学，它越像抽奖。

我建议你马上做的 5 件事

  1. 给每个长期项目加一个 AGENTS.md；
  2. 把“启动、测试、构建、备份、回滚”命令写进去；
  3. 给 AI 的 SSH 权限单独分层，不要默认全权生产；
  4. 前端项目一定让 AI 看到页面，不要只让它猜；
  5. 所有数据库直写任务都先备份，再验证页面。

最后说句实在的

AI 编程助手最强的地方，不是替你写一段漂亮代码，而是接手那些“你会做，但很烦”的流程：查日志、看页面、跑测试、整理文档、复现问题、生成小补丁。

未来的差距，可能不在于谁会不会用 AI，而在于谁更会给 AI 配工具、立规矩、拆任务。

会用聊天框，只是入门；会搭 Agent 工作流，才是真正的生产力。

参考资料：

本文是面向个人开发者和小团队的实用技术向整理，适合作为 AI Agent 工作流入门清单。