第7篇 全栈AI · anything-analyzer

原创

陈看山
陈看山

安全诸子

2026年6月9日 13:00
上海

在小说阅读器读本章

去阅读

这是全栈AI系列的第 7 篇。上一篇我们聊的是“安全测试 Agent 化”，把原本需要人工来回切换的流程，尽量交给 Agent 去做。这一篇继续沿着“自动化 + AI”往下走，但关注点换成了更底层、也更常见的一件事：抓包之后，怎么把海量请求真正读明白。

如果你做过接口排查、逆向分析、联调定位，或者只是想弄清楚某个应用到底发了什么请求，你大概率会有同一种感受：抓包不难，难的是分析。请求一多，噪声一大，真正关键的那几条往往要翻很久。anything-analyzer 解决的，正是这一步。

先说结论：它不是“更会抓包”，而是“更会分析”

从公开介绍来看，anything-analyzer 的定位并不是单纯的抓包工具，而是一个“全场景抓包 + AI 自动分析”方案。它关心的不是你从哪里抓到流量，而是抓到之后，能不能自动做第一轮筛选、提取重点、归纳逻辑，并把分析结果继续往下追问。

这类工具的价值在于，它把过去很依赖经验的过程，拆成了两个层次：先从大量流量里把噪声过滤掉，找出值得看的请求；

1. 再围绕关键请求做深度分析，回答“它在做什么、为什么这么做、哪里可能有风险”。
2. 对于经常面对复杂系统的人来说，这比单纯导出一份 HAR 或 PCAP 更有用。因为真正耗时的，从来不是“有没有数据”，而是“怎么从数据里找出线索”。

anything-analyzer 的核心思路：先筛，再拆，再追问

公开信息里，anything-analyzer 比较有代表性的能力，是它采用了“两阶段分析”思路。

第一阶段是智能过滤。系统先对抓到的请求进行初筛，把明显无关、重复度高、干扰分析的内容先压下去。这个阶段的目标，不是下结论，而是缩小视野，让分析对象从“所有流量”变成“关键流量”。

第二阶段才进入深度分析。这里会结合请求参数、接口特征、调用链、返回内容等信息，尝试回答几个常见问题：

• 这个接口的业务作用是什么；
• 请求之间有没有前后依赖；
• 是否存在鉴权、签名、加密、编码等处理；
• 某个字段为什么每次都会变化；
• 这个请求是否存在安全审计上的关注点。
• 更重要的是，它支持流式输出和多轮追问。也就是说，分析不是一次性出报告就结束，而是可以在结果出来后继续追问细节，比如“这段参数生成逻辑来自哪里”“这个加密调用对应哪一层代码”“还有哪些请求和它属于同一条链路”。这让它更接近一个“随问随答的分析搭子”，而不是静态报告生成器。

五种分析模式，覆盖不同任务

anything-analyzer 公开介绍里提到了 5 种分析模式。它们不是为了炫技，而是对应不同场景下的分析目标。下面这张表可以更直观地看出差别：

如果把这五种模式放在一起看，你会发现它并不是简单地“多几个按钮”，而是把分析目标按任务类型拆开了。这样做的好处是，AI 不需要在一个模式里同时承担所有职责，结果也更容易收敛。

它为什么特别适合“前端到后端”的全链路排查

很多抓包工具只负责“看到流量”，但现实工作里，经常要继续往下追：这个请求来自哪里？参数在哪一层生成？前端是不是做了签名？加密函数是自写的还是用了第三方库？后端又是怎么校验的？

anything-analyzer 公开介绍中提到的 JS Hook 注入能力，很适合补上这条链路。它可以自动拦截一些常见的前端调用点，例如 fetch、XHR、crypto.subtle、CryptoJS，以及常见国密相关调用。对分析者来说，这意味着你不只是看到请求结果，还能看到它在浏览器侧是怎么被拼出来的。

同时，它还支持从 JS 文件中提取与加密相关的代码片段。这一点对逆向分析尤其关键。因为很多时候，真正值得看的不是整份脚本，而是那几段和签名、加密、编码直接相关的逻辑。先把关键代码抽出来，再让 AI 结合流量一起分析，效率会高很多。

一个比较实用的工作流

如果把它放到真实工作里，我更建议按下面这个顺序使用：

1. 先确定目标，而不是一上来就“全量抓”

你可以先想清楚：是想看某个接口的参数生成逻辑，还是想排查应用性能，还是想做安全自查。目标不同，后面的分析模式也不同。先定目标，AI 才不会在一堆无关请求里发散。

2. 让工具先做第一轮过滤

把明显重复、静态资源、无关心跳请求先压缩掉。这个阶段的产出不是结论，而是“候选关键请求列表”。只要候选集小下来，后面的分析质量会明显更稳定。

3. 针对关键请求继续追问

看到某个异常参数、可疑加密、频繁重放的接口，不要急着下结论，直接继续问：

• 这个字段是怎么来的；
• 这个签名依赖哪些入参；
• 这个请求是否与前一个响应有关；
• 是否存在安全或性能上的异常点。

4. 最后回到人工判断

AI 很擅长归纳和联想，但最终是否成立，还是要回到业务语义和真实代码。特别是在接口逆向和安全审计场景里，不能把“看起来像”直接当成“就是”。

落地建议：把它当成“分析加速器”，不是“自动裁判”

如果你准备把这类工具放进日常工作流，我建议重点关注三件事：

• 第一，尽量在虚拟机或隔离环境里使用，尤其是来源不明的工具或样本；
• 第二，优先用于自测、排障、研究和授权场景，不要跨越边界；
• 第三，把 AI 输出视为分析线索，而不是最终结论，关键判断仍然要靠你自己复核。
• 对于工程团队来说，最实用的方式不是追求“完全自动化”，而是把它嵌进现有流程里：先抓、再筛、再问、再核对。这样既能提效，又不至于把分析权完全交出去。

边界说明：能力越强，越要守住使用边界

需要明确的是，抓包和逆向分析本身是中性的技术能力，适合做排障、兼容性分析、安全自查和协议研究。但一旦被用于未授权访问、绕过鉴权、窃取数据或其他非法用途，性质就完全变了。

所以，讨论 anything-analyzer 这样的工具，重点应当放在工程价值上：它如何帮助我们更快理解复杂流量，如何减少重复劳动，如何把“看不懂的请求”变成“可追问、可定位、可验证的分析对象”。技术可以很强，但使用边界必须更清楚。

如果你正在做全栈排障、接口逆向、前端加密分析，或者想把抓包后的人工整理步骤交给 AI 先跑一轮，anything-analyzer 这类工具值得关注。它未必替你做所有判断，但很可能帮你省下最耗时间的那一半。