深度拆解 Sonnet 5.5 ：半价 Opus 只是表象，Agent Runtime 才是变化核心
📋 文章概况
一篇对 Anthropic 刚发布的 Claude Sonnet 5.5 的深度技术解读，核心论点是：这次升级的真正变化不在模型输出层，而在 Agent Runtime 的结构——模型获得了"静态依赖分析"和"执行图压缩"能力，使原本笨重的 model—tool 循环得以瘦身。文章围绕 state rehydration、Batch Tool Call、effort 的节点级分配、checkpoint 与回滚四个层面展开。
💎 独特亮点
- Agent 成本不能只看 Token，要看 model—tool barrier 的密度：文章提出一次任务真正消耗资源的地方还包括工具等待、状态回填、重新规划、上下文增长和失败恢复。Sonnet 5.5 在 Lovable 测试中 Tool Call 减少约三分之一，Shell Run 接近减半，Base44 应用构建任务平均迭代次数从 7.7 次降到 3.6 次——这些数据直接量化了"模型变聪明"对 runtime 成本的压缩效果。
- "state rehydration"是长期 Agent 的隐性成本：每跨一次 model—tool 边界，模型都需要重新恢复与当前决策相关的工作状态（已验证假设、文件改动、环境状态、未解决问题）。失败路径会放大这个问题——错误搜索和错误修改产生的残留状态会持续进入 working set，后面的正确路径也要为它们付出处理成本。长上下文窗口解决的是"历史能不能保存"，runtime 更难处理的是"哪些内容还应该留在当前 working set"。
- effort 增加 test-time compute 可能反向扩大执行图：Anthropic 在 FrontierCode 上出现过 Max effort 低于 Xhigh 的情况，解释是高 effort 让模型更频繁调用 code-review skill 并拆给多个 subagent，部分分支超时或产生超出任务边界的修改。effort 改变了 branch factor——更多内部推理不一定减少外部执行，反而可能制造更大的执行图。
🔧 可动手实践
| 目录点 | 你可以做什么 | 可动手程度 |
|---|---|---|
| 用 model—tool barrier 密度替代 Token 计数作为 Agent 成本指标 | 在你自己的 Agent 项目中埋点统计：一次任务经历多少次 model—tool 往返、batch 中多少结果真正被后续决策使用、失败后回退多远、active working set 增长曲线、subagent 产生多少未提交分支。用这些数据定位问题出在模型、执行器、状态管理还是 controller | ✅可实现 |
| 在工具返回后做 result reduction | 在 runtime 中增加工具返回的压缩层：合并重复内容、把长日志缩成与当前决策相关的片段、过滤低价值结果，再把压缩后的状态送回模型，防止 observation 膨胀抵消 batch 并行省下的同步成本 | ✅可实现 |
| 节点级 effort 分配策略 | 把 effort 从"整条任务固定档位"改为按节点风险分配：读取仓库、搜索 symbol 用轻 reasoning；跨文件写入、改 schema、高副作用动作前增加 reasoning 做依赖检查和 change-set planning；代码写入后尽快进入测试，用真实环境反馈替代内部推演 | ✅可实现 |
| 写操作前 checkpoint + 隔离验证 | 在关键写操作之前保存稳定状态，失败后只回退最近一次变更；用独立 worktree、临时分支或沙箱隔离候选修改，subagent 验证通过后再合并，未通过的分支整体丢弃 | ✅可实现 |
工作流（最小实验）:
- 选一个你当前 Agent 项目中反复出现"多轮工具调用但进展缓慢"的任务类型（如代码排障、跨文件重构）。
- 在 runtime 中加一层工具返回压缩：对每个工具返回做去重和截断，只保留与当前决策直接相关的片段，记录压缩前后的 token 量和模型下一轮决策质量。
- 把 effort 改为节点级：在写操作前显式插入一轮依赖检查（哪些 change-set 有先后关系、哪些文件会被同时修改），记录是否避免了冲突、测试失败或回滚。
- 对比改造前后同一任务类型的 model—tool barrier 次数、总耗时和成功率。
🧠 可复用认知
- Agent 的瓶颈会从"模型不够聪明"迁移到"runtime 不够聪明"：当模型具备了依赖分析和执行图压缩能力后，runtime 是否支持 batch、是否做 result reduction、是否在正确位置放 checkpoint，直接决定了模型能力的兑现程度。模型能力和 runtime 结构是耦合进化的。
- 计算预算的位置比总量更重要：同样一份 test-time compute，放在"错误代价更高的节点之前"（依赖检查、change-set planning）可以消除后续失败执行，放在"证据已经足够之后"则会制造更多 subagent 和验证分支，把执行图越做越大。
- 同步点（synchronization barrier）是 Agent 执行效率的核心变量：执行图能不能压缩，关键不是一次发出多少 Tool Call，而是同步点放在哪里——读取阶段尽量推迟 barrier 让信息收集并行完成，写操作阶段收紧执行顺序防止状态互相覆盖。
🏷️ 关键词
#Agent-Runtime #state-rehydration #Batch-Tool-Call #model-tool-barrier #执行图压缩 #partial-order-planning #result-reduction #节点级effort #checkpoint回滚 #working-set
分类标签: Agent架构 上下文管理 成本控制
📊 价值判断
推荐等级: 值得一看（深度/实现细节维度强：文章给出了 state rehydration、synchronization barrier、result reduction、节点级 effort 等可操作的 runtime 设计概念，并附有 Sonnet 5.5 的具体运行数据作为证据；这些机制层面的分析无法在摘要中完整展开，原文的因果链论证对理解"为什么模型能力会改变 runtime 结构"有实质帮助）
最值得看: 第 02 节"Batch Tool Call 与同步点压缩"和第 03 节"effort 的节点级分配"——这两节包含了最具体的机制分析和 FrontierCode 上 Max effort 低于 Xhigh 的反直觉案例
适合场景: 你正在设计或优化自己的 Agent runtime（尤其是代码 Agent），需要一套超越 Token 计数的成本分析框架；或你想理解为什么模型升级后 Agent 系统的瓶颈会从模型层转移到 runtime 层