Agentic Decompilation（智能体反编译）
一句话定义：让一群 LLM 智能体（agent）分工协作，把编译好的二进制文件（binary）逆向还原成人类能读、最好还能重新编译的源代码——注意关键字是「智能体集群」，而不是单个模型一次性输出。
它和经典反编译差在哪
经典反编译器（如 IDA、Ghidra 这类工具中的反编译模块）走的是确定性路线：解析指令、构建控制流图、做数据流分析、套用模式匹配生成 C 伪代码。它快、免费、可复现，但输出通常是「能看不能编译」的伪代码：变量叫 v1、a2，类型靠猜，函数边界靠启发式，遇到混淆或优化过的代码就退化。
Agentic 反编译把其中「靠猜」的部分外包给 LLM：让模型看着一段反汇编，判断这是什么数据结构、这个函数在干什么、该取什么名字、类型是什么，然后把伪代码改写成真正能编译的源码。因为一段函数往往上下文不够判断，需要跨函数、跨模块地互相印证，所以做成「集群」——不同 agent 负责不同职责，共享一份中间状态。
流水线大概长这样
| 阶段 | 干什么 | 谁来做 |
|---|---|---|
| 分片反汇编 | 把二进制切成函数/基本块，生成反汇编与初始伪代码 | 传统工具，确定性 |
| 符号命名 | 给变量、函数、结构体起有意义的名字（sub_4012A0 → parse_header） | LLM 智能体 |
| 类型恢复 | 推断参数类型、结构体布局、指针与数组 | LLM + 约束求解 |
| 代码改写 | 把伪代码改写成可编译的 C/C++ | LLM 智能体 |
| 编译验证 | 真正调编译器编译，报错回灌、迭代修复 | 编译器 + 智能体循环 |
| 语义校验 | 比对行为是否与原二进制一致 | 差分测试、符号执行 |
打个比方：经典反编译像把一台拆掉的宜家柜子按螺丝孔位置硬拼回图纸；Agentic 反编译像请了一支施工队，有人认零件、有人贴标签、有人照图施工，最后还有一个质检员拿成品去和原柜子比对承重。
核心难点：能编译 ≠ 语义正确
这是最容易被外行低估的一条。LLM 很擅长把代码改成「编译器不报错」的样子：补个强制类型转换、把指针改成 void*、把不确定的分支写成 if 加注释。编译通过了，但行为可能早就偏了。
所以验收必须分层：
- 可编译：语法与类型过关，最低门槛。
- 可链接：依赖的符号、调用约定、ABI 对得上。
- 行为等价：在给定输入集合上，输出与原二进制一致——需要差分测试（differential testing）或符号执行佐证。
- 可维护：命名、结构、注释达到人类可读水平，这是主观项。
实践中，编译通过往往只是整个成本的零头，真正烧钱的是后面两层的来回迭代。
成本结构为什么吓人
一次反编译不是「一次调用」，而是一个循环：切片 → 生成 → 编译失败 → 回灌错误 → 重写 → 再编译。每个函数可能要迭代数轮，每轮都要把上下文（反汇编片段、已有符号表、编译错误）重新塞进提示。整个项目动辄消耗数百 B token（B = billion，十亿级）量级并不夸张，具体数字随目标程序规模和模型选择差异极大，以各家官方页面为准。
成本主要来自三块：一是上下文重复注入（同一份背景被反复读），二是编译-修复循环的轮数，三是集群内部 agent 之间互相评审带来的额外调用。这也是为什么这类方案目前多用于高价值目标（遗留系统、无源码的合规审计、恶意样本分析），而不是随便拿个小程序试。
对从业者的意义
对安全与逆向工程师：它把「读伪代码」的体力活部分自动化，人从命名和类型推断转向设定验收标准、审查关键路径。你的价值从「能看懂汇编」变成「能判断这份还原结果可不可信」。
对普通职场人：这套思路——分片、分角色、加上一个客观可执行的验证器——其实是所有「LLM 做长任务」的通用模板。能不能落地，往往不取决于模型多强，而取决于你有没有一个像编译器那样「不接受就报错」的硬标准。