REA（morluto/rea）：把「逆向工程」做成智能体的一个 MCP 工具面——134 工具、24 Provider、无静默回退的工程拆解

一、导读

REA（Reverse Engineer Anything，当日涨星 +4,655、★16,948、MIT）把二进制、JavaScript/Electron、.NET、Android、固件与网页运行时的逆向能力，收敛成一个本地 MCP Server + 一套同源 CLI。它的关键不是「又一个 Ghidra 插件」，而是三条纪律：工具面按分析师任务形状设计、Provider 选择确定且永不静默回退、每条结论都带可复用 Evidence。

二、项目速览

项目	详情
仓库	morluto/rea（GitHub API，数据获取日 2026-10-08）
主语言	TypeScript（含 Java/Python Bridge 与原生 Node-API 模块）
Star / 当日涨星	16,948 / +4,655（GitHub Trending daily，2026-10-08）
Fork / Watch / License	1,771 / 50 / MIT
首次发布	2026-04-14（仓库创建）；最新提交 2026-10-08
最新版本	rea-agents 5.0.0（2026-10-07 发布，该 Release 含 133 个 MCP 工具）
规模	文件树约 1,974 个文件
工具面	134 个 MCP 工具 · 89 个 CLI 命令 · 6 个 MCP Prompt
集成面	24 个 Provider（含 3 个深度引擎）· 12 个可配置客户端
分发	npm rea-agents；MCP Registry io.github.morluto/rea

三、为什么是它：问题背景与定位

痛点：瓶颈不是「分析不出来」，而是「结论留不下来」。 逆向的传统工作流是「人择工具、人搬证据、人记笔记」——用 Hopper 看反汇编，切 Ghidra 看 CFG，把伪代码复制进笔记，下个问题重来。当驱动者换成编码智能体，代价被放大：智能体每轮都要重建上下文，而跨工具的证据链从来不存在于任何一个工具里。

定位：不是反编译器，是「调查协调层」。 项目措辞克制——不声称恢复原始源码，也不声称自动克隆应用。REA 把已有引擎（Hopper / Ghidra / IDA / JADX / Binwalk / Unblob / Wakaru / CDP / V8 Inspector）装到背后，向智能体暴露一套 provider-neutral（引擎中立） 的工具契约。第三方评测概括为「它是工作流协调器，不是反编译器；价值取决于你已装的那个 Provider」。

涨星动因。 一是精准踩中「MCP + 编码智能体」交汇点——把逆向这种高门槛手工技能接入 MCP，等于开了一个新工具品类；二是工具面数量本身构成传播点——134 个 MCP 工具远超常见单引擎 MCP 服务器；三是零门槛验证，无引擎也能先跑静态 JavaScript 分析，30 秒见效。

四、【重点】架构原理

4.1 整体架构：六层 + 一条「不变的绑定」主线

官方架构图把系统切成入口层 → 适配层 → 应用层 → Provider 层 → 进程基础层 → 契约层。压缩后的数据流视图如下：

┌── 入口层 ─────────────────────────────────────────────────────┐
│ src/main.ts      MCP stdio server（配置/会话/进程生命周期）    │
│ src/cli.ts       CLI 适配器（setup / doctor / analysis）      │
│ scripts/rea.mjs  调度器：路由 mcp 与 one-shot                 │
└──────────────┬────────────────────────────────────────────────┘
               │ 两者共用同一套 application 工作流（CLI/MCP 对等）
               ▼
┌── 适配层 ─────────────────────────────────────────────────────┐
│ src/server/    MCP 请求翻译、createServer、工具注册            │
│ bridge/hopper_bridge.py   跑在 Hopper 内，适配其 Python API   │
│ bridge/ghidra/*.java      打包 HeadlessScript：清单/反编译/   │
│                           references/CFG                      │
│ Setup：macOS 校验 DMG→~/Applications；Linux 校验后调原生包管理器│
└──────────────┬────────────────────────────────────────────────┘
               ▼
┌── 应用层（CLI 与 MCP 的公共大脑）──────────────────────────────┐
│ SessionProviderRouter + BinarySession ← ★唯一不可变深度绑定    │
│ AnalysisProviderRegistry ← 排序候选、确定性选择、【无回退】    │
│ InvestigationRecords + EvidenceLedger + Unknown 归属          │
│ BinarySessionRecords + AnalysisSnapshotCache（提交后通知）     │
└──────────────┬────────────────────────────────────────────────┘
               ▼
┌── Provider 层（24 个，按操作族是否重叠分两类）────────────────┐
│ 深度（重叠，必须选择）：hopper · ghidra · ida                 │
│ 辅助（不相交，直接路由）：rea-cdp-browser · rea-playwright-* │
│  rea-v8-inspector · rea-javascript-application · rea-dotnet-* │
│  · rea-apple-application · native-macos · rea-artifact-graph  │
│  · jadx · binwalk · unblob · wakaru · har-schema · mitmproxy  │
└──────────────┬────────────────────────────────────────────────┘
               ▼
┌── 进程基础层 ─────────────────────────────────────────────────┐
│ src/process/  自有进程组、私有根目录、截止时间、有界读取、清理 │
│ src/windows/  Node-API：NTFS 准入、受保护 DACL、原子 Job      │
└──────────────┬────────────────────────────────────────────────┘
               ▼
┌── 契约层 ─────────────────────────────────────────────────────┐
│ provider-neutral 输入/输出 schema；Evidence 双通道返回        │
│ { result, evidence_id, evidence }                            │
└───────────────────────────────────────────────────────────────┘

最值得记住的一条线：AnalysisProviderRegistry 在目标解析之后、深度客户端创建之前完成选择，产出不可变的 binding，此后整个会话都绑在它上面。

4.2 分层模块拆解

层	职责与关键接口
入口层	main.ts 起 MCP stdio server，cli.ts 起 one-shot CLI，rea.mjs 路由。两者不是两套实现，而是同一 application 工作流的两个适配器——这是 CLI/MCP 对等的结构性保证
适配层	src/server/ 做 MCP 翻译与 tools/list 目录；两个 Bridge 把引擎原生 API 翻成中立操作；Setup 适配器负责宿主安装与校验（不注入 sudo、不动 Homebrew）
应用层	AnalysisProviderRegistry（候选发现、目标支持判定、选项/profile 解析、选择）；BinarySession（唯一绑定 + 不相交辅助路由）；investigation/（EvidenceLedger、Unknown 归属）；快照缓存
Provider 层	深度三引擎各有适配器（Hopper 走 Unix socket + BridgeLauncher；Ghidra 走 Unix/Windows 传输 + 有界生命周期；IDA 适配上游 MCP 契约，可 GUI 绑定或起自有 headless 数据库）；辅助 Provider 各自独立授权，不参与深度选择
进程基础层	只清理能证明归自己所有的进程组、私有根、有界读取与诊断、超时与取消
契约层	严格 object + 显式 required + enum；「缺失的证据是 unknown，不是空、也不是 false」；结果内联返回，不让智能体为理解结果再去解引用不透明链接

4.3 核心机制与算法原理

① 工具按「分析师的问法」设计，而非按引擎 API。 docs/tool-design.md 给出六种任务形状：inspect（单目标事实 → 字段/源位置/facet 可用性）、search/list（候选 → 稳定排序 + 上下文）、trace（关系 → 类型化边 + 支撑证据 + 未解析路径）、compare（两个标识工件 → 配对身份 + 可比覆盖度 + 带证据 delta）、workflow（需内部组合的结论 → 内联结果 + 贡献证据）、observe/capture（运行时问题 → 权限 + 生命周期 + 清理状态）。两条否定式纪律同样关键：「不要为迁就假想的智能体预算而施加面向调用方的限制」，以及避免不透明 mode flag 与把发现/执行/变更焊死的 mega-tool。

② Provider 二分类：不相交用组合，重叠用选择。 这是全项目最关键的架构决策（ADR-0001，2026-07-15 接受）。深度 Provider 实现重叠的静态分析操作族（Hopper / Ghidra / IDA）；辅助 Provider 操作族不相交（产物清点、macOS 原生检查、CDP、V8 Inspector、APK、固件）。不相交部分继续用 CompositeProvider 组合（它必须拒绝重复操作声明），重叠部分交给 AnalysisProviderRegistry：

                         target-free discovery
                                  |
                     AnalysisProviderRegistry
                       /                    \
                   Hopper                 Ghidra
                       \                    /
                        one selected binding        ← 只选一个
                                  |
        +-------------------------+-------------------------+
        |                         |                         |
  selected deep family     artifact family          native family
        +-------------------------+-------------------------+
                                  |
                            BinarySession

③ 确定性选择：auto 绝不猜。 选择发生在目标中立解析之后、深度客户端创建之前，优先级为 请求/CLI 参数 > 环境变量 REA_ANALYSIS_PROVIDER > 默认 auto。规则：显式 provider 必须存在、可用、支持目标、接受选项、能解析出具体版本与 profile，任一步失败即返回类型化错误、绝不试下一个；恰好一个可用候选 → auto-single-candidate；多于一个 → ambiguous 错误，列出候选要求指定——不偏爱 Hopper、不按注册顺序、不选启动最快、不选第一个健康响应；无深度候选时仍可建立未绑定目标，让辅助操作继续可用。

④ 绑定一次，中途永不回退。 binding 含四要素：规范目标身份、被选 provider 身份与具体版本、选择来源、分析 profile 承诺。同目标无选择器重开 → 保持原绑定；换 provider 或 profile → 视为真实切换（排空在途调用、关自有资源、解析新绑定、串行事务启动），失败则尽力恢复原绑定并返回原错误；Provider 退出、超时、取消、能力失败、适配器错误一律不回退。被拒绝的替代方案同样有据：让组合器取第一个重复路由（数组顺序不是产品策略）、让引擎竞速取最快响应（机器负载会决定结果与出处）。

⑤ 分析 profile：把「同样的字节」升级成「同样的语义」。 旧快照只记 loader 参数，两份分析可能因语言、编译器、loader、分析器或引擎版本不同而结论不一致却看起来「目标兼容」。新设计要求适配器在创建客户端前归一化每个影响结果的语义输入（Hopper 的 loader 与架构标志；Ghidra 的 language ID、compiler spec、import mode、analyzer set 与选项），显式化默认值、排序无序集合、解析掉隐式宿主依赖，返回中立信封：

{ "provider": { "id": "ghidra", "version": "<concrete version>" },
  "parameters": {},
  "digest": "<sha256 of RFC 8785 canonical JSON excluding digest>" }

三条硬约束：parameters 只含分析语义，不含凭据/授权/临时路径/安装路径/PID/时间戳；深度绑定必须有具体版本，解析不出报 version_unresolved，不会持久化只承诺 null 或「装了什么就是什么」的缓存；快照命中要求目标摘要 + 格式/种类 + 架构 + provider ID + 版本 + profile 摘要 + 操作 + 规范参数全部精确匹配。旧 Snapshot v1 无法解析为当前格式（loader_args 无法证明引擎版本与默认值），必须重采。

⑥ 工具契约的三条不可协商项。 默认返回完整结果，把分页、截断、部分失败、取消、不可用显式化；区分观察、推导与推断，每条重要关系引用证据并保留未解析的边；诚实声明副作用并强制遵守请求命名的目标与生命周期。文档还澄清：readOnlyHint 把会话状态算进去——一次记录了附加 Evidence 的分析调用会被标为非只读，即使目标本身没变。

⑦ Evidence：可复用、可比较的一等记录。 工具返回 { result, evidence_id, evidence }（text 与 structured 双通道），evidence.normalized_result 恒等于 result；同一记录留在会话 bundle 里，且可直接喂给兼容比较工具（analyze_function 的 Evidence 传给 compare_functions）。MCP 还支持「已保留引用」避免重算：

{ "name": "trace_application_feature",
  "arguments": {
    "application": { "kind": "retained-evidence", "evidence_id": "ev_<64 位小写十六进制>" },
    "seed": { "kind": "module", "value": "search.js", "match": "exact" } } }

引用属于当前连接的 Evidence 账本：打开另一目标会保留记录，但 close_binary 会清空它们（即使当时没有活动二进制）；新连接有自己的账本。引用缺失时报出确切 ID 与 details.reason: "missing"，且服务器无法推断它是从未记录、被清空还是被另一连接持有。

⑧ 完整性默认 fail closed。 产物完整性校验默认失败即停；只有确需「验证过的兄弟节点继续推进」时才可显式选 integrity_policy=record-and-continue，此时矛盾的字节被隔离、不参与嵌套展开，并连同声明/观测哈希、信任等级、出处与解包状态一起记录；比较会归类为 contradiction，重建不能当作「未变更」。

4.4 性能与可靠性设计取舍

取舍	为什么	代价
重叠即 ambiguous	装第二个引擎不能静默改变结果	多引擎宿主必须显式选择，有摩擦
无静默回退	回退可能把不兼容引擎状态与证据混在同一下	引擎挂了必须手动切换或重开
profile 精确匹配快照	「同样的字节」不等于「同样的语义」	换 provider/版本/profile 后必须重采
Ghidra 首次查询才启动引擎	open_binary 只做绑定校验，不背导入时延	客户端 deadline 可能先超时，需专门恢复流程
只清理「能证明自有的」进程	最大风险不是装不上而是杀掉别人的进程	清理不彻底时只能报 cleanup_incomplete

两个官方文档给出的时延数字（非本文实测）：Ghidra 启动截止时间 330,000 ms（覆盖导入、自动分析、bridge 连接与健康就绪）；受控 Linux x64/WSL2 夹具上首次 overview 约 64 秒（Ghidra 12.1.4、NTFS 挂载安装、JDK 21、2 CPU、512 MiB 堆）。同时提醒：钉住的 SDK 2.3.1 客户端默认 60,000 ms，可能早于服务截止时间就取消，故示例把 callTool 超时设 240,000 ms——文档写明「240 秒是实测示例，不是通用超时」。

4.5 与其他路线的差异

与单引擎 MCP 插件（GhidraMCP 类）：工具名与语义绑定那一款引擎；REA 坚持 provider-neutral，明确「不会新增 ghidra_decompile 或 hopper_decompile 工具」。与直接脚本化引擎：差别在调查状态存在哪里——脚本化时输出散落各处、发现之间的关联靠你的笔记，REA 用统一接口 + 版本化领域图 + Evidence 记录让智能体跨组件追踪；代价是引擎异常时你要调 REA 的 bridge，而不是自己的脚本。与云端分析服务：REA 本地分析、不上传应用，代价是上限 = 你的机器 + 你已购的引擎授权。

五、【重点】应用场景

场景一：看懂某个 App 的功能，在自己项目里重建（官方主场景）

痛点：你在别人的应用里看到一个功能想复刻，但没有源码，传统做法是人肉反汇编加猜测。 做法：把 REA 注册给智能体，让它带着问题去查，并要求它给出证据与限制。

npx rea-agents setup   # 引导式：检测智能体、注册 MCP、可选装 Hopper
# 重启后提问：Understand how search works in the Notes app, show me the
# evidence, and build a similar feature for my project.

收益与量化：官方 Showcase 的 DX-Ball 案例给出可核查数字（检查点 2026-10-07）：已恢复维护 55 个 C 函数、完成 45,380 次与原码比对、其中 33 个函数编译后字节匹配。以「声音声像计算」为例，智能体先用 function 0x406400 拿到伪代码，发现它声明 FUN_00406400(void) 却调用 __ftol()——这个矛盾成为继续深挖的具体理由，随后三步拿到答案：

scripts/rea function original/DXBALL.EXE 0x00406400 \
  --snapshot .analysis/rea/dxball.snapshot.json --json

① 读指令发现伪代码缺失的输入（[EBP+8] 暴露被隐藏的整数参数）；② 跟随调用者 0x411f40，看到 tile_x 先乘 30 再加 20，得出屏幕坐标语义 20 + 30 × tile_x；③ 读内存常量 0x420068/0x420070/0x4210a0，得到 1.5625、500.0、初始 pan 缩放 1.0。最终 C 函数在 scale=1 时左边界 −500、中心 0、右边界 500，并通过两项独立检查：3,205 个行为用例（0–640 每个整数位置 × 五个 scale：0、0.5、1、20、−1）与63 个编译字节完全匹配（VC4.0 工具链重放，应用已审阅重定位）。

边界：官方自己划线——不声称恢复原始源码，也不声称自动克隆应用。若目标是恶意样本行为分析、漏洞利用开发或固件提取，它的工作流面向「产品功能模仿」而非对抗性分析，不建议当 malware triage 主力。

场景二：同一份证据跨工具传递而不重算

痛点：多步调查中第二步要复用第一步输出，传统做法是复制到笔记，跨工具跨会话即丢失，且无法证明「你比较的确实是同一个东西」。 做法：用 Evidence 的已保留引用把上游产物直接喂给下游（见 4.3 ⑦）；CLI 侧对应可移植文件：

rea evidence-import  /path/to/bundle.json
rea evidence-export  /path/to/bundle.json /path/to/canonical.json
rea compare          /path/to/left.json /path/to/right.json

收益与量化：零重算 + 可审计——引用形式与内联形式走同一套语义、身份、权威与出处校验，但不重跑生产者。工具面自身也有直接收益：analyze_function 的 Evidence 可直接传给 compare_functions，inspect_artifact 的传给 compare_artifacts。 边界：引用属于单个连接——close_binary 会清空账本（即使没有活动二进制），独立 CLI 调用无法解析另一个 MCP 连接的保留记录。要跨会话保留，必须在关闭前 evidence-export。

场景三：把「版本对比」做成可复现的配对实验

痛点：升级第三方依赖或客户端后行为变了，需说清哪些变了、哪些没变、哪些还不知道；人工对比两份反汇编不可复现、无法交差。 做法：导入历史源码树做参照，与当前工件做 source-to-bundle 比较，或用同一套证据做版本对比。

rea import-reference-source /absolute/path/to/source
rea compare-application-versions ...     # 版本对比
rea compare-source-to-bundle ...         # 源码 ↔ 打包产物

收益与量化：结果分类明确——配对身份、可比覆盖度、带证据的 delta，并把未配对记录、结构不匹配的解码签名、矛盾项单独归类。工程纪律也有硬口径（docs/testing.md）：check:pr 的 PR 验收目标是基准机上三次热构建的中位墙钟时间低于 3 分钟；CI 覆盖率门槛为总体语句 65% / 分支 60% / 函数 60% / 行 68%（src/domain/** 与 src/contracts/** 另有更高门槛）。 边界：历史源码导入要求 Linux 或 macOS 上的安全 no-follow 文件打开，原生 Windows 返回 unsupported_host（需在 WSL 或其他受支持宿主跑 Linux 版）。跨 provider 只能比较「各自契约明确规定的规范化语义」，精确伪代码或 provider 专有元数据一律不视为等价——缺 profile 或不兼容时结论是 unknown/incompatible，永远不会是「相等」。

场景四：把「智能体产出的结论」变成可验证闭环

痛点：当智能体说「这个功能是这样实现的」，团队无法验收——没有可执行检查，结论就只是自然语言。 做法：用重建义务账本把证据转成确定性声明清单，每条声明必须由唯一 owner + 类型 + 用例夹具 + 通过验证器共同闭合。

rea build-reconstruction-obligation-ledger \
  '{ "evidence_bundle": {...}, "reviewed_obligations": [...], "manifest": {...} }' --json

收益与量化：账本保守性写得很死——静态应用图的事实只产生候选义务，不证明运行时或进程行为；必需义务只有在「一个 manifest 绑定提供唯一 owner、所有必需类型、每个必需用例夹具、以及权威等级可比的通过验证器」时才闭合。文档给出一句可核查的纪律：「绿色单元测试不能闭合一个 packaged-process 义务；纯静态来源不能闭合运行时或进程声明。」 边界：把声明标成 blocked/out-of-scope 会记录处置，但不会静默计入已验证。若团队没有维护夹具与验证器的习惯，引入账本只会增加文书成本，不建议在该成熟度下上马。

场景五：给不可信分析动作做进程隔离与清理纪律

痛点：让智能体驱动反汇编器/浏览器/固件解包器，意味着启动一堆你并不完全掌控的进程（GUI 引擎、Playwright、JADX、Binwalk）。这类工具最可怕的失败模式不是装不上，而是杀了不属于自己的进程、改了用户的项目。 做法：把进程所有权做成基础层能力——src/process/ 统一管理自有进程组、私有根、截止时间与有界读取，只清理能证明自有的资源；清理失败报 cleanup_incomplete 并只列出仍然存在的自有资源种类。

rea doctor --provider ghidra --json        # 只读诊断：平台/架构/版本/JDK
rea setup --client codex --dry-run --json  # 只出计划，状态 planned，退出码 0

收益与量化：几处可核查的硬约束——Ghidra 每个已验证会话用临时项目 + 隔离的 home/cache/config/temp 路径，传 -readOnly、-deleteProject，从不开用户已有项目；Hopper 在 Linux 上跑在私有 Xvfb 显示并自动选择 demo 模式，不使用用户桌面显示；若宿主把 /tmp/.X11-unix 挂成不可变 mount，REA 先验证冲突，再用非特权用户 + mount namespace 仅对该目录覆盖私有 tmpfs——宿主 mount 与 /tmp 其余部分不受影响，且该回退路径永不调用 sudo。 边界：macOS 需 Hopper 首次运行 UI 在同一用户会话完成（选 demo 或激活授权），临时 macOS runner 需预置用户会话或一次交互式引导。此外辅助 Provider 采用的 cua-som（AGPL-3.0-or-later）与可选 cua-perception 扩展（含 AGPL-3.0-only 的 OmniParser 模型产物）都不是 MIT，网络分发可能触发 AGPL 源码义务——打包进对外服务前必须先做许可证评估。

六、快速上手

环境：Node.js 22.x（≥22.19）、24.x（≥24.11）或 26+；不支持 Node 23/25 与预发布版，安装器不会升级 Node.js、npm 或 Homebrew。

npx rea-agents@latest setup        # 引导式：展示精确路径与外部影响，需批准才写
rea setup --dry-run                # 只看计划，退出码 0
rea setup --client codex --client cursor --skill=false --dry-run
npm install --global rea-agents && rea --help
npx -y rea-agents@latest analyze-javascript-application /path/to/app --json  # 无引擎最小示例
export GHIDRA_INSTALL_DIR=/path/to/ghidra_12.1.4_PUBLIC   # 配 Ghidra（REA 不下载/安装 Ghidra、Java）
export JAVA_HOME=/path/to/jdk-21
rea doctor --json && rea providers --json

MCP 手动注册（须钉住具体版本）：

{ "mcpServers": { "rea": { "command": "npx", "args": ["-y", "rea-agents@5.0.0", "mcp"] } } }

配置后重启智能体。常用命令：analyze、function、decompile、xrefs、trace；默认输出 TOON，存盘用 --json。

七、横向对比

维度	REA	单引擎 MCP 插件	直接脚本化引擎	云端分析服务
定位	调查协调层（不是反编译器）	单引擎 MCP 暴露	引擎原生脚本接口	托管分析平台
工具面	134 MCP / 89 CLI	十几到上百（视项目）	引擎 API 全量	平台 API
引擎中立	是（不允许 ghidra_* 平行工具）	否，绑定该引擎	否	部分
多引擎共存	是，但重叠即 ambiguous、绝不静默回退	不适用	需自己编排	平台决定
证据模型	Evidence + 账本 + 快照分区 + 未知归属	多为纯文本	自己存文件	平台内
跨会话可复现	需 profile 精确匹配才命中快照	无	无	平台内
数据位置	本地，不上传应用	本地	本地	上传服务方
主要成本	需自备引擎（Hopper 商业 / Ghidra 自配 JDK）	只需该引擎	只需该引擎	按量付费
最大风险	版本节奏快；抽象层故障需调 bridge	能力受单引擎限制	调查状态不可复用	数据出境与合规

选型一句话：要让智能体跨多种目标做可追溯调查 → REA；只操作某一个引擎 → 单引擎插件更轻；需要对抗性分析/样本行为 → 另找专用工具链；数据不能出本地 → 排除云端。

八、局限、风险与社区观察

一、平台覆盖不均，且官方标注比宣传更保守。 深度原生的稳定部分是 macOS + Linux（Hopper 支持 macOS 12+、Ubuntu 24.04+、Fedora 41+、64 位 Arch/CachyOS；Ghidra 支持 Linux x64 与 macOS x64/arm64，需 Ghidra 12.1.x 与它声明的 64 位完整 JDK）。Windows x64 是实验性 P0，只放行固定本地 NTFS 卷上的原生 x86/x86-64 PE，且只允许 25 个只读操作（13 个清单/搜索 + 12 个函数分析），GUI 与变更操作不可用。文档反复强调**「验证成功的宿主不等于支持该宿主」——macOS ARM64 是本实现真正验证过的宿主，「接纳 macOS Intel 并不声称做过 Intel 验证运行」**。

二、快照与引用有明确失效语义。 Snapshot v1 无法解析为当前格式（loader_args 无法证明引擎版本与默认值），必须重采；Evidence 引用属于单个连接，close_binary 清空账本（即使当时没有活动二进制）；不同 provider 或 profile 摘要永不快照兼容。升级路径须规划「重新采集」成本。

三、版本节奏快是双刃剑。 公开 Release 显示 4.0.0/4.0.1 在 2026-10-05、4.1.0 在 2026-10-06、5.0.0 在 2026-10-07——三天三个版本。对一个会往 6 个以上客户端写 MCP 注册的工具，这就是实际升级成本。缓解已写进契约：注册追加式、先备份、写后读回，@latest 不会静默替换 npm 选定的版本，因此显式精确版本是官方给出的回滚路径。

四、许可证必须分层看。 本体是 MIT，但驱动它的是别人的引擎（Hopper 商业、Ghidra Apache-2.0、IDA 需授权）。更要紧的是仓库内混合许可：Cua Spaces 相关目录是 FSL-1.1-MIT（source-available，发布满两年转 MIT）；cua-som 是 AGPL-3.0-or-later（含 Ultralytics 依赖许可），可选 cua-perception 扩展捆绑 AGPL-3.0-only 的 OmniParser 模型产物，明确不是 MIT，网络分发可能触发 AGPL 源码义务，Cua 无法对该检测器重新授权。上线前必须逐目录核对 LICENSING.md。

五、维护与治理是加分项。 当日（2026-10-08）仍在提交；仓库提供 AGENTS.md、SECURITY.md 与15 个 GitHub Actions 工作流（含 real-hopper.yml、real-ghidra-windows.yml、real-browser.yml 等真实引擎车道）；docs/ 下有 3 份 ADR 与 30 篇专题文档。测试把「行为深度」分七档，明确禁止用 mock provider 的成功来声称引擎可用。

九、小结与行动建议

一句话概括：REA 把「逆向工程」从一个人的手工活，变成一组带证据链、可跨工具传递、可被智能体验证的机器契约——它不替你反编译，但保证每个结论都能说出出处、限制和未知。

1. 先零成本验收再投入。 无引擎也能跑 analyze-javascript-application <app> --json；确认结果对你有用，再考虑配 Hopper 或 Ghidra。
2. 动手前必跑 rea setup --dry-run。 它打印确切路径与外部影响、状态 planned、退出码 0，而最终批准提示默认是 No——首次运行天然安全。
3. 锁定精确版本，不裸跟 @latest。 三天三个版本、且每个版本都可能改写 6+ 客户端的 MCP 注册；升级前先跑 rea doctor。
4. 把 Evidence 导出纳入流程。 引用属于单连接、close_binary 会清空账本——要跨会话保留结论，必须在关闭前 evidence-export。
5. 多引擎宿主必须显式选 Provider。 同时装 Hopper 与 Ghidra 且不指定会得到 ambiguous，这是刻意设计：装第二个引擎绝不允许静默改变分析结果。
6. 许可证评估下钻到目录级。 本体 MIT 不代表仓库整体 MIT，对外提供托管服务前先核对 LICENSING.md 与各 model card。

资料来源（抓取日期 2026-10-08）：GitHub REST API（morluto/rea 元数据 ★16,948 / fork 1,771 / MIT / created 2026-04-14 / pushed 2026-10-08；Releases 15 条，最新 rea-agents-5.0.0；递归文件树约 1,974 个 blob）；仓库 README.md、docs/product-catalog.json（5.0.0、SDK 2.3.1、134/89/6/24/12）、docs/architecture.mermaid、docs/adr/0001-provider-selection-and-analysis-profiles.md、docs/tool-design.md、docs/mcp-contracts.md、docs/cli.md、docs/installation.md、docs/testing.md、docs/native-investigation.md、docs/reconstruction-obligation-ledgers.md；官网 Showcase morluto.github.io/rea/showcase/dx-ball/（55 / 45,380 / 33 / 3,205 / 63，检查点 2026-10-07）；GitHub Trending daily 与 weekly；第三方评测 Hysen Labs《REA review》；社区检索（LaurieWired/GhidraMCP、Reddit r/mcp、Hacker News id=46882389）。「同类工具约 15 个」与「main 134 vs 发布 133 工具」为待确认口径。