一家软件公司的源代码还锁在自己手里，竞争对手却可能已经摸清了它的技术实现。

Notion没有公开桌面客户端的完整源代码，但研究者已经从它发布的安装包里，追出了复制粘贴功能的一条完整调用链。从页面发起请求，到进程间通信，再到系统剪贴板写入，每个环节都能找到具体的代码证据。

连一款1996年的Windows游戏DX-Ball，也被研究者借助AI拆开了。一个声音计算函数被重新写成C代码，经过3,205组原程序行为对照，最终连重新编译生成的63个机器码字节都实现了匹配。

这两项研究背后，都出现了同一个开源工具：REA。

它的全名是Reverse Engineer Anything，意思是逆向工程任何东西。开发者morluto将它开源后，项目迅速走红。截至2026年10月12日，GitHub已经积累了超过10万个Star。

REA最有意思的地方，是让Codex、Claude Code这样的AI Agent，可以调用专业逆向工程工具，研究没有源代码的软件，并尝试独立开发类似功能。

过去，软件公司花几年时间解决的技术问题，竞争对手可能需要重新摸索很久。如今，部分技术经验可能藏在它主动交付给用户的程序里，等着被Agent挖出来。

AI已经降低了写软件的成本，如今又开始降低读懂软件的成本。

这两股力量叠加，软件公司依靠技术实现建立领先优势的方式，可能发生根本变化。

但真正值得担心的，并不只是别人看懂了代码。

如果竞争对手已经能够以更低成本做出相似功能，软件公司究竟还有什么理由，让客户继续付钱？

先看Notion。

复制粘贴是软件里最普通的功能，却也是富文本编辑器里相当麻烦的工程问题。

Notion的页面由不同类型的内容块组成。一张表格包含行、列和单元格，一个文档可能同时存在文字、图片、代码块和嵌套结构。

用户复制这些内容时，软件需要同时考虑两个问题：普通应用能不能识别，重新粘贴回Notion以后，原来的结构还能不能恢复。

比如复制一张表格，粘贴到普通文本编辑器里，可能只需要保留文字。但如果粘贴回Notion，用户希望得到的依然是一张表格。

这就涉及剪贴板格式、内容序列化、跨程序兼容等一系列技术问题。

那么，Notion究竟怎么做的？

REA官方研究了Notion Desktop 7.6.1。

Notion桌面客户端使用Electron开发，界面和操作系统之间需要通过特定机制通信。研究者先从安装包中的Preload脚本入手，找到页面能够调用的clipboard.write方法。

沿着调用关系继续调查，发现这项操作通过ipcRenderer.invoke发出请求，再由主进程里的ipcMain.handle接收。

双方通过一条名为notion:clipboard:write的通信通道连接。主进程检查请求来源后，调用Electron提供的系统剪贴板接口。

原本藏在安装包中的代码，就这样被串成了一条清楚的功能调用链。

更有意思的是，研究者还结合另一批缓存的Notion Web模块，发现其结构化复制机制的一部分。

Notion可以把特殊标识放进复制的HTML，并在本地保存对应的内容块数据。重新粘贴时，如果标识能够匹配，软件就有机会恢复原来的内容结构；匹配不到，则使用普通文本和HTML。

需要说明，这些Web模块与桌面安装包来自不同版本，研究中的部分结果也依靠局部测试验证。整个案例没有复原Notion编辑器的全部运行逻辑。

但它已经展示了一个重要事实：商业软件即使没有公开完整源代码，部分实现机制仍然可以从已发布的程序中被研究出来。

对于准备开发富文本编辑器的团队，这样的发现很有价值。

过去遇到复杂功能，工程师通常查文档、读开源代码、搜索技术博客，再自己设计实现方案。现在，他们还可以研究成熟软件实际采用了什么方法，哪些细节值得借鉴。

类似的调查，也可能发生在本地搜索、文件管理、离线缓存、快捷键系统、数据转换等功能上。

当然，看到实现方式并不意味着可以直接复制受保护的代码。独立开发仍然需要考虑授权、兼容性和测试。

但研发团队至少多了一条获取技术知识的路径。

软件公司交付给客户的安装包，可能同时交出了一部分工程经验。

以前，这些经验要靠专业工程师花费大量时间才能研究。REA想改变的，恰恰是这个成本。

REA听起来很厉害，但它使用的底层技术并不新鲜。

逆向工程已经存在几十年。

Ghidra、IDA、Hopper等专业工具，早就能够分析编译后的程序，显示汇编指令、函数调用关系，以及部分还原出来的高级语言代码。

真正难的是理解。

一个软件可能包含几万个函数。经过编译、压缩或者混淆以后，原来的变量名、类型和程序结构可能消失。反编译工具能给出一大堆代码，却不会直接告诉工程师，用户点击某个按钮以后，究竟发生了什么。

研究人员需要自己寻找字符串、追踪函数、分析数据，再不断设计实验。

这项工作的门槛很高，经验也很难快速复制。

REA抓住了其中一个机会：把专业分析工具接入Agent，让AI参与组织调查。

它通过MCP协议和命令行工具，连接不同类型的分析能力。研究Windows、macOS等平台的原生程序，可以调用Ghidra、Hopper或IDA；研究Electron、JavaScript应用，可以检查模块结构和进程间通信；Android APK、.NET程序集、浏览器脚本等，也有对应的分析路径。

这些功能有不同的安装条件和支持范围，实际成熟度也存在差异。但对于编程Agent，它们可以被组织成一套连续的调查工具。

假设一家创业公司看中了竞争对手的本地文件搜索功能。

开发者可以让Codex研究这款软件如何建立索引、处理查询，以及怎样对搜索结果排序。

Agent先判断目标属于什么类型，检查安装包，寻找相关模块。如果发现关键逻辑藏在某个原生程序里，就调用反编译工具继续分析。找到可能的实现方案后，再设计测试，在允许的环境中验证实际行为。

最终，Agent可以整理出功能原理，编写一个独立的实现版本。

整个过程仍然可能遇到代码混淆、分析失败、缺少运行环境等障碍，需要工程师介入。服务器端的内部逻辑，也不会因为分析了客户端就自动暴露。

REA负责提供分析能力和证据，Agent负责选择调查路径，真正的产品开发仍然需要编程、测试和验收。

对开发团队来说，重要的变化是，以前必须由专家亲自操作的一部分调查工作，现在有机会交给Agent持续推进。

REA还设计了一套Evidence证据机制，记录分析对象、文件哈希、工具来源、代码位置、置信度以及尚未确认的内容。

这套设计很有必要。

AI善于把零散线索整理成一套看似完整的解释，但逆向工程最危险的事情，就是把猜测当成事实。

一段代码的用途判断错了，后面所有研究都可能偏离方向。一个常数读取错了，即使重新编译成功，程序行为也可能完全不同。

REA试图保留每一步调查的依据，让结果可以被复核、比较和继续研究。

如果把它安装到已有的编程环境中，基本入口是npx rea-agents setup，然后根据向导配置相应Agent和分析工具。具体可用能力取决于目标软件类型及本地工具环境。

这对于小型研发团队尤其有吸引力。

过去研究一个陌生的二进制程序，可能需要专门寻找逆向工程师。现在，普通开发者有机会在Agent帮助下完成部分初步调查，再把真正困难的环节交给专业人员。

AI开发的下一场效率提升，可能来自少走别人已经走过的技术弯路。

不过，能够找到代码线索，与真正复现软件功能，仍然隔着一大段工程距离。

DX-Ball的案例，很适合解释这段距离。

研究者想恢复一款1996年游戏的运行逻辑。其中一个函数负责根据砖块的横向位置，计算声音应该偏向左声道还是右声道。

第一次反编译，得到的结果几乎只有一个类型转换函数，看不出真正的计算过程。

Agent继续检查底层指令，找到调用者，恢复输入参数的含义，再读取程序内存中的计算常数，才把原始逻辑整理成能够维护的C代码。

这说明反编译的结果经常只是调查的起点。

更关键的是验证。

研究者让新代码与原始程序执行相同输入，逐步比较结果。确认函数行为后，还通过历史编译器检查最终生成的机器代码。

整个DX-Ball重建工程，截至2026年10月7日，已维护55个C函数，进行了45,380次原始程序对照，其中33个函数达成编译字节匹配。

这些成果来自REA、Agent、人工研究和专门测试工具的协作，游戏整体当时仍未恢复完成。

还有一个案例更能说明问题。

开发者N0zoM1z0在《东方永夜抄》的重建过程中，曾经遇到一个离谱的错误。

一个函数已经通过严格的编译结果对照，后来却发现道具自动收集功能行为异常。

原版程序判断玩家火力是否达到上限，使用的常数是128.0，重建代码却写成了0.0。

为什么测试没有发现？

因为验证工具比较了调整后的机器指令，却没有充分检查指令所引用的常数值。

修复以后，团队重新审计1,548处浮点常数引用，又找到12处错误，涉及5个此前已经通过验收的函数。

AI把代码研究出来了，验收系统却把错误当成了成功。

这件事值得所有使用Agent开发软件的团队警惕。Agent提高执行速度以后，验证机制如果跟不上，错误同样可能快速积累。

REA自身也仍然存在需要解决的工程问题。10月11日，社区发现其Electron分析会漏掉某些窗口实例，错误地报告零个窗口，相关问题当天通过代码修复并关闭。

所以，对于REA这类工具，不能只看它能分析多少种程序，还要看它如何保留未知情况、处理错误，以及用什么证据支持结论。

从商业角度，逆向工程的价值必须经过三道门槛。

第一道门是看得懂。竞争对手能不能理解某项功能的实现方式？

第二道门是做得出。理解原理以后，能不能以合理成本开发出可靠的替代功能？

第三道门是卖得掉。功能做出来以后，原来的客户为什么要转过来？

REA主要降低第一道门槛，也能间接帮助第二道门。第三道门的难度，往往被技术行业严重低估。

一家企业研究清楚Notion的剪贴板机制，距离抢走Notion的客户，可能还有十万八千里。

能拆开软件，不代表就能拆走生意。

但这不意味着软件公司可以高枕无忧。

因为不同软件的三道门槛，差别实在太大。

假设市场上有一家文件转换软件公司，核心功能就是把某种专业文件转换成另一种格式。

它已经经营多年，技术细节没有公开，产品依靠订阅收费。

如果竞争对手能够研究清楚文件格式和转换行为，再借助Agent开发出性能相近的工具，原公司的技术优势就可能迅速缩水。

更麻烦的是，这种产品往往没有太高的迁移成本。用户只关心文件能不能正确转换，至于背后是哪家公司，未必特别重要。

只要新产品足够可靠，价格更低，客户就有理由更换。

对这类软件来说，研发门槛曾经是一种重要保护。Agent如果持续降低开发和研究成本，这层保护就可能变薄。

当然，真正的竞争还涉及格式覆盖、兼容性、客户支持、渠道和品牌。一家看似简单的软件，也可能因为这些积累保住市场。

Adobe的情况复杂得多。

Photoshop拥有大量可以被观察和研究的客户端能力。图像处理、图层操作、文件读写、插件交互，都可能成为专业逆向工程研究的对象。

但要理解其中某个功能，与重新开发一个具备同等专业能力的Photoshop，完全是两回事。

长期积累的文件兼容性、性能优化、专业工作流和插件生态，都需要持续投入。对于设计师和企业来说，迁移也意味着培训、项目文件、协作习惯和交付风险。

所以，Adobe未必最害怕别人研究它的代码。

它更应该警惕的是另一种竞争。

假设一家电商企业每天需要制作上千张商品图片。过去可能需要设计师在Photoshop里抠图、修图、调整尺寸和处理背景。

现在，如果PhotoRoom这类产品能够通过AI更快完成这些任务，客户根本不需要等待一款完整的Photoshop替代品出现。

一个新的工作流程，就可能带走原来软件的一部分使用需求。

软件公司面临的竞争有两条路：有人研究它的功能，再做一遍；也有人改变完成任务的方法，让原来的功能失去价值。

REA代表了第一条路径上值得关注的工具。整个AI Agent产业的冲击，则同时发生在两条路径上。

Salesforce又是另一种情况。

企业CRM的前端功能可以被观察，客户资料管理、销售流程和报表等模块，也存在被独立开发的可能。

但Salesforce真正难以替代的部分，还包括企业多年积累的数据、复杂的权限关系、第三方系统集成，以及销售团队形成的业务流程。

一家大型企业不会因为出现一套更便宜的CRM界面，就立即把原来的系统扔掉。

迁移本身可能比软件订阅费贵得多。

但Salesforce同样面临第二条路径的压力。如果未来的Agent能够跨越邮件、日历、CRM和内部业务系统，直接完成客户跟进、信息更新和销售分析，一部分原来需要用户手工操作的软件功能，就可能被新的工作方式吸收。

这时，传统软件的竞争对手甚至未必需要开发同样的界面。

因此，判断一家软件公司的护城河，可以从四个问题入手。

核心能力有多少能够被外部观察？竞争者掌握原理以后需要投入多少资源才能复现？新功能是否容易通过测试证明足够可靠？客户迁移又需要付出多少成本？

四个问题都容易解决的产品，面临的同质化压力通常更大。

但也要注意，客户暂时离不开一个系统，与客户真心愿意持续购买，是两种截然不同的商业状态。

依靠复杂集成、历史数据和迁移风险留住客户，能够提供一定保护。长期看，企业仍然需要持续证明软件能够创造足够价值。

如果一家公司只剩下让客户迁移困难的能力，那些表面上的高续费率，也可能掩盖越来越严重的客户不满。

这里出现了一个更深的变化。

过去，部分软件公司可以靠技术领先赢得几年的时间。如今，Agent有机会缩短其中一部分研发差距。

于是，企业必须在竞争对手追上功能之前，建立下一层优势：更可靠的交付、更深入的业务场景、更完整的数据与集成关系，或者持续领先的产品体验。

代码写得复杂，可以增加模仿难度；生意做得扎实，才能增加替代难度。

而软件行业真正的利润，最终取决于后者。

REA最容易传播的场景，是看到一款喜欢的软件，让Agent研究它，再实现类似功能。

这种需求足够直观，开发者也很容易产生兴趣。

但从商业化角度看，真正愿意支付高价的客户，可能来自另一个市场。

大量制造企业、金融机构、医院和公共部门，仍然使用着十几年前甚至几十年前开发的软件。

有些系统的原始供应商已经消失，关键工程师离职，技术文档不完整，源代码也难以取得。

程序还在运行，却没人敢动。

例如一家制造企业，生产线上使用着二十年前开发的设备控制系统。现在准备更换硬件、升级操作系统，却发现旧程序与新环境不兼容。

管理者希望尽快改造，工程师却不敢轻易承诺。

因为没人能完整说明旧系统的内部逻辑。某个通信参数、异常处理规则或者文件格式理解错了，就可能造成生产停机。

过去，这类项目往往需要专门的逆向工程师、设备工程师和软件团队，花费大量时间研究原有程序，再逐步进行替代和验证。

REA所代表的Agent逆向能力，有机会降低其中部分调查成本。

在取得必要授权、建立适当隔离环境以后，Agent可以帮助梳理程序结构、分析数据格式、研究通信协议，并配合工程师设计新的兼容实现。

再通过原有系统和新系统的对照测试，逐步确认关键功能是否恢复。

涉及工业控制、医疗设备和关键业务时，安全性与可靠性仍然需要专业验证，无法依靠Agent的一份分析报告直接验收。

但这门生意的付费理由非常清楚。

客户花钱，是为了让旧设备继续使用、让系统平稳迁移、减少停机风险，或者摆脱已经无法维护的软件。

一款老程序可能早已没有技术上的新鲜感，却控制着价值几千万元的生产流程。

解决它的兼容与迁移问题，商业价值远远超过重新做一个漂亮的界面。

类似需求还存在于历史文件格式恢复、银行遗留系统迁移、专业仪器兼容、企业软件现代化等领域。

这些场景都需要理解既有程序，而且有明确的验收结果。

对于REA这样一种专业能力，可能比泛泛宣传“AI可以复制任何软件”更容易形成真正的企业付费。

当然，REA目前仍是一套快速发展的开源工具，距离大规模承担复杂企业交付，还存在可靠性、授权管理、部署环境和责任划分等问题。商业机会是否成立，也需要通过真实项目验证。

有趣的是，REA自己也绕不开软件护城河的问题。

它连接的许多底层工具早就存在，MCP接口也没有很高的独占门槛。其他团队完全可以开发类似的Agent逆向工具。

未来真正有可能形成积累的，是复杂程序的适配经验、可靠的证据体系、大量真实测试，以及企业级工作流中的安全性与交付能力。

一个帮助别人研究软件实现的项目，最终也要回答同样的问题：当竞争对手理解了它的技术，为什么客户还会选择它？

这个故事多少带着一点讽刺。

REA距离真正意义上的“逆向一切”，仍然有很远的距离。

它无法凭空获得服务器端代码和专有数据，也无法保证任何软件都能被完整复现。逆向研究还需要遵守相关法律、软件许可和授权边界。

但它代表的方向已经足够清晰。

过去，软件开发主要依靠工程师积累知识、阅读公开代码，再用自己的时间解决问题。现在，Agent开始具备系统研究成熟程序的工具条件，并可以把研究成果继续交给自动编程和测试流程。

部分技术经验的传播速度会加快，依靠实现细节建立的竞争优势，可能更难长期维持。

对于小型开发团队，这是扩大研发能力的机会。对于依靠技术领先收费的软件公司，则意味着需要重新计算自己的优势还能维持多久。

但即使竞争对手能够理解软件、复现功能，也未必能够赢得客户。

Notion拥有用户积累的知识和协作关系，Adobe拥有专业工作流和软件生态，Salesforce深度嵌入企业的业务系统。它们都有需要持续维护的优势，也都面临AI改变用户工作方式的挑战。

AI能拆开软件，却不能自动拆走客户。

真正危险的，是那些竞争对手研究完技术以后，发现除了这些功能，原来的公司已经没有多少值得客户留下来的理由。

过去，源代码可以成为技术领先的屏障。未来，更多软件公司必须回答一个更难的问题。

当别人也能做出同样的功能，客户凭什么继续付钱？