REA 深度拆解:当 AI 开始读懂没有源码的软件

封面｜沿用上一版黑白视觉，AI 生成概念插画。

这篇笔记围绕一个问题展开：当 AI 能调用逆向分析工具，它能帮我们理解软件到什么程度？以下基于官方文档与公开案例整理，并非我的实机测评。［1］

REA 的全称是 Reverse Engineer Anything。它把不同类型的软件分析能力接到智能体上：读取程序文件、追踪调用关系、检查二进制，也能观察网页或运行行为。你提出问题，智能体组织调查，工具返回发现与证据。［1］

理解它最容易的方法，是把它看成一个连接层：上面是你熟悉的编程智能体，下面是实际工作的分析工具。MCP 提供调用接口，让智能体能够继续追问、解释结果，再据此写出需要验证的实现。［1］

让 AI 看一张界面截图，它可以猜出很多合理的实现方式。但合理，不等于真实。我们真正想知道的是：这个软件实际走了哪条路径，哪个函数处理输入，数据又在哪里发生变化。

图一｜据官方调查流程重绘。实线是调查顺序，底部回路表示需要继续追问与验证。［1］

REA 的官方流程，是让智能体通过工具检查目标、追踪相关代码，拿到带证据的发现后，再解释、实现和测试。返回的代码位置、引用关系与未知项，比一句流畅的结论更有用。［1］

比如你问“这个应用怎样导出文件”，需要的不只是“它调用了某个 API”。你还要弄清输入从哪里来、经过哪些转换、文件写到哪里，以及失败时怎样处理。把问题缩小到一个可验证的行为，调查才容易收敛。

Notion 的官方案例从一个小问题开始：页面调用 clipboard.write 后，请求究竟去了哪里？REA 给出 preload 中相关代码的位置，智能体再沿着包装函数和 IPC 通道继续读，直到找到主进程的剪贴板写入操作。［2］

图二｜据官方 Notion 案例重绘的简化调用链，不是产品截图。案例材料来自 Notion Desktop 7.6.1。［2］

这条路径经过页面 API、preload 包装与进程通信，再抵达主进程。接收端还会检查发送者。从界面到系统能力之间的连接，就这样被拆成了可以逐段检查的环节。［2］

官方案例也解释了复制内容为什么能保留结构：它观察到，复制的 HTML 里带有一个 ID，与本地保存的块数据建立关联；粘贴时，匹配的 ID 可用于恢复块数据。这里必须留意，不同部分来自不同版本的材料和模块测试，不能把它们说成对所有版本的承诺。［2］

DX-Ball 的案例研究的是一个很小的行为：砖块被击中后，如何把横向位置转换成声音的左右声像。第一次反编译得到的伪代码并不完整，研究者因此继续检查原始指令、调用者和内存常量，补出计算过程。［3］

公开案例报告，这个函数的重建通过了 3,205 个原始 x86 对照用例，并复现了函数的 63 个编译字节。这是一个具体函数的结果，不代表整款游戏已经被完整恢复，也不能当成 REA 的通用成功率。［3］

如果你维护 JavaScript 或 Electron 应用，可以从自己拥有或获准分析的应用包开始。静态 JavaScript 分析不需要原生反编译引擎；原生二进制的深入分析则要准备相应后端，比如 Hopper、Ghidra 或 IDA。先选目标，再查依赖，不要把所有工具都装一遍。［1］

这些是我认为值得尝试的使用场景，并非对任意目标都有效的保证。第一次使用，选一个范围小、行为容易复现的问题，更容易判断工具有没有帮到你。

官方快速入口

npx rea-agents setup

按官方说明，setup 会让你选择智能体、审阅配置变更，并添加 MCP 服务与配套工作流指引；完成后需要重启智能体。当前 README 要求 Node.js 22.x（至少 22.19）、24.x（至少 24.11），或 26 及以上，并安装 npm。不同分析目标另有依赖，以对应文档为准。［1］

研究自己拥有或获得授权的软件，也要尊重目标软件与分析工具的许可。先明确问题和材料范围，再判断哪些结果足够支撑结论，这比一次输出很长的“分析报告”更重要。

REA 让我感兴趣的，是它把“提出问题—读取材料—追踪关系—验证判断”串成了一套可以继续推进的工作流。能不能理解一个具体功能，最终还是要回到那条证据链。

如果让你选一个最想弄明白的软件功能，你会从哪个问题开始？

REFERENCES

［1］REA 官方仓库与 READMEhttps://github.com/morluto/rea

［2］Notion 剪贴板桥接案例https://rea.tools/showcase/notion/

［3］DX-Ball 声像计算案例https://rea.tools/showcase/dx-ball/

依据 2026 年 10 月 14 日可见官方资料整理。官方案例结果与本文分析分别标明。