用AI Agent重构Android APK逆向分析工作流

1. 为什么我会把 Android 逆向工程交给 AI Agent

先讲一个让我下定决心做这个项目的场景。上个月我需要分析一个第三方 App 的资源文件结构和签名信息，整个流程说起来不复杂：解包、看 AndroidManifest、拉签名、确认目标 SDK 版本和权限声明，再定位几个关键字符串。但真正动手的时候，我发现自己在一遍又一遍地重复敲同样的命令，而且每换一个目标 App，都得重新走一遍这串流程。

当时我脑子里冒出来的想法是：这套流程明明已经高度固定了，为什么不把它写成一个 AI Agent 可以理解、可以执行的工作流？让 Agent 自己跑命令、读产物、做判断，我只负责给方向和审核结果。

事实上，apk-reverse这个方向并不是什么新东西，把单个 ApkTool 命令或者 jadx 反编译脚本写出来的人很多。但把整条逆向链路——从解包、配置解析、代码反编译、资源提取、签名校验到最终报告生成——作为一条可编排、可复现、可被 Agent 驱动的工作流来做，目前还很少有人系统性地整理。这篇内容就是想把这套工作流完整拆开，讲清楚每一步为什么这么做、底层逻辑是什么、实际跑起来会遇到哪些坑，以及如何把它接入你自己的 AI Agent 架构里。

适合谁来读？如果你正在做 Android 逆向分析、移动安全测试、竞品 App 研究，或者你手里已经有一个 AI Agent 项目，正发愁怎么让它去执行真实世界里的复杂任务，这篇文章都能给你一套可以落地的参考实现。

先给个结论：把逆向工程工作流交给 AI Agent，核心价值不在于让 Agent 替你做安全研究，而在于让那些"套路固定、重复度高、出错成本低"的环节自动化，把人的精力释放到真正需要判断力的地方。

2. apk-reverse 工作流整体架构与核心模块拆解

2.1 不是让你写死脚本，而是让 Agent 可理解、可决策

很多第一次接触"AI Agent + 逆向工程"的人会有一个误解：Agent 工作流不就是把原来写好的脚本用自然语言包装一下吗？其实差别很大。

传统脚本是确定性的——输入一个 APK，跑 ApkTool，输出反编译结果，完事。Agent 工作流则要求每一步都有"感知-决策-执行-反馈"的闭环。比如解包之后，Agent 需要主动读取 AndroidManifest.xml，识别主 Activity、申请的敏感权限、目标 SDK 版本，然后根据这些信息决定下一步是去做代码审计还是做资源分析。

这就意味着，整个工作流的每一步都要有明确的输入、输出和判断条件，而不是简单地把命令串起来。我整理了一下，一个完整的 apk-reverse Agent 工作流至少需要这几个模块：

2.2 用 Rust 还是用 Python 做底座，我的取舍

我的实现里底座语言选择了 Rust。这里有个背景：AI Agent 的指令执行往往需要低延迟、高可靠、内存安全的运行环境，Python 虽然生态丰富、写起来快，但一旦涉及大型 APK 的文件解析和二进制处理，性能瓶颈很明显。Rust 在内存管理和并发上有天然优势，也能直接编译成单二进制文件丢到任何 Linux 环境里跑，对 Agent 的部署非常友好。

当然，这不代表完全抛弃 Python。实际架构里笨重的语义分析、报告格式化这类任务仍可以外抛给 Python 脚本，Rust 只负责核心链路的编排和文件处理。这种"Rust 主流程 + Python 辅助分析"的组合，是我实测下来性能和开发效率比较平衡的方案。

有人会问：为什么不能直接用现成的 Frida、ApkTool 那些工具，非要自己做一套工作流？我的回答是：工具是原子操作，工作流是编排。ApkTool 只负责把 APK 解开，但解开之后做什么、怎么做、结果怎么解读，这些是需要你自己定义的。AI Agent 的价值恰恰在编排层。

2.3 两个核心 Agent 角色的划分

我的工作流里拆了两个角色：分析 Agent和执行 Agent。分析 Agent 负责理解任务目标、拆解分析计划、读取中间产物并做推理判断；执行 Agent 负责调用具体的命令工具，比如 apkanalyzer、aapt2、jadx、ApkTool 等。

为什么拆成两个？因为它们在职责边界、运行环境、失败处理上的需求完全不同。分析 Agent 需要大模型上下文窗口、需要能看到多次执行的输出，因此采用大模型 API 或本地模型推理；执行 Agent 则是轻量级进程管理器，负责命令的启停、超时控制、退出码检查。这样就算执行 Agent 跑挂了任务失败，分析 Agent 也能根据错误信息重新生成指令，再次下发执行，形成真正的反馈闭环。

实际开发中，我会让执行 Agent 返回一个统一格式的执行结果结构：退出码、标准输出、错误输出、执行耗时。分析 Agent 拿到这个结构后，判断是继续还是纠错。这一步是整个工作流能不能"活"起来的关键。

3. 从零实现工作流：APK 信息采集与解包实操

3.1 基础环境配置

在写任何逻辑之前，先把环境拾掇干净。这个环节容易翻车——很多人以为装个 ApkTool 就能干活，真正解包的时候才发现要用的工具链比想象中多。

我目前在 Ubuntu 22.04 上跑这套工作流，核心工具清单如下：

• JDK 11 或以上（ApkTool、jadx 都是 Java 生态）
• Android SDK 构建工具（提供 aapt2、apkanalyzer）
• ApkTool（资源与 smali 解码）
• jadx（smali 转 Java 的可读源码）
• jadx-gui（人肉审计时用来浏览，Agent 模式下可不装）
• keytool 与 apksigner（签名校验）
• file、md5sum 等基础系统工具

安装那几步本身不难，但有一个细节必须提醒：环境变量要统一。比如 aapt2 在不同版本里的默认行为有差异，我碰到过明明装了 build-tools 30，但临时输入文件路径带空格导致 aapt2 直接挂掉的情况。所以路径统一走环境变量注入，别写死在脚本里。

3.2 第一步：确认这个 APK 到底是什么

这是最容易被跳过的步骤，但恰恰是最重要的。拿到一个 APK 文件，先不要急急忙忙解包，先确认三件事：

文件本身是不是合法的 zip 结构。APK 本质是 zip 压缩包，用 file 命令和 magic bytes 校验一下，能在早期拦截掉很多"伪装成 APK 的勒索病毒"或"直接改名的不良文件"。我见过有人拿到的样本根本不是 Android 安装包，结果后面每一步都在做无用功。

第二步是计算哈希值并记录。这一步看起来对分析没什么用，但对工作流的可复现性和核查很重要。你在逆向过程中得到的每一份报告，对应的样本必须是唯一确定的，哈希就是那个指纹。

第三步是用 aapt2 dump badging 快速拿包名、版本号、原生平台等基础信息。这一步的输出是整个工作流的第一层结构化数据，分析 Agent 后面做任何判断都依赖它。

3.3 解包：ApkTool 和 apkanalyzer 到底该选谁

解包这一步，我一般同时跑两套命令，产出物用途不同：

ApkTool 做完整资源解码，主要是拿到可读的 AndroidManifest.xml、资源和 smali 代码。命令很简单：

apktool d -f -o output_dir target.apk

其中-f是强制覆盖，-o指定输出目录。实测里一个 50MB 左右的 APK，ApkTool 跑完大概在 10~40 秒之间，取决于机器的磁盘和 CPU。

apkanalyzer 则是 Android 官方工具，适合拿结构化元数据。比如：

apkanalyzer manifest target.apk apkanalyzer files list target.apk

它输出的格式更加规整，方便 Agent 做后续解析。相比之下 ApkTool 输出的 AndroidManifest.xml 虽然可读性好，但遇到一些混淆过的资源命名或者特殊编码时，解析起来会麻烦些。

所以我的习惯是：用 ApkTool 做资源级解码，用 apkanalyzer 做结构级信息采集，两者互补。很多教程只讲 ApkTool 一条路，等你想自动化的时候就会哭。

3.4 动态授权目录的处理：从路径读出的攻防线索

近两年 Android 应用里大量出现一类路径：/storage/emulated/0/Android/data/包名/files/...，比如com.tencent.tmgp.sgame（王者荣耀）下的 pandora 目录。这类路径消息其实隐含了大量信息。

/storage/emulated/0是可共享外部存储的根路径，Android/data是应用私有外部目录，files是应用自己的文件子目录。一个应用把资源或缓存放到这个位置，一是为了绕过内部存储大小的限制，二是为了跨 App 共享某些数据。所以当你逆向时在代码、资源、日志里频繁看到这类路径，基本可以判断这个 App 存在文件级数据交换逻辑。

再注意一个点：/storage/emulated/0/Android/data/其实屏蔽了内部路径细节，而且新版 Android 对这块目录的访问限制越来越严。Agent 在分析这类路径的时候，不只是识别字符串，还要判断这个 App 是否有能力访问沙盒外的敏感目录，这就需要结合 Manifest 中的权限声明。

我在工作流中为这类路径专门配置了正则识别和大数据归类模块，用于判断该 App 是否存在敏感数据搬运行为。这里有个可复现经验：任何一个从外部读文件写文件的 App，都值得你重点观察它的文件读写对儿。

4. AndroidManifest 与签名信息的深度解析

4.1 Manifest 不是一张清单，而是一张地图

很多人觉得 Manifest 解析就是把所有 Activity、Service、Receiver 列出来。这没错，但只做到了 20% 的价值。

AndroidManifest.xml 在逆向分析里更像一张地图：你需要在上面找到入口、找到暗道、找到权限边界。分析 Agent 在读完 Manifest 之后，至少要输出以下几类决策数据：

• Main Activity：App 的启动入口，往往是核心业务代码的挂载点
• exported 组件：能被外部应用调起的组件，这是攻击面最大的地方
• Application 类：自定义 Application 常常承载全局初始化逻辑
• 权限申请列表：与业务无关的高危权限是典型的风险信号
• URL scheme / service 声明：深链入口，也是注入点

比如看到一个 App 申请了android.permission.QUERY_ALL_PACKAGES（查询所有已安装应用）却没申请任何存储权限，紧接着在代码里发现它遍历了所有应用信息并写入了某个/files/下的数据库，那这个 App 的行为就很值得放在显微镜下看。

所以我让分析 Agent 在拿到 Manifest 后，先做一个"组件重要性排序"，再决定从哪个组件开始深挖。这一步能让整个分析过程聚焦，不会在读无关代码上浪费时间。

4.2 签名信息：验证来源与判断篡改

签名校验是很多人会忽略的环节，尤其是自动化分析时。我总结过一句话：每次解包之前都应该知道这份 APK 是谁签的名、用的是 v1 还是 v2 签名方案，因为签名方案直接决定了某些注入手法是否可行。

用 apksigner 校验：

apksigner verify --print-certs test.apk

输出中能看到签名证书的 SHA-256 指纹。Agent 拿到指纹后可以对比在线数据库，判断这个签名的归属。如果一份 APK 的签名信息和官方版本不一致，那要么是第三方篡改包，要么是恶意重打包。分析价值完全不同。

这里有一个很常见的坑：待分析的样本可能同时包含 v1 和 v2 签名。v1 签名在 Android 7.0 以下生效，v2 在 Android 7.0 以上生效。如果你在验证的时候不看签名方案版本，直接用 v2 校验逻辑去处理，会得到一个看似"校验失败"的结果，实际只是因为样本没有 v2 签名而已。这个细节在你做 Agent 自动化时很重要，因为你不可能每次都人工去判断签名方案。

4.3 资源文件里藏着大量线索：不要直奔代码

很多新手做逆向分析，总喜欢第一时间奔着反编译出来的 Java 代码去读。我实测下来发现，真正花时间读代码之前，应该先花半小时把 res 资源目录扫一遍。资源里静态字符串经常比代码本身更能暴露业务逻辑。

举个例子，我在某个样本里发现一张文件名为cron_secret_key.png的图片资源，你以为它是图片，实际里面藏了一段 base64 编码的密钥。把这些密钥组合起来，配合外部 URL 的域名特征，基本可以拼出整个 App 的通信架构。

这部分的实现方式，我让分析 Agent 关注几个关键点：资源命名规律（是否混淆）、硬编码的 URL 与 key、so 库的命名与来源。lib/下的 so 文件命名特别有讲究，比如直接叫libprotect.so的，那基本是把壳或保护逻辑写进去了，值得优先看。

4.4 从 Android Studio 角度反视项目结构

既然在做 APK 逆向，很多人会顺手把反编译产物导入 Android Studio 里看。这招确实好用，但有个大坑：Android Studio 是基于 Gradle 工程结构的，本身不是为 smali 或反编译产物设计的。

如果你把 jadx 输出的 Java 代码直接丢进 Android Studio，工程结构大概率要报错。我的做法是，用 jadx-gui 做浏览参考，真正可编译、可查询的工程还是靠 apktool 解出来的 smali + 资源去搭。当然 Agent 模式下不需要 IDE，它只需要能可编程地读取、检索、全文搜索这些代码数据。

但反过来看，理解 Android Studio 的项目结构，反而能帮你更好地设计反编译产物的目录组织：哪些目录放哪类文件、哪些文件是资源的、哪些是代码的，都应该在设计工作流时预先规划好。Agent 不会像人一样"乱点"，它只能跟着你定义好的结构走，所以结构设计的合理性直接决定分析效率。

5. 代码反编译与关键逻辑定位：让 Agent 学会"找鱼"

5.1 反编译链路的选择与衔接

反编译是整个逆向流程中算力最密集的步骤。我主要用 jadx 来负责代码转换，但它不是银弹。

之前遇到过一个混淆得很凶的样本，jadx 的反编译结果缺失了大量方法体，很多逻辑都是空的。后来我把 smali 反编译链路加进去，用 ApkTool 产出 smali，再用脚本把对应类的 smali 字段、指令流结构化，配合 Agent 去分析。smali 虽然读起来痛苦，但它是"保真"的——不像 jadx 会因为混淆而漏掉代码。有些情况下，smali 的分析结果是唯一可靠的信息来源。

所以我目前的链路是：

1. jadx 反编译 Java 源码，给 Agent 一个大体框架
2. smali 结构化指令流，用于 jadx 失效时的深挖
3. 交叉引用分析，根据字符串、类名、包名反查逻辑位置

三条链路互相印证，Agent 就不会被单一失真结果带偏。

5.2 关键字命中：不只是搜字符串

让 Agent 在几万行代码里定位关键逻辑，最常用的手段就是关键字检索。我预置了一批模式，每次解包后都会全量扫描：

• 网络相关：http://、https://、socket、websocket、grpc
• 数据存储：sqlite、SharedPreferences、FileOutputStream、encrypted
• 安全相关：root、su、Magic、Hook、frida、xposed
• 组件调度：Intent、startActivity、content://、file://、Binder

content://这个值得多说一句。比如搜索热点词里出现的content://com.baidu.searchbox.fileprovider/baiddpath/...，这种 FileProvider 的 content URI 意味着该 App 对外开放了文件访问能力。攻击者如果能控制传入的 URI 的路径部分，就可能造成任意文件读取。工作流里必须对content://资源做高优匹配并转成分析报告。

我实际跑的时候，将关键字命中结果按"风险等级"分组，匹配到高危关键字后，Agent 会直接定位到对应代码块，再读取上下文。整个过程完全脚本化，不需要人工点开代码一行行看。这一步是 Agent 工作流里"省人"效果最明显的。

5.3 硬编码信息的提取与自动化

隐藏在各种字符串表、资源文件、代码常量里的硬编码信息，往往是高效分析的富矿。比如：

• API endpoints
• 加密密钥
• Token / Secret
• 证书指纹
• 第三方 SDK 的 appId

我在工作流里集成了一个基于正则与启发式规则的提取器，专门负责挑这些字段。它有几个规则是固定保留的：

[a-zA-Z0-9+/]{40,} -> 疑似 base64 密钥 eyJ[a-zA-Z0-9_-]+\.eyJ[a-zA-Z0-9_-]+ -> JWT AIza[0-9A-Za-z_-]{35} -> Google API Key sk-[0-9a-zA-Z]{20,} -> OpenAI 风格密钥

这套提取器跑完以后会生成一个结构化 JSON，Agent 读 JSON 来决定这些信息的用途。有一次我拿到一个样本，里面直接搜出来一个硬编码的 MySQL 连接串，这属于让我比较意外的发现——正常 App 很少会在客户端带数据库连接串。

5.4 对逆向样本中游戏型 App（如 tmgp.sgame）的分析侧重

热点词里反复出现com.tencent.tmgp.sgame，这是一类很典型的游戏 App。游戏类逆向和普通应用逆向的重心差异很大：游戏的重点分析区域包括 Lua/脚本资源目录、so 库里的热更新逻辑、内购支付的校验点、风控系统与登录态校验等。特别是 pandora 这个文件路径频繁出现，结合搜索词，我判断游戏场景中经常会有一类"模块化资源加载"框架，脚本和数据都是动态拉下来的。Agent 在分析这类路径时，要重点盯动态加载入口，比如遇到loadLibrary、DexClassLoader、PathClassLoader就得高亮。

这类逻辑在实际安全工作流里我做的是"红线提示"，即告知分析者这个位置可能涉及动态代码加载，需要人工二次确认，Agent 不直接下结论。这种"Agent 预判 + 人工复审"的分工，是做安全向工作流时比较稳妥的取舍。

6. 常见问题与踩坑记录：我替你把弯路走完

6.1 反编译后代码不全，是工具问题还是样本问题？

这个问题频率极高。先说结论：大部分情况下不是工具坏了，而是样本做了混淆或去符号化处理。jadx 在遇到指令无法映射为 Java 语法时，往往直接跳过方法体，导致代码缺失。

我有一次碰到一个样本，某个 Activity 的所有方法都为空，以为是 jadx 的 bug，后来把 apktool 拉出来看 smali，发现这个类被整体保护了——里面有大量的 native 方法调用，实际的逻辑全在 so 库里。所以如果你也遇到"代码不全"，马上切 smali 层面看，再盯一下对应的 so。

Agent 处理这个问题的逻辑可以这样写：当反编译结果里某个类 or 方法体为空时，执行 Agent 自动补充跑一遍 jadx --show-bad-code 或者直接拉 smali 片段，让分析 Agent 从这些片段里重新推理。

6.2 大型 APK 解包超时与内存溢出

一个复杂的 APK 解包，瞬时内存占用很夸张。我碰过最大的样本，jadx 内存占用跑到了 6GB 以上。如果 Agent 的执行环境内存限制了 4GB，那么任务就会因为 OOM 直接中断。

这里给几个可操作的优化方案：

• 使用 jadx 的--decompilation-mode simple降低 CPU 占用
• 设置合理的 JVM 堆大小：-Xmx2g或-Xmx4g
• 对超大 APK 优先做分模块反编译，比如只反编译某个包路径下的类
• 命令统一加超时控制，别让 Agent 吊死在一个任务上

我在工作流里专门加了一组"任务级别超时"的配置，默认单命令 120 秒超时，整个解包任务 300 秒超时。一旦超时就返回错误给 Agent，由它在预算范围内决定重试还是换方案。这个机制的引入让工作流的稳定性提高了一个量级。

6.3 Android 文件系统访问限制导致的分析盲区

如今 Android 11+ 对Android/data目录的限制越来越死，这意味着用户设备本身很难直接读取某些应用的私有数据目录。但逆向分析的对象是 APK 文件本身，那是不是就不受影响了？

其实影响很大。因为很多逆向工作需要动态调试：在设备或模拟器上安装目标 App、运行时查看文件写入、抓取网络包。如果设备系统版本太高，沙盒外的路径不让碰，动态分析难度直接翻倍。

所以我的建议是：工作流的静态分析可以兼容任何系统，但动态调试部分严格限定在 Android 10 及以下或专门调试的模拟器镜像里跑。这也是很多分析团队还在保留 Android 9/10 老设备的原因。

6.4 带壳/加固样本的处理思路

市面上主流加固厂商的壳（腾讯乐固、360、爱加密、梆梆等）会把 dex 整体加密，直接跑 ApkTool 解出来的代码全是壳的入口，看不到业务逻辑。Agent 在面对这种情况时，要有明确的"特征识别—策略切换"逻辑。

我的处理路径是：先解包看是否存在加壳特征——比如libjiagu.so、libDexHelper.so、libshell*.so等文件名，然后查Application类是不是壳的加载类。确认加壳之后，静态层面基本到此为止，直接进入脱壳配置：dump 运行时内存中的 dex 再分析。

这一步我没法给一个全自动的银弹方案，因为壳的版本和样本场景差异太大。完全自动化的脱壳仍然是一个深度研究的课题。人工介入 + Agent 辅助是这个阶段的最优解。

6.5 工作流编码：Agent 的记忆与上下文管理

最后一个常被忽略的问题是上下文。AI Agent 分析一个大工程时，如果每一步结果都塞进同一个上下文窗口，那很快就会被撑爆。我的做法是把每一阶段的产出物持久化，分析 Agent 只在需要时读取指定路径：

work_space/ meta.json # APK 基本信息 manifest.json # Manifest 解析结果 signature.json # 签名信息 reverse_source/ # 反编译产物 analysis_notes.md # 分析推理过程

这个结构也让 Agent 在断点恢复时更方便。当它跑挂了，只要拿到工作目录路径，就可以接着上一次的分析继续干，不用从头开始。这算是 Agent 化工作流和纯脚本化工具链一个很大的体验差异。

7. 让工作流接入 AI Agent 架构与后续扩展

7.1 一个最小可运行的接入示例

为了让你更直观地理解工作流如何被 Agent 驱动，我给出一个简化但可运行的接入逻辑，用 Python 写一个 Agent 调度器，调用工作流的 CLI 命令，并处理返回结果：

import json import subprocess def run_reverse_workflow(apk_path, model_api, workspace): # 第一步：初始化执行环境 env_ready = subprocess.run( ["apk-reverse", "env-check"], capture_output=True, text=True ) if env_ready.returncode != 0: return {"status": "failed", "step": "env-check", "error": env_ready.stderr} # 第二步：执行完整工作流 workflow_result = subprocess.run( ["apk-reverse", "run", apk_path, "--workspace", workspace], capture_output=True, text=True, timeout=600, ) if workflow_result.returncode != 0: return {"status": "failed", "step": "workflow", "error": workflow_result.stderr} # 第三步：读取元数据与报告，交给模型做推理 meta = json.load(open(f"{workspace}/meta.json")) manifest = json.load(open(f"{workspace}/manifest.json")) report = open(f"{workspace}/report.md").read() prompt = f""" 这是一次 Android 逆向分析的结果。 包名: {meta['package']} 版本: {meta['version']} 组件信息: {json.dumps(manifest, ensure_ascii=False)[:2000]} 分析报告: {report[:4000]} 请给出行为总结与风险等级评估。 """ reasoning = model_api(prompt) return {"status": "success", "reasoning": reasoning, "artifacts": workspace}

这个例子的核心思想是：工作流产出结构化中间文件，Agent 只负责根据这些中间文件做推理与判断。这比让 Agent 一个命令一个命令地原生执行可靠得多，因为中间文件的格式是稳定的、可验证的，不会因为命令行输出格式的改变而让 Agent 误解。

7.2 接入 Dify / Coze 这类工作流平台的思路

有不少读者问我：自己不想写代码层，能不能直接把 apk-reverse 拼接到 Dify 或 Coze 这种可视化的 Agent 工作流平台上？答案是完全可以。

思路是把你本地的 apk-reverse 封装成一个 HTTP 服务，提供一个预执行 + 反馈任务的接口。Dify 的自定义工具节点或 Coze 的插件系统都能直接调用它。大致流程是：

1. Dify/Coze 收到用户的自然语言指令，例如"分析这个 APK 的隐私风险"
2. 工作流调用 apk-reverse HTTP API，上传文件并启动分析任务
3. 服务端执行工作流，返回 JSON 格式的结果
4. 大模型解读结果，生成面向用户的分析报告

这样做的好处是复用平台上已有的 LLM 编排能力和人工审核组件，同时不用在平台里硬编码复杂的命令行逻辑。

7.3 后续扩展方向：n8n 等其他编排器的兼容

n8n 这类自动化编排工具也可以作为调用方来使用。它的优势在于强大的定时触发和消息通知能力，比如让你每周自动对一批 APK 做例行安全扫描，产出报告后直接推送到企业微信或者邮件列表。这块只要把 apk-reverse 的 CLI 或 HTTP 接口暴露出来，接入成本很低。

我目前已经拿 n8n 跑通了一个简单的场景：监听一个 Dropbox 目录，有新 APK 上传就自动触发逆向分析与报告生成，结果回传到 Notion 数据库。整个过程的稳定性让我比较满意，之后可以考虑加上增量分析——只分析和上一次签名的差异部分，大幅节省算力。

7.4 关于 Token 消耗：怎么让 Agent 更省

AI Agent 跑逆向分析，最烧钱的是 Token。尤其是把几百 KB 的反编译代码一次性塞进上下文，Token 费用会让你怀疑人生。我的优化经验有三条：

• 全程只让 Agent 读取"分层摘要"：先读 Manifest 结构摘要，再按需读单个类的代码摘要，不要全量加载
• 对代码块做摘要化处理：用本地脚本先把方法体压成行为描述，再丢给大模型
• 设置分析深度等级：浅层分析只用规则匹配 + 正则提取，只有深层分析才启用大模型推理

这样一套下来，一次完整逆向分析的 Token 花费能被压缩到原来的五分之一左右。

8. 复盘与建议：哪些地方值得你多花时间

最后分享一点我在整体设计里的心得，不做总结，只说判断。

第一点，这套工作流的价值上限在于"你对目标 App 的理解深度"，而不在于工具多花哨。如果连 Android 四大组件、dex 加载流程、APK 打包结构都搞不清楚，写出来的 Agent 指令大概率也是错的。先夯实基础，再追求自动化。

第二点，Rust 底座一定能提升执行效率，但初期原型阶段我建议先用 Python 把工作流跑通。函数式原型跑通了再往 Rust 迁移，会省掉大量重构痛苦。我一开始就用 Rust 写，踩了不少"还没想明白流程就把实现写死了"的坑。

第三点，安全边界一定要控制好。Agent 一旦真正拥有执行命令的权限，它就是一个有"手和脚"的工具。我建议至少做三层限制：一是只允许操作指定的工作目录与命令白名单；二是所有命令默认加沙箱限制，禁止网络外联；三是高风险行为（比如脱壳、Hook 注入）必须人工确认后才能放行。这不是技术洁癖，而是你只要让 Agent 跑过一次高危样本，就会明白那扇门一旦打开意味着什么。

目前 apk-reverse 这个项目还在持续迭代，我的重心已经转向动态分析的 Agent 化，也就是让 Agent 自主完成"安装-运行-抓包-内存提取"的闭环。等那部分稳定了，再整理出来分享。如果你也在做 Android 逆向或者 Agent 应用落地，欢迎在评论区聊聊你遇到的那些"明明很简单就是自动化不了"的环节，说不定下一个版本就是为你的场景做的。