指南/Claude 降智排查
Claude 看起来变笨：先按症状排查，再判断模型有没有变
「Claude 降智」描述的是使用感受，不能直接定位故障。回答变短、长对话失忆、工具调用失败和任务通过率下降，分别指向不同的检查项。先固定请求和评分标准，再沿着症状排查客户端、模型服务与中转路由。
先把「变笨」改写成可观察症状
同一句「最近不如以前」，可能对应下面几类记录。排查入口由症状决定。
| 症状 | 优先检查 | 先保存什么 |
|---|---|---|
| 长对话漏掉早先约束 | 完整出站上下文、客户端压缩或截断、输入用量 | messages、system、tools、模型 ID、Usage |
| 回答突然变短或半句结束 | 输出上限、stop_reason、思考配置、流式连接 | 原始响应、结束事件、max_tokens |
| 工具调用或结构化输出失效 | 工具 Schema、参数透传、兼容接口与 SDK 版本 | 最终出站 JSON、内容块、错误对象 |
| 只在高峰时段变慢或失败 | 429、529、超时、重试和区域路由 | HTTP 状态、响应头、请求 ID、每次尝试 |
| 固定任务的通过率持续下降 | prompt 版本、模型 ID、采样参数、官方同期表现 | 测试集版本、评分结果、样本数与时间 |
表中几类问题可以同时出现。例如一次 529 触发客户端重试，后一次请求可能走到中转站的备用路由；调用方最终只看到成功响应，延迟和输出都变了。没有每次尝试的记录，就容易把服务波动写成模型能力变化。
单次问答不能鉴别模型
直接问「你是什么模型」只能得到一段生成文本。系统提示、中转层注入的说明和提问方式都能影响答案，模型自报无法证明运行时身份。
拿一道难题测试也有同样限制。生成结果受采样影响，一道题答对或答错没有稳定的错误率基线。Anthropic 的评测指南要求先定义具体、可衡量的成功标准，再用测试集比较结果；代码测试、精确匹配或明确评分规则都比「看起来聪明」更容易复查。
适合排查的任务应满足两个条件：输入可以版本化，结果可以重复评分。例如代码是否通过固定测试、JSON 是否符合 Schema、抽取结果是否包含指定字段。开放式写作可以保留人工评分，但需要固定评分说明，并同时报告样本数。
固定请求，再比较结果
每次测试至少保存下面这些条件：
- 端点、协议、模型完整 ID、SDK 版本和发起区域。
- 最终发出的 system、messages、tools、图片或文件描述，以及生成参数。
- 原始响应内容块、Usage、
stop_reason、响应头、请求 ID 和流式结束状态。 - 测试集版本、每题评分、总样本数与准确时间。
给排序后的出站 JSON 计算哈希，可以快速发现两次请求是否相同。聊天界面里的用户消息没有变化，但工具说明、历史消息或系统提示已经变化时，应先处理客户端差异。
测试要重复运行并报告分布。输出长度、首 Token 延迟和单题得分都可能波动；中位数、通过率或终止原因构成比一条样本更适合比较。样本量没有脱离任务难度和差异大小的通用答案，记录中应明确写出 n，不要只给百分比。
长对话失忆：先查上下文
模型没有复述早先内容，可能是客户端没有把那段内容继续发送，也可能是客户端做了摘要、清理工具结果或截断。先看最终出站请求，再看输入 Usage；只检查界面展示的对话记录不够。
Claude 的上下文处理还受模型版本与思考配置影响。Anthropic 的上下文窗口文档说明，不同模型具有各自的窗口限制；当前型号到达窗口边界时，可能以 model_context_window_exceeded 结束。Thinking 文档还区分当前轮与历史 thinking 块如何占用窗口。模型、配置或客户端历史策略变了，多轮表现也会变。
若出站请求已经缺少早先消息，可以确认问题发生在客户端或其前置代理。出站请求完整而中转返回的输入用量持续偏低，只能说明请求处理或计量存在差异；要确认中转层删除了哪一段，还需要它的上游请求日志。更完整的检查顺序见上下文被截断怎么判断。
回答变短：看终止原因和参数
回答长度受任务、输出上限、停止序列和思考投入影响。Anthropic 的 stop_reason 文档区分自然结束、达到 max_tokens、触发停止序列、工具调用和上下文窗口耗尽。半句结束并伴随 max_tokens，应先调整输出预算或上下文；end_turn 则表示服务报告模型自然结束，仍需结合任务与参数继续排查。
effort 是行为控制，不保证固定 Token 数。Anthropic 的 Effort 文档明确说明，它会影响响应投入，但不是严格预算。Thinking 生成的 Token 还会计入输出费用与 max_tokens。兼容接口可能忽略、换算或限制相关字段，因此要保存最终出站请求和原始内容块，不能从可见答案长度反推参数是否生效。各接口差异见AI API 参数为什么没有生效。
流式连接提前中断也会留下短答案。收到 HTTP 200 只代表响应已经开始，SSE 中途仍可能报错；客户端若只展示已收到的片段，会让网络故障看起来像模型主动收尾。此时应检查结束事件和流式响应完整性。
时好时坏：查错误、重试和采样
Anthropic 的错误文档将 429 定义为达到速率限制，529 表示服务暂时过载；官方 SDK 对部分连接错误、限流和 5xx 默认重试。高峰期的错误比例、重试次数或请求耗时增加，可以解释「偶尔变差」的一部分，但它们不会自动证明模型被降级。
每次响应都有 request-id。中转站若透传或提供自己的请求 ID，应把 ID 与客户端调用 ID 对应保存。一次用户操作经过几次尝试、每次走了哪个端点、哪一条最终展示给用户，必须能从日志还原。
错误率稳定、请求也没有重试时，再看采样因素。即使使用固定模型 ID，生成结果也不保证逐字一致。温度、工具可用性和任务输入中的微小变化都可能改变输出；开放式任务尤其容易把自然波动误记成能力下降。固定测试集的通过率持续偏移，比「连续两次回答不好」更值得进入模型与路由排查。
固定模型 ID 也要区分模型与服务
Anthropic 的模型 ID 与版本说明规定，每个正式模型 ID 对应固定模型版本；4.6 之前的部分短名称是指向日期快照的便利别名。4.6 及后续的无日期 ID 是固定版本，不是移动别名。
固定模型版本也没有冻结外围服务。官方文档列出的请求路由、安全分类器和采样逻辑仍可能更新，并可能带来小幅可观察差异。因此，模型 ID 不变与行为略有变化可以同时成立。若测试使用旧型号短别名，还要先查它当前解析到哪个日期快照。
中转站另外维护一层模型映射。它可以把公开名称映射到不同账号池、云区域或上游模型，也可以重新包装响应里的 model 字段。仅凭字段值不变，无法确认最终后端；仅凭行为偏移，也无法指出具体替换成哪个模型。
用官方同期对照缩小范围
客户端请求确认一致后，在相近时间把同一份测试集分别发送到官方端点与中转站。两边要使用相同协议和固定模型版本，评分规则也保持一致。
| 对照结果 | 优先排查 |
|---|---|
| 官方与中转同时下降 | 测试集变化、模型服务更新、共同的客户端配置 |
| 只有中转下降，且集中在特定账号或时段 | 中转请求改写、参数处理、路由与上游资源 |
| 任务得分稳定，只有延迟变差 | 网络、排队、限流与重试 |
| 任务得分下降，同时 Usage、终止原因或协议结构变化 | 上下文、参数、模型版本与路由的组合变化 |
只有中转持续偏离官方时，可以确认两条服务路径表现不同。模型指纹、服务方日志或可信上游记录，才能进一步支持模型身份判断；运营方是否故意换成低成本模型又是另一项结论。学术方法及误判边界见模型掉包的审计研究。
如果问题只发生在接入后的某些时间或流量分组，继续复用同一套测试条件，按准入测试之后的持续复查方法扩大时间覆盖。本文负责定位一次「变笨」可能发生在哪一层；持续监控负责回答变化从何时开始、影响多少请求。
LinkyMonitor 保存固定任务的请求版本、Usage、终止原因与结果变化，帮助定位 Claude 从何时、在哪类请求上开始偏离。