REA让Agent读懂成品软件：逆向分析的瓶颈移到了哪里
10月22日，作者哈密在人人都是产品经理发布了使用REA拆解腾讯WorkBuddy客户端的文章。作者把提示词模板、运行流程和安全规则作为调查对象，尝试解释一款桌面Agent的工程设计。这把一个具体问题摆到了产品团队面前：拿到发布包后，哪些设计可以看懂，哪些能力仍须实际验证。作者拆解文章
截至10月23日核验，REA已经通过MCP连接多种逆向分析工具，并支持应用代码与运行行为分析。MCP是Agent调用外部工具的接口。REA的主要价值，是让Agent围绕一个具体功能，连续寻找证据、提出解释，再交给可执行的检验。 工程师可以把“这段程序为什么这样算”交给Agent调查，但能否采用它恢复的实现，仍要看验证结果。项目说明
反编译工具早已存在，Agent接手的是连续调查
WorkBuddy拆解报道提供了一个比功能截图更深入的调查对象。
作者声称定位到了提示词模板与控制规则，但这仍是第三方对客户端的分析，不能直接当作腾讯对内部架构的确认。读取一条“操作前须确认”的规则，可以帮助形成待测假设；它能否在模糊指令、工具失败或多轮操作中持续生效，还要看执行路径和实际结果。
10月20日，公众号字母AI从产品防护角度报道了REA，讨论客户端能暴露什么、哪些信任判断应留在服务端。两篇近期文章把同一问题的两面摆了出来：分析者希望读懂设计，开发者需要判断哪些实现可以公开。要回答双方的问题，都必须把文件里看见的规则与系统真正执行的行为分开。字母AI报道
REA解决的问题，出现在得到反编译结果之后。Ghidra早已具备反汇编、反编译、程序图和脚本能力。反汇编把机器码转为处理器指令，反编译则尝试恢复为便于阅读的高级语言。工程师有了这些工具，仍须判断从哪里查起、哪些变量可信，以及下一步应该检查哪个调用者。Ghidra官方说明
同一个“导出”按钮，可能先经过界面代码，再跨进程传递参数，最后调用本地库或远端接口。单独读懂一个函数，未必能解释用户看到的结果。过去需要分析人员在这些层之间保持线索，分辨哪些关系来自代码，哪些只是猜测。
REA让Agent通过同一套接口查询函数、指令、引用和相关文件。Agent可以依据上一步返回的证据继续追问，命令行工具CLI也使用相同的工作流。这里减少的是工具之间的手工衔接，以及每次查询时重新交代上下文的负担。它依赖底层分析引擎的能力，也继承那些引擎无法恢复的信息。原生分析文档
此前的DX-Ball案例说明，连续调查为什么比一段漂亮的伪代码更重要。DX-Ball是一款1996年的Windows游戏。反编译器最初把目标函数呈现为无参数函数，只显示一个转换调用。Agent随后检查原始指令，发现栈上的整数输入，再沿调用者确认其含义，并读取计算常数。恢复的C函数接受了3,205组行为比对，还通过了63字节的编译结果核对。验证针对这个函数成立，整个可玩游戏当时仍在重建。函数还原与验证
这个案例支持一个具体判断：Agent有机会承担发现矛盾、追查依赖和提出实现的工作。它没有证明自动生成的解释天然可靠。恰恰因为第一份伪代码漏掉了重要信息，原始指令和原程序才成为不可省略的参照。
从一个页面方法追到系统调用，才算解释了功能
REA在应用层的价值，是把分散在不同文件和进程里的实现接起来。
官方Notion案例以桌面版7.6.1的应用包为对象，追踪复制功能：页面调用一个剪贴板方法，预加载代码通过IPC发送请求，主进程检查发送者后，再调用Electron写入系统剪贴板。IPC指进程之间传递请求和数据的机制。Electron是用于构建桌面应用的软件框架。Notion案例
这条路径回答了“复制在哪里完成”，也说明为什么只看页面方法容易误判。方法名可以被包装，实际动作可能位于另一个进程。追到接收端，才能区分谁负责传参、谁检查来源、谁真正执行操作。工程师由此得到的是一个可以逐段核对的解释，而非仅凭功能表现写出的相似实现。
REA的JavaScript工作流为这类调查保留模块关系和证据位置。文档还明确区分静态文件观察、运行时观察、推断关系和未知项。调用路径来自静态图时，它说明代码怎样连接；是否在某次操作中真正执行，仍需要运行观察。两种材料互相补足，不能互相替代。应用追踪文档
这一点也决定了REA与已有工具怎样比较。下表按“解释一个具体功能需要什么证据”对齐，它比较的是工作分工，没有性能排名。
| 路线 | 主要取得什么 | 解释功能时还缺什么 |
|---|---|---|
| Ghidra等静态分析工具 | 指令、伪代码、引用与程序结构 | 需要继续定位业务含义，并检验执行行为 |
| Frida动态插桩 | 在运行过程中追踪函数和观察数据 | 结果受触发场景影响，仍需解释相关代码 |
| 浏览器观察 | 页面、脚本及网络活动 | 客户端观测不到的服务端实现仍不可见 |
| REA配合Agent | 组织查询、关联多层材料、继续追问 | 受底层工具和证据覆盖限制，恢复实现仍需测试 |
Frida本身就支持运行时函数追踪和可编程插桩。REA的浏览器工作流也围绕选定页面收集观察。因此，REA应当用“是否减少完成一次调查所需的人工工作”来检验价值。仅看工具数量，无法判断它比熟练工程师现有的脚本更有效。Frida官方文档、REA浏览器观察文档
能拿到的代码，决定Agent能够解释到哪里
REA的适用边界首先由软件部署位置决定。
本地程序包含某段计算，分析工具才可能追到这段实现；客户端只负责发送请求时，客户端代码最多解释请求如何构造、响应如何处理。把更多分析工具接进Agent，不会自动增加服务端源码的可见性。
这对金融Skill尤其容易造成误解。假设一个投研Skill在本地接收问题，然后把问题交给远端研究服务。拆解本地脚本，可以确认它增加了什么约束、调用哪个接口、怎样整理返回内容。要判断远端如何选择研报、计算预测或形成结论，还需要服务端材料，或通过受控调用检验其行为。这是由程序分布位置推出的边界，不能从一次客户端检查推导出机构内部算法。
相反，如果一个历史分析程序把计算逻辑保存在本地库中，逆向调查就可能帮助解释某个异常结果。工程师可以固定原程序、输入和环境，恢复一个小函数，再比较原实现与新实现。在这类任务中，REA提供的代码位置和调用关系能直接转化为测试对象，证据与工程产出之间的距离较短。
同样需要警惕“没找到”的含义。REA文档说明，查询结果的分页结束，不等于未完整分析的应用中不存在相关代码。原生静态路径也不等于运行时一定可达。Agent如果把局部扫描写成全局结论，报告越流畅，越容易掩盖覆盖缺口。应用覆盖说明、原生追踪边界
由此可以推断，逆向分析的自动化会改变人工复核的位置。工程师可以减少亲手执行每次查询的时间，把注意力放到关键假设和验证设计上。这个收益尚不能量化：现有公开案例展示了可行路径，没有给出与人工、其他Agent方案在同一任务下的耗时、成本和错误率比较。
下一步看：换一个版本，结论还能否经受检验
REA能否用于持续维护，要看它怎样处理新版本和未见输入。
官方CLI文档已经提供分析快照机制，复用结果需要目标字节、操作、参数、引擎与设置匹配。这个约束提醒工程团队：一份分析结论应当属于具体程序及条件，文件名相同不足以证明实现相同。CLI与证据文档
更有说服力的下一步验证，是让Agent在一个范围明确的维护任务中工作。例如，先解释旧版解析器怎样处理边界输入，再检查新版是否保留相同行为。评估时同时记录调查时间、人工介入、漏掉的分支，以及恢复实现与原程序的差异。这样才能区分“更快写出解释”和“更快完成可靠维护”。
一个关键的反证也在这里：如果熟练工程师用现成工具更快定位问题，或者Agent需要大量人工纠正，REA在该任务上的采用收益就会缩小。若程序的关键逻辑始终在远端，继续增加本地分析深度也无法回答核心问题。应当先确认任务是否存在可获得、可验证的实现，再判断自动化能节省多少工作。
公开案例支持的一项意义，是REA让Agent有了一条沿成品软件追查实现的工作路径。公开案例把这条路径推进到了函数还原和行为核对。要扩大到复杂软件的维护与迁移，还需证明它能稳定识别未知项、保留决定性证据，并在变化后的程序上继续通过检验。接下来应关注的成果，是更多可复现的维护任务，以及完成这些任务需要多少人工。
资料核验日期：2026年10月23日。入口是10月22日的作者报道，DX-Ball用于历史比较。WorkBuddy客户端拆解属于作者陈述，官方案例结果来自项目方记录；本文未独立复跑这些实验。