execute_code 工具面限制实验

execute_code 工具面限制实验

这篇论文研究一个很实际的问题：在 coding agent 中，把 agent 限制到 execute_code / MCP code-execution 这类较窄工具面，什么时候会比暴露 bash/IDE primitives 更好？作者做了三臂 ablation：baseline、bash_only、code_only，并在合成计算任务与 SWE-bench Mini 修改任务上比较 Claude Code 与 OpenAI Codex CLI。

为什么对用户重要

Hermes 的工具面设计直接影响任务质量、成本和风险。直觉上，“工具越多越强”；但这篇论文提醒：工具面是 Harness-Engineering 的核心变量，不同任务 regime 与不同 agent design 下，窄工具面可能降低成本、减少无关探索，也可能增加编辑摩擦或削弱系统操作能力。

对用户来说，这尤其相关：当前 Hermes 同时有 terminal、read_file、search_files、patch、write_file 等工具。什么时候应该鼓励 agent 用窄而确定的工具，什么时候必须开放 shell，是一个可被实验化的问题，而不应只靠偏好。

机制 / 一阶原理

论文的关键框架是 Capability Overlap：如果一个任务需要的能力与 execute_code 工具面高度重合，那么 code_only 可以减少路径成本和工具选择成本；如果任务需要文件系统、依赖安装、复杂 shell、版本控制或交互式调试，过窄工具面就会造成绕路。

三类成本可以分开看：

1. Path-cost：完成同一修改需要多少步、多少 token、多少工具调用。窄工具面在计算型任务中可能更短，在仓库修改中可能因编辑/探索能力不足而更长。
2. Failure-cost：工具选择错误、环境假设错误或无法观察状态会造成失败重试。
3. Pricing / batching asymmetry：不同 agent/tool API 的 token 计费、批处理和输出控制不同，导致同一工具面在不同系统上成本不同。

这和 did-it-claim-evidence-reconciliation 的思想互补：工具调用不仅要发生，还要能被审计；工具面越宽，越需要 receipts 和 gate。

与既有 wiki 概念的关系

• 对 Agentic-Coding：它把“agent 能不能写代码”拆成 tool-surface × task-regime × agent-design 的交互，而不是只看模型名。
• 对 Harness-Engineering：工具暴露策略就是 harness。限制工具不是保守主义，而是用环境结构塑造行动路径。
• 对 Agent-Benchmarks：评测报告应记录工具面，否则不同 harness 下的分数不可比。

对 Hermes / llm-wiki 的可执行启发

1. 保持当前“文件读取/搜索/patch 优先，terminal 用于执行/系统命令”的工具纪律是合理的：它相当于把常见编辑操作放在可审计窄工具面，把高权限 shell 留给真正需要的步骤。
2. 未来可以给 Hermes 任务报告增加 tool-surface 统计：用了哪些工具、哪些本可用更窄工具完成、哪些必须 shell。
3. 对无人 cron，默认应偏向窄工具面与确定性 helper：例如 search_files/read_file/patch 优先于临时 shell 脚本；但 arXiv/RSS/API 抓取这类网络批处理仍适合 terminal Python。

失败模式 / 边界

• 论文是特定 benchmark 与 agent 的 ablation；结论不能直接推广成“永远禁 bash”或“永远开放 bash”。
• 过度限制工具会让 agent 绕过约束，例如用代码生成 shell side effects；因此限制必须配合 sandbox、权限和审计。
• 如果任务合同不清楚，窄工具面可能只是让失败更安静，而不是更安全。

写入记录

• 2026-07-14 09:00 CST：新增 execute_code 工具面 ablation 来源页，提炼 tool-surface × task-regime × agent-design 对 Hermes 工具纪律的启发。