企业官网建设流程全解析

逆向三件套横评：轻量实现、完整编排层、直连引擎，谁先跑通谁更省

【免费下载链接】leanreaOne 8 KB skill that replaces REA (Reverse Engineer Anything): plain CLI tools, no MCP. Benchmarked: 38% faster, 35% cheaper.项目地址: https://gitcode.com/gh_mirrors/le/leanrea

2026 年 4 月建仓的 REA（Reverse Engineer Anything，npm 包名rea-agents）在过去一个多月里被媒体报道"一周 10 万星""9 天 20 万星"，麻省理工科技评论甚至抛出"软件开发护城河守得住吗"的追问，DoNews、InfoQ、极客公园跟进讨论，CnBeta 则报道了用它在 Switch 游戏上做出原生 PC 移植的案例。它的定位很明确：一个 MCP 服务器，把 AI Agent 接到 asar、otool、nm、go version -m、jadx、apktool、Ghidra、tshark、binwalk、sqlite3 这套逆向工具链上。

但爆火之后真正值得工程上追问的问题是：当 Agent 本身已经自带 Bash，本地 CLI 工具又都是现成的，中间这层 207 个工具的 MCP 编排层，到底买了什么？leanrea 这个项目就是冲着这个问题来的——它的全部实现是一个 8 KB 的 skill 文件，宣称"做到 REA 能做到的事：没有 MCP server，没有 207 个工具，没有 setup"。

本文不重复营销叙事，而是把 leanrea 仓库里那份真实跑过的三组对照基准（36 次 headless 运行、正则判分、逐条可查的原始指标）拆开，横评三条路线：

• 直连引擎：不装 skill、不挂 MCP，Agent 直接用 Bash 驱动 otool/nm/strings/asar 等原始工具（基准里的none组）；
• 完整编排层：REA 6.5.0，25 MB npm 包 + MCP server + 207 个工具 + 它自己的 skill（rea组）；
• 轻量实现：leanrea 的单文件SKILL.md（leanrea组）。

一、三条路线：装了什么，token 花在哪

1.1 直连引擎：零安装，模型直接对 otool 说话

这条路线没有任何中间层。Agent 拿到的就是 Bash，逆向引擎就是系统里本来就有的 Xcode 工具链、Homebrew 包。bench/run.py 里none组的运行配置只有--allowedTools "Bash,Read,Grep,Glob,Write,Skill,mcp__rea"，不带任何 MCP 配置。

从 bench/results/final.jsonl 的逐次运行记录能看到直连组的实际行为轨迹：分析mac_utils.node时，none组自己打出了T=./mac_utils.node;、strings、otool、sed这样的组合命令——也就是说，一个带终端权限的现代 Agent，在没有指导的情况下也能自己凑出可用的逆向工作流。代价是每次都要重新探索：同一目标，它用了 81 个 turn、3.11 M token 才跑完四道题。

1.2 完整编排层：REA，207 个工具，3.35 MB 的定义

README.md 里的对比表把 REA 的体量讲得很直白：

3.35 MB 的定义体积怎么构成的，bench/mcp_list.py 直接对rea --mcp的tools/list做了拆解：输入 schema 745 KB、输出 schema 2.46 MB、描述 90 KB。

安装路径也是三条里最重的：npm install rea-agents@6.5.0（bench/setup.sh 第 15 行），再写一份 MCP 配置指向rea.mjs --mcp。社区教程（CSDN 上成系列的安装/接入文）还给出两条额外的运行前置：Node 22.x/24.x/26+；若要接 Ghidra 引擎，则限定 Ghidra 12.1.x + JDK 21 组合，设置GHIDRA_INSTALL_DIR与JAVA_HOME，用rea doctor做只读体检、rea setup注册客户端，且首次分析存在引擎 330 秒上限与客户端默认 60 秒超时的冲突，卡死要用rea close + rea open恢复——配置成本明显高于另外两条路线。换来的是 25 项只读 Ghidra 静态分析操作，以及一套引擎无关的调度：同一套 Agent 接口下切换 JS/Electron、.NET、APK、固件目标。

1.3 轻量实现：一个 8 KB 的 SKILL.md

leanrea 的全部工程实体是 leanrea/SKILL.md，四段结构：

1. Rules：先按file -b T和 magic bytes 路由；解压到$TMPDIR/re/<name>的副本上作业；rg -uu搜解压树（打包器把代码藏在.webpack/、.vite/这类点目录里，普通rg会漏）；不cat大文件，用rg -o '.{0,200}NEEDLE.{0,200}'切片；独立探针用;批量进一次 shell 调用；每条结论标注seen（附 file:offset 或符号/字符串）/inferred/unknown。
2. First move：每类目标一条"粘贴即跑"的组合命令，一次 tool call 拿到完整清单。例如 Electron 路线：

A=./app.asar; X=$TMPDIR/re/asar; rm -rf $X; npx -y @electron/asar extract $A $X && jq '{name,version,main}' $X/package.json; find $X -path '*/node_modules' -prune -o -type f \( -name '*.js' -o -name '*.node' \) -print | head -60; ls ${A}.unpacked/node_modules 2>/dev/null; rg -uu -l --glob '!node_modules' 'exposeInMainWorld' $X

3. Router：一张"目标类型 → 最快命令"的路由表，覆盖 Electron/asar、压缩 JS 与 source map、Hermes/bytenode、Mach-O、ELF/PE、Go（go version -m T alone usually answers the question）、Rust、.NET、APK、Flutter snapshot hash、WASM、SQLite、plist、pcap/HAR、固件、网站与运行时。
4. Speed patterns：字符串与导入优先、从 otool 的 literal pool 注释反查字符串的宿主函数、读调用序列而不逐条指令、比对版本先 diff 清单（nm、模块表、go version -m）再 diff 代码。

安装也是一条命令：npx skills add aicodeking/leanrea（README.md 的 Install 节），skills CLI 会把它铺进 Claude Code、Codex、Cursor、Gemini CLI 等客户端；不挑客户端时，直接把SKILL.md粘进 rules/system prompt 即可——纯文本，没有运行时。

二、同一目标的跑通成本对比

2.1 测试方法

基准定义在 bench/BENCHMARK.md：Claude Code 2.1.301 headless（claude -p）、Sonnet 5.5、macOS arm64。四个任务各 3 次重复 × 3 组，36 次运行，三组"并排同时跑"（bench/run_all.sh 里&并行 +wait），每次运行--max-budget-usd 4，答案用正则对着人手写的答案键判分（bench/tasks.json）。

四个目标物是 Notion 桌面版的app.asar与原生插件mac_utils.node，以及 Homebrew 的gh二进制：

• electron：从 asar 里追 Notion 的"会议检测"——原生函数、主进程类、两个 IPC 通道；
• native：mac_utils.node的全部 JS 可导出函数、TCC 麦克风权限检查、单实例锁机制；
• go：不运行gh，报出工具链版本、main 包路径和两个依赖的精确版本；
• deep：仅凭反汇编还原单实例锁的 socket 路径格式、线上协议与对端认证方式（答案键包括/tmp/com.notion.singleinstance.、geteuid、proc_pidpath、getpeereid、4 字节长度前缀、JSON 等 8 个正则）。

2.2 总表与分任务

12 次运行的合计（我对 final.jsonl 独立复算过，与发布数字一致）：

分任务的中位墙钟/平均 turn/成本：

几个值得注意的形状：

• REA 不是"跑不通"，而是每一步都更贵更慢。electron 题上它比 leanrea 慢 2.3 倍；最坏的一次运行（final.jsonl 中 rea/electron 第 13 次）122.4 s、13 个 turn、$0.397，工具轨迹是ToolSearch → mcp__rea__analyze_javascript_application ×2 → find → grep ×3 → python3 ×4——MCP 调用和裸 Bash 混用，说明 Agent 并没有被"托管"进 MCP，而是两边来回跑。
• 直连引擎在简单题上并不弱。go 题上 none 组 13.8 s、$0.092 全场最省，因为答案本来就在go version -m一条命令里；native 题它甚至比 leanrea 快了 7 秒。模型本身够强时，脚手架的边际收益在简单题上接近零。
• 难题是分水岭。deep 题（纯反汇编推理）上，none 组丢分最重（16/24，8 个答案键只命中一半，还伴随一次拒答），leanrea 和 REA 都是 24/24。脚手架的价值随题目难度上升才显现出来。

2.3 上下文开销：那个 400k token 的坑

bench/ctx.sh 用一个探针（"Reply with exactly OK."）测量各配置空转一次的上下文 token 与成本：

这一行是全篇最被低估的数字：在不支持按需检索工具（deferred tool search）的客户端里全量加载 REA，光是说"OK"就要 40 万 token、$1.60。BENCHMARK.md 特意注明基准测的是 REA 的最优情形（Claude Code 的延迟工具检索），而 207 个工具里多数客户端每次都要付 369k 的税——上下文窗口紧张或多轮长会话时，这笔税会复利。

2.4 单操作微基准：过一层编排的延迟与体积

同一操作、同一文件，bench/BENCHMARK.md 记录了 REA CLI 与裸命令的对决：

第三行是"跑通成本"最直观的注脚：真实桌面应用的 asar 会踩 REA 的完整性校验，需要额外 flag 才能继续；即便跑通，140 MB 的中间产物对一个"查两个 IPC 通道"的问题也是严重过量——而最终判分只看答案里的几个字符串。编排层保证了流程的确定性，但也把每次操作的固定开销抬高了 9~900 倍。

三、输出质量与可验证性

谁先跑通：三条路线都能跑通全部四题，没有硬失败。分秒差别是 leanrea（388 s）< 直连（479 s）< REA（627 s）。"跑通"若按首次成功计，直连安装成本为零、leanrea 一条npx命令、REA 需要 npm 包 + MCP 注册 + 可选的 Ghidra/JDK 环境；"跑通"若按单次分析耗时计，leanrea 四题里拿下三个最快中位数。

谁更准：REA 75/75 是唯一满分。leanrea 74/75，唯一一次失手是 electron 题报了 v1 广播通道而非 v2——两个通道在代码里都存在，属于近失而非幻觉。直连组 67/75，失分构成更值得看：deep 题 16/24（漏掉euid、exe、hash、sock等键）+ 一次拒答，外加一次判分假阴性（回答写了 "Go 1.27.1" 而正则要求 "go1.27.1"，BENCHMARK.md 已按勘误修正）。

可验证性：这是三条路线设计取向差异最大的地方。leanrea 把证据纪律写进了 leanrea/SKILL.md 的 Rules：每条结论必须标seen（引用file:offset或符号/字符串）、inferred或unknown，且"没找到的事实是 unknown，不是 absent；静态阅读不等于观察到执行"。基准里 leanrea 组的工具轨迹（每次运行 3~6 个 Bash 调用、总 55 turn）与这条"2–4 次工具调用就收手"的约束对得上——它的省，本质是纪律省下来的。REA 走另一条路：用结构化工具把 Agent 约束在确定性流程里，75/75 的稳定性来自"工具替你选对路径"；代价是 124 个 turn、5.93 M token，比 leanrea 多一倍。直连组则没有任何约束，好坏都取决于当次模型状态——simple 题全场最省、deep 题全场最烂，方差就是它的成本。

需要保持的诚实边界（仓库自己在 Caveats 里写明）：每组 n=3、单模型（Sonnet）、单机、单目标版本（答案键绑死 Notion 7.35.1 与 go1.27.1 构建的gh）；Ghidra/Hopper/jadx 未安装，native 题两组都落在 Xcode 工具链上，没有测到 REA 的重引擎调度能力；而"裸模型本来就不错"是既定事实——leanrea 相对直连的优势（19% 更快、32% 少 turn、成本持平、且避免了那次拒答）远小于相对 REA 的优势。

四、选型矩阵与决策树

把三组数据压成一张矩阵：

决策树，按顺序问：

1. 你的 Agent 是否已能熟练使用终端（Claude Code、Codex 这类带 Bash 的客户端），目标是否落在 Router 表的常见 15 类之内（Electron、Mach-O/ELF/PE、Go/Rust/.NET、APK、WASM、SQLite、pcap、固件、网站）？
   • 是 → 轻量 skill 路线。本次测试里它同时是"最快跑完"和"同精度下最低 token"，且 8 KB 的指令本身可审计、可改写。
   • 否，或需要多引擎调度（Ghidra/IDA 适配、25 项只读静态操作）、团队级可复现的证据链、CI 里锁定行为 → REA。它是三组中唯一 75/75，稳定性是买来的，不是免费的：124 个 turn、$3.36、以及下条的上下文税。
   • 一次性简单问题、模型强、对成本极端敏感 → 直连引擎。go 题 $0.092 就是这条路的上限演示；但别让它碰 deep 级别的纯反汇编推理——本次 16/24 + 一次拒答。
2. 客户端是否支持延迟/按需工具检索？不支持就不要全量挂 REA 的 207 个工具——那是一问一答 369k token、$1.60 的固定税。
3. 要不要接重引擎？要 Ghidra 就接受 12.1.x + JDK 21 的版本红线、rea doctor体检与首次分析的超时坑（330 s 引擎上限 vs 60 s 客户端默认，rea close + rea open恢复）。这三条路线里只有 REA 把这层做了，另外两条把 Ghidra 降级为"真要伪代码时再开一次analyzeHeadless"的备选项（SKILL.md 的 Native 行原文即如此）。

一句话收束：直连引擎证明了"模型 + 终端"本身已经能完成大部分逆向工作，完整编排层买的不是能力而是稳定性与标准化（75/75 与 74/75 之间那 1 分、加上一次被避免的拒答，就是它全部的可见产出），而 8 KB 的轻量实现吃掉了编排层的大部分收益、只付约 3k token 的指令成本。"谁先跑通"：安装上直连最快、单题耗时上 leanrea 最快、全对率上 REA 唯一满分；"谁更省"：token 账本上 leanrea 比 REA 省 60%，成本上三组几乎打平（$2.17~$2.21），真正的成本悬崖藏在 REA 客户端兼容性里那 369k 的上下文里。

最后照例把限定条件说死：样本量每组 3、单模型单机、目标版本绑死、重引擎缺席——这份横评回答的是"常见目标 + 现有 CLI 工具链"这个区间内的架构问题，而不是 REA 全能力面的审计。仓库作者自己在 README 末尾也留了这句话：leanrea 与 REA 无关，"只是验证一下：带一个简短注记和朴素工具的模型，能不能更快做完同样的事"。就这 36 次运行而言，答案是：能，而且便宜得多。

【免费下载链接】leanreaOne 8 KB skill that replaces REA (Reverse Engineer Anything): plain CLI tools, no MCP. Benchmarked: 38% faster, 35% cheaper.项目地址: https://gitcode.com/gh_mirrors/le/leanrea