技术 · 熟练
这段代码到底在干什么，谁去查？
工具负责取证，agent 只负责推理
逆向工程缺的一直不是智力，是体力 —— 反汇编、跟调用、把算术拼回去，占掉九成时间。2026 年 10 月公开的 REA 这类工具把这件事拆成两半：工具负责收集 agent 自己拿不到的证据（例程的指令列表、反编译代码、函数之间的调用关系、网页真正加载的那份脚本），agent 只负责推理（哪条代码路径在跑、算什么、要怎么改或重做）。门槛因此从「会用反汇编器」降到「会提问」。这一页给的是这条分工的落地顺序、留下的证据形态，以及两条不能省的前置：先确认你有权分析这个目标，再用一个自己能核对的小例子校准它。⚠️ 它的公开示例是精选演示 —— 真正好不好用，取决于 agent 能不能读懂更脏的目标。
方法 · 一图看懂
1
把「取证」和「推理」分开 — 取证交给工具（可复现、可核对），推理交给 agent；两者留下的东西不是一回事
2
取证要拿到 agent 自己拿不到的东西 — 指令列表 / 反编译结果 / 函数调用关系 / 页面真正加载的脚本
3
让 agent 用自然语言回答「哪条路径在跑」 — 而不是让它凭训练记忆猜这个程序大概怎么写
4
先拿一个能自己核对的小例子校准它 — 你对结果已知，才知道它读证据读得准不准
原理 · 为什么有效
传统的逆向工程把两件事绑在一个人身上：收集证据（反汇编、调试、指令级跟踪）和解释证据（推出这段逻辑在做什么）。前者的门槛是工具链熟练度，后者的门槛是经验 —— 两条门槛叠在一起，把这件事锁在了少数人手里。把工具链封成一个入口之后，收证据这一步可以被机械化（同一目标跑两次，拿到的指令列表应该一样），而解释这一步正好是语言模型擅长的：它有足够的常识去读懂「这段在算百分比」「这个常量是加速系数」。⇒ 关键判据也随之变了：证据必须可复现，结论只是解释。同一份证据上，agent 的解释可以错，也可以被下一个提问推翻 —— 所以两样东西要分开留档，不能把解释当证据存下来。
适用场景
适用：需要理解无文档行为的人 —— 想搞清一个第三方库为什么这样算、一个旧系统某个分支何时触发、一段前端脚本真正做了什么；做互操作、功能重实现或安全研究的开发者。
不适用：你只是想读自己项目的源码（那是检索与索引问题，知识图谱那类工具更合适）；只想快速知道某个 API 怎么用（去读官方文档）。
⚠️ 一条硬前置：这类工具是靠「研究已经完成的程序」来工作的 —— 把它指向第三方软件之前，先看清许可与服务条款，别把「技术上做得到」当成「可以这么做」。
自测 · 5 问
我要回答的是「这段代码为什么这么写」，还是「这个程序实际上做了什么」？
我有没有先确认自己有权分析这个目标（许可 / 条款 / 授权）？
工具给出的证据（指令列表 / 反编译结果 / 调用关系）我留下档了吗？
这份结论里，哪些是可复现的证据，哪些只是 agent 的解释？
我有没有用一个自己已知结果的小例子先校准它？
怎么上手 · 验证步骤
顺序照这个走：
① 先定问题 —— 写成一句话：「我想知道 X 在什么条件下会 Y」。问题越具体，取证范围越小。
② 确认授权 —— 许可、条款、目标是否属于你或你有权分析的范围；不确定就先不装。
③ 装工具并对接 agent —— 按官方给的单条安装命令接上，重启会话让它生效。
④ 先只要证据 —— 让它把指令列表 / 反编译结果 / 调用关系取回来，此步不要结论。
⑤ 再要解释 —— 基于那份证据问「哪条路径在跑、算什么」。
⑥ 校准 —— 拿一个你自己知道答案的目标（一个简单小程序的某个行为）跑一遍，看它解释得对不对。
⑦ 分开留档 —— 证据一份、解释一份；解释要标注「依据哪份证据」。
做完怎么自己对照检查：用 agent 的解释去预测一个你已知的输入输出。例：它说「这个函数在每次更新时把速度加 0.001 直到上限」→ 你就问「那 10000 次更新后是多少？」。对不上就说明它读错了证据，而不是证据错了 —— 回去重取证据。第二个动作：把你的问题换一种问法再问一遍，两次解释不一致的地方，就是证据不足的地方。