没有源码,AI 也能研究软件?聊聊开源项目 REA

一个软件，没有公开源码，你能让 AI 搞明白它的功能是怎么做出来的吗？

最近迅速走红的开源项目 REA，想把这件事交给 agent。

按第三方统计站 GitTrend 的页面口径，morluto/rea 在 2026 年 10 月 12 日单日新增约 5.45 万颗星。

这是该站的统计，尚未逐条复核 GitHub 星标记录。热度很高，但至于能完成多少专业工作，还得看具体证据。

图，REA 的 GitHub 项目页，截图日期 2026-10-14。图中 Star 为抓取时的累计数。

来源 https://github.com/morluto/rea

我更感兴趣的是它背后的变化。以前，我们让 agent 写一个功能。现在，有人开始让它研究一个已经存在的功能，找出实现路径，再据此写出自己的版本。

这一步，把 agent 带进了一门很有门槛的手艺。

逆向工程，究竟在研究什么？

我们平时写程序，通常从源码出发，得到一个可以运行的软件。

逆向工程沿着相反的方向走。从软件成品、安装包或运行行为出发，追查里面的结构和逻辑。

好比拿到一只机械表，你可以读说明书，知道怎么调时间；也可以拆开表壳，看看齿轮如何传动。后者才是在研究它如何工作。

落到软件上，问题可以非常具体。

• • 一个编辑器为什么能保留复制内容的格式？
• • 某个桌面应用点击导出后，数据究竟经过了哪些模块？
• • 一个老程序没有源码了，还能不能找回某段计算逻辑？

这些问题需要查看程序内部的线索。

有时是打包后的 JavaScript，有时是函数调用关系，有时是只有机器能直接执行的二进制指令。专家要在这些线索之间来回追踪，判断下一步该看哪里。

难点就在这儿。工具能给你很多信息，但研究者要把信息连成解释。

REA 给 Agent 准备了一张工作台

REA 的全称是 Reverse Engineer Anything，中文可以理解为「逆向分析各种软件」。

它是一个连接 agent 与软件分析工具的开源工作台。你仍然和 Claude Code、Cursor 等 coding agent 对话，REA 则给它提供读取软件、追查函数和整理证据的能力。

要理解 REA，可以先想一个具体问题：你想知道「这个软件是怎么把文字复制到剪贴板里的」。

以前，你可能需要自己打开专业工具、翻找代码，再把找到的材料交给 AI 分析。REA 则让 AI 助手能够直接参与调查。这里有几个角色，分清楚就容易理解了。

• • 你：提出问题的人。告诉它想研究哪个软件、哪个功能。
• • Agent：负责调查的 AI 助手。它决定先看哪里，发现线索后继续往下查。
• • REA：给助手用的分析工具箱。它提供检查软件、读取代码、追踪函数等能力，并连接底下的专业分析工具。
• • MCP：助手与工具箱之间的连接。助手通过它发出「帮我查看这段代码」的请求，再拿回分析结果。
• • Skill：调查工作手册。告诉助手面对不同类型的软件，可以从哪里入手，遇到疑点怎样继续查，怎样检查自己的判断。

一次调查就可以这样展开：你问复制功能怎么实现，助手通过 REA 查找相关代码，拿到线索后继续追踪，再把找到的调用路径和证据整理成解释。

碰到不同类型的软件，底下使用的工具也会不同，Hopper、Ghidra、IDA 就是其中的专业分析工具。

图，项目 README 发布的 Hopper 实际界面，目标为 /usr/bin/true。主区显示指令，底部可见 REA 桥接脚本执行记录。

来源 https://github.com/morluto/rea/blob/main/docs/assets/rea-hopper-analysis.png

一个剪贴板功能，足以看出区别

项目方公开了一个 Notion 桌面端的案例，研究的是一个很日常的功能：你复制一段文字后，这些内容是怎样进入电脑剪贴板的？

剪贴板就是电脑暂时存放复制内容的地方，等你按下「粘贴」时，再从这里取出内容。

可以把这个过程想成去酒店寄存行李。你只需要把行李交给前台，酒店内部还要有人传话、核对，再把行李放进寄存柜。

Notion 显示文字和按钮的页面，就像酒店前台。你发出复制请求，页面便把「请存放这些内容」的消息交给中间的传话员。这位传话员，在代码里叫「预加载层」。

传话员再把消息送给仓库管理员，也就是软件的「主进程」。管理员检查消息是谁发来的，确认可以处理后，再调用系统功能，把文字放进剪贴板这个「寄存柜」。

你看到的是一次复制操作，软件内部完成的是几次交接。

REA 和 Agent 要研究的，就是这条交接路线。

相关代码可能分散在不同文件里，REA 先帮助找到它们的位置，Agent 再顺着代码阅读：

• • 页面把请求交给了谁？
• • 谁接收并检查了请求？
• • 哪段代码最终负责写入剪贴板？

这里还有一条重要线索。发送消息和接收消息的代码，都使用了同一个通道名称 notion:clipboard:write。

它就像电话两端都标着「行李寄存专线」，能帮助 Agent 找到相互联系的两端，再结合两边的代码，把整个交接过程查清楚。

图，Notion Desktop 7.6.1 的官方案例页面截图。从左到右展示页面的请求怎样经过中间层、后台，最终写入系统剪贴板。下方的 notion:clipboard:write 就是连接发送端与接收端的通道名称。

来源 https://rea.tools/showcase/notion/

这就是它与看截图分析产品的区别。截图能告诉你用户看到了什么；内部证据能帮你追问，这个体验由哪些程序步骤支撑。

对竞品研究而言，这多了一种调查方式。在获得相应分析权限的前提下，你可以围绕一个具体机制展开研究，缩小试错范围，再为自己的产品设计实现方案。

当然，学会一个机制之后，仍然要结合自己的数据、架构和需求重新开发。

它怎么做到连续追查？

可以用一个简单的小例子来理解。假设一个软件，输入 10 就输出 25，我们想查清楚的是：中间到底怎么算的？

第一步，先看简略说明。

Agent 通过 REA 查看程序，拿到一份方便阅读的说明，也就是「伪代码」。但这份说明没有把计算过程讲清楚，看完仍然不知道，10 为什么会变成 25。

第二步，继续查详细步骤。

于是，Agent 再通过 REA 查看「汇编指令」。可以把它理解为更接近电脑执行步骤的操作清单。从这里，才查出程序先把 10 乘以 2，再加上 5，得到 25。

中间的过程终于补齐了：10 → 乘以 2 → 加上 5 → 得到 25。

第三步，验证有没有理解错。

把查到的算法写成代码，再换几组数字，与原程序的结果比较。如果结果对不上，就继续检查哪里漏看了、哪里理解错了。

这就是「调查循环」：查材料，发现疑点，继续找证据，再验证自己的理解。

上面的算式只是帮助理解的假设例子。项目方公开的 DX-Ball 老游戏案例，展示的也是这样的过程。

它研究的是，砖块的位置怎样影响声音偏向左边还是右边。Agent 发现最初的简略说明不完整，便继续追查输入、详细指令和程序里的固定数字，逐步补出了计算过程。

图，官方案例把原始 x86 指令放在左侧，重建的 C 函数放在右侧；可以核对输入、乘法、减法和缩放步骤。

来源 https://rea.tools/showcase/dx-ball/#sound-pan

该案例报告，这一个重建函数通过了 3,205 个与原始 x86 代码的比较用例，并复现了对应函数的 63 个编译字节。

这是具体函数上的验证结果，不能扩展成所有软件都能自动还原。

REA 在过程中提供分析能力。把理解转成新代码，再运行测试，主要仍由 agent 的常规开发工具完成。

更有价值的部分，是它保留了「不知道」

研究黑箱，很容易出现一种错觉。报告写得完整，就以为软件已经被完全理解。

REA 的证据机制试图约束这种错觉。

分析记录会保留来源、结果和限制，调查流程要求区分已经观察到的事实、根据事实作出的推断，以及还没有解决的问题。

如果某段调用关系没有查全，空白结果就不能当成「这里什么都没有」。

这对安全审计尤其有用。研究者可以让 agent 整理可疑路径和待验证点，再据此安排检查；但一份没有报告漏洞的分析，仍然不能证明目标安全。

我认为，这也是专业 agent 产品值得借鉴的地方。它既要帮助用户找答案，也要让用户知道答案覆盖了多大范围。

它有哪些不足，使用前要知道？

看到这里，可能会觉得，只要把 REA 接上，Agent 就能把一个陌生软件研究明白了。实际使用中，还有几道门槛。

第一，安装和适配仍有门槛。

前面的简单示例只需要 Node.js 和 npm，但分析编译后的原生程序，还要准备对应引擎。能否顺利分析，也取决于电脑系统、程序类型和所用引擎的支持范围。

项目更新很快，仓库最新代码里的能力，也不一定已经进入你安装的版本。

安装好 REA，只是接上了工具箱；具体任务能不能完成，还要看工具是否齐全、是否适配。

第二，有些信息原本就看不到。

程序编译后，原来的注释、变量名等信息可能已经丢失。分析工具可以帮助理解程序如何工作，却无法保证找回开发者当初写下的完整源码。

代码如果经过混淆处理，线索还会更难读懂。

同样，拿到一个客户端，通常也看不到服务器内部的全部实现。AI 可以帮助分析现有材料，但不能凭空补出缺失的证据。

第三，附了证据，解释也可能有错。

Agent 可能读错一段代码，也可能把两段原本无关的逻辑联系起来。代码位置和分析记录让人更容易核对，却不能保证每次推理都正确。

所以，涉及安全判断、功能重建等重要结论时，仍需要检查原始材料，并用合适的测试验证。

它能分担查找与追踪的工作，研究者仍要判断结果是否站得住。

第四，时间、费用和数据去向都要考虑。

REA 本身开源，但 Hopper、IDA 等商业工具有各自的许可要求；反复调查也会消耗时间和所用模型服务的额度。

一次小示例能跑通，并不能直接说明分析整个大型软件需要多少成本。

另外，REA 在本机分析，不等于所有分析结果都留在本机。Agent 收到的代码片段和结果，可能进入所用模型服务商的处理流程。研究私有软件时，需要结合所用助手的配置和数据政策判断。

能力范围与数据说明 https://rea.tools/faq/；分析结果与第三方工具说明 https://github.com/morluto/rea/blob/main/DISCLAIMER.md。

第一次使用，可以照着这六步走

第一次尝试，可以先用官方提供的 Notes 小示例。它有一个「导出笔记」按钮，我们要让 Agent 查清楚：按下按钮后，笔记怎样变成 CSV 文件，又被保存到了哪里？

第一步，准备一个能操作本地文件的 AI 助手。

可以使用 Cursor、Claude Code 等支持本地 MCP 工具的 Agent。先按各自的说明安装、登录，并在电脑上新建一个用于练习的工作文件夹，让助手在这个文件夹里工作。

后面有两类操作：代码块里的命令，输入电脑的「终端」；写给助手的任务，输入它的聊天框。

第二步，检查电脑有没有 Node.js 和 npm。

它们是运行 REA 所需的基础环境。macOS 可以在系统搜索里输入 Terminal，Windows 可以打开 PowerShell，然后依次输入：

node -vnpm -v

如果都能显示版本号，就检查 Node.js 是否符合要求：22.x 至少为 22.19，24.x 至少为 24.11，或使用 26 及以上版本。

如果提示找不到命令，或者版本不符合要求，可以按官方上手指南安装 Node.js 24 LTS。npm 通常会随 Node.js 一起安装，完成后重新打开终端再检查。

Node.js 下载地址 https://nodejs.org/

第三步，把 REA 接到你使用的助手上。

在终端输入：

npx rea-agents@latest setup

如果 npm 询问是否下载这个包，确认后继续。在 REA 的设置列表里，选择你实际使用的助手，例如 Cursor 或 Claude Code。

接着查看它准备修改哪些配置，确认后再应用。这个过程会配置 MCP 连接，并安装配套的调查 skill。如果出现可选的 Hopper 安装，这次入门练习可以先跳过。

Windows 如果提示脚本执行受限，可以按官方指南把这条命令中的 npx 换成 npx.cmd。

第四步，重启助手，确认它能看见 REA。

桌面应用需要完整退出后重新打开；在终端里运行的助手，则退出当前会话，再重新启动。

然后在助手的聊天框发送：

请检查 REA 是否已经连接，并列出当前可以实际调用的 REA 工具。如果连接有问题，请说明具体原因。

这一步要确认的是，新会话里已经出现可调用的工具。如果没有，先检查助手的 MCP 连接状态和报错信息。配置完成后，需要重新连接工具的情况，并不等于整个安装过程都要重来。

第五步，用官方示例发起一次调查。

把下面这段话发给助手：

请下载官方示例 https://rea.tools/examples/notes-example.zip，解压到当前工作目录中新建的示例文件夹。

使用 REA 静态分析这些文件，不运行应用。

请查清楚：

• • 点击「Export notes」后，数据经过了哪些步骤？
• • 生成的 notes.csv 保存在哪里、包含哪些字段？

请展示相关文件名和代码位置，并列出尚未确认的部分。

如果助手无法下载文件，也可以自己打开这个链接，下载并解压，再把解压后文件夹的完整路径告诉它。

这里的重点，是让助手实际调用 REA 检查示例文件，再根据取得的结果解释导出流程。

第六步，拿着结果回去核对。

一份有用的回答，应该能指出按钮对应的代码、请求怎样传到后台、哪里负责整理 CSV，以及哪里决定保存路径。

你可以继续问：

请打开你提到的代码位置，指出决定保存路径和导出字段的具体语句。哪些结论是直接从代码读到的，哪些还需要运行程序验证？

这个练习是在读取代码，所以得到的是「按照这些代码，程序应该怎样工作」。

它并不代表已经真的点击按钮、生成并检查过文件。把两者分清，才能判断调查完成到了哪一步。

跑通这个流程后，再换成自己有权分析的应用，每次先研究一个功能。如果目标是编译后的原生程序，还需要按照对应平台的文档配置 Hopper、Ghidra 或 IDA 等分析引擎。

接下来，我更看好它往这三个方向发展

结合 REA 当前的能力和官方路线图，我会关注下面三个方向。这些是我的判断，具体能做到哪一步，还要看后续实现和验证。

一，把「读代码」和「看实际运行」连接得更紧。

还记得酒店寄存行李的比喻吗？读代码，像查看酒店的操作手册；观察运行过程，则像跟着一次实际寄存，看看工作人员到底怎样交接。

REA 已经提供部分运行时观察能力，官方路线图也把连接静态发现和运行时观察列为重点。我期待的是，当两边出现矛盾时，Agent 能更主动地补查和验证。

从「根据代码推测会怎样」，走到「拿实际结果核对」，这会直接影响专业用户对结论的信任。

二，复杂任务更稳定，新手少做一些配置。

模型如果继续提升读代码、规划步骤和使用工具的能力，Agent 就有机会承接更长的调查过程。但它仍需要底层工具给出足够可靠的材料。

官方路线图还在推进更多原生架构、调用关系和复杂代码比较的验证。

在我看来，这些能力需要进一步体现在使用体验上：更准确地识别目标、选择适合的工具，失败时说清楚卡在哪里。

这样，前面的六步流程才有机会变得更顺畅，更多开发者也更容易把一次调查做完。

三，更深入地进入开发和安全团队的日常工作。

REA 已经有版本比较等能力。未来值得继续推进的，是把这些能力与日常工作连接起来。

例如：

• • 软件更新后，继续检查上一次关注的导出功能有没有变化；
• • 研究一个安全修复时，对照新旧代码，找出修改位置、可能影响的路径，以及尚未验证的部分。

这些是可以发展的工作流示例，还需要具体任务检验效果。

如果调查记录能够复用，下一次研究就有机会从已有证据出发。

我认为，模型能力继续进步，会让更多人有机会使用专业工具。REA 想持续有价值，还需要把跨工具的调查、证据核对和结果验证做扎实。

能帮助人更快地弄明白一个软件，也能让人检查它为什么这样判断，这样的能力才值得长期依赖。