Anthropic 技术栈里的「五宗罪」由何而来？

比模型跑分掉了更麻烦的，是模型还在升级，用户却开始觉得越来越不好用。

Anthropic 最近就有点这个味道。

这几天 X 上有一条帖子，把 Claude 这段时间几种很典型的不满放到了一起：文本和代码开始被加入机器可读标记，Sonnet 5 的实际体验没有跟上模型升级的声势，Fable 5 卖得更贵，却很难让人明显感到它比 Opus 5 强在哪里；还有一个更刺眼的反馈，Fable 5 的上下文只用到大约 20%–30%，后面的能力就开始往下掉。

这几件事表面上没什么关系，一个像生成机制问题，一个像模型能力问题，一个像定价问题，还有一个干脆像长上下文出了毛病。

但放到 Claude 现在的技术栈里看，它们其实分别卡在 5 个很具体的位置：模型怎么生成，推理时愿意花多少计算，不同模型为什么越来越难分层，长上下文为什么没装满就开始失效，以及实验里的能力为什么到了真实 Agent 任务里经常打折。

所以 Anthropic 最近的问题，可能不是简单的“模型退步了”。更像是 Claude 越来越强之后，生成、计算、上下文和 Agent 运行时之间开始互相拖后腿了。

第一宗罪：毁掉了代码的生成空间

机器可读标记放在普通文本里，技术难点是既留下稳定信号，又尽量不改变生成质量。到了代码，这个问题会明显变难，因为自然语言和代码的 token 分布并不一样。

论文：https://arxiv.org/pdf/2301.10226

自然语言经常存在多个语义接近的候选。同一个意思可以换词、调语序，模型在很多位置拥有一定生成冗余。文本水印的一类常见思路，就是利用这种冗余，在多个可接受 token 之间轻微改变采样概率，积累足够长以后留下统计规律。

代码却有大量低熵位置。

变量声明之后，后续引用几乎只能使用同一个名字；JSON 的字段、引号和括号受严格结构约束；函数参数必须符合接口；路径、正则、SQL、Shell 命令里，一个 token 发生变化就可能直接改变行为。

从概率分布看，这些位置往往非常尖锐。正确 token 占据很高概率，其他候选不是另一种表达，而可能就是错误。因此，代码水印面对的核心限制其实是编码容量。

如果一个位置只有一种合理输出，它几乎没有空间承载额外信号；如果系统只在高熵位置嵌入标记，又会遇到代码短、结构化 token 比例高、可利用位置不足的问题。

于是可检测强度、生成质量和抗修改能力之间会形成直接取舍：信号太弱难以检测，约束太强可能影响正确生成，而经过格式化、局部改写之后还想保留检测能力，又需要更高的信号冗余。

论文：https://arxiv.org/pdf/2301.10226

Anthropic 没有公开 Claude 文本标记具体怎样改变采样，因此不能把 Claude Code 的质量变化直接归因到某一种水印算法。

这里能确定的是另一个变化：代码生成正在同时承担越来越多约束。除了语义和执行正确性，它还可能需要服从工具协议、结构化格式、安全规则和来源标记，而代码本身能够吸收这些额外约束的自由度远小于自然语言。

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

Sonnet 5 的 adaptive thinking 带来的变化，并不只是让模型多想一会。

以前谈 Sonnet、Opus、Fable，很容易把它们理解成几个固定能力点。现在加入 effort 以后，同一个模型可以落在不同的 test-time compute 区间里，型号本身已经不能完整代表一次请求实际投入了多少能力。

参考链接：https://platform.claude.com/docs/en/build-with-claude/effort

这个变化放到 Coding Agent 里尤其明显。Claude 面对一个 bug 时，不只需要生成修改方案，还需要决定读哪些文件、追哪条调用链、保留几个候选假设、要不要运行测试、是否继续检查依赖，以及什么时候认为证据已经足够。

这些动作可以看成一棵搜索树。较低的计算投入意味着更早剪掉分支、更快形成判断；更高的投入允许模型继续搜索和验证，减少在证据不足时直接执行动作的概率。

参考链接：https://platform.claude.com/docs/en/build-with-claude/effort

因此 effort 调节的不是单纯的 thinking 长度，而是一次 Agent 任务允许展开多大的搜索范围。这会直接改变 Anthropic 的模型分层。

如果一个普通 coding 任务对 Opus 已经不难，提高 effort 以后，Opus 很可能快速进入性能平台区。Fable 即使拥有更强的基础模型，也没有多少剩余难度可以转化成明显体验差。

用户却从请求开始就要支付型号之间的价格差。于是 Fable 更容易体现价值的，不会是常规代码解释、小规模重构或者普通 debugging，而是陌生代码库、多阶段规划、跨工具操作、长时间自主执行，以及错误发生以后仍需要恢复的任务。

参考链接：https://www.anthropic.com/news/claude-opus-5

这意味着高阶模型出售的东西正在发生变化。它卖的不再只是“这一轮答案更强”，而是更复杂轨迹里的额外可靠性。

问题在于，这种优势需要任务足够长才能展开，而任务一旦拉长，模型能力就不再是唯一决定因素，上下文状态开始进入核心位置。

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

看到 1M context，很容易把它理解成一块巨大的工作内存，因此当 Claude 只使用 200K 或 300K token 就开始遗漏、反复甚至出现状态混乱时，会显得非常反直觉。

但 context window 衡量的是容量，不是状态一致性。长 Agent 会话也不是一篇静态文档，而是一份不断追加的执行历史。

参考链接：https://platform.claude.com/docs/en/build-with-claude/context-windows

一个文件可能先后被修改几次；某个 bug 最初被判断成缓存问题，后来发现来自并发；一个测试可能先失败、随后通过，又因为新的修改重新失败。旧内容不会随着状态变化自动删除，新内容只是继续追加在后面。

这里出现的问题已经不只是 retrieval。模型不仅要找到和当前任务相关的信息，还要判断这些信息现在是否仍然有效。

旧版函数和新版函数高度相似，旧测试日志和新测试日志包含大量相同 token，已经被推翻的分析也可能和当前问题在语义上高度相关。Attention 找到这些内容并不困难，困难的是确定它们之间的覆盖关系。

数据库可以靠版本号、更新时间、事务和显式字段维护 current state，自然语言 context 通常没有这种结构。它更接近 append-only log，模型需要自己从事件顺序中恢复现在的世界是什么样。

参考链接：https://platform.claude.com/docs/en/build-with-claude/context-windows

因此，长上下文的复杂度并不和 token 占用比例简单对应。250K token 的静态文档可能比 250K token 的 Agent 历史容易处理得多，因为后者包含大量被修改过的对象、阶段性判断、工具结果和已经失效的状态。

Thinking history 还会进一步增加这种复杂度。会话里保存的不只是“发生过什么”，还可能包含“当时为什么这么判断”。如果早期 reasoning 建立在一个后来被推翻的假设上，那段推理仍然可能因为和当前问题高度相关而继续参与后续判断。

所以 1M context 的真正限制不只是能放多少信息，而是当同一个对象出现越来越多历史版本以后，模型还能不能稳定恢复当前版本。

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

当 context 继续增长，compaction 看起来像一个自然办法：把旧历史压短，再继续执行。但 Agent 场景里的 compaction 和普通摘要并不是一回事。

摘要文章时少掉一个例子，影响通常只是信息完整度；压缩 Agent 轨迹时，遗漏一个仍然有效的限制条件，后面的执行路径可能直接改变。

参考链接：https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools

因为 compaction 必须解决的不是“哪些内容重要”，而是“哪些内容现在还算数”。一段历史里可能同时存在已经完成的任务、后来被推翻的判断、当前仍然成立的接口约束、过期测试结果和临时 workaround。压缩器需要把这些时间状态重新整理成一个能够供下一轮继续工作的表示。

如果“目前怀疑问题来自缓存”被压成“问题来自缓存”，临时假设就变成了事实；如果一个已经废弃的方案仍然进入摘要，后面的 Agent 可能重新沿旧路径执行；如果某项关键限制没有进入摘要，它之后甚至不会再被模型看到。

所以 compaction 的关键指标不是压缩率，而是状态保真。这也是 Git、测试、任务文件、memory 和结构化 handoff 在长时 Agent 中越来越重要的原因。

它们不是单纯增加模型能看到的信息，而是在把一些需要长期成立的状态，从自然语言历史中移到外部系统。Git 明确当前代码版本，测试给出可验证结果，任务文件记录完成情况，结构化状态区分当前结论和历史尝试。

Context 可以保留丰富历史，但不能长期承担全部状态管理职责。

参考链接：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

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

前面的几个问题仍然可以理解成模型如何处理输入。Agent 再往前一步，因为它会主动修改环境。

普通聊天里，模型答错一次，错误通常停留在输出文本。Agent 可以修改代码、执行命令、安装依赖、调整配置，再读取这些动作产生的新结果。

于是错误不再只是判断错误，还会变成环境变化。假设 Claude 把一个 bug 错判成缓存问题，于是修改缓存逻辑、重试机制和几个调用点。测试随后出现一批新的异常。

这些异常是真实的，但它们并不是原始 bug 自然产生的，而是上一轮修改制造出来的。这会让 Agent 进入一种很特殊的失败模式：模型开始分析自己创造出来的数据分布。

参考链接：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

如果它能识别“这些新错误是在上一轮修改之后出现的”，还可以回滚并重新检查原始假设；如果没有建立这层因果关系，就可能继续把新错误视为独立问题，一个接一个修补。

此时每一步局部操作都可能有依据，但整条任务轨迹已经偏离原来的问题。所以长 Agent 的可靠性不能只看单步正确率。更关键的是错误进入环境以后，系统能不能检测、归因和恢复。

Git diff 可以告诉模型哪些变化刚刚发生，测试可以验证某项行为有没有被破坏，checkpoint 和 rollback 可以限制错误扩散，独立 evaluator 则可以在模型自己的解释之外提供额外校验。

这些组件的作用，本质上是在给 Agent 增加闭环纠错能力。

参考链接：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

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

很多 benchmark 测的是：给模型一个初始化好的环境，它能不能完成任务。真实 Agent 多了一层困难：环境会随着模型自己的动作不断变化。因此两个最终通过率接近的模型，真实体验可能完全不同。

一个模型可能前期判断很准，但一旦走错就不断沿错误路径修补；另一个模型单步未必明显更强，却能更快发现某次修改制造了新问题，然后回滚重新选择路径。

只看终点，很难区分这两种行为。如果 Agent 任务继续拉长，更有意义的指标会变成 compaction 之后关键状态保留了多少、错误修改发生以后能否找到引入错误的步骤、随着工具调用增加内部任务状态是否继续和真实环境一致，以及发生偏航之后需要付出多大代价才能恢复。

这些指标测的不是一次 response 有多聪明，而是一条 trajectory 能不能保持可控。

综上所述，Anthropic 最近暴露出来的几类问题，其实落在不同层面。这些问题集中出现以后，Claude 的技术瓶颈也开始发生变化。

过去更像是在问模型能不能把某一道题做出来，现在更难的是另一件事：当任务运行几个小时、经过几十轮工具调用、几次状态压缩和多次代码修改以后，系统还能不能维持一份可信的当前世界。

模型能力继续增长，只能提高每一步判断的上限。而长 Agent 能不能稳定工作，越来越取决于另一套能力：状态是否清楚，动作是否可验证，错误是否可回滚。

JOTO 企业落地观察

• 对企业部署意味着：长时 Agent 的稳定性不再仅依赖模型能力，而需同步构建外部状态管理（如 Git 版本、结构化任务状态）与闭环纠错机制（如 checkpoint 回滚、独立 evaluator），否则模型越强，错误扩散风险越高。
• 这类系统的取舍在于：是否将部分状态管理职能从自然语言 context 中剥离至专用系统。完全依赖 context 会随长度增长迅速劣化，但引入外部系统将增加工程复杂度与运维成本。
• 对智能体工程而言，effort 机制使模型能力呈现连续谱而非离散档位，企业需重新设计 API 调用策略——不再按型号付费，而需根据任务复杂度动态调节计算预算，这对成本控制与 SLA 设计提出新要求。
• 在 AI 安全治理层面，Agent 自我修改环境带来的错误放大效应，要求企业级部署必须强制嵌入不可绕过的验证环节（如测试执行、diff 校验），仅靠 prompt 约束或模型内省已不足以保障生产环境可靠性。