REA：当 Agent 开始理解没有源码的软件

本文基于 REA 官方项目文档与仓库源码撰写，属于技术观察。我尚未亲自使用 REA。文中的调查过程是说明方法的假设示例，不是实测记录。本文讨论的是查阅时的仓库内容；仓库主分支与已发布软件包可能存在能力差异。

从 REA 说起：为什么逆向工程项目会引起 Agent 开发者的关注？#

给 Agent 一个开源项目，它可以搜索代码、阅读文档，沿着函数调用寻找答案。但如果问题变成“这个没有源码的应用，搜索功能是怎样工作的”，常用的阅读路径就中断了。

软件仍会留下线索。安装包里有文件和资源，二进制程序里有指令和字符串，运行中的应用会对输入作出反应。困难在于，这些线索不能像一份设计文档那样直接阅读，需要借助专业工具提取、关联和解释。

REA（Reverse Engineer Anything）尝试提供这样的工具入口。它通过 MCP 向 Agent 暴露分析能力，项目文档列出的目标包括原生二进制、JavaScript 与 Electron 应用、网站和 .NET 程序等。Agent 可以提出问题、调用工具、读取结果，再决定是否需要继续追踪。REA 项目说明 · 支持的目标与前提

这也是它对 Agent 开发者有意思的地方：Agent 不再只能处理已经整理成文字的知识，还可以尝试借助工具，从原始程序和行为中获取材料。当然，能获取材料与能理解软件，是两件需要分别验证的事。

没有源码，Agent 如何理解软件？#

逆向分析常用的几种方法，回答的是不同层次的问题。

反编译把机器指令转换成较易阅读的伪代码。它能帮助分析者判断某段代码可能在做什么，却无法保证恢复原作者的变量名、模块边界和设计意图。伪代码看起来像源码，本质上仍是工具根据现有信息生成的解释。

静态分析不运行目标，而是检查程序文件本身：函数、字符串、引用、模块依赖、资源或进程间通信入口。例如，REA 的原生分析流程可以先列出函数，再针对某个地址查看指令、伪代码和引用；JavaScript 与 Electron 分析则侧重模块及其关系。原生程序分析文档 · REA 项目说明

运行时观察关心程序在特定条件下实际发生了什么。一次网络请求、一个进程输出或一次界面交互，都可能帮助验证静态分析形成的猜测。但观察只覆盖当时的环境、输入和路径。没有看到某个行为，不能直接推断它永远不会发生。

假设我们要研究一个应用的搜索功能：静态分析可能找到输入框对应的模块和调用路径；运行时观察可能显示输入关键词后出现了网络请求。两者放在一起，可以支持“某次搜索涉及远端请求”的判断。它们仍不足以证明所有查询都走远端，也未必能说明请求返回后每一步如何处理。真正有用的解释，要连同这些限制一起给出。

REA 是如何实现的？#

从仓库结构看，REA 有命令行和 MCP 两类入口，它们连接到共享的分析流程；下层再由适配器与 Ghidra、Hopper、IDA 等原生分析器，以及其他目标类型对应的工具交互。这样的设计让 Agent 面对的是“检查目标”“分析函数”“追踪引用”等操作，而不是每次都从头处理不同工具的接口。REA 架构图源码 · REA 工具设计文档

图 1｜REA 将专业分析工具接到 Agent 的调查流程中；工具返回证据、覆盖限制与未解问题，Agent 再据此选择下一步。作者绘制，点击图片可查看大图。

MCP 在这里负责连接工具和传递结果。它本身不会替 Agent 选择研究问题。REA 提供了引导式调查提示，例如追踪功能、比较应用版本和核查重建结果；项目文档明确说明，这些提示给出起点，不会自行调用工具。实际调查仍要根据目标、已有证据和下一步问题作出选择。引导式 MCP 工作流

REA 更有价值的一层，是把证据作为结果的一部分。其 MCP 契约要求分析工具返回结构化结果和 Evidence 标识，并保留分析配置、原始结果或规范化结果等信息。相关流程还记录覆盖范围、局限与尚未解决的问题。比如调用图只覆盖已成功读取的关系时，空结果不能被当作“这个函数没有其他调用”。MCP 结果契约 · 证据工作流

这让后续判断有机会回答一个关键问题：结论究竟来自程序中的哪项观察，还是来自模型自己的推断？

从工具调用到自主探索#

如果 Agent 只调用一次反编译工具，然后把返回的伪代码改写成一段流畅描述，它完成的是信息转述。未知软件的研究通常要多走几步。

仍以搜索功能为例，一个可能的调查顺序是：先找入口，再沿调用关系定位处理逻辑；根据结果提出“本地检索”或“远端检索”的假设；随后寻找能区分两种解释的证据。如果发现静态路径不完整，就记录缺口，而不是凭熟悉的代码模式补齐故事。这里描述的是一种调查方法，并非我的 REA 使用经历。

REA 的证据工作流支持记录未解决的问题，并要求在比较与验证时保留证据来源和覆盖限制。它也提醒使用者：静态差异是行为变化的候选线索，匹配到的模式并不自动证明因果关系。证据工作流

我倾向于把这种能力称为有工具支持的探索。专业工具扩大了 Agent 能接触的材料范围；Agent 是否选对下一步、是否愿意修正假设，仍是独立的问题。返回更多数据，不一定会带来更可靠的答案。

理解、复现与重建：数据库的边界#

一个没有源码的软件，也不一定只有一个可分析的程序。今天常见的应用把界面和部分逻辑放在客户端，把账户、业务规则、数据与模型服务放在远端。逆向客户端之前，应该先问：想知道的信息究竟位于哪一侧？

图 2｜客户端分析可以帮助理解或复现部分功能；完整系统还涉及未交付的服务端实现、数据和授权。作者绘制，点击图片可查看大图。

本地数据与云端数据的区别尤其明显：

数据所在位置	客户端分析可能得到什么	主要限制
本机 SQLite 数据库	在有权访问且文件可读时，可检查本地快照的表、字段和选定记录	加密、访问权限与不一致的实时副本可能阻止或误导分析
浏览器或 Electron 使用的 IndexedDB	可能检查这台设备上保存的结构化数据	只代表本机、对应用户与已同步到本地的内容
随安装包分发的数据文件	可能识别并提取包内资源	包内没有的数据无法从中恢复
云端数据库与完整用户数据	客户端请求和响应可能透露部分字段与业务流程	仅凭客户端不能获得远端数据库、完整表结构或未返回的数据

REA 文档给出了检查明确选定的本地 SQLite 快照的工具，并要求注意数据库与 WAL 的一致性及返回结果的覆盖范围。IndexedDB 则是客户端存储机制；本机存有某些记录，不意味着它保存了服务端的完整数据。REA SQLite 数据库快照文档 · MDN：IndexedDB 基本概念

设想一个 AI 笔记应用：桌面客户端负责界面、输入和本地缓存；请求经由 API 到达服务端；服务端再处理身份验证、笔记存取和 AI 任务。对客户端的合法分析，可能揭示它发出了哪些请求、怎样处理返回值，以及某些数据如何缓存在本机。即使观察到 /api/notes，也不能据此知道服务器的源码、数据库所有表、尚未返回的笔记，或模型内部如何实现。已有网络记录可以帮助描述观察到的接口行为，但请求格式不是完整的服务端契约。REA 网络记录分析文档

所以，“理解软件”至少要分成三个目标。

理解一个功能#

如果问题是“搜索按钮如何触发请求”或“富文本编辑器如何组织本地状态”，客户端代码与行为可能已经提供足够线索。结论仍应限定在实际检查过的版本、路径和输入上。

复现类似功能#

开发一个具有笔记搜索、分类和标签能力的新应用，未必需要原软件的数据库。可以根据合法可观察的行为整理需求，独立设计自己的数据模型和后端，再用明确的测试场景比较功能表现。这样得到的是新实现，不是恢复原系统。

重建整个系统#

如果目标包括原有账户、数百万条独有数据、云端业务规则或专有模型，仅靠客户端通常无法完成。即使推测出一个合理的表结构，也没有因此获得表里的数据。REA 扩展了 Agent 可观察和分析的范围，不能让从未进入客户端的信息凭空出现。

这三个目标的验证强度也不同。伪代码可能足以提出实现思路，却不足以证明边界条件正确；几次运行结果能验证这些输入，却不能覆盖所有路径。REA 的重建验证文档将结论限定在声明的可比较范围内：推断不能冒充实际观察，局部通过也不等于整个产品等价。重建覆盖范围说明 · 证据工作流

还有操作与权利边界。读取程序文件、运行程序、捕获流量和操作设备可能需要不同的授权；拥有一份软件文件，不意味着可以进行所有形式的分析或使用所得结果。REA 项目自己的责任使用说明也提醒使用者核查权限、目标程序的权利，以及分析结果的准确性。REA 责任使用说明

因此，“理解”最好落实到具体问题：解释了哪个功能？依据哪些观察？哪些路径与数据不在视野内？如果开发新实现，又用什么测试验证它？

关于 Agent 能力扩展的一些思考#

过去，我们主要让 AI 阅读已有的源代码、文档和知识。REA 展示了另一种可能：当信息并不直接可读时，Agent 能否借助专业工具主动寻找证据，并逐步建立对未知系统的理解？

从目前阅读的文档和源码看，REA 为这条路径提供了几块基础：不同分析器的适配、可供 Agent 调用的操作、可追溯的结果，以及对覆盖不足和未知问题的表达。它没有消除调查中的判断工作。相反，当 Agent 获得更多工具，区分观察、推断和未知会变得更加重要。

这也是我目前对 REA 最感兴趣的角度。它不需要被证明能“自动理解任何软件”，才值得研究。更实际的问题是：在范围清楚、授权明确的任务里，Agent 能否说清自己理解的是客户端的一条流程、一个可复现的功能，还是整个系统；又能否指出哪些服务端实现与数据始终不在视野内？这要等具体使用后才能进一步评价。

资料来源#

资料查阅日期：2026 年 10 月 19 日。

JaisonG1n