由 re-a-research.md 生成

REA 技术调研报告（v1.0）：面向编码助手的逆向工程工具链 —— 从双入口适配到依据留痕与能力边界

字段内容
文档类型技术调研报告
版本v1.0
状态公开资料整理；源码逐行核对锁定 commit c22111eca2c4bc84a084f12711f405b3e7422a40（2026-10-12 抓取）；未安装与运行 REA，未做目标侧实测
密级公开资料
作者Qoder Research
生成日期2026-10-12
研究截点2026-10-12
目标读者评估在编码助手工作流中引入逆向工程能力的工程师、安全评估与取证团队、工具链选型与平台适配人员
调研问题① CLI 与 MCP 两条适配路径如何共享同一套分析管线；② 结论可信度由哪些对象与格式支撑（目标摘要绑定、等级、未知项、错误面）；③ Android 反编译与设备两条链的依赖、平台验证面与失效边界；④ 面向 RISC-V 场景时哪些可核对、哪些可推断、哪些无公开验证；⑤ 与通用 MCP 工具相比的差异、成本与取舍
覆盖范围morluto/rea 固定 commit c22111eca2c4bc84a084f12711f405b3e7422a40（对应 npm rea-agents 6.4.0）：入口分发、组装层、工具接口面、依据模型、错误面约定、Android/JADX、adb、Go 静态读取、进程捕获、provider 选择、版本策略；含仓库 README 与官方文档
排除范围REA 的安装与端到端运行验证；商业 provider（Hopper/IDA）的采购与授权行为；真机 RISC-V 目标实测；性能与稳定性基准；目标应用本身的功能分析

摘要

背景与现状

REA 的定位可以从 README 的示例用法读出（原文英文）：让编码助手"理解 Notes 应用里的搜索如何工作、展示依据、并为你的项目构建一个类似功能" [S02]。它运行在用户本机，面向本地文件、目录、设备与进程场景；对上以 MCP 服务器形态接入编码助手，对下调用或内建各目标家族的分析能力。安装入口是 npx rea-agents setup：该命令向所选编码助手写入 MCP 注册与配套工作流说明，并备份既有配置；官方列出的支持对象包括 Claude Code、Codex、Cursor、Gemini CLI、Grok Build 等 [S02]。运行环境要求 Node.js 22.x（≥22.19）、24.x（≥24.11）或 26+，package.json 的 engines 约束为 ^22.19.0 || ^24.11.0 || >=26.0.0 [S01][S19]。

目标家族与其代价面在 README 的能力总览里有完整表格，可压缩成下表；这张表也是后续"能力边界"讨论的起点 [S02]。

目标家族返回内容外部依赖与平台
原生二进制伪代码、汇编、字符串、符号、调用与引用Hopper、Ghidra 或 IDA 之一；REA 不附带
Go 二进制编译器版本、模块、构建设置无，内建静态读取
Android APK清单声明、类、反编译方法与引用无头 JADX 与完整 JDK 17+，用户自备
Android 设备设备、包、进程、日志、截图、文件传输adb，用户自备
JavaScript/Electron模块、导入、路由、IPC 与原生扩展关系Node.js 与 npm
网站页面结构、脚本、网络观察与截图Chrome 家族浏览器
固件区域、解包结果与原生分析接力Binwalk 或 Unblob（Linux）
WASM、.NET、记录崩溃、进程行为校验与节、CIL 元数据、线程寄存器、终端输出与文件系统观察WABT 1.0.42、无（纯静态）、pwntools、原生 PTY（Linux/macOS）

版本节奏方面，仓库采用 release-please 的 node 策略并把版本策略设为 always-bump-minor，即每次发布至少抬升次版本号；快照时最新发布为 6.4.0（2026-10-11），README 提醒用户保持更新 [S02][S19]。这个节奏决定了任何行为结论都必须绑定 commit 与版本号阅读——本报告锁定 c22111ec 与 6.4.0。

图 1：REA 分层架构与双适配器共享路径
图 1：REA 分层架构与双适配器共享路径

图 1：REA 分层架构与双适配器共享路径 —— 从 scripts/rea.mjs 分发器到 src/composition/binary.ts 唯一接线点，再到工具接口面、应用层与目标链。来源：仓库 README 与 docs/architecture.mermaid，结合 src/composition/binary.ts 注释核对 [S02][S03][S04]；数据口径：分层与节点语义按 commit c22111ec 整理，工具数量取自 TOOL_EFFECTS 审计表 [S07]。

见图 1，读图先看右侧三条竖线的合流：无论用户敲命令行还是编码助手走 MCP，流量都会先汇入绿色虚线框中的组装层，再由它构造工具服务器；这意味着"两条产品形态"在实现上只有入口适配的差别，分析能力、依据语义与生命周期是同一份代码。图底部把目标链拆成"原生走注册表、其余走专链"两类，对应后文 3.1 与 3.3、3.4 的结构划分。

与通用 MCP 工具的差异可以先给一句总判断：常见 MCP 服务器把"某个数据源或某个操作"暴露给模型，返回通常是字符串或简单对象；REA 针对的是"本机目标的分析工作流"，并把"结论从哪来"做成了带目标摘要、定位与等级的结构化记录，再叠加覆盖全部工具的副作用审计（见 3.1）与统一错误面（见 3.2）[S07][S10][S13]。这层结构化纪律是它与"给模型挂一把反编译命令"的本质区别，也是本报告把篇幅大量放在依据模型上的原因。

技术详解：从双入口适配到依据留痕的核心机制

本章按四段展开：3.1 讲入口与组装（两条适配器如何收敛成一条管线），3.2 讲依据留痕与错误面（结论可信度从哪来），3.3 讲 Android 的双链依赖与验证状态，3.4 讲多目标家族边界与 RISC-V 的三档判定。所有行号与字符串均锁定 commit c22111ec，引用编号见参考来源台账 [S02]。

3.1 双入口适配：一个分发器、一个组装层、一套工具接口面

入口路径很短。scripts/rea.mjs 是外层分发器：命令行形态进入 src/cli.ts 的一次性实现，MCP 形态进入 src/main.ts，后者经 serveStdio()（来自 @modelcontextprotocol/server/stdio）把服务器挂到标准输入输出上 [S05][S06]。src/main.ts 的启动序列是 parseConfig() 解析环境变量、createBinarySession() 组装运行时、openInitialTarget() 处理启动目标、startMcpTransport() 启动传输 [S05]。

组装层的定位可以直接逐字引用源码注释，这段话是全仓库对"双入口不分叉"最直接的承诺：

/**
 * Compose the target-switching runtime shared directly by CLI and MCP adapters.
 * This is the sole production wiring point, so both adapters share identical
 * provider selection, profile, lifecycle, and Evidence semantics.
 */

createBinarySession() 在同一处注册三个原生分析 provider：Hopper、Ghidra、IDA [S04]。provider 选择由注册表统一裁决：环境变量 REA_ANALYSIS_PROVIDER 默认值为 "auto" [S09]；选择来源是三个取值 request、environment、auto-single-candidate（单候选自动选择会在结果里标注来源）；当来源为 auto 且候选多于一个时返回 ambiguous 错误而不是猜测，候选全不可用时给出拒绝原因——这套原因被枚举成 12 个拒绝码：not_configured、executable_missing、runtime_missing、unsupported_host、unsupported_version、target_kind_unsupported、target_format_unsupported、architecture_unsupported、target_role_unsupported、managed_target_unsupported、open_options_invalid、version_unresolved [S09]。注册表类注释把原则写得更直白：选择是确定性的、注册顺序不影响结果、失败不回退 [S03][S09]。

工具接口面在 src/contracts/toolContracts.ts 汇总为 25 个分组的单一有序清单，当前共 173 个公开工具（数量以 TOOL_EFFECTS 审计表的键为准，该表与注册清单的相等关系由 src/contracts/toolEffects.test.ts 以"audits every public tool exactly once"的断言锁定）[S07]。每个工具在审计表里声明副作用：是否改动目标、是否写文件、是否起进程、是否联网、是否执行外部代码、是否变更设备状态、是否幂等；运行时 toolContractMetadata() 对未审计的工具直接抛错：

/** Resolve the audited metadata for one public tool. */
export const toolContractMetadata = (name: string) => {
  const audited = TOOL_EFFECTS[name];
  if (audited === undefined)
    throw new Error(`Missing effect audit for ${name}`);

也就是说，"新增工具但忘了声明副作用"在测试阶段即不可通过，这对以"助手自动调用"为使用方式的工具链是必要约束 [S07]。MCP 接口面还有两个可核对的数字：scripts/generate-mcp-tool-catalog.mjs 在构建时生成工具目录并做 Ajv 校验（生成物不入源码库），REA_MCP_INPUT_SCHEMA_PROFILE=compact 把对外广告的输入模式压缩到 13,312 字节预算内；响应侧 REA_MCP_MAX_RESPONSE_BYTES 有 10 MiB 的下限（默认 stdio 接收缓冲）[S08][S18]。

选择来源（selectionSource）触发方式行为
request调用方在工具参数里点名 provider按名解析；不可用即按拒绝码报错
environmentREA_ANALYSIS_PROVIDER 指定单个 provider按配置解析；不满足即报错
auto-single-candidate来源为 auto 且恰有一个候选可用选中并标注来源；多候选或零候选均报错

把一次分析串起来，主链路可以复述为五步：

① 编码助手经 stdio 连接 MCP 服务器，或用户直接执行 CLI 命令； ② 用 open_binary、binary_session 等工具打开并绑定本地目标； ③ 注册表按请求参数或环境变量做确定性选择； ④ 应用层共享工作流执行分析（反编译、交叉引用、调用图、路径追踪等）； ⑤ 结果与依据记录经统一输出结构返回；CLI 一次性执行后丢弃会话，MCP 保留会话供后续调用 [S04][S05][S07]。

失效边界集中在"选不到"和"起不来"两处：选择失败有 12 个拒绝码与 ambiguous 错误显式表达，不存在静默换工具；原生 provider 启动有超时上限，Ghidra 默认 330 秒、Hopper 默认 120 秒，可用 REA_GHIDRA_STARTUP_TIMEOUT_MS、REA_HOPPER_STARTUP_TIMEOUT_MS 调整，大型目标需要先抬高这两个上限否则表现为启动超时 [S18][S20]。验证方式不需要安装：以本仓库快照即可核对工具清单与分组一致性，运行侧与 tools/list 的并集比对、binary_session 输出中的选择来源字段都能直接观察 [S05][S09]。

成本与权衡：确定性选择牺牲了"随便挑一个能用的"便利，换来可复现的行为与可解释的失败理由；双适配器共享同一组装层把行为分叉的成本压到最低，代价是任何适配器的个性化需求都必须经共享抽象表达，CLI 与 MCP 不能各自特化。对使用者而言，这意味着"MCP 里能做出来的事，CLI 脚本里同样能做"，反之亦然 [S04]。

3.2 依据留痕模型：目标绑定、分级、未知项与错误面

MCP 规定了工具调用怎么走线，没有规定"结论从哪来"。REA 在这一层自建了一套结构化留痕。第一步是打开即绑定：hashReadable() 对目标全量字节做流式 sha256、统计字节数并保留前 8,192 字节（ARTIFACT_CLASSIFICATION_PREFIX_BYTES = 8_192）作为格式分类材料 [S12]。与此同时，目标对象（subject）由五个字段固定：名称、digest.sha256、format、architecture 与本地路径；其中 format 是约 30 个取值的枚举（elf、macho、pe、apk、ipa、asar、dmg 等）[S10]。后续所有分析记录都挂在这个摘要上——同一份记录换一个文件版本便不再成立，这是整套可信度机制的地基。

每条记录另有两个维度：定位与等级。定位（location）是判别联合，五类取值：地址、地址区间、产物内路径、文件偏移、文件偏移区间 [S10]。等级（authority）是五档枚举：shipped-artifact、controlled-replay、historical-reference、external-service、analyst-inference [S10]。会话级台账 EvidenceLedger 负责收纳：记录不可变、写入幂等（同一标识重复写入不产生第二份）、内容冲突被拒绝（recordsAgree() 不成立即报错）[S11]。

等级取值字面含义（转述）与目标原物的距离
shipped-artifact直接来自下发物本身最近
controlled-replay受控重放条件下得到近
historical-reference历史版本或既有资料对照中
external-service由外部服务返回远
analyst-inference分析者推断最远

未决问题与结论同等重要，REA 把它们做成一等对象：编号前缀 unk_，稳定编号由"领域、问题、范围摘要"三要素的规范化 JSON 哈希生成（stableUnknownId()），跨调用、跨会话保持同一身份；未知项之间支持 depends-on、related-to、contradicts 三类关系；处置是一个判别联合——verified 要求至少挂一条依据记录，withdrawn 与 out-of-scope 不要求：

const resolutionSchema = z.discriminatedUnion("disposition", [
  z.object({
    disposition: z.literal("verified"),
    rationale: text,
    evidence_ids: z.array(evidenceIdSchema).min(1),
  }),
  z.object({
    disposition: z.enum(["withdrawn", "out-of-scope"]),
    rationale: text,
    evidence_ids: z.array(evidenceIdSchema),
  }),
]);

跨会话传递采用保留引用投影：{"kind":"retained-evidence","evidence_id":"ev_..."}，配套 export_evidence_bundle 与对应导入工具，让"结论 + 依据 + 未知项"作为一个包裹整体迁移 [S08][S11]。

错误面是同一纪律在失败路径上的延伸。docs/error-contract.schema.json（JSON Schema draft 2020-12）把错误类别收敛为 10 个枚举值，并强制必填字段 code、category、message、retryable 与 remediation.action [S13]。

错误类别字面含义（转述）相关边界举例（可核对）
invalid_input输入不合法路径或参数拒绝
unsupported_providerprovider 不可用或不支持12 个拒绝码覆盖的多数场景
unsupported_target目标类型不受支持格式与角色判定
integrity_mismatch完整性核对不匹配摘要/快照核对失败
truncated结果被预算截断1 MiB 上游字节预算等
cancelled调用被取消调用方中止
timeout超时启动 330 秒、模块探测 10 秒等
resource_constraint资源上限终端单元格、协议帧 8 MiB 等
unavailable依赖不可达连接中断等
execution_failure外部进程执行失败子进程退出码异常等

这 10 类与必填字段并非手写文档：scripts/generate-error-schema.mjs 在构建时从 dist/contracts/errorSchemas.js 生成 Schema，另有 114 行的用户可见差错文案清单 docs/user-visible-errors.csv 逐条登记触发位置、风险与替代文案，保证文档与实现对读 [S13]。

图 2：分析工作流与依据留痕模型
图 2：分析工作流与依据留痕模型

图 2：分析工作流与依据留痕模型 —— 从打开目标的全量摘要，到记录、会话级台账、未知项处置与跨会话引用投影。来源：src/domain/evidence.ts、src/application/investigation/EvidenceLedger.ts 与 src/artifacts/ArtifactHash.ts 逐行核对 [S10][S11][S12]；数据口径：字段与枚举取值以 commit c22111ec 源码为准，错误面按 docs/error-contract.schema.json 整理 [S13]。

见图 2，读图注意三个分叉口：摘要与绑定在最上游（任何记录都不脱离目标摘要存在）；台账之后分两路——未决问题进 unk_ 跟踪、完成状态整体打包外带；最底部的红色节点是失败面的统一出口，所有类别的异常都收敛到同一套必填字段，调用方不需要为每个工具写不同的错误解析。

把机制串成可复述的五步：

① 打开目标，全量 sha256 与 8 KiB 前缀一并落档； ② 每次工具调用产生的观察以 subject、等级、定位三要素写入台账； ③ 台账对重复与冲突做幂等与拒绝处理； ④ 未能回答的问题编号为 unk_ 并进入关系图； ⑤ 会话结束或以包裹导出时，全部记录可跨会话引用 [S10][S11][S12]。

失效边界与验证方式：摘要不匹配走 integrity_mismatch；截断与取消是两个独立类别，调用方能区分"结果少了"与"没跑完"；冲突记录被台账拒绝而不是覆盖 [S11][S13]。验证上，verify_unknown_resolution 工具可对处置做再次核对，台账的幂等与冲突行为可直接复现（同一记录重复写入）[S07][S11]。成本与权衡方面：全量哈希让打开大目标的 I/O 开销上升，换来确定性的版本绑定；留痕让响应结构更重，REA 用"保留引用 + 按需展开"的投影降低读取代价 [S08][S12]。

3.3 Android 双链：JADX 无头反编译桥与 adb 设备链

Android 方向由两条互不依赖的链路组成，先看 APK 反编译链。引擎版本被硬固定在一个发布物上，字段逐字如下：

/** Audited upstream release; source remains unmodified in the Git submodule. */
export const JADX_RELEASE = Object.freeze({
  version: "0.7.1",
  revision: "5844800a486d2248fa949b74c9896285f5b54de2",
  sha256: "6e5eacf500b64292bfb73c49797c1958f6ee44646e43e868039ae7feb573ff75",
  url: "https://github.com/1013503897/jadx-headless-mcp/releases/download/v0.7.1/jadx-headless-mcp-0.7.1-all.jar",
});

REA 不代管这个 JAR：配置缺位时的补救指引原文是 "REA does not download or install it."，用户需自行准备 JAR 并以绝对路径写入 REA_JADX_MCP_JAR，另需完整 JDK 17+（JAVA_HOME），主机与 Java 启动器都会在接线前接受 requireSupportedHost() 与 requireJavaHomeExecutable() 的检查 [S14]。资源读取边界在代码注释里给出审计依据：JAR 元数据最多读取 8 MiB（JAR_METADATA_READ_MAX_BYTES，注释记录 0.7.1 版 JAR 的 ZIP 中央目录实测为 2,294,350 字节，此处不读类体），Java 模块探测超时 10 秒（JAVA_MODULE_LISTING_TIMEOUT_MS）[S14]。运行期还有两组预算：解码清单与方法文本有 1 MiB 上游字节预算；协议帧超过 8 MiB、单操作 stdout+stderr 超过 32 MiB 会失败并给出诊断，而不是返回不完整清单——文档明确这些是内存安全边界而非未公开的结果上限 [S14]。

平台验证状态值得单独标出，因为它是"已验证"与"未验证"分界最清楚的一条链：当前元数据桥在 macOS arm64 与 OpenJDK 21 上以公开 Appium ApiDemos 样本做过真实验证；POSIX 适配器理论上支持 Linux，但文档原文声明新桥"尚未在 Linux/JDK 25 组合上接受真实验证"；Windows x64 走 Job Object 方案，真实验证使用 JDK 21 与固定的 JADX 0.7.1 JAR [S14]。能力边界同样被显式声明：JADX_LIMITATIONS 以四段文字说明不覆盖的范围，其中一段原文为 "APK signatures, split APKs, native libraries and Android runtime capture are not verified by this provider."（APK 签名、拆分 APK、native 库与 Android 运行时采集均不在该 provider 的承诺内）[S14]。

adb 链的形态不同：它是一个纯客户端检查 + 设备操作层。二进制解析顺序是先读环境变量 REA_ADB_PATH（必须绝对路径）、回退到 PATH；可用性探测执行 adb version，代码注释强调该探测"never starts the adb server"（不拉起后台守护），超时 10 秒、输出上限 64 KiB [S15]。设备清单工具 list_adb_devices 的行为也写得很克制：设备状态按 adb devices -l 原样保留，unauthorized 与 offline 不会被折叠成失败——分析层用 /unauthorized/iu、/device[^\n]*not found|device offline|still authorizing|more than one device/iu 这类分类规则把状态翻译成面向调用方的解释 [S15]。工具面上，adb 链提供 24 个工具（inspect_adb_client、list_adb_devices、capture_adb_screen、read_adb_logcat、文件传输与生命周期操作等），是当前分组中数量最大的一组 [S07]。

对比维度APK 反编译链（JADX 桥）设备链（adb）
外部依赖无头 JADX 0.7.1 JAR + 完整 JDK 17+adb 可执行文件
版本固定方式revision 与 sha256 双固定，子模块源码不改动不固定版本，按 adb version 探测
REA 是否代管安装否，明确不下载不安装否，仅解析用户提供的二进制
主要预算边界元数据 8 MiB、上游 1 MiB、帧 8 MiB、I/O 32 MiB探测超时 10 秒、输出 64 KiB
已验证平台macOS arm64 + OpenJDK 21；Linux/JDK 25 未验证由 adb 自身支持面决定，REA 不做平台承诺
能力盲区签名、拆分 APK、native 库、运行时授权与离线状态原样透出，不代为修复

把两条链串成操作序列：

① 用户准备外部工具（JAR 或 adb）； ② 通过 REA_JADX_MCP_JAR、REA_ADB_PATH 或 PATH 让 REA 找到它们； ③ 打开 APK 或调用 adb 工具时，前置检查先行（主机支持、Java 启动器、版本探测）； ④ 分析经无头 JVM 或 adb 子进程执行； ⑤ 结果与依据记录按 3.2 的模型落档 [S14][S15]。

失效边界与验证条件：JAR 路径、JDK 版本、主机平台三者任一不满足都会在探测阶段失败并给出补救文案；Linux/JDK 25 组合缺乏验证记录，被明确列为"未验证"而非"不支持"；adb 侧把设备状态原样透出，避免把"用户还没授权"误报成工具故障 [S14][S15]。成本与权衡：固定 revision + sha256 的组合把供应链风险压到最低，代价是引擎升级必须由用户手动换 JAR；两条链相互独立，使"只分析 APK"不需要设备、"只操作设备"不需要反编译器，但共用同一套依据模型，结论仍能汇合到同一台账里 [S10][S14]。

3.4 多目标家族与 RISC-V 判定：事实、推断与未知

先看除 Android 之外的家族分布。内建能力不需要任何外部安装：Go 二进制用自实现的 ELF/PE/thin Mach-O 静态读取器（readGoElfImage()），进程行为捕获用捆绑的 node-pty 后端，.NET 程序集为纯静态读取 [S16][S17]。外部工具链则必须由用户准备，REA 只负责调用：固件分析调用 Binwalk 或 Unblob（Linux，私有工作区，不做设备挂载与仿真）、WASM 依赖 WABT 1.0.42、离线 ELF 与记录崩溃依赖 pwntools（Linux x64）、网站分析依赖 Chrome 家族浏览器、Android 资源依赖 Apktool [S02][S20]。商业与独立进程类则是第三档：原生深度分析的 Hopper 与 IDA 都是商业授权产品，Ghidra 开源但需本机安装，JEB 要求用户自行启动一个 MCP 服务并经 REA_JEB_MCP_URL 接入——REA 在所有场景下都不附带、不代购、不代为配置这些工具 [S20]。

图 3：能力边界与外部依赖对照
图 3：能力边界与外部依赖对照

图 3：能力边界与外部依赖对照 —— 内建能力、外部工具链与商业/独立进程三类划分，附三条平台约束。来源：README 能力表与 docs/installation.md、docs/ida-provider.md、docs/firmware-analysis.md [S02][S20]；数据口径：平台与依赖约束按 commit c22111ec 的文档与源码核对，预算数字取 src/config/providerStartupTimeout.ts 与 docs/mcp-contracts.md [S08][S18]。

见图 3，三类框的区别可以总结成一句话：绿色框装的是"装上 REA 就有的能力"，黄色框是"REA 会调但不会给的依赖"，红色框是"商用许可或独立进程，REA 只认接口"。下方三条灰色注记是选型时最容易忽略的三条硬约束：进程捕获没有 Windows 原生支持（ProcessCapturePlatformUnavailable 文案原文为 "Windows PTY process capture is unavailable because this adapter does not yet verify descendant cleanup."，并提示 Windows 下可用 WSL 内运行 Linux REA，但这不构成原生 Windows 进程树捕获 [S17]）；离线 ELF、EVM 与 pwntools 链绑定 Linux x64；启动与响应预算可调但有下限 [S17][S18][S20]。

Go 子链与 RISC-V 的交点值得单独给出原文。ELF 机器码到名称的映射表里有一行 [243, "riscv"]（EM_RISCV），这是全仓库中 RISC-V 在功能代码里最实质的一处出现：

const elfArchitecture = (machine: number): string => {
  const names = new Map([
    [3, "386"],
    [8, "mips"],
    [20, "ppc"],
    [21, "ppc64"],
    [22, "s390"],
    [40, "arm"],
    [62, "amd64"],
    [183, "arm64"],
    [243, "riscv"],
    [258, "loongarch"],
  ]);
  return names.get(machine) ?? `elf-machine-${machine}`;
};

配合它的还有测试夹具中的 architecture: "riscv64" 取值（src/application/go/GoBinaryService.test.ts）与构建工具链里出现的 @oxc-parser/binding-linux-riscv64-gnu 开发依赖（属于构建工具而非运行时功能）；除此之外，仓库没有任何 RISC-V 专属文档或支持声明 [S16][S21]。

图 4：RISC-V 判定的三档结构
图 4：RISC-V 判定的三档结构

图 4：RISC-V 判定的三档结构 —— 事实（源码可核对）、推断（结构性理由）与未知（无公开验证）。来源：src/go/GoElfImage.ts、src/application/go/GoBinaryService.test.ts、licenses/npm-dependencies.txt 与 docs/android-analysis.md [S16][S21][S14]；数据口径：以 commit c22111ec 全仓库检索为准，仅收录源码与文档中可核对的痕迹 [S19]。

见图 4，三档之间用箭头连成一条推理链：事实层只有四处痕迹；推断层说明为什么机制上"看不出排斥 RISC-V 的结构"（依据模型把架构当数据字段、进程捕获按操作系统判定、Go 读取是纯解析）；未知层则列出报告中不做承诺的部分。把这条链压缩成表：

判定维度事实（源码可核对）推断（结构性理由）未知（无公开验证）
Go 子链机器码表含 [243, "riscv"]；测试夹具用 riscv64RISC-V 会被识别为 "riscv" 而非 "elf-machine-243"无 RISC-V Go 二进制端到端实测
原生 provider无架构专属分支；语言由文件头检测，可用 REA_GHIDRA_LANGUAGE_ID 覆盖RISC-V 反汇编可达性取决于 Ghidra 自身语言表Ghidra 对 RISC-V 的配置与效果未在 REA 侧验证
进程捕获平台判定按操作系统而非指令集RISC-V Linux 主机不发生额外分支无 RISC-V 主机（含 WSL）运行记录
Android 链桥验证状态明示 macOS arm64/JDK 21；Linux/JDK 25 未验证JADX 为 Java 程序，与宿主指令集无强绑定RISC-V 主机上的 JVM 行为无记录
整体声明无 RISC-V 文档、无支持承诺文字工具链未设置架构闸门上游是否把 RISC-V 列为目标未知

步骤序列上，评估一款工具对 RISC-V 场景的可用性可以照此执行：

① 按目标家族定位子链（Go、原生、进程、Android）； ② 在子链源码中查架构相关分支（如机器码表、语言检测）； ③ 核对 provider 自身的语言与平台支持面（Ghidra 语言表、JDK 提供方）； ④ 以目标环境端到端实测作为最终判定，而不是以文档字面推断 [S09][S16][S20]。

失效边界与成本权衡：版本滚动快（always-bump-minor 加高频发布）意味着任何行为结论都会随版本漂移，本报告的应对是把一切绑定到 commit c22111ec 与 6.4.0 [S19]；商业 provider 的可用性不属于 REA 的可控面——IDA 文档明示 Linux 无头链路"在对应真实工作流完成前不宣称支持"，Ghidra 的 Windows 支持仍是 P0 只读 [S20]。对 RISC-V 采用者来说，最实际的权衡是：如果要复用 REA 的"内建 + 依据留痕"能力，Go 与进程子链是零成本入口；如果要原生深度反编译，则要先解决 provider 语言表与商业授权的双重成本 [S16][S20]。

总结与展望

把前文压成三个设计支点。其一是共享组装：CLI 与 MCP 只有一个接线点，任何"两个入口行为不一致"的怀疑都可以先在该文件证伪或证实 [S04]。其二是依据留痕：目标摘要绑定、五档等级、五类定位、会话级台账、unk_ 未知项与统一错误面共同组成"结论从哪来"的完整回答，这层纪律比任何单个工具的能力更能决定它在严肃场景（安全评估、取证、移植核查）中的可用性 [S10][S11][S13]。其三是边界明示：不在能力表里的目标明确不承诺，不代管的外部工具明确不安装，未验证的平台组合明确标注"未验证"，这种写法让选型评估可以完全基于文档完成第一轮筛选 [S02][S14][S20]。

对采用者，建议按三步核对：第一步用 tools/list 与分组清单比对 173 个工具是否覆盖需求（含副作用审计带来的自动化安全边界）[S07][S08]；第二步按目标家族盘点外部依赖与平台约束（原生 provider 的授权、Android 链的 JDK、进程链的操作系统）[S17][S20]；第三步对关键目标做小样本端到端试跑，重点观察依据记录与未知项的行为是否符合预期 [S10][S11]。

展望方面有三条可观察的线索：其一，MCP 生态的工具数量在快速增长，但"返回结构化的依据与未知项"仍是少数项目的做法，REA 把这层做成了产品级纪律，这会成为它与其他连接器拉开差距的主线 [S10]；其二，版本节奏（always-bump-minor 加高频修复）说明项目仍在快速演进，任何生产采用都应固定版本并把升级当作一等事件 [S19]；其三，RISC-V 与新平台的支持状态只能以目标环境实测为准——本报告给出的三档判定框架可直接复用于后续版本复核，当上游出现 RISC-V 专属文档或验证记录时，对应章节需要重做 [S16][S21]。

参考来源

以下引用全部锚定 morluto/rea 固定 commit c22111eca2c4bc84a084f12711f405b3e7422a40（2026-10-12 抓取；行号均以该快照为准），npm 元数据为同日抓取。

附录 A：主要结论与依据对照

主要结论依据（来源与位置）判定档位
CLI 与 MCP 共享唯一组装层，行为不分叉src/composition/binary.ts 注释与注册代码 [S04]源码事实
173 个公开工具、25 个分组，副作用逐一声明且严格执行TOOL_EFFECTS 与 toolEffects.test.ts 相等断言 [S07]源码事实
provider 选择确定性、无回退，失败理由枚举 12 个拒绝码AnalysisProviderRegistry.ts 与 providerSelection.ts [S09]源码事实
打开目标即绑定全量 sha256 与 8 KiB 前缀ArtifactHash.ts [S12]源码事实
记录三要素（目标摘要、等级、定位）与五档等级枚举src/domain/evidence.ts [S10]源码事实
台账不可变、写入幂等、冲突拒绝；未知项 unk_ 稳定编号EvidenceLedger.ts 与 residualUnknown.ts [S10][S11]源码事实
错误面 10 类与必填字段由构建期生成，114 行文案清单对读docs/error-contract.schema.json 与生成脚本 [S13]源码与生成物
JADX 0.7.1 双固定（revision+sha256），REA 不下载不安装JadxRelease.ts 与 docs/android-analysis.md [S14]源码事实
Android 桥验证状态：macOS arm64/JDK 21 已验；Linux/JDK 25 未验docs/android-analysis.md [S14]官方文档声明
adb 用户自备、不代管安装；设备状态原样保留AdbConfiguration.ts 与 AdbProvider.ts [S15]源码事实
进程捕获仅 Linux/macOS 原生 PTY，Windows 明确不可用ProcessCaptureCapability.ts 与 docs/process-capture.md [S17]源码与官方文档
RISC-V：源码痕迹仅四处，无端到端实测；按事实/推断/未知分档GoElfImage.ts、测试夹具与依赖清单 [S16][S21]事实与未知分档（见 3.4）

附录 B：检查与验收清单

检查项核对方式结果
源码快照完整性浅抓取后以 git rev-parse HEAD 与目标 SHA 比对一致（c22111ec…）
元数据结构固定结构校验脚本（11 字段、文档类型）通过
来源可追溯每条来源编号（如 [S01]）可回跳固定 commit 的文件路径通过（见参考来源与附录 A）
图与图注本地图片 4 张；图注含来源与数据口径通过（图 1 至图 4）
表格数量Markdown 表格计数通过（≥4）
语言规范正文无 Meta 词汇与未决标记通过
RISC-V 三档判定全仓库检索与图 4、按表逐条核对通过

附录 C：研究方法与局限

本报告的方法分三层。第一层是固定快照：以 git fetch 方式浅抓取目标 commit c22111ec 的全仓库源码，所有行号、枚举取值与引文均以该快照为准，不引用滚动中的主分支。第二层是逐文件核对：对入口、组装、接口、领域对象、配置、Android、adb、Go 与进程九个片区分别逐行阅读，关键结论保留原文引用（本报告中的代码块均为逐字摘录或按快照字段的原样转写）。第三层是三档判定：能直接核对到源码或官方文档的写入"事实"；只有结构性理由支持的写入"推断"；仓库中不存在的验证记录写入"未知"——尤其 RISC-V 相关结论严格遵守这条纪律，不把"代码里没有架构闸门"扩展成"支持 RISC-V"。

局限同样要说清楚：其一，本报告未安装、未运行 REA，所有运行期行为结论都来自源码与官方文档，未经实机复现；其二，行号与枚举随版本漂移，引用相对快照有效，后续版本需要重新核对；其三，商业 provider（Hopper、IDA）的内部行为与许可细节超出核查范围；其四，Android 桥在 Linux/JDK 25 与 JEB 链上的实际表现依赖用户环境，文档声明与真实工作流之间可能存在时滞；其五，对 RISC-V 的任何进一步判断都需要目标板卡或等价环境上的端到端实测，包括打开、反编译、依据落盘全链路。