给 Agent 加工具这件事，已经亏钱了

我先说一个我被硬打了三次脸的判断。

去年我写过一句话，大意是「Agent 的工具链越丰富，能力上限越高」。那时候的依据很朴素：MCP 协议把工具接进来了，工具越多，模型能干的事就越多。这个逻辑在纸面上无懈可击——一个只会写代码的模型和一个能查数据库、能跑测试、能发邮件的模型，能力边界怎么可能一样？

然后今天，三份互不相干的材料同时指向反方向。

一份是 arXiv 上今天挂 HN 的论文，一份是有人在生产环境抓了 40 遍包的数据，还有一份是个 1300 颗星的小仓库，作者直接把别人的 207 个工具全删了。

三份材料指向同一件事：我们给 Agent 加工具这件事，边际收益已经跨过零线，进入负数区了。

更麻烦的是，这三份材料说的不是同一层的东西，但如果把它们叠起来看，能拼出一个相当反常识的结论。

一、一篇论文说：精心设计的 Harness 全是冗余

先说论文。arXiv 2609.40303，今天上 HN，标题叫《How Much of a Harness Does a Strong Agent Need for Autonomous ML Engineering?》，EPFL 的三个人写的，Kirill Brilliantov、Alejandro Hernández-Cano、Emmanuel Abbé。

做机器学习工程（MLE）自动化的社区，过去三年的主流架构是 Harness：外层写一个程序，负责反复调 LLM 生成代码、执行、评分、再把分数喂回去。基于这个框架 they've built 出了一堆精巧的东西——搜索树、程序种群、专职检索子 Agent、多 Agent 编排。听起来每一层都有存在的理由。

论文干的事很简单：固定模型、固定硬件、固定时间预算、固定任务集，然后把 Harness 一层一层拆掉，看看到底哪层有用。

结论是这样的：几乎全部的收益来自运行时和 LLM 本身，几乎没有一分来自建在上面的那些机器。

具体数字。论文做了一个叫 Malena 的东西，本质上就是「一个长 session 的 coding agent，给它 shell 和文件系统，就这么跑」。然后拿去跟四个开源 SOTA Harness 打：MLEvolve、AiScientist、Arbor、ScienceFlow。

同一个 GLM 5.2 backbone 上，Malena 的获奖率（medal rate）是 62.5%，被测的最好的外部 Harness 是 47.1%。换 Kimi K3，换 DeepSeek V4 Flash，统计结论要么偏向 Malena，要么「没有显著差异」。

唯一的例外是 Gemma 4 31B——最小的那个模型。那里 MLEvolve 的百分位估计领先，但置信区间还是重叠。论文自己说得很谨慎：弱模型仍然吃手工 workflow prior 的红利，agent 能力一上来，裸循环就把差距抹平了。

多 Agent 编排那部分我看得最仔细，因为这是我最近一直在写的东西。论文设了三个干预：

干预	含义	百分位（自选）	获奖率（自选）
base	什么都不加	66.51	55.7%
+D	委派子 Agent（层级 planner-executor）	63.62	45.2%
+P3	三个独立实例并行（对等网络）	67.77	52.4%
+B+P3	并行 + 广播工具	58.91	33.3%

看第四行。三个独立实例并行跑，加上互相广播消息，获奖率从 55.7% 掉到 33.3%。不是「没提升」，是显著变差。

论文对 +P3 的解释我觉得很诚实：并行确实把 oracle（事后最优选择）的天花板抬上去了，67.77 对 66.51，但独立实例之间的「选择差距」涨得更多，所以最终自己提交的那份，质量跟 base 差不多。翻译成人话：三个 agent 各写各的，最后你只能挑一个提交，而你挑不动的那个差距，比并行带来的收益还大。

论文最后一句话我直接抄给你们：

Almost all of the gain comes from the runtime and LLM backbone, and almost none from what is built on top of them.

然后是这句：

coding-agent post-training substitutes for the scaffolding that harnesses hand-design.

Coding Agent 的后训练，正在替代 Harness 手工设计的脚手架。

论文最后还引了 Sutton 的 bitter lesson。我看到这儿的时候笑了一下——十年前 RL 社区那句话现在被原样搬回来，方向反过来了：这次不是「通用方法胜过人 hand-crafted 特征」，是「通用方法胜过了人 hand-crafted 流程」。

不过这篇论文最值得抠的其实是它的实验设计，因为这个设计决定了它的结论能推广到多远。

论文在 Limitations 里自己承认了：主要结果依赖 MLE-bench，而 MLE-bench 任务本身有准备问题，而且它来自公开的 Kaggle 竞赛，是一个合理的污染目标。作者的缓解手段是手动修了一些坏任务，然后换了一套更干净的 NatureBench 做交叉验证。

还有一点我觉得论文说得比大多数论文诚实——它在附录 D.3 里专门写了一段，说明它往每个外部 Harness 上砸了多少「调优功夫」：针对 backbone 的 bug 修复、配置消融。也就是说作者不是把对手的默认配置原封不动摆上来挨打，他是真花时间让对手跑正常的。

即便如此，结论依然成立。作者甚至给出了一个对我有利的限定：论文里说存在一种「调优投入的不对称」，可能 Malena 自己得到的调优更多。

那这是不是意味着「Harness 无用论」过头了？我把论文里的四条限定列一下：

第一，模型够强才有这个结论。 Gemma 4 31B 上 MLEvolve 还是赢的（虽然置信区间重叠）。论文自己讲：弱 backbone 仍然吃手工 workflow prior 的红利。你手上要是在跑 7B、14B 这种量级的开源模型，多 Agent 编排还是有价值的。

第二，任务有客观反馈信号。 MLE 任务的好处是有一个 noisy 但是客观的验证分数。这不是所有 coding 任务的属性。写一个重构任务、一个性能优化任务，你没有「跑一下就知道对不对」的信号——那些才是 Harness 真正可能有价值的地方，因为那里需要外部程序来定义什么叫「更好」。

第三，预算够长。 论文所有实验都是 6 小时到 24 小时预算。多 Agent 在短任务上的表现论文没测。

第四，compaction 不是免费的。 论文附录 C.7 做了一个专门的实验，人为砍 Malena 的上下文窗口，发现每次 compaction 会丢掉大约 76% 的累积上下文。也就是说「单长 session」这个最小基线有一个隐含前提：模型足够好，能在丢 76% 上下文之后自己重新捡起来。这对现在的 frontier 模型成立，对弱模型不成立。

把这四条摆在旁边，我的判断是：这不是「Harness 无用论」，这是「Harness 的护城河正在变窄」。 强模型 + 有客观信号 + 长预算这三个条件同时满足时，Harness 的边际收益趋近于零；三个条件缺一个，它还有位置。

而今天主流模型恰好是 frontier 级，今天最热的任务恰好是 MLE 这种有明确验证分数的，长期 Agent 编程恰好是长预算的。三个条件同时踩中。

这不是巧合，这是趋势。

二、一份抓包数据说：同一份工具清单，价差 62000 倍

论文讲的是长时程的 MLE 自动化，离大部分人的日常有点远。真正扎手的是第二份材料。

Spirit Room 这家在做 MCP 工具链的测试，他们抓了一个生产环境的 99 工具 MCP server 的包，看同一个工具清单在不同 Agent 客户端里被怎么处理。

先给个锚点：99 个工具的定义，compact JSON，o200k_base 分词，68,286 个 token。

然后是各客户端加载同一份清单，第一次请求的增量：

客户端	首次请求增量	会不会每次重发
Codex 0.161.0（code mode）	+0	否，搜索结果才进历史
Claude Code 2.1.301（默认）	+1,715	只重发它加载的定义（每个约 573 token）
OpenCode 2.0.31	约 +5,270（首请求总计）	否，只有代码打印的进上下文
OpenCode 1.18.34	+73,415	是，每次都发
Claude Code（tool search 关闭）	+107,541	是，每次都发

同一份东西，+0 到 +107,541。

这不是「有的客户端优化得好，有的没优化」的问题。是成本可以相差六万倍，而且完全由用户的客户端决定，不由你决定。

有几个细节值得单独拎出来。

第一个是 OpenCode 1 的真实账单。 他们在 8 个只读问题上跑了 40 遍，OpenCode 1 每个问题平均 3.7 次模型请求，也就是说——光是工具定义，每个问题就烧掉约 230k token。按它自己的统计，每个问题总输入 341,615 token。Claude Code 和 Codex 在同样的问题上平均是 222k 和 221k。

OpenCode 1 的三分之二 token 花在「告诉模型有哪些工具」上。不是在干活。

第二个是那个配置陷阱，这条我要单独警告。 Claude Code 在走自定义 API base URL 的时候——比如公司网关、代理——会自动把 tool search 关掉，然后把全部 99 个定义塞进去。手动加 ENABLE_TOOL_SEARCH=true 能救回来，实测首次请求从 143,357 token 降到 22,446。

如果你公司所有人都在 Claude Code 前面挂个网关，那你现在的账单正在为同一份工具定义付六倍的价钱，而且没人知道。

第三个是搜索式加载的隐藏成本。 大家都喜欢「按需加载」这个说法，因为它听着聪明。但它换了一种失败模式：从「花太多钱」变成「找不到东西」。

同一个生产 server，80 次只读实跑：

• Codex 8 次完全没找到工具（5-19% 的区间），它报告说没有可用连接，然后试了浏览器
• Claude Code 40 次全部找到，91-100%

而 Codex 在第一次真正调用之前，为了搜索烧掉约 40k token。

所以「少工具」不是免费的。它是把钱从 token 账单挪到了命中率账单上。挪完之后账单好看了一点点，然后你会在某个周一早上发现线上有个 agent 说「我连不上你的服务」。

三、一个 1300 星的小仓库说：207 个工具打不过 8KB

第三份材料是 GitHub 上的 aicodeking/leanrea。

这个仓库 10 月 17 号建的，今天 1306 颗星。它干的事一句话说完：把 morluto/rea 的实现整个删掉，留一个 8KB 的 SKILL.md。

rea 是啥——一个 35 万星的项目，把逆向工程整个 Agent 化。它的做法是在 Agent 和工具之间加一层 MCP：asar、otool、nm、go version -m、jadx、apktool、Ghidra、tshark、binwalk、sqlite3，全都包成 207 个工具定义给 Agent 塞进去。

leanrea 的做法是：告诉 Agent 每种目标类型跑哪条命令最快，给几条可以直接粘贴的侦察命令，列几个 REA 代码帮你处理了的坑。然后让 Agent 自己用 Bash 跑真正的工具。

不装 npm 包，不装 MCP server，不挂 207 个工具。上下文对比：

	REA 6.5.0	leanrea
装什么	25 MB npm 包 + MCP server	一个 SKILL.md
指令体积	23.5 KB skill + 48.8 KB references	8 KB
加给 Agent 的工具	207 个（3.35 MB 定义）	0（用 Bash）
agent 回一句 "OK" 的上下文	400.7k token，$1.60	34.5k token，$0.09

上下文砍掉 91.6%，一次 1.6 美元变成 9 美分。

但上下文只是一半。作者做了正经 benchmark：Claude Code headless，Sonnet 5.5，macOS arm64，4 个逆向任务 × 3 次重复 × 3 个 arm 并排跑，答案对着人工答案打分。

arm	墙钟时间	成本	轮次	token	得分
leanrea	388 s	$2.17	55	2.40 M	74/75
完全不给 skill	479 s	$2.21	81	3.11 M	67/75
REA（MCP + 它的 skill）	627 s	$3.36	124	5.93 M	75/75

对 REA，leanrea 少了 38% 时间、35% 钱、56% 轮次、60% token，准确率打平。它唯一的失误是把一个 IPC 通道的版本号说错了（说了旧的 v1，正确的是 v2，两个通道都存在）。

作者还贴了一组单操作对比，比总表更狠：

操作	REA	裸命令
Go build 信息	0.56 s	go version -m：0.06 s
Mach-O 总览	3.32 s	otool + dyld_info + nm：0.04 s
Electron 应用分析（真实桌面应用）	asar 完整性校验不过就挂，过了之后 47.9 s + 140 MB JSON	asar extract + rg -uu：4.8 s，24 KB

最后一行。140 MB 的 JSON，24 KB 的输出。差了五千多倍。

这组数字背后的道理很朴素：MCP 工具的返回值必须能被模型读，而模型的输入是文本。工具层为了让「返回值结构化、可被多次引用、可以被拼接」，就必须把原始数据塞进结构化字段。逆向工程这种任务，原始数据是二进制——一结构化就爆炸。

裸命令没有这个问题，因为它直接把管道接给了下一个命令，中间那份 140 MB 从来没变成文本。

四、但我要泼一盆冷水：Skill 有用，工具有害

上面这些如果就这么讲出去，很容易变成「赶紧把 MCP 全删了」。那不对。

leanrea 作者自己在 caveats 里写了一条，我觉得是这三份材料里最诚实的一句：

The plain model is already good at this. leanrea's gain over no skill (about 19% faster, 32% fewer turns) is smaller than its gain over REA.

对着那张表再看一遍——

• leanrea vs REA：少 60% token，准确率打平
• leanrea vs 完全不给 skill：只少 24% token（2.40M vs 3.11M），快 19%，少 32% 轮次

所以真正的结论是：8KB 的 skill 依然比裸模型好，砍掉的是工具层带来的净亏损，不是 skill 的价值。

这个区分是全文最硬的地方，也是最容易被误读的地方。

把三层拆开：

1. skill（8KB 纯文本，路由知识）——有正收益，但不大。19% 时间、32% 轮次。这部分是「告诉 Agent 什么时候该用哪条命令、有哪些坑」，是真的知识。
2. MCP 工具层（207 个定义）——净负收益。60% token，0% 准确率。这部分是「把 Agent 已经会的 Bash 命令重新包装一遍，让它通过一次函数调用去拿」。
3. 后训练过的 backbone——最大收益，全在模型里。

论文说「收益几乎全在 backbone」，leanrea 的 benchmark 说「skill 有小收益、工具层有大亏损」，抓包数据说「token 成本差六万倍」。三份材料说的是同一件事的三个投影。

我们过去两年在这三层上的投入分布是反的：我们在第 3 层没什么选择权，在第 2 层下注最重。

不过「为什么工具层会亏成这样」这件事，值得掰开讲，因为只有讲清楚机制，你才知道自己该改哪一层。

机制一：工具定义是每次都要重发的固定开销。

这一条最朴素，也最容易被忽略。

MCP 工具定义属于 system prompt 的一部分，它不像用户的实际对话内容那样能被压缩掉——它必须在每一次请求里完整出现，因为模型需要它来知道有什么工具可用。

拿抓包数据算一笔：一个 99 工具的中型 server 是 68,286 token。假设你一天跑 200 次请求、其中一半是能走 tool search 的、另一半是全量加载的，你自己算。我替一个典型团队算了一下：50 个工程师，每人每天 300 次 Agent 请求，其中 40% 走全量加载：

50 × 300 × 0.4 × 68,286 ≈ 4.1 亿 token/天。

按 GLM 5.2 的 $0.3477/M input 算，这是每天 142 美元，一年 5.2 万美元。纯工具定义，什么活都没干。

这不是「优化」，这是你在给「让模型知道有哪些工具」这个动作付费，而且付的是无限期的。

机制二：工具返回值必须可被模型读，这是个架构性约束。

MCP 工具的返回值要能被模型读进上下文。而模型只能读文本。所以任何工具想返回复杂数据，都得把数据编码成结构化文本。

问题来了——这个编码过程是有损且低效的。

leanrea 那组 Electron 的数据是极端案例：47.9 秒，140 MB 的 JSON。因为 app.asar 是个打包后的完整应用，解出来的 AST 节点、source map、字符串表、依赖树全都要塞进返回值。这 140 MB 里绝大部分对「回答用户问题」没有用，但工具层没法判断——它必须完整返回，因为 schema 说这是它能给的。

裸命令没这个问题，因为它根本不进 LLM。asar extract 到目录，rg -uu 去搜，管道接上，中间那份 140 MB 从来没有变成文本，也从来不需要付费。

这就是工具层的本质困境：它为了能被 Agent 复用，必须把数据变成 Agent 能读的形状；一旦变成可读的形状，就进入了计费维度。

顺便说，这也解释了为什么今天 OpenCode 2 的 codemode 设计（agent 写 JS 脚本批量调工具）在架构上是对的——它让中间结果留在代码里，只把 print 出来的部分送进模型。Spirit Room 那份抓包里说得很清楚：OpenCode 2 里 agent 写的脚本从 server 拉了 2.4 MB，过滤后的答案是 188 token。

2.4 MB 进，188 token 出。中间那 2.4 MB 是代码在处理，不是模型在处理。

机制三：工具越多，「选错」的概率越高。

这一条是隐性的，但抓包数据给了它一个硬数字：99 个工具里，2 个占了整个列表的三分之一权重。

为什么两个工具能占三分之一？因为工具定义的大小极不均匀——一个查数据库的工具和一个只返回一句静态文本的工具，定义差几百倍。而模型的注意力对列表里「看起来信息量最大」的那几个格外关注，剩下的长尾基本是背景板。

作者的做法很聪明也很便宜：加一个 start_here 工具，作为入口做聚合。加完之后，4 工具版和 99 工具版在「第一步选对」这个测试上都是满分（12/12 和 24/24）。

意思就是：99 个工具带来的能力，一个入口工具 + 4 个真正常用的工具，就能覆盖。 剩下的 95 个是纯粹的上下文税。

这一条我觉得是全文最实用的洞察，因为它意味着「砍工具」不等于「做减法设计」，你只需要做一个 30 行的小聚合层就能把税降下来。

机制四：工具链把 Agent 的「弱点」固化了。

这一条是我的个人判断，数据支撑弱一些，但我觉得值得说。

一个强模型的默认策略是「我自己想办法」——它会写 Bash、会查文档、会试错。而一个挂了 207 个工具的 Agent，默认策略变成「我找一个合适的工具调用」。

后者的上限受限于工具集里有什么，前者的上限受限于模型本身。

论文的整个结论本质上就是这一句话的实验版本：Malena 给模型的是 shell 和文件系统，不是工具集；然后发现结果比工具集更好。

这也解释了一个反常现象——为什么 Opus 这个级别的模型在 Claude Code 里表现这么好，而现在很多人在用开源模型（7B-30B 那个量级）时，收益要小很多。因为弱模型自己想办法的能力弱，它真的需要工具集来代替自己思考。

所以「工具越少越强」这条规律有个明确的适用边界：模型越强越成立。 弱模型上它是错的。

五、NVIDIA 用一个数字承认了另一件事

还有一个材料，它跟性能无关，但跟前面所有材料是一体的。

NVIDIA 的 SkillSpector 上榜了（20,838 星）。它不是性能工具，是安全扫描器。README 里那组数字：

在 31,132 个 skill 的分析子集里，26.1% 含漏洞，5.2% 高度疑似恶意。

它覆盖 71 种漏洞模式、17 个类别：prompt injection、数据外泄、权限提升、供应链、过度自主权、输出处理、系统提示泄露、记忆投毒、工具滥用、rogue agent、anti-refusal、trigger abuse、危险代码 AST、污点追踪、YARA 签名、MCP 最小权限、MCP 工具投毒。

然后它进了 NVIDIA Verified Skills 流水线——扫描、评估、签名、发布，通过了才进 NVIDIA 的 skill 目录。

这里有个时间点值得算一算。

obra/superpowers 今天 303,039 星，mattpocock/skills 299,629 星。也就是说 Skills 协议现在有三十万星级别的社区体量。三十万个 skill 里，四分之一有洞，其中 5% 大概率是故意的。

这个比例跟 npm 生态 2018 年那会儿差不多。你回忆一下 2018 年发生了什么——event-stream、左侧 pad 事件、ua-parser-js 劫持。npm 花了大概三年，加上 Dependabot 和 GitHub Advisory Database，才把「安装即信任」这个模型勉强打上补丁。

Skills 协议现在正在原地重演这一段，只不过这次的执行者是 Agent，不是人。

而且这次更糟一层。人装一个 npm 包，最坏情况是人被诱导执行了一段代码。Agent 装一个 skill，拿到的是这个 Agent 的全部信任——它可以读写文件、可以调工具、可以改自己的记忆。SkillSpector 那 17 个类别里，「memory poisoning」和「rogue agent」是 npm 时代不存在的类别，因为 npm 包不会自己写笔记。

六、最扎心的一句：这是笔正在贬值的投资

论文里那句话我反复看了几遍：

effort spent elaborating harnesses around a model that is already strong at working autonomously has poor returns

它说的是「回报差」。但我觉得更准确的说法是「这笔投资在持续贬值」。

看论文自己那张表——Gemma 4 31B 上 MLEvolve 还能赢，GLM 5.2 上就赢不了，Kimi K3 上更赢不了。这个趋势是单调的、不可逆的，方向就是模型能力上升、Harness 边际收益下降。

也就是说：

你在 Harness 上投的每一小时，都在等一个必然到来的贬值日。而且你不知道那天是哪天。

这就是为什么论文说「equal time budget 下的 no advantage」这件事比结果本身更重要——它不只是在说「现在没用」，它是在说「这条曲线在往下走」。

顺着这个逻辑再推一步，会推到一个挺冒犯的结论：

2026 年 10 月 GitHub Trending 上，DeepSeek 官方开源了自己的 Agent Harness（deepseek-harness，25.7 万星），Anomaly 的 OpenCode 22 万星，affaan-m/ECC 28.5 万星在卖「Harness 性能优化」，stablyai/orca 10 万星在卖「多 Agent 舰队指挥台」，还有 reason-network 在做 Agent 间通信协议、harp 在做多 Agent 并行终端。

这不是说它们没价值。多 Agent 运维层确实是空白，值得做。

但这里面有一层结构性的荒谬：模型厂下场做 Harness，同时有论文证明 Harness 的价值会被模型厂自己的产品持续侵蚀。DeepSeek 开源 deepseek-harness 的那一刻，也是 deepseek 后训练往前推一步、把脚手架内化进模型的那一刻。

DeepSeek 在做一件正确的事，同时这件事在做的一件对的事是让自己的开源 Harness 项目贬值。

这不是阴谋，这是脚注。

七、六件能今天就做的事

方法论说再多，不如给你能今天跑的东西。

30 分钟档：

1. 加一个 start_here 工具。 Spirit Room 实测过一个东西：99 个工具里有 2 个占了整个列表的三分之一权重。加一个「从这里开始」的入口工具之后，4 工具版和 99 工具版在「第一步选对」这个任务上都拿到满分（12/12 和 24/24）。别做工具瘦身，先做入口聚合——这是成本最低的一刀。

2. 检查你是不是走在网关后面。 如果你公司 Claude Code 前挂了统一网关或代理，tool search 可能是关着的。查一下环境变量，没有就加：

export ENABLE_TOOL_SEARCH=true

实测首次请求 143,357 → 22,446 token。这是我见过最不值当的钱——不是能力问题，是配置问题，白扔的。

3. 算一次真实账单，不是估算。 你现在对「工具定义占了多少 token」大概率没有概念。开一轮 debug 看首次请求的 input token 数，减去你的实际输入，剩下的就是工具税。如果你跑 OpenCode 1 那一行，你付的是三分之二。

4. 查你的两个最胖工具。 99 个工具里两个占了三分之一。找出你的 MCP server 里最大的那两个定义，看它们返回了什么，是不是把整份原始数据塞进字段里了。逆向、数据库导出、日志查询这三类最容易中招。

5. 扫一遍你的 skill。 SkillSpector 是 Apache 2.0，uv tool install 一条命令，71 种模式静态扫描不需要 LLM。四分之一的 skill 有洞，这不是小概率。装上，扫一遍你装的每一个。

30 天档：

6. 重写所有工具描述的第一行。 这条是 Spirit Room 明确点名的一条，因为它的机制最反直觉：Agent 看到的第一行，根本不是你写的那个 description。

看 Claude Code 那行——「113 个工具名，约 1,258 token，没有 schema」。看 OpenCode 2——「99 个工具里的 16 个，一行描述，881 token，加上一个搜索函数」。看 Codex——「一个工具名都没有」。

也就是说：你在 description 后面精心写的第三、四、五句话，在很多客户端里模型压根看不到。必须把关键信息压进第一行。

他们的改写例子也很直白：

改前  ledger_dispatch — "Dispatches the document to the configured recipient."
改后  invoice_send    — "Email an invoice (bill) to a customer. Requires an existing invoice ID."

名字里带上用户会用的词，描述第一行把同义词塞进去。用户的原话是「发账单」，模型搜的是 bill，你的工具叫 invoice_send 且描述里有 bill——两条路都通。

还有一条：不要在每个工具描述里重复一堆不相关的关键词，那会制造互相竞争的匹配项，反而更难选。这个反直觉，但我信——匹配的本质是区分度，不是召回率。

八、我被这轮打脸之后改了什么判断

我改了两条。

第一条： 「工具链越丰富，能力上限越高」这句话，我现在认为在 2026 年是错的。不是「在某些场景错」，是方向错了。工具层已经从能力放大器变成了固定成本，而这个固定成本乘以「每次请求重发」这个行为之后，会盖过它带来的收益。leanrea 的 60% token 换来 0% 准确率，这是个不能再清晰的信号。

第二条： 我一直觉得 Harness 是「模型不够强时的过渡方案」，现在我觉得这个说法还不够狠。更准确的说法是——Harness 是一个正在贬值的资产，它的折旧速度由模型厂商的后训练进度决定，而这个进度不由你控制。

这带来一个很具体的投资决策问题：如果你现在要选一个方向投入三个月，Harness 工程（编排、检索、多 Agent 协调）是一个正在缩小的池子，而 Agent 侧的安全、可观测、回归测试（今天 GitHub 上那个把生产失败冻结成回归测试的 Tracely-ai，1,166 星，方向就在这儿）是跟着能力一起变大的池子。

论文的 Table 1 里 +B+P3 那个 33.3%，我会记很久。三个 Agent 并行 + 广播，结果比一个 Agent 单独跑差了 22.4 个百分点。

这是对「多 Agent 基础设施」这整个叙事最重的一拳。

最后那根刺

今天这三份材料，指向的是同一个没人愿意承认的账：

Agent 的能力增长曲线，和 Agent 的工具账单曲线，正在朝相反方向走。

模型越强，你需要给它的工具越少。但工具越少，Skill 的相对价值越高；Skill 越多，供应链攻击面越大；而供应链里四分之一的包有问题。

你今天装的每一个 MCP 工具、写的每一个 SKILL.md、调优的每一层 Harness，都是在给一个六个月后自己就会做的模型付费。

然后这堆东西里，四分之一带着洞。

我不打算说「别用工具」。工具当然有用，逆向工程的例子已经证明它有用。

我想说的是一件更小但更重要的事：在你下一次准备给 Agent 挂第 80 个工具之前，先花五分钟算一下那 80 个工具定义加起来有多少 token。

这个数你多半没算过。

算完之后你会发现，你不是在一个功能丰富的 Agent 平台上工作，你是在一个按 token 计费的、你自己都不知道有多贵的系统上工作。

---

附：本文素材来源

主源一 · 论文 arXiv:2609.40303《How Much of a Harness Does a Strong Agent Need for Autonomous ML Engineering?》，Kirill Brilliantov / Alejandro Hernández-Cano / Emmanuel Abbé（EPFL），2026-10-22 上 HN。

关键数据：固定 backbone（GLM 5.2 / Kimi K3 / DeepSeek V4 Flash / DeepSeek V4 Pro）+ 固定硬件（1×A100 80GB / 12 CPU / 144GB RAM，vLLM 本地服务）+ 固定时间预算，Malena 单长 session coding agent 获奖率 62.5% vs 最佳外部 harness 47.1%；对比 MLEvolve / AiScientist / Arbor / ScienceFlow 四个开源 SOTA；多 agent 消融 base 55.7% / +D 45.2% / +P3 52.4% / +B+P3 33.3%；成本 Malena $12.12 vs AiScientist $1.95（6.2x，差距几乎全在 cache-read token）；结论句「Almost all of the gain comes from the runtime and LLM backbone, and almost none from what is built on top of them」。

主源二 · 抓包实测 Spirit Room《How Many MCP Tools Is Too Many? Real token costs across five agents》（2026-10-21 发布，抓包日期 2026-10-16）+《How to Optimise MCP Tools by Knowing How Agents Call Them》（2026-10-16 发布，10-21 更新），作者 Leonid Bugaev。

关键数据：99 工具生产 server 定义 68,286 token（o200k_base compact JSON）；首次请求增量 Codex +0 / Claude Code 默认 +1,715 / OpenCode 2.0 约 +5,270 / OpenCode 1 +73,415 / Claude Code 关 tool search +107,541；OpenCode 1 40 次实跑平均 3.7 请求/问题 → 约 230k token 纯工具定义/问题（总输入 341,615，Claude Code 222k / Codex 221k）；ENABLE_TOOL_SEARCH=true 使首次请求 143,357 → 22,446；Codex 80 次实跑 8 次未找到工具（5-19%），搜索前烧 40k token，Claude Code 40/40 找到；99 工具里 2 个占三分之一权重，加 start_here 后 4 工具版与 99 工具版均满分。

主源三 · 第三方 benchmark GitHub aicodeking/leanrea（2026-10-17 建仓，今日 1,306 星，Python），README 实测数据。benchmark：Claude Code headless / Sonnet 5.5 / macOS arm64 / 4 任务 × 3 reps × 3 arms 并排；leanrea 388s $2.17 55 turns 2.40M tokens 74 分 vs REA 627s $3.36 124 turns 5.93M 75 分 vs 无 skill 479s $2.21 81 turns 3.11M 67 分。单操作：Go build info REA 0.56s vs go version -m 0.06s；Mach-o REA 3.32s vs otool+dyld_info+nm 0.04s；Electron REA 47.9s + 140MB JSON vs asar extract + rg -uu 4.8s + 24KB。作者 caveats：仅 3 reps / 单模型 / 单机；Ghidra/Hopper/jadx 未安装；作者明确指出「对 REA 的增益远大于对无 skill 的增益」。

被测对象 morluto/rea 今日 356,006 星，单日 +9,977，连续第八周上榜。

主源四 · 供应链侧 GitHub NVIDIA/SkillSpector（20,838 星，Apache 2.0，topics: agent-security / supply-chain-security / mcp 等）。README：31,132 skill 分析子集中 26.1% 含漏洞、5.2% 高度疑似恶意；71 种模式 / 17 类别；已接入 NVIDIA Verified Skills 流水线（扫描→评估→签名→发布）。对照 Skills 生态体量：obra/superpowers 303,039 星、mattpocock/skills 299,629 星。

交叉来源

• deepseek-ai/deepseek-harness 今日 256,865 星（单日 +897）——模型厂下场做 Harness
• stablyai/orca 100,934 星（+1,469）/ reason-machines/reason-network 890★ / dominikmartn/harp 509★ / jwuthri-cloud/Tracely-ai 1,166★ —— 多 Agent 运维层在拆标准件
• affaan-m/ECC 285,434 星（+736）—— Harness 性能优化系统，对应 HarnessTax 论点的可执行版本

以上 star 数为 2026-10-22 12:00 抓取，均已通过 api.github.com core API 实测，未采用 trending 页 HTML 字段。