为什么需要 agent-eyes
未来代码大多由 AI 写，但二次调试和 bug 校验常常无人读代码——无论你还是 AI agent，调试时缺的都是同一样东西：浏览器里到底发生了什么。
下面是日常开发中最常踩的三个"盲区"，也是这个插件存在的理由。
三个让你抓瞎的盲区
1. 网络层盲区：fetch 看不到 cookie
你在控制台 console.log(await fetch(...)) 只能看到响应体，看不到最关键的鉴权信息：
- 请求带了哪些
Cookie？服务端Set-Cookie设了什么Domain/Secure/SameSite？ - 有没有发生重定向？重定向链路上 cookie 丢了没？
- CORS 预检为什么失败？
典型场景：登录接口明明返回 200，下个请求却 401。你怀疑是 token 没存，但 localStorage / cookie 里明明有——问题其实出在 cookie 的 Domain 或 SameSite 属性上，浏览器默默拒收了。而 fetch 层面你完全看不到这些。详见招牌案例：登录成功却 401。
2. 错误流不可追溯：控制台错误转瞬即逝
控制台的错误有几个致命问题：
- 一闪而过：页面一刷新、一跳转，之前的错误全没了
- 混着噪声：React dev warning、浏览器扩展报错、库的 deprecation 混在一起
- 没法分类：同一个错误刷了 100 次，控制台看不出频次，没法判断"这个到底要不要紧"
典型场景：agent 帮你改完代码，你问"刚才那个报错还在吗"——但控制台早被新一轮日志冲掉了，谁也答不上来。
3. 接口字段只能猜：类型定义和真实返回对不上
你的 TypeScript 类型说 user.email: string，但接口实际返回的是 user.emailAddress。代码按类型写，线上崩。
典型场景：后端改了字段，没通知前端；或者 mock 数据和真实接口结构不一致。你只能靠"跑一下看报不报错"来验证，而报错信息往往在三层层包装之后。
这个插件做了什么
把上面三个盲区全部落成 结构化、可解析、每次启动清空、最新记录在最上方 的运行时日志文件：
| 盲区 | 对应的日志 | 你能看到的 |
|---|---|---|
| 网络层盲区 | proxy-<host>.log | 请求/响应的 Cookie / Set-Cookie / status，包括被浏览器拒收的 |
| 错误流不可追溯 | errors.log | 聚合去重 + 频率计数，顶部是 Top Errors，按频次排序 |
| 字段只能猜 | api-calls.log | 真实的请求体 + 响应体，不带任何类型假设 |
0.9.0 起额外记录脱敏登录态画像，0.10.0 起自动记录脱敏交互轨迹——让 agent 能还原"先到哪个页面、点了哪个按钮、触发了什么问题"。
和别的方案有什么不同
你可能会问：这些 Chrome DevTools 不都能看吗？MSW 不是能 mock 吗？
- DevTools 是给人看的，不是给 agent 看的。它在 GUI 里，agent 没法读取；刷新就没了；没法跨会话对比。
- MSW 是 mock 工具，不是观测工具。它能造数据，但真实接口返回什么它不管。
- 这个插件的日志是文件，agent 能
cat/grep/head，每次启动自动清空，跨工具链通用。