近期，社交媒体 X 上一条帖子集中反映了用户对 Claude 的诸多不满：文本和代码被加入机器可读标记，Sonnet 5 的实际体验未能匹配模型升级的声势，Fable 5 定价更高却难以让用户明显感到比 Opus 5 更强，且 Fable 5 的上下文仅使用约 20%–30% 时后续能力就开始下降。这些表面零散的问题，在 Claude 的技术栈中分别对应五个具体环节：生成机制、推理计算投入、模型分层、长上下文状态管理以及 Agent 错误回灌。Anthropic 的瓶颈正从单点能力转向轨迹可靠性。

第一宗罪：代码生成空间被压缩

机器可读标记嵌入普通文本时，技术难点在于既留下稳定信号又不损害生成质量。但在代码场景中，这一难题显著加剧，因为自然语言与代码的 token 分布差异巨大。自然语言常存在多个语义接近的候选，模型拥有生成冗余，文本水印可借此在可接受 token 间微调采样概率。而代码包含大量低熵位置：变量声明后引用几乎只能使用同一名字，JSON 的字段、引号和括号受严格结构约束，函数参数必须符合接口，路径、正则、SQL、Shell 命令中一个 token 变化就可能改变行为。这些位置的概率分布尖锐，正确 token 占据高概率，其他候选往往就是错误。因此，代码水印面临的核心限制是编码容量：若位置只有一种合理输出，则几乎没有空间承载额外信号；若仅在高熵位置嵌入标记，又会遇到代码短、结构化 token 比例高、可利用位置不足的问题。可检测强度、生成质量与抗修改能力之间形成直接取舍。Anthropic 未公开 Claude 文本标记如何改变采样，因此不能将 Claude Code 的质量变化直接归因于某一种水印算法。但可以确定的是，代码生成正承担越来越多约束——除语义和执行正确性外，还需服从工具协议、结构化格式、安全规则和来源标记，而代码吸收额外约束的自由度远小于自然语言。

第二宗罪：模型档位变成计算曲线

Sonnet 5 的 adaptive thinking 带来的变化不仅是让模型多想一会。以往 Sonnet、Opus、Fable 可理解为固定能力点，现在加入 effort 后，同一模型可落在不同 test-time compute 区间，型号本身已不能完整代表一次请求实际投入的能力。在 Coding Agent 中，Claude 面对 bug 时需决定读哪些文件、追哪条调用链、保留几个候选假设、是否运行测试、是否继续检查依赖，以及何时认为证据足够。这些动作构成一棵搜索树：较低计算投入意味着更早剪枝、更快形成判断；更高投入允许继续搜索和验证，减少证据不足时直接执行的概率。因此 effort 调节的不是单纯 thinking 长度，而是 Agent 任务允许展开的搜索范围。这改变了模型分层：若普通 coding 任务对 Opus 已不难，提高 effort 后 Opus 可能快速进入性能平台区，Fable 即使基础模型更强，也没有剩余难度转化为明显体验差，但用户从请求开始就支付型号间的价格差。Fable 的价值更体现在陌生代码库、多阶段规划、跨工具操作、长时间自主执行及错误恢复等任务上。高阶模型出售的不再是“这一轮答案更强”，而是复杂轨迹里的额外可靠性。但该优势需任务足够长才能展开，而任务拉长后，上下文状态开始成为核心因素。

第三宗罪：能装海量历史，却理不清当前状态

看到 1M context，容易将其理解为巨大工作内存，因此当 Claude 仅使用 200K 或 300K token 就开始遗漏、反复甚至状态混乱时，显得反直觉。但 context window 衡量的是容量，不是状态一致性。长 Agent 会话不是静态文档，而是不断追加的执行历史：文件可能被多次修改，bug 最初被判断为缓存问题后来发现来自并发，测试先失败后通过又因新修改重新失败。旧内容不会自动删除，新内容只是追加。问题已超出 retrieval：模型不仅要找到相关信息，还要判断这些信息是否仍然有效。旧版函数与新函数高度相似，旧测试日志与新日志包含大量相同 token，已被推翻的分析也可能与当前问题语义相关。Attention 找到这些内容不难，难的是确定覆盖关系。数据库可依靠版本号、更新时间、事务和显式字段维护 current state，而自然语言 context 通常没有这种结构，更接近 append-only log，模型需自行从事件顺序恢复当前世界。因此，长上下文的复杂度与 token 占用比例并非简单对应：250K token 的静态文档可能比 250K token 的 Agent 历史容易处理得多。Thinking history 还会增加复杂度，会话中保存的不只是“发生过什么”，还可能包含“当时为什么这么判断”，早期 reasoning 若建立在后来被推翻的假设上，仍可能因高度相关而继续参与判断。所以 1M context 的真正限制不只是能放多少信息，而是当同一对象出现越来越多历史版本后，模型能否稳定恢复当前版本。

第四宗罪：压缩的是历史，重新生成的是状态

当 context 继续增长，compaction 看似自然：把旧历史压短再继续执行。但 Agent 场景的 compaction 与普通摘要不同。摘要文章少掉一个例子，影响通常只是信息完整度；压缩 Agent 轨迹时，遗漏一个仍有效的限制条件，后续执行路径可能直接改变。compaction 必须解决的不是“哪些内容重要”，而是“哪些内容现在还算数”。一段历史中可能同时存在已完成任务、被推翻判断、仍成立的接口约束、过期测试结果和临时 workaround，压缩器需将这些时间状态重新整理成可供下一轮工作的表示。若“目前怀疑问题来自缓存”被压成“问题来自缓存”，临时假设就变成事实；若已废弃方案仍进入摘要，后续 Agent 可能重走旧路径；若关键限制未进入摘要，它之后甚至不会被模型看到。因此 compaction 的关键指标不是压缩率，而是状态保真。这也是 Git、测试、任务文件、memory 和结构化 handoff 在长时 Agent 中越来越重要的原因——它们将需长期成立的状态从自然语言历史移到外部系统：Git 明确当前代码版本，测试给出可验证结果，任务文件记录完成情况，结构化状态区分当前结论和历史尝试。Context 可保留丰富历史，但不能长期承担全部状态管理职责。

第五宗罪：模型修补自己制造的 Bug，错误越来越大

Agent 会主动修改环境，这是与普通聊天的根本区别。普通聊天中模型答错一次，错误停留在输出文本；Agent 可修改代码、执行命令、安装依赖、调整配置，再读取新结果。于是错误不再只是判断错误，还会变成环境变化。假设 Claude 将 bug 错判为缓存问题，修改缓存逻辑、重试机制和调用点，测试随后出现一批新异常。这些异常是真实的，但并非原始 bug 自然产生，而是上一轮修改制造出来的。这使 Agent 进入特殊失败模式：模型开始分析自己创造出来的数据分布。若它能识别“这些新错误是在上一轮修改之后出现的”，可回滚并重新检查原始假设；若未建立因果关系，就可能继续将新错误视为独立问题，一个接一个修补。此时每一步局部操作都有依据，但整条任务轨迹已偏离原始问题。因此长 Agent 的可靠性不能只看单步正确率，更关键的是错误进入环境后系统能否检测、归因和恢复。Git diff 可告知模型哪些变化刚发生，测试可验证行为是否被破坏，checkpoint 和 rollback 可限制错误扩散，独立 evaluator 可提供额外校验。这些组件的作用本质上是给 Agent 增加闭环纠错能力。

结语：Benchmark 缺的是轨迹可靠性

许多 benchmark 测的是给定初始化环境后模型能否完成任务，而真实 Agent 多了一层困难：环境会随模型自身动作不断变化。因此两个最终通过率接近的模型，真实体验可能完全不同：一个前期判断准但走错后不断沿错误路径修补；另一个单步未必更强，却能更快发现修改制造的新问题并回滚重选路径。只看终点难以区分这两种行为。若 Agent 任务继续拉长，更有意义的指标将变成：compaction 后关键状态保留多少、错误修改后能否找到引入错误的步骤、工具调用增加时内部任务状态是否与真实环境一致、发生偏航后恢复代价多大。这些指标测的不是单次 response 的聪明程度，而是一条 trajectory 能否保持可控。Anthropic 最近暴露的问题落在不同层面，集中出现后，Claude 的技术瓶颈正从“能否解出某道题”转向“当任务运行数小时、经过几十轮工具调用、多次状态压缩和代码修改后，系统能否维持一份可信的当前世界”。模型能力增长提高每一步判断的上限，而长 Agent 能否稳定工作，越来越取决于状态是否清楚、动作是否可验证、错误是否可回滚。