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