1它到底在解决什么问题

逆向工程的真正瓶颈，从来不是工具不够多。

过去几十年，逆向工具已经很成熟：Hopper、Ghidra、IDA 各有所长，JADX 能拆 Android，Binwalk 能解固件。但工具再强，「读懂」这一步仍然依赖人——要先判断该看哪个函数、理解这段指令在做什么、再把这些碎片拼成一个能被解释的规则。

AI 编程助手恰好擅长后面这半段：理解上下文、串联线索、解释与生成代码。它缺的是前面那半段——看见程序内部。REA 的价值就在于补上这一环：

值得注意的是，REA 把「共享工作流」做成了硬约束。官方文档写明，CLI 与 MCP 是同一批应用层工作流的两个薄适配器，而不是两套实现。这意味着：你在终端里跑出的结果，和智能体通过 MCP 拿到的结果，走的是同一条代码路径——不存在「命令行更准」或「AI 那边更好用」的偏差。

2怎么用：一句话，四步走

安装一条命令，使用一句自然语言。

安装

把下面这句话直接丢给你的编程助手，让它自己完成配置：

也可以在终端直接运行 npx rea-agents@latest setup。安装流程会注册 MCP 服务并写入配套的工作流指引，确认计划后重启助手即可。原生分析需要本机已有 Hopper、Ghidra 或 IDA；而静态 JavaScript 分析与 .NET 检查不需要任何原生分析引擎。

工作流程

REA 的官方调查流程可以概括为四步，关键在于它是一条可以不断追问的闭环：

图 1｜REA 调查流程（依官方流程图重绘中文版） 你提出一个问题 → REA 调动分析工具检查与追踪 → 返回代码、引用与未知项 → 智能体据此解释、实现并测试；任何一步都可以追问，回到第二步继续调查。

注意第 3 步里的一个细节：返回内容不只是「代码」，还明确包含「未知项」。这不是没做完，而是刻意的设计——后面第 5 节会专门讲。

3上手看两个真实例子

官网给了两个可以直接复现的示例，都很适合当直觉入口。

示例一：先弄清那个「反常识」的百分比

Windows 计算器里，200 + 10% 得到 220，而 200 × 10% 得到 20。同一个「%」键，为什么在两个运算符后面行为完全不同？

官网记录了实际调查过程：使用 REA 4.1.0 检查 Windows 计算器 11.2508.4.0（x64），REA 启动 calc.exe、打开 ms-calculator:，再由助手选定已安装的库，返回 % 处理函数的原始指令与可读摘要。结论是——它按运算符走了两条分支：

图 2｜同一个「%」按钮，两条不同的分支 在「+」之后，百分比作用于第一个数（200 的 10% = 20，故 200 + 20 = 220）；在「×」之后，百分数直接当作小数参与乘法（200 × 0.1 = 20）。规则与数值取自 REA 官网对 Windows 计算器 11.2508.4.0 (x64) 的实际分析结果

原始指令长这样（节选），助手读到的分支判据就是那两个运算符 ID：

汇编节选，运算符常量含义对照 Microsoft 公开源码命名

这些指令 ID 并不是猜的：IDC_MUL = 92、IDC_DIV = 91、IDC_PERCENT = 118 都能在 Microsoft 开源的 calculator 项目里找到对应定义。也就是说，REA 给出的是可以拿去交叉验证的结论，而不是一段「看起来很像」的推测。

示例二：Chrome 小恐龙为什么越跑越快

第二个例子更贴近「想改点什么」的场景：给浏览器小恐龙游戏加一个速度滑块。但要调参，先得知道原版的加速规则到底是什么。

这次的分析目标是运行在网页里的游戏脚本。REA 通过本地调试连接读取到已加载的 index.js，把实际代码与设置交给助手，规则随即浮出水面——总共三个常量：

图 3｜规则被读出来之后，参数就可以自己定 起始速度 6（SPEED），每次未发生碰撞的更新增加 0.001（ACCELERATION），加速到 13（MAX_SPEED）后不再变化。规则与常量取自 REA 官网对小恐龙游戏浏览器版的实际分析结果

更值得留意的是官网交代的验证方式：在受控的浏览器检查中直接调用原版更新函数、禁用障碍物与自动调度，结果保留一位小数时——更新 4,000 次后速度为 10.0，更新 10,000 次后为 13.0。这与上面的公式完全吻合，等于用实测给结论盖了章。

4三个「说到做到」的硬核案例

如果说上面两个是入门，下面这三个是真正见功力的地方。

案例一：DX-Ball——63 个字节的完全一致

DX-Ball 是 1996 年的 Windows 游戏。有个社区重建项目想把它重写成一份可维护的 C 代码，其中一项任务是：砖块被击中时，左右声像是怎么算出来的？

REA 提供了指令、调用方引用和数据常量。调查还原出的计算涉及几个浮点常量：

常量来自 DX-Ball 1.07 的分析记录，使用 REA 4.1.0。

还原出的函数通过了两项可独立复核的检查：

「字节完全一致」这个标准有多严格？它意味着重建的源码不只是算得对，而是和当年那版编译器生成出了逐字节相同的机器码。项目自己的记录也显示，这份重建代码有对应的编译器冷重放检查、明确的重定位清单，没有使用字节掩码或填充来「凑数」。

整个重建项目的进度同样值得一看（截至 2026 年 10 月 7 日）：

目前关卡与资源处理、砖块碰撞、动画、粒子与奖励生成已经还原；球与挡板的物理逻辑、道具处理以及 Windows 集成仍在推进中。这是一个进行中的工程，而不是一份演示。

案例二：TH04——把 16 位 DOS 弹幕对准玩家

TH04 是 PC-98 平台的游戏。它的「环形弹幕」怎么一次性算出 16 颗子弹的方向，并整体转向玩家？

REA 先检查了 DOS 映像以确认加载代码与重定位记录对应所提供的可执行文件（格式 dos-mz、加载段 4096、头 6144 字节、模块 150,114 字节），再分析角度计算函数。核心是一段很典型的定点运算：

0x2d0ed: SHL  AX, 0x8          ; 索引 × 2560x2d0f0: MOV  DL, byte ptr [0x53af]  ; 读取子弹数量0x2d0f9: IDIV BX                ; 除以数量 → 得到等分角

节选：等分角的计算。源码里这个数量字段被命名为 bullet_template.count

而「转向玩家」的部分，是把两个坐标差交给一个方向计算辅助函数，再把返回值叠加到环的基准角上：

// 重建源码（节选）group_angle_offset += iatan2(    player_pos.cur.y - bullet_template.origin.y,    player_pos.cur.x - bullet_template.origin.x);

游戏用 256 个角度单位表示一整圈，16 颗子弹之间各隔 16 个单位（0、16、32……240），再加上玩家方向，整圈就朝目标转了过去。这项还原的目标代码段在两次独立冷构建中被复现，编译工具链为 Turbo C++ 4.0J，目标 extent 为 2,139 字节。

案例三：Notion——跨进程追踪一次「复制」

前两个是原生二进制，第三个是 Electron 应用，考察的是跨层追踪能力：在 Notion 里复制一段内容，数据从页面到系统剪贴板走了哪条路？

REA 分析预加载脚本后返回了两个精确的源码位置（对应压缩包中的行号与列号），助手顺藤摸瓜找到了整条调用链：

把四段串起来的，是一个通道名：notion:clipboard:write。分析对象为 Notion Desktop 7.6.1，使用 REA 4.1.0。这个案例很好地展示了 REA 的能力边界：它负责把链路和位置找出来，解读与实现由智能体完成。

除这三个之外，官网案例页还收录了 Android APK 分析与 CTF 挑战等场景，合计 5 个案例。感兴趣可以去看完整版。

5它凭什么能被信任

让 AI 读二进制，最大的风险不是读不懂，而是「编得像」。

REA 在这一点上的设计，是全文最值得细看的部分。它没有把「让模型说得更自信」当成目标，反而把不确定性做成了产品结构的一部分。

第一，每条证据都标着「有多可信」

在 REA 里，一条证据不是一句结论，而是一个带类型的结构，其中有两个维度是明确枚举出来的：

两个枚举均定义于源码 src/domain/evidence.ts，且带偏序，可比较大小。

这两轴不是装饰。当 REA 要判定某个「未知项」是否已被解决时，会检查证据的置信等级是否达到该未知项要求的等级（inferred < derived < observed）——不够格的证据不能算作解决。官方工具设计文档里的原话很能说明取向：

第二，「未知项」是一个会被保存、被版本化的实体

这一点设计得相当少见。REA 里有 4 个专门操作未知项的工具（列出、记录、更新、验证解决）。每个未知项不是一条备忘，而是一个带编号（unk 前缀）的结构化记录，包含：

为什么值得这么做？因为在逆向工程里，「我确定不知道这里」本身就是极有价值的线索——它标出了证据链的断点，指明了下一轮该查哪里。如果模型把一个断点悄悄填上一个看似合理的猜测，整条证据链的可信度就被污染了，而且这种污染极难被发现。

REA 的态度在两句话里说得非常清楚，我把原文一并列出：

还有一个容易被忽略的细节：命令退出码为 0，并不代表这次调查没有未知项。未知项是正常结果的一部分，而不是错误。

第三，工具数量是「可审计」的

REA 对外公开的每个工具都有明确的效果审计（explicit effect audit for every public tool）。我在源码层面核对过这套契约的规模：170 个 MCP 工具、127 条 CLI 主命令、6 个 MCP prompt、31 个 provider 条目——而且工具数量用两套独立方法（逐个契约数组解析、与效果审计表交叉比对）算出来完全一致，无重名。

第四，失败时不「自作主张」

provider 的选择被设计为确定性排序，不做自动回退。也就是说，当你指定的分析引擎不可用时，REA 不会偷偷换一个引擎继续跑。原因是自动回退会破坏证据的权威归属——如果结论来自你不知道的引擎，那这条证据就没法被正确评估。

第五，各引擎的权限被写死

依据官方 AGENTS.md 及各 provider 文档。

与之配套的还有几条很具体的自我约束：安装器不得安装或升级任何无关软件（包括 Homebrew、Node.js、npm、Java、Ghidra 都不行）；rea setup 在写入文件或安装 Hopper 之前，必须先展示计划变更并获得批准；传输用的凭据要脱敏，且不得仅凭字段名就推断某个值是敏感信息。

6它能分析什么

覆盖面比想象中宽，从原生二进制一直铺到固件。

REA 需要 Node.js 22.19+ / 24.11+ / 26+ 与 npm；额外依赖取决于分析目标：

依据 README 的「可以分析什么」表格整理。

覆盖到 31 个 provider 条目，背后对应的是 13 组 provider 层（pwntools / EVM / Hopper / Ghidra / IDA / 制品与原生 / 浏览器 / JavaScript / V8 inspector / .NET / 固件 / Android / 引用库）。架构上有一条明文约束：依赖只能向内流动，引擎协议与 provider 专有代码不得进入 domain 与 application 层——这是它能同时容纳这么多异构引擎还不失控的原因。

7规模、活跃度与本地化

一个值得关注的信号：它的迭代速度。

项目创建于 2026 年 4 月 14 日，采用 MIT 协议，主力语言是 TypeScript。真正让人在意的是发布节奏——仅 10 月 5 日到 10 月 11 日这一周，就连续发布了从 4.0.0 到 6.4.0 的多个版本。官方文档里甚至专门提醒用户：「REA 更新较快，新版本经常包含错误修复，请保持安装的版本为最新。」

本地化做得很彻底：仓库根目录有 19 个 README 语言版本（1 个英文 + 18 个翻译），官网同样提供 19 种语言，包含简体中文、繁體中文、日本語、한국어、Русский、العربية、فارسی、ไทย 等。文档目录下约 44 篇技术文档，覆盖从安装、CLI、MCP 契约到各分析场景的完整链路。

支持的智能体达 18 个，包括 Claude Code、Codex、Cursor、Gemini CLI 等主流编程助手；任何支持本地 MCP 服务的客户端都可以通过手动注册接入。值得一提的是，它还专门为 DSH（DeepSeek Harness）做了适配——通过 DSH 侧的 MCP 客户端接入，工具名呈现为 mcp__rea__<tool>，并对 dsh 0.2.0-rc.2 做过端到端验证。

8边界：它不能做什么

这一节对想认真用它的人很重要。

它不替你做判断

REA 返回的是证据——指令、伪代码、引用、未知项。至于「这段代码实现的是什么业务逻辑」「这个值该怎么用」，仍然需要智能体（以及你）来解释。它的官方表述很克制：原生分析返回伪代码和汇编，JavaScript/Electron 分析恢复模块及其关系，智能体利用这些发现去编写并测试实现。

它明确不是沙箱

静态分析只读取文件；但运行时捕获会以你的用户权限运行目标或与之交互。官方在各运行时指南中要求明确说明这一点。也就是说，把 REA 指向一个不信任的程序时，你需要自己判断风险。

它不上传你的应用，但模型侧是另一回事

这是 FAQ 里最该看的一条：REA 在本机分析目标；但智能体会接收工具返回结果，而模型提供商有自己的数据政策。所以「本地分析」与「数据不出本机」是两件事，前者是 REA 的保证，后者取决于你用的哪个助手。

它需要合法授权

免责声明里还有一条颇有意思的补充：项目没有发行也没有背书任何加密货币或代币，任何使用 REA 名义的代币都与项目无关。对一个高星开源项目来说，这是很现实的防盗用声明。