编码 Agent 为什么开始只用 Bash：一线 Agent 工程师的 Harness 瘦身实录

如果你最近用过编码 Agent，可能已经注意到一个变化：它们开始用 Bash 去做过去由 read、edit、search 这类专用工具负责的事。原因不复杂——前沿模型在 Bash 上已经达到”超人类”水平，专用工具在它眼里反而成了限制。

Philipp Schmid 是 Google DeepMind 负责 Gemini 与 Gemini API 全部 Agent 相关工作的工程师。他有个独特习惯：每隔几个月就从零重写一次自己的 Agent Harness，目的是搞清楚”什么变了、什么可以删掉”。这一轮实验，他把模型可用的工具删到只剩两个：一个 Bash，一个媒体查看器。

结果如何？任务完成率保持在同一水平，而 Agent 在复杂工作和验证环节的移动更少受工具边界掣肘。

“Bash 超人类”到底是什么意思

Schmid 特意说明这是狭义定义：编码 Agent 能在几秒内合成出一次性的命令行程序，而大多数开发者组装并验证同样的程序需要长得多的时间。

单看零件——git、rg、jq、Python、临时文件、进程替换、测试运行器——你可能都熟。真正的差异在”时间压力下一次性把 40 行工作流正确拼起来”。人类开发者通常逐步交互地解决，每步之间检查语法和状态；编码 Agent 则从 POSIX 工具、编程语言、构建系统和公开源代码中学到的模式里直接组装整段编排。它仍会犯错，区别是一次性能尝试多少正确的编排。

Bash 在这里充当路由层：重活可能发生在 Python、Git、SQLite、编译器或项目专属 CLI 里，一个 Shell 接口让 Agent 组合调用全部能力，而不需要运行时设计者预测每一种有用的操作。

三个来自真实 Agent 轨迹的例子

以下是从 Schmid 个人 Agent 轨迹简化的实例。

实例一：多文件原地改名

场景：把一个变量在实现、调用方和测试里全部改名。

Agent 的做法是合成一段 Python 脚本：先把每个文件里旧代码片段的出现次数数清楚，任何文件匹配数不对就整体退出、一行不改；全部对齐后才一次性写入四文件改名。写完后自动跑格式化、lint、类型检查、聚焦测试，最后打印紧凑 diff。失败检查留在工作树里，下一轮可以直接查看并修复——“先验证再收工”的循环就是 Agent 的内循环。

这个模式的价值：它把”跨文件重命名”这种传统上要专用 AI 重构工具的任务，变成了一段自校验的命令行程序，且中途任何异常都会安全中止而不是留下半改状态。复用这个思路，把你的改名对照表写进同样的脚本结构，就能让任意编码 Agent 安全处理批量代码改名任务。

实例二：复现并二分定位间歇性故障

场景：某个测试只是偶尔失败，要找出引入抖动的第一个 commit，还不能动当前工作区。

Agent 合成的脚本用了几个关键手法：git worktree 建独立临时检出，本地文件原地不动；git bisect run 自动二分；每个 commit 用 5 个随机种子跑测试，失败少于 3 次才算”好”——单次不走运不会污染二分结果；结束后自动清理 worktree，打印首个坏 commit、可疑改动的截断 diff 和日志尾部。

你得到的是一份诊断结论，而不是把每一次测试运行都灌进上下文窗口。

实例三：聚合超限的生产日志

场景：压缩生产日志大到无法直接加载进模型，需要失败接口、错误类别和 P95 延迟。

Agent 的方案：Python 流式读取 gz 压缩日志，逐行解析 JSON 后写入临时目录里的 SQLite；用 SQL 完成 join、P95 排序和错误类别聚合；最终只返回 5 条 JSON 摘要记录（接口、失败数、平均延迟、P95、错误类别）。中间数据全部留在环境里，只有摘要进入模型上下文——这是”上下文卸载”的标准姿势。

为什么原子工具曾经是对的

几个月前 Schmid 还主张编码 Agent 应该从健壮的原子工具开始，避免 cat、sed、echo 这类 Shell 命令——一条不小心的命令可能撑爆上下文、返回难懂的错误、或因引号问题损坏编辑。这些限制对未仪表化的 Shell 依然成立。

但前沿模型现在更擅长组合小型 Python 补丁器、Git 命令、带引号的 heredoc 和聚焦测试。与此同时，Harness 可以吸收原子工具的价值：截断超长输出并告知 Agent 如何取更窄切片（输出控制）；返回退出状态、耗时、超时状态与进程信息（诊断）；在模型之外对路径、网络、破坏性动作设闸（隔离与策略）；让 Agent 启动、查看、停止长时命令而不阻塞回合（异步进程）。

唯一的例外是多模态输入：文本输出无法把截图送进视觉模型。Shell 命令可以渲染页面、截取图表、保存视频帧，但像素仍需通过多模态通道进入模型——所以媒体查看器保留为第二个工具。

对 Harness 工程的启示

Schmid 对比了”以 Shell 为中心”与”暴露读写编辑搜索独立工具”两种 Agent 配置，在同一编码任务集同条件下跑分：Shell 中心配置的 AI 任务完成率持平或更好。

这正是苦涩教训（Bitter Lesson）在 Harness 设计上的体现：随算力扩展的通用方法胜过手工捷径，Bash 就是那个通用计算层。

但不是所有工具都该删：如果某个工具提供了更好的能力接口，就该保留。浏览器控制是典型例子——导航、点击、输入、等待页面稳定、返回截图能在一次调用里完成，比 Bash 里调 CLI 再两步传文件高效。服务集成同理，或者用 mcp-cli 让 schema 永远不进提示词。

最后是他给读者的三条可操作建议：

• 删掉微工具：文件读取、搜索、多文件编辑、diff、验证，都试着交给 Bash。
• 把子 Agent 当执行防火墙：把杂乱的探索和调试委托出去，只把干净结果收回父上下文。
• 系统指令保持最小：给仓库说明、领域知识和任务本身留出更多空间。

目标是一句话：更小的接口，更大的行动空间。

原文信息

作者：Philipp Schmid（@_philschmid），Google DeepMind Agent 工程师

原文地址：