ARTICLE · 1267064
8KB文档干掉25MB服务,反编译工具圈吵翻了:我站8KB这边
装得越多越专业？
一份文档 干掉 207 个工具
36 次基准给出的答案
MCP 工具封装 · 上下文成本 · 选型判断
技术负责人的选型笔记
📦 5 Parts + Conclusion
👉 滑动
PART 01
两个玩家两条路线
ROUTES
PART 02
4个任务36次
BENCHMARK
PART 03
封装层的开销
OVERHEAD
PART 04
管理成本按人头算
TEAM COST
PART ///
写在最后
账和结论
一份 8KB 的文档，在自己的基准里把 25MB 的 MCP 全家桶比下去了
一个只有一份文档的开源项目，把 25MB 的反编译全家桶比下去了。星数是 2894 对 39 万，差了 135 倍，赢的却是小的那边。我看到这份基准测试的时候头一个反应是不信，因为它挑战的是我自己这两年的习惯：给 AI 装 MCP 工具、装插件、装全家桶，装得越多，感觉越专业。数据我算完又对了一遍，结论没变，反而更难看了。
先说清楚我的位置。我给团队搭过 AI 辅助分析的工具链，Java、Python、Rust 的二进制都碰过，也踩过 MCP 配置的坑。这篇文章不是产品评测，是我作为要给团队签字的人，看完两边数据后的选型笔记。结论先放前面：一年以内、没专职平台工程师的团队，我反对无脑上 MCP 反编译全家桶。
— 图1说明
01
PART
两个玩家两条路线
ROUTES
这场架的两个主角，路线完全相反。
39 万星的 REA（Reverse Engineer Anything）走的是全家桶路线：一个 MCP 服务器，把 asar、otool、nm、jadx、Ghidra、binwalk、tshark、sqlite3 这些命令行工具包成 207 个工具，交给 agent 调用。它自己统计过，加进 agent 的工具定义有 3.35MB。npm 包下载下来 25MB。skill 加参考文档合计 72.3KB。安装方式一条命令：npx rea-agents setup，选好 agent，重启生效。
2894 星的 leanrea 反着来：一份 8KB 的 SKILL.md，零工具注册，不装任何服务。它做的事是告诉 agent，哪类目标文件用哪条命令最快、第一批侦察命令怎么一次贴进去跑完、哪些坑是 REA 的代码替你兜住而裸命令不会兜的。然后 agent 自己跑真命令。安装是 npx skills add aicodeking/leanrea，产物就是一份文档。
— 图2说明
这张表最扎眼的是最后一行。同样一句「回 OK」，工具全量加载的 REA 要烧 40 万 token，leanrea 是 3.45 万。18 倍的钱，买的是一层 agent 命令行本来就有的封装。
02
PART
4个任务36次
BENCHMARK
但跑分赢只赢了一半，另一半藏在一个我第一遍没看懂的数字里，放在文末说。
光看体积说明不了问题，文档干活不行，再小也是玩具。leanrea 的作者做了一组基准：Claude Code 无头模式，Sonnet 5.5，macOS arm64，4 个逆向任务乘 3 次重复乘 3 个对照组，三组并排跑，答案对着手工答案要点打分。
任务挑得不算水：一个是把某 Electron 应用的功能从 app.asar 追穿到主进程类和 IPC 通道；一个是清点该应用原生插件的导出、权限检查和单实例锁；一个是从剥了符号的 gh 二进制里读出工具链和依赖版本；最后一个从反汇编直接推出锁文件的 socket 路径格式、线上协议和对端鉴权。
结论要念出来：对照 REA，leanrea 少 38% 的墙钟时间、少 35% 的钱、少 56% 的轮次、少 60% 的 token，得分只差 1 分。它答偏的只有那一题，把旧的 IPC 通道当成了 v2 通道，两个通道其实并存。74 分和 75 分的差别，放在我的场景里是无感的。
这里有个坑，我第一遍没注意到。这个基准只有每格 3 次重复、1 个模型、1 台机器，而且机器是 macOS。Ghidra、Hopper、jadx 三件重武器在测试机上没装，原生任务两边都是拿 Xcode 命令行工具跑的，这恰好是 leanrea 的主场。重武器齐装的逆向工程师，REA 的分还能再涨。但反过来说，装了重武器的小团队是少数，一台 M 系列 Mac 加 Xcode 命令行工具，才是多数人的真实环境。
03
PART
封装层的开销
OVERHEAD
还有个更直接的证据，作者没有只测 agent 对话，还把同一个操作在 REA 的 CLI 和裸命令上各跑了一遍。你平时敲命令时心里默认的速度，就是下表右列那个量级。
注意第二行，0.04 秒对 3.32 秒。这不是模型快慢问题，是封装层开销问题。otool、dyld_info、nm 三条命令并起来 0.04 秒能拿全的信息，经过一层 MCP 调度变成 3.32 秒。
比如最小复现，就是下面这种日常操作，绕开封装直接敲，这就是 leanrea 让 agent 直接跑的路子：
$ otool -L Ghidra | head -3
Ghidra:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
$ go version -m ./gh | head -4
./gh: go1.23.4
path github.com/cli/cli/v2/cmd/gh
mod github.com/cli/cli/v2 v2.63.2
第三行那个asar 完整性报错也很眼熟，我自己在别的工具上见过同款：为了防篡改加的校验，先把合法用户的正常分析拦住了，得翻文档找那个跳过参数。
— 图3说明
我反对的不是 MCP。MCP 在权限隔离、审计、远程工具共享这些场景里是真需求。我反对的是把「agent 已经能直接调的本机命令行工具」再包一层 MCP。这层封装没有换来能力，换来的是 3.35MB 的工具定义、每次会话的加载开销，和一个要跟着上游版本追的适配层。
04
PART
管理成本按人头算
TEAM COST
工具选型我从来不只看跑分，还要看这套东西占团队里一个人多少时间。两套路线的管理成本画像差得很远。
装机成本
leanrea 是一份文档加进 skills 目录，5 分钟的事；REA 要装 npm 包、注册 MCP、按 agent 逐个配置、重启生效，首次配置至少半小时，团队机器越多越贵。
升级成本
leanrea 的升级就是npx skills update leanrea，改的是文档，坏了删掉就行；REA 的 207 个工具跟着上游二进制的参数变化走，工具名和参数一变，agent 的调用就断。
上下文成本
这是每月持续付的账。按一个工程师一天问 20 次、每月 20 个工作日算，工具全载入的路线一个月要流过 1.6 亿 token 在「加载工具再应答」这件事上，leanrea 对应的是 1380 万。就算你的客户端有按需加载，省 60% 的轮次还是实打实的钱。
排错成本
REA 出问题要看 MCP 日志、工具 schema 和包版本三处；leanrea 出问题就是命令本身的问题，会敲命令的人就能查。
管理成本上我给的判断很干脆：一个 10 人以内、没有专职平台工程师的团队，每多一层要维护的中间件，就是从产品时间里扣钱。leanrea 这种「文档即工具」的形态，维护成本约等于零，这是它最大的价值，比 38% 的提速值钱。
///
LAST
这个案例的真正启示，不在这两个工具
SUMMARY
往大了看，这件事和工具无关，和这两年的风气有关。agent 能力上来之后，行业惯性是给它加装备：加 MCP、加插件、加技能市场，好像不给 agent 装满工具就是不专业。这个基准给出了一个难堪的对照：一份写得好的文档，把工具的调用时机、顺序、坑位讲清楚，效果优于 207 个封装好的工具，还便宜 97%。
我自己这两年的工具链也在瘦身。给 agent 写清楚「先跑哪条命令、看到什么再往下」，比再接一个服务有效。文档写得好，本身就是在给团队省算力账单。
上文那个我第一遍没看懂的数字，现在可以解释了。同样是工具全载入后应答一次「回 OK」，REA 400.7k tokens 对 leanrea 34.5k。这不是逆向能力的差距，是 207 个工具定义挂在上下文里的固定开销。你的 agent 每开始一轮对话，先付这笔钱，然后才轮到干活。
最后补一句诚实话，这篇给不了什么：我没有在 Windows 和 Linux 上复现这组数字，重武器逆向场景（加固、混淆、内核）两边都没测，那部分 REA 的生态优势我无法证伪。macOS 日常分析这个场景，我的结论不变。
写到这里你可能想问：你们团队的 agent 现在挂了多少个 MCP 工具？流过的 token 有没有算过一笔账？评论区报个数，我挺想知道 3.35MB 工具定义这件事，是个例还是常态。
你们团队的 agent 现在挂了多少个 MCP 工具？流过的 token 有没有算过一笔账？
觉得有用，欢迎点赞、在看、转发。
THANKS FOR READING
