没源码,也能看懂软件怎么工作?这个开源工具,让 AI 顺着证据找答案

我更愿意分享的，不是“让 AI 什么都能做”的神话，而是一种更踏实的做法：先找到软件里的证据，再让 AI 解释。REA 这个开源项目，就是沿着这条路做的。

复制一段内容，有的软件能带上格式，有的只剩纯文字；导出一份文件，看起来都是同一种后缀，换个工具却打不开。界面上的动作很简单，背后经过哪些模块、传了什么数据，我们通常看不见。

这时候，直接问 AI“它是怎么实现的”，往往会得到一份像模像样的通用方案。问题不在于方案有没有道理，而在于：它讲的是常见做法，还是这个软件真实使用的做法？没有输入文件，没有调用位置，没有验证过程，两个答案很容易混在一起。

我关注 REA，正是因为它试图把这件事拆开。不是先编一个解释，再找材料撑住它；而是让工具先检查应用，把找到的内容交给代理继续分析。遇到缺口，就把缺口留下。

REA 全称 Reverse Engineer Anything，可以理解为一个面向 AI 编程代理的分析工具箱。它通过命令行和 MCP 接口提供能力，让代理检查应用包、代码或二进制文件，拿到结构化结果，再据此回答问题。

这里的 MCP，先把它理解成“代理调用工具的连接方式”就够了。AI 负责提出问题、组织推理；REA 负责调用分析能力、返回观察结果。它不等于新的聊天模型，也不等于点一下就还原整个软件源码的魔法。

不同应用，需要的分析路径不一样。JavaScript、Electron 应用，可以从打包脚本、预加载层、IPC 调用等位置做静态分析；.NET 有对应的静态工作流；原生二进制则可以结合 Hopper、Ghidra 或 IDA 等分析提供方。

这并不意味着你必须把所有工具都装一遍。尤其是先读一个自己的 JavaScript 项目，没必要为了“功能齐全”先安装原生反汇编器。提供方是否安装、支持哪些格式、当前平台能走哪条链，都要按实际目标来选。

项目也覆盖一些运行时调查能力，但静态查看和运行时调试不是同一回事：前者主要读文件，后者可能启动目标、附加调试或采集状态。做第一轮练习时，我建议先选静态路径，目标越小，越容易核对。

组件库通常给你按钮、表格、弹窗，方便搭建界面。REA 提供的则是“检查软件”的能力。它自己不是给普通用户直接打开就用的桌面聊天客户端，也不会替你包办产品设计、部署和测试。

如果你已经在用 Codex、Claude Code、Cursor 或其他受支持的代理，REA 更像补进工作流的一组工具。它让代理少一些凭经验补全，多一些针对具体文件的调查。但最后的解释、修改建议和实现代码，仍需要你用实际行为去验收。

官方展示了 Notion Desktop 7.6.1 的剪贴板调查。研究对象是本地打包的应用文件，不是对着截图猜功能。问题也很具体：页面里的复制操作，最后如何写入桌面剪贴板？

这个案例把路径拆成四层：页面调用剪贴板 API；预加载包装器把请求传到主进程；主进程的处理器检查发送者；最后调用 Electron 的剪贴板写入能力，把文字和 HTML 数据交出去。

const clipboardApi = {   write: invokerInMain("notion:clipboard:write") };

上面的通道名把网页侧动作和主进程处理逻辑连在一起。但这里有个特别值得讲清楚的细节：REA 的初次静态结果中，有些调用使用动态变量，通道还没有被直接解析。研究者继续阅读打包的包装代码，才把具体通道和接收端对应起来。

所以，这不是“工具自动画完完整调用图”的案例，更不是我在本机实测了 Notion 的整段复制过程。它展示的是：工具先缩小范围，人和代理继续追踪，最后形成有出处的解释。官方还说明，部分网页模块材料来自另一次缓存版本，不能当作与桌面复制同一时刻的抓包。

我也看了 REA 自己保存 JavaScript 分析证据的代码。它记录目标标识、分析操作、结果、位置和 limitations，并用哈希标识这份证据。源码里把这类结论标为 derived，也就是推导结果。哈希能帮助确认材料，不代表推理已经正确；保留限制条件，反而更利于后续复查。

先拿自己的小型 JavaScript 或 Electron 项目练习，问一个能核对的问题，例如“这个导出按钮经过哪些文件，最终写入哪里”。你知道预期行为，就更容易看出回答到底来自证据，还是泛泛而谈。

先检查 Node.js 和 npm。当前核对的 6.4.0 声明支持 Node 22.19 系列、24.11 系列或 26 及以上；新手选择符合要求的 Node 24 版本，少走兼容性弯路。下面固定版本，是为了让这篇教程更容易复现。

node --version npm --version npx rea-agents@6.4.0 setup

配置向导会让你选择代理客户端和相关设置。只选你真正使用的那个，阅读它计划修改的文件；可选分析器按需要决定，暂时不做原生分析就先不装。完成后重启代理客户端，让配置生效。不要把“执行命令成功”直接当作“所有能力都可用”。

npx rea-agents@6.4.0 setup --client codex --dry-run --json

连上以后，第一次提问可以这么写：“请静态分析我自己的这个项目，说明导出功能涉及的文件和调用位置；每个结论给出依据，动态解析不出的部分单独列出；不要启动目标，不要修改代码。”目标范围明确，结果也更好验收。

第一种，是学习真实应用的设计。Notion 的剪贴板案例就适合研究网页层与桌面层怎样协作。重点不是照搬整款产品，而是看清边界、数据流和调用关系，再写自己的小实验验证理解。

第二种，是旧软件的兼容与保存。官方 DX-Ball 案例研究的是一个声音声像计算函数：根据横向位置计算声音偏左还是偏右。项目作者展示了 3,205 组原始 x86 行为对照，以及 63 字节的编译匹配结果。

这两个数字很亮眼，但范围很小：它证明的是这个函数的重建对照，不是整个游戏已经被一键恢复。这里的结果属于官方重建项目，也不是我的本机测试成绩。把验证范围写清楚，比把标题写成“AI 复活整个游戏”更有信息量。

第三种，是排查自己的项目。这是我基于工具能力提出的练习场景，不是官方客户案例：例如分析导出数据结构，对照自己写的读取器；或检查 Electron 页面请求到了哪个主进程处理器，再写测试确认参数和结果。

不想先接代理，也可以用命令行跑一次静态分析。把下方路径改成你自己的应用目录，保留双引号，尤其是路径有空格时。示例目录是占位，不是电脑上已经存在的项目。

npx rea-agents@6.4.0 analyze-javascript-application "D:/rea-demo" --json

CLI 和 MCP 使用同一套工作流能力，只是入口不同。命令行更适合先看原始结构化结果，接入代理则方便继续追问。两者都需要有效的目标文件；把一个下载页面地址贴进去，不等于已经拿到应用包。

npx rea-agents@6.4.0 doctor --client codex --json

如果你的目标变成原生程序，再补齐对应提供方并检查环境。别用“我能分析 JS”推导成“我也能分析任意平台的可执行文件”。源码构建是另一条面向开发者的路线，第一次体验没有必要先从克隆仓库、编译所有依赖开始。

本次核对时，npm 最新版本和仓库包版本都是 6.4.0，该版 Release 发布于北京时间 2026 年 10 月 11 日。仓库在 10 月 12 日仍有提交。它不是只剩介绍页的概念项目，安装、工作流和案例都有相应材料。

不过，版本号相同不代表 npm 发布包与当前主分支每一行都相同。上面的教程固定发布版本，而调查记录保存了本次查看的仓库提交。Notion 和 DX-Ball 展示使用的是 REA 4.1.0；别把历史案例说成 6.4.0 新增能力。

它比较适合写代码的人、研究应用机制的人，以及希望给代理补上静态分析能力的学习者。你不一定要先精通反汇编，但至少愿意理解路径、进程、参数和日志，并能接受“这一段暂时没查出来”的结果。

如果你期待上传一个软件后，马上拿到完整、可编译、完全等价的工程，它并不是这样的交付承诺。对纯新手来说，把第一步缩到一个自己的小项目、一条清晰调用链，会比追求“分析任何软件”更有效。

• REA 在本地检查材料，不代表你使用的代理模型也在本地。源码片段、分析结果可能进入模型请求；公司项目先确认数据处理范围。
• 静态分析与运行时调查分别控制。前者读文件，后者可能启动或调试目标，操作影响不同。
• 项目代码使用 MIT 许可证；Hopper、IDA、目标应用和相关资源仍有各自的许可条件。工具开源，不等于获得其他软件的复制、分发权限。
• 分析结果只是证据与解释的起点。兼容实现或重建代码，要继续做输入输出测试；一次看起来正确的回答不是验收。

REA 最打动我的地方，不是名字里的 Anything，而是它试图让代理面对具体材料工作：读到什么就记录什么，推导出来的结论明确标记，没覆盖的部分留下限制，再用真实行为验证。

从 Notion 的四层剪贴板路线，到 DX-Ball 的一个声音函数，好的案例都没有省掉范围和过程。对于科技分享，我也希望把这些讲清楚：工具做了哪一步、谁补了哪一步、验证证明了多大范围。

如果你想试，先找一个自己的小项目，把问题压缩到一个功能。让 AI 给出文件位置和证据，再亲手核对。这个小动作，往往比一句“帮我完整逆向它”更能得到真正有用的答案。

本文为项目资料解读；图中官方案例与界面不代表本机实测，使用时按自己的环境核对。