首页 / 资讯详情
Claude Code 额度回落：Agent 正在制造新的「祖传代码屎山」？
摘要
代码确实是 Agent 写的，只是后来的 Agent 已经不知道前面的 Agent 为什么这么写了。 作者丨郑佳美 编辑丨岑 峰 Claude Code 原定于 8 月 19 日结束的 +50% 周额度加成，又被 Anthropic 延长到了 8 月 31 日。也就在原定截止日前后，Hacker News 上出现了一轮关于 Claude Code 使用成本的讨论：不少人发现，一个并不复杂的任务，Agent 跑上几轮，额度就会掉得很快。问题在于，Claude Code 消耗的并不只是最后生成的那几行代码。读文件、搜调用链、跑测试、处理日志，每一步都会继续进入后面的上下文。任务越长，Agent 背着的历史越重，系统也越依赖清理和压缩。代码可以完整留在仓库里，早期的设计理由却可能在压缩中逐渐变薄。于是 Token 消耗和代码屎山开始在同一个地方汇合。01修个小 Bug，为何需要几十次推理？普通 Chat coding 的计算边界很清楚。输入一段代码，模型读完以后给出解释或者修改方案，这一轮基本结束。雷峰网而 Claude Code 的基本单元换成了 agent loop。模型先观察当前状态，决定下一步要读哪个文件或者执行什么命令；工具返回结果以后，模型再进行下一轮判断。读源码、搜索引用、运行测试、查看 Git diff、修改文件，看上去像一个连续动作，在模型侧其实是一串独立的推理请求。Claude Code 官方文档也把这种“模型判断—调用工具—根据结果继续判断”的循环作为 Agent 工作方式的核心。比如一个登录状态偶发失效的问题。Agent 先找到入口，发现状态来自 service，于是继续读取 service；看到缓存后搜索谁在写它；接着跑测试，测试出现另一个异常，于是去看 fixture；修完以后再次验证，旧测试又暴露出兼容问题。可能直到这时，它才真正开始写那几行代码。因此，diff 大小和计算量之间几乎不存在稳定比例。5 行补丁背后可能只有 3 次推理，也可能已经经过 30 次工具交互。如果把一次 Agent 任务拆开，可以先得到两个变量：一个是 step count，Agent 为了完成任务走了多少步；另一个是 working set，走到当前这一步时，模型还需要掌握多少项目状态。只增加 step count 已经会提高消耗。如果 working set 还在同步变大，情况就完全不同了。第 3 步也许只需要处理几千 Token，第 30 步却可能已经背着项目规则、相关源码、测试结果、修改历史和工具返回继续推理。雷峰网这也是 Coding Agent 成本结构发生变化的起点：计算量开始取决于“走多少步 × 每一步背多重”，而不再取决于写了多少行代码。02Token 到底烧在哪里？把 Agent 的一次模型请求拆开，可以粗略看成三块。相对稳定的部分包括 system prompt、CLAUDE.md、工具定义和项目规则；不断变化的部分包括代码文件、搜索结果、测试日志、Git diff 和此前的任务轨迹；最后还有这一轮模型生成的 reasoning、文字与代码。这里容易产生一个误区：只要前面的内容已经读过，就不应该重复产生太多成本。问题在于，LLM 两次请求之间不存在一个传统程序那样可以随时访问的内部内存。上一轮知道的信息，如果下