REA 到底解决什么问题

我们想理解的是软件，不是一段漂亮的解释

一个桌面工具没有完整源码，你想知道它怎样处理剪贴板；一个本地 SDK 升级了，同样的输入却得到不同结果；仓库里的修复已经合并，安装包的行为仍然没变。这些问题有个共同点：关键事实不完全在你手里的源码和文档中，而在实际的软件产物或运行过程里。

过去，这通常需要工程师拆包、搜索字符串、看反编译结果，再用操作和测试逐步核对。现在大模型能读代码、解释伪代码、整理调查步骤，看上去似乎可以接手不少工作。但新的问题也随之出现：一段解释读起来很顺，究竟是因为模型找到了证据，还是因为它很擅长把缺口补成故事？

REA（Reverse Engineer Anything）值得研究，就在这个交叉点上。它是一套面向 AI Agent 的逆向工程工具系统：让 Agent 能调用专门的分析工具，接触实际产物和选定的运行观察，再围绕这些材料继续调查。

本章先建立整体认识：它解决什么问题，AI 与工具怎样分工，为什么分析之后还需要验证。具体类名、参数、命令和输出留在后面的深读与实践章节，不要求你先记住一张工具清单。

逆向不是把编译倒放一遍

这里的“产物”，指的是已经构建或发布出来的文件：打包后的 JavaScript、桌面安装包、原生动态库、命令行程序等。逆向工程从这些文件和可观察行为出发，反推结构、接口或某段实现。

任务不一定是“还原整个软件的源码”。找出一个按钮连接哪些模块、确认本地库怎样处理一个参数、弄清两版命令的结果为什么不同，都可能是更有价值、也更容易验收的目标。

不同材料能回答的问题也不同。JavaScript 解析可以帮助找到模块和静态关系；原生反编译器将机器指令整理成便于阅读的伪代码；运行观察能记录某个环境里实际发生的事情。它们之间需要相互核对。尤其是反编译，并不能自动找回已经丢失的注释、变量名、类型和原始模块结构。

所以研究 REA，不应只问“支持多少种文件”，还要问：我现在缺的事实是什么，哪条工具路径能取得它，拿到之后怎样判断解释对不对？

为什么不能只把文件和日志交给大模型

大模型擅长连接语义：把用户的问题拆成步骤，在材料中寻找线索，解释陌生代码，并提出候选实现。这些能力对调查很有帮助。

但它不会因为一个字符串像接口名，就自动知道这次操作调用了哪个函数；也不会因为伪代码看起来合理，就保证其类型和错误语义准确。没有相应工具时，模型甚至无法取得某些材料，只能在已有文本范围里分析。

逆向中的危险，往往来自一次没有说明的跨越：从“产物里存在这个字符串”，跳到“用户这次操作执行了这里”；从“两个版本结构不同”，跳到“这就是故障原因”。解析器和模型各有难题，不能把前者视为早已彻底解决，也不能让后者的流畅表达替代证据。

REA 的价值，是尝试让这条调查链更容易被程序调用、继续查询和复查。它不使模型天然正确，但可以让模型少一些只能靠猜的地方。

REA、大模型和宿主，分别在做什么

可以把宿主 Agent 理解为组织调查的工作台。模型负责解释与选择；Harness 是工作台中推进循环、管理上下文、权限和预算的运行部分。REA 则接在工具层：验证请求、固定目标、组织分析，把结果和来源交还给宿主。

真正解析字节或取得运行材料的，是解析器、反编译引擎和观察器。REA 将这些不同能力接到共同的工具接口上，但不会消除它们的平台要求、工具差异和专业判断成本。

这个分工带来一个容易被名称掩盖的事实：REA 的静态分析可以在没有模型参与时运行。 解析、建关系图、计算哈希、封装记录都不是模型生成的文字。CLI 是终端调用入口；MCP 是宿主与工具服务交互的协议入口。模型位于分析工具之外，通过宿主决定下一步。

如果把它与熟练工程师直接使用传统工具比较，变化主要在协作方式：人原来亲自完成的工具调度、材料整理和下一步选择，可以部分交给 Agent。传统工具也可能有脚本、插件、项目数据库和审计记录，不能说这些能力由 REA 首次创造。更准确的研究问题是：REA 的统一契约、目标绑定和未知记录，是否让特定的人机协作任务更容易完成和复查？目前的小样本不能回答普遍提效多少。

相关依据可从固定源码的运行入口、工具契约与工作流说明继续核查。

一次调查，怎样从问题走到有限结论

先明确一个具体问题和允许调查的目标；宿主选择工具，REA 校验请求并组织分析；解析器或观察器取得材料，形成带来源和限制的 Evidence。Evidence 可以理解为可追查的分析记录，而不是替调查者担保的“正确答案证书”。

随后，模型根据材料提出解释，决定继续查询哪里，或者编写一个待验证的兼容实现。最后必须把解释或实现放到明确的输入、环境和验收条件下检查。验证不通过，就回到假设和材料；证据不足，也可以以一份写清未知的调查报告结束。

这条链里有三项常被忽略的设计：

• 结果绑定到目标。 需要知道分析的是哪一份文件、哪个版本、什么参数，不能把另一版本的材料接到当前解释上。
• 失败与覆盖要留下来。 只取得部分观察时，不能交给模型一份看起来完整的成功结果；模型读完一组分页，也不等于工具分析了全部程序。
• 解释接受独立验收。 模型提出的规范、实现和测试彼此一致，仍可能一起偏离目标。验收依据需要与候选解释区分。

第二章会沿源码展开这条链；第三章再讲每种材料究竟能支持什么声明。

一次小样本，让“说不知道”变得具体

本专题已经完成一轮自有 JavaScript 样本分析与行为对照。Mac 上启动分析失败，Linux 上同一固定发布版完成了解析；返回形状比较给出了 changed: 0，同时保留 unknown: 1。

这个结果最有教学价值的地方，不是“工具很聪明地找到了故障”，而是它没有把不能确定配对的返回形态擅自写成删除或无变化。调查者还要阅读相关位置、核对样本源码，再用事先约定的行为测试检查。只摘出三个零，会漏掉重要材料；把那个未知直接改写成工具已证明根因，同样过头。

具体命令、失败记录、输出和测试在实践章，配对含义在证据章。它是事先知道答案的白盒练习，不是独立恢复未知应用的成绩。这个小实验只承担解释方法的任务，不作为六章的贯穿案例；完整应用案例仍留待后续选题。

对工程开发有什么用，又不适合替代什么

REA 更值得考虑的任务，是要取得的事实确实缺在当前仓库之外：核对实际发布包、理解外部本地组件、调查授权桌面功能、比较命令行行为，或整理兼容实现所需的协议与样本。

若拥有完整源码，问题就在业务计算或普通数据查询里，先用搜索、断点、日志和测试通常更直接。REA 也不是通用沙箱、生产性能诊断平台，或自动保证任何软件都能被复制的产品。具体工具家族与载体前提集中放在工程用途与能力参考，不在这里逐项铺开。

接入之前还要考虑代价：引擎准备、平台兼容、模型请求、人工复核与独立验证。本地解析不代表工具结果不会交给远端模型；实际执行目标，也不能因为通过了 Agent 就自动变安全。第六章会把这些要求落到接入判断。

怎样读完这个专题

第一次阅读，可以按“问题与分工 → 系统怎样取得材料 → 结论怎样验证 → 工程用途 → 实践 → 接入”顺序走。你不需要在第一遍记住所有名称，只要能解释每一环为什么存在。

需要深入或让 AI 协助复查时，第二章保留实际文件与调用关系，第三章保留字段、规则与反例，第五章提供命令、代码和结果对照，第六章提供接入前的任务边界。它们是同一套知识的不同深度，不是“给人看的故事”和“给机器的另一套真相”。

本专题的长期主线是：面对没有完整源码的软件，怎样借助 REA 和大模型，从产物与行为中理解一个功能，再验证这种理解是否可靠。

版本与研究范围：源码阅读固定在 2026-10-13 的 d13c9f84；实跑固定使用发布提交 a56f7bb6 对应的 rea-agents@6.4.0。两棵源码树不同。2026-10-14 的小样本不能扩写为原生引擎、完整应用或实际 MCP 集成均已验证，也不能据此声称普遍提效或独立逆向正确率。