跳到正文

上线时间 2026年4月

档案卡 · 第 065 号

REA

一个跑在本机的 MCP 服务器和命令行工具,把反编译器、JavaScript 与 .NET 读取器、浏览器和进程录制器收成同一套工具给 agent 调用,每条结论都连同证据和它的边界一起返回。

Screenshot of REA
编辑截图, 11 Oct 2026REA ↗

这是什么

REA 回答的是源码回答不了的那个问题:一个已经发出去的程序,是怎么做出这个功能的。

它是一个跑在本机的 MCP 服务器加命令行,agent 逐个工具去调,每次调用返回的是它查到了什么,以及这个结论背后的证据。

用它打开一个原生二进制,走的还是你机器上已经装好的 Hopper、Ghidra 或 IDA,读出伪代码、汇编、字符串、交叉引用和调用图;

解开一个 JavaScript 或 Electron 应用,一路跟到它的 IPC 边界;

不运行就读取 .NET 程序集的元数据和 CIL;

用本机的 Chrome 系浏览器打开页面,记录它请求了什么;

录下一个进程的终端输出、退出状态和对文件系统的改动;

解包固件、反编译安卓包,或者读一份存下来的 HAR。

分析全程在本机完成,项目的规矩是 local-only,除了 agent 自己的模型服务商收到的东西之外什么都不外发。

某个工具看不到的地方,结果会写成一条未知,而不是把空白补上。

反编译本身不在这个包里,安装包也不在:release 页面一个文件都没挂。

谁做的

一个 2020-12-22 注册的 GitHub 账号,252 个公开仓库、1,549 个关注者,简介写着 member of technically staff,所在地标的是 Sinsai。贡献者表上有 92 个账号。除作者之外,主要出力的是三个:@N0zoM1z0 445 次提交、@kaoru0822-kitauji 373 次、@rudycelekli 85 次,对比作者本人的 1,214 次。README 里挂的两个 showcase 就是第一个账号自己的仓库:N0zoM1z0/dx-ball 和 N0zoM1z0/th04。

它是怎么搭起来的

组成 · 6

组织方式是:分析是一条由声明式契约搭起来的流水线,agent 只是它的一个客户端。每项能力都是一个带具名输入 schema、具名输出 schema 和一份审计过的效果记录的工具,而同一份清单同时支撑 MCP 服务器、命令行和自动生成的文档——正因如此,CATALOG_IDENTITY 才能对整个表面发布一份 sha256,验证器才能拿发布出去的包去比对它声称的那个源码版本。围绕这份清单有四层,依赖只有一个方向:领域语义与契约在中间,外面是 provider 适配器,再外面是共享的应用流程,最外面是 CLI 与 MCP 适配器;AGENTS.md 把这条写成规则,.github/workflows/ci.yml 用模块边界检查去强制它。provider 不随包分发。每一个都是 REA 写给别人的脚本接口的桥:Hopper 走它的 Python 接口,Ghidra 走一份无头的 Java 脚本,IDA 和 JEB 走调用者本来就起着的 MCP 服务器。这样 REA 不必自己发布一个反编译器,agent 仍然拿得到反编译结果。什么都不上传,什么都不改:原生分析跑在临时的 Ghidra 数据库上或只读挂载的 IDA 上,批注落在会话里而不是可执行文件里,AGENTS.md 也禁止安装器去碰无关的软件。

src/contracts 与 src/server
公开表面:172 条工具契约,各带具名 schema 和效果审计,旁边是提示词契约、给预算更小的客户端用的 schema 档位,以及把这一切注册进去、并用同一种规范编码返回结果的 MCP 服务器。
src/domain
458 个文件、约十万行语义:Evidence 记录及其打包、带标签的错误代数、分析视图与档位、调用路径、函数对比、重构覆盖率与它的义务账本、dyld 解析,以及 JavaScript 的语义图和静态分析。
src/hopper、src/ghidra、src/ida、src/jeb 与 bridge/
四个 provider 适配器和它们驱动的脚本。Hopper 走一条 socket 连到加载在应用内部的 Python 桥,配目标租约和可取消的正则 worker;Ghidra 用 AnalyzeHeadless 加 REA 自己的 Java 脚本无头启动;IDA 和 JEB 走调用者自己起的 MCP 服务器。
src/dotnet、src/native、src/artifacts 与 src/javascript
不需要任何引擎的读取器:一个覆盖元数据堆、表布局和 CIL 的托管程序集解析器,Mach-O 与 PE 资源检查、plist、归档、代码签名、Apple 应用包解剖、包格式、source map 解码,以及 JavaScript 源码恢复。
src/browser、src/process、src/inspector、src/adb 与 native/windows
看东西跑起来的那一半:DevTools 协议上的浏览与场景录制、进程归属与录制、Node Inspector 目标、经 adb 的安卓设备控制,以及那个用 C++ 写的 Node-API 插件——它在 Windows 上提供基于句柄的文件系统权限、Job Object 归属和私有 DACL。
src/cli、install.sh、.agents/skills 与 .github/workflows
入口:和工具一一对应的单次命令、先出计划再改客户端配置并留备份的 setup、随包的 reverse-engineer-anything skill 及其参考文件,以及二十二个 workflow——其中大多数名字里带 Real,因为它们跑的是真引擎而不是夹具。

取舍,以及另一种做法

  • 驱动用户已经装好的引擎,而不是自己带一个反编译器 替代 自带一套分析引擎

    third_party/README.md 把政策和理由写在一起:上游源码原样留在按提交钉住的 submodule 里,绝不复制进 REA 的领域层或应用层,分析过程中也不下载任何引擎。REA 留下的是桥、契约和解释,这也是为什么 Ghidra 的桥是这仓库里 3,833 行 Java,而不是一个依赖。

  • 审计每个工具的效果,再从这份审计里推出它的 MCP 注解 替代 逐个手工决定只读与破坏性提示

    toolEffects.ts 为全部 172 个工具声明了效果记录,annotationsFromEffects 只从那八个布尔值推出四个 MCP 提示,完全不看工具名,而 toolContractMetadata 在缺条目时直接抛错。新增一个工具,就必须有人先写清它对目标、会话、文件系统和网络做了什么。

  • 让面向 agent 和面向人的两个表面共用同一份清单 替代 给命令行另开一套顺手的命令

    命令行的名字是 src/cliCommandNames.ts 里一个冻结的对象,工具契约是一个有序数组,catalogIdentity.ts 把三份目录合在一起做摘要。正因如此验证才有意义:可以拿发布出去的包去问,它的工具清单是不是那份规范清单。

  • 不让 setup 安装或升级任何它非装不可之外的东西 替代 让 setup 一步到位装好整套工具链

    AGENTS.md 给安装器写死了这条规则,点名 Homebrew、Node.js、npm、Java 和 Ghidra 都不许碰,并要求 rea setup 在写文件之前先展示计划、取得批准。Hopper 是唯一的例外,而即便是它,也是提出建议而不是直接动手。

  • 在调用者的机器上分析,什么都不上传 替代 做一个托管的在线分析服务

    仓库自称 local-only,目标从本机路径读取,引擎作为子进程启动,README 对上传问题的回答是把数据政策指向 agent 自己的模型服务商。这是一份用户不被允许发到任何地方的目标也能拿来分析的原因。

依据morluto/rea 的 README.md、AGENTS.md、CONTRIBUTING.md、SECURITY.md、package.json、server.json、.gitmodules、third_party/README.md、docs/installation.md、docs/testing.md、docs/mcp-contracts.md、docs/windows-ghidra-p0.md、docs/roadmap.md、docs/architecture.mermaid、vitest.config.ts、.github/workflows/ 下的 ci.yml 及其余 workflow、scripts/verify-deepseek-client.mjs、src/catalogIdentity.ts、src/contracts/、src/domain/、src/native/、src/dotnet/、src/hopper/、src/ghidra/、bridge/、native/windows/ 与 .agents/skills/,2026-10-11 读取。

制作过程

7 个阶段
  1. 01

    这 30 MB 里是什么

    我在 2026-10-11 的 14:58Z 克隆了 main,量的是代码树而不是仓库页面。树里有 2,779 个文件、31,123,835 字节,合 29.7 MiB。GitHub 自己的 size 字段写 46,708 KB,因为那统计的是 packfile 里存的东西。语言统计和这棵树只差零头:TypeScript 14,136,292 字节,JavaScript 1,714,588,HTML 521,528,Python 292,270,Java 274,198,C++ 69,042,汇编 4,208 字节。 只算源码不算数据,2,467 个文件里有 497,077 行。体量在 src/:1,497 个 TypeScript 文件共 300,089 行,其中 340 个是长在源码树里的测试文件、占 77,189 行,于是非测试的 TypeScript 是 222,900 行。光 src/domain 一个目录就是 458 个文件、100,001 行。tests/ 另有 578 个文件、127,061 行,scripts/ 是 241 个 .mjs、48,664 行,docs/ 是 47 份 Markdown、10,460 行。把 src/ 和 tests/ 合起来数,742 个文件里有 4,463 个 it( 块,分散在 vitest.config.ts 里那十二个 vitest 项目下。单文件最大的不是一张表:src/adb/AdbProvider.ts 有 2,070 行,后面跟着 1,798 行的 src/domain/native/nativeAotPe.ts、1,531 行的进程录制生命周期文件、1,459 行的客户端配置文档,以及两个各 1,220 行和 1,119 行的 JavaScript 语义分析文件。 剩下的不是代码。website/locales/ 下有 18 份 gettext 目录,分别是 ar、de、es、fa、fr、id、it、ja、ko、pl、pt-BR、ru、th、tr、uk、vi、zh-CN 和 zh-TW。合起来 237,154 行、9,094 KB,单份文件从中文的 471,205 字节到泰文的 619,905 字节。英文 README 旁边还有十八份译本。有四座桥不是用 TypeScript 写的:光 bridge/ghidra/ReaGhidraBridge.java 一份就是 3,833 行、185,179 字节,Ghidra 那批脚本合计 4,879 行 Java;bridge/hopper_bridge.py 是 1,162 行 Python,bridge/native/rea_lldb_tracer.py 是 839 行;native/windows/src 是 1,326 行 C++,编译成唯一一个预编译的 Windows 插件。

  2. 02

    一台服务器、172 个工具,以及每个工具背后站着谁

    公开的工具清单就是一个有序数组。src/contracts/toolContracts.ts 把 25 个文件摊进 TOOL_CONTRACTS,而每条契约都经由一个辅助函数调用 toolContractMetadata(name);只要 src/contracts/toolEffects.ts 里没有对应条目,这个函数就抛出 Missing effect audit for <name>。那份文件就是审计表,所以它的键就是工具名单:172 个名字,从 open_binary、list_procedures、procedure_pseudo_code,经 analyze_javascript_application、inspect_managed_artifact、observe_web_execution、capture_process_scenario、extract_firmware、pull_adb_package,一直到 verify_reconstruction 和 build_reconstruction_obligation_ledger。直接解析那 28 个契约数组得到 170 个名字,另外 read_bytes 和 address_to_file_offset 单独放在另一个文件里,两个数在 172 上对上。src/catalogIdentity.ts 把同一个数字发布成 CATALOG_IDENTITY.counts.mcp_tools,旁边是命令行条数和三份 sha256,分别覆盖工具目录、提示词目录以及两者合并后的结果。 每个名字背后站着的东西并不一样。做原生分析时,REA 里没有反编译器,只有通往三个反编译器的桥。Hopper 由 bridge/hopper_bridge.py 驱动,REA 把这份脚本加载进正在运行的应用里,src/hopper/ 是它的客户端:请求队列、目标租约、可取消的正则 worker、清理,以及 1,026 行的 HopperClient.ts。Ghidra 通过 ghidra.app.util.headless.AnalyzeHeadless 无头启动,用 -scriptPath 和 -postScript 挂上 REA 自己写的脚本,包括 ReaGhidraBridge.java、ReaGhidraPrepareCom.java、ReaGhidraApplySeeds.java 和 ReaGhidraNoReturnFix.java。IDA 走调用者自己起的 IDA MCP 服务器,JEB 走调用者自己起的 JEB 客户端,JADX 走调用者自备的无头 MCP JAR,固件走 Binwalk 或 Unblob。 另外一些名字背后是 REA 自己的读取器。src/dotnet 是 28 个文件、9,278 行,不运行就解析托管程序集:PE 读取器、元数据堆、表布局与行宽、CIL 指令解码器、方法体读取器,以及异常区的校验。src/native 是 54 个文件、11,982 行,做 Mach-O 检查、PE 资源解析、plist 与归档、代码签名读取、胖二进制选择、dyld 解析和 LLDB 调用跟踪。src/browser 是 113 个文件、24,424 行,跑在 DevTools 协议上;src/process 是 57 个文件、13,917 行,管进程归属与录制;JavaScript 那一侧自带解析器、语义图和 source map 解码器,不叫外部分析器。 third_party/README.md 用一段话交代了这个安排:REA 通过 provider 适配器接入已有工具,上游源码原样留在按提交钉住的 submodule 里,不会被复制进 REA 的领域层或应用层。五个 submodule 各钉了一个提交:JADX 的无头 MCP、Binwalk、Unblob、一个 NativeAOT 的 Ghidra 扩展,以及 Wakaru。分析过程中 REA 不会去下载任何引擎。

  3. 03

    「什么都能逆」这句话能核到哪一步

    说法写在仓库简介里:Reverse engineer anything with agents, from app behavior down to native binaries. 能核它的地方是 README 自己那张能力表,因为最后一列写明了每个目标需要什么。表里一共 15 行。两行除了 Node 什么都不用:JavaScript 与 Electron 应用,以及 .NET 程序集,后者的要求一栏写的是 None (static only)。另外两行需要读者大概率已经有的东西:网站要一个 Chrome 系浏览器,存下来的抓包要一份 HAR。剩下十一行都点名了一个引擎或一套操作系统。原生二进制要 Hopper、Ghidra 或 IDA。离线 ELF 布局要在 Linux x64 上由调用者自备 pwntools。WASM 产物要 WABT 1.0.42。EVM 字节码要在 Linux x64 上有一个原始载体。录下来的 Linux 崩溃要 pwntools,可选再配 GDB 与 pwndbg。安卓包要无头 JADX 和完整 JDK,安卓设备要 adb,安卓资源要 Apktool。固件要在 Linux 上跑 Binwalk 或 Unblob。JEB 工程要调用者先起一个 JEB 客户端。进程行为要 Linux 或 macOS 上的原生 PTY。 Windows 的边界是写下来的,不是踩出来的。docs/windows-ghidra-p0.md 把它在 Windows x64 上的支持称作实验性的、只读的,点名可用的只有 25 个只读的 Ghidra 清单、内存与函数操作,并用自己的话写着,这条边界不构成 Windows 上的功能对齐。32 位 x86 的 PE 支持在 main 上,5.0.0 之前的 npm 版本里没有。Ghidra 的图形界面状态、批注、其他架构与格式,以及所有只属于 Hopper 的操作,都不在这条边界内。Hopper 本身是 REA 在 macOS 和 Linux 上驱动的应用,项目为它单独留了一条 Linux 验证通道和一个私有显示探测。 分析是不是真的,和它能不能带走,是两个问题,而在前一个问题上这棵树给得很具体。.NET 读取器自己解 CIL,还校验异常区。Mach-O 那一侧会预测 dylib 的加载顺序,再拿 dyld 实际加载的镜像去对。JavaScript 那一侧建的是带成员改写、promise 归属和引用生命周期的语义图,并在同一个进程里解析 source map。src/domain/native/nativeAotPe.ts 从一个只读镜像里解析 NativeAOT 的 ready-to-run 快照。树里没有的是反汇编器、反编译器和模拟器。README 结尾那句免责声明就是整件事的形状:REA 提供的是合法的逆向研究工具,而深度原生那条通道是别人的引擎,跑在 REA 维护的一份契约上。

  4. 04

    DeepSeek Harness:文档里有,POSIX 上验过,setup 不支持

    本站读者和这一节直接相关。DeepSeek Harness 不在 REA 的客户端表里。那张表列了 rea setup --client 能配置的 17 个客户端:Claude Code、Claude Desktop、Codex、Cursor、Gemini CLI、Windsurf、Devin、OpenCode、Antigravity、GitHub Copilot CLI、Command Code、Qwen Code、VS Code、Grok Build、OMP、Pi 和 Hermes,Grok Bot 因为连接器不是这些文件而单列在表后。Harness 在表下面另起一节,标题就说明了差别:它用的是 Cordis 的 YAML 补丁序列,而不是 mcpServers 对象,setup --client 不改这种格式。 文档给的是一段手写补丁,针对 Harness 0.2.0-rc.2。往 $DSH_HOME/cordis.patch.yml 里追加一条,DSH_HOME 未设时是 ~/.dsh/cordis.patch.yml;条目里写 id: rea-mcp、name: "@deepseek-ai/dsh-mcp-client"、serverName: rea、transport: stdio,以及 node 和 scripts/rea.mjs 的绝对路径。Harness 之后把这些工具暴露成 mcp__rea__<tool_name>。skill 是第二步,用 rea setup --skill 装进 ~/.agents/skills;Harness 自己会扫这个目录,配置了 $DSH_AGENTS_HOME/skills 时扫那里,然后它原生的 skill 工具就能装载 reverse-engineer-anything。 这条集成有一条验证通道,而且很窄。npm run verify:deepseek-client 跑的是 scripts/verify-deepseek-client.mjs:它要求本机已经装了 dsh,按 @deepseek-ai/dsh@0.2.0-rc.2 验过;把 Cordis 补丁写进一个隔离的 DSH_HOME,把 HOME 和 USERPROFILE 绑到一个一次性账号上。它检查 skill 能否加载、完整目录能否被发现、转发过去的输入 schema 和正则,以及一个路径里带非 ASCII 字符的 JavaScript Evidence 结果。它的第 9 行直接断言平台不是 Windows,附带一句 Native Windows coverage is unverified. 背后的模型是一个本机的 OpenAI 兼容假服务,声明着一百万 token 上下文,也就是 Harness 默认那个 DeepSeek Flash 模型的容量,所以这条通道建立的是「接通了」,不是「线上 DeepSeek API 可用」;docs/testing.md 原话就是这么说的。这条通道只在 POSIX 上跑,.github/workflows/ 里没有任何一个 workflow 调它,所以它只在有人手动跑的时候才跑。 缺口在 issue 列表上,而且带着方案。#1839,标题是 [Feature] Add native DeepSeek Harness (DSH) client support to REA setup,2026-10-11 提交,标签是 enhancement 和 triage,我读的时候一条评论都没有。正文把缺的东西列得很具体:rea setup --client dsh --dry-run --json、rea doctor --client dsh --json、可重复执行的注册、安全移除,以及不能碰 Cordis 里无关的内容;作者同时表示愿意自己实现,并请维护者就 Cordis YAML 该怎么安全处理给个方向。开着的就是这个问题。前一天还有一条 #1636,问的是 Harness 那种进程不退出就算跑完的无头模式该怎么跟踪。

  5. 05

    半年的提交历史,大半在最后一周

    GitHub 在 2026-04-14 建了仓库,第一次提交落在同一分钟,2026-04-14T00:51:30Z。然后是空白,一直到 2026-07-11。main 上现在有 2,323 次提交,最后一次在 2026-10-11T14:58:01Z。 按月算是四月 1 次、七月 697 次、八月 21 次、九月 100 次、十月 1,504 次。按周看更陡。2026-07-06 那一周 110 次,下一周 364 次,然后 172、56、11、4,八月和九月大部分时间一周只有一次;再往后 2026-09-28 那一周 107 次,截至 2026-10-11 的最后七天是 1,496 次。整个项目将近三分之二的历史写在它最后一周里,十月那七天的日计数依次是 117、113、281、205、351、268 和 161。 提交标题说明了这是哪一种工作。2,323 次提交里 1,005 次以 fix 开头,对比 200 次 test、187 次 feat、181 次 docs、164 次 refactor 和 105 次 perf。作者名有 103 个;按 GitHub 账号算是 morluto 1,214 次、N0zoM1z0 445 次、kaoru0822-kitauji 373 次、rudycelekli 85 次,贡献者接口返回 92 个账号。380 次提交带 Co-authored-by 尾注,489 行尾注里有 297 行点名了某个模型或 agent:Claude Opus 5.5 占 260 行,Cursor Agent 23 行,Devin 5 行,Claude Sonnet 5.5 3 行。78 次提交带 Signed-off-by。分支列表翻一页基本都是 agent 分支:agent/…、codex/…、cursor/…,和 release/…、fix/… 混在一起。 release 很密,而且是空的。从 2026-07-12 的 rea-0.2.0 到 2026-10-11 的 rea-agents-6.4.0 一共 35 个,每一个挂的附件都是 0,因为分发走的是 npm。npm 上有 31 个 rea-agents 版本,6.4.0 解开是 7,776,450 字节。下载量的形状和提交一样:九月每天 10 到 43 次,然后 2026-10-03 是 418 次,次日 798 次,再往后 4,048、5,032、9,000、19,983 和 34,790。最后这一周占了整月 74,461 次下载里的 73,651 次。README 里有两行属于同一个事实:星数那一段现在写的是 90,000 GitHub stars,下面那段免责声明说项目没有发行也没有背书任何加密货币或代币,用 REA 名字的代币与本项目无关。这个数字跑得比一条记录能记住的速度快:2026-10-11 的 22:52 接口返回 91,053 颗星,同一天 23:07 本站写入的监控基线读到的是 91,384。

  6. 06

    159 个未关闭的条目

    2026-10-11 这天 GitHub 的计数器读数是 159 个未关闭条目。同一天晚上把 issue 接口翻完,得到 107 条 issue 和 50 条 PR,而单查 PR 接口是 51 条,所以这个数字主要是 issue,加上一部分来自贡献者的在办工作。107 条里只有 15 条挂着 bug 标签,71 条是 enhancement,45 条还挂着 triage,也就是维护者还没读到。其余高频标签是 P1: high 36 条、roadmap 22 条、area: mcp 18 条、P2: medium 16 条、area: providers 12 条、area: domain 11 条、P0: critical 10 条。另外 19 条一个标签都没有。 107 条里有 53 条一条评论都没有,66 条是这条记录之前七天内提的。11 条超过三个月,27 条在一到三个月之间。最老的那十条全部提于 2026-07-12,也就是第一个 release 的第二天,它们是几份总纲:#32「把 REA 演进成 agent 优先的多工具逆向平台」;#39 浏览器与 Web 支持;#48「Evidence v2 与确定性进程保真」;以及 #54、#55、#59,讲 Hopper 函数档案和进程树录制。同一批里还有一组 Hopper 一致性验证器的总纲,#333 和 #339 到 #344。 最大的一簇是 Windows,而且是一份总纲拆成了十六条 issue。#287 到 #290、#318 到 #329 全部提于 2026-07-16 和 2026-07-20,讲的都是同一个原生 Node-API 包:基于句柄的、防重解析点的文件系统权限,带 kill-on-close 的 Job Object 归属,运行根目录上的私有 DACL,以及每一项各自的真机 Windows 验证器。它们到现在还开着。下一簇要的是新的 provider 通道而不是修 bug:MIPS16(#1851)、armhf(#1745)、PowerPC(#1741)、6502 与 65816(#1641)、MIPS32(#1620)、PSP(#1330)、AArch64 跳转表(#487)、dSYM 匹配(#1193)、NativeAOT(#744),外加三条干脆想换引擎的:Binary Ninja(#1551)、Hex-Rays 官方的 IDA MCP 服务器(#1416)和 rsleigh(#1389)。客户端接入是单独一小撮:DeepSeek Harness(#1839)、Kimi Code(#1791)、Codex 插件(#1269),以及一个不需要包管理器的安装方式(#1316)。 bug 那一类是用户会撞上的那种。#1387 说 analyze-javascript-application --json 在一个 6.2.0 能跑完的 bundle 上中止,也就是一个人手里那个版本的回归。#1554 说完整的 MCP 输入目录会让 GitHub Copilot CLI 的普通对话直接卡住。#1720 说查询类调用死在一个固定的 60 秒超时上,比配置的 Ghidra 启动期限还短。#1719 说 open_binary 根本没起 provider 客户端就返回了。#1701 说 Windows 原生权限自检在真机上失败,还留下探测目录。#1808 说 demo 模式的 Hopper 6.6.0 在分析一个系统二进制时段错误,并留下一个中毒的会话。#1859 提于写这条记录的同一天,说 Windows 上的真机 Ghidra 验证器在所有主机上都失败。讨论最多的是设计类而不是 bug:#1065 有 40 条评论,#740 有 21 条,#287 有 15 条,#724 有 11 条。

  7. 07

    它跑得起来,以及跑起来之前要装什么

    安装是一条命令。npx rea-agents setup 把你选的客户端注册好并装上配套 skill;npm install --global rea-agents 得到一个终端里的 rea;仓库里的 install.sh 只要平台不是 Darwin 或 Linux 就直接退出。Node 是唯一的硬要求,22.x 从 22.19 起,24.x 从 24.11 起,或者 26 及以上。 我没有描述发布包,而是把它拉了下来。rea-agents@6.4.0 压缩后 1,825,761 字节,解开 7,776,450 字节,一共 1,161 个条目:其中 1,112 个是 dist/ 下的 JavaScript,7 个是随包的 skill,21 个是那几座桥,还有一个是预编译的 Windows x64 Node-API 插件,在 native/windows/build/rea-windows-x64.node。Ghidra 那批 Java 脚本和 Hopper 的 Python 桥都在 npm 包里,所以没有人需要自己拼一座桥。包里有 35 个运行时依赖。 rea setup 先给一份计划、要批准才动文件,改动之前会备份,而且不会安装或升级 Ghidra、Java、Python、Node、npm、Hopper 或编译器。Hopper 是它唯一能提出帮你装的引擎,而且只在批准之后。分析在本机完成,README 对「REA 会不会上传我的应用」的回答是:目标在本机分析,agent 自己的模型服务商另有它的数据政策。 持续集成是体量显形的地方。注册在案的 workflow 有二十二个,二十一个在跑、一个被手动关掉,接口记录的运行次数是 13,777。主 ci.yml 自 2026-09-01 起完成了 2,500 次,其中 800 次落在写这条记录之前的 25 小时里。这 800 次里 198 次成功、115 次失败、266 次被更新的提交取消,还有 221 次停在 action_required,那是 GitHub 在等维护者批准一个 fork 的 workflow。在 main 上被取消才是常态:214 次 push 触发的运行里,182 次被取消。包验证矩阵跑在 Linux x64、Linux arm64、macOS 15 的两种架构和 Windows x64 上。 有两条边界写在仓库自己里面。Windows 上的原生分析就是前面那条实验性、只读的边界,而 DeepSeek Harness 的验证通道干脆拒绝在 Windows 上运行。另外 main 上有的功能,你装的那个 npm 版本里不一定有;docs/installation.md 专门留了一节 Released package and main,里面点名说 2026-10-11 查过的版本是 6.4.0。

他会告诉你什么

  • 没有安装包可下载。35 个 release 的附件全是零,而 install.sh 只要平台不是 Darwin 或 Linux 就直接退出,所以在 Windows 上走的是 npm 加那个预编译的 x64 插件。Windows 上的原生分析在 docs/windows-ghidra-p0.md 里被写成实验性、只读,可用的是 25 个 Ghidra 操作;32 位 x86 的 PE 支持在 main 上,5.0.0 之前的 npm 版本里没有。
  • 这句话的边界是读者手里已经有什么。README 那十五行目标里有两行除了 Node 什么都不用,另外十一行点名了一个引擎、一个设备工具或一套 POSIX 主机,而且 README 就在提出主张的那张表里写明了是哪一种。所以这里的「什么都能」指的是:格式要么在这仓库里有读取器,要么你盘里有引擎。
  • 星数和项目年龄不是同一个测量。91,053 颗星和 20,140 个 fork 在不到半年里到齐,可仓库在头三个月里只躺着一次提交,2,323 次提交里有 1,496 次落在最后七天,1,005 次提交以 fix 开头。4.0.0、5.0.0、6.0.0 三个大版本分别在 2026-10-05、2026-10-07 和 2026-10-08 发出,相隔三天。
  • 未关闭的队列很年轻,而且大多不是 bug。107 条开着的 issue 里 66 条是最后一周提的,53 条一条评论都没有。一份拆成十六条的 Windows 原生权限总纲从 2026-07-16 和 2026-07-20 开到现在,Hopper 函数档案和一致性那几份总纲从 2026-07-12 开到现在;还没收敛的工作其实都在那里。
  • CI 的通过率没有它的体量那么好看。25 小时里完成 800 次 ci.yml,其中 198 次成功、266 次被取消、221 次在等维护者批准 fork 的 workflow;在 main 上,214 次 push 触发的运行里有 182 次被后来的提交取消。这里的一个绿勾说的是某一次提交的某一刻,而五个 runner 上的包验证矩阵才是那张矩阵里值得数的部分。
  • DeepSeek Harness 在文档里有,在 setup 里没有。rea setup --client 覆盖 17 个客户端,Harness 不在其中,集成方式就是文档里一段手写的 Cordis 补丁加一次单独的 skill 安装。验证通道拒绝在 Windows 上运行,用的是本机模型夹具而不是线上 API,而且没有任何 workflow 会调它。#1839 要的是把它做成一等支持,写这条记录时还没有回复。
  • 有四条开着的 bug 说的不是分析本身,而是答案的形状。#1719 说 open_binary 没起 provider 客户端就返回;#1720 说查询类调用死在一个 60 秒上限上;#1387 说新的小版本在一个上一版能跑完的 bundle 上中止;#1808 说 demo 模式的 Hopper 段错误之后留下一个中毒的会话。这四条里工具都答了话,而答出来的东西不是契约上写明的那个。

相关档案

全部档案 →