核心判断：Agent 产品的“聪明程度”不只由底层模型决定。默认推理预算、上下文保留策略和系统提示词，任何一项改动都可能让同一个模型表现得像换了能力档位。
一次质量波动，暴露三层产品变量
2026 年 4 月，Anthropic 回应 Claude Code、Claude Agent SDK 和 Claude Cowork 用户的质量反馈，并公开三项已经回滚或修复的产品层问题：默认 reasoning effort 下调、会话 thinking 清理异常，以及压缩输出的系统提示词改动。
这份复盘最值得关注的地方，不是某个具体版本“变笨了”，而是它证明了 Agent 的最终质量来自一整套运行系统。模型权重不变，周边配置仍然可以显著改变用户体验。
变量一：默认推理预算就是产品能力
Anthropic 披露，Claude Code 在 3 月 4 日把默认 reasoning effort 从 high 调整为 medium，目的是减少延迟和额度消耗；该默认值在 4 月 7 日回滚。
对平台来说，这是合理的成本与响应时间优化。对复杂编码任务来说，它却可能减少模型用于规划、检查和恢复错误的计算预算。用户看到的不是一个配置项，而是 Agent 是否愿意多想一步。
因此，团队评测 Coding Agent 时不能只记录模型名称，还要固定：
- reasoning effort 或等价推理档位；
- 最大 token 与上下文限制；
- 工具调用预算；
- 超时、重试和压缩策略；
- 产品版本与日期。
缺少这些信息，同一模型的两次评测可能根本不可比较。
变量二：工作记忆不只是聊天记录
第二个问题来自 idle session 的 thinking 清理优化。官方复盘称，3 月 26 日引入的改动存在 bug，导致后续轮次持续清除更早的 thinking；用户可能观察到 Agent 健忘、重复劳动或选择奇怪的工具。问题于 4 月 10 日修复。
长程 Agent 需要保留的状态远多于对话文本：
- 已完成和待完成的子任务；
- 为什么选择当前方案；
- 工具执行结果与失败原因；
- 已验证的假设；
- 可恢复的检查点。
如果只保留最终回答、丢掉中间决策路径，Agent 仍然可以继续输出，却可能无法延续原来的计划。表面上像模型失忆，本质上是运行时状态被破坏。
工程上应把关键状态从隐式 thinking 中抽出来，保存为结构化计划、任务状态和验证记录。这样即使对话被压缩或会话恢复，Agent 仍能从明确检查点继续。
变量三：系统提示词是需要回归测试的代码
第三项改动发生在 4 月 16 日。Anthropic 为了让输出更简洁，修改了系统提示词；更广泛的评测随后显示约 3% 的质量下降，团队在 4 月 20 日回滚。官方同时说明，这一问题没有影响 API。
“少说一点”听起来像纯文风优化，但在编码 Agent 里，解释、计划和风险提示可能是质量控制的一部分。过度压缩会让模型减少验证步骤、遗漏边界条件，或更早宣布任务完成。
因此系统提示词、工具描述和输出约束都应像代码一样管理：
- 使用版本控制；
- 每次变更绑定真实工作流评测；
- 同时观察质量、成本和延迟；
- 支持灰度发布与快速回滚；
- 保存可复现的 Agent 轨迹。
为什么平均分不足以发现问题
短题 benchmark 往往看不到长程 Agent 的退化。真正容易受这些变量影响的是跨文件修改、长时间调试、反复调用工具和中途恢复的任务。
更合适的回归集应该包含：
- 多文件、跨模块变更；
- 需要先调查再实施的任务；
- 工具失败后的恢复；
- 上下文压缩后的继续执行；
- 对最终文件、测试和约束的确定性验收。
除了成功率，还要记录重复调用次数、遗漏约束数、无效修改、单任务成本和完成前是否主动验证。
给团队的上线清单
- 明确展示当前模型和推理档位；
- 固定关键工作流的评测配置；
- 把计划、证据和检查点结构化保存；
- 对提示词和工具描述做版本管理；
- 质量、延迟和成本分开观测；
- 保留一键回滚到上一稳定配置的能力。
结论
Agent 质量是模型、运行时和产品配置共同作用的结果。模型供应商没有更换权重，不代表用户体验不会发生明显变化。想让长程 Agent 稳定，团队必须把默认参数、上下文策略和提示词都纳入正式的软件质量体系。
参考资料与延伸阅读
文中的日期、影响范围和约 3% 评测变化均来自 Anthropic 官方复盘；它们不代表第三方独立评测结论。资料核验日期：2026-08-23。