Tool Call 少三成，Shell Run 近减半，迭代降至 3.6 次。 作者丨郑佳美
编辑丨岑 峰
刚刚，Anthropic 发布了 Claude Sonnet 5.5。如果只看发布页，这仍然是一轮常规模型升级：API 单价没变，生成速度更快，Terminal-Bench、CursorBench 等 Agent benchmark 的成绩明显上涨。但把几组运行数据放在一起，会发现这次变化并不只发生在模型输出这一层。Lovable 的测试里，Tool Call 数量减少约三分之一，Shell Run 接近减半，Base44 的应用构建任务中，平均迭代次数从 7.7 次降到 3.6 次。Anthropic 还提到，新模型更频繁地把多个工具调用放在同一批执行。这意味着 Agent 成本不能只看 Token。一次任务真正消耗资源的地方，还包括工具等待、状态回填、重新规划、上下文增长和失败恢复。只要 model—tool 循环足够长，这些成本就会持续叠加。在“模型变聪明了”的背后，工程上其实是模型具备了“静态依赖分析”与“执行图压缩”的能力，使原本笨重的 Agent Runtime 架构得以瘦身。Sonnet 5.5 的变化，恰好把问题推到了 Agent runtime 本身：为什么更强的前置规划能够减少 Tool Call，批量工具调用到底压缩了什么，以及 effort 增加的 test-time compute，什么时候能减少后续执行，什么时候反而会把执行图越做越大。雷峰网聊天模型的一次请求结束以后，当前计算基本结束，但 Agent 不一样，它需要持续维护一个会变化的工作状态，其中包括用户目标、已经验证过的假设、工具返回、代码改动、环境状态以及尚未解决的问题。每完成一次 Tool Call，runtime 都要把新的结果合并进当前状态，然后让模型重新判断原来的计划是否仍然成立。雷峰网(公众号：雷峰网)这里有一层很实际的成本，可以叫作 state rehydration。模型下一轮并不是只读一段刚返回的测试日志，它还需要知道为什么运行这项测试、此前动过哪些文件、哪些假设已经排除，以及当前工作区相比任务开始时发生了什么变化。随着任务继续，这个工作状态会不断膨胀，每一次重新进入 reasoning，都需要重新恢复和当前决策相关的那部分状态。失败路径会把这个问题进一步放大。假设代码 Agent 一开始判断错误，把问题归到认证中间件，于是搜索相关 symbol、读取文件、修改逻辑，再运行测试，最后发现问题其实来自 session serialization。前面的代码、修改记录、测试日志和中间判断已经进入上下文，如果 runtime 只是不断追加历史内容，那么后面的正确路径仍然要在这批残留状态里继续工作。所以长上下文本身并不能解决 Agent 成本问题。上下文窗口变大，解决的是历史能不能保存，runtime 更难处理的是，哪些内容还应该留在当前 working set。一个稳定的长期 Agent，需要把当前节点直接依赖的信息留在活动区，把已经形成稳定结论的内容压缩成结构化状态，而原始日志、重复搜索结果和已经失去依赖关系的 observation 应该尽快退出工作集。这一层决定了为什么一次无效 Tool Call 的代价通常高于它本身。错误搜索不仅浪费一次工具执行，还会制造额外状态，错误修改又会带来测试日志、恢复动作和新的判断分支。只要这些内容进入 working set，后面的节点就要继续为它们付出处理成本。也正因为每跨一次 model—tool 边界都需要重新恢复工作状态，下一步自然就是减少那些没有必要存在的边界。传统 ReAct 的执行方式是一条严格串行链：模型决定一个动作，工具执行，结果返回，模型再次判断，然后再触发下一个动作。这种方式实现简单，但它默认每个工具之间都存在依赖，即使很多操作本来可以同时进行。代码排障就是典型场景。搜索异常字符串、读取 package 配置、定位测试文件、检查几个 symbol 的引用关系，很多时候只是读取当前代码状态，彼此没有必须等待的顺序。传统 ReAct 仍可能把它们拆成多轮，每轮都重新进入模型，Batch Tool Call 则要求模型在进入工具层之前先做一次局部依赖判断，把可以共同执行的动作放到同一批里。这里真正被压缩的是 synchronization barrier。原来模型每拿到一个结果，都要停下来恢复状态并重新规划，现在模型先确定这一阶段需要哪些信息，中间多个 barrier 可以直接消失，工具并行运行以后，结果再一次性交回模型。这要求模型具备的不只是工具选择能力，还需要 partial-order planning，也就是判断哪些动作存在先后关系，哪些动作只读状态，哪些动作会改变状态。只读操作容易并行，写操作则必须考虑 read-after-write 和 write-after-write 关系。比如测试必须看到修改后的代码，调用方修改可能依赖接口已经更新，两个 subagent 同时编辑同一个文件还会产生写冲突。因此，执行图能不能压缩，关键不是一次发出多少 Tool Call，而是同步点放在哪里。读取阶段可以尽量推迟 barrier，让信息收集在同一个执行层完成，进入写操作以后，则需要重新收紧执行顺序，确保状态变化不会互相覆盖。批量执行还有一个反向问题：fan-out 太大以后，会产生很重的 fan-in。一次并发十几个工具虽然减少了等待，但模型下一轮可能收到大量代码、日志和搜索结果，如果这些内容原样进入上下文，前面省下来的同步成本又会以 observation 膨胀的形式回来。因此，runtime 还需要在工具返回以后做 result reduction，把重复内容合并，把长日志缩成和当前决策相关的片段，把低价值结果直接过滤，再把压缩后的状态送回模型。Sonnet 5.5 同时出现更频繁的 batch 和更少的 Tool Call 总量，说明变化并不只是并发更多，而是模型在一些任务里更早形成了一组相对完整的信息需求，减少了后面不断补查的次数。当模型开始参与决定执行图怎么展开以后，effort 的作用也随之发生变化，因为更多 reasoning 不再只是让模型思考得更久，而会直接改变后面会不会继续展开新的工具和 subagent。在单轮任务里，提高 effort 主要增加模型内部的 test-time compute，进入 Agent 场景以后，内部 reasoning 会直接改变外部动作，因此同样一部分计算预算放在不同位置，结果可能完全不同。如果模型在修改代码之前多做一轮依赖检查，发现两个 change-set 存在接口顺序关系，那么后面可能直接避免一次冲突、一次测试失败和一次回滚。这种额外 reasoning 虽然增加了内部计算，却减少了外部执行。如果当前证据已经足够，模型仍然继续扩展分析，情况就会反过来，它可能启动更多 code review、subagent 和验证，把额外计算变成更多执行节点。Anthropic 在 FrontierCode 上出现过 Max effort 低于 Xhigh 的情况，其中一个解释就是高 effort 让模型更频繁地调用 code-review skill，并拆给多个 subagent，部分分支随后超时或者产生超出任务边界的修改。有意思的是，这不是某个 benchmark 的高低，而是 effort 改变了 branch factor：模型内部预算增加以后，执行图也随之膨胀。因此，更合理的 effort 策略应该落到节点级，而不是整条任务固定一个档位。读取仓库、搜索 symbol 这类低风险步骤，可以用较轻的 reasoning 快速生成查询集合。准备跨文件写入、修改 schema 或执行高副作用动作之前，可以增加 reasoning，把计算放在依赖检查和 change-set planning 上，代码写入以后则尽快进入测试，因为真实环境反馈比继续内部推演更有效，如果验证失败，再根据新的 observation 提高 reasoning，而不是重新扫描已经确认过的部分。这里还需要 checkpoint。Agent 如果每次失败都从任务开头重新恢复状态，retry 会把执行链重新拉长。如果 runtime 在关键写操作之前保存稳定状态，失败以后只回退最近一次变更，再从可信节点继续，失败造成的影响就能局限在较小范围。代码 Agent 可以借助独立 worktree、临时分支或者沙箱隔离候选修改，让 subagent 在独立环境里完成验证，通过以后再合并进主工作区，没有通过的分支则整体丢弃。到这一层，Agent runtime 已经不再只是一个 model—tool 循环，而更像一个动态 controller：它要维护工作状态，决定同步点，控制 fan-out，为高风险节点分配更多 reasoning，在写操作之前保存 checkpoint，再根据验证结果决定继续、回滚还是提交。Sonnet 5.5 这次变化里，或许值得保留下来的结论其实只有一个：模型能力开始直接影响 Agent runtime 的结构。如果模型能够在动作之前更好地判断依赖，runtime 就可以减少同步点，如果 observation 能被及时压缩，working set 就不会随着任务长度持续膨胀。如果 effort 被放在错误代价更高的节点上，额外的 test-time compute 就有机会换掉后面的失败执行，而不是继续扩大搜索空间。所以后续衡量 Agent，输入输出 Token 只是底层计量。更有用的指标会是一次任务经历多少 model—tool barrier，batch 中多少结果真正被后续决策使用，失败以后需要回退多远，active working set 在运行过程中增长到什么程度，以及 subagent 产生了多少最终没有提交的分支。这些数据能够直接判断一套 Agent 系统的问题到底出在模型、执行器、状态管理，还是 controller 本身。Sonnet 5.5 带来的变化，最终还是落在同一个工程问题上：如何把更多计算放到真正能消除后续执行成本的位置，而不是让 Agent 用更多 reasoning 去制造更大的执行图。参考链接：https://www.anthropic.com/claude-sonnet-5-5
可独家畅览：
专家演讲PPT
大会报告全文
热门论文解读
学术新星访谈
扫描上方二维码
或点击「阅读原文」关注专区。
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
