Coding Agent 的「外挂」到底哪个有用？176 组对照实验给出第一张价目表

💡 一句话总结：每个 coding agent 产品都在堆功能——加规划、做上下文摘要、造一堆工具。但这些组件各自的边际价值没人测过。这项研究做了 agent 工程界少见的受控实验：固定执行循环、只换一个组件、176 组对照。结果颠覆几个流行直觉：planning 对强模型不涨精度只省钱；给 bash 强模型配预定义工具纯属浪费钱。

导语：agent 外壳的「堆料」时代该结束了

现在的 coding agent（Claude Code、各类开源 harness）都长着相似的脸：任务规划器、一堆预定义工具、上下文压缩摘要……这些组件不是拍脑袋来的——每个都有出处——但「它们各自值多少钱」从来没人算过。

这造成了工程界的尴尬现状：有人在给 GPT 级模型上三重上下文管理，有人发现裸 bash 就够用；有人坚信 planning 提升质量，有人砍掉规划反而更快。大家都在凭信仰调 harness。

UMass、Emory 和 Zoom 的团队做了 agent 工程界久违的事：把 harness 拆开，固定其他一切，一次只换一个组件，176 组对照实验，把每个组件的边际价值标上价签。

想看原文？

• 📄 论文：arXiv 2609.20804

它的思路是什么？

• 🧪 受控实验设计：执行循环固定不动，三个组件单变量轮换——planning（开/关）、action space（纯 bash vs 预定义工具）、context management（5 种策略 × 4 档预算）
• 📊 双基准四模型：SWE-Bench Verified + Terminal-Bench 2.1；Nemotron-3 三个尺寸 + Mistral-Medium-3.5-128B——强模型与弱模型分开看
• 🔬 轨迹级归因：不止看分数，还看轨迹怎么变的——上下文管理延长轨迹而不改行为、planning 改变轨迹停在哪、action space 改变写码粒度

效果到底怎么样？（四大发现）

• 🌊 上下文管理的价值随预算收紧而暴涨：便宜模型配小上下文时，它的收益主要来自防止上下文溢出崩溃——是保险，不是引擎
• ✂️ 规则删节 > LLM 摘要：先用规则删（老日志、重复输出）再上 LLM 摘要的混合策略整体效率最强；而「把删掉的内容存起来供恢复」这个精巧机制——模型很少用，零精度收益
• 💰 planning 的角色翻转：对弱模型它是精度脚手架（没它做不完任务）；对强模型精度几乎不变、纯粹是省钱器（少走弯路少烧 token）
• 🖥️ bash 强模型不需要工具全家桶：bash 能力强的模型用纯 bash 接口干得一样好、成本大幅更低——命令行中心任务尤其明显；预定义工具真正帮到的是 bash 弱的模型

为什么你要关心？

• 🛠️ harness 配置有了决策树：预算紧 → 先上上下文管理；模型 bash 强 → 砍工具裸 bash；模型强 → planning 降级为省钱选项——按「模型能力 × 预算」配置，别按信仰
• 💸 「可恢复删节」类精巧设计先测再用：工程直觉里优雅的机制，实测可能没人用——组件上线上前先做这样的消融
• 📐 评测方法论可直接搬：固定循环 + 单变量轮换 + 轨迹级归因，这套实验设计适用于一切 agent 系统的组件评估

理性看待

冷静看三点：SWE-Bench 仅 Python，多语言结论待验；模型尺寸不是能力的完美代理（作者自认）；报告的交叉点数字换模型族需要重测。但这张「组件价目表」的价值不在于具体数字，而在于它示范了正确的问题：不是「要不要加这个组件」，而是「这个组件对我的模型和预算值多少钱」。