Red Hat 分析 219 个 Claude Code 会话：75% 时间在阅读

Red Hat 对 219 个真实 Claude Code 会话的分析（经 SemiAnalysis 转发）表明，中位数的 agent 轮次大部分时间在阅读上下文，而非编写代码。这颠覆了「生成是瓶颈」这一假设。

219 个真实 Claude Code 会话分析

• 中位轮次：约 75% 的 token 用于阅读上下文
• 25% 的 token 用于生成
• 数据来源：Red Hat，经 SemiAnalysis 转发

上下文，而非生成，才是瓶颈

一个编码 agent 的一个轮次大部分是阅读。在来自 SemiAnalysis 的 219 个真实 Claude Code 会话中，据 Red Hat 分析，中位请求约将 75% 的 token 用于阅读上下文。其余四分之一用于生成补丁或命令。

这个比例很关键，因为它重新定位了优化工作的方向。大多数 agentic 编码框架都在优化生成延迟——模型推理速度、投机解码、更小的草稿模型。但如果一个轮次中 75% 的 token 都消耗在阅读文件、diff 和工具输出上，那么将生成成本减半只能削减总延迟的一小部分。真正的杠杆是上下文管理：剪枝无关文件、缓存重复读取、压缩工具输出。

这与 agentic 编码市场的更广泛趋势一致。OpenAI 的 Codex、Anthropic 的 Claude Code 和 Google 的 Jules 都将更大的上下文窗口作为卖点——Claude 支持 200K token，Gemini 1M。但更大的窗口会带来臃肿的 prompt。数据表明，agent 正在消耗计算资源来反复重新读取相同的仓库状态，这是没有哪个模型发布直接解决的问题。

为什么这对基础设施团队很重要

对于基础设施团队来说，这个比例有直接的成本影响。Token 定价是对称的——在许多提供商那里，输入和输出每 token 成本相同。如果一个 agent 消耗的输入 token 是输出的 4 倍，那么输入 token 量决定了账单。大规模运行 agent 的企业应该预期上下文读取将主导其 API 支出，而不是生成。

Red Hat 的表述——「编码 agent 的一个轮次大部分是阅读」——对「agent 在写代码」这一营销叙事是一个有益的纠偏。它们大部分是在重新阅读。219 个会话的样本是真实的生产使用，而非基准测试，因此这个比例反映了实际工作负载：多文件仓库、长工具输出和迭代调试。

来源没有披露精确的 token 分配或跨会话的分布，所以将这 75% 作为一个中位数而非绝对标准。总体方向与之前关于 agent 效率的研究一致——最近实验室发现表明，在类似工具中，上下文缓存和检索主导了 agent 延迟。

给构建者的启示

对于构建编码 agent 的团队来说，这意味着要投资于上下文工程，而不仅仅是模型质量。像仓库索引、选择性文件包含和增量 diff 摘要这样的技术可能比换成更快的模型带来更大的延迟收益。对于模型提供商来说，机会在于更便宜的输入 token 或更智能的上下文压缩——这两者都是 Anthropic 和 OpenAI 的活跃研究领域。

关注下一代 agent 框架——Claude Code 2.0、Codex 改进或开源替代方案——是否会公开发布其读-to-写 token 比例。如果提供商开始优化上下文缓存——如 Anthropic 的 prompt caching 或 Google 的 context recycling——预期延迟和成本基准将会发生变化。还要关注企业 agent 日志在生产环境中是否显示类似的比例。

一个新工具：Headroom

一个新工具 Headroom 正是针对这一低效问题，它在上下文到达 API 之前对其进行压缩。其 README 报告，编码 agent 可减少 15–20% 的 token，对于 JSON 和构建日志等结构化负载，减少幅度高达 70–95%。Headroom 通过本地代理或 MCP 服务器路由 Claude Code，使用内容哈希和检索来保持保真度。一位实践者报告了一个月后约 26% 的真实节省。该工具的存在凸显了市场对上下文膨胀的日益增长的应对，验证了 Red Hat 的发现——阅读主导了 agent 轮次。

原文发布于 gentic.news