Anthropic 近日发布 Claude Sonnet 5.5。从发布页信息来看，这似乎是一次常规的模型迭代：API 单价保持不变，生成速度有所提升，Terminal-Bench、CursorBench 等 Agent 基准测试成绩明显上涨。但多组运行数据显示，此次更新的核心变化并不局限于模型输出层面。
在 Lovable 的测试中，Sonnet 5.5 的 Tool Call 数量减少约三分之一，Shell Run 接近减半。Base44 的应用构建任务中，平均迭代次数从 7.7 次降至 3.6 次。Anthropic 同时提到，新模型更频繁地将多个工具调用放在同一批次中执行。这些数据表明，Agent 的成本结构正在发生变化——Token 消耗并非唯一指标，工具等待、状态回填、重新规划、上下文增长和失败恢复同样构成实质性开销。
Agent 与聊天模型在计算模式上存在本质差异。聊天模型一次请求结束后计算即告完成，而 Agent 需要持续维护一个动态变化的工作状态，涵盖用户目标、已验证假设、工具返回结果、代码改动、环境状态以及尚未解决的问题。每完成一次 Tool Call，Runtime 都要将新结果合并进当前状态，再让模型重新判断原有计划是否成立。这一过程涉及状态恢复成本，即 state rehydration。模型下一轮不仅需要读取最新返回的测试日志，还需要了解为何运行该测试、此前修改过哪些文件、哪些假设已被排除，以及当前工作区相对任务初始状态发生了哪些变化。
随着任务推进，工作状态会不断膨胀，每次进入 reasoning 阶段都需要恢复与当前决策相关的状态片段。失败路径会进一步放大这一问题。以代码 Agent 为例，若初始判断将问题归因于认证中间件，模型会搜索相关 symbol、读取文件、修改逻辑并运行测试，最终发现问题实际来自 session serialization。此前的代码、修改记录、测试日志和中间判断已进入上下文，若 Runtime 仅做历史追加，后续正确路径仍需在这批残留状态中运行。因此，长上下文窗口解决的是历史能否保存的问题，而 Runtime 更需要处理的是哪些内容应留在当前 working set。稳定的长期 Agent 需要将当前节点直接依赖的信息保留在活动区，把已形成稳定结论的内容压缩为结构化状态，同时让原始日志、重复搜索结果和已失去依赖关系的 observation 尽快退出工作集。
传统 ReAct 采用严格串行链：模型决定动作，工具执行，结果返回，模型再次判断，再触发下一动作。这种方式实现简单，但默认每个工具之间存在依赖，即使许多操作本可同时进行。代码排障是典型场景——搜索异常字符串、读取 package 配置、定位测试文件、检查 symbol 引用关系，多数情况下只是读取当前代码状态，彼此没有必须等待的顺序。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 总量，说明变化不仅是并发增加，而是模型在部分任务中更早形成相对完整的信息需求，减少了后续补查次数。
在 Agent 场景中，effort 的作用也发生变化。单轮任务里提高 effort 主要增加模型内部 test-time compute，而进入 Agent 场景后，内部 reasoning 会直接改变外部动作。若模型在修改代码前多做一轮依赖检查，发现两个 change-set 存在接口顺序关系，可能直接避免一次冲突、一次测试失败和一次回滚——额外 reasoning 增加了内部计算，却减少了外部执行。反之，若当前证据已足够而模型仍继续扩展分析，则可能启动更多 code review、subagent 和验证，将额外计算转化为更多执行节点。
Sonnet 5.5 的更新表明，模型能力的提升正在从单纯的输出质量优化转向对 Agent Runtime 架构的直接影响。当模型开始参与决定执行图如何展开，Agent 系统的成本结构、同步策略和状态管理方式都将随之调整。对于构建生产级 Agent 的企业而言，这意味着评估模型时需将 Runtime 层面的执行效率纳入考量，而非仅关注基准测试分数或 Token 单价。
该文观点仅代表作者本人，企服科学平台仅提供信息存储空间服务。
