REA 安装与首次使用指南

核验日期：2026-10-17。本文依据 REA 官方文档整理，尚未完成本站安装实测；仓库 main 分支与 npm 已发布包可能存在功能差异。

第一次用 REA，先确定要检查什么：JavaScript/Electron 应用可以走静态分析路径；原生程序的深度反编译则需要相应分析工具。把“接入助手”和“分析工具准备完成”分别检查，比遇到错误后反复重装更容易定位问题。

如果你还在判断它是否适合自己的任务，先看 REA 功能、适用场景与局限。本文集中讲首次接入和验收。

先按目标选择路径

REA 与 Ghidra 承担不同工作：REA 连接助手与分析流程；Ghidra 是可选的原生分析工具之一。静态 JavaScript 分析不要求先配置 Ghidra。见 官方项目说明。

第一步：确认下载来源和环境

从 官方仓库 morluto/rea、rea.tools 的链接进入安装说明。npm 包名为 rea-agents，不要仅凭同名仓库或复制的 README 判断来源。

先在终端检查已有环境：

node --version
npm --version

官方当前列出的 Node.js 要求是 22.x ≥22.19、24.x ≥24.11，或 26+。其他依赖随分析任务而变，安装前核对 官方快速开始。

第二步：接入你正在使用的助手

运行官方设置向导：

npx rea-agents@latest setup

选择需要配置的客户端，阅读拟修改的配置路径和操作，再确认应用。完成后重启助手；在需要单独启用 MCP 的客户端中，还要检查工具是否启用。

这里的验收点是“新会话能发现 REA 工具”。npm 下载完成、设置向导完成、当前会话可调用工具，是三个不同的状态。更多说明见 官方安装指南。

第三步：先完成一个边界清晰的任务

第一次建议使用自己拥有或获准分析的测试应用，只问一个具体问题。例如：

请先确认 REA 当前可用的工具，再检查这个应用的入口和模块关系。每个结论给出对应文件或分析证据，把无法确定的部分单独列出。

这是本文提供的任务模板，不是已验证的运行结果。确认工具返回了什么，再决定是否进一步追踪某项功能。

如果你的目标是已解包的 JavaScript/Electron 目录或 ASAR，也可以先走 CLI 路径：

npx rea-agents@latest analyze-javascript-application /absolute/path/to/app --json > app-evidence.json

把示例路径替换为目标的绝对路径，输出文件名自行选择。该命令可能产生较大的证据文件，不宜整份粘贴给助手；可按 官方 CLI 文档 从保存的结果中提取摘要。

连接失败时，按症状定位

先确认你失败在“命令启动、客户端注册、当前会话连接、分析工具依赖”哪一层。以下检查依据当前官方安装文档；它们不是各问题发生频率的统计。

终端有 Node，但 REA 仍提示版本不支持

node -v
npm -v

当前 REA 支持 Node.js 22.19+ 的 22 系列、24.11+ 的 24 系列及 26+，不支持 23、25 或预发布版本。若终端输出例如 22.14，先安装受支持版本，重开终端，再检查；不要反复重装同一个 REA 包。助手进程可能使用不同 PATH，终端正常不等于客户端环境相同。见 官方环境要求。

Windows PowerShell 提示禁止运行脚本

官方提供了使用命令 shim 的路径：

npx.cmd rea-agents@latest setup

这针对 PowerShell 启动 npx 脚本时的限制，不要求你全局关闭执行策略。完成设置后完全退出并重新启动客户端，再检查 REA 工具列表；Windows 原生分析的额外限制仍需单独核验。

setup 完成，助手仍看不到 REA 工具

先检查正在使用的客户端，例如 Codex：

npx -y rea-agents@latest doctor --client codex --json

其他客户端按官方表替换 ID。预期是针对该客户端的诊断健康；如果注册失败，按诊断修复对应配置。如果检查健康但当前会话仍没有工具，重启或重新连接客户端，并在 MCP 设置中确认 REA 已启用。诊断配置正常不等于当前聊天会话已连接；Skill 说明文件也不能替代 MCP 连接。

REA 可用，但 Ghidra 相关分析失败

npx -y rea-agents@latest doctor --provider ghidra --json

看指定 provider 的失败项，而不是仅看一个总体状态。核对 Ghidra、JDK 与路径条件；设置路径后重新运行 setup，让客户端获得更新的环境，再重启客户端。出现 ambiguous 时先查看返回的候选并显式选择，不要把它当成“完全没安装”。使用 JavaScript/Electron 静态路径则不需要为了这个任务先修好 Ghidra。

macOS 静态分析报辅助程序编译失败

本站 Electron 实战 的首轮受限沙箱运行确实遇到了这个问题：诊断指向 xcrun 编译进程归属辅助程序失败。先确认命令行编译工具可用，阅读诊断中的编译错误，并确认当前环境允许所需的本地编译。该问题与助手是否加载 Skill 不同；本案例在正常编译权限下运行成功，不能据此保证其他编译错误有相同原因。

命令有 JSON 输出，但不知道算不算成功

先查看是否有 error、code、remediation；有错误时不要把部分观察当成完整成功。成功 Evidence 中再检查 operation、coverage、limitations 与任务所需字段。保留错误信息，按对应失败项修复后再试。完整 JSON 可能带本机路径，分享前先检查。

官方参考：安装与诊断文档。想练习独立于客户端连接的 CLI 路线，可以跟做 五文件 Electron 静态分析案例。

Windows 用户需要额外确认什么？

不要把“REA 能在 Windows 启动”理解为“所有分析路径都受到同等支持”。官方将 Windows Ghidra P0 标为实验性边界，并列出系统、磁盘、JDK、Ghidra 与目标格式条件；仓库新增能力也不一定已进入你安装的 npm 版本。

计划分析 Windows 原生程序时，先对照 Windows Ghidra P0 文档 核验自己的版本与目标，再配置环境。

怎样判断第一次分析完成了？

可以用三个问题检查结果：目标身份和路径是否明确？结论是否能回到具体证据？尚未识别的部分有没有被说明？这是阅读分析结果的检查方法，不代表对 REA 准确率的测试结论。

静态分析与运行时观察应分别理解：静态 JavaScript 工作流读取应用材料，而运行时观察涉及与正在运行的目标交互。需要追踪功能时，先读 官方 JavaScript 应用工作流，确认当前结果的证据范围。

接下来可以返回 REA 详情与源码审查，结合自己的目标判断是否需要继续深入。文档提到的功能若在本地不存在，先核对已安装版本，避免将仓库 main 分支说明直接套在旧包上。