模型变差了，不一定是权重变了

Tue, 05 May 2026 10:50:22 +0800

最近 Anthropic、OpenAI、智谱都发布了一篇各自线上问题的复盘：

Anthropic 解释 Claude Code 近期质量下降、容易遗忘上下文的问题
OpenAI 分析 GPT 系列模型为什么会突然输出“哥布林”这类奇怪表达
智谱复盘 GLM-5 在复杂 Coding Agent 场景里出现乱码、复读、生僻字的问题

联想到去年 Anthropic 和 OpenAI 也有过类似的用户侧体验降级复盘，趁着假期，我把几篇文章整体拿出来读了一遍。

读完之后最大的感受是：用户说“模型变差了”，通常是在描述一种真实体感，但它不是一个足够精确的工程归因。这个问题可能发生在模型层，也可能发生在推理系统层，还可能发生在 Agent 产品的 harness 层。

异常的表现

用户侧感受到的“模型表现下降”，其实不只有一种形式。

有些表现得像能力下降。比如 Claude Code 更容易遗忘上下文、推理接不上，用户直观感受就是“降智了”。

有些是风格和人格的问题。比如 GPT-4o 某个版本变得过度谄媚，太容易顺着用户说。它不一定是不聪明，而是边界感和人格稳定性变差了。

有些是表达习惯异常。比如 GPT 系列模型突然更容易输出“哥布林”这类突兀的词。单次看可能只是一个小怪癖，但当它跨模型版本、跨场景持续出现时，就变成了质量问题。

还有一些是更明显的输出异常。智谱在复盘里提到，GLM-5 在复杂 Coding Agent 任务中出现过乱码、复读、生僻字。这类问题在用户侧会非常明显，但在线下标准推理环境里不一定容易复现。

这些问题不像传统软件 bug 那样直接 crash，也不一定会马上体现在 benchmark 榜单上。真实用户在连续使用过程中，会先冷不丁感受到“不对劲”。

问题可能发生在哪一层

不同于传统软件，大模型和 Agent 产品表现不如预期，可能是系统中任何一个环节出问题导致的。粗略看，可以分成三层：模型层、推理系统层、Agent 产品 harness 层。

模型层

OpenAI 的 GPT-4o 过度谄媚，以及 GPT 系列模型输出“哥布林”概率升高，都更接近模型层问题。

再往底层追溯，可以看到训练数据和奖励信号的影响。过度谄媚的表达、带有奇怪口癖的表达，在训练过程中更容易被某些奖励模型判定为好的输出，最后就会把模型推向不符合预期的行为。

这里的问题不是“模型不够聪明”，而是模型被训练成了不合适的性格和表达习惯。

这对 Agent 产品也有提醒：模型质量不只是智力，还包括诚实性、边界感、表达风格和长期稳定性。

推理系统层

去年 Claude 有一段时间质量波动明显，当时 Anthropic 官方多次表态，不会因为需求高峰、时间或服务器负载主动降低模型质量。最终复盘里，他们把问题定位到推理链路中的底层问题。

智谱的 Scaling Pain：超大规模 Coding Agent 推理实践把类似问题讲得更具体：GLM-5 在标准推理环境下表现正常，但在高并发、长上下文的 Coding Agent 场景下，会偶发乱码、复读、生僻字。最后定位到的不是模型本身，而是大规模推理系统里的底层竞态、状态管理、KV Cache 回收复用时序等问题。

这说明推理系统不是一根透明管道。

到了 Coding Agent 这种长上下文、多轮工具调用、高并发的场景，推理系统不只是性能问题，也会直接变成质量问题。权重没变，不代表服务出来的模型体验不会变。

Agent 产品 harness 层

Claude Code 这次复盘最有启发的是，它的问题并不在 API 或推理层，而是在 Claude Code、Claude Agent SDK、Claude Cowork 这些产品层。

其中有几个变化很典型：

某个版本降低了默认的思考等级，本意是平衡智能水平和响应延迟，但最终导致输出质量下降
某些 bug 导致推理历史被错误清理，后续轮次接不上前面的思考，用户感受到的是 Claude Code 更容易遗忘
一段为了防止模型输出太冗长的系统提示词，反而导致编码质量下降

这里的关键点是：harness 不是“提示词”这么简单。它包含系统提示词、工具定义、上下文组织、推理历史保留、默认配置、工具调用策略和交互结构。

同一个模型，在不同 harness 里可能表现出完全不同的能力。

为什么会漏到线上

这几篇复盘还有一个共同点：即使 LLM 公司内部已经有不少发布前准出机制，仍然会有一些导致用户负反馈的问题漏到线上。

原因之一是，这类问题不一定像传统软件 bug 那样明确。

用户反馈常常是“没以前好用”“有点怪”“太迎合”“上下文接不上”。这些反馈很真实，但对工程排查来说又很模糊。它们不一定能被一条 prompt 稳定复现，也不一定能被现有量化指标识别。

另一个原因是，很多问题只在真实线上环境里出现。

智谱那篇里提到，部分异常在标准推理环境下不存在，只有在高并发、长上下文、Coding Agent 场景下才会触发。也就是说，离线评测稳定，不代表线上长任务稳定；单轮 prompt 正常，不代表多轮 Agent 轨迹正常。

所以用户反馈和内部指标不能互相替代。

用户反馈更贴近真实体验，很多“模型变差了”的问题往往是用户先感知到。但用户反馈也会比较稀疏、有噪音，并且样本有偏。

内部指标更稳定、覆盖面更广，也更适合做版本对比和持续监控。但内部指标不一定能完整代表真实用户体验。

更好的方式不是二选一，而是把用户反馈当成问题发现信号，再把高质量反馈沉淀成内部评测、回归用例和上线准出标准。

对 Agent 开发者的启发

对 Agent 产品开发者来说，我觉得有三点比较重要。

第一，Agent 产品交付的是端到端体验，不是一次模型调用。

模型本身的能力和品性很重要，但 Agent harness 如何让模型在具体产品场景里稳定发挥，同样重要。开发者首先要定义清楚产品应该表现出什么能力、边界和风格，再结合对模型的手感，通过评测、消融实验、上下文组织、工具设计和默认配置，调配出一个合适的 Agent 环境。

这个过程本身就是 Agent 开发者的差异化价值。

第二，Agent 评测应该覆盖完整任务轨迹，而不只是单轮回答。

很多问题不会在单条 prompt 里出现，而是在长上下文、多轮工具调用、复杂任务链路、真实负载下才暴露。对 Coding Agent 来说，单轮回答质量只是局部信号，真正应该关注的是一整条任务轨迹能不能稳定完成。

这意味着评测和观测都要更接近真实产品形态：记录模型版本、harness 配置、工具调用轨迹、上下文状态、失败步骤和用户反馈。

第三，要建立更短的用户反馈到问题修复闭环。

用户说“模型变笨了”通常是一个模糊症状，不能直接复现。在保证用户隐私的前提下，Agent 产品需要保留最小必要的调试信息，把用户反馈转化成可以分析的 bad case。

对于能定位到产品代码或 harness 配置的问题，可以让 Coding Agent 参与问题复现、原因分析、代码修复和测试验证，帮助缩短从用户反馈到修复上线的链路。

我自己的感受是：到了 Coding Agent 场景，用户体验已经不是单纯的“模型能力”问题，而是模型、推理系统、Agent harness 和反馈闭环一起构成的端到端能力。

GLM on liaohch3