一、引言：从“这个功能怎么做的”到“证据在哪里”
看到一个应用里的功能，工程师经常会问：它的实现从哪个模块开始？跨过哪些进程边界？如果只有安装包、压缩后的脚本或运行中的页面，单靠搜索字符串和猜测调用链，很容易把“找到线索”写成“已经证明”。
REA（Reverse Engineer Anything） 的切入点不是替你自动得到全部答案，而是把分析能力接给编码代理：代理提出调查问题，经 MCP 调用工具，继续追问，最后把观察、证据和局限组织成解释；不用代理时，也可以走 CLI。项目覆盖原生二进制、JavaScript/Electron、.NET、网站和其他工件，但不同目标的前提并不相同。
本文重点回答三个问题：REA 如何把工具接到 Agent 上？它怎样避免“分析结果就是事实”的错觉？哪些任务能静态完成，哪些会触碰运行时和外部分析器？
范围说明：本文阅读了仓库提交
c3fc6c3的关键源码、README 与项目文档，以及官方 Notion 案例；没有安装 REA、运行第三方目标或复现实验。案例中的观察与数据来自项目公开材料，不是本文独立测量。该提交的package.json标为6.1.0，不等于已经核实 npm 当前发布版本。
二、先看结构：MCP 与 CLI 是入口，不是两套分析引擎
REA 的 npm 包名是 rea-agents。package.json 把 rea 和 rea-agents 两个命令都指向 scripts/rea.mjs。这个小文件先看参数：单独的 mcp 或 --mcp 进入 MCP 服务，mcp doctor 走独立诊断分支，其余参数进入 CLI。setup 并没有一个单独的启动器分支，而是交给 CLI 的命令体系处理。查看入口源码
沿两条入口向里追：
- MCP 侧：
src/main.ts解析环境配置，创建二进制会话，再启动 stdio 传输；真正的工具注册集中在src/server/createServer.ts，按二进制分析、配置型能力、浏览器/应用观察和会话工具等组别装配。 - CLI 侧：
src/cli.ts注册安装、分析、工件、浏览器等命令。它通过src/composition/directAnalysis.ts绑定应用层的直接分析函数，而不是在 CLI 命令里重新实现一套分析逻辑。 - 提供者侧：
src/composition/binary.ts创建 Hopper、Ghidra、IDA 三个原生提供者，交给AnalysisProviderRegistry，辅助提供者另以惰性方式接入；托管代码分析有独立的静态提供者入口。这里是组装关系，不意味着三种引擎每次都启动。
这也是项目最值得借鉴的架构取舍：传输层处理“如何给 Agent 或终端使用”，应用层处理“如何调查”，提供者处理“借什么能力调查”。 官方 CLI 文档 明确说 CLI 使用与 MCP 相同的应用工作流和 Evidence 契约；但两者的进程生命周期并不一样，CLI 每条命令是一次独立调用，不能把 MCP 会话中保留的状态想当然带到下一次 CLI 命令。
工具多，不代表此刻都能用
REA 的 tools/list 契约 返回的是规范工具清单，包含当前不可用的工具。是否真的可用，要看 binary_session({}) 返回的 tool_availability：它会说明原因、补救方式以及缺少的客户端能力。原生提供者选定之后也不会因运行失败就悄悄切到另一家。对 Agent 来说，这比“调用失败再乱试”更可控；代价是使用者必须先看清环境和目标。
三、核心不是“会反编译”，而是证据的归属
把反编译器接成一个 MCP 工具并不难。难的是下一步：代理拿到一段伪代码、一张模块图或一次网页网络观察之后，能否说清它从哪里来、支持什么判断、还有什么没有验证。
REA 在这里做了几层约束：
- 结果有结构。MCP 契约 要求产出 Evidence 的工具返回完整记录；客户端可读取
structuredContent.normalized_result和structuredContent.evidence_id，而不是只解析一段自然语言。 - 记录有会话边界。同一 MCP 连接可以用
evidence_id引用保留的证据；close_binary会清空保留记录。要在 CLI 的独立调用之间复用结果，需要保存完整输出，而不能只记一个当前会话里的 ID。相关契约 - 传输不偷偷截断结论。
src/server/toolResult.ts在完整结果超过 MCP 响应预算时返回资源约束错误，并给出恢复线索，而不是把半段证据冒充成功结果。是否存在可恢复的保留记录，取决于该次调用是否已经成功记录 Evidence。 - 成功不等于完美。CLI 文档 说明退出码
0仍可能伴随部分证据、警告或未解决问题。调查者需要读状态和局限，而非只看 shell 是否返回成功。
因此，一个好的 Agent 回答不该只是“我找到了 clipboard.write，所以功能就是这样”。更稳妥的写法是分三栏：直接观察到的源码/位置、由调用链推出的行为、尚未做的运行时验证。这不是措辞上的谨慎，而是在给下一轮调查留下可检查的接口。
四、拿 Notion 案例看：工具负责定位，人负责把链补齐
官方的 Notion 剪贴板案例 很适合检验这个边界。调查目标是：桌面应用里一次写入剪贴板，如何从网页侧走到 Electron 主进程？
案例记录中，REA 对保存的 tab preload 标出页面 API __electronApi 与一个 invoke 调用的位置。这一层只证明“这里值得继续看”：工具输出的通道表达式是变量 e，不是自己解析出了具体通道名。接下来，调查者阅读压缩后的 preload，才把包装函数 invokerInMain("notion:clipboard:write") 与 ipcRenderer.invoke(channel, ...args) 连起来；再到主进程找到同名 ipcMain.handle 处理器，确认通过 isNotionWebContents(event.sender) 检查后调用 Electron 的 clipboard.write(data)。
这条链最有价值的不是函数名，而是每一跳的证据性质不同：REA 给入口与位置，源码阅读给通道名和包装函数的展开，主进程代码给实际写入点和发送者检查。案例没有展示一次桌面 UI 操作的端到端捕获，因此不能把这条静态调用链写成“已经实测了系统剪贴板最终内容”。
案例还谈到结构化块数据：HTML 里一个 notionvc 标识用于关联本地保存的块副本，不能据此说“所有结构化块都直接写进系统剪贴板”。相关 Web 资源与上面的桌面 IPC 证据不来自完全相同的版本；在复述时把它们拆开，才不会让两个真实观察拼成一个虚假的“同版本全链路验证”。
这里的通用方法可以迁移到其他项目：先让工具缩小搜索空间，再沿具体边界核对源码，最后写下没有验证的环节。定位不是证明，调用链也不是运行时实验。
五、怎么选路径：静态读取与运行目标不是一回事
REA 的 README 能力表 列了很多目标，但“支持”不代表开箱即用。基本运行时要求是 Node.js 22.x（≥22.19）、24.x（≥24.11） 或 26+，并安装 npm。更重要的是目标类型：
- JavaScript/Electron：可以从目录或 ASAR 做静态分析，得到模块、导入、source map、路由、IPC 等线索；不必先装 Hopper 或 Ghidra。对有权分析的样本，README 给出
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json作为一次性命令示例。 - .NET 程序集：读取元数据、CIL 与声明的原生依赖，属于静态检查路径。
- 原生二进制：深入的伪代码、汇编、调用和引用需要 Hopper、Ghidra 或 IDA 中的相应提供者；平台、格式和提供者健康状态还要单独核对。
- 网站与运行时行为：网站观察需要 Chrome 系浏览器；运行时捕获可能以当前用户权限启动目标程序，与“只读取现成文件”不是同一种风险。
npx rea-agents setup 会向支持的 Agent 注册 MCP 服务和匹配的工作流说明，并可能修改现有配置；应先审阅它提出的变更，再决定是否安装。REA 的“本地分析”指目标在本地被分析，不等于发给 Agent 的工具结果永远不经过模型服务，后者还受模型提供方的数据政策约束。参见 README 的 FAQ
六、结论：把工具能力与结论可信度分开设计
REA 的价值可以压缩成三个工程判断：
- 入口复用工作流：同一调查逻辑供 MCP 与 CLI 使用，代理交互和自动化脚本不必各造一套；但要显式处理会话生命周期差异。
- 结果携带证据与未知项：有来源、有 ID、有容量和错误契约，代理才能把“找到线索”写成可反驳、可继续追查的结论。
- 执行边界按目标拆开：静态读取、调用外部原生分析器、观察浏览器和运行目标，前提与副作用不同；有工具名称不等于当前具备能力，更不等于获得对目标的授权。
如果你想借鉴它的设计，不必从“支持所有格式”开始。先选一种你有权分析的目标，定义好问题 → 证据 → 推断 → 未知项的返回契约，再决定通过 MCP、CLI 或两者暴露。把这条线走通，比给 Agent 增加几十个没有边界说明的工具更重要。
资料来源
- 项目架构图
docs/architecture.mermaid（本文配图为独立 SVG，不依赖 Mermaid 渲染） - MCP 结果与工具发现契约 · CLI 与 Evidence 指南
- 官方 Notion 剪贴板案例
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
