AI 能帮你复刻软件功能了?你最想做哪一个

Matthew Berman 在 X 上介绍 REA 时，配了一句“Software is done”。到 2026 年 10 月 13 日的资料抓取时，这个开源项目已获得超过 16 万颗 GitHub Star。“一键克隆”“闭源末日”也出现在围绕它的讨论里。Berman 原帖、项目仓库

REA 把研究现有软件的工具接给了编程 Agent。它可以帮助追踪某个功能，给出证据，再由 Agent 编写和验证类似实现。对使用者来说，期待很具体，看到一个好用的功能，能不能在自己的项目里做出一个版本？

这已经有局部案例，但解释一个函数、重建一个功能、交付一款完整产品，难度各不相同。官方展示的局部重建，恰好能帮助我们看清这段距离。

为什么它这么容易被转发

REA 的全名是 Reverse Engineer Anything，中文可以译作“逆向任何东西”。这个名字把一个专业工具，变成了人人都能产生联想的愿望。

看到软件里一个好用的功能，能不能弄清它怎么实现？旧程序没有源码，能不能找出某个错误？自己买的设备，能不能换一个更顺手的控制端？这些问题比“支持多少种二进制格式”容易传播得多。

开发者 jinglian 讨论 REA 时，就把注意力放在了空调、热水器等设备的通信协议上。他想借助分析 App、抓包和固件的工具，理解设备怎样接受指令，再自己写控制端。这条帖子说明了一种具体期待，该帖转述的应用成果仍需要单独核验。原帖

REA 又给这种期待提供了一个很短的入口。官方安装方式是一行 npx rea-agents setup，可以接入 Claude Code、Codex、Cursor 等常见编程 Agent。使用者沿用熟悉的提问方式，就能开始调用另一类工具。官方安装文档

我的判断是，这几个因素共同放大了它的吸引力。需求容易理解，入口容易转述，工具覆盖面很宽，再加上“软件要完了”的口号，技术讨论很快就变成了商业冲击的故事。

不过，一行安装命令只缩短了开始使用的路径。分析引擎的配置、问题的定义、结果的验证，依然需要有人完成。

Agent、REA 和反编译器，各自负责什么

REA 提供命令行工具和 MCP 服务。MCP 可以理解为编程 Agent 调用外部工具的接口。你使用的模型负责提出问题、选择下一步调查和解释结果；REA 组织分析操作、交付结果；Ghidra、Hopper、IDA 等引擎承担原生二进制的反汇编与反编译。

▲ 流程示意。Agent 决定调查方向，REA 组织调用并整理结果，人负责核对解释与重建结果。

假设你要调查自己有权分析的一款笔记软件，想知道它为什么把一条记录导出成两行。Agent 可以先查找导出相关的字符串，定位函数，沿着调用关系追踪，再检查换行和引号怎样处理。新证据会改变下一步该查哪里。

这样的调查，比让模型直接猜一段 CSV 导出逻辑更有依据。解释仍可能出错，但你有机会拿着函数地址、指令和引用关系回去核对。

不同目标需要不同准备。原生二进制的深入分析依赖相应引擎；静态 JavaScript、Electron 和 .NET 检查可以走无需原生引擎的路径；APK 和固件分析又有各自的工具依赖。支持列表中的每一项，都有自己的适用条件。官方能力与依赖说明

安装 REA，并不会自动补齐所有这些条件。软件的混淆、缺失的符号、间接调用和没有观察到的运行路径，也会继续影响分析结果。

看懂一个功能，已经有扎实的例子

官方 DX-Ball 案例调查的是一个很小的功能。砖块被击中后，游戏怎样根据横坐标，决定声音偏向左边还是右边？

▲ 项目方案例。3,205 个对照案例和 63 字节匹配，都针对这个局部函数，并有指定工具链条件。

最初的反编译结果只显示一个数值转换调用，连输入和前面的计算都没有表达完整。调查继续回到机器指令，找出了传入参数，又追踪调用方和常量，才重建出对应的 C 函数。

项目方报告，这个函数通过了 3,205 个原始 x86 输入案例的对照，并在指定工具链和重定位处理条件下，匹配了完整函数的 63 个字节。官方 DX-Ball 案例

这个结果的说服力，来自问题明确、范围有限，以及重建后做了核对。它也暴露了调查的难点。第一次得到的伪代码并不足以回答问题，Agent 还得继续取证。

Notion 的剪贴板案例展示了另一种用途。调查从页面侧的剪贴板接口出发，穿过连接页面与主进程的脚本和进程间通信，追到主进程中的处理逻辑。对于想理解某个功能的开发者，这种跨文件、跨进程的追踪很有帮助。官方 Notion 案例

但这些结果的范围都很具体。前者验证了一个声像计算函数，后者追踪了特定版本的剪贴板处理过程。它们没有证明 REA 能自动重建任意游戏或整款 Notion。

没人维护的老程序，能不能继续用下去？

还有一个值得尝试的正面应用，是那些仍在使用、却已经无人维护的老程序。假设原开发公司已经倒闭，源码和文档也找不到了，使用者最想解决的，可能是旧数据怎样导出，或某个计算结果为什么总不对。

▲ 应用设想。有权分析并完成行为核对后，局部结论才可能用于修复或迁移；不是已经跑通的企业案例。

REA 可以作为调查工具，帮助开发者从现有程序里查找相关功能，理解文件格式、计算规则或与设备通信的方式，再核对证据。搞清一小部分，就可能为修复、局部替换或迁移提供依据。官方也将软件保存、互操作，以及对自有或获授权软件的调试和审计列为预期用途。官方说明

这是一种应用设想。找回局部规则，距离接手整个旧系统仍有工程工作；程序依赖的环境、设备或服务端缺失，也不会自动补齐。改动应先在备份或测试环境中验证，并确认相应权限。

现有材料还没有证明 REA 成功接管了这类企业旧系统。更适合的第一步，是选一个有权分析的小功能，先把解释与真实行为对上。

带证据，仍然需要查证

REA 的一个重要设计，是把分析结果、来源、限制和未知项组织成可追溯的记录。已有记录还能作为后续比较和查询的输入，让调查能够继续追问。

官方协议里有一个很实用的限定。如果调用关系的检查覆盖不完整，返回一个空列表，并不能证明这个函数没有调用其他函数。过大的结果也要通过分页或导出继续读取，不能把看不到的部分当作不存在。官方 MCP 合约

这会影响结论怎样写。查到一条调用路径，可以说明在相应证据中发现了它；没有查到，就要继续区分到底是确实没有，还是分析没有覆盖到。

证据记录也无法替代事实判断。银栋梁的源码分析指出，记录的哈希能检查内容与引用是否一致，却不能独立证明分析真的执行过，更不能证明模型的解释正确。源码分析

可追溯的结果，让错误更容易被发现。 要做到这一点，使用者仍得检查原始证据，并验证那些会影响后续决策的结论。

一份对照评测，给热度补上了基准

GitTested 于 2026 年 10 月 9 日进行的测试，使用 REA 6.2.0、Sonnet 5.5 的 medium 配置，以及 Linux arm64 和 Ghidra 12.1.4，分析四个不超过 264 KB 的去符号二进制，也就是去掉函数名称等符号信息的二进制程序。

15 道原生问题按事先从源码确定的事实评分，共有 75 个检查点。普通命令行工具组得到 74 分，强制使用 REA 的组得到 73 分。五项函数重建任务，两组都通过。REA 组的 token 消耗中位数约为前者的 2.5 倍，按该评测的计费估算，成本约为 1.5 倍。token 是模型处理文本的计量单位，实际费用还会受到缓存等计费条件影响。GitTested 原始评测

▲ 公开评测数据重新绘图。小样本没有观察到准确率提升，token 与估算费用增加；并非本次亲测。

这组小样本没有观察到更高准确率。普通工具已经接近满分，给 REA 留下的提升空间很小；同时，增加工具和上下文也增加了消耗。分差不足以支持谁更强，更不能外推到所有大型程序。

这个比较提醒我们，工具的意义要放回具体任务里。对于 Agent 已经能用普通工具回答的问题，再接一套分析工具，收益可能有限。复杂目标是否能从统一入口和证据管理中受益，还需要更有代表性的测试。

这是公开评测的结果，本次资料整理没有复现实验或审计它的逐轮日志。官方成功案例与有限对照测试，都不足以给出一个通用的“逆向成功率”。

闭源产品的边界在哪里

拿到安装包，能分析的是其中携带的代码、资源和可观察行为。客户端没有携带的服务器实现，无法直接从客户端反编译出来。 网络请求能提供输入与输出线索，也无法直接交出服务器内部的源码。

这使“克隆一款软件”变成了几个不同的问题。相似的界面可能做得出来，某个本地算法可能重建出来，服务端行为也可能通过有限观察加以模仿。但完整的数据、账号体系、异常处理、性能和持续运维，仍需要另行建设与验证。

功能实现越依赖本地代码，越值得检查它是否容易被理解和重建。依靠数据、服务能力或用户关系形成的优势，则需要另外评估。REA 给软件开发者增加了一个分析工具，也增加了一个审视自己产品的角度。

使用成本和权限同样要算清。REA 自有代码采用 MIT 许可，模型调用与商业分析引擎仍可能产生费用。项目的许可也不会替目标软件授予新的权利。官方明确不支持绕过 DRM、授权检查或复制专有代码与资源等用途。许可说明、官方免责声明

隐私还有一个容易漏看的地方。REA 在本地分析，外部 Agent 却会接收工具结果；反编译文本、字符串和路径等信息，可能随模型请求离开设备。内部软件能不能拿来分析，需要同时检查目标权限和模型的数据处理政策。官方 FAQ

对于准备尝试 REA 的人，适合的起点是一个自己有权分析、知道正确答案的小程序或局部功能。先确认问题能否被回答，再考虑扩大范围。

▲ 编辑整理。先确认问题、出处和对照验证，再讨论是否值得扩大分析范围。

验收时，可以只盯住三个问题。

• 结论能否对应到本次取得的函数、字符串、指令或行为记录？
• 报告是否说清检查范围，还有哪些部分没有观察到？
• 根据结论写出的实现，是否用明确的输入和边界条件做过对照？

这三件事走得通，REA 就有了可以讨论的实际价值。它能让更多开发者开始调查软件、追问实现，再把有限的结论用于自己的工程工作。具体能走多远，要由问题、证据和验证共同决定。

信息来源

• REA 官方仓库与文档
• 官方 DX-Ball 案例与Notion 案例
• GitTested 原始对照评测
• 银栋梁的固定版本源码分析
• Berman 原帖与jinglian 原帖