REA 接入前的技术核对：静态分析、后端和 MCP 分别检查什么

REA 接入前的技术核对：静态分析、后端和 MCP 分别检查什么

准备把 REA 接到 Agent 时，先区分三个问题：分析输入是什么，对应工作流需要什么依赖，Agent 是否真的连到了这项能力。它们出错时的表现可能相似，处理方向却不同。把所有失败都归到“模型没理解”，往往会在错误的位置反复尝试。

REA 是 Reverse Engineer Anything，通过 MCP 提供软件分析能力，同时提供 CLI。本文依据官方 6.4.0 资料讨论接入与复核方法，没有安装运行软件。文中的检查顺序是供读者在自己的环境中执行的方案，不是成功运行日志。

从目标类型决定依赖

JavaScript/Electron 静态分析、.NET 静态检查与原生二进制分析，不能用同一张依赖表笼统处理。官方说明中，前两类对应的静态工作流不要求先配置原生反编译后端。原生目标则按场景使用 Hopper、Ghidra 或 IDA，并受后端自身的环境与目标支持范围约束。

这一区分最直接的用途是缩小排查范围。研究自己的 Electron 打包产物时，先确认输入确实是要分析的构建，再看静态工作流返回的结构。若手里是原生程序，则应把后端是否可用放到前面检查，不能仅凭 Agent 能显示 REA 名称就认定分析条件已经具备。

官方要求的 Node.js 范围是 22.x 中至少 22.19、24.x 中至少 24.11，或 26 及以上。环境记录里应写出实际版本，避免“已经装了 Node”这种无法复核的描述。对团队来说，目标版本、运行环境和所选后端至少要能被另一台机器上的同事辨认。

配置计划与实际连接是两步

官方 setup 工作流允许先查看配置计划，确认后再写入，并保留备份。检查计划时，应该看它准备改哪个客户端、增加什么入口，以及路径是否属于当前环境。Windows、WSL 和远端开发环境里的相同路径字符串，未必指向同一份文件。

配置更新后需要重启相应 Agent 客户端。这里很容易产生一种误判：磁盘上的配置已经改过，当前会话却仍使用旧状态。排查时先确认正在使用哪个客户端与会话，再核对它实际暴露的工具，能减少重复修改配置的次数。

若团队同时保留开发版和日常使用版客户端，复现说明还应注明本轮选择了哪一个。先记录配置目标，再记录实际发起查询的会话；两者不一致时，优先纠正连接对象，不要连续安装依赖来碰运气。

我会把“计划已经生成”“配置已经写入”“客户端已经重新加载”“目标工作流可以调用”分别记下来。前一个状态不能替代后一个状态。即使每一步都看起来平常，这样记录仍有助于定位问题究竟发生在接入层还是分析层。

用一个已知目标检查分析链路

第一次验证不宜追求复杂。可以选择自己的小程序或已经了解结构的打包产物，把问题限定在一个功能上，例如导出文本前是否进行换行处理。已知目标的好处是有参照：返回内容偏离问题时，我们能判断是入口选错、线索不充分，还是解释超出了证据。

对于 Electron 例子，应分别看界面事件、preload 暴露的接口、IPC 消息以及主进程处理。这里是一种拆分问题的方法，不是声称每个应用都具有完全相同的结构。若某一层没有出现在材料里，应保留缺口，不能自动补出一条“常见实现”。

能找到写文件函数，只能证明存在相关代码。要把它连到某个按钮，还需核对调用与消息关系；要解释特定输入产生的最终文件，则需要进一步验证实际行为。把这三种问题分开，讨论中的分歧才有明确落点。

原生后端的界面能说明什么

项目文档中的这张图展示了 Hopper 对 /usr/bin/true 的分析，右侧有文件格式与架构信息，下方有分析输出。它能说明 REA 与既有原生分析工具协作的方式，但没有展示 Windows 或 Ghidra 的完整接入过程，也不能作为本文的运行成功证据。

排查原生目标时，我会先确认文件类型与后端选择，再处理具体查询。若更换后端，讨论记录也要同步注明。不同工具对同一目标形成的表示可能不同；仅比较两段文字是否相似，不足以判断哪份分析更可靠。更值得比较的是位置是否可追溯、调用关系有没有依据，以及未识别部分如何报告。

时间与内存边界要进入结果解释

6.4.0 的资料提到 JavaScript 分析的资源边界，以及保留大体量证据后再按需选择内容。实际交流中，这意味着不能只看“返回了 JSON”或“有一段摘要”。还应检查该轮工作覆盖了什么，哪些内容因为限制没有完成，摘要对应的原始材料在哪里。

一种可操作的记录方式是：原问题放在最前面，随后写已获得的线索、支持的判断和未完成的部分。下一轮只补与缺口有关的查询。这样即使某次分析停止，已经得到的材料仍有明确用途，而不会混在一份看似完整的结论中。

如果先后分析两个版本，还要把目标身份分开。否则很容易用旧版本的入口解释新版本的行为。对比前先确认输入，再看差异，远比看到函数名称相似就认定逻辑未变稳妥。

分享一个失败案例时，哪些信息最有用

有价值的讨论帖应描述预期分析什么、实际拿到什么、从哪一步开始偏离预期。保留相关错误与上下文，比只写“不能用”更容易得到帮助。同时删去与问题无关的敏感材料，避免为了复现一个路径问题交出整个私有项目。

本地后端与模型服务也需要分开看。后端读取本地文件，不保证传给 Agent 的工具结果始终停留在本机。准备分析自己的项目之前，应按客户端和模型服务的实际配置确定允许进入问答的材料范围。

本次选用 rea-agents-6.4.0 官方 Release 的源码 ZIP。该发行没有上传预编译安装附件，归档不包含子模块内容；它适合研究实现，不能替代完整环境准备。主仓库的 MIT 许可与所接后端工具的使用条件也分别成立。

项目参考：morluto/rea。如果要交流接入问题，建议从“目标类型、当前环境、连接状态、最小问题、实际结果”这几项开始。这样讨论能够定位到具体一步，而不是围绕一句笼统的“AI 逆向是否靠谱”打转。

源码资料

本次分享为源码归档，供阅读与技术研究。

百度网盘：https://pan.baidu.com/s/1tQSj1INJC7C28PvqO-y5tQ?pwd=srvi

提取码：srvi

夸克网盘：https://pan.quark.cn/s/d551e8dbc19d