REA 入门:让 Agent 看懂没源码程序

想知道一个没有源码的程序，某个按钮点下去到底做了什么？以前这事门槛不低：要懂逆向、会看反编译结果，还得能把调用链一段段串起来。

REA 入门的价值就在这里。它不是新模型，也不是一键反编译神器，而是把软件分析工具接给 Codex、Claude Code 这类支持 MCP 的 Agent，让 Agent 能围绕证据解释程序行为。[1]

这篇文章只基于 REA 官方公开材料整理，不写成本机亲测。我们按一条小白也能理解的路线来：先明确问题，再调用工具取证，然后解释调用关系，最后对照验证。读完之后，你至少能判断 REA 适合解决什么问题、怎么接入 Agent，以及官方 DX-Ball 案例为什么能从看不懂的 __ftol，一路追到坐标公式。

REA 到底是什么

REA 是一个开源项目，提供 MCP 服务和 CLI 工作流，把程序分析能力交给兼容 Agent 调用。[1]

MCP 可以先简单理解成工具接口协议：Agent 不只是和你聊天，还能通过这个接口调用本地工具、读取分析结果，再把原本难读的材料整理成更容易理解的解释。

它覆盖的目标类型不少，包括原生程序、JavaScript/Electron、.NET、Android、网站，以及保存下来的网络记录。[1]

但这里要注意：覆盖不代表每台电脑都能完整分析所有目标。实际能力会受目标类型、操作系统、provider 和依赖工具影响。比如深度原生分析可能会用到 Hopper、Ghidra 或 IDA；而静态 JavaScript 和 .NET 检查，则不需要这些原生逆向引擎。[4]

适合问哪类程序问题

REA 更适合回答范围清楚的问题，比如：这个程序的某个功能是怎么实现的？

举个官方材料里的方向：在一个 Electron 应用里，页面调用剪贴板 API 后，代码经过哪些 preload 包装、IPC 通道和主进程 handler，最后才到 Electron 的 clipboard.write。[3]

它不适合被当成魔法按钮。不要丢一个很大的安装包，然后问：帮我完全理解它。这个问题太大，Agent 很难围绕证据推进。

更好的问法是：某个按钮触发后有没有写剪贴板？某个声音参数是怎么从输入算出来的？某段网络记录里的字段来自哪里？问题越具体，Agent 越容易调用工具取证，也越不容易把猜测写成结论。

安装前准备

官方安装指南要求先准备 Node.js 和 npm，并且 Node.js 版本需要满足 22.19+、24.11+ 或 26+。[1]

对小白来说，Node.js 可以理解成运行 JavaScript 工具链的环境；npm 则是跟着 Node.js 一起使用的包管理器。

可以先在终端里检查版本：

node -vnpm -v

如果版本不满足，就先升级 Node.js。这里不要跳步骤，因为后面的 npx 命令依赖 npm 工作。

验证方法也很简单：终端能正常输出版本号，并且 Node.js 版本落在官方要求范围内，就可以继续往下走。

接入 Agent 的入门命令

官方给出的接入方式，是运行 setup 命令，让工具引导你选择 Agent、审阅配置变更并批准，完成后再重启 Agent。[1]

命令如下：

npx rea-agents@latest setup

这个过程中，最需要认真看的不是命令本身，而是审阅配置变更。

因为它会把 REA 的 MCP 能力接到你选择的 Agent 上。接好之后，Agent 才能调用对应工具。跑完后也别急着上来就问复杂问题，先重启 Agent，再用一个范围很小的问题确认工具是否可用。

给 Agent 一个好问题

我建议把问题写成：目标 + 行为 + 证据要求。

比如可以这样问：请分析这个 Electron 应用中 clipboard.write 的调用路径，说明页面 API、preload、IPC 和主进程 handler 分别出现在哪里，并标出证据限制。

这个写法比分析一下这个软件强很多。它把 Agent 的工作顺序约束住了：先找入口，再追调用关系，再解释每一段证据。

对于没有源码的程序，最怕的不是看不懂，而是把猜测当结论。所以每一步都要追问一句：证据在哪里？

JavaScript 和 Electron 命令怎么看

官方材料提到，REA 可以用于 JavaScript/Electron 场景，并且静态 JavaScript 检查读取用户提供的文件，不运行目标程序。[1]

这点对小白很重要。静态检查就是读文件分析，不是把应用打开后手动点一遍。

如果你看到类似 CLI 命令，路径占位符通常表示你需要换成自己的解包目录或 ASAR 文件位置。可以先这样理解：

rea <subcommand> <path-to-unpacked-app-or-asar>

这里不能写成我们本机成功跑通了，因为本文只依据官方材料整理。更稳的做法是先看清目标路径、目标类型和 REA 当前支持的 provider，再让 Agent 针对一个具体 API 或函数做追踪。

DX-Ball 案例的起点：看见 __ftol

官方 DX-Ball 1.07 案例分析的是 1996 年 Windows 游戏 DX-Ball 中，声音声像计算相关逻辑。[2]

案例一开始遇到的问题很典型：反编译结果只显示 __ftol，但输入语义不清楚。对新手来说，__ftol 可以先理解成浮点数转整数时可能出现的运行库辅助函数。

如果只看这一层，很容易卡住。REA 官方案例的处理方式不是直接猜，而是继续查看指令、追踪调用方、读取数据常量。[2]

这就对应前面那条路线：明确问题之后，调用工具取证，而不是把不完整的反编译伪代码当成最终答案。

DX-Ball 坐标公式怎么追出来

在 DX-Ball 案例里，调用方提供了关键输入关系：x = 20 + 30 × tile_x。[2]

这句话非常适合帮小白建立感觉：逆向分析不是只盯着一个函数看，而是要继续看谁调用了它、传了什么参数、这些参数代表什么。

官方案例还提到读取常量，比如 1.5625、500.0、1.0，并把这些证据放回声音声像计算里理解。[2]

这里要保持谨慎：常量本身只是证据。只有把常量、调用方、指令和返回值比较放在一起，才更接近这个函数到底在做什么的解释。

DX-Ball 的验证数字怎么读

官方 DX-Ball 展示页给了项目方检查点数据：在 2026-10-07 检查点下，项目展示页标注了维护中的 C 函数、与原程序比较次数、编译后字节匹配等信息。

其中，声音声像函数报告了 3,205 组原始 x86 返回值比较，并在指定 VC4.0 编译器重放与 relocation 检查后，匹配 63 个函数字节。[2]

这组数字很有价值，但边界也要说清楚：它来自 REA 项目方公开展示页，不是本文作者独立复现。

教程写作最怕把官方案例写成我实测，这会误导读者。更稳妥的表达是：官方案例通过大量返回值比较和编译字节匹配，展示了它如何对照验证重建结果。

Notion 剪贴板案例能学到什么

REA 官方 Notion Desktop 7.6.1 案例展示了另一个方向：分析 Electron 应用中的剪贴板调用链。

案例从页面暴露的 clipboard.write 出发，追到 preload 包装，再经过 ipcRenderer.invoke、ipcMain.handle，最后到 Electron 的 clipboard.write，并检查发送方。[3]

这类案例很适合普通开发者理解 Electron 应用的边界。页面代码通常不能直接接触所有系统能力，中间会经过 preload 和 IPC。

REA 的作用，是帮 Agent 把这些调用点串起来。但最终结论仍然要落在具体文件、函数和调用证据上。

静态分析、运行时和权限边界

官方文档说明，静态 JavaScript 与 .NET 检查读取用户提供的文件，不运行目标程序；运行时捕获则可能以当前用户权限启动或交互目标。[1]

这两类观察方式要分清楚：静态分析偏看材料，运行时捕获偏观察程序实际动作。

还有一个安全点不能省。REA 在本地分析目标，但 Agent 收到工具结果后，会交给它背后的模型服务处理；模型服务的数据政策需要你自己确认。[1]

如果目标是闭源软件，分析前也应该获得授权。Windows Ghidra 支持目前标记为 experimental，不能把它当成所有 Windows 原生分析都稳定可用。[4]

新手推荐的四步工作流

新手用 REA，不要一上来就追求一次吃透整个程序。更推荐按四步走：明确一个小问题、让 Agent 调用工具取证、要求它解释调用关系，再用官方案例那样的对照验证思路检查结论。

可以直接把提示词写得更硬一点：

请只分析这个具体问题：<这里写按钮、API 或函数名>。按“证据、调用关系、推断、不确定性”四部分回答。不要把没有证据的猜测写成结论。

做完这一步，你得到的不是一个神奇答案，而是一份更容易阅读的软件分析笔记。

它会告诉你：哪些地方有证据，哪些地方只是推断，哪些地方还需要继续追。对小白来说，这比直接看一堆反编译代码友好太多。

参考资料

[1] REA 官方 README

[2] REA 官方 DX-Ball 案例

[3] REA 官方 Notion 案例

[4] REA GitHub 项目说明

关注「GitHub开源」，这里持续整理值得上手的开源项目、AI 工具与可复用工作流。点击公众号主页关注，下一次把能落地的东西带走。