1. 从10.3%到70.6%这个数字背后到底发生了什么Terminal-Bench 这个基准测试在圈内一直是个挺有意思的存在。它不像那些跑分软件一样只看模型能不能答对题而是把模型扔进真实的终端环境里让它自己敲命令、看输出、判断下一步该干什么直到把任务完成。说白了它考的不是你知不知道而是你能不能动手把事办了。Sonnet 5.5 在这个基准上从 10.3% 直接跳到 70.6%这个跨度放在任何评测体系里都算得上夸张。很多人第一反应是模型变聪明了但我把官方放出来的技术说明和几个第三方复现报告翻了一遍之后发现事情没那么简单。真正被改掉的东西是成本结构而不是推理能力本身。这个区别很关键。如果只是模型变聪明了那意味着你需要更大的模型、更多的算力、更高的调用费用。但如果是成本结构被重构了那意味着同样的任务你花更少的钱就能跑完而且跑得更稳。对于真正要把 Agent 落地到生产环境的人来说后者的价值远大于前者。我先把结论摆在这里Sonnet 5.5 在 Terminal-Bench 上的跃升核心来自三个层面的改动——工具调用链路的压缩、失败重试策略的重写、上下文管理的精细化。这三件事单独看都不算新鲜但组合在一起产生的效果就是让模型在终端环境里的有效动作密度大幅提升。什么叫有效动作密度你可以理解为模型每执行一步操作有多大比例是在真正推进任务而不是在浪费 token 做无用功。10.3% 的时候大量步骤消耗在重复确认、格式纠错、无效重试上到了 70.6%这些浪费被压到了很低的水平。这里要提醒一句Terminal-Bench 的分数不等于模型在你自己业务场景里的表现。它考的是通用终端操作能力你的场景可能有完全不同的命令集和约束条件。但这个基准的改动思路是可以直接借鉴到自己的 Agent 系统里的。接下来我会把这几个层面的改动拆开讲每一层都会说清楚改了什么为什么这样改有效你在自己的项目里怎么复现这个思路。不管你是用 Claude Code 做开发辅助还是自己在搭 Agent 系统这些内容都能直接用上。2. 工具调用链路压缩从每步都问到批量执行2.1 旧版本的问题单步确认带来的隐性成本在 10.3% 那个阶段模型在终端里的行为模式基本是走一步看一步。执行一条命令等输出分析输出再决定下一条命令。这个模式在人类看来很自然但放到模型身上就会产生巨大的隐性成本。首先是 token 消耗。每执行一条命令模型都要把完整的上下文重新读一遍——包括之前所有的命令历史、输出结果、系统提示。命令越多上下文越长每次调用的成本就越高。一个需要 50 步才能完成的任务到后面每一步的输入 token 可能是第一步的好几倍。其次是延迟累积。每一步都要等模型生成、等命令执行、等结果返回再进入下一轮。50 步就是 50 次往返哪怕每次只多花 200 毫秒累积起来也是十几秒的额外等待。更麻烦的是错误传播。如果第三步的判断出了偏差后面所有步骤都会建立在错误的前提上。而单步模式下模型很难在早期发现这种偏差因为它每次只能看到眼前这一步的输出。2.2 新版本的策略把可预测的步骤合并成批次Sonnet 5.5 的做法是在任务开始时先做一次计划生成把那些输入输出关系明确、不依赖中间结果的命令合并成一个批次一次性执行。举个例子。假设任务是在当前目录下找到所有超过 10MB 的日志文件统计它们的总大小然后按大小排序输出前五个。旧模式下模型可能会这样走先ls看目录结构再find . -name *.log找日志文件再du -h看每个文件大小再筛选超过 10MB 的再排序再取前五每一步都要等结果。但实际上第 2 到第 6 步完全可以合并成一条管道命令find . -name *.log -size 10M -exec du -h {} | sort -rh | head -5新版本会倾向于直接生成这样的复合命令而不是拆成六步。这一条命令的执行成本可能只有六步模式的五分之一甚至更低。2.3 批量执行的边界在哪里当然不是所有步骤都能合并。判断标准是这一步的输入是否依赖上一步的输出。如果依赖就必须分开如果不依赖就可以合并。我在自己的项目里复现这个思路时总结了一个简单的判断流程步骤类型是否可合并原因信息收集类ls、find、cat可合并输入固定不依赖中间结果条件判断类if、grep 筛选视情况如果判断条件已知可合并依赖前序输出的操作不可合并必须等上一步结果需要人工确认的操作不可合并安全边界要求这个表格看起来简单但实际用起来需要你对任务本身有足够的理解。我的经验是先让模型生成完整的步骤列表然后人工标注哪些步骤之间有数据依赖把无依赖的步骤合并。跑几轮之后模型自己就能学会这个模式。注意批量执行会带来一个副作用——如果批次中某条命令失败整个批次的输出都会变得难以解读。所以合并的时候要控制粒度不要把太多不相关的命令塞进同一个批次。3. 失败重试策略重写从盲目重试到诊断后重试3.1 旧版本的失败处理有多浪费在终端环境里命令失败是常态。路径不对、权限不够、参数写错、依赖缺失任何一种情况都会导致命令返回非零退出码。旧版本模型遇到失败时的典型反应是换个写法再试一次。这个策略的问题在于它没有区分失败的原因类型。路径错误和权限错误需要完全不同的修复方式但模型往往只是把同样的命令换个参数再跑一遍结果当然是继续失败。我见过最夸张的情况是模型在同一个权限问题上连续重试了七八次每次都是微调命令写法但根本没意识到问题出在文件权限上。这种盲目重试的成本是双重的既浪费了 token 和调用次数又拉长了任务完成时间。在 Terminal-Bench 这种按任务完成率计分的基准里重试次数直接影响了最终得分。3.2 新版本的诊断优先策略Sonnet 5.5 的改动是失败后先诊断再决定是否重试。诊断的方式是执行一组轻量的探测命令快速定位失败原因。比如一条cd /some/path失败了旧版本可能直接重试或者换个路径猜。新版本会先跑ls -ld /some/path 21 whoami id这三条命令分别检查路径是否存在及权限、当前用户身份、用户所属组。根据输出结果模型能准确判断是路径不存在、权限不足、还是其他问题然后采取对应的修复动作。这个策略的核心洞察是诊断的成本远低于盲目重试的成本。三条探测命令可能只花几百 token但能避免七八次无效重试。而且诊断结果还能被后续步骤复用不会重复浪费。3.3 我在实际项目里踩过的坑这个思路听起来很合理但实际落地时有一个坑诊断命令本身也可能失败。如果诊断命令的写法有问题或者环境本身处于异常状态诊断就会变成新一轮的盲目尝试。我的处理方式是给诊断命令加一层兜底如果诊断命令也失败了就退回到最保守的策略——输出当前环境的完整状态env、pwd、ls -la让模型基于完整信息做判断。这个兜底策略虽然成本高但至少不会陷入死循环。另一个坑是诊断过度。有些失败原因很明显比如命令拼写错误不需要跑一堆探测命令。我的经验是设置一个阈值如果失败信息里已经包含了明确的错误类型如 command not found、permission denied就直接按对应策略处理不额外诊断。4. 上下文管理精细化让每一步都记得住重点4.1 长任务中的上下文膨胀问题终端任务往往需要几十甚至上百步才能完成。每一步都会产生新的输出这些输出如果全部保留在上下文里很快就会超出模型的窗口限制或者即使没超限也会因为信息过载导致模型抓不住重点。旧版本的处理方式比较粗暴要么全部保留导致上下文膨胀要么简单截断导致关键信息丢失。这两种方式都会影响任务完成率。我实测过一个需要 80 步左右的任务旧版本跑到后面经常忘记前面已经确认过的路径和参数反复重新确认浪费了大量步骤。4.2 分层上下文的做法新版本引入了一个分层结构把上下文分成三个层次持久层任务目标、关键约束、已确认的环境信息。这一层始终保留不随步骤增加而膨胀。工作层最近若干步的操作和输出。这一层滚动更新保留最近 N 步的完整信息。归档层更早的步骤信息压缩成摘要形式保留。只保留关键结论丢弃过程细节。这个结构的妙处在于它让模型在每一步都能看到任务目标是什么当前进展到哪了之前确认过哪些关键信息而不会被大量过程细节淹没。我在自己的 Agent 项目里复现这个结构时用了一个简单的实现方式每完成 10 步就把前 10 步的输出压缩成一段摘要只保留做了什么结果是什么有没有需要记住的结论三个字段。实测下来这个简单的压缩策略就能显著改善长任务的表现。4.3 什么信息该保留什么该丢弃这是上下文管理里最难的部分。我的判断标准是信息类型处理方式理由任务目标和约束永久保留所有决策的基础已确认的路径、参数永久保留避免重复确认命令执行的成功/失败状态保留摘要影响后续决策命令的完整输出滚动保留最近几步细节只在近期有用中间过程的调试信息及时丢弃对后续步骤无价值这个表格不是死的需要根据任务类型调整。比如调试类任务需要保留更多中间输出而部署类任务只需要保留最终状态。一个实用技巧在系统提示里明确告诉模型哪些信息是关键的需要在后续步骤中记住。这看起来是废话但实测下来能显著减少模型忘记关键信息的情况。5. 成本视角下的真实收益为什么这比变聪明更重要5.1 算一笔实际的账假设一个终端任务需要 50 步完成。在旧版本下由于重试和上下文膨胀实际执行的步骤可能是 80 步每步平均消耗 3000 token总消耗约 24 万 token。新版本下步骤压缩到 40 步每步平均消耗 2000 token总消耗约 8 万 token。按当前主流 API 的定价这个差距意味着单任务成本降低到原来的三分之一左右。如果每天要跑几千个任务这个差距就是实打实的运营成本差异。更重要的是成本降低带来的不只是省钱还有策略空间。当单任务成本足够低时你就可以用更激进的重试策略、更充分的诊断流程、更长的上下文保留这些在成本敏感的场景下是做不到的。5.2 成本优化不等于偷工减料这里要澄清一个误解成本优化不是简单地少花钱而是把钱花在刀刃上。Sonnet 5.5 的改动里有些地方反而增加了开销——比如失败后的诊断命令比如分层上下文的维护逻辑。这些额外的开销换来了更高的任务完成率最终算总账是划算的。我在自己的项目里也验证过这个逻辑。之前为了省钱把重试次数限制得很死结果任务完成率上不去用户投诉反而更多。后来放开了重试策略加上诊断流程单任务成本上升了 20%但完成率从 60% 提到了 85%综合下来反而是更优的选择。5.3 对 Agent 落地的影响对于真正要把 Agent 用到生产环境的人来说这个改动方向的意义在于它让 Agent 的运营成本变得可预测、可控制。之前的 Agent 系统最大的问题就是成本不可控——一个任务可能花几毛钱也可能花几块钱取决于模型心情。这种不确定性让很多团队不敢把 Agent 放到核心业务里。而成本结构的优化让单任务成本变得稳定这才让 Agent 真正具备了规模化落地的基础。6. 在自己的项目里复现这些思路6.1 从工具调用层开始改如果你在用 Claude Code 或者自己搭 Agent 系统最容易落地的改动就是工具调用链路的压缩。具体做法是在系统提示里明确要求模型优先使用复合命令减少单步操作给模型提供一批常用的命令模板让它知道哪些操作可以合并在工具定义里增加批量执行的能力允许一次提交多条命令这三步里第一步的效果最明显。我实测下来仅仅是在提示里加一句尽量用管道和组合命令减少执行步数就能让平均步数下降 20% 左右。6.2 重试策略的改造要点重试策略的改造需要更细致的设计。我的建议是给失败信息分类不同类型的失败走不同的处理路径为常见失败类型准备诊断命令模板设置重试上限超过上限就输出完整环境状态让人工介入这里的关键是不要试图让模型自己判断失败类型而是用规则先做一层过滤。模型在失败信息明确的情况下判断很准但在模糊情况下容易瞎猜。6.3 上下文管理的实现细节上下文管理是最难改的部分因为它涉及到整个系统的架构。如果不想大改可以先从简单的摘要压缩开始def compress_history(steps, keep_recent5): if len(steps) keep_recent: return steps recent steps[-keep_recent:] older steps[:-keep_recent] summary summarize(older) # 调用模型生成摘要 return [summary] recent这个简单的实现就能带来明显的改善。等跑顺了再考虑更精细的分层结构。6.4 一个容易忽略的细节提示词里的成本意识最后分享一个我在实践中发现的小技巧在系统提示里明确告诉模型成本是重要的考量因素。这听起来很虚但实测下来模型在知道成本重要的情况下会自发地选择更简洁的命令、更少的重试、更精炼的输出。这个技巧的原理是模型的输出分布会受到提示词的影响。当提示词里强调成本时模型在生成时会倾向于那些更经济的选项。这不是玄学而是提示词工程里被反复验证过的现象。7. 这套改动思路的适用边界7.1 什么场景下收益最大这套改动思路在以下场景里收益最明显长链路任务需要几十步以上才能完成的任务上下文管理和重试策略的优化效果最显著高失败率环境命令失败频繁的场景诊断优先策略能大幅减少无效重试成本敏感场景需要大规模调用、对单任务成本敏感的场景链路压缩的价值最大反过来如果是短任务、低失败率、成本不敏感的场景这套改动的收益就没那么明显甚至可能因为额外的诊断开销而略微增加成本。7.2 什么情况下不要照搬有一个场景我建议不要照搬这套思路安全敏感的操作。比如涉及删除文件、修改系统配置、执行不可逆操作的任务批量执行和自动重试都会带来风险。这种场景下宁可慢一点、贵一点也要保证每一步都可控、可审计。我的做法是给这类操作单独设置一条规则所有不可逆操作必须单步执行且需要显式确认。这条规则会覆盖掉批量执行的优化但这是必要的安全代价。7.3 后续可以继续优化的方向这套思路还有继续优化的空间。我目前在看的方向有两个一是基于任务类型的自适应策略不同类型的任务用不同的压缩和重试策略二是跨任务的上下文复用把相似任务里确认过的环境信息缓存下来避免重复探测。这两个方向都还在实验阶段等有稳定结果了再单独写一篇分享。如果你也在做类似的事情欢迎交流踩坑经验。8. 我在实际使用中的几点体会用了一段时间之后我最大的感受是Agent 系统的优化重点不在模型本身而在模型和环境的交互方式上。同样的模型换一套工具调用策略、换一套失败处理逻辑、换一套上下文管理方式表现可能差出好几倍。Sonnet 5.5 在 Terminal-Bench 上的跃升本质上就是把这几个交互层面的问题解决得更好。它没有让模型更聪明而是让模型更会干活。这个区别对于做工程的人来说意义重大——因为交互层面的优化是我们可以自己复现、自己调整、自己迭代的。另一个体会是成本优化和效果优化不是对立的。很多人觉得要效果好就得多花钱但实际做下来很多成本浪费恰恰是因为策略不对。把策略调对了效果和成本可以同时改善。这个认知上的转变可能比任何具体的技术改动都重要。最后说一个具体的操作建议如果你现在正在用 Claude Code 或者类似的工具不妨先做一件事——统计一下你的任务平均需要多少步完成其中有多少步是无效的。这个数字往往会让你吃惊而改善的空间就藏在这个数字里。