# 更强的编码智能体，反而需要更少的工具？ **Summary:** 在176种配置下，上下文管理、规划和工具的价值随模型和任务而变化。我建议在添加新组件前，先评估模型与框架的匹配度。 - Canonical: https://markhuang.ai/zh/news/stronger-coding-agents-fewer-tools - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-18 - Section: News - Tags: 编码智能体, 智能体框架, 上下文管理, 开发者工具, AI评估 - Source: [arXiv](https://arxiv.org/abs/2609.20804) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![一个发光的编码模型核心连接到可互换的规划、记忆和工具模块，置于工程测试台上](https://cdn.markhuang.ai/news/stronger-coding-agents-fewer-tools/hero.webp) *编码模型并非孤军奋战。围绕它的外围组件可能挽救一次运行，可能白白烧掉token，也可能反而碍事。* 新论文《[编码智能体框架设计的实证研究](https://arxiv.org/abs/2609.20804)》测试了176种配置，涵盖四个模型、两个编码基准、五种上下文管理策略，以及从32K到128K token的上下文预算。没有一种配置能通吃。 我认为这个复杂的答案恰恰最有价值。团队应该停止把规划、记忆和专用工具当作必选项清单。每个组件都必须应对模型实际出现的问题。较弱的模型可能需要更多结构才能完成首次编辑。而具备shell能力的模型，用一个通用接口可能比一堆专用工具效果更好。 ## 上下文管理主要保障生存 最清晰的结果来自上下文管理。研究人员比较了无管理与四种管理策略：省略旧工具输出、让旧输出可恢复、总结早期历史，或组合这些机制。在SWE-Bench Verified上，有管理相比无管理的成功率优势从32K token时的35.7个百分点降至128K时的2.7个百分点。在Terminal-Bench 2.1上，这一优势从9.5个百分点降至2.8个百分点。 原因并不浪漫。没有管理时，运行经常因达到窗口上限而停止。在32K时，模型平均溢出率在SWE-Bench上为78.7%，在Terminal-Bench上为61.0%。所有管理策略在所有测试预算下都实现了零溢出失败。 这几乎不支持“摘要能让智能体更聪明”的观点。在这个实验中，上下文管理主要是让智能体活到能编辑和验证的阶段。随着窗口增大，无管理运行的存活率提高，准确率提升几乎消失。 组合策略整体效率最佳：先移除冗余的旧工具输出，仅当历史仍超过更高阈值时才进行摘要。它在八个模型-基准组合中的七个里实现了最低平均成本。然而，为省略内容添加的恢复工具很少被使用，且并未比单纯省略带来更高的准确率。一个功能听着再让人安心，也未必挣得到自己的位置。 ## 更强的模型可能偏好更小的工具包 行动空间的结果值得在产品评审中讨论。在论文的128K基线设置下，30B Nemotron模型在SWE-Bench上使用预定义文件和搜索工具时得分为25.2%，但仅用bash时仅为10.2%。而550B模型则相反：使用预定义工具时为65.8%，用bash时达到69.4%，同时平均每任务成本从2.33美元降至1.11美元。 大模型并非简单地“更擅长工具”。bash让它能把操作组合成更粗粒度的动作。在Terminal-Bench上，它的中位轨迹长度从47步降至31步，其中编写代码的动作占比也更高。更窄的接口减少了往返次数。 但这不意味着只用bash就是万能方案。Mistral-Medium-3.5-128B在移除预定义工具后，SWE-Bench得分从68.6%降至45.4%，尽管它在Terminal-Bench上的结果朝相反方向变化。模型规模不能简单等同于shell熟练度，任务类型仍然关键。 > **Info:** > > 我会从最小的框架开始，只要能让特定模型可靠完成代表性任务就行。当轨迹显示出现了某个组件旨在解决的问题时，再添加该组件，并重新测量准确率和成本。 ## 规划可以是一种停止策略 随着能力提升，规划的作用也在变化。对于SWE-Bench上的30B模型，移除持久化规划后，中位轨迹长度从40轮降至5轮。没有规划时，68.6%的运行在未编辑前就结束了。规划将成功率从13.6%提升至25.2%，但平均任务成本从0.02美元升至0.09美元。 对于更强的模型，规划并未以同样方式显著提升准确率。它主要减少了编辑后的重复验证。启用规划后，550B模型的SWE-Bench中位轨迹从108轮降至74轮，Mistral模型从68轮降至53轮。 我通常认为规划是开始工作的路线图。这篇论文让我重新思考运行收尾阶段的作用。持久化规划可以告诉犹豫的模型继续前进，也可以告诉过度活跃的模型承诺的工作已经完成。无论哪种情况，它的价值都体现在轨迹停止的位置。 ## 证据的边界 论文坦诚地说明了局限性。每种配置每个任务只运行一次。Terminal-Bench包含89个任务，因此其中许多比较并不具备统计显著性。SWE-Bench Verified包含500个Python问题，而规划和行动空间的消融实验仅在128K下使用组合上下文策略进行了测试。 工具比较也捆绑了多项变更。预定义接口包含文件状态跟踪、写前读取检查和自动诊断，而只用bash则移除了整个套件。该实验告诉我哪种完整接口在各条件下有效，但无法确定差异究竟来自工具数量、提示词、诊断功能还是动作粒度。 其他研究也指向相同方向，但未给出明确配方。《[同一模型，不同框架](https://arxiv.org/abs/2608.26218)》发现，在上下文紧张时，机械缩短旧工具结果会改变模型本身不变情况下的结果。另一项[智能体脚手架的全因子研究](https://arxiv.org/abs/2605.05716)发现，在问答和数学任务上，全组件配置并非最优。细节虽有不同，但两者都挑战了“更多脚手架等于更强系统”的习惯思维。 ## 我会把模型和框架作为一个整体来版本化 这项研究强化了我之前[提到的观点](https://markhuang.ai/news/astra-arc-score-45-1-point-harness-gap)：Astra的ARC分数因框架变更移动了45.1分——产品远不止一个模型名称。这里，研究人员通过调整单个部件并观察轨迹变化，将这一观点落到了实处。 做采购决策时，我会把模型、框架版本、上下文策略、规划协议、工具接口、token预算和任务类型记录为一个经过测试的整体。然后保留一个小的评估集，用于暴露过早放弃、上下文溢出、shell错误和过度验证等问题。这些失败分类能告诉我哪个组件值得再试一次。 我不会因为一篇论文就把所有强编码智能体简化为bash。我在要求每一层都证明自己的价值。如果规划节省了token，就保留它。如果压缩只是为了防止生产环境永远不会遇到的32K人工上限，那就如实评估这一收益。如果专用工具拖慢了已经精通shell的模型，就移除它们。我想要的脚手架规模，应该恰好匹配我面前的实际问题。