深度拆解 Sonnet 5.5 ：半价 Opus 只是表象，Agent Runtime 才是变化核心- 大数跨境

首页

深度拆解 Sonnet 5.5 ：半价 Opus 只是表象，Agent Runtime 才是变化核心

AI科技评论

2026-09-29

导读：Tool Call 少三成，Shell Run 近减半，迭代降至 3.6 次。

Tool Call 减少约三成，Shell Run 接近减半，平均迭代次数降至 3.6 次。

作者丨郑佳美

编辑丨岑峰

Anthropic 近日正式发布 Claude Sonnet 5.5。从表面看，这是一次常规的模型升级：API 单价保持不变，生成速度提升，且在 Terminal-Bench、CursorBench 等 Agent 基准测试中成绩显著。

然而，深入分析运行数据可以发现，此次升级的核心变化不仅在于模型输出层。在 Lovable 的测试中，Tool Call 数量减少约三分之一，Shell Run 接近减半；在 Base44 的应用构建任务中，平均迭代次数从 7.6 次大幅降至 3.6 次。此外，新模型更频繁地将多个工具调用合并至同一批次执行。

这一现象揭示了一个关键事实：Agent 的成本评估不能仅局限于 Token 消耗。工具等待、状态回填、重新规划、上下文增长及失败恢复等环节同样消耗大量资源。只要 model-tool 循环链路过长，这些隐性成本便会持续叠加。

Sonnet 5.5 的突破在于工程层面实现了“静态依赖分析”与“执行图压缩”能力，从而简化了原本笨重的 Agent Runtime 架构。这也引出了新的技术议题：为何更强的前置规划能减少 Tool Call？批量工具调用究竟压缩了什么？以及增加的 test-time compute 何时能优化执行，何时反而会导致执行图膨胀？

Agent 工作状态日益沉重

与传统聊天模型不同，Agent 需要持续维护动态的工作状态，包括用户目标、已验证假设、工具返回结果、代码变更、环境状态及未决问题。每完成一次 Tool Call，Runtime 需将新结果合并至当前状态，并让模型重新评估原计划的有效性。

这一过程产生了被称为“state rehydration”的实际成本。模型在下一轮推理时，不仅需要读取最新的测试日志，还需理解测试初衷、文件修改历史、已排除假设以及工作区相对于任务初始状态的变化。

随着任务推进，工作状态不断膨胀，每次重新进入推理阶段都需要恢复与当前决策相关的状态。失败路径会加剧这一问题：若 Agent 初期判断错误（如误判问题源于认证中间件），其产生的搜索记录、文件读取、逻辑修改及测试日志均会进入上下文。即使后续发现真实原因（如 session serialization），这些残留状态仍会保留在工作集中，增加后续处理负担。

因此，单纯扩大上下文窗口并不能解决 Agent 成本问题。上下文变大仅解决了历史数据的存储，而 Runtime 面临的挑战是如何筛选出应保留在当前 working set 中的有效内容。

高效的长期 Agent 应将直接依赖信息保留在活动区，将稳定结论压缩为结构化状态，并尽快剔除原始日志、重复搜索结果及失去依赖关系的观察数据。无效 Tool Call 的高昂代价不仅在于执行本身，更在于其制造了额外状态，导致后续节点需持续为此付出处理成本。减少不必要的 model-tool 边界交互成为优化关键。

Batch Tool Call 的本质机制

传统 ReAct 模式采用严格串行链：模型决定动作、工具执行、返回结果、模型再判断。这种方式默认工具间存在依赖，即便许多操作可并行执行。以代码排障为例，搜索异常字符串、读取配置、定位文件及检查符号引用等操作，往往仅需读取当前代码状态，彼此无强制顺序要求。

Batch Tool Call 要求模型在进入工具层前进行局部依赖判断，将可并行动作合并至同一批次。其核心在于压缩 synchronization barrier（同步屏障）。传统模式下，模型每获取一个结果需停顿以恢复状态并重新规划；而在批量模式下，模型预先确定所需信息集，消除中间多次停顿，待工具并行执行完毕后一次性接收结果。

这要求模型具备偏序规划（partial-order planning）能力，即识别动作间的先后关系、只读状态及状态改变操作。只读操作易于并行，而写操作需严格考虑 read-after-write 和 write-after-write 依赖，避免冲突。

执行图的压缩关键不在于并发数量，而在于同步点的位置。读取阶段应尽量推迟 barrier，实现信息收集的并行化；进入写操作后则需收紧执行顺序，确保状态一致性。

此外，批量执行面临 fan-out 过大导致的 fan-in 沉重问题。若大量并发结果原样进入上下文，节省的同步成本将以 observation 膨胀的形式回归。因此，Runtime 需在工具返回后执行 result reduction，合并重复内容，提炼长日志中与决策相关的片段，过滤低价值结果，再将压缩后的状态送回模型。

Sonnet 5.5 表现出更频繁的 batch 执行和更少的 Tool Call 总量，表明模型能在早期形成完整的信息需求集，减少后续补查。当模型开始参与执行图展开决策时，effort 的作用也随之转变：更多的 reasoning 不再仅是延长思考时间，而是直接决定后续是否展开新的工具和 subagent。

Effort 对执行图的调控作用

在 Agent 场景中，提高 effort 主要增加模型内部的 test-time compute。由于内部 reasoning 直接驱动外部动作，计算预算的分配位置至关重要。若模型在修改代码前通过额外 reasoning 发现接口顺序依赖，可避免后续的冲突、测试失败及回滚，以内部计算换取外部执行的减少。

反之，若证据已充分却继续扩展分析，可能导致启动过多的 code review 或 subagent，使额外计算转化为更多执行节点，甚至引发超时或越界修改。Anthropic 在 FrontierCode benchmarks 中发现 Max effort 表现低于 Xhigh，原因正是高 effort 导致执行图过度膨胀。

合理的 effort 策略应细化至节点级：在读取仓库、搜索 symbol 等低风险步骤使用较轻 reasoning 快速生成查询集；在跨文件写入、修改 schema 等高副作用动作前增加 reasoning，专注于依赖检查和 change-set planning；代码写入后尽快进入测试，利用真实环境反馈替代内部推演。

Checkpoint 机制同样重要。若每次失败均从头恢复状态，retry 将拉长执行链。Runtime 应在关键写操作前保存稳定状态，失败时仅回退最近变更，从可信节点继续。代码 Agent 可利用独立 worktree、临时分支或沙箱隔离候选修改，验证通过后合并，未通过则整体丢弃，从而限制失败影响范围。

至此，Agent Runtime 已演变为动态 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 分支的数量。这些数据能精准定位系统瓶颈在于模型、执行器、状态管理还是 Controller 本身。

Sonnet 5.5 带来的变革最终归结为一个工程核心：如何将更多计算资源投入到真正能消除后续执行成本的位置，避免 Agent 因过度 reasoning 而构建庞大的执行图。

参考链接：https://www.anthropic.com/claude-sonnet-5-5

【声明】内容源于网络

AI科技评论

聚焦AI前沿研究，关注AI工程落地。

内容 8980

粉丝 0

AI科技评论聚焦AI前沿研究，关注AI工程落地。

总阅读260.0k

粉丝0

内容9.0k