AI Agent辅助Web逆向：AST解析与大模型驱动的JS代码分析实战

每隔一段时间，总会看到有人问：拿到一个不熟悉的网站，怎么快速看懂它的前端加密参数？搜索接口在哪？一堆混淆过的 JS 代码到底从哪里开始看？

过去的标准流程是：打开 DevTools → 打断点 → 翻 Source 面板 → 顺着调用栈一点一点摸。这套流程有效，但极度依赖经验。遇到稍微长一点的代码，光“看代码”就得耗上半天。尤其是现在前端工程化越来越重，代码被编译、压缩、混淆之后，变量的含义已经丢失，字符串被拆分重组，函数名变成_0x3f2a这种随机样式，人工阅读成本非常高。

AI Agent 的出现正在改变这个过程。它不是把逆向变成“一键通杀”，而是把代码阅读、调用关系梳理、思路记录这些重复劳动交给大模型，让人集中在判断和验证上。本文会完整拆解一套 AI Agent 辅助 Web 代码分析的搭建流程，包括环境准备、核心模块、电商场景下的实战步骤、完整源码示例和常见问题排查。

在开始之前，我想先给一个明确的判断：Agent 不是万能钥匙。它能把一个 2 小时的代码阅读任务压缩到 20 分钟，但前提是你自己知道浏览器调试怎么用、断点怎么看、调用链怎么理解。工具放大的是你的专业能力，而不是替代你的专业能力。“全网最强、通杀一切”这种说法，看看就好，真正可复用的是工作流和工程方法。

在动手之前，先补一个更重要的前提：你只能分析自己拥有、或已获得明确授权的网页和接口。未授权抓取、绕过付费墙、处理他人敏感数据，都是明确越界的行为。本文所有示例都假设你在合法的测试环境中调试自己的项目，或者拿到了目标系统的书面授权。下面开始。

1. 先泼一盆冷水：Agent 不是“通杀”，而是“加速器”

如果你的预期是“扔一个 URL 进去，Agent 自动把签名算法、接口依赖、数据流全部吐出来”，那大概率会失望。当前大模型在代码分析上的强项是语言理解，而不是动态执行。它能读代码、解释逻辑、整理调用关系，但它不知道代码在浏览器里运行时实际产生了什么值。

举个例子。一个典型的电商商品列表接口，前端请求 URL 里往往带sign、token、ts这类参数。ts是时间戳，sign是由某个函数根据请求参数计算出来的签名。人工分析时，你会打断点、看调用栈、观察参数传入传出，最终还原出签名算法。

Agent 能做的是：把 JS 文件切成结构化摘要，识别出sign这个字符串出现在哪些函数附近，然后把“这段代码大概在做什么”翻译成人能理解的语言。它会告诉你“在_0x3f2a函数里，参数a和b被拼接后做了某种哈希运算”。但它不能替代你断点验证，不能替代你确认a到底是不是timestamp，更不能自动生成一个能通过风控的完整请求。

表格对比传统流程和 Agent 辅助流程：

所以，Agent 的角色是“加速器”而不是“通杀器”。真正适合用它的读者是：

• 做过几单简单逆向，但每次都要花大量时间读压缩代码。
• 需要在短时间内梳理多个 JS 文件的逻辑。
• 团队里有新人，希望用 AI 生成注释和调用链，缩短上手时间。
• 安全测试、合规分析场景中，需要快速理解目标前端逻辑。

不适合用它的人，是把 Agent 当成免死金牌、完全不懂 HTTP 和浏览器调试、又想去打未授权目标的人。这种人无论用什么工具，都走不远。

2. 核心概念：Web 逆向分析到底在分析什么

在展开代码之前，先统一概念。很多人把“逆向”理解成一个很神秘的词，其实落到 Web 前端，它的核心就是三件事：

2.1 接口识别

请求从哪里来？先看 DevTools 的 Network 面板，找到触发某个数据加载的 XHR/Fetch 请求。找到之后，记录 URL、请求方法、请求头、请求体、响应结构。这一步是整个分析的地基。

2.2 参数生成逻辑追溯

很多站点不会把关键参数放在明面上，而是在前端 JS 里动态生成。比如sign = md5(ts + secret + params)，这样的逻辑编译压缩后散落在某个 JS 文件里。你需要找到“这个参数是什么时候生成的”“由哪个函数生成”“依赖哪些输入”。

2.3 链路依赖理解

JS 文件之间会互相引用，接口响应可能又触发下一个 JS 加载。一个页面背后可能同时存在十几个接口，数据流是 A 接口给 B 接口提供参数。把这条链路画清楚，才叫真正理解了目标系统。

AI Agent 在前端代码分析里的定位，是帮你加速 2.1 到 2.3 里的“读代码”部分。具体能力包括：

• AST 解析：把源码转成语法树，让程序可以批量检索函数、变量、字符串。
• 语义归纳：把“某个深层嵌套的函数”翻译成“这是一个拼接请求参数的函数”。
• 调用链可视化：统计函数之间的调用关系，输出结构化列表。
• 报告生成：把分析结果整理成 Markdown 或 JSON，方便团队协作。

注意，AST 解析工具本身是成熟技术，Agent 只是调度它。理解这一点，你就知道 Agent 并不是在黑魔法，而是把传统的“先静态扫描、再人工读代码”变成了“先静态扫描、AI 读一遍、人只看重点”。

3. 合规底线与授权边界

这篇文章反复提到合规，不是套话，而是因为 Web 代码分析很容易滑向灰色地带。写清楚边界，比教技巧更重要。

合法的场景包括：

• 分析你自己开发和维护的前端项目。
• 在获得授权的漏洞测试、安全评估项目中，分析目标系统。
• 在测试环境、模拟站点上研究前端签名算法，目标是提升自己的安全能力。
• 使用公开 API，且遵守服务条款和 robots 协议。

绝对不要做的事：

• 对未授权站点进行批量数据采集。
• 绕过登录、付费墙、风控机制去获取受限内容。
• 抓取和分析其他用户的订单、个人信息、支付数据。
• 利用发现的漏洞去攻击生产系统。

如果你发现目标系统存在未授权接口或安全缺陷，正确的做法是：验证后立刻停止，通过官方渠道报告，而不是继续深入或公开展示。涉及认证、权限或生产数据时，坚持最小权限原则：只用测试账号，只访问测试数据，只在隔离环境验证。

代理池、验证码识别、自动化点击绕过风控这类话题，不属于本文讨论范围，也不会在后续内容中出现。理解思路，永远比滥用工具重要。

4. 环境准备与 Agent 项目结构

先搭建一个最小可用的 Agent 分析工程。本文的示例使用的是通用技术栈，不绑定某个厂商的专属平台，所有 LLM 调用都抽象成“请求一个 chat completion 接口”，方便替换模型。

4.1 运行环境

• Node.js 16+：用来运行 AST 解析脚本，版本请以实际安装为准。
• Python 3.10+：用来组织 Agent 流水线。如果环境较老，将下文中的Optional[str]改为str即可。
• 一个可用的 LLM API：支持 OpenAI 兼容的/v1/chat/completions接口即可，模型名称请按实际填写。
• Git：方便保存和迭代 Prompt 模板、脚本版本。

安装 Node 依赖：

npm init -y npm install @babel/parser @babel/traverse

如果项目里出现 JSX、TypeScript 等代码，解析时需要调整 parser 的 plugins。本文示例先处理普通 JavaScript，实际遇到什么语法，再加对应插件。

4.2 LLM 配置

采用环境变量注入 API Key，不要把密钥写在代码里。

export LLM_API_KEY="sk-xxxxxxxx" export LLM_BASE="https://api.openai.com" export LLM_MODEL="gpt-4o-mini"

如果使用的是其他兼容服务商，把LLM_BASE换成对应地址即可。

4.3 项目结构

web-agent-analyzer/ ├── tools/ │ └── extract_ast.js # AST 解析脚本 ├── agent_pipeline.py # Agent 主流程 ├── prompt_templates/ # 存放各种提示词模板 │ └── analyze_code.md ├── reports/ # 生成的分析报告 ├── samples/ # 待分析的 JS 文件 │ └── target.js ├── package.json └── requirements.txt

prompt_templates/单独放提示词，是为了方便版本管理。提示词的改动会直接影响报告质量，把它当成代码一样维护，是 Agent 工程化的关键。

5. 核心模块一：AST 解析，把混淆 JS 变成结构化摘要

AST 全称是 Abstract Syntax Tree，抽象语法树。简单理解，就是把一段代码“拆骨架”：函数声明、变量声明、调用关系、字符串常量，全部变成可遍历的节点。压缩混淆过的代码虽然难以阅读，但 AST 解析器仍然能还原它的结构骨架。

下面是一个完整可运行的 AST 提取脚本。它的作用是读取一个 JS 文件，输出函数列表、调用关系、字符串常量和属性访问链。

// 文件路径：tools/extract_ast.js // 用途：读取一个 JS 文件，输出函数、调用关系、字符串常量清单（JSON） const fs = require('fs'); const parser = require('@babel/parser'); const traverse = require('@babel/traverse').default; const filePath = process.argv[2]; if (!filePath) { console.error('用法: node tools/extract_ast.js <js文件路径>'); process.exit(1); } const code = fs.readFileSync(filePath, 'utf-8'); let ast; try { ast = parser.parse(code, { sourceType: 'unambiguous', }); } catch (e) { console.error(`解析失败: ${e.message}`); process.exit(1); } const result = { functions: [], calls: [], strings: [], objectChains: [], }; function nodeName(node) { if (!node) return ''; if (node.type === 'Identifier') return node.name; if (node.type === 'ThisExpression') return 'this'; if (node.type === 'MemberExpression') { return nodeName(node.object) + '.' + nodeName(node.property); } return ''; } traverse(ast, { FunctionDeclaration(path) { result.functions.push({ kind: 'function', name: path.node.id ? path.node.id.name : '<anonymous>', params: path.node.params.map((p) => nodeName(p)), start: path.node.start, end: path.node.end, }); }, CallExpression(path) { result.calls.push({ callee: nodeName(path.node.callee), start: path.node.start, }); }, StringLiteral(path) { const value = path.node.value; if (typeof value === 'string' && value.length > 0) { result.strings.push(value); } }, MemberExpression(path) { const name = nodeName(path.node); if (name.length > 0) { result.objectChains.push(name); } }, }); console.log(JSON.stringify(result, null, 2));

这个脚本的定位是“给 Agent 的第一双眼睛”。运行方式：

node tools/extract_ast.js samples/target.js > reports/ast.json

输出内容包含四类信息：

为什么先做这一步？因为直接把 100KB 压缩代码丢给大模型，会产生三个问题：

• 超出上下文窗口，或者 cost 爆炸。
• 输出冗长，重点被淹没。
• 大模型把大量时间花在“读代码”上，忽略了分析判断。

先结构化，再交给 LLM，是控制质量的关键，也是 Agent 工作流和“直接扔代码给 ChatGPT”的核心区别。

6. 核心模块二：LLM 生成注释与调用链分析报告

拿到 AST 摘要后，就可以让大模型干活了。这一节给出 Agent 主流程的完整代码。

# 文件路径：agent_pipeline.py """ 最小可用的 Agent 分析流水线： 1. 调用 extract_ast.js 生成 AST 摘要 2. 构造分阶段提示词 3. 调用大模型生成解释与调用链报告 4. 保存 Markdown 报告 """ import json import os import subprocess import sys from typing import Optional import requests def extract_ast(js_path: str) -> dict: result = subprocess.run( ["node", "tools/extract_ast.js", js_path], capture_output=True, text=True, check=True, ) return json.loads(result.stdout) def call_llm(messages, model: Optional[str] = None) -> str: api_key = os.getenv("LLM_API_KEY") base_url = os.getenv("LLM_BASE", "https://api.openai.com") model = model or os.getenv("LLM_MODEL", "gpt-4o-mini") resp = requests.post( f"{base_url}/v1/chat/completions", headers={"Authorization": f"Bearer {api_key}"}, json={"model": model, "messages": messages, "temperature": 0.2}, timeout=60, ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] PROMPT_TEMPLATE = """ 你是一个 Web 前端代码分析助手。下面是一段从授权分析项目中提取的 JS 结构信息： ```json {structure}

请完成两件事：

1. 用通俗中文解释这段代码的职责，标注关键函数、变量和字符串常量。
2. 如果存在加密参数生成逻辑，说明可能的输入和输出，不要猜测不存在的逻辑。 生成 Markdown 报告，包含调用链分析。 """

def generate_report(js_path: str) -> str: print(f"[1/3] 解析 AST: {js_path}") structure = extract_ast(js_path) print(f"[2/3] 提取到 {len(structure['functions'])} 个函数、" f"{len(structure['calls'])} 个调用、" f"{len(structure['strings'])} 个字符串。")

messages = [ {"role": "system", "content": "你是严谨、克制的代码分析助手，只做基于输入结构的推断，禁止编造。"}, {"role": "user", "content": PROMPT_TEMPLATE.format( structure=json.dumps(structure, ensure_ascii=False, indent=2) )}, ] print("[3/3] 调用 LLM 生成报告...") report = call_llm(messages) out_path = "reports/report.md" os.makedirs("reports", exist_ok=True) with open(out_path, "w", encoding="utf-8") as f: f.write(report) print(f"报告已保存: {out_path}") return out_path

ifname== "main": if len(sys.argv) < 2: print("用法: python agent_pipeline.py <js文件路径>") sys.exit(1) generate_report(sys.argv[1])

运行方式： ```bash python agent_pipeline.py samples/target.js

这里有一个容易犯的错误：把 AST 摘要一次性塞进提示词，导致输出变成“JSON 复读机”。解决思路是分级推进。第一轮先用摘要生成一个大纲，第二轮再把关注度最高的函数切片提取出来，单独请求大模型做细读。例如，Agent 发现字符串列表里有sign相关字样，就可以自动触发第二轮：

1. 提取该字符串附近 300 行的代码片段。
2. 让大模型解释“这个值是怎么参与计算的”。
3. 输出候选参数列表和需要人工验证的环节。

把“一次读全部”改成“先扫描，再聚焦”，报告质量会稳定很多。这也是 Agent 编排和大模型原生能力之间真正的分界线。

7. 电商平台实战：商品接口分析全流程

下面用一个典型场景串起全部步骤。假设你有一个自己开发的电商 Demo 站点，或者拿到了某电商项目的书面授权，需要分析商品列表接口的签名参数生成逻辑。

7.1 定位前端代码

打开 DevTools，切到 Network 面板，找到商品列表请求。选中 XHR 过滤，定位到类似list?keyword=书包&page=1&sign=...的请求。把响应和请求参数记录下来。注意观察 URL 和载荷里有哪个参数是“动态的”：时间戳会随时间变化，签名会随其他参数变化。

7.2 搜索关键字

切到 Sources 面板，打开前端 JS 文件，全局搜索sign、md5、sha、encrypt、secret等关键词。很多压缩代码里，函数名被改了，但字符串常量还保留着原始语义。如果页面加载了多个 JS，可以配合 Network 面板按资源大小排序，优先看体积最大的那个。

7.3 保存文件并运行 AST 解析

把定位到的 JS 文件保存到本地。注意，压缩代码可能非常大，几 MB 的 JS 文件直接丢进大模型并不现实。先用工具切分。

例如，使用extract_ast.js提取该文件的函数和字符串摘要：

node tools/extract_ast.js samples/target.js > reports/ast.json

然后手动浏览ast.json里的strings和functions，确认sign相关字符串出现了几次、出现在哪个函数附近。这一步不需要 AI，肉眼扫 JSON 就已经比在一整段压缩代码里翻找快得多。

7.4 交给 Agent 做语义归纳

接着运行：

python agent_pipeline.py samples/target.js

预期输出报告会包含调用链分析，例如：

window.getSign接收参数obj，内部调用md5函数，将obj.keyword + obj.page + timestamp按固定顺序拼接后计算哈希，返回 32 位字符串。

看到这种描述，不要急着信。它只是基于静态结构做的推测。下一步必须回到 DevTools 验证。

7.5 断点验证

在 DevTools 里给getSign下断点，触发一次商品查询。观察传入参数、函数内部每一步的运算结果。确认：

• 参数顺序是否和 Agent 描述一致。
• 是否还夹带了页面环境信息，比如 userAgent、屏幕宽度。
• 时间戳是否是毫秒级。

断点验证通过后，才可以把这段逻辑复现到自己的测试脚本里。复现时只在自己有权调用的测试接口上做验证，不要做突发高频请求。

7.6 链路整理

商品列表接口通常不是孤立的。它可能先请求config接口拿到一个种子值，再用种子里的一部分参与签名计算。这种情况下，把多个 JS 文件都交给同一套流水线处理：

python agent_pipeline.py samples/config.js python agent_pipeline.py samples/list.js

然后对照两份报告，标记出跨文件的依赖关系。Agent 适合逐份分析，但“哪份 JS 先加载、哪个接口先启动”这件事，仍然要用 DevTools 的 Network 时间线和 Initiator 面板确认。

8. 常见问题与排查思路

这里最值得强调的一点是：静态分析报告不是结论。大模型的通病是会“自信地编造”，它会补全缺失的逻辑，把未知的部分修饰成已知。所以每一条 Agent 输出，在落到代码之前，必须经过断点验证。建议把验证结果追加到报告末尾，形成“推理 vs 实证”两条记录，方便后续复查。

9. 最佳实践与工程化建议

最后补充一些工程层面的建议。这些经验比任何“通杀技巧”都耐得住时间。

9.1 授权先行，留痕归档

每个分析任务都应该记录目标、时间、授权依据。可以用一个简单的case目录，存放授权说明、JS 文件、AST 摘要和最终报告。将来如果有人问起“当时为什么分析这个”，你能拿出完整的合规链路。

9.2 最小权限原则

在测试环境中，只使用测试账号；绝不使用生产环境账号做验证。涉及个人数据时，只保留脱敏后的字段。对任何请求，都要控制频率，不要给自己站点的测试接口造成压力。

9.3 Prompt 模板版本化

Prompt 是最容易被忽略的“代码”。把不同的提示词模板放入prompt_templates/，用 Git 管理改动。记录“这个模板在什么场景下表现好，在什么场景下失效”。随着项目积累，你会拥有一套比任何公开教程都适配自己业务的提示词库。

9.4 输出结构化

让 Agent 始终输出 JSON 和 Markdown 两种格式。JSON 方便机器解析，Markdown 方便人阅读。示例：

{ "function": "getSign", "params": ["keyword", "page", "timestamp"], "algorithm": "md5(keyword + page + timestamp)", "confidence": "medium", "needVerify": ["param order", "timestamp unit"] }

结构化输出最大的收益是：即使这次分析结论有误，下一次也能自动化地对比新旧报告，找出差异点。

9.5 人机协作，别让 Agent 全自动

全自动是效率的陷阱。让 Agent 自动生成报告没问题，但让 Agent 自动重放签名请求、自动批量访问目标站点，就是在把自己推向风险区。正确姿势是：Agent 负责读和写，人负责判断和验证。

9.6 成本控制

LLM 调用是按 token 计费的，JS 文件动辄几百 KB，全部塞进去既慢又贵。更好的做法是：先用 AST 摘要把文件压缩到几 KB，再决定哪些函数需要细读。对大型 JS 文件，可以按函数切片分批请求，最后再汇总。这个思路不仅省钱，还能显著提升报告质量。

10. 总结与后续学习方向

AI Agent 在 Web 代码分析中的价值不是“全能破解”，而是把“读代码、写注释、理调用链”这些脏活自动化。本文的核心流程可以概括成四步：

1. 用 AST 解析器把压缩 JS 变成结构化 JSON。
2. 用第一轮提示词让 LLM 生成全局概览。
3. 针对可疑函数，提取切片做细读。
4. 回到 DevTools 打断点验证，把实证结果写回报告。

这套流程用到今天依然有效，而且不绑定特定模型。无论底层换成开源模型、国产模型还是闭源模型，工作流本身是稳定的。

如果你想继续深入，推荐按这个顺序学习：

• JavaScript 混淆原理：字符串编码、控制流扁平化、变量名重写。
• AST 操作：学会用@babel/parser和@babel/traverse改代码，而不只是读代码。
• 浏览器调试技巧：条件断点、调用栈、日志点。
• HTTP 协议基础：请求头、状态码、缓存、鉴权。
• Agent 工作流编排：把多个工具串成流水线，学会设计提示词和工具调用。

不要迷信“最强”和“通杀”。真正值钱的，是你对浏览器调试和代码逻辑的理解，AI Agent 只是帮你把理解力放大一点。在合规前提下动手练一练，哪怕从一个自己写的 Demo 站开始，也比收藏十个模板有用得多。