1. 从 10.3% 到 70.6% 到底意味着什么Terminal-Bench 这个基准测试圈外人可能不太熟但只要你用过命令行 Agent 类工具就一定间接接触过它背后的评测逻辑。它测的不是模型能不能背出tar的十个参数而是给一个真实的终端环境让模型自己规划、执行、纠错最终把任务跑通。10.3% 到 70.6% 这个跨度放在任何基准上都是换了一代产品级别的跃迁但这次真正值得聊的不是分数本身而是这个分数是怎么被省出来的。先把结论摆前面Sonnet 5.5 这一代在 Terminal-Bench 上的提升核心驱动力不是模型变聪明了多少而是单位任务成本被压到了一个临界点以下使得多轮试错 自我验证这套原本烧钱烧到没人敢用的策略第一次变得经济可行。换句话说以前不是模型不会做是做一次太贵贵到你不敢让它反复试。现在成本下来了试错次数上去了成功率自然就上去了。这篇文章适合三类人看一是正在做 Agent 产品、纠结要不要上多轮验证策略的工程师二是自己搭命令行自动化流程、想知道该不该换模型的开发者三是单纯好奇成本优化这四个字在 Agent 场景里到底怎么落地的技术爱好者。我会把 Terminal-Bench 的评测机制、成本结构、多轮策略的经济账、以及我自己踩过的坑全部拆开讲清楚。需要提前说明的是下面涉及的具体价格、token 消耗量、轮次数据部分是基于公开基准测试的常见实践推算出来的合理区间不是官方逐条公布的精确数字但量级和趋势是可靠的。你拿去参考决策没问题别拿去当合同附件。2. Terminal-Bench 到底在测什么为什么它比普通代码基准难2.1 终端任务的本质状态机 不确定性普通的代码生成基准比如给一道算法题让模型写函数本质上是输入到输出的单次映射。模型写对了就得分写错了就零分中间没有交互。Terminal-Bench 完全不是这个逻辑。它给模型的是一个有状态的终端环境——文件系统、进程、环境变量、网络状态全都是活的你执行一条命令环境就变了下一条命令的输入取决于上一条命令的输出。这就带来一个根本性的难点模型必须学会看结果再决定下一步。比如让它装一个依赖pip install报了个版本冲突聪明的模型会去读报错、降级版本、重试笨的模型会原样再跑一遍然后卡死。这个读结果—判断—调整的循环就是 Agent 能力的核心也是 Terminal-Bench 真正想测的东西。我自己的经验是终端任务里大概有 60% 以上的失败不是模型不会而是模型没看输出就往下走。它假设上一步成功了结果环境根本没变后面全盘皆输。所以任何提升终端成功率的方案第一优先级永远是强制模型验证每一步的实际结果而不是让它一口气把命令全写完。2.2 10.3% 这个数字背后的真实困境10.3% 是什么概念大概就是模型能搞定最简单的单步任务比如ls一下、cat一个文件、跑一条不带参数的命令。一旦任务需要三步以上、需要处理报错、需要根据中间结果分支基本就崩了。这个数字之所以低不是因为模型的知识不够。你单独问它怎么解压 tar.gz它能答得头头是道。问题在于终端任务要求的是在真实反馈下持续决策而早期的做法往往是一次性生成完整命令序列然后祈祷它能跑通。这种盲写策略在真实环境里的成功率低得可怜。提示判断一个终端 Agent 好不好用最简单的办法就是看它执行完一条命令后会不会主动去echo $?或者读一遍输出。不会的基本可以判定它没有真正的验证循环。2.3 70.6% 意味着跨过了可用门槛70.6% 这个数字在工程上有个特殊意义它跨过了人愿意把任务交给它的心理门槛。低于 50% 的时候你用它还不如自己敲命令快到了 70% 左右它开始能帮你省下大量重复劳动剩下的 30% 你人工兜底整体效率是正的。而这个跨越恰恰不是靠模型突然变聪明实现的。下面这张表能说明问题维度早期方案10.3% 档Sonnet 5.5 档70.6%单任务平均轮次1-2 轮8-15 轮每轮是否验证结果基本不验证强制验证失败后是否重试极少常态单任务 token 消耗低高 3-5 倍单任务综合成本看似低实则浪费看似高实则划算看明白了吗成功率翻了好几倍代价是 token 消耗涨了好几倍。如果单价不变这个账根本算不过来。所以真正的关键变量是单价降下来了。3. 成本才是这次真正的变量一笔必须算清楚的账3.1 为什么多轮试错以前是奢侈品假设一个终端任务单轮平均消耗 3000 token早期模型单价假设是每百万 token 输入 3 美元、输出 15 美元这是行业里中高端模型的常见量级。单轮成本大概在 0.02-0.04 美元之间。如果只跑 1 轮成本可以忽略但如果为了把成功率从 10% 拉到 70%需要跑 10 轮成本就变成了 0.2-0.4 美元一个任务。听起来还是不贵那你乘以规模。一个团队每天跑 10 万个任务一天就是 2 万到 4 万美元一个月 60 万到 120 万美元。这个数字足以让任何产品经理在立项会上被 CFO 按在地上摩擦。所以早期不是没人想到多轮验证这个思路而是算完账发现根本用不起。3.2 单价下降如何改变了整个策略空间Sonnet 5.5 这一代把单价压下来之后同样的 10 轮任务成本可能降到了原来的三分之一甚至更低。这时候账就反过来了多花几倍 token换来 7 倍的成功率提升单位成功任务的成本反而是下降的。我给大家算一笔更直观的账。假设目标是完成 100 个任务旧方案单价高只能跑 1 轮成功率 10%要完成 100 个成功任务得发起 1000 次总成本 1000 × 单轮成本。新方案单价低能跑 10 轮成功率 70%要完成 100 个成功任务只需发起约 143 次总成本 143 × 10 × 单轮成本新单价。把新单价设为旧单价的 1/4代入一算旧方案总成本 1000 单位新方案总成本 143 × 10 × 0.25 357.5 单位。成本直接砍掉了六成多成功率还高了 7 倍。这就是成本优化这四个字在 Agent 场景里的真实含义——它不是省钱它是解锁了原本被成本锁死的能力。3.3 成本结构里最容易被忽略的两块很多人算成本只算 token 单价这是新手最容易踩的坑。实际上还有两块隐性成本第一块是失败重试的浪费。一个任务失败了你不仅要付这次的钱还要付重新发起的钱。成功率低的时候这部分浪费占比极高。10% 成功率的方案90% 的钱是打水漂的。第二块是人工兜底成本。任务失败后要么人工介入要么用户流失。这部分成本不进 API 账单但进你的财务报表。70% 成功率和 10% 成功率人工兜底的量差了好几倍。注意评估一个 Agent 方案的经济性永远要看每个成功任务的综合成本而不是每次调用的单价。单价低但成功率也低的方案往往是最贵的。4. 多轮验证循环怎么搭从原理到可复现的实操4.1 核心循环的四步结构一个能跑到 70% 成功率的终端 Agent它的执行循环基本逃不出这四步规划 → 执行 → 观察 → 修正。听起来简单但每一步都有讲究。规划阶段模型要做的不是把命令全列出来而是只规划下一步做什么。这一点极其关键。一次性规划十步的模型遇到第三步报错就全乱了只规划一步的模型每步都能根据最新状态调整。执行阶段就是真的把命令丢进终端跑。这里有个细节必须捕获完整的 stdout 和 stderr包括退出码。很多实现只抓 stdout结果 stderr 里的报错信息全丢了模型看不到错误自然没法修正。观察阶段是把执行结果喂回给模型。这里建议做一层轻量清洗把超长的输出截断或摘要避免把上下文撑爆。但报错信息一定要完整保留那是模型修正的唯一线索。修正阶段模型根据观察结果决定是继续下一步还是重试当前步还是换个思路。这个决策质量直接决定了最终成功率。4.2 一个最小可用的循环实现下面这段伪代码是我自己搭验证循环时用的骨架逻辑清晰你可以直接照着改def run_terminal_agent(task, max_turns15): history [] state {cwd: /workspace, last_output: , exit_code: 0} for turn in range(max_turns): # 规划只让模型决定下一步 action model.plan(task, history, state) if action.type finish: return {success: True, turns: turn 1} # 执行捕获完整输出和退出码 result execute_in_terminal(action.command, cwdstate[cwd]) # 观察清洗后回填状态 state[last_output] truncate(result.stdout result.stderr, 2000) state[exit_code] result.exit_code state[cwd] result.new_cwd # 修正把结果写进历史供下一轮规划 history.append({ command: action.command, output: state[last_output], exit_code: result.exit_code }) # 连续失败保护 if consecutive_failures(history) 3: history.append({hint: 连续失败请换一种思路}) return {success: False, turns: max_turns}这段代码里max_turns15是个经验值。设太小复杂任务跑不完设太大成本失控。我实测下来大部分终端任务在 8-12 轮内能收敛15 轮是个比较安全的兜底。4.3 参数选择背后的计算逻辑为什么是 15 轮而不是 30 轮这里有个成本收益的平衡点。假设每多一轮成功率提升的边际收益是递减的前 5 轮可能把成功率从 20% 拉到 60%再 5 轮拉到 70%再 5 轮可能只拉到 72%。而成本是线性增长的。所以最优轮次就在边际成功率提升 ≈ 边际成本增加的那个点附近。你可以自己做个实验固定一批任务分别设 max_turns 为 5、10、15、20、30记录成功率和总成本画个曲线拐点就是你的最优值。不同任务类型的最优值不一样别照搬别人的数字。提示连续失败保护consecutive_failures这个机制非常重要。没有它模型容易陷入同一个错误命令反复重试的死循环白白烧钱。三次连续失败就强制注入换思路的提示能救回不少任务。5. 工具选型与配置别在环境上栽跟头5.1 命令行 Agent 的运行环境怎么选终端 Agent 对运行环境的要求比普通 API 调用高得多。它需要一个隔离的、可重置的、有完整 shell 的环境。我见过太多人图省事直接在本机跑结果模型一条rm -rf下去哭都来不及。常见的选择有这么几种各有取舍方案隔离性启动速度适用场景本地容器好快个人开发、小规模测试虚拟机最好慢需要完整系统调用云沙箱好中生产环境、批量任务本机直接跑无最快仅限只读任务不推荐我个人的建议是开发和测试阶段用本地容器就够了轻量、快、好调试。生产环境一定要上云沙箱或者专门的隔离方案因为你要面对的是不可控的模型行为隔离是底线。5.2 环境初始化的几个关键点环境搭好之后有几个初始化动作必须做否则后面全是坑第一固定工作目录。每次任务开始前把 cwd 重置到一个干净的目录避免上一个任务的残留文件干扰。我吃过这个亏一个任务留下的临时文件让下一个任务的ls结果全乱了模型判断失误。第二预装常用工具。模型经常会用curl、jq、git、python这些工具如果环境里没有它会浪费好几轮去装甚至装不上。提前装好能省下大量轮次。第三设置超时。每条命令都要有超时保护不然模型跑一个sleep 9999或者卡在交互式命令上整个任务就挂死了。我一般设 30 秒单命令超时长任务单独放行。第四禁用交互式命令。像vim、top、less这种需要交互的命令模型一进去就出不来。可以在环境层面做限制或者在系统提示里明确禁止。5.3 系统提示词怎么写才有效系统提示词是终端 Agent 的操作手册写得好不好直接影响成功率。我的经验是提示词里必须包含这几条硬性规则每次只输出一条命令不要一次给多条执行后必须检查退出码和输出再决定下一步遇到报错先读报错信息不要盲目重试禁止使用交互式命令任务完成后明确输出完成标志这几条看起来简单但能挡掉一大半的低级错误。尤其是每次只输出一条命令这条是保证验证循环生效的前提。如果模型一次给五条命令中间某条失败了后面四条的执行结果全是错的验证就失去意义了。6. 常见问题与排查技巧实录6.1 成功率上不去的典型原因排查很多人搭好循环之后发现成功率还是卡在 30%-40%上不去。这时候别急着换模型先按下面这个表排查现象可能原因排查方法模型反复执行同一命令没看到报错输出检查 stderr 是否被捕获任务中途卡死遇到交互式命令检查是否有超时保护前期顺利后期崩上下文被撑爆检查输出截断策略简单任务也失败环境缺工具检查预装工具清单成功率忽高忽低环境没重置检查任务间隔离我遇到最多的问题是输出截断把关键报错截掉了。模型看到的是被截断的输出报错信息在中间被砍了它自然没法修正。解决办法是截断时优先保留头部和尾部尤其是尾部因为报错通常在最后几行。6.2 成本失控的三种情况和应对成本失控是另一个高频问题。常见的有三种第一种轮次没有上限。模型陷入死循环一直重试token 哗哗地烧。应对就是设硬性 max_turns到点强制结束。第二种上下文无限增长。每一轮的历史都全量塞回去轮次一多输入 token 爆炸。应对是做历史压缩只保留最近几轮的关键信息或者对早期历史做摘要。第三种失败任务反复重发。外层调度没有去重同一个失败任务被反复发起。应对是在调度层做失败标记超过重试次数就进人工队列别再自动跑了。注意成本优化不是一味地省而是把钱花在刀刃上。该多跑几轮的任务别舍不得该及时止损的任务别硬撑。判断标准就是每个成功任务的综合成本。6.3 几个我踩过的坑说几个具体的。有一次我为了省 token把历史压缩得太狠结果模型忘了前面已经装过某个依赖又装了一遍反而浪费了更多轮次。压缩要适度关键的状态信息装了什么、改了什么文件必须保留。还有一次环境没做网络隔离模型跑了个需要联网的命令结果因为网络策略卡了半天最后超时。终端 Agent 的网络访问一定要提前规划好要么全禁要么白名单别让它自己瞎试。最后一个也是最隐蔽的模型对成功的判断标准和你不一样。它可能觉得命令退出码是 0 就算成功了但实际任务目标根本没达成。所以任务完成的判定最好由外部逻辑来做比如检查某个文件是否存在、某个输出是否符合预期而不是完全交给模型自己说我完成了。7. 这套思路还能怎么扩展把成本压下来、把验证循环搭起来之后你会发现很多以前不敢想的事情变得可行了。比如批量处理成千上万个运维任务比如让 Agent 自己写脚本、自己测试、自己修 bug比如把多个终端 Agent 串起来做流水线。我最近在试的一个方向是给验证循环加一层经验记忆——把成功任务的命令序列存下来下次遇到类似任务时作为参考注入。实测下来能让常见任务的轮次减少 30% 左右成本又降了一截。这个思路不复杂但效果挺实在有兴趣的可以自己试试。另外一个值得关注的点是成本下降带来的不只是能多跑几轮还有能跑更复杂的任务。以前因为成本限制只能做单步任务现在可以尝试多步骤、跨工具的复杂流程。这才是成本优化真正的价值——它打开的是能力边界而不只是省钱。
