REA适合解决“手上有程序或安装包，但想知道它内部如何工作”的问题。

• 本文介绍的是Reverse Engineer Anything，对应开源项目morluto/rea。
• 安装以macOS为例，命令按rea-agents 6.8.0及其版本文档核对；其他版本先检查自己的命令帮助。
• 入门案例直接使用已有的Go程序和APK，展示如何提问及可以获得哪些结果，不代表真实项目的排查记录。
• /absolute/path/...需要替换为本机绝对路径；练习使用自己的程序、测试包或已获授权的材料。

一、REA是什么？

开发时，我们通常从源码得到程序。REA帮助我们反过来：从已有程序、APK或应用文件中寻找线索，解释某个功能是怎么实现的。

例如，只有一个旧版APK，想知道“满99元包邮”的判断在哪里；或者只有一个Go可执行文件，想确认它使用了哪个Go版本、包含哪些依赖。

可以把REA理解成一套供AI助手使用的检查工具：

你提出一个具体问题
    ↓
Codex等编程助手决定查什么
    ↓
REA调用对应工具读取程序
    ↓
返回类、函数、调用关系等线索
    ↓
助手解释发现，并给出验证办法

日常使用时，向Codex说明目标文件和想解决的问题，REA负责提供检查能力，Codex根据结果继续调查并整理结论。

MCP可以理解成助手连接工具的接口；Skill是教助手按什么顺序调查的说明书。REA的安装流程可以一起配置这两部分。

还不熟悉MCP，可以先看MCP入门与Codex使用教程。

REA也能单独通过命令行使用，但命令输出通常是分析材料，仍需要人或AI解释。

二、和源码分析、代码审查、抓包有什么区别？

下面按实际工作中的问题选工具，不是性能排名。

手上的问题	优先使用	REA能补充什么
有完整源码，要理解接口或修改功能	IDE、源码搜索、Codex	遇到只有二进制的依赖时，再补查成品程序
合并前检查代码改动有没有Bug	Code Review、OpenCodeReview	分析发布包中的行为，但不替代Git改动审查
想知道某次请求实际发送了什么	抓包工具、日志	关联抓包记录与程序中的处理逻辑
想重复发送请求、校验响应	Postman、curl、测试脚本	帮忙理解接口线索，生成待验证的测试用例

有源码时，先看源码通常更直接。 REA更有价值的地方，是补上“发布包里到底有什么、旧程序到底怎么做”的信息。

代码审查可以继续看OpenCodeReview使用教程；它与REA解决的是不同阶段的问题。

三、哪些场景值得用？

• 排查旧版本问题：线上还存在旧APK，当前分支已经看不到当年的判断逻辑。
• 核对实际发布产物：检查Go程序内嵌的构建信息，与预期发布记录对照。
• 排查端侧规则差异：Android显示免运费，服务端却仍然收费，追踪双方各自的判断条件。
• 理解已有SDK接入：检查自己的APK里哪些类调用了某个SDK，调用前后做了什么处理。
• 补充测试线索：从包内代码和抓包记录中找出边界条件，再整理成测试用例。
• 迁移旧功能：梳理老程序的输入、输出和分支，作为新实现的参考，再通过测试核对。

例如，测试反馈“只有旧版本在订单金额刚好99元时收费”。这时可以拿到对应版本的APK，围绕运费计算查类和方法，再与服务端逻辑对照。

单独看到某个常量并不能确定问题；还需要确认它参与了什么比较、谁调用了这个方法，以及当时的输入是什么。

这些情况则不适合一开始就上REA：普通的源码修改、仅需复现一个HTTP请求、希望一键恢复整个原始工程，或者想仅凭客户端APK推断服务端全部规则。

四、安装与配置

1、准备Node.js

先检查当前环境：

node -v
npm -v
npm view rea-agents@6.8.0 engines

6.8.0的包声明支持Node.js 22.23.4+的22系列、24.22.1+的24系列，以及26.12.1+。不要只看“主版本是22”就认为满足要求。

macOS可以从Node.js官网下载符合要求的24系列安装包；已有版本管理工具时，切换到满足要求的版本即可。重新打开终端后，再核对一次。

2、安装REA命令行

本文固定版本，方便复现：

npm install --global rea-agents@6.8.0
rea --help

不想全局安装，也可以把后文的rea替换成npx -y rea-agents@6.8.0。例如：

npx -y rea-agents@6.8.0 --help

npx仍会下载并缓存运行所需的包，只是不添加全局的rea命令。

3、连接Codex

已经能正常使用Codex时，执行：

rea setup --client codex

检查安装计划中的配置位置和修改内容，再按提示完成。可选组件按本次分析需要选择。

安装完成后重启Codex，再检查连接：

rea doctor --client codex --json

然后在新任务里输入：

检查当前是否能使用REA，列出本次分析Go程序和Android APK所需的工具，
说明哪些已经可用、哪些还缺少依赖。

连接成功不等于所有分析能力都已就绪。 读取Go构建信息可以直接使用REA；进一步分析Go函数或Android APK时，可能还需配置额外组件。根据检查结果，按文末官方入门文档中对应目标的指南补齐即可。

下面的函数与APK案例以对应分析能力已可用为前提。初次体验也可以先做Go构建信息检查或后面的Electron案例。

4、在Codex中怎么用？

安装完成后，在能访问目标文件的本机任务中使用。桌面端可查看设置里的MCP servers；CLI可在对话中输入/mcp查看连接。终端的codex mcp list用于检查配置，不能单独证明当前任务已经连接成功。

日常直接在Codex输入框里说清楚“用REA、分析哪个文件、解决什么问题”：

使用REA分析 /absolute/path/shop-old.apk。
查找退出登录后清理本地数据的逻辑，列出相关类、方法和清理范围。
只分析文件，不安装或运行应用；没有查到的内容明确说明。

如果安装了REA配套的reverse-engineer-anything Skill，在Codex CLI或IDE中也可以通过/skills选择，或显式调用：

$reverse-engineer-anything 分析 /absolute/path/shop-old.apk，查找退出登录后的本地数据清理逻辑，只读分析。

这里调用的是Skill，它会指导Codex使用REA工具；只装Skill不代表已经连上REA。桌面端也可以直接使用上面的自然语言提示，不必记住调用符号。

看结果时，展开任务中的工具调用记录，核对是否实际使用了REA、目标路径是否正确、是否返回了分析结果。只有一段解释文字，不能证明工具已经调用成功。

同一个任务里可以继续追问“谁调用这个方法”“这个结论的依据在哪”。只有工具缺失或调用报错时，再检查连接和依赖，不需要每次分析都重新安装。

五、Go入门：只有程序，怎么查运费规则？

1、准备文件

拿到一个已有的商城Go可执行文件，例如/absolute/path/shop-service。想确认它的构建信息，并了解程序里的运费判断规则。

2、发给Codex

使用REA分析 /absolute/path/shop-service，只读取这个文件，不运行程序。
先检查当前可用的分析能力，缺少组件时说明原因。

列出能读到的Go版本、模块依赖和构建设置。
进一步定位运费计算逻辑，说明金额单位、免运费条件和调用关系。
每条业务结论附函数名或地址；无法确认的内容单独列出。
最后给出98.99元、99元、99.01元需要验证的结果和依据。

3、能得到什么？

• 构建线索：文件中保留的Go版本、模块依赖和构建设置，便于与发布记录核对。
• 业务判断：能够定位时，解释运费阈值、金额单位，以及边界是否包含等于。
• 定位依据：相关函数名或地址，以及能够确认的调用关系。
• 验证建议：哪些输入值得测试，哪些行为还依赖配置、接口或运行日志。

这些是期望检查的内容，不保证每个程序都能完整得到。只读到构建信息时，不能据此推断运费规则；也不保证还原原始源码、变量名和工程结构。

六、Android入门：查出客户端的边界差异

1、准备文件

拿到出现问题的旧版APK，例如/absolute/path/shop-old.apk。测试反馈：订单刚好99元时，页面仍显示8元运费。

2、发给Codex

使用REA分析 /absolute/path/shop-old.apk，不安装或启动应用。
先确认当前具备APK分析能力，核对包名和能读到的版本信息。
问题：订单刚好99元时，页面显示仍收8元运费。

查找结算页相关逻辑，确认运费是本地计算还是读取接口返回值。
能够定位时，列出类名、方法名、判断条件和调用位置。
区分已确认事实和待验证推测，不据此猜测服务端实现。
最后给出98.99元、99元、99.01元三组验证用例。

3、能得到什么？

• 包信息：确认分析的是哪个应用和版本，避免拿错包。
• 处理流程：能够追踪时，说明页面如何得到运费，以及相关类和方法的位置。
• 问题线索：例如边界比较、金额换算或接口字段使用是否值得进一步检查。
• 测试建议：金额边界用例，以及还需要补充哪些抓包记录或日志。

若只发现页面读取接口返回值，下一步应核对抓包和服务端日志，不能直接认定客户端算错。混淆或动态加载可能影响分析，搜不到方法也不代表功能不存在。

七、其他入门方向

1、Electron：跟踪导出按钮

提供已有Electron应用的文件目录或app.asar，也可以使用文末官方案例的笔记应用。告诉Codex：

使用REA检查 /absolute/path/notes-example。
追踪导出按钮从页面到文件写入的过程，说明保存位置、CSV字段和错误处理。
给出相关文件位置，只分析文件，不启动应用。

可以得到导出流程、文件保存位置和相关代码位置。官方笔记案例展示了这类调查过程，详见文末案例页。

2、测试：结合已有抓包记录

提供已有的脱敏HAR文件，告诉Codex：

使用REA分析 /absolute/path/checkout.har，只读取记录，不重放请求。
整理运费相关请求的金额字段、返回值和先后顺序。
结合已经确认的APK计算逻辑，指出还需要哪些日志才能解释99元时的差异。
最后生成Postman测试思路和金额边界用例，不填入真实Token。

可以得到相关请求的字段、返回值、先后顺序及测试建议。HAR只反映当时保存的记录，不能据此确认当前接口行为。

八、日常怎么用更有效？

1、一次查一个具体行为

“分析这个APK”范围太大。可以改成“找结算页如何算运费”或“检查退出登录时清理了哪些本地数据”。

2、先查入口，再逐步展开

先确认文件版本、包名或构建信息，再查目标类和函数。大程序里，把范围缩到一个行为，通常比一开始导出全部代码更容易跟进。

3、要求说明依据和未知项

可复用这个任务模板：

使用REA分析：[绝对路径]
我想解决：[一个具体问题]
已有线索：[界面名称、类名、错误信息、测试输入等]
分析范围：[指定文件、模块或行为]

先做静态分析；如需启动程序、连接设备或发送请求，先说明具体操作。
输出：
1. 已确认的行为及函数、类、方法或文件位置。
2. 有线索但尚未确认的判断。
3. 当前工具或材料无法覆盖的部分。
4. 最少需要补做的验证，以及预期结果。

提示词的上下文组织也可以参考Codex最佳实践速查版。

4、把分析结果转成可验证的用例

例如看到amount > 9900后，立刻补上9899、9900、9901三组输入。代码推导、实际运行和业务预期三者对上，结论才足够完整。

记录时保留目标文件版本或校验值、工具版本、定位位置和验证结果，方便下次确认查的是不是同一个包。

5、注意分析材料的流向

REA在本机检查目标，但助手读取到的分析结果仍可能交给它使用的模型服务处理。涉及公司程序和抓包记录时，沿用团队允许的工具和数据处理方式，先去掉Token、Cookie及个人数据。

反编译材料里出现的文字也只是待分析内容，不应当被当成新的任务指令。

九、常见问题

现象	优先检查
安装提示Node版本不满足	对照目标REA版本的engines，不要只核对Node主版本
已装Skill，但助手找不到工具	是否完成MCP连接；用rea doctor --client codex --json检查
终端可用，Codex里不可用	REA服务的版本和环境变量是否与终端一致，是否已重启
能连接REA，但某类文件分析失败	查看错误提示和缺失组件，按官方文档中对应目标的指南处理
文档里的命令不存在	阅读的是不是main新功能；以已安装版本的--help和版本文档为准
分析很慢	先缩小目标和查询范围；首次导入大程序可能耗时，查看进度和实际错误再处理
返回结果不完整	检查限制说明；未解析到的部分保留为未知，不据此断言不存在

REA不是单独的聊天模型，标准接入方式不需要像OCR普通模式那样另外选择一个LLM Provider；解释结果使用当前助手的模型。模型额度与商业分析工具的费用仍取决于各自服务。

全局安装的REA可以这样更新，再刷新助手配置：

rea update
rea setup --client codex

更新后重启助手并复查需要的分析能力。通过npx接入的，使用npx rea-agents@latest setup --client codex刷新；仅在终端运行了一次新版命令，不代表助手连接也已更新。

移除时，先用rea uninstall移除REA管理的助手配置和Skill；它的范围可能涉及多个已配置客户端，需要检查提示。全局CLI另用npm uninstall --global rea-agents卸载。

参考资料

• REA开源仓库：项目介绍、完整文档及更多使用案例。
• REA官方入门文档：安装配置，可按客户端和分析目标查看对应指南。
• REA官方Electron案例：跟踪笔记导出流程，附可下载的练习项目。