🤖 AI

When Does Restricting a Coding Agent to execute_code Help? A Regime $\times$ Agent-Design Ablation

本文表明，将编码智能体限制在单一的 `execute_code` 工具上，其效果往往与使用丰富的工具环境相当，且通常成本更低，这揭示了最优工具集是由任务机制与特定智能体设计之间的相互作用共同决定的，而非由其中任何一个因素单独决定。

原作者： Hong Yang, Qi Yu, Travis Desell

发布于 2026-07-14

📖 1 分钟阅读☕ 轻松阅读

原作者： Hong Yang, Qi Yu, Travis Desell

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你有一个超级聪明的机器人助手，它的工作是修复损坏的代码或解决数学难题。现在，科技界正就这个机器人应该如何与计算机交流以完成任务展开一场巨大的辩论。

有人说：“给它一个功能齐全的工具箱，为每项任务都准备好专门的按钮！”（就像一个高级 IDE）。
另一些人说：“直接给它一个命令行，让它输入 shell 命令就行了！”（就像电影里的黑客）。
第三组人说：“不！让机器人写一段 Python 脚本并一次性运行它就好！”（即 execute_code 方法）。

这篇论文就像是一个巨大的、公正的裁判，通过设置一场比赛来观察哪种方法实际上最省钱且效率最高。他们并没有凭空猜测；他们让同一个机器人（两个不同的模型：Claude 和 Codex）在完全相同的任务上运行，但仅仅改变了它们被允许使用的工具。

以下是他们的发现，通过简单的故事进行了解析。

核心发现：这取决于机器人和任务

最大的惊喜在于：并没有一个单一的“最佳”工具。谁是赢家取决于机器人是谁以及它正在做什么。

可以这样理解：

“数学谜题”类任务 (Artifact Tasks)： 如果机器人是在进行计算或数据处理，那么“编写脚本并运行”的方法（code_only）是明显的赢家。这就像雇佣了一位厨师，他只需写出一个完美的食谱，然后一次性把整顿饭做完。
- 对于 Claude 机器人，这种方法节省了 24.6% 的成本。
- 对于 Codex 机器人，它节省了大约 6.7%（尽管论文指出这一结果有些波动，有点像抛硬币的结果）。
- 结论： 对于数学和数据，脚本方法更便宜，且解决问题的能力同样出色。
“修复混乱代码库”类任务 (SWE-bench Tasks)： 这类任务比较棘手。它们涉及编辑复杂项目中的许多文件。
- 如果你使用 Codex 机器人： 脚本方法仍然是冠军！它节省了 19.9% 的成本。为什么呢？因为脚本方法可以让机器人将许多小的请求打包成一个大包裹，就像一辆货运卡车一次运送 50 个包裹，而不是一个人走 50 趟。
- 如果你使用 Claude 机器人： 哎呀。脚本方法实际上变得更贵了（增加了 14.4%），尽管论文指出这一差异在统计学上并非“确定无疑”，只是一个强烈的趋势。为什么？因为对于 Claude 来说，写一个脚本来编辑文件，就像是为了换个轮胎而先造出一辆新车一样。解释这些编辑操作需要消耗太多的文字（token），产生了“编辑摩擦”。

这篇论文排除了什么

论文明确反对“一种工具界面对所有人始终更好”的观点。

它排除了： “特殊的 IDE 按钮是始终必需的。”（因为脚本方法在 Codex 上胜出了）。
它排除了： “Bash 命令是始终足够的。”（因为在 Claude 处理数学任务时，脚本方法更便宜）。
它排除了： “代码执行始终是最便宜的。”（因为在处理复杂的代码修复时，它对 Claude 来说更贵了）。

作者非常明确：你不能仅仅根据工具本身来选择工具。你必须观察机器人的大脑与工作类型之间的组合。

“通过率”的惊喜

这里是最重要的一部分：成本发生了变化，但成功率却没有变化。

想象两个跑步者。一个穿着沉重的靴子（昂贵的工具），另一个穿着运动鞋（便宜的工具）。论文发现，两名跑步者完成比赛的速度完全相同。

无论机器人使用的是高级工具箱、bash 命令还是脚本方法，它们正确解决任务的百分比几乎是一样的（差距在 3 个百分点以内）。
“脚本”方法并没有让机器人变得更聪明或更笨；它只是改变了机器人走向终点的方式。有时候这种行走是冲刺（便宜），有时候则是踉跄（昂贵）。

为什么成本会发生变化？

论文深入探讨了脚本方法为何更便宜或更贵。

“编辑摩擦”税 (针对 Claude)： 当 Claude 需要使用脚本方法来修复文件时，它必须写一段很长的 Python 脚本来仅仅表达“修改第 5 行”。这消耗了大量的“输出 token”（机器人必须输入的文字）。这就像你每次想翻页时都要交一笔过路费。这种情况主要发生在机器人失败或遇到困难的任务中，使得这些特定的运行过程变得非常昂贵。
“批处理”红利 (针对 Codex)： 当 Codex 使用脚本方法时，它可以将许多小命令打包进一个脚本中。与其向计算机请求“读取文件 A”，然后再“读取文件 B”，最后“读取文件 C”（三次独立的行程），它会一次性要求“读取 A、B 和 C”。这节省了大量的“输入 token”（机器人需要阅读的文字）。
“注定失败的运行”效应： Claude 在代码修复任务上的额外成本，主要发生在机器人已经注定会失败的时候。这就像一辆车在原地打转时耗尽了汽油。脚本方法并没有导致失败；它只是让失败的尝试变得更贵了。

我们有多确定？

作者对数学任务和 Codex 机器人结果非常有信心。他们在 93 个数学任务和 100 个代码修复任务上进行了测试，并为每个任务使用了三个“种子”（随机起点），以确保结果不是偶然。Codex 在代码修复任务上的节省具有统计学意义（19.9% 的降幅，p 值为 2.0 × 10⁻⁹，这意味着几乎不可能纯属巧合）。

然而，对于代码修复任务中的 Claude 机器人，结果则有些模糊。成本上升了 14.4%，但统计测试显示这并不是一个“板上钉钉”的证明（p 值为 0.12）。作者称之为“方向性”的结果，意味着趋势确实存在，但他们需要进行更多次的测试才能 100% 确定这不是一次偶然。

总结

如果你正在构建一个编程智能体：

不要靠猜。 “最佳”工具取决于你的特定机器人和你的特定工作。
对于数学/数据： 尝试“编写脚本”的方法。它更便宜，效果也一样好。
对于代码修复： 视情况而定。如果你使用 Codex，脚本方法很棒。如果你使用 Claude，你可能希望保留标准的编辑工具，特别是在处理难题时，因为脚本方法可能会陷入“编辑摩擦”的泥潭。
不要担心智能问题： 改变工具不会让你的机器人变得更聪明或更笨；它只会改变旅程的价格标签。

论文的结论是：运行智能体的“最便宜”方式并不是一个普适的规则；它是一个谜题，你必须将工具与机器人和任务进行匹配。

技术摘要：何时限制编码智能体使用 `execute_code` 会有所帮助？

问题陈述

当前编码智能体领域在关于最优“工具表面”（即暴露给智能体的接口集）的问题上存在三种互不兼容的主张：

需要专门的 IDE 原语： 结构化接口（例如智能体计算机接口或 ACI）的表现显著优于原始 shell 访问，正如 SWE-agent 所论证的那样。
Bash 足矣： 最简化的仅限 bash 的脚手架可以在不使用 IDE 原语的情况下，在软件工程基准测试中达到具有竞争力的性能。
代码执行是最优的： 通过单一的 execute_code 工具（通过模型上下文协议，MCP）路由智能体动作，与直接调用原生工具相比，可以大幅减少 token 使用量。

先前的研究未能解决这些矛盾，因为现有的研究通常固定了一个变量（例如，在特定模型上比较 ACI 与 shell），而没有跨越任务范式（计算型 vs. 代码修改型）和智能体设计（不同的模型家族）。因此，该领域缺乏一个统一的理解，即在何种条件下更倾向于使用哪种工具表面。

方法论

作者进行了一项“缺失的交叉对比”，采用了一个完整、三臂消融研究。实验设计采用了 $3 \times 2 \times 2$ 的因子设计结构：

三种工具表面：
- 基准 (Baseline)： 智能体的默认工具表面（例如 Read, Grep, Edit, Write, Bash）。
- 仅限 Bash (Bash_Only)： 仅限于原生 bash 加只读浏览（Read, Glob, Grep）；移除了所有文件编辑原语（Edit, Write）。
- 仅限代码 (Code_Only)： 整个原生表面被替换为一个运行持久化 Python+Bash REPL 的单一 MCP 工具 (mcp__codebox__execute_code)。所有原生内置工具均被禁用。
两种智能体： Claude Code (模型 claude-sonnet-4-6) 和 OpenAI Codex CLI (模型 gpt-5.5)。
两种任务范式：
- 计算型 (Computation)： 一个新的 “Artifact” 套件（ $n=93$ ），由包含工作区、隐藏评分器和参考输出的自包含任务组成。
- 修改型 (Modification)： SWE-bench Mini（ $n=100$ ），一个经过筛选的仓库修改任务子集。

实验控制：

完整性： 测试框架强制执行严格的 SWE-bench 协议，即测试补丁在智能体终止后才应用。使用 fuse-overlayfs 在不同实验组之间隔离文件系统状态，以防止交叉污染。
成本核算： 为了应对服务端提示词缓存的变异性，作者采用了“缓存调整成本”指标。该指标对首轮输入 token 应用中位数下限调整，从而在不声称实现完全缓存隔离的情况下，使“热/冷”缓存的随机性归一化。
统计严谨性： 推断单位是任务而非种子。结果通过对三个独立种子之间的单任务差异进行配对 Wilcoxon 符号秩检验进行分析。

核心贡献

1. 四单元格智能体条件成本结构

研究表明，将智能体限制在 execute_code 的成本效益并非普适，而是由任务范式和智能体设计共同决定的。

四个单元格中有三个有利于 code_only：
- Artifact/Claude： 显著降低成本 ( $-24.6\%$ , $p=7.4 \times 10^{-14}$ )。
- Artifact/Codex： 方向性降低成本 ( $-6.7\%$ , 不显著)。
- SWE-bench/Codex： 显著降低成本 ( $-19.9\%$ , $p=2.0 \times 10^{-9}$ )。
一个单元格趋势反转：
- SWE-bench/Claude： code_only 在方向上成本更高 ( $+14.4\%$ , 不显著)。

这一发现证明，文献中的三个先前主张并不矛盾，它们仅在特定的（范式, 智能体）组合下成立。

2. 三机制因果分解

作者将观察到的成本差异分解为三个不同的机制：

路径成本 (编辑摩擦/Edit Friction)： 对于 SWE-bench 上的 Claude，code_only 迫使每次文件编辑都必须以 Python 脚本的形式表达。这使得输出 token 随编辑量而缩放（Spearman $\rho=0.488$ ），从而在处理高编辑量任务时产生了“税收”。
失败成本 (Failure-Cost)： Claude 在 SWE-bench 上的成本超支集中在“注定失败”的轨迹中（即所有实验组都失败的实例）。在全票通过的子集上，成本差距从 $+14.4\%$ 收缩至 $+4.1\%$ （不显著）。
定价不对称 (批处理/Batching)： 对于 SWE-bench 上的 Codex，code_only 主要通过输入 token 减少（ $-24.8\%$ ）实现了显著节省。这是由于工具调用的批处理（一个 Python 脚本取代了多个原生工具调用）以及程序化输出抑制（智能体约束了输出量，避免了原生工具的硬性输出上限）驱动的。

3. 能力不变性

在所有四个单元格和三种工具表面中，通过率在统计上是持平的（差异 $<3$ 个百分点，均不显著）。

一致性矩阵显示，对于大多数实例（多数投票下 $\ge 91\%$ ），所有实验组要么同时通过，要么同时失败。
这证实了工具表面选择改变了解决任务的路径和成本，但并未改变解决任务的能力，这与“能力重叠原则”一致。

结果总结

论文提供了一张关于何时 code_only 有益的“一目了然”图谱：

计算型任务 (Artifact)： 将其限制在 execute_code 对两种智能体来说都更便宜，其中 Claude 的收益显著。
修改型任务 (SWE-bench) 配合 Codex： 限制在 execute_code 由于输入 token 批处理和输出控制，成本显著降低。
修改型任务 (SWE-bench) 配合 Claude： 限制在 code_only 在方向上成本更高。这是由“编辑摩擦”（编辑时产生更高的输出 token）和“失败成本”（昂贵的失败轨迹）驱动的，而非由于成功的编辑带来的惩罚。

意义与主张

本文通过证明没有任何单一工具表面在所有上下文中都是最优的，从而解决了该领域的“三个矛盾主张”。

成本 vs. 能力： 工具表面选择的核心信号是成本，而非通过率。由于通过率是不变的，因此工具表面的选择是一个成本工程决策，而非能力增强手段。
共同决定： 最优表面由任务范式（计算型 vs. 修改型）与特定智能体实现（如何处理批处理、输出上限和编辑原语）的交集决定。
经验实证： 本研究提供了支持编码智能体中“工具使用税”不等性的首次经验证据：只有当工具表面的特定任务能力增益超过其定义的单次调用成本时，该工具表面才能带来净收益。

作者明确指出，他们的发现是成本工程主张，而非能力主张。他们既没有提出 code_only 是普遍优越的，也没有声称其结果在未经进一步验证的情况下可推广到所有模型或外部 MCP 工具。其意义在于提供了一个能够区分智能体设计与范式效应的实验方法论框架，使该领域从轶事性的行业报告转向受控的、交叉消融研究。