# DevTools for agents：让 Agent 看见真实浏览器

<div class="grid grid-cols-2 gap-8 mt-8">

<div class="card-blue">
<div class="font-semibold mb-3">人类调试时看什么？</div>
<div class="space-y-2 text-sm">

- Console 错误
- Network 请求
- Performance 录制
- Lighthouse 结果
- Memory / Heap snapshot

</div>
</div>

<div class="card-green">
<div class="font-semibold mb-3">Agent 也应该看什么？</div>
<div class="space-y-2 text-sm">

- 页面真实渲染状态
- 运行时错误和警告
- 资源瀑布与接口失败
- 性能瓶颈和内存线索
- 扩展和多窗口调试上下文

</div>
</div>

</div>

<div class="mt-8 text-2xl font-bold">
只把代码发给 Agent 不够，它还需要理解代码在浏览器里怎么运行。
</div>

<!--
这一页讲 DevTools for agents。

人类开发者调试 Web，不会只看源码。我们会打开 Console 看报错，打开 Network 看请求和瀑布图，打开 Performance 看主线程和长任务，打开 Lighthouse 看性能、可访问性和最佳实践，必要时还会看 Memory 和 Heap snapshot。

但很多编码 Agent 只拿到代码上下文，它并不知道页面真实运行时发生了什么。代码看起来没问题，不代表页面真的渲染正确；接口写对了，不代表请求真的成功；组件逻辑合理，不代表交互不卡；构建通过，也不代表用户在浏览器里看到的是正确页面。

DevTools for agents 的方向，就是把这些浏览器调试能力开放给 Agent，让它不只是“读代码”，还可以“看运行现场”。换句话说，Agent 不应该只基于文件做推理，它也应该能结合 Console、Network、Performance 和页面状态来判断问题。

这会改变我们和 Agent 的协作方式。过去我们可能只是把错误栈贴给 AI，让它猜哪里错了；未来更合理的方式是让它连接真实浏览器环境，看到当前页面、当前请求、当前报错和当前性能瓶颈，再提出修改建议。

举个例子，如果页面白屏，Agent 不应该只搜索代码里的 mounted 或 useEffect；它应该先看 Console 有没有运行时异常，再看 Network 有没有资源 404 或接口 500，再看页面是否真的挂载了根节点。这样调试会更接近一个高级前端真实排查问题的路径。
-->