REA 工作原理

00摘要：十二条核心论断

每条都是可证伪的机制判断，后面各章逐一展开。证据标记见表末说明。

1. REA 自己不产出分析知识。它把"知识"外包给 provider，自身只负责调度、约束与存档。证据：package.json 的 36 个运行时依赖里，没有任何原生反编译引擎；唯一带分析语义的依赖是 evmole（EVM 字节码，纯 WASM 可内联）。 源码
2. 它的调度单位是 provider，不是工具。170 个 MCP 工具只是 provider 能力的投影面；引擎（Ghidra/Hopper/IDA/JEB）本身也只是 provider 的一种实现。证据：官方架构图把 13 个 provider 与 src/server/（仅做请求转译）分列为不同层。 源码
3. provider 选择是确定性的，且失败即报错不猜测。注册表按排序取候选、命中即用、无模糊回退。实测对 Stickies.app 调 rea inspect，直接返回 provider_unavailable 并逐条列出四个引擎各自的不可用原因。 实测
4. 能力面天然分两层，且可以在零引擎下完全运行。rea capabilities --json 返回 18 项 target-free 操作，本机零引擎环境下 18/18 全部 available。这条"纯净子集"是它可裁剪性的来源。 实测
5. "操作可用"不等于"对任意目标可用"——这是两套不同的可用性。inspect_asset_catalog 在能力目录里是 available: true，但真拿 Assets.car 去调，返回 target_unavailable / unsupported binary format。能力声明管"操作存不存在"，目标准入管"这个输入能不能读"。 实测
6. 它用一张"产物图"统一所有目标类型。nib、JavaScript 应用、.NET 程序集、Mach-O、APK 都归一到 nodes + edges + kind 的同一结构。实测 decode-interface-builder 对 3 个 nib 产出 780 节点 / 421 边。 实测 源码
7. 它真正可移植的资产是证据模型，不是分析算法。输出结构固定为 observations / hypotheses / contradictions / unexplored_branches / next_probes，每份证据带稳定 ID 与 authority 分级。换掉引擎，这套口径不变。 实测
8. 复刻不是附带功能，是一等公民。仓库里有独立的义务台账服务、覆盖度服务、9 阶段一致性契约，以及 docs/reconstruction-obligation-ledgers.md 与 docs/reconstruction-readiness.md，并有 CI 脚本 verify-reconstruction-readiness.mjs。 源码
9. 它的判定是 fail-closed：不合格一律不聚合为通过。契约明确规定 fail、unknown、unsupported、truncated、skipped 永不聚合为 pass；每阶段与每项检查必须恰好出现一次并链接到证据。 源码
10. CLI 与 MCP 是同一内核的两个薄适配器，能力等价。官方架构图里 scripts/rea.mjs 只是 dispatcher，把请求路由到 src/cli.ts（one-shot）或 src/main.ts（MCP stdio），两者共用 src/application/ 与 src/composition/。所以未激活 MCP 不构成能力损失。 源码 实测
11. 它的价值上限由你装的 provider 决定。这是"编排层"定位的必然代价——工具再多，反汇编深度仍取决于你装了 Ghidra 还是 Hopper。反过来也成立：不装引擎时它退化成一套诚实、可复现的静态产物分析器，而非什么都做不了的空壳。 推断
12. 它把"分析失败"与"环境损坏"分开归因。9 阶段契约里 diagnose-environment 的必需证明是"把损坏的运行时与分析失败分开、检测版本偏差、恢复后 revision 变化"。多数工具会把两者混成一个"运行失败"。 源码

01定位判定：它为什么不是反编译器

先把最容易误判的一点钉死，后面所有机制都建立在它之上。

第一次看到 REA 的能力清单，最自然的理解是"一个 AI 版的反编译器"。但这个理解会立刻导致一连串错误的预期：为什么装完它还是"什么都反不了"？为什么 doctor 退出码是 1？为什么 170 个工具里绝大多数在零引擎环境下用不了？

正确答案是：REA 是分析编排层（analysis orchestration layer），不是分析引擎。它把"产生分析知识"这件事整体外包给 provider，自己只做三件事——把请求路由到合适的 provider、把能力边界与限制声明清楚、把观测结果封成可复现的证据。

证据一：依赖审计——36 个运行时依赖，零引擎

这是最直接的判据。一个真正的反编译器必须依赖反编译算法；如果依赖树里一个都没有，它在结构上就不可能是反编译器。

证据二：官方架构图把"引擎"和"调度"分到不同层

仓库的 docs/architecture.mermaid 用 11 个 subgraph 描述了自己的构成。其中 src/server/ 的标注是 「MCP request translation」（MCP 请求转译），而所有引擎——Ghidra、Hopper、IDA、JEB、pwntools、EVM、Binwalk——都落在独立的 Provider Layers 里，并且各自的标注都在强调适配而非实现：

Provider Layers
├─ src/ghidra/   Ghidra discovery, profile & function analysis
│                snapshot, Unix/Windows transport, bounded lifecycle
├─ src/hopper/   Hopper launch & Unix-socket protocol
│                BridgeLauncher, HopperClient, protocol
├─ src/ida/      Upstream MCP contract adaptation
│                live GUI binding or owned headless database
├─ src/native/pwntools/ + pwndbg/
│                BYO offline ELF/core adapters
│                unchanged upstream parsers, ABI structures
├─ src/evm/      unchanged EVMole/WASM in bounded owned worker
└─ ... (共 13 个)

注意几个措辞：「adaptation」（适配）、「BYO」（bring your own）、「unchanged upstream」（上游未改动）。REA 在架构文档里明确承认这些能力不是它实现的：src/ida/ 是"上游 MCP 契约的适配"，pwntools/pwndbg 是"BYO 离线适配器，上游解析器/ABI 结构/映射 API 均未改动"。

证据三：实测报错自证了边界

最干脆的证据来自一次真实调用。用 REA 的"正规入口"分析一个 macOS 应用：

$ rea inspect /System/Applications/Stickies.app
error: provider_unavailable
  operation = current_document
  ghidra : not_configured
  ghidra : architecture_unsupported   ← v1 无法强制 universal Mach-O 的架构
  hopper : executable_missing
  ida    : not_configured

它没有尝试"降级用别的方式凑一个结果"，没有返回半个分析，也没有含糊地报"分析失败"。它做的是：列出所有候选 provider，逐个说明为什么用不了。这正是"编排层"的自证——当没有可用的执行者时，编排者唯一诚实的动作就是报告"没有执行者"。

反过来：它也不是"空壳"

把 REA 简化成"只是个包装层"同样是误判。零引擎环境下它依然能完成实质工作——18 项 target-free 操作中有 decode_interface_builder（解 nib）、inspect_keyed_archive（解 keyed archive）、inspect_plist、inspect_macho、list_architectures、demangle_swift、trace_dylib_resolution 等。这些不是"包装"，是它自己实现的静态解析能力（src/domain/apple/interfaceBuilderGraph.ts、src/domain/artifactGraph.ts 等）。

所以准确的定位是：REA = 自研的静态产物分析内核 + 对第三方引擎的统一编排 + 一套证据契约。三者权重随你安装了什么而变。

02分层架构：依赖为什么必须向内流动

官方架构图给出 11 个层次。理解层间依赖方向，才能理解为什么"换个引擎"不会牵动其他部分。

仓库的 docs/architecture.mermaid 是理解 REA 结构最好的入口。它把系统切成 11 个 subgraph，并且给出了层间连线。把连线关系提炼出来，依赖方向非常干净：

DISPATCH (scripts/rea.mjs)  →  CLI (src/cli.ts)  |  MAIN (src/main.ts)
MAIN  →  CONFIG  |  SERVER  |  APP
CLI   →  APP
MAIN  →  COMPOSITION     CLI → COMPOSITION     SERVER → COMPOSITION

关键点在于 Composition 层被三个入口同时依赖，而 Composition 自己不依赖任何入口。这是典型的依赖倒置：入口层薄，装配层重，能力层（provider）只被装配层引用。

三件关键装置

官方架构图在应用层单独点名了三个装置。它们是理解 REA 运行时行为的钥匙：

Provider 层的真实规模

官方图列了 13 个 provider subgraph。按文件数看它们的权重差异很大——这个分布本身就是一种表态：

03一次分析的完整生命周期

从请求进入到证据封存，中间发生八件事。其中"run 分配先于 provider 启动"是最容易被忽略、却最能说明设计意图的一步。

把 CLI 与 MCP 两条入口合起来看，一次分析请求的流转可以切成八段。这段流程不是我从文档猜的——它由三处交叉确认：官方架构图的层间连线、docs/mcp-contracts.md 里对 binary_session 的逐字段规定，以及实测的 provider_unavailable 报错结构。

逐段说明

一个反向证据：目录是不变的

契约文档里有一条容易被读漏、但很能说明问题：

tools/list returns the complete canonical tool inventory,
including tools that are currently unavailable.

Opening or closing a target or observing a provider health
transition leaves that catalog unchanged and does not emit
notifications/tools/list_changed.

也就是说：打开一个引擎、或引擎从故障中恢复，都不会让工具目录发生变化。目录是"规范全量"，不是"当前可用集"。这与很多工具"动态注册能力"的做法正好相反。

这个选择的代价是：调用方必须在每次调用前用 binary_session 查当前可调用集，不能靠目录推断。收益是：宿主（以及模型上下文）里的工具定义永远稳定——不会因为某个引擎的启动或崩溃而让上下文里的一大块 schema 失效重算。

04Provider 模型：确定性与不可替换性

"确定性选择、无回退"听着像一句广告语，但它有精确的字段级语义。这一章把它拆开。

REA 的 provider 不是插件式的"多路尝试"。它是一套带类型的选择协议——候选、绑定、选择来源、歧义，各自是不同字段，语义不可互换。契约文档对此有明文规定。

三类 provider

13 个 provider 按"能力从哪来"可以归为三类。这个分类决定了它们在零引擎环境下的命运：

选择协议的精确语义

契约文档对 binary_session 的几个字段做了明确的区分，这几条合起来就是"确定性"的完整定义：

实测：失败出口长什么样

对 Stickies.app 调 rea inspect，命中的是中间那条出口。它的输出结构值得逐行读：

error: provider_unavailable
  operation = current_document      ← 失败的是哪个"操作"，不是哪个"工具"
  ghidra : not_configured           ← 候选 1：装了没配
  ghidra : architecture_unsupported ← 候选 1 的第二个卡点
  hopper : executable_missing       ← 候选 2：可执行文件不在
  ida    : not_configured           ← 候选 3：未配置
  (jeb 甚至没进入候选)

三点值得注意：

• 按"操作"失败，不按"工具"失败。报的是 operation = current_document。这与架构图里"operation"是路由的一等公民一致——工具只是 operation 的对外投影。
• 同一候选可以有多个卡点。ghidra 出现了两次：既未配置，又架构不支持。architecture_unsupported 这一条特别有信息量——它说明这类检查带有目标侧约束，不只是"环境里有没有"。
• 没有进入候选的引擎不会出现。jeb 不在清单里，说明候选集本身也是过滤后的结果，而不是"所有已知引擎都列一遍"。

05引擎边界：两套可用性，别混为一谈

"这个操作能用吗"和"这个操作能处理这个文件吗"是两个不同的问题。REA 把它们分成了两套机制。

零引擎环境下，rea capabilities --json 返回 18 项 available: true 的操作。这份清单是本次实践最有用的产出之一——它精确划出了"不装任何东西也能做什么"的边界。

18 项零引擎能力全清单

按作用对象分组，这 18 项构成了一套完整的"静态产物分析"工具集：

第二套可用性：目标准入

上表里有一项 inspect_asset_catalog。它在能力目录里是绿的。但真拿一个 Assets.car 去调用时：

$ rea inspect-asset-catalog .../Stickies.app/Contents/Resources/Assets.car
error: target_unavailable
  reason: unsupported binary format

这不是 bug，也不是配置问题。它是两套独立机制在各自如实表态：

三个状态，而不是两个

从 binary_session 与 rea doctor 的字段设计可以看出，REA 的可用性是三态的：

第三态最容易被忽略，也最能说明这套设计的性格。契约文档里对 rea doctor 的原文是：它"keeps live-server state unknown unless the active connection supplies identity"——在没有活动连接提供身份之前，它宁可说"我不知道"，也不猜。

同样地，target-free 发现阶段会返回 unknown target support，而不是把"没试过"标成"不支持"。这是一个很克制、也很少见的默认值选择。

06产物图：一张图管住所有目标类型

nib、JavaScript 应用、.NET 程序集、Mach-O、APK——它们的分析结果落在同一个数据结构里。这是 REA 能"一套工具面覆盖多种目标"的结构前提。

实测中信息量最大的一次调用是 decode-interface-builder。它把 3 个 nib 文件解成了一张 780 节点、421 条边的图，并在结果里标了 hierarchy_complete: true。但真正值得注意的是这个结果的形状——它不是"nib 专用输出"，而是通用产物图。

节点与边的字段

从实测输出的 JSON 结构可以直接读出图的模型：

同构的姊妹实现

产物图不是只有 Apple 一种。仓库里能数出一组平行实现，共用同一套"节点 + 边"抽象：

注意第四行：javascriptRuntimeReconciliationGraph——把静态图与运行时观测图做对账。这说明图模型不只是"记录"，还是"比较"的载体。这直接支撑了第 09 章的义务闭合逻辑（静态事实只能产生候选义务，不能证明运行时行为）。

07证据模型：五元口径与稳定标识

这是 REA 最可移植的一层，也是它和"跑个脚本输出一段文字"之间最本质的区别。

实测 rea inspect-artifact 的输出是一份 426 KB 的 JSON，其顶层结构给出了 REA 对"一次调查"的定义：

实测的标识长什么样

这些 ID 不是示意，是本次实践真实返回的值：

evidence_id    = ev_68273f72…
inspection_id  = ai_75fdbdff4d78311f95e2f7355a84e9be4249907362b59373bbbaa6efc

next_probes[0] = { operation: analyze_javascript_application,
                   authority: ast-static-analysis }

三个细节：

• ID 带类型前缀。ev_ 是证据、ai_ 是 inspection。前缀让 ID 在日志和引用中自带语义，不需要额外查表。
• inspection_id 是 64 位十六进制——长度暗示它是内容摘要而非自增序号。配合目录摘要 catalog_digest，一次调查可以被完整锚定。
• next_probes 带 authority。它不只是说"建议下一步做什么"，还说"这一步的证据权威性属于哪一级"。

authority 是什么，为什么它重要

从契约文档能确认 authority 至少有三个取值：process、packaged-process、ast-static-analysis。它的作用在第 09 章的复刻台账里说得最清楚：

一个必需义务只有在"验证者的权威性与原始观测相当"（a passing verifier whose authority is comparable to the original observation）时才能闭合。

换句话说：你不能用一个静态分析的结论，去证明一个只有真实运行时才能确立的事实。这条规则把"证据强度"从一句定性描述，变成了机器可校验的字段约束。

一条很讲成本意识的工程约束

契约文档里有这么一条，值得单独摘出来：

Hosts forward input schemas to the model with every request,
so advertised examples never copy complete producer Evidence.
An embedded Evidence record is shown as its exact
{"kind":"retained-evidence","evidence_id":"ev_..."} reference.

因为宿主（IDE、CLI 客户端）会把工具定义连同示例随每一次请求发给模型，所以工具广告里的示例绝不复制完整的证据正文——只给一个引用指针。这是对 token 成本的正向设计：工具面的大小不能随证据体量膨胀。

配套的还有 REA_MCP_INPUT_SCHEMA_PROFILE=compact：某些函数调用型客户端对单个工具的 parameters schema 有字面序列化大小上限（文档记录了 Moonshot 系客户端如 kimi-cli 在默认目录下每个请求都会失败，社区实测 13.7 KB 被接受、约 15 KB 被拒绝）。compact profile 把每个输入 schema 压进 13,312 字节预算，而服务端仍按完整 schema 校验——所以按精简广告调用的调用方会收到类型化错误，而不是被静默接受。

这个取舍很有意思：宁可让不按规范调用的客户端收到明确报错，也不放宽真实校验。又是一次 fail-closed。

08双接口：同一内核的两个薄适配器

"你没激活 MCP 就等于没用上 REA"是一个自然但错误的推断。这一章用结构证据说明为什么。

本次实践里，mcp__rea__* 工具始终未出现（需要用户在连接器页手动信任）。但整个工作流照常跑通了——这说明 CLI 与 MCP 不是"主从"关系。官方架构图给出了结构上的解释：

DISPATCH  scripts/rea.mjs
  ├─→  CLI   src/cli.ts + src/cli/
  │         One-shot CLI adapter
  │         setup, diagnostics, analysis, decompilation
  └─→  MAIN  src/main.ts + src/main/
            MCP stdio server adapter
            config, session, process lifetime

CLI  →  APP          MAIN  →  APP
CLI  →  COMPOSITION  MAIN  →  COMPOSITION
SERVER (MCP 转译) →  COMPOSITION

两条路径汇合在同一个 src/application/ 与 src/composition/。scripts/rea.mjs 只是一个 dispatcher（文档原话：Executable dispatcher，routes mcp / one-shot）。所以适配层是薄的，内核是共享的。

能力等价的三个结构证据

实测：MCP 通道确实在工作

虽然会话里没有 mcp__rea__* 工具，但 MCP 服务器本身是通的。用事件驱动的 stdio 探针实测：

→ initialize (protocolVersion 2024-11-05)
← serverInfo {"name":"rea","version":"6.4.0"}
→ notifications/initialized
→ tools/list
← 170 个工具，170/170 带完整 inputSchema

同时实测出一个对使用者有实际影响的特性：冷启动成本高。首次 tools/list 需要加载全部 170 个工具的 schema，用固定延时等待的探针连续三次超时（最长等到 260 秒）。换成事件驱动——一收到 initialize 响应就立刻发 tools/list，而不是靠定时——才稳定取回结果。

数量不对称不等于能力不对称

实测中，CLI 侧用正则从 rea --help 提取到 129 个子命令，MCP 侧 tools/list 返回 170 个工具。两者数量不等，原因在于暴露粒度不同——同一个底层 operation 可能按 surface（CLI / MCP）、按 mode、或按客户端能力差异，投影成不同数量的对外条目。

契约文档对这种粒度有一套明确的展开规则（tool_availability.groups[].names 逐条展开，携带 surface、availability、reason、remediation、default-mode 状态、modes 与 client 需求），并给了一条校验建议：把各组的名字取并集，与 tools/list 比对，即可验证客户端是否收到了完整目录。它还补了一句关键的：某操作若不出现在任何组里，就意味着它从完整清单中缺失——而不是"隐式地不可用"。

09复刻契约：把"逆向一个应用"变成可判定的工程

这是 REA 最独特的一层，也是本次实践真正用到的那部分。它不满足于"给你一堆观测"，而是要判定"复刻到什么程度算完成"。

仓库里有一组专门的设施，规模远超"顺手加个功能"的程度：

义务台账：闭合条件

义务台账（obligation ledger）的核心机制可以概括成一句话：把"应该复刻什么"变成带闭合条件的条目，然后逐条判定它闭没闭合。

一条必需的复刻义务只有在同时满足以下全部条件时才能闭合：

1. 一个 manifest binding 提供了唯一的实现方（unique owner）；
2. 提供了所有必需的 parser / schema / domain 类型；
3. 提供了每一个必需的用例 fixture；
4. 有一个通过的验证器，且该验证器的 authority 与原始观测相当；
5. 该验证器枚举了这条义务的 ID；
6. 验证结果存在于输入证据包中。

而下列任何一条都会让闭合保持 open 或转为 failed：矛盾、重复的定义或实现方、残留未知、缺失依赖、权威不可用。

义务条目的字段设计本身就是一份方法论：

9 阶段一致性契约

仓库另有一套"复刻就绪度"契约，通过 npm run verify:readiness 在干净检出上执行，并且不对公众暴露为 CLI 命令或 MCP 工具（文档明确说明：它是项目自己的验证器，不是产品能力）。它规定了 9 个必需阶段：

fail-closed：12 条拒绝就绪的情形

契约还列了一张"什么时候判定为不就绪"的清单。它比"通过条件"更能说明设计取向——因为这里每一条都是主动拒绝给出结论：

• 一个有界能力没有给出有效的数值限制；
• 一个 fixture 缺少恰好一个兼容的选中工作流；
• 调用了不兼容或不可用的 provider；
• 类型化的 CLI 失败却以 0 退出，或 MCP 失败却报告成功；
• 并发行为使用了全域序比较；
• 把截断、不稳定、权威不可用或矛盾标记为等价；
• 一处刻意的主分歧没有被本地化；
• 矛盾证据或受影响的比较缺失；
• 复刻义务台账不是 ready、没有必需义务，或保留了未归属/未验证的必需义务；
• 进程超出其声明的 target / lifecycle、取消丢失诊断信息，或自有资源未释放；
• 重放不确定、篡改与过期未被检测，或预期源摘要不符。

最后一条尤其能说明"可复现"是被当作硬要求写进契约的：连"上次的源摘要和这次不一样"都必须被检测出来并拒绝。

10进程基础层与工程纪律

编排层要长期跑别人的引擎、启别人的进程、读别人写的文件——这一层的约束条件，比功能更能看出项目的成熟度。

官方架构图里有一个专门的 subgraph 叫 Provider Process Foundation，包含 src/process/（59 个文件）与 src/windows/。它的标注是：owned process groups, private roots, deadlines, bounded file reads and diagnostics, cleanup。这六项就是 REA 对"如何安全地跑一个第三方引擎"给出的答案。

安装期安全审计

本次实践在安装前对 npm 包做了一轮审计。结论如下——这一节的方法比结论更有参考价值：

生命周期：一个被推翻的担心

本次实践用独立前缀安装（~/.local/share/rea + 软链），而不是 npm 全局。安装后我产生过一个担心：既然 npm root -g 指向的位置与我们的实际安装位置不同，那么 rea setup 注册客户端时会不会写入一个坏掉的启动器路径？

实测证明这个担心不成立：

$ rea setup --client codex --dry-run
  Command: "/Users/junjian/.local/share/rea/lib/node_modules/rea-agents/scripts/rea.mjs" "mcp"
                                    ↑ 正是我们的实际安装位置

$ rea update
  {"status":"current","currentVersion":"6.4.0","installMethod":"npm"}

REA 用的是自身路径自省，而不是去问 npm root -g。所以"装在哪"这个问题，它自己知道答案，不需要外部约定。

顺带记一条实测到的 Node 生态机制，它解释了为什么当初必须显式指定前缀：nvm 的 npm 首行是 #!/usr/bin/env node，所以用绝对路径调用它，它仍然会去跑 PATH 上的那个 node，从而把 prefix 解析成那个 node 的目录。显式 --prefix 因此是必要且正确的。

doctor 的退出码语义

实测中 rea doctor 返回退出码 1。这不是环境坏了——它的检查项里同时包含"本机装了哪些受支持的客户端"和"引擎是否就绪"，于是未注册的客户端与未安装的引擎都被计入不健康项。

真正需要关注的是环境侧的判定。契约文档对 doctor 的职责描述是：它检查受支持的 JSON/TOML 客户端注册，把它们的命令向量归类为 aligned / stale / missing / invalid 四态，并且在没有活动连接提供身份之前，把实时服务器状态保持为 unknown。

四态分类 + 一个诚实的 unknown，这又是一次"宁可分类细一点，也不含糊说一句配置有问题"。

工程纪律的几个可观测量

其中 knip（死代码）与 jscpd（重复代码）这两项值得单独注意：它们是"清理型"检查，不是功能型检查。一个项目愿意在 CI 里跑这两样，说明它把结构性整洁当成了持续约束，而不是一次性重构。

11失效模式，与三条被实测推翻的判断

这一章是全文最该读的一章。前面十章的机制再准确，也不如"我错在哪、为什么错"来得有用。

三条更正

更正一：路径隐患不存在

本次改用独立前缀安装后，我担心 rea setup 会基于 npm root -g 拼出错误的启动器路径。--dry-run 实测显示它解析到的是真实安装位置。原因是它用自身路径自省。这条更正的含义是：不要用"通用生态常识"去推测一个具体工具的实现——REA 在这件事上做得比通用做法更可靠。

更正二：Assets.car 不是我的疏漏

我在复刻规划的自我批评里，把"完全跳过了 Assets.car"列为自己的遗漏。实际补跑后 inspect-asset-catalog 返回 target_unavailable / unsupported binary format。REA 自己也读不了这个文件。这条更正的含义是：先验证工具是否具备某能力，再检讨自己是否遗漏——否则会把工具边界误记成自己的失误，进而去做无效的补救。

更正三：接引擎不只是一个环境变量

我把"设 GHIDRA_INSTALL_DIR 即可"写进了规划。实测报错里出现了 ghidra: architecture_unsupported，并附有说明：v1 无法对 universal Mach-O 强制架构，须先 thin。这意味着接入 Ghidra 的前提条件里，包含一步针对目标文件的前置处理。这条更正的含义是："装上就能用"通常在编排层工具上不成立——编排层的接入成本不只在你装了什么，还在目标本身的形态。

失效模式清单

把本次实践与契约文档合起来看，REA 会"用不了"或"给不出结论"的情形可以归纳成五类。它们都不表现为崩溃，而是表现为带原因的显式拒绝：

本次实践未完成的项

为避免读者把"没提到"误当成"不需要"，这里列出我知道但没做的：

• capture-native-ui-scenario / observe-native-ui —— 这 4 项运行时观测能力可用但未跑。它们是补上 nib 几何缺失（第 06 章那个边界）的唯一途径，也是复刻规划里 P0 行为观测阶段的核心。本机工具链（Xcode CLI）已具备，未跑的原因是需要在目标机上真实启动应用。
• project-apple-application-graph —— 未跑。它能把已采集的库存证据投影成应用图，是复刻规划的下一步。
• build-reconstruction-obligation-ledger / evaluate-reconstruction-coverage —— 未跑。第 09 章讲的机制来自文档与源码，不是执行结果；我给的字段清单有文档依据，但没有实际产出过一份 ledger。
• DSh 客户端注册 —— npm 6.4.0 不含 dsh 适配器，需要从源码构建，未做。
• 真实引擎端到端 —— 未装任何引擎，所以"装上引擎后 REA 表现如何"这一半，本文无法评价。

12正确用法清单

如果只带走一页，带这一页。每条都对应前面某一章的机制。

13结论

以下判断是观点，不是共识。它们建立在前十二章的证据上，但推论部分由我负责。

它解决的问题不是"分析能力"，是"分析的可复核性"

如果把 REA 的价值理解成"让 AI 能反编译"，那它的天花板就是它所编排的引擎——你装了 Ghidra，它就有 Ghidra 的水平。这不是一个有护城河的位置。

但如果把它的价值理解成"让分析结论变得可复核、可比较、可复现"，那它做的事情就没有替代品：五元口径把观测与推断分开、authority 分级阻止证据越级、稳定 ID 让结论可追溯、fail-closed 让"没做成"无法伪装成"做成了"。这套东西在引擎换成什么之后都依然成立。

本次实践最有说服力的一个细节：126 KB 的证据包里，contradictions 与 unexplored_branches 是正式字段。一个把"我有哪些没查清"写进输出结构的工具，和一个只输出结论的工具，可信度不在一个层级上。

它的定位代价是真实的

编排层必然要付的代价是：能力上限受制于被编排者。零引擎环境下，REA 能做的是 18 项静态产物分析；要触及反汇编与伪代码，必须自带引擎。doctor 退出码 1、170 个工具里大量不可用、provider_unavailable——这些都是同一个代价的不同表现。

但这个代价换来的是可裁剪性：不装引擎不会让任何一项已有能力失效（第 05 章的两栏没有交集）。对使用者来说，这意味着一件事：你可以从零成本开始用，然后按需加装，而不是必须先配齐一整条工具链。

对"AI 原生工具"的一点观察

REA 是少数把失败路径设计得和成功路径一样完整的工具。它有三套显式的失败分级（provider / target / authority）、一个诚实的三态可用性（含 unknown）、一份 12 条的就绪拒绝清单，以及"缺少源证据永不声称闭合"的明文规定。

这与"AI Agent 需要什么"这个问题直接相关：Agent 最容易犯的错不是"不会做"，而是"不知道自己做没做成"。一个把"我做到了什么程度、还差什么、下一步该采什么证据"结构化输出的工具，比一个"能力强但只说结论"的工具更适合被编排进 Agent 流程——因为后者会让 Agent 在不确定的地方自信地继续往前走。

14附录：本次实践的命令与产物

实跑过的 REA 命令

# 版本与能力面
rea --version                                    → 6.4.0
rea --help                                       → 129 个子命令
rea capabilities --json                          → 18 项 target-free，全 available
rea doctor --json                                → node / host 双绿
rea capabilities / providers                     → 目录身份摘要

# 目标分析（零引擎路径）
rea inspect /System/Applications/Stickies.app    → provider_unavailable（引擎绑定）
rea decode-interface-builder <app> --format json → 780 节点 / 421 边 / 3 nib
rea inspect-artifact <app> --format json         → 426 KB，ev_68273f72…
rea inspect-asset-catalog <Assets.car>            → target_unavailable
rea analyze-javascript-application <fixture>     → 退出码 0，11 阶段全走完

# 生命周期
rea setup --client codex --dry-run               → 解析到真实安装路径
rea update --json                                → status: current

# MCP 通道
rea mcp  （stdio JSON-RPC）
  → initialize (2024-11-05) ─→ serverInfo rea/6.4.0
  → tools/list ─→ 170 个工具，170/170 带 inputSchema

本次实践产出的三份交付物

关键数据来源

• 本机 CLI 实测：rea 子命令 的输出，2026-10-12
• 仓库文件：通过 GitHub API 读取的 docs/architecture.mermaid、docs/mcp-contracts.md、docs/reconstruction-obligation-ledgers.md、docs/reconstruction-readiness.md、package.json、以及 src/ 目录树
• npm registry：rea-agents 的版本、依赖、发布者与完整性信息
• MCP 探针：自写的 stdio JSON-RPC 探针（事件驱动）

本文未使用任何 Apple 的界面文案、图标或资源文件。所有引用 REA 仓库内容的部分均已注明文件路径，读者可自行复核。