Agent爬虫逆向实战：用ReAct循环自动化破解加密参数

1. 为什么说古法爬虫逆向已死

1.1 古法逆向的五个致命耗时点

先聊聊我自己的经历。前几年做数据采集，最怕的就是遇到带加密参数的项目。打开浏览器的开发者工具，先抓接口看请求头，看到一个X-Sign之类的参数，后面跟着一长串看不懂的密文，那一刻的心情，大概和看到体检报告上出现异常指标差不多。

所谓古法逆向，说白了就是靠人肉一步步把前端的加密逻辑啃下来。这套流程我跑了快十年，闭着眼都能数出它有多少个黑洞：

第一步是抓包。听起来简单，但一遇到数据来自 WebSocket 或者异步加载的接口，光是把完整的请求链路搞清楚就能耗掉半天。第二步是定位参数。用全局搜索搜参数名，搜出来一堆压缩后的 JS 文件，那里面全是混淆过的变量名，你根本不知道这个参数的赋值逻辑藏在哪一行。第三步是打断点。这是最折磨人的环节，动态调试时一不小心就踩进神代码的死循环，要么跳进了被删掉的 source map 映射，要么被迫去看几千行的压缩代码。第四步是把加密逻辑翻译成 Python 或者 Node 代码，这个环节要处理各种兼容问题，很多在浏览器环境里能跑的 API，脱离了浏览器之后完全是另一个脾气。第五步更头疼——你刚把逻辑搞清楚，第二天再看请求，发现签名算法悄然改了，整个流程重来。

我遇到过一个印象深刻的案例。某平台的产品列表页接口，签名参数有几十个字符，还绑定了平台的公开密钥和时间戳，它的加密过程中用到了浏览器特定的环境指纹。我用了整整三个工作日才把算法还原清楚，结果第五天对方改了参数生成方式。那种感觉真的让人心灰意冷——数据采集越做越像在跟一个看不见的对手玩你追我赶的游戏。

1.2 不是技术不行，是性价比崩了

回头想一想，古法逆向真正的问题不是手艺不行，而是效率模型已经彻底跟不上需求了。一个前端团队改签名逻辑可能只需要一两个小时，而另一端的人肉逆向少说也得一天。也就是说，只要对方愿意频繁改动，你永远处于被动状态。

更麻烦的是，现在的网站前端已经不像过去那样结构简单。反过来看现在的技术环境，微前端架构、WebAssembly、各种混淆与反调试手段混合在一起，一个普通页面里的 JS 文件动不动就有几十个，每个都可能藏着一层加密逻辑。靠人工去顺着代码执行流追线索，本质上就是拿时间去换结果。

在这个背景下，Agent 的出现像给这个行业换了一种工作姿势。大模型对代码和网络协议有很强的理解能力，它能帮你做这件事：读代码、找参数来源、猜解密逻辑、生成脚本、跑测试、根据报错自我修正。以前一个人要花三天完成的工作，现在半天就能出一个可用的结果，虽然不完全能脱离人工，但效率提升非常明显。

需要提前说明的是，我讲的 Agent 爬虫逆向，不是拿一个机器人替你烧杀抢掠那种。它其实是一个教会大模型使用抓包工具、浏览器调试工具、代码执行环境，并且赋予它自我验证能力的工作流。下面我从思路到搭建再到案例，把整套流程给你捋一遍。

2. Agent 爬虫逆向究竟在做什么

2.1 Agent 的角色不是“代替你逆向”，而是“替你跑完逆向的脏活”

如果你指望 Agent 能完全替代你的判断力，直接输入一个网址就返回所有数据，我只能说，目前还不太现实。但如果你把它定位成“一个能帮你穷举方案、快速验证、反复修正的执行者”，那它确实能干掉大部分重复劳动。

我习惯把一个爬虫逆向任务拆成下面几个环节，然后分别交给 Agent 去处理：

• 理解目标：读取页面源码、接口返回结构、JS 文件列表，搞清楚数据到底是怎么渲染出来的。
• 定位关键逻辑：跟踪某个加密参数在代码里的赋值关系，区分它来自 Cookie、动态接口还是前端计算。
• 还原或绕行：能还原的还原，还原成本太高的就改用浏览器自动化方式直接执行页面环境里的函数。
• 编写代码：把上述结果封装成可复用的采集脚本。
• 验证修正：跑一遍代码，把报错信息反馈给模型，让它继续改，直到通过。

你会发现，这个流程里真正需要“技术判断”的环节其实比重不大，大部分时间花在了读取、检索、验证、试错上。这些恰恰是大模型比较擅长的事。Agent 本质上是一个带有目标导向的循环，能不断根据观察采取行动，并根据新得到的信息调整计划。

2.2 ReAct 循环：从“看到”到“做到”再到“验证”

现在主流的 Agent 都跑在一种叫 ReAct 的范式上。拆开来看就是“思考-行动-观察”的循环。拿一个具体的抓包任务来举例。

第一步，Agent 拿到一个带加密参数的接口地址，它先不做任何动作，而是分析这个接口出现在哪些调用链路上，哪一步该用脚本执行工具去尝试获取数据。它会说“先查看文章页 HTML，找到数据接口的调用位置”，这是一个思考过程。

第二步，它会调用浏览器自动化工具，把页面打开，等待渲染完成后开始监听网络请求。它会自动过滤掉图片、字体这些静态资源，把 XHR 和 Fetch 请求挑出来，整理出接口列表。

第三步，观察返回结果。它看到接口里有一个sign参数，那接下来它会去 HTML 或 JS 文件里搜索这个字符串的赋值逻辑。找到了就读取相关代码块，找不到就换一种思路尝试。

这一整个循环里，每一步的结果都会反馈给模型，指引它下一步怎么做。这就是 Agent 和脚本自动化的本质区别。

2.3 为什么通用 Agent 框架都能“看懂”网页

很多人会好奇，大模型又没有浏览器，怎么分析网页？其实思路是通过工具把网页的文本信息喂给它。比如无头浏览器可以把 DOM 结构提取成文本摘要、接口的请求和响应会整理成 JSON 格式、JS 代码可以搜索并提取关键片段，然后再作为上下文提供给模型。

这个“给模型建立上下文”的过程，是 Agent 能不能干好活的关键。你给它一团乱麻一样的压缩 JS，它也会头疼；但你把“这段函数接收了两个参数，最终 return 的是一个拼接结果”这种结构信息提取出来，它就能很快做出判断。所以 Agent 搭建过程中，最值得花时间的不是代码逻辑，而是怎么把工具返回的信息转换成对模型友好的输入。

3. Agent 搭建流程实战

3.1 技术选型：模型、框架与工具链怎么配

开始搭 Agent 之前，先把选型理清楚。我用过不少方案，这条组合目前的稳定性最高：

• 大模型：推荐带工具调用能力的模型，能输出结构化参数。能力强一点的模型在代码理解上会更准，对混淆代码的容忍度也更高。
• Agent 框架：直接调用大模型 API 自己写 ReAct 循环，或者使用成熟的编排框架。为了不引入太多黑盒，我更倾向于自己写一个轻量循环，只保留规划、调用工具、反馈三个动作。
• 浏览器自动化：选一个能接管真实浏览器的工具。这个很关键，因为很多网站只有登录状态下才返回完整数据，也依赖真实的浏览器指纹。需要支持监听网络请求、执行页面内 JavaScript。
• 代码执行环境：Python 和 Node 都得准备。加密逻辑还原出来是 JavaScript 就丢给 Node 执行，数据抓取和清洗的部分用 Python 处理更顺手。

举个例子，一个最简版的 ReAct 循环如果用 Python 来写，框架骨架大概是下面这样。这里的核心逻辑就是“取出一个动作、执行它、把结果放回上下文、再来一轮”。

import json from llm import chat_completion messages = [ {"role": "system", "content": "你是爬虫逆向助手，负责分析网页并生成采集代码。"}, {"role": "user", "content": "分析当前页面中的商品数据接口，并给出获取方式。"} ] tools = [ { "name": "get_network_requests", "description": "获取当前页面的所有网络请求", "parameters": {"type": "object", "properties": {}} }, { "name": "search_js_source", "description": "在JS文件中搜索指定字符串，返回关联代码片段", "parameters": { "type": "object", "properties": { "keyword": {"type": "string", "description": "要搜索的关键字"} }, "required": ["keyword"] } } ] for step in range(10): response = chat_completion(messages=messages, tools=tools) if response.finish_reason == "tool_calls": for call in response.tool_calls: result = execute_tool(call.function.name, json.loads(call.function.arguments)) messages.append({ "role": "tool", "name": call.function.name, "content": json.dumps(result, ensure_ascii=False) }) else: print(response.content) break

这套循环本身不复杂，但要跑得稳，有几个细节必须注意。第一，工具的返回体一定要精简。Agent 的上下文窗口虽然年年扩大，但也没有大到能把整份压缩 JS 塞进去的程度，所以工具侧要主动做裁剪，只返回匹配行附近的代码。第二，每个工具调用都要有异常捕获。Agent 在执行中经常碰到超时、元素找不到、节点崩掉这类问题，一旦没接住，整个流程就断了。

3.2 系统提示词设计：给 Agent 立规矩

提示词的质量直接决定 Agent 的执行路径。我踩过不少坑，最大的一个教训是：你如果只告诉它“帮我把这个网站的数据接口找出来”，它可能会很努力地分析 HTML，但忽略了你真正需要的加密参数生成逻辑。

我一般在系统提示词里固定三层内容。

第一层定义身份与目标。我会写：你是一名资深的爬虫逆向工程师，你的任务是根据用户的请求，完成网页分析、加密参数定位与采集代码生成。

第二层定义任务拆解与输出格式。要求它按“先分析接口、再定位参数、最后生成代码”的顺序执行。每完成一个阶段，要输出结构化结果。这一步能让模型输出更稳定，而不是一上来就给你一大段代码。

第三层定义行为边界与重试策略。比如遇到验证码不要自动尝试绕过，要先暂停分析，把页面验证码问题反馈给用户。遇到加密签名无法还原时，优先评估用浏览器执行页面内函数的方式替代，不要在纯 Node 环境里死磕。

下面是我目前比较常用的一套提示词骨架，你可以参考。

你是爬虫逆向工程师。你的工作流程： 1. 分析目标页面，列出所有数据接口（URL、请求方法、关键参数）。 2. 对每个接口，判断哪些参数需要动态生成（如签名、令牌）。 3. 定位这些参数的来源：优先在JS源码中搜索参数名，搜索时使用代码搜索工具。 4. 如果参数计算过于复杂或代码已混淆，不要尝试还原算法，而是评估是否可以通过浏览器执行页面内函数获取。 5. 生成可运行的采集脚本，运行后将报错信息返回给你自己并自动修复，直到通过。 约束： - 不得绕过身份验证，不得采用攻击性手段。 - 每次工具调用前，先简述你的判断依据。 - 最终输出包含：关键接口表、参数来源说明、采集脚本用法。

这套提示词的核心价值是，它把“怎么干活”这件模糊的事情，变成了一个带检查点的执行流程。实测下来，Agent 跑偏的概率大幅下降。

3.3 工具侧配置：浏览器自动化的关键参数

浏览器自动化是整个 Agent 体系里最容易被低估的一环。如果你的目标网站没有复杂的加密，严格来说不用浏览器自动化也能抓数据，但一旦涉及动态签名、登录态、验证码，无头浏览器反而是最稳的“解释器”。

我用的浏览器自动化工具是 Playwright。它比早期方案稳定得多，而且内置了网络事件监听。启动配置里有几个参数需要注意一下。

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch( headless=True, args=[ "--disable-blink-features=AutomationControlled", "--window-size=1440,900" ] ) context = browser.new_context( viewport={"width": 1440, "height": 900}, user_agent=( "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/121.0.0.0 Safari/537.36" ), locale="zh-CN" ) page = context.new_page() requests_log = [] def on_request(flow): if flow.request.resource_type in ("xhr", "fetch"): requests_log.append({ "url": flow.request.url, "method": flow.request.method, "headers": dict(flow.request.headers), "post_data": flow.request.post_data }) page.on("request", on_request) page.goto("https://目标站点/商品列表", wait_until="networkidle") print(requests_log)

参数选择上有一个容易被忽略的细节：--disable-blink-features=AutomationControlled这个参数的作用是关闭浏览器自动化的特征标记，避免网站通过window.chrome相关属性识别出自动化环境。另外，headless=False有时候比无头模式更稳，因为现在的无头浏览器依然比有头模式更容易暴露特征。如果你在采集过程中频繁遇到空白页或异常的验证码弹出，可以优先尝试改用有头模式，配合虚拟显示器使用。

3.4 任务编排与人工接管点

顺着 ReAct 循环说到这，还有一件事想强调：人工的参与是必要的，但是参与方式要进行调整。与其每一步都盯，不如设计几个固定的检查点。

第一个检查点是接口清单确认。Agent 会列出它找到的所有数据接口，这个阶段最值得人工过一遍，避免它抓错了页面核心的接口，尤其是滚动加载场景下，数据接口和页面信息接口很容易混淆。

第二个检查点是参数来源说明。Agent 需要针对你重点关注的参数给出定位依据，比如它是在哪一段 JS 里发现的，或者它是根据什么判断这是一个动态参数。这一步能帮你判断它的结论可不可信。

第三个检查点是最终脚本的运行结果。脚本能跑通不代表能稳定跑。建议再让 Agent 做一轮重复性测试，连续跑几次没有出现偶发失败，才能放到正式环境去用。

这三个检查点会额外花掉一些时间，但能明显降低 Agent 乱跑带来的返工成本。

4. 电商平台实战记录

4.1 任务目标与站点分析

纸上谈兵讲了半天，不如直接还原一个实战案例。这个案例来自我近期接手的一个模拟项目，我称之为某电商平台。目标很简单：采集某个商品分类下的商品ID、标题、价格和销量。

这个站点有一个很明显的特点：前端渲染依赖数据接口，直接爬 HTML 只能拿到框架空壳。数据分析请求时，发现所有数据接口都带着一个动态签名参数X-Sign，并且每次刷新页面签名都会变化。

用传统思路来看，核心问题在于弄清楚这个签名是怎么产生的。放在以前，我会打开Sources面板全局搜索X-Sign，然后开始一段漫长的断点调试之旅。这次我直接把任务交给了 Agent 来处理。

4.2 Agent 执行过程全还原

我把 Agent 接上浏览器自动化工具，让它打开这个商品列表页，并监听所有网络请求。

第一轮执行中，Agent 很快拿到了数据接口清单。它发现真正返回商品数据的接口是/api/v1/search，参数里有一个X-Sign和t时间戳。它接着做了这样的判断：t是毫秒时间戳，X-Sign是动态计算值，下一步应该搜索和签名相关的 JS 代码。

第二轮，Agent 调用了代码搜索工具，在有映射关系的源码中搜索X-Sign和sign关键词。搜索结果显示它出现在压缩后的配置文件中。它提取了相关代码片段，发现签名是由一个通用加密函数计算出来的，输入参数包括时间戳、请求路径和一个固定密钥。

这里出现了一个有意思的场景：Agent 没有尝试去逆向通用加密函数的完整实现，而是评估了一下还原成本，然后决定走另一条路。它在分析后输出了一句话，大致意思是“该函数涉及多个加密库的调用，且依赖浏览器环境对象，还原风险较高，建议使用页面执行方式获取”。

于是第三轮，Agent 切换到 Node 执行流程，在浏览器环境里直接调用了页面暴露的数据访问方法，拿到了带签名的完整请求，然后把签名塞回 Python 脚本的请求头里，成功就跑通了接口。

从启动到出结果，整个过程大约用了二十多分钟。放到我以前靠人肉逆向，这个站点至少需要半天到一天。而且中间 Agent 的所有操作都有记录，我可以在检查点上直接复查。

4.3 关键产出：采集脚本与运行验证

最终 Agent 交付的代码整体逻辑并不复杂，结构也清晰。核心思路是请求签名执行一次浏览器调用，然后普通数据用标准 API 请求处理。

import time import requests from playwright.sync_api import sync_playwright PAGE_URL = "https://目标站点/商品分类?keyword=手机" def fetch_signed_url(path, params): with sync_playwright() as p: browser = p.chromium.launch(headless=True) page = browser.new_page() page.goto(PAGE_URL, wait_until="networkidle") signed_params = page.evaluate( "() => window._signProvider.getSignature({path, params})", {"path": path, "params": params} ) browser.close() return signed_params def collect_products(): signed = fetch_signed_url("/api/v1/search", {"keyword": "手机", "page": 1}) resp = requests.get( "https://目标站点/api/v1/search", params={**{"keyword": "手机", "page": 1}, **signed} ) data = resp.json() return [ { "id": item["id"], "title": item["title"], "price": item["price"], "sales": item["sales"] } for item in data["items"] ] if __name__ == "__main__": products = collect_products() print("采到商品数量:", len(products)) print(products[:3])

这个方案有一个明显的取舍点：每个接口请求都要先启动一个浏览器实例去获取签名，性能开销不算低。实际部署时，我更建议将它做成带缓存的服务，比如缓存签名后只要时间戳在有效期内就直接复用，或者用长驻浏览器页面轮询签名。Agent 在首次交付时用的是最简单的直连方案，这也符合它“先跑通再优化”的执行风格。

4.4 这个案例的“为什么能成”复盘

这个站点能快速拿下，有几个客观条件起了作用。第一，它的签名函数入口相对集中，没有大量分布在各模块里，Agent 搜索定位比较顺利。第二，页面暴露了可以直接调用的签名提供方，省去了复杂的算法还原环节。第三，签名本身没有绑定某一用户态会话，不需要登录就能获取。

如果换一个更硬的站点，例如把签名打散在多个入口、绑定登录状态、加一轮行为验证，Agent 的自动化率会明显下降，人工参与的权重就会增加。所以“秒杀一切网站逆向”这个说法要打点折扣，更准确的说法是“能在大多数常规站点上做到高效率替代人肉逆向”。

5. 常见问题与排查实录

5.1 Agent 分析结论与事实不符

这是 Agent 模式最常遇到的问题，而且隐患不小。我遇到过 Agent 信誓旦旦地告诉我某个参数是时间戳加密生成的，结果一验证，发现它其实是服务端下发的会话标识。如果全信它的结论，可能整个方案就做歪了。

经验是永远要求 Agent 给结论附上证据。我会在提示词里强制要求“每一个判断必须附带代码片段或接口返回的原文”，这样就算它判断错了，我也能顺着线索快速纠正。另外，在关键节点上用人工检查点去卡住流程，比事后发现问题再返工要高效得多。

5.2 签名参数失效

很多网站的签名会绑定时间戳和当前会话状态，因此 Agent 生成的采集脚本可能第一次跑得很顺利，几分钟后就报鉴权失败。这种情况大多是缓存策略出了问题。

排查思路很简单。第一步，先确认签名里的时间戳是否硬编码了，如果是，改成每次请求时动态获取。第二步，确认浏览器执行的签名函数是否依赖页面内的登录态，如果依赖，就要在运行时保持同一份会话。第三步，检查签名是否绑定了请求目标 URL，如果绑定，就要求所有请求使用固定的 URL 模板。实践中，这三个原因覆盖了大部分签名失效的场景。

5.3 验证码与风控拦截

这套方案一旦跑频次上去，就很可能撞到验证码。Agent 遇到验证码时，如果任务里没做约束，它有可能会尝试一些自动填充行为，这个方向我不建议。

更合理的做法是让 Agent 识别出验证码后直接切换到人工验证流程。比如设置一个等待机制，给页面插入人工介入的暂停点，人输完验证码后再让 Agent 继续。实测下来，这种方式既合规，也不会频繁把任务跑废。

5.4 偶发反爬导致的空数据

还有一种情况是 Agent 把页面跑通了，但是数据偶尔为空，或者返回来的数据缺少关键字段。这一步常被当成脚本 bug 去排查，但根源往往是测试环境的访问频率太高，触发了数据降级返回。

遇到这种情况，我会先让 Agent 把连续十次请求的响应状态码和返回体积做一次汇总。如果响应里出现常见的风控提示词，就说明不是代码问题，而是需要降低频率或换策略。把采集间隔从几百毫秒调到两秒以上，往往能稳定不少。

下面整理一份高频问题速查表，方便你在遇到类似情况时快速对照。

6. 一些更低成本的替代方案

6.1 轻量级 Agent：单模型多工具

如果你不想维护一套复杂的自动化链路，也可以做一个简化版。核心思路是：不用浏览器自动化，而是把网络请求和 JS 执行接口直接封装成工具给模型调用。

这种方案适合目标站点前端逻辑并不复杂、但请求头里带着若干自定义参数的场景。比如你面对的是一个接口参数由简单拼接和时间戳生成的站点，就不必大费周章启动无头浏览器。让 Agent 调用一个 Node 执行工具去运行一小段 JS，再调用一个 HTTP 请求工具去直接请求接口，也能形成类似 ReAct 的闭环。

这样的轻量版跑起来更清爽，成本也低。但它有一个硬前提：目标站点必须允许纯代码方式请求。一旦加密逻辑依赖浏览器环境能力，比如navigator对象、Canvas指纹或者完整的 DOM 树，这个方案就会报废。

6.2 什么时候不需要 Agent

这里说点实在话，并不是所有爬虫需求都需要上 Agent。如果你面对的目标就是一个静态页面，没有任何动态加密参数，接口直接明文返回数据，那用普通脚本反而更高效。Agent 的价值在于自动化处理“有不确定性”的任务，如果任务本身确定得不能再确定，引入模型和循环反而是浪费。

还有一个判断角度是维护成本。Agent 方案的运行依赖大模型服务，跑一次任务要消耗不少 Token。一个需要频繁重新分析的长线采集任务，如果把分析成本换成固定脚本加人工兜底，综合成本可能更低。我的习惯是先评估目标站点变动频率。一天变一次以上的，上 Agent 才值得；十天半个月都不变的，就不必凑热闹了。

6.3 从 Agent 方案沉淀人工经验

最后补一个我认为最有价值的习惯。Agent 每次成功分析出目标站点的逻辑，不要让它跑完就结束。把它的分析结论、关键代码片段、签名处理方式整理成一份文档，沉淀到团队的知识库里。下一次再遇到类似结构的站点，直接拿文档里的模板去套，效率能再上一个台阶。

我之前维护过一个站点列表，里面记录了每个站点的签名类型、加密入口、绕行方案和风险等级。这份文档有一半内容是从 Agent 的执行日志里提炼出来的。后来接手的新同学遇到问题，第一件事不是去重新逆向，而是先去查文档，极大地减少了重复劳动。

最后说点个人体会

Agent 这套工作流，从一开始的“自嗨实验”到现在能出现在我的日常生产环境里，本质上是重新理解了爬虫逆向这件事。以前的思路是“我要把加密逻辑彻底还原清楚再做采集”，现在的思路变成了“我只关心能不能稳定拿到准确的数据，用什么方式拿到并不重要”。这样一种导向上的转变，才是 Agent 模式真正厉害的地方。

如果你是第一次接触 Agent，我建议不要急着搭一个特别庞大的框架。先选一个你自己业务里最常碰到的简单站点，把浏览器自动化和工具调用跑通，让 Agent 帮你完成一次完整的分析循环。你会在这个过程里感受到它哪些判断靠谱、哪些环节还离不开人。

最后再分享一个小技巧。如果你准备长期维护一套 Agent 逆向系统，一定要把工具返回的上下文压缩成一个统一格式。我的做法是所有工具返回前都会先转成 JSON，并且只保留和任务相关的字段。这一步看起来不起眼，但能让 Agent 的分析效率提升一大截。工具返回的数据太占上下文，大模型反而会被噪声干扰，误判率直线上升。祝你在自动化采集这条路上少踩坑，多拿结果。