事件概述

Anthropic 发布了 Claude Sonnet 5.5。虽然 API 单价未变且生成速度提升，但运行数据揭示了更深层次的架构变化：Tool Call 数量减少约三分之一，Shell Run 接近减半，Base44 应用构建任务的平均迭代次数从 7.7 次降至 3.6 次。新模型更频繁地将多个工具调用置于同一批次执行，标志着 Agent 成本优化重心从“模型智能”转向“Runtime 工程效率”。

核心信息

1. Agent 工作状态的膨胀与成本陷阱

• State Rehydration 成本：Agent 需持续维护包含用户目标、假设、工具返回、代码改动等的工作状态。每次 Tool Call 后，模型需重新恢复并判断计划，导致计算资源在状态合并上大量消耗。
• 上下文管理的困境：长上下文仅解决历史保存问题，无法解决“哪些内容应留在当前 Working Set”的问题。无效 Tool Call 会制造额外状态（如错误日志、残留修改），导致后续节点在处理中付出更高成本。
• 优化方向：稳定的长期 Agent 需将直接依赖信息保留在活动区，将稳定结论压缩为结构化状态，并尽快让原始日志和低价值观察退出工作集。

2. Batch Tool Call 的本质：同步屏障的压缩

• 传统 ReAct 局限：串行执行默认工具间存在依赖，即使操作可并行也需多轮交互，每轮都涉及状态恢复和重新规划。
• 局部依赖判断：Sonnet 5.5 要求模型在进入工具层前进行 Partial-order Planning，区分只读操作（易并行）和写操作（需考虑读写冲突）。通过推迟读取阶段的同步点，实现工具并行运行，一次性交回结果。
• Fan-in 风险与 Result Reduction：并发增加可能导致返回结果（Observation）膨胀。Runtime 需在工具返回后进行结果压缩，合并重复内容，过滤低价值结果，防止同步成本的节省被上下文膨胀抵消。

3. Effort 策略对执行图的影响

• Test-time Compute 的双刃剑：增加 Effort 可能通过前置依赖检查避免后续冲突和执行失败，但也可能因过度推理导致执行图膨胀（如启动过多 Subagent 或 Code Review 分支）。
• 节点级 Effort 分配：
  • 低风险步骤（如读取仓库、搜索 Symbol）：使用较轻的 Reasoning 快速生成查询集合。
  • 高风险步骤（如跨文件写入、修改 Schema）：增加 Reasoning 预算，专注于依赖检查和 Change-set Planning。
  • 验证阶段：代码写入后尽快进入测试，利用真实环境反馈而非继续内部推演；若失败，再根据新 Observation 提高 Reasoning。
• Checkpoint 机制：在关键写操作前保存稳定状态，失败时仅回退最近变更，避免从头重试导致的执行链拉长。利用独立 Worktree 或沙箱隔离候选修改，通过后再合并。

值得关注

• 成本指标的转变：衡量 Agent 系统的核心指标应从输入/输出 Token 转向：
  • 一次任务经历的 Model-Tool Barrier 数量。
  • Batch 中结果被后续决策使用的比例。
  • 失败后的回退距离。
  • Active Working Set 的增长程度。
  • Subagent 产生的未提交分支数量。
• 工程本质：Sonnet 5.5 的变化表明，模型能力直接影响 Agent Runtime 结构。未来的优化重点是如何将计算资源投入到能消除后续执行成本的位置，而非通过更多 Reasoning 制造更大的执行图。