1. 为什么要把 Android 逆向塞进 AI Agent 的工作流里做 Android 逆向这些年我最大的感受不是技术难而是流程碎。一个中等难度的 APK从拿到包到定位关键逻辑中间要经历解包、反编译、抓包、动态调试、Hook 验证、算法还原这一长串动作每一步用的工具都不一样每一步的产出格式也不一样。apktool 吐出来的是 smalijadx 吐出来的是 Java 伪代码Frida 的脚本又是另一套 JS 逻辑中间还得自己拿小本本记“这个类在哪个 dex”“这个字符串被谁引用了”。一个人做还行一旦想把这套东西交给团队或者交给自动化流程立刻就乱套了。apk-reverse这个项目标题吸引我的地方就在于它想干的事情不是再写一个反编译工具而是把逆向工程这件事本身抽象成一套 AI Agent 可以执行的完整工作流。这个定位很关键。市面上反编译工具已经足够多了jadx、apktool、Ghidra、IDA 各有所长缺的从来不是“能不能反编译”而是“反编译完之后谁来串起来”。AI Agent 在这里扮演的角色不是替代逆向工程师的判断而是把那些重复的、有固定套路的、需要来回切换工具的动作固化下来让 Agent 按步骤去执行、去汇总、去交叉验证。我先把话说在前面这套东西适合谁如果你是完全没碰过 Android 的小白直接上 Agent 工作流会一头雾水因为你连 smali 和 Java 的对应关系都还没建立起来Agent 给你的结论你没法判断对错。它真正适合的是已经会手动逆向、但被重复劳动拖累的人以及想把逆向能力产品化、流程化的团队。你要先知道手动怎么做才能判断 Agent 哪一步做对了、哪一步跑偏了。这也是我后面所有内容的前提。从热搜词也能看出来大家关心的方向很集中ai agent 搭建、ai agent 主流架构、工作流编码、轻量级工作流、逆向工程游戏逆向。这些词拼在一起其实勾勒出了一个很清晰的需求画像——用轻量级的 Agent 架构把逆向工程这种重手工的活编码成可复用的工作流。我接下来就按这个思路把整个项目的设计、拆解、实操和踩坑一层层讲清楚。2. 整体架构设计Agent 工作流到底该怎么分层2.1 逆向工程为什么天然适合工作流化先想一个问题为什么逆向工程适合做成工作流而不是做成一个“一键出结果”的黑盒工具因为逆向的本质是信息逐步收敛的过程。你一开始面对的是一个黑盒 APK什么都不知道通过静态分析你知道了有哪些类、哪些字符串、哪些权限通过动态分析你知道了运行时调用了什么、网络请求长什么样通过 Hook 你验证了某个函数的输入输出。每一步都在缩小范围每一步的产出都是下一步的输入。这种“链式收敛”的结构恰好就是工作流最擅长表达的东西。工作流的本质是什么是有向的、带状态的、可分步验证的任务图。逆向的每一步都可以定义成图上的一个节点节点之间有明确的输入输出契约。比如“解包”节点的输出是目录结构“反编译”节点的输入是 dex 文件、输出是 Java 源码“字符串提取”节点的输入是资源文件、输出是候选关键字符串列表。一旦你把每个节点定义清楚Agent 就可以按图索骥地执行而不是每次都靠人脑去记下一步该干嘛。我个人的判断是逆向工程里大概有60% 到 70% 的工作是可以被工作流固化的剩下的 30% 才是真正需要人类直觉和经验的部分比如判断某个混淆后的控制流到底在干什么、某个加密算法是不是魔改过的标准算法。Agent 工作流的目标不是吃掉那 30%而是把那 70% 做扎实让人能把精力集中在真正难的地方。2.2 三层架构工具层、编排层、决策层我在设计这类工作流的时候习惯把它拆成三层这个分层方式在apk-reverse这种项目里同样适用。工具层是最底下的一层负责“干活”。apktool 负责解包和重打包jadx 负责反编译成 Javabaksmali 负责 smali 层面的处理Frida 负责动态注入mitmproxy 负责流量抓取。这一层的每个工具都是独立的、可单独调用的它们不关心自己被谁调用、为什么被调用。工具层的设计原则是单一职责、输入输出明确一个工具只干一件事干完把结果放到约定的位置。编排层是中间层负责“调度”。它知道整个逆向流程分几步、每步调用哪个工具、上一步的产出怎么传给下一步、哪一步失败了该怎么重试。编排层是工作流的骨架它把工具层那些零散的能力串成一条线。这一层通常用工作流引擎来实现可以是轻量的脚本编排也可以是带状态管理的图执行引擎。编排层的关键是状态管理——逆向过程中会产生大量中间产物哪个产物已经生成、哪个还没生成、哪个需要重新生成这些状态必须被准确记录否则工作流跑到一半就乱了。决策层是最上面一层也是 AI Agent 真正发挥价值的地方。它负责“判断”。比如反编译出来几千个类哪些值得深入看字符串提取出来几百条哪些像是密钥、哪些像是接口地址抓到的流量里哪些请求的参数是加密的、哪些是明文的这些判断如果全靠规则写死维护成本极高交给 Agent 来做它可以根据上下文灵活判断还能给出判断理由。决策层的设计原则是可解释、可回溯Agent 做的每个判断都要留下痕迹方便人工复核。这三层的关系是决策层告诉编排层“下一步做什么”编排层调用工具层“去执行”工具层把结果返回给编排层编排层再把结果喂给决策层“做判断”。一个完整的闭环。2.3 为什么选轻量级工作流而不是重型框架热搜里有个词叫轻量级工作流这个选择我认为是对的。逆向工程的工作流有个特点步骤不算特别多但每步的产出都很大。一个 APK 反编译出来可能是几百 MB 的源码抓包抓一天可能是几万条请求。如果你用重型框架光是状态序列化和反序列化的开销就够呛而且重型框架往往有很强的“约定”你想在中间插一个自定义的 Hook 验证步骤改起来很别扭。轻量级工作流的好处是灵活、可控、好调试。你可以用最朴素的方式——一个主控脚本加若干子脚本——来实现编排状态就用文件系统来存每个节点的产出落到一个约定目录里。这种方式看起来土但实测下来非常稳因为文件系统本身就是最好的状态存储你随时可以进去看中间产物出问题了直接定位到某个文件。我见过太多人一上来就上重型框架结果调试成本比开发成本还高最后工作流没跑通时间全花在跟框架较劲上了。提示轻量级不等于简陋。轻量级工作流同样需要明确的节点定义、输入输出契约和错误处理只是实现手段更朴素。别把“轻量”理解成“随便写写”。3. 核心环节拆解从 APK 到可执行工作流的每一步3.1 静态分析节点的设计要点静态分析是整个工作流的起点也是最容易做扎实的一环。我把静态分析拆成几个独立的节点每个节点负责一类信息的提取。第一个节点是解包与结构解析。用 apktool 把 APK 解开得到AndroidManifest.xml、res/资源目录、smali/代码目录、assets/和lib/等。这一步的产出是标准化的目录结构后续所有节点都基于这个结构工作。这里有个细节要注意apktool 解出来的AndroidManifest.xml是解码后的可读 XML而原始 APK 里是二进制格式如果你需要对比原始文件得单独保留一份。另外lib/目录下的 so 文件是 native 代码静态分析阶段先标记出来留给后续的 native 分析节点处理。第二个节点是反编译与代码索引。用 jadx 把 dex 反编译成 Java 源码同时生成一个类名、方法名、字符串的索引。这个索引非常关键它是后续 Agent 做判断的基础数据。索引里至少要包含每个类的完整路径、每个方法的签名、每个字符串常量及其所在位置。有了这个索引Agent 在分析某个功能时就能快速定位到相关代码而不是在几千个文件里瞎翻。第三个节点是敏感信息扫描。这一步用规则加 Agent 判断的方式扫描代码和资源里的敏感信息。规则部分负责扫那些格式固定的东西比如 URL、IP、邮箱、AK/SK 这类有明确模式的字符串Agent 部分负责扫那些格式不固定但语义敏感的东西比如硬编码的密钥、加密盐值、调试开关。我实测下来纯规则扫描的误报率很高因为很多字符串看起来像密钥其实是测试数据加上 Agent 的语义判断之后准确率能提升不少。第四个节点是权限与组件分析。从AndroidManifest.xml里提取所有声明的权限、Activity、Service、Receiver、Provider分析哪些组件是导出的、哪些权限是危险的。这一步的产出是一张组件关系图对后续理解 App 的整体行为很有帮助。比如你发现某个导出的 Provider 没有权限保护那它很可能就是一个攻击面。3.2 动态分析节点的设计要点静态分析看的是“代码写了什么”动态分析看的是“代码实际跑了什么”。两者必须结合因为静态分析会被混淆和动态加载骗过去而动态分析能看到真实的运行时行为。动态分析的第一个节点是环境准备与注入。这一步要准备一台可调试的设备或模拟器把目标 App 装上去然后用 Frida 把探针注入进去。注入的探针分几类一类是 Hook 关键 API比如网络请求、文件读写、加密函数一类是 Hook 目标 App 自己的方法这个需要先通过静态分析找到候选方法一类是内存扫描用来找运行时才解密出来的字符串。这里有个坑很多 App 有反调试和反注入检测直接注入会被发现需要先做一些对抗处理比如隐藏 Frida 的特征、绕过 ptrace 检测。这部分内容比较敏感我只说思路具体实现大家自己研究。第二个节点是流量抓取与分析。用抓包工具把 App 的网络请求抓下来分析请求结构、参数格式、加密方式。这一步和静态分析是互补的静态分析告诉你“有个加密函数叫 encrypt”动态分析告诉你“这个 encrypt 函数的输入是这些参数、输出是那个密文”。两者一对照加密逻辑就清楚了。抓包的时候要注意证书绑定SSL Pinning很多 App 会校验服务端证书直接抓会失败需要先绕过校验。第三个节点是行为记录与回放。把 App 在特定操作下的行为完整记录下来包括调用了哪些方法、传了什么参数、返回了什么结果、发了哪些网络请求。这个记录是后续做算法还原和协议复现的基础。我习惯把行为记录做成结构化的日志每条记录包含时间戳、调用栈、输入输出方便后续检索和对比。3.3 Agent 决策节点的设计要点前面两个环节是“干活”这个环节是“动脑”。Agent 决策节点要解决的核心问题是面对海量信息怎么快速找到有价值的线索。第一个决策场景是关键代码定位。反编译出来几千个类不可能一个个看。Agent 要根据任务目标从索引里筛选出候选类。比如任务是“找到登录接口的加密逻辑”Agent 就会优先看名字里带 login、auth、sign、encrypt 的类看调用了加密 API 的类看和网络请求相关的类。筛选出候选之后再逐个分析给出每个候选的可疑程度和理由。第二个决策场景是加密算法识别。逆向里最常见的任务之一就是还原加密算法。Agent 拿到一段可疑代码后要判断它是不是标准算法、是不是标准算法的变种、还是完全自定义的。判断依据包括常量表比如 AES 的 S 盒、MD5 的初始向量、运算结构比如循环移位、异或、模运算、调用关系比如调用了MessageDigest还是自己实现的。我实测下来Agent 对标准算法的识别准确率很高对变种的识别需要人工复核对完全自定义的算法基本只能给出“这是自定义算法”的结论具体逻辑还得人来啃。第三个决策场景是分析路径规划。逆向是个探索过程下一步该看哪里很大程度上取决于上一步发现了什么。Agent 要根据当前掌握的信息规划下一步的分析方向。比如发现了一个可疑的 native 库下一步就应该去分析这个 so 文件发现了一个动态加载的 dex下一步就应该去 dump 这个 dex。这种路径规划能力是 Agent 相比固定脚本最大的优势。3.4 节点之间的数据契约怎么定工作流能不能跑通很大程度上取决于节点之间的数据契约定得好不好。我踩过的坑里有一大半是数据格式不统一导致的。我的做法是所有节点的产出都落到文件系统用统一的目录结构和命名规范。比如每个分析任务建一个工作目录目录下按节点名建子目录每个子目录里放该节点的产出。产出的格式尽量用结构化数据比如 JSON、CSV避免用纯文本因为纯文本后续解析起来很痛苦。节点之间的传递用“引用”而不是“拷贝”。比如反编译节点产出的源码目录后续节点只需要知道这个目录的路径不需要把源码内容复制一遍。这样既省空间又避免了数据不一致的问题。还有一个细节每个节点的产出都要带元信息包括生成时间、使用的工具版本、输入是什么、有没有报错。这些元信息在排查问题时非常有用。我遇到过好几次工作流跑出来的结果不对最后发现是某个工具的版本变了导致输出格式变了如果有元信息记录一眼就能定位到问题。4. 实操过程手把手搭一个最小可用的逆向工作流4.1 环境准备与工具链安装先把工具链装齐。我列一下最小可用集合以及每个工具的用途和安装方式。工具用途安装方式备注apktool解包/重打包 APK官网下载 jar 包需要 Java 环境jadxdex 反编译为 JavaGitHub release 下载有命令行版和 GUI 版baksmalidex 反编译为 smali官网下载 jar 包和 apktool 配合使用Frida动态注入与 Hookpip 安装需要设备端 servermitmproxy流量抓取pip 安装需要配置证书Python 3.10编排脚本系统包管理器建议用虚拟环境安装的时候有几个坑要注意。apktool 的版本要和目标 APK 的格式匹配太老的版本解不了新格式的包。jadx 的内存占用比较大反编译大 App 的时候要给它足够的堆内存我一般设成 4G 起步。Frida 的版本要和设备端 server 的版本严格一致不一致会连不上。mitmproxy 的证书要装到系统证书区装到用户证书区在新版本 Android 上会被忽略。注意工具链的版本管理很重要。建议把每个工具的版本号记录在一个配置文件里工作流启动时先检查版本不匹配就报警。我吃过版本不一致的亏排查了大半天才发现是工具升级导致的。4.2 编排脚本的骨架实现编排脚本我用 Python 写核心思路是“节点函数 状态检查 顺序执行”。下面是一个简化版的骨架展示核心结构。import os import json import subprocess from pathlib import Path class ReverseWorkflow: def __init__(self, apk_path, work_dir): self.apk_path apk_path self.work_dir Path(work_dir) self.state_file self.work_dir / state.json self.state self.load_state() def load_state(self): if self.state_file.exists(): return json.loads(self.state_file.read_text()) return {completed: [], artifacts: {}} def save_state(self): self.state_file.write_text(json.dumps(self.state, indent2)) def run_node(self, name, func): if name in self.state[completed]: print(f[skip] {name} already done) return self.state[artifacts].get(name) print(f[run] {name}) result func() self.state[completed].append(name) self.state[artifacts][name] result self.save_state() return result def node_unpack(self): out_dir self.work_dir / unpacked subprocess.run([ apktool, d, -f, -o, str(out_dir), self.apk_path ], checkTrue) return str(out_dir) def node_decompile(self): out_dir self.work_dir / decompiled subprocess.run([ jadx, -d, str(out_dir), self.apk_path ], checkTrue) return str(out_dir) def node_index(self): decompiled self.state[artifacts][decompile] index build_index(decompiled) index_file self.work_dir / index.json index_file.write_text(json.dumps(index, indent2)) return str(index_file) def execute(self): self.run_node(unpack, self.node_unpack) self.run_node(decompile, self.node_decompile) self.run_node(index, self.node_index) # 后续节点按需添加这个骨架的核心是run_node方法它做了三件事检查节点是否已完成、执行节点函数、记录状态。状态记录用 JSON 文件简单可靠。每个节点函数只关心自己的逻辑不关心被谁调用、什么时候调用这样节点之间就解耦了。build_index函数负责从反编译结果里提取类名、方法名、字符串生成索引。这个函数的具体实现比较长核心逻辑是遍历反编译目录下的所有.java文件用正则或 AST 解析提取信息。我建议用 AST 解析而不是正则因为正则处理不了复杂的代码结构容易漏掉或误匹配。4.3 接入 Agent 做智能判断编排脚本跑通之后下一步是把 Agent 接进来做判断。接入的方式有两种一种是把 Agent 作为一个节点输入是前序节点的产出输出是判断结果另一种是把 Agent 作为编排的“大脑”由它来决定下一步执行哪个节点。第一种方式简单可控适合刚起步的时候用。比如加一个node_scan_secrets节点输入是反编译目录输出是敏感信息列表。这个节点内部调用 Agent把代码片段喂给 Agent让 Agent 判断哪些是敏感信息。def node_scan_secrets(self): decompiled self.state[artifacts][decompile] candidates extract_candidates(decompiled) # 规则初筛 results [] for cand in candidates: verdict call_agent( prompt判断以下代码片段是否包含硬编码密钥或敏感信息 给出判断和理由\n cand[code], contextcand ) if verdict[is_sensitive]: results.append({**cand, reason: verdict[reason]}) out_file self.work_dir / secrets.json out_file.write_text(json.dumps(results, indent2)) return str(out_file)第二种方式更灵活但实现难度也更大。它需要 Agent 维护一个“当前分析状态”根据状态决定下一步。这种方式适合分析路径不固定的场景比如探索性的逆向。实现的时候要注意给 Agent 设定明确的“可执行动作集合”不能让它在无限的动作空间里瞎选否则很容易跑偏。我个人的建议是先用第一种方式把流程跑通再逐步引入第二种方式。一上来就搞全自动的 Agent 决策很容易因为 Agent 判断失误导致整个流程卡死而且排查起来很痛苦。4.4 结果汇总与报告生成工作流跑完之后要把各个节点的产出汇总成一份可读的报告。报告的内容包括App 基本信息、权限列表、组件列表、敏感信息列表、关键代码片段、加密算法识别结果、网络请求样本、分析结论。报告生成这个环节看起来简单其实很考验设计。我的经验是报告要分层先给结论再给证据。结论部分用一两句话概括发现了什么证据部分附上具体的代码片段、请求样本、日志记录。这样读报告的人可以先看结论感兴趣再往下看证据效率高很多。报告格式我推荐用 Markdown因为 Markdown 既能表达结构又能嵌入代码块和表格而且方便后续转换成其他格式。生成报告的时候把每个节点的产出按预设的模板填充进去就行。模板要留出“人工补充”的位置因为 Agent 的判断不可能 100% 准确总有一些地方需要人工复核和补充。5. 常见问题与排查技巧实录5.1 工作流跑不通的典型原因工作流跑不通十有八九是下面几个原因之一。我整理成表格方便对照排查。现象可能原因排查方法解决方式解包失败apktool 版本不匹配看报错信息里的格式版本升级 apktool反编译卡死jadx 内存不足看进程内存占用加大堆内存参数注入失败反调试检测看 Frida 日志做对抗处理抓包失败证书绑定看 App 是否校验证书绕过证书校验Agent 判断跑偏提示词不清晰看 Agent 的输入输出优化提示词状态错乱中间产物被手动改动对比 state.json 和实际文件清理状态重跑这里面最容易被忽视的是状态错乱。有时候你手动改了一个中间产物想看看效果结果工作流下次跑的时候以为这个节点已经完成了直接跳过用的还是旧产物。这种问题很隐蔽因为工作流不报错只是结果不对。我的做法是任何手动改动都要同步更新 state.json或者干脆清空状态重跑。5.2 Agent 判断不准怎么调Agent 判断不准通常不是模型能力问题而是上下文给得不够或者提示词写得不好。我总结了几个调优方向。第一给足上下文。判断一段代码是不是加密逻辑光看这段代码本身不够还要看它被谁调用、调用了谁、周围的代码是什么。把调用链和上下文一起喂给 Agent准确率会明显提升。第二明确判断标准。不要问 Agent“这段代码可疑吗”这种问题太开放Agent 的回答会很飘。要问“这段代码是否包含以下特征之一硬编码密钥、自定义加密、动态加载、反射调用”把判断标准列清楚Agent 的回答就稳定多了。第三要求给出理由。让 Agent 不仅给结论还要给理由。理由本身可能不完美但能帮你判断 Agent 是不是真的看懂了代码还是在瞎猜。如果理由明显不对那结论也不可信。第四分步判断。复杂的判断拆成几步每步只判断一个维度。比如先判断“这段代码有没有加密特征”再判断“如果有是标准算法还是自定义算法”最后判断“如果是标准算法是哪种”。分步判断比一步到位准确率高很多。5.3 性能与并发问题热搜里有个词叫ai agent 怎么扛并发这个问题在逆向工作流里同样存在。逆向的很多步骤是 CPU 密集型的比如反编译、索引构建、代码扫描这些步骤如果串行执行一个大 App 跑下来可能要几十分钟。我的做法是把可以并行的节点并行化。比如反编译和资源解析可以并行因为两者互不依赖多个文件的敏感信息扫描可以并行因为文件之间互不依赖。并行的实现方式可以用多进程也可以用多线程看具体任务的类型。CPU 密集型的用多进程IO 密集型的用多线程。但并行不是越多越好。我实测下来并行度设成 CPU 核心数的 1.5 倍左右比较合适再高反而会因为上下文切换和资源竞争导致性能下降。另外要注意有些工具本身不支持并发调用比如 apktool 同时跑多个实例可能会冲突这种工具就得串行。还有一个容易被忽视的点Agent 调用是有成本的。如果每个文件都调一次 Agent几千个文件就是几千次调用成本和时间都受不了。我的做法是先用规则做初筛把候选范围缩小到几十个再调 Agent 做精细判断。这样既控制了成本又保证了准确率。5.4 法律与合规边界这一点必须单独说。逆向工程本身是个中性技术但它的应用场景有明确的边界。做安全研究、做兼容性分析、做自己 App 的加固验证这些是正当用途。但如果是破解别人的付费功能、窃取别人的数据、绕过别人的授权机制那就是另一回事了。我的原则是只对自己有权限的目标做逆向只做正当用途的分析。工作流本身只是工具工具没有对错用工具的人要守住底线。另外分析过程中拿到的数据要妥善保管不要泄露不要用于分析之外的用途。这些不是技术问题但比技术问题更重要。6. 这套工作流还能怎么扩展6.1 接入更多分析能力现在的工作流主要覆盖静态分析和基础动态分析还能往几个方向扩展。一个是native 层分析。很多核心逻辑藏在 so 文件里Java 层只是壳。可以把 Ghidra 或 IDA 的分析能力接进来对 so 文件做反汇编和反编译提取函数列表、字符串、调用关系。native 分析的难度比 Java 层高不少但价值也大因为核心算法往往就在这一层。另一个是协议逆向。把抓到的流量做结构化解析提取请求方法、路径、参数、响应结构然后和静态分析的结果做关联。比如发现某个请求的参数是加密的就去静态分析里找对应的加密函数两者一对照协议就还原出来了。还有一个是自动化验证。分析出某个算法之后自动写一个验证脚本用真实输入跑一遍看输出和 App 的实际输出是否一致。一致就说明算法还原正确不一致就说明还有遗漏。这个闭环能大幅提升分析结果的可靠性。6.2 工作流的复用与沉淀工作流最大的价值不是跑一次而是反复跑、跑不同的目标。所以要把工作流做成可复用的资产而不是一次性的脚本。复用的关键是参数化。把目标 APK 路径、工作目录、分析目标、Agent 提示词这些都做成参数换一个目标只需要改参数不用改代码。另外要把常见的分析套路沉淀成“模板”比如“登录加密分析模板”“协议还原模板”“加固检测模板”每个模板定义好节点顺序和判断标准用的时候直接套。沉淀的另一个维度是知识库。每次分析完把发现的算法特征、混淆手法、加固方案记录下来形成自己的知识库。下次遇到类似的目标先查知识库能省很多时间。这个知识库可以喂给 Agent让 Agent 在判断的时候参考历史案例准确率会更高。6.3 团队协作场景下的改造如果这套工作流要给团队用还需要做一些改造。首先是权限管理。不同的人能看不同的分析结果敏感的分析结论要限制访问。这个可以在工作流的输出环节加一层权限控制。其次是任务分配。一个大的逆向任务可以拆成多个子任务分给不同的人。工作流要支持任务的拆分和合并还要能追踪每个子任务的进度。最后是结果评审。Agent 的判断需要人工复核工作流要支持评审流程比如 Agent 给出结论后标记为“待复核”人工复核后标记为“已确认”或“已修正”。评审记录也要保存下来作为后续优化的依据。7. 我踩过的几个印象深刻的坑说几个具体的坑都是真金白银换来的经验。第一个坑是过度依赖 Agent 的结论。刚开始用的时候Agent 说什么我就信什么结果有一次 Agent 把一个正常的配置字符串判断成了密钥我照着去分析浪费了大半天。后来我定了个规矩Agent 的结论只能作为线索不能作为定论关键结论必须人工验证。Agent 的价值在于帮你快速缩小范围不在于替你做最终判断。第二个坑是工作流没有断点续跑能力。有一次跑一个大 App跑到反编译那一步花了四十分钟结果后面一个节点报错整个流程挂了。重新跑又得从解包开始四十分钟白费。后来我加了状态管理每个节点完成后记录状态重跑的时候跳过已完成的节点效率高了很多。这个改造看起来简单但收益巨大。第三个坑是工具版本升级导致输出格式变化。jadx 升级了一个版本输出的 Java 代码格式变了我原来写的正则解析全失效了索引构建直接报错。后来我把工具版本固定下来写进配置文件工作流启动时检查版本不匹配就报警。工具升级是好事但要在可控的前提下升级。第四个坑是忽略了中间产物的清理。逆向过程中会产生大量中间产物一个 App 分析下来可能占几十 G 空间。跑多了之后磁盘就满了工作流莫名其妙失败。后来我加了个清理节点每次分析完成后自动清理临时文件只保留最终报告和关键产物。8. 给想上手的人几句实在话如果你看到这里想自己搭一套我的建议是从最小的闭环开始。不要一上来就想着做全自动、做多 Agent 协作、做复杂的决策树。先做一个能解包、能反编译、能生成基础报告的最小工作流跑通一个真实的 APK感受一下整个流程。跑通之后再逐步加节点、加 Agent、加判断逻辑。工具的选择上能用现成的就用现成的不要重复造轮子。apktool、jadx、Frida 这些都是经过大量验证的工具直接用就好。你要造的轮子是“编排”和“判断”不是“反编译”本身。Agent 的接入上先规则后 Agent。规则能搞定的用规则规则搞不定的再上 Agent。规则便宜、稳定、可解释Agent 灵活但成本高、有不确定性。两者结合各取所长。最后保持手动分析的能力。工作流是提效工具不是替代品。你自己得会手动逆向才能判断工作流跑出来的结果对不对才能在工作流卡住的时候手动突破。工具越强人的判断力越重要这个道理在逆向这个领域尤其成立。
：RAG 发展的四种基础范式与未来趋势)
