anything-analyzer 教程：给 Agent 一套网络观察台，而不是让它盲猜接口

很多 AI Agent 做网页任务时，最尴尬的不是不会写代码，而是看不见真实网络。浏览器里点一下，背后跑了哪些 API、带了什么 Cookie、哪里做了签名、哪个请求失败了，Agent 往往只能靠页面结果猜。

`anything-analyzer` 把这个问题往工程侧推了一步：内嵌浏览器抓包、MITM 代理、JS Hook、AI 分析和 MCP Server 放在同一个桌面工具里。它不是传统抓包工具换皮，而是试图把“网络观察能力”变成 Agent 可以调用的工具。

过去排查一个复杂 Web 应用，你可能要开 DevTools 看浏览器请求，用 Charles 或 Fiddler 看代理流量，再用 Wireshark 看底层包。每个工具都强，但上下文割裂。

anything-analyzer 的设计重点是统一 Session：网页、桌面应用、终端命令、手机代理等来源，最终都汇入同一个会话。这样 AI 分析时看到的不是孤立请求，而是一段完整操作里的请求流。

这对 Agent 很重要。Agent 不该只拿一个失败页面截图就开始猜原因，它应该能先问：这次操作产生了哪些请求？哪个接口返回 401？哪个请求体里有关键参数？重定向发生在哪一步？

最简单的入口，是从 Releases 下载对应平台安装包。启动后先配置 LLM，再新建 Session，用内嵌浏览器访问目标页面。

如果只是调试自己的网站或授权测试环境，不需要上来就动系统代理。先从浏览器 Session 开始：

1. Settings 里配置 LLM。
2. 新建 Session，填入测试站点 URL。
3. 用内嵌浏览器完成一次真实操作。
4. 让 AI 分析 API 结构、失败请求或性能瓶颈。
5. 对关键请求继续追问，而不是从头再抓。

这个流程比“先把所有流量都代理进来”更安全，也更容易定位问题。桌面应用、手机、终端命令可以后面再接。

工具支持 MITM 代理、系统代理、手机 Wi-Fi 代理、终端代理等方式。技术上这很强，风险也很明显。它适合用在：自己的应用、公司的测试环境、授权安全审计、接口联调、性能诊断。

不适合用来绕过第三方网站限制、窃取数据、规避风控或拆别人 App 的私有接口。这个边界必须写在前面。抓包工具是显微镜，不是通行证。

如果你在团队里推广这类工具，建议先立规矩：

这样用，它能显著提高调试效率；边界糊了，它就会变成安全事故。

一次页面操作可能产生几十到几百个请求，里面大部分是图片、字体、埋点、广告、静态资源。直接把全量流量塞给模型，不但贵，还容易把重点冲散。

anything-analyzer 的思路是分阶段：先过滤噪声，再聚焦分析。它提供自动识别、API 逆向、安全审计、性能分析、JS 加密逆向等模式。对日常开发来说，最实用的是三类：

这类报告不是为了替代工程师判断，而是把“先翻半小时请求列表”的体力活降下来。

内置 MCP Server 是这个项目最值得关注的部分。它把抓包和分析能力暴露给 Claude Desktop、Cursor 等工具。未来比较合理的工作流会是：

Agent 发现网页任务失败
→ 调用 anything-analyzer 抓一次授权测试流程
→ 读取过滤后的关键请求
→ 判断是接口、鉴权、前端状态还是等待条件问题
→ 生成修复建议或测试代码

这比让 Agent 只靠 DOM 和截图判断要扎实得多。尤其是 E2E 测试、自研后台、低代码平台、内部管理系统，问题经常不在按钮本身，而在按钮后面的网络链路。

它不是万能破解器。协议层工具解决的是可观察流量和可授权分析，不是所有访问限制。端到端加密、硬件绑定、设备指纹、行为生物特征、业务风控策略，这些不是一个抓包工具就能“解决”的。

更准确地说，anything-analyzer 给 Agent 补的是一套网络观察台。它让 Agent 不再盲猜接口，不再只看页面截图，但最终怎么修改代码、怎么设计测试、怎么判断合规，仍然要人负责。

这个定位如果想清楚，它会很有用；如果把它当“绕过一切”的工具，就跑偏了。