Claude Code 2.1.232-2.1.312 Token 使用量与智能体摘要优化

Claude Code 的 Token 开销问题

Claude Code 是 Anthropic AI 编码智能体的命令行界面，研究发现它会将约 15–20% 的用户 Token 配额消耗在几乎没有实际用途的后台任务上。具体来说，该工具会定期将整个会话记录发送给模型，以生成一个 3-5 个词的智能体 UI 面板状态更新。自 2.1.232 版本以来，此行为默认为开启状态，导致速率限制额度和 Token 配额出现显著且往往难以察觉的消耗。

技术根本原因

后台智能体每 30 秒会发起一次 agent_summary 查询。对 OpenTelemetry 导出的数据分析显示，这些摘要请求占该工具所有 API 调用量的近 20%。虽然许多此类请求受益于提示词缓存（prompt caching），但其极高的频率（大约每五个请求中就有一个）导致了巨大的累积成本。由于该二进制文件是以预编译的 Bun 字节码形式分发的，标准配置文件并未提供在不禁用子智能体或分支等必要智能体功能的情况下，关闭这些特定后台调用的开关。

实施变通方案

为了回收这些 Token，我们开发了一个 Bun 预加载脚本，用于拦截负责摘要计时的特定 setTimeout 或 setInterval 调用。通过源文本锚点识别计时器回调，该脚本可以有效抑制摘要请求，同时保持其他智能体操作不受影响。

用户可以通过全局设置 BUN_OPTIONS 环境变量来预加载该抑制脚本，从而应用此修复：

export BUN_OPTIONS="--preload /path/to/no-agent-summary.js"

应用预加载后，用户必须重启 Claude Code 守护进程 (claude daemon stop --any)，以确保所有活动会话都能继承新的环境变量。可以通过监控 OpenTelemetry 导出数据中的 query_source 来验证此抑制效果，此时 agent_summary 请求应降至零。

社区见解与细微差别

围绕这一发现的讨论突显了关于 AI 智能体设计和供应商激励机制的几个关键观点：

• 激励错位： 评论者指出，当模型提供商同时构建智能体框架时，几乎没有动力去优先考虑 Token 的使用效率。正如一位用户所观察到的：“模型制造商完全没有动力去优先考虑高效的 Token 使用。”
• 验证挑战： 虽然一些用户质疑提示词缓存是否能减轻成本，但独立测量证实了其对总 Token 支出 15-20% 的影响。用户报告称，即使在缓存命中的情况下，在运行长期会话时，这种开销依然显著。
• 更新风险： 由于该变通方案依赖于匹配二进制文件回调函数中的特定内部字符串，Claude Code 的未来更新可能会破坏此钩子。建议用户在每次更新后重新验证其遥测数据，以确保抑制功能依然有效。
• 替代观点： 一些用户指出，影响程度可能因使用模式而异，某些工作流（例如“ultracode”）受到的影响可能比重度依赖子智能体的任务要小。其他人则对该工具日益臃肿表示不满，认为极简主义仍然是替代编码助手的一个关键差异化优势。

此变通方案按原样提供，与 Anthropic 无关。建议用户通过 OpenTelemetry 监控自己的 API 使用情况，以确定此优化是否对其特定工作流有必要。