Anthropic于9月30日发布Claude Sonnet 5.5。据雷峰网报道，若只看发布页，这仍是一轮常规模型升级：API单价没有变化，生成速度更快，Terminal-Bench、CursorBench等Agent基准成绩明显上涨。但把几组运行数据放在一起，变化并不只发生在模型输出层。Lovable的测试中，Tool Call数量减少约三分之一，Shell Run接近减半；Base44的应用构建任务里，平均迭代次数从7.7次降到3.6次。Anthropic还提到，新模型更频繁地把多个工具调用放在同一批执行。
雷峰网在拆解文章中称，Agent成本不能只看Token。一次任务真正消耗资源的地方，还包括工具等待、状态回填、重新规划、上下文增长和失败恢复。模型具备静态依赖分析与执行图压缩能力，才使原本笨重的Agent Runtime架构得以瘦身。
文章认为，Agent需要持续维护会变化的工作状态，包括用户目标、已验证假设、工具返回、代码改动和尚未解决的问题。每完成一次Tool Call，runtime都要把新结果合并进当前状态，再让模型重新判断原计划是否成立。随着任务继续，工作状态会不断膨胀，每次重新进入reasoning都要恢复与当前决策相关的状态。失败路径会放大这一问题：前面产生的代码、修改记录和测试日志若一直留在上下文，后面的正确路径仍要在这批残留状态里工作。因此长上下文本身并不能解决Agent成本问题，runtime更难处理的是哪些内容还应该留在当前working set。
Batch Tool Call是另一处变化。传统ReAct执行方式是一条严格串行链，模型决定动作、工具执行、结果返回、模型再次判断，再触发下一个动作，这默认每个工具之间都存在依赖。Batch Tool Call要求模型进入工具层之前先做局部依赖判断，把可共同执行的动作放进同一批，真正被压缩的是synchronization barrier。这要求模型具备partial-order planning能力，区分只读操作与写操作，并处理read-after-write和write-after-write关系。批量执行还会带来fan-in压力，runtime需要通过result reduction合并重复内容、缩短长日志、过滤低价值结果，再把压缩后的状态送回模型。
雷峰网还提到，effort会改变执行图。如果模型在修改代码前多做一轮依赖检查，可能避免一次冲突、测试失败和回滚；如果证据已经足够仍继续扩展分析，则可能启动更多code review、subagent和验证，把额外计算变成更多执行节点。Anthropic在FrontierCode上出现过Max effort低于Xhigh的情况，一种解释是高effort让模型更频繁调用code-review skill并拆给多个subagent，部分分支随后超时或产生超出任务边界的修改。文章称，effort策略因此更应落到节点级，低风险步骤可用较轻reasoning，准备跨文件写入或执行高副作用动作前再增加reasoning，代码写入后尽快进入测试。runtime还需要checkpoint，在关键写操作前保存稳定状态，失败后只回退最近一次变更。
文章最后称，Sonnet 5.5的变化表明模型能力开始直接影响Agent runtime结构。后续衡量Agent，输入输出Token只是底层计量，更有用的指标是一次任务经历多少model—tool barrier、batch中多少结果真正被后续决策使用、失败后需要回退多远、active working set增长到什么程度，以及subagent产生了多少最终没有提交的分支。Sonnet 5.5带来的工程问题仍是：如何把更多计算放到真正能消除后续执行成本的位置，而不是让Agent用更多reasoning制造更大的执行图。