拆解爆火开源项目 REA：逆向开发软件的流程

从产品定位、工作流程和技术架构，看懂 REA 怎样把应用分析能力交给 AI Agent。

过去，想借鉴一个 APP 的功能，我们通常从界面和交互开始：它有哪些按钮，用户怎样操作，最终得到什么结果。

但要把功能做出来，还需要理解另一层问题：数据经过了哪些处理，模块怎样协作，哪些行为依赖本地程序，哪些又依赖远程服务。

AI 已经能根据描述写代码。如果它还能检查现成应用的内部结构，开发过程就多了一种起点：从已有软件的实现分析依据出发，理解功能，再为自己的项目编写实现。

REA 试图提供的，正是这套应用分析能力。

这篇文章围绕它是什么、如何工作、技术架构和基本用法展开，帮助读者建立产品认知。

一、REA 是什么？

REA 的全称是 Reverse Engineer Anything。

github 开源链接：https://github.com/morluto/rea

它是一个开源项目，通过 MCP 服务和命令行工具，将本地应用检查、代码追踪与行为观测等能力提供给 AI Agent 和开发者。

它与 AI Agent 有明确的职责分工：Agent 接收用户目标，决定调查什么、如何解释发现，并编写新的实现。

REA 执行分析动作，返回发现及其依据。

这意味着，一个完整的使用场景需要两部分协作：AI 的理解与开发能力，以及 REA 提供的分析工具。

REA 自身也有组合分析流程和结构化处理逻辑，但接收自然语言目标、看完结果后决定下一步的角色，主要由外部 Agent 承担。

用户给目标 → Agent 调用 REA → REA 返回分析依据 → Agent 解释、继续调查或编写实现。

这里的“逆向开发”，更适合理解为：在缺少原始源码的情况下，检查已经交付的应用，推断某个功能的实现机制，再构建一个满足自身需求的版本。

分析得到的材料可能是伪代码、模块关系、调用引用、接口信息或运行观测；这些材料与原作者的完整源码之间，仍有距离。

REA 还覆盖 .NET、Android APK 等其他对象；具体能力随目标类型、平台和已配置工具而变化。

二、工作流程：从问题到分析依据，再到实现

第一步，定义目标。

“分析这个 APP”过于宽泛。

更有效的任务会限定某个功能，说明希望了解哪些处理过程，以及最后需要一份分析报告、实现建议，还是可运行代码。

明确范围，才能判断分析依据是否足够。

第二步，检查目标并选择分析路径。

用户提供应用包、目录、二进制文件或网页。

Agent 根据目标类型调用相应工具：JavaScript 应用关注模块和关系，原生程序需要反编译及引用分析，网页则可能需要页面与网络观测。不同目标不必经过同一组工具。

第三步，获得分析依据并缩小调查范围。

初次分析通常用于建立概览，后续调查再围绕函数、字符串、接口或通信通道追踪相关路径。

REA 的 JavaScript 功能追踪会读取已经建立的关系图，找到与指定线索关联的部分。

第四步，解释发现，处理未知项。

Agent 将工具结果整理为人能理解的说明，并判断还缺什么材料。

找到一条静态调用路径，只说明代码结构支持这条路径；它是否在某次操作中真正执行，还需要相应的运行分析依据。

第五步，根据分析依据编写实现。

Agent 结合原功能的机制和新项目的约束，选择实现方式。

交付目标可以是一个独立组件、一段算法或一个小工具，技术栈也可以与原应用不同。

第六步，对照验证。

验证关注相同输入、输出、异常和边界条件下的行为。

若出现差异，就回到调查阶段补充分析依据。

是否“重建成功”，需要按目标功能的验收条件判断，不能仅凭工具调用成功或代码能够启动。

三、技术架构：把应用变成可调查的信息

入口：MCP 面向 Agent，CLI 面向终端操作

MCP 可以理解为 Agent 调用外部工具的接口。

接入后，Agent 能按工具的参数要求发起检查、追踪和查询。

CLI 则允许开发者直接在终端完成分析，便于调试或脚本化使用。

这两类入口共享应用层分析能力。

例如，JavaScript 应用分析的 MCP 工具与 CLI 命令，都会进入同一应用服务。

这样，同一个任务可以由 Agent 发起，也可以由开发者直接执行。

分析：静态解析与外部引擎协作

对于 JavaScript / Electron 应用，REA 会检查应用文件，解析代码，整理模块、导入和进程边界等关系，再形成便于追踪的图结构。

这个过程可以直接读取交付文件，不需要运行应用，也不要求安装原生反编译引擎。

Electron 应用的一个难点是功能跨越页面、预加载脚本和主进程。

REA 会识别部分通信关系：当代码中的通道名明确、且只有一个兼容的处理器时，才建立对应关系；多个候选会保留为歧义。这样的约束有助于减少把相似线索误认成确定链路的情况。

对于原生程序，REA 连接 Hopper、Ghidra、IDA 等工具，使用它们的深度分析能力，并管理调用及结果。引擎的能力、目标格式和宿主平台，都会影响可执行的分析范围。

输出：Evidence 让结论有来源、有边界

REA 返回的核心材料是结构化的 Evidence，即分析依据记录。它包含目标与分析工具的身份、执行的操作、结果、位置、限制，以及观察、推导或推断等信息。Agent 可以据此继续调查，并在解释结论时给出依据。

这里尤其需要注意：“观察到”可以指观察到交付文件中的代码结构，并不必然代表已经观察到应用运行时执行了该行为。阅读分析依据时，要同时看材料来源、分析方式和限制。

会话：让调查能够接着进行

MCP 服务可以在进程内保留目标状态和分析依据，后续工具据此查看已取得的材料。大型结果也可以通过摘要和进一步查询分步读取。需要跨进程保存时，则使用明确的快照或分析依据导出。

从产品设计看，这种组织方式让调查可以逐步深入，同时提醒使用者：分析记录的保存、外部 Agent 的上下文，以及结论是否成立，是三个需要分别管理的问题。

四、怎么使用：接入、准备目标、提出问题

接入 AI Agent

这里可以使用 DeepSeek Harness，准备 Node.js 和 npm 后，可以使用官方引导命令。

▼
bash
复制代码
npx rea-agents@latest setup

根据引导选择要接入的客户端，查看并确认配置变更，再重启或重新连接 Agent。setup 会配置 MCP 注册，并安装配套的工作流指引。仅安装工作流 Skill，与完成工具接入之间还有区别。

如果选择原生程序分析，还要准备对应引擎；JavaScript 静态分析可以直接开始。初次任务适合限定一个功能，方便理解结果和判断还缺哪些分析依据。

准备目标与问题

给 Agent 明确的本地绝对路径、应用版本、目标功能，以及希望得到的输出。已经解包的目录和 ASAR，是 JavaScript / Electron 分析常用的输入。ASAR 是 Electron 常见的应用文件归档格式。

macOS 的 .app 是应用包目录，内部还可能包含 JavaScript 归档和原生文件。针对 Electron 的静态分析，明确指出其 ASAR 或相关目录，更容易选对路径。不要把所有目标都交给同一个通用命令来猜测。

可以从这样的提问开始：

请使用 REA 分析位于「本地绝对路径」的应用中「具体功能」的实现。先识别目标类型，再说明相关模块、处理步骤和数据去向。每个关键结论附分析依据位置，并区分直接观察、推断和未确认行为。先交付分析报告，再给出在我的项目中重建该功能的建议。

五、产品判断：价值在哪里

我的判断是，REA 最有价值的地方，是让已有软件成为 AI 开发时可以调查的材料。

用户可以从一个真实功能提出问题，Agent 则有机会沿着文件、模块和调用关系寻找依据，再把调查结果转化为自己的实现。

从产品角度看，统一的工具入口有助于减少切换分析工具的负担；结构化分析依据有助于检查结论、继续追问。

这些设计提供了改善调查效率的条件，实际效果仍要结合具体目标、模型和环境评价。

对于 AI 产品从业者，REA 展示了一种值得关注的开发方式：让 Agent 在写代码之前，多一道对已有软件的调查。把这一步做扎实，生成的实现才有机会建立在可核验的理解之上。