ARTICLE · 1165869

REA:让 AI 看懂软件内部逻辑,这个 Skill 能做到什么?

发布时间：2026-10-13 03:03:43 最近访问：2026-10-13 03:03:44

一个应用的导出按钮，究竟调用了哪些模块？复制一段内容时，文本和格式怎样进入系统剪贴板？一个没有源代码的旧程序，里面的计算逻辑还能不能找回来？

REA（Reverse Engineer Anything）面向的正是这类问题：把分析工具接入 AI 智能体，让智能体检查软件文件、追踪相关代码，并根据证据解释功能的实现方式。

理解 REA，可以从一个具体目标开始：把“这个功能怎么实现”变成一项有代码位置、有调用路径、有验证步骤的调查。

01｜功能定位：Skill 指导调查，工具负责分析

REA 包含三个相互配合的部分：Skill 提供调查流程指引，MCP 服务让智能体调用分析能力，CLI 提供终端入口。官方说明明确指出，单独安装 Skill 只会增加调查指引；完整使用还需要注册 MCP 服务并配置相应工具。

智能体先通过 REA 检查目标，取得发现与证据，再继续追问、解释行为，或编写并测试实现。因此，分析结果与后续生成的代码属于不同环节：REA 提供检查依据，智能体利用这些依据推进任务。工作原理

REA 的输出随分析目标变化，常见结果包括以下几类：

对使用者而言，这些输出最有价值的地方，是让解释可以回到具体位置检查：哪个文件包含入口，哪个函数接收参数，哪条调用连接了两个进程，以及哪些结论仍需要进一步验证。

REA 的 Electron 教程使用了一个“导出笔记”示例。点击按钮后，页面调用公开 API，经预加载脚本发送 IPC 消息，主进程接收消息，再调用 CSV 写入逻辑。

这个示例可以整理成一条容易阅读的路径：

点击导出 → 页面 API → 预加载脚本 → IPC 通道 → 主进程处理函数 → CSV 文件

教程同时说明，这条路径来自对代码的静态分析；若要确认某次操作实际执行了哪些步骤，还需要运行时捕获来检查。

这种效果适合回答一个范围明确的问题，例如“导出的文件在哪里生成”。它让调查能够沿着调用关系继续深入，而不是停留在界面描述上。

在 Notion 桌面应用的案例中，REA 定位了预加载脚本里的页面 API 和 IPC 调用位置。随后，编程助手继续读取包装函数与主进程处理代码，追踪文本和 HTML 如何写入系统剪贴板。

展示结果包括源码位置、通信通道名称，以及从页面接口到系统剪贴板的代码链路。读者可以看到“复制操作经过哪些环节”，并检查每一步对应的代码依据。

案例针对指定版本的应用包与保存的网页资源展开，其中部分结果来自模块测试；页面明确说明，没有记录桌面 UI 操作。因此，这个案例证明的是相应代码与测试中的行为，不能直接推成所有版本、所有使用情境都相同。

DX-Ball 案例调查的是“砖块的位置如何转换为声音的左右声像”。最初的伪代码并不完整，助手继续检查汇编、调用方和常量，随后重建了对应的 C 函数。

案例页面报告，该函数通过了 3,205 个与原始 x86 函数比较的行为测试；使用指定编译工具链并完成相应核对后，编译结果匹配原函数的 全部 63 字节。

这些数字对应案例中的特定函数与测试条件，不能用来承诺任意程序都能完整还原。

这个案例展示了 REA 更深入的一种用途：从低层代码取得证据，形成可读实现，再通过对比测试检查实现是否正确。

准备好符合项目要求的 Node.js 和 npm 后，运行：

npx rea-agents setup

按提示选择智能体、检查配置变更，完成设置后重启智能体。分析原生二进制还需要 Hopper、Ghidra 或 IDA 等分析引擎；静态 JavaScript 分析无需这些原生引擎。安装入口

第一次使用时，选择一个文件可获取、问题范围较小的目标，更便于检查输出是否回答了你的问题。

[示例提示词]

用 REA 检查这个 Electron 应用的导出功能。定位入口，追踪到文件写入逻辑，展示相关文件与代码位置。区分代码中已确认的事实、需要运行验证的行为，以及目前无法确认的部分。

评价结果时，可以重点检查三件事：解释是否附带证据，证据是否对应目标版本，以及生成的实现是否经过验证。

REA 面向合法研究、教育、互操作性、软件保存，以及对自己拥有或获授权的软件进行分析。目标分析在本机运行，但智能体接收工具结果后，仍适用其模型服务的数据政策。项目 FAQ 与声明

本文依据官方文档、教程与案例整理，未进行本地安装实测。前文配图为概念插画，实际工具输出以文档和具体分析结果为准。