最近 GitHub 上有一个项目引起了不少开发者的关注：REA（Reverse Engineer Anything） 。
它的介绍非常直接：
Reverse engineer anything with agents, from app behavior down to native binaries.
翻译过来就是：让 AI Agent 帮你逆向分析软件，从应用行为一直深入到原生二进制。
这听起来有点夸张。
以前我们想研究一个没有源码的应用，可能需要打开浏览器开发者工具、抓包、分析 JavaScript、使用反编译工具，甚至阅读汇编代码。
现在，REA 尝试把这些能力整合到 AI 编程 Agent 的工作流中。
你可以让 Agent 帮你分析一个网站的交互逻辑、研究一个 Electron 应用的实现、理解某个二进制文件，甚至为自己编写一个兼容实现。
真正值得关注的，不是 AI 又多了一个工具，而是逆向工程的使用门槛正在发生变化。
本文从前端开发者的视角，聊聊 REA 是什么、它为什么受到关注、背后的技术架构，以及它对日常开发究竟有什么价值。
一、REA 到底是什么？
先说结论：
REA 不是一个新的 AI 大模型，也不是一个独立完成所有反编译工作的超级工具。它更像是一个连接 AI Agent 与逆向分析工具的桥梁。
它主要提供两种使用方式：
- MCP Server：让 Claude Code、Codex 等支持 MCP 的编程 Agent 调用分析能力。
- CLI：让开发者直接在终端执行相应的分析工作流。
REA 可以根据目标类型调用相应的分析能力，再把结构化结果和证据交给 Agent，让模型继续分析、追问或生成实现方案。
举个例子。
假设你正在使用一个没有源码的桌面应用，发现其中有一个很好用的功能，想知道它是怎么实现的。
传统方式可能是：
- 找到应用安装目录。
- 判断它使用了什么技术栈。
- 查找相关资源和代码。
- 尝试反编译或调试。
- 分析业务逻辑。
- 根据分析结果自己实现。
接入 REA 后，你可以让编程 Agent 帮你组织这些步骤，并根据分析结果继续追踪。
这里需要注意：REA 不会凭空还原所有软件的完整源码。不同目标需要不同工具，最终结果也取决于目标类型、分析工具和可获得的证据。
项目本身也不是要取代 Ghidra、IDA 或 Hopper，而是让 Agent 更容易驱动这些工具。
二、为什么 REA 会突然火起来？
我认为有三个原因。
1. AI 编程正在从生成代码走向理解软件
早期的 AI 编程工具主要解决的是：
- 根据描述生成函数。
- 根据注释补全代码。
- 根据报错修复 Bug。
- 根据需求生成组件。
但真正复杂的开发工作，往往不是直接写代码，而是先理解一个系统。
比如：
- 一个按钮为什么在特定状态下不可点击？
- 一个请求为什么会被后端拒绝？
- 某个网站的状态切换究竟遵循什么规则？
- 一个旧项目为什么在特定环境下才会出现问题？
这些问题都需要调查、验证和反复追踪。
REA 尝试把这种调查能力交给 Agent，让它不只生成代码，还能主动寻找相关证据。
这也是 Agent 与传统代码补全工具的重要区别。
2. MCP 让不同工具拥有统一的调用入口
如果没有 MCP，每一种 AI 工具都可能需要单独适配不同的分析工具。
有了 MCP 这样的标准化接口，REA 就可以把一组分析能力暴露给支持 MCP 的 Agent。
可以简单理解为：
- AI Agent 负责提出问题、规划步骤和理解结果。
- REA 负责提供可调用的分析工作流。
- Ghidra、Hopper 等工具负责特定类型的底层分析。
- 浏览器或其他运行环境负责提供实际行为证据。
这种架构最大的价值，是把原本分散在不同工具中的能力组织成一个更适合 AI 调用的工作流。
3. 它降低了专业工具的使用门槛
过去，研究原生二进制通常需要一定的逆向工程知识。
你可能需要理解汇编、调用约定、符号表、反编译结果等概念。
现在，Agent 可以先帮助你定位相关信息、解释分析结果，再根据证据继续调查。
这不代表专业知识不再重要，而是意味着开发者可以把更多时间放在提出问题、验证结论和设计实现方案上。
三、REA 的技术架构是怎样的？
从架构角度看，可以把 REA 理解为一个面向 AI Agent 的分析调度层。
整体流程大致如下：
yaml
开发者提出问题
|
v
AI Coding Agent
|
v
REA MCP / CLI
|
v
选择对应的分析工作流
|
+---------+----------+
| | |
v v v
网站分析 应用分析 二进制分析
| | |
v v v
浏览器工具 资源分析 Ghidra / Hopper
| | |
+---------+----------+
|
v
返回结构化证据
|
v
Agent 继续分析或生成代码这是对其工作方式的概念化说明，不是项目内部模块的一一对应图。
1. MCP：让 Agent 能够调用分析能力
MCP 可以理解为模型与外部工具之间的一种标准化通信协议。
Agent 不需要把所有分析功能都写进自己的代码中，而是可以通过 MCP 调用外部工具。
例如，Agent 发现需要了解某个应用的模块结构，就可以调用相应的分析能力，再根据返回的信息决定下一步做什么。
需要注意的是，MCP 本身并不会自动产生逆向能力。真正的能力来自 REA 提供的工作流以及它连接的底层工具。
2. 分析引擎：不同目标采用不同工具
REA 并不是使用同一种方法分析所有软件。
| 分析目标 | 可能采用的能力 | 可以获得的信息 |
|---|---|---|
| 网站 | 浏览器检查与运行时分析 | 页面行为、请求和交互证据 |
| Electron 应用 | ASAR 与 JavaScript 资源分析 | 应用结构、模块和代码线索 |
| Go 二进制 | 二进制元数据分析 | 编译信息、模块及构建信息 |
| 原生二进制 | Ghidra、Hopper 或 IDA | 反汇编、伪代码及交叉引用 |
| Android 应用 | APK 资源分析及相关工具 | 资源、组件和代码线索 |
具体能力取决于目标类型、操作系统、外部工具和项目当前版本。
这里有一个重要区别：分析工具负责提供证据，AI 负责理解证据。
如果底层工具没有获取到某段逻辑，AI 也不应该仅凭猜测就宣称已经还原了完整实现。
3. 结构化结果：让 AI 能够继续工作
传统逆向分析往往需要开发者自己在多个界面之间切换。
REA 希望将分析结果组织成 Agent 可以继续处理的信息。
比如，分析结果中可能包含：
- 相关模块或函数。
- 代码位置和调用关系。
- 反编译得到的伪代码。
- 网络请求或运行行为线索。
- 与结论相关的证据及限制。
这样，Agent 就可以继续提出更具体的问题，而不是每次都从头开始。
四、对前端开发者来说，REA 有哪些实际用途？
我认为前端开发者不一定需要研究原生二进制，但 REA 的思路很值得关注。
场景一：研究没有源码的网站
假设你发现一个网站的表格交互设计很好，想研究它的筛选、排序和分页行为。
你可以先使用浏览器开发者工具观察页面，再让支持的 Agent 通过 REA 的相关能力辅助分析。
重点关注：
- 点击筛选项后发生了什么。
- URL 参数如何变化。
- 请求参数和返回数据之间有什么关系。
- 加载状态、空状态和异常状态如何处理。
- 不同操作之间是否存在依赖关系。
需要强调的是，REA 并不意味着能够自动获得任何网站的完整源码。对于普通网页，浏览器开发者工具通常已经能够提供大量信息；REA 的价值在于把调查过程更好地组织起来。
适合的场景：学习交互设计、研究公开网站行为、分析自己有权检查的系统。
场景二：理解 Electron 桌面应用
Electron 应用本质上结合了 Chromium、Node.js 和应用自身的资源。
如果应用保留了可分析的 JavaScript 资源，研究者就可能从资源包中获得模块结构和部分业务逻辑线索。
例如，面对一个自己有权分析的桌面应用，可以尝试回答：
- 它使用什么前端框架？
- 主要模块是如何组织的？
- 某个功能可能由哪些模块实现？
- 哪些配置与运行行为有关？
REA 可以帮助 Agent 组织这些分析步骤。
不过，代码混淆、打包优化、原生模块和运行时限制都会影响分析效果。
场景三：研究旧系统的业务逻辑
这可能是我认为更有实际价值的场景。
假设公司有一个历史系统，源码缺失或者文档已经过期，但你拥有合法的分析权限。
维护者可能只知道：
- 系统可以正常运行。
- 某些输入会触发特殊结果。
- 旧客户端与新服务之间存在兼容性问题。
通过分析可观察行为和可用的程序证据，可以帮助团队整理业务规则，并为重写系统提供参考。
当然，涉及商业系统时，还需要遵守公司的安全制度、软件许可和数据保护要求。
场景四：为兼容性实现提供依据
如果你正在开发一个需要兼容旧协议或旧文件格式的工具，最重要的往往是理解原有系统的行为。
例如：
- 不同输入对应什么输出。
- 哪些字段是必填的。
- 边界条件如何处理。
- 错误状态如何表达。
REA 的价值在于帮助 Agent 更系统地收集证据，而不是直接猜测实现。
对于协议兼容和软件迁移，有证据的行为描述，比看起来合理的代码更重要。
五、REA 和普通 AI 编程工具有什么区别？
这几个工具经常被放在一起讨论，但它们解决的问题并不完全相同。
| 工具 | 主要定位 | 核心价值 |
|---|---|---|
| Claude Code | AI 编程 Agent | 理解代码库、修改代码、执行开发任务 |
| OpenCode | 开源 AI 编程 Agent | 提供终端和其他形式的 Agent 工作流 |
| Cursor | AI 编程环境 | 将 AI 能力融入编辑器开发流程 |
| Ghidra | 逆向分析工具 | 反汇编、反编译和程序分析 |
| REA | Agent 逆向分析工具集成层 | 让 AI Agent 更方便地调用分析工作流 |
这意味着 REA 并不一定要替代你已经在使用的编程工具。
如果你的日常工作是 SolidJS、React 或 TypeScript 开发，依然可以使用原有的 Agent 处理常规开发任务。
当你遇到需要深入调查软件行为、分析程序结构或者调用专门逆向工具的任务时，再考虑引入 REA。
六、REA 有哪些局限？
项目很火，不代表它能解决所有问题。
1. 反编译结果不等于原始源码
编译后的程序丢失了很多源代码层面的信息。
变量名、注释、类型信息以及原始模块结构可能无法完整恢复。
伪代码看起来很像高级语言，但不代表它与原始实现完全一致。
2. AI 可能误解分析结果
Agent 能够解释证据，但仍然可能出现错误推断。
特别是在复杂调用链、动态行为或缺乏符号信息的情况下，需要开发者自行验证关键结论。
3. 外部工具仍然重要
部分深度分析能力依赖 Ghidra、Hopper 或 IDA 等工具。不同工具的安装条件、授权方式和操作系统支持也不相同。
REA 不是安装后就能无条件分析所有目标的万能程序。
4. 逆向分析涉及安全与合规问题
研究自己开发的软件、获准分析的程序或公开的互操作性问题，与未经授权地提取他人的商业机密，并不是一回事。
使用这类工具时，应该明确目标权限，避免访问未经授权的数据或将分析能力用于恶意用途。
七、如何开始尝试 REA？
如果你使用的是 macOS，可以从官方仓库开始：
先检查运行环境：
node -v
npm -v项目当前文档要求使用受支持的 Node.js 版本，例如 Node.js 22.19 及以上的 22.x 版本、24.11 及以上的 24.x 版本，或 26 及以上版本。具体要求以当前版本文档为准。
然后查看仓库中的安装和初始化说明：
sql
npm view rea-agents version
npm view rea-agents这两条命令用于查询 npm 包的信息，不会安装软件。
确认项目文档、包名和依赖要求后，再按官方安装指南进行安装和 Agent 注册：
首次尝试时，建议选择自己开发的测试网站或明确获准分析的应用。
不要直接拿公司的生产程序、包含敏感信息的客户端或不属于自己的商业软件做实验。
八、我的看法：AI 逆向工程真正改变的是什么？
我认为，REA 最值得关注的地方，并不是它能够反编译多少种程序。
真正的变化是：原本需要专业人员手动串联的调查工具，正在变成 AI Agent 可以主动调用的工作流。
过去，一个开发者需要知道应该打开什么工具、查看什么信息、如何理解结果。
现在，Agent 可以参与这些步骤，把调查、分析、验证和实现连接起来。
但这并不意味着软件开发会变成简单的复制粘贴。
恰恰相反，当获取信息和生成代码越来越容易，开发者更重要的能力会逐渐变成：
- 能否提出正确的问题。
- 能否区分事实、推测和错误结论。
- 能否验证分析结果。
- 能否把观察到的行为转化为稳定、可维护的实现。
- 能否在技术能力与安全、法律边界之间做出正确判断。
对于前端开发者来说，我建议把 REA 看作一个值得研究的技术方向，而不是一个必须立即安装的开发工具。
如果你经常维护旧系统、研究第三方交互、排查复杂兼容性问题，那么它值得尝试。
如果你的工作主要是常规页面开发，那么现有的浏览器开发者工具和 AI 编程 Agent 可能已经足够。
AI 不只是帮助我们写代码，也正在帮助我们理解那些原本难以理解的软件。REA 展示的，正是这个方向的一种可能性。
参考资料
- REA GitHub 仓库：github.com/morluto/rea
- REA 官方网站：rea.tools/
- Ghidra：github.com/NationalSec...
- Model Context Protocol：modelcontextprotocol.io/
欢迎在评论区交流：你觉得 AI 逆向工程最有价值的场景，是研究网站交互、理解旧系统，还是辅助分析二进制程序？