REA 源码与架构分析：Agent 如何连接反编译器、静态分析与运行观察

项目仓库：morluto/rea

AI 参与说明（Agent：Codex）：本文由 Codex 根据 REA 官方资料、Context7 检索材料与固定提交源码协助调研、撰写和校验，整理日期为 2026-10-10。源码基线为 33b9b31，该提交的 package 版本为 6.3.0；本文的架构评价属于对源码的工程分析。运行记录：模型 gpt-6.1-sol，reasoning effort ultra，执行入口 Codex Desktop，提供方 openai；运行记录中的 CLI 版本 0.162.0-alpha.17.2（不代表桌面 App 版本）。

中文润色（2026-10-10，Agent：Codex）：使用 humanizer-zh 编辑中文表达，保留本文事实、术语、代码、链接与证据边界；本次未更新技术结论。运行记录：模型 gpt-6.1-sol，reasoning effort ultra，执行入口 Codex Desktop，提供方 openai；运行记录中的 CLI 版本 0.162.0-alpha.17.2（不代表桌面 App 版本）。

REA（Reverse Engineer Anything）最值得研究的设计，是把多种逆向分析能力组织成一套本地工具系统，供外部 Agent 调用、组合和核对。原生机器码的反编译交给 Hopper、Ghidra、IDA；JavaScript/Electron 的静态解析、关系图与部分工作流由 REA 自己实现；运行观察则接到 CDP、Playwright、V8 Inspector 和受控进程等后端。

REA supplies analysis tools and Evidence; the external Agent owns the investigation loop. 在本次固定版本的入口、应用工作流、依赖与相关调用检索中，没有发现内置模型调用或自主 Agent Loop。MCP Prompt 返回文本模板，复合工具执行确定性代码。查哪个函数、如何解释结果、怎样重建功能，仍由外部 Agent 决定。MCP Prompt 实现，复合工具分发

先认识几个术语

分析基线与项目范围

本文锁定完整 commit 33b9b31a6fb50cc3e6f4591d0395dbba15b51f13，避免移动的 main 与文档检索缓存混用。package.json 声明包名 rea-agents，同时提供 rea 与 rea-agents 两个命令；Node.js 要求是 ^22.19.0 || ^24.11.0 || >=26.0.0。6.3.0 是该提交声明的版本，不代表 npm 当前 latest 的独立核验结果。package.json

项目的能力跨越多个后端，但适用条件不同：

后三类可对照 .NET 边界、JADX 配置与限制、Firmware Provider。下面重点拆解共享内核、原生后端和 JavaScript/Electron 主线。

总体架构：两个入口，共用应用内核

沿着依赖关系看，REA 分为入口、协议适配、应用工作流、领域合同和后端适配几层。CLI 与 MCP 共用应用服务和 Provider，但 CLI 不需要把每条命令转成 MCP 请求。官方架构图源码

flowchart TB
  Agent[外部 Agent<br/>持有 Agent Loop] --> MCP[MCP Adapter<br/>长期 stdio 进程]
  Terminal[终端用户] --> CLI[CLI Adapter<br/>单次命令]
  MCP --> App[Application Services<br/>共同工作流]
  CLI --> App
  App --> Session[BinarySession<br/>目标与 Provider 路由]
  App --> JS[JavaScript / Electron<br/>静态解析与图构建]
  App --> Runtime[Browser / Process<br/>运行观察]
  Session --> Deep[选定的深度 Provider<br/>Hopper / Ghidra / IDA]
  Session --> Auxiliary[辅助 Provider<br/>Artifact / Native 等]
  Deep --> Evidence[Evidence<br/>来源、结果与限制]
  Auxiliary --> Evidence
  JS --> Evidence
  Runtime --> Evidence

图中 Evidence 是各流程共用的结果合同。各工具可以在自己的流程中记录和交付结果，图中的箭头不表示所有输出都会广播给所有后端。

src/composition/binary.ts 将 Hopper、Ghidra、IDA 放进同一个 AnalysisProviderRegistry，辅助能力通过相应 Provider 装配；MCP 的 main.ts 创建长期 BinarySession，CLI 的 DirectAnalysis 则为单次分析建立并清理 Session。共同装配点，MCP 生命周期，CLI 分析实现

这种分层让终端、MCP 和测试可以调用同一个分析算法。协议层负责参数、输出和连接生命周期，应用层不必依赖某个 Agent 产品。

MCP 合同：工具目录稳定，可用性单独查询

REA 有两种容易混淆的目录：ToolContract 定义面向调用者的工具名称、输入输出 Schema、副作用和示例；AnalysisProviderRegistry 负责选择能分析某个目标的深度后端。前者回答“有哪些工具”，后者回答“这次由谁执行”。工具合同集合

tools/list 包含暂时不可用的工具。打开目标、关闭目标或后端健康状态改变，并不改变整个工具目录。Agent 应读取 binary_session 的 result.tool_availability，查看当前目标、宿主、Provider 和客户端协议能力是否满足条件，以及原因与修复建议。MCP runtime contracts

Schema 也分两层：Canonical Zod Schema 负责严格的运行时验证；向客户端公布的 JSON Schema 则为兼容模型接口调整展示形式，例如把根对象 union 展示成一个对象。这种投影可能无法表达全部互斥关系，非法组合最终仍由 Canonical Schema 拒绝。源码只替换展示部分，保留原始验证器。Schema 投影，保留 Canonical 验证器

因此，工具已出现在目录中、参数符合向客户端公布的 Schema、目标已打开，是三个不同的条件。任何一项都不能保证分析成功。

原生分析：选择引擎、固定来源、接入 Bridge

Provider 选择是确定性的

显式请求的 Provider 优先于环境默认值。auto 会评估目标支持与配置：恰好一个可用候选才绑定；多个候选返回 ambiguous；没有深度候选时可保留未绑定状态，让适用的辅助能力继续工作。候选按 ID 排序，注册先后不是隐含优先级。选择算法

A successful deep-analysis selection binds the target to one Provider and one committed Analysis Profile. SessionProviderRouter 把这个绑定与互不重叠的辅助操作家族组合起来。运行失败时，REA 不会悄悄切换到另一家反编译器，以免同一调查中的结果来源随之改变。目标路由

REA 分别建模“发现配置”“支持这个目标”和“引擎实际就绪”。生产路由的 CompositeProvider 在打开目标时直接从本地返回 health，直到首次实际操作才创建子客户端；Ghidra 也要等到首次后端查询才启动并导入目标。open_binary 成功不能单独证明 JVM 已完成分析。CompositeProvider，Ghidra 首次查询

三家引擎的集成方式不同

依据分别见 Hopper Bridge、Ghidra Bridge、IDA 操作映射。输出是引擎生成的伪代码，不是原始源码；符号、类型、间接调用和运行路径仍可能不完整。

以 Ghidra 为例，REA 不只是调用一次命令：它准备私有目标副本、临时项目与运行目录，生成 token 和 run ID，启动自己拥有的进程，再核对握手中的目标 hash、Analysis Profile、语言配置、Provider 版本和能力。如果尚未确认进程已停止，就保留运行目录，留待重试清理，以免仍在运行的 JVM 继续写入已删除的位置。Ghidra 启动，握手校验

这些机制约束了通信、来源和资源归属。不过，私有目录与 token 不等于容器隔离，也不能让引擎解析器自动成为可处理任意目标的安全沙箱。

取消请求不等于停止底层引擎

三家适配器都会串行执行同一目标内的请求，避免文档、数据库和单个 Program 的状态相互干扰，但取消方式不同：

• Hopper：已经发送的请求被取消时，可以结束调用者的等待，仍保留在途请求占用，直到真实响应到达；不会假装队列已经空闲。
• Ghidra：取消正在执行的请求会终止临时 Session 并清理受控进程，后续重新导入需要付出启动成本，Session 注释也会丢失。
• IDA：取消后仍需等待上游在途请求收束，再清理拥有的资源；不能据此声称上游反编译立刻停止。

对应实现见 HopperRequestQueue、GhidraRequestQueue、IdaSessionClient。MCP 能接受多个请求，不表示一个原生引擎能并行分析多个请求。

JavaScript/Electron：从文件到两张关系图

JavaScript/Electron 这条路线最能体现 REA 自己实现的分析逻辑。analyze_javascript_application 接受目录或 ASAR 作为专用输入：先建立 Canonical Artifact Inventory，再读取已编目的文件，核对字节与 SHA-256 并解析文本，最后构建图并生成 Evidence。静态路径可以将 .node 文件识别为原生边界，但不会加载执行它。重建入口，字节复核

flowchart TB
  Input[目录 / ASAR] --> Inventory[Artifact Inventory<br/>身份与文件清单]
  Inventory --> Bytes[读取文件<br/>复核字节与 SHA-256]
  Bytes --> Parse[AST / package.json / HTML / Source Map]
  Parse --> Structure[模块、入口与边界 findings]
  Parse --> Semantics[词法 binding 与静态语义 IR]
  Structure --> Application[JavaScript Application Graph]
  Semantics --> Semantic[JavaScript Semantic Relation Graph]
  Application --> Validate[结果校验、封存与 Evidence]
  Semantic --> Validate

两张图回答不同问题：

AST 由 Babel Parser 解析生成，静态语义分析在此基础上建立词法 Scope、Binding、模块关系，以及有限的值、参数与返回关系。它能做的比字符串搜索更多，但不执行 JavaScript，也不是完整的解释器或完整的控制流敏感分析。Parser，静态语义算法

Bundle 恢复靠识别结构

REA 对特定 Webpack/Rspack Chunk 结构读取字面量 Module Table 和 Factory；当前源码也识别 esbuild 的 __commonJS / __esm 字面量 Wrapper。它保留源码切片摘要与结构指纹，不通过执行 Bootstrap 来枚举模块。Chunk 识别，esbuild Wrapper

这些识别仍依赖特定格式，动态计算的模块表、自定义加载器和混淆可能无法恢复。某些 Runtime 名称、Framework Marker 或路由字段只能提供候选线索，不能仅凭一个 path 字段就断言应用使用了某个路由框架。

Semantic Relation Graph 在本版本还有明确资源上限：全树最多保留 100,000 个节点，每文件最多 20,000 个节点，并在 Coverage 中记录截断与遗漏信息。未截断的语义 Coverage 仍可为 unknown；解析成功不等于完整恢复行为。资源上限及 Coverage，语义限制

Electron IPC 配对是一个清楚的算法例子

REA 收集 BrowserWindow、Preload、contextBridge 暴露成员、IPC 注册和发送位置，再按以下条件配对 Renderer Transmission 与 Main Handler：

1. Channel 必须是精确相同的字面量。
2. IPC Mode 必须兼容，例如 invoke 与 handle。
3. 只有一个候选 Handler 才是 paired；多个为 ambiguous，没有为 unpaired。

对于动态 Channel，REA 不猜测配对关系；只有唯一配对才会生成对应的静态推断边。配对算法，图边与限制

A unique static IPC pairing does not prove runtime registration or reachability. 两段代码使用相同 Channel，并不证明用户点击后一定走到该 Handler。类似地，event.sender 检查只能作为权限验证的候选线索；发现 JavaScript 请求 .node 成员，也不能证明该原生导出存在。Sender Validation Candidate，原生成员边界

Browser：运行观察需要区分模式

普通采集只有明确要求才读取 Script Source；分析 Source Map 时也可能发出额外 HTTP 请求。Script Source 开关，Source Map 请求

V8 Coverage 明确报告 resets_execution_counters 和 disables_optimized_execution，缺失 Coverage 不能当成零执行。不能把所有 Browser 工具归为“无影响的被动读取”。普通采集，Coverage 副作用，Scenario 动作

REA 还支持静态图与运行时图之间的 Reconciliation。匹配时优先使用捕获源代码的 SHA-256，并结合授权的位置映射；有多个候选时保留歧义，内容摘要冲突时也不会仅凭路径一致就判定匹配。没有摘要时，若满足相应条件，可以采用唯一授权位置，但这种匹配的依据较弱。匹配实现

Bundle 被加载时，内部 Module 可以只是 resident-in-loaded-asset，不能直接写成 Factory 已执行。只有在限定捕获范围与完整性条件满足时，才报告 not-observed-in-capture；这仍不等于应用永远不会使用它。Load State

Evidence：统一结果，但不替代事实判断

Evidence 是 REA 组织多个后端分析结果的关键。主要字段如下：Schema

计算 Evidence 的摘要时，会纳入结果、参数、来源、配置、限制和关联记录。导入时会重新检查摘要，可以拒绝语义字段已改变却仍使用旧 ID 的记录。目标显示名称与 local_path 不属于目标的语义身份，但其他结果字段仍可能含有路径，因此不能据此推断任意搬移都会保留相同 ID。摘要与导入检查

An Evidence hash checks content consistency, not the truth of an analysis claim. 这里没有第三方签名或独立可信时间戳。能构造记录的人也能计算新的摘要，因此 Schema 与 Hash 正确，只说明结构和引用一致，不能单独证明引擎真的执行过、推断正确或输入者可信。这是从摘要实现得出的工程判断。Canonical Digest

项目另有 Unknown 记录，用于维护尚未解决的问题、修订关系，以及支持性与反驳性 Evidence。这样，“未观察到”“能力不足”“已有矛盾”都可以保留为可追踪的状态，不必合并成一个空数组或含糊的成功结果。

完整分析与适合阅读的 View 分开

MCP 的成功回复同时提供文本与结构化内容，但仍受响应预算和 Node 单字符串上限约束。如果已完成的结果超过投递预算，REA 可以保留完整 Evidence，并返回 Transport Constraint 与恢复引用。调用者据此读取合适的 View、导出 Bundle，或改用完整 CLI JSON；REA 不会截断结果后再声称它完整。结果投递

这里的“不截断”只针对已完成结果的 MCP 投递。采集窗口、图资源预算和 Provider 能力仍可能使分析本身不完整，必须继续读取 Coverage 与 Limitations。

Session、Snapshot 与 Ledger 是三种状态

Snapshot Key 对规范化的 {target, binding, operation, parameters} 计算摘要。结果必须满足能力与副作用条件才能缓存；依赖 GUI 当前位置、修改 Artifact、明确标记 live 等操作不能简单重放。换目标或 Analysis Profile 也不能冒用旧条目。缓存准入，Query Identity

本版本的 10,000 条上限属于 Snapshot Cache 的结果绑定，不是全部 Evidence 的存储上限。IDA 的活跃数据库采用 live 语义，因为外部 GUI 可能改变数据库，前后身份检查也不构成数据库锁。IDA Profile

内存 Snapshot 重放会追加本次没有重跑 Provider 的 Limitation；CLI 的持久 Snapshot 快速路径可以直接返回原有 Evidence。因此，本文建议在使用结果时，同时记录本次是重放还是新查询；Evidence 仍然有效，并不意味着它是一次新观察。长期 MCP 连接可以引用同一 Ledger 的 Evidence ID；单次 CLI 进程不能拿另一个连接的 ID 直接查结果，需要完整 Inline Evidence 或导出的文件。REA 也不会因此自动获得跨重启的 Agent 任务恢复能力。内存重放，CLI 快速路径

Skill、Prompt 和算法工具各做什么

REA 的 Skill 是给外部 Agent 的调查方法：选择目标、先读摘要、关注限制、避免重复调用、维护 Unknown、引用 Evidence，并分解复杂问题。MCP Prompt 提供调查文本模板。Enhanced Tool 则将多个操作写成可执行工作流。三者都不在 REA 服务端发起模型循环。

例如，原生 trace_feature 先通过 search_strings、search_procedures 执行 Literal Search，再查询 Xrefs，定位包含该地址的 Procedure。它没有使用 Embedding 或模型来自动理解一句自然语言对应哪些函数。选择合理的 Seed、追踪后续调用链和解释结果，仍需由外部调查过程完成。trace_feature 的实现

项目自身的 Skill 也明确：已有完整源码仓库的普通架构分析应使用常规仓库工具；REA 更适合结论依赖已发布 Binary、Package、反编译或源码无法证明的运行行为时使用。本次研究项目本身，因此直接读源码，不需要先配置反编译器。项目 Skill 的适用范围

可复现实验：验证 IPC 配对，而不运行 Electron

下面的输入只是静态分析 Fixture，无需安装或启动 Electron。它故意包含顶层 throw；静态读取应成功，执行目标则会失败。运行环境要求与上文相同。

先锁定源码并编译。本例禁用依赖安装脚本，只用于静态路径；不调用 setup，不修改 Agent 配置。

git clone https://github.com/morluto/rea.git rea-source
cd rea-source
git checkout 33b9b31a6fb50cc3e6f4591d0395dbba15b51f13
npm ci --ignore-scripts --no-audit --no-fund
npm run compile

在这个源码目录中创建临时输入，并取得完整 JSON：

rea_sample=$(mktemp -d)
cat > "$rea_sample/package.json" <<'JSON'
{"name":"rea-static-demo","version":"1.0.0","main":"main.js"}
JSON
cat > "$rea_sample/main.js" <<'JS'
const { BrowserWindow, ipcMain } = require("electron");
new BrowserWindow({
  webPreferences: { preload: require.resolve("./preload.js") }
});
ipcMain.handle("notes:get", () => ["demo"]);
throw new Error("Static fixture must never execute");
JS
cat > "$rea_sample/preload.js" <<'JS'
const { contextBridge, ipcRenderer } = require("electron");
contextBridge.exposeInMainWorld("notes", {
  get: () => ipcRenderer.invoke("notes:get")
});
JS
node scripts/rea.mjs analyze-javascript-application "$rea_sample" --json > evidence.json
node --input-type=module -e '
import { readFileSync } from "node:fs";
const e = JSON.parse(readFileSync("evidence.json", "utf8"));
console.log(JSON.stringify({
  operation: e.operation,
  confidence: e.confidence,
  ipc: e.normalized_result.summary.ipc
}, null, 2));
'

进度信息写到 stderr，重定向的文件保存完整 Evidence。验收重点是唯一配对，而不是节点数量。接着做两个输入变更：

• 在 Main 文件再加一个 ipcMain.handle("notes:get", () => ["second"])，静态候选变成两个。这是用于观察歧义的 Fixture，不是正确的 Electron 运行程序。
• 恢复原 Main，将 Preload 成员改成 get: (channel) => ipcRenderer.invoke(channel)，Channel 成为无法确定的动态输入。

使用 Node.js 26.0.0 和固定提交编译出的 CLI 运行上述静态路径，得到以下三组结果：

三组 Evidence 的 confidence 都为 derived。同输入重复分析得到相同 Evidence ID；改变输入后 ID 改变。另在 Fixture 中加入写文件哨兵，分析后文件没有出现；修改 Evidence 的 confidence 却保留原 ID，parseEvidence 拒绝导入。

本次还运行了项目已有的 evidence.test.ts、AnalysisProviderRegistry.test.ts 和 AnalysisSnapshotCache.test.ts，共 40 项通过，覆盖记录一致性、Provider 选择与快照规则。实验没有启动真实 Hopper、Ghidra、IDA 或 Electron；它核验的是该版本对自造静态输入和合同边界的行为。

架构评价与适用边界

从源码看，最值得复用的是四个设计：CLI 与 MCP 共用业务工作流；固定目标和 Provider 配置，并将它们纳入结果来源；将完整结果与供 Agent 阅读的 View 分开；将 Unknown、Coverage 和副作用写入合同。这些机制让调查过程能够积累可追踪的结果，也减少了静默切换后端或把资料缺口写成结论的机会。

代价是需要处理更多边界条件。同一个操作可能涉及 Schema 投影、可用性、目标身份、Profile、缓存策略、Evidence 校验、传输预算和资源清理。只看工具名字或 README，很容易高估实际能力；阅读源码时，应沿一条完整的数据流，追到后端实现和结果合同。

REA 适合分析已发布的原生或 Electron 应用，追踪 Package 的模块与接口，比较版本，以及将运行观察与静态制品对齐。这些场景都符合项目的主要用途。完整源码已有答案时，先读源码通常更直接。需要证明重建代码与原行为一致时，仍需针对目标设计输入、输出和失败路径的实际验证；伪代码、静态边或匹配指纹都不能单独替代它。

本地分析只说明 REA 的工具执行位置。外部 Agent 会接收结果，并按自己的模型服务链路处理；Evidence 还可能包含本地路径与目标细节，公开引用时应选取必要字段并脱敏。本文实验输出只展示自造 Fixture 的聚合信息。项目的数据流说明

建议源码阅读顺序与关联阅读

先看 scripts/rea.mjs 和 src/composition/binary.ts，理清入口和依赖关系；再看 src/contracts/toolContracts.ts、src/application/binary/ 和 src/domain/evidence.ts，理解调用与结果合同。随后选择一个后端继续读：原生分析追到 Bridge 和 Request Queue；JavaScript 则从 JavaScriptApplicationService 追到 Artifact Reconstruction、Electron Pairing 和 Graph Builder。最后用已有测试核对失败、歧义和取消路径。

• Agents Overview：本栏目导航。
• Pi Agent 框架架构：包边界、Agent Loop 与接入选择：对照理解真正管理模型循环的 Runtime 与 REA 工具系统的分工。
• Context7 源码分析：技术架构、MCP 运行原理与检索链路：另一类 MCP 接入层及其后端边界。