Sonnet 5.5推理档位怎么选？medium、high和max的取舍

把 Sonnet 5.5 的 effort 当作需要评估的参数，不要当作质量保证。Anthropic 建议，需求明确的 Agent 编程和多步工具任务可从 medium 开始，更难或更长的工作再试 high；对延迟敏感的聊天建议 medium 或 low。原生 API 默认值仍是 high，Claude Code 则有自己的默认设置。

这些建议来自 2026 年 9 月 29 日核对的 Sonnet 5.5行为文档。本文介绍怎样测试取舍，不声称 Ofox 对所有 effort 档位做过基准实测。

先看任务，再选起点

最后一行是评估建议，不是官方保证 xhigh 或 max 可以修好问题。缺少需求、没有所需工具或指令互相矛盾的任务，任何档位都可能做不出来。

模型页面规定 API 默认 high，Claude Code配置文档则将该客户端的 Sonnet 5.5 默认值列为 medium。比较前先记录入口，否则两次都写“默认Sonnet”的运行，实际可能不是同一设置。

为什么不建议一律开max

Artificial Analysis发布评测发现 max 档输出 token 消耗很高，与部分替代配置相比成本取舍不利。同一报告也展示了较强的基准能力。这两点可以同时成立：模型可能通过花更多 token 获得更好的结果。

该报告测试了存在结构化输出问题的预发布部署，并说明相关项目将重跑。其基准费用不是你修 Bug 的报价，也不证明每次 max 都浪费。它更适合作为同时收集费用和质量的理由。

更高 effort 也可能改变行为。多探索一些方向，如果能验证相关解释，就有价值；如果扩大了修改范围或研究无关事项，就会产生负担。因此验收标准不仅要包含测试通过，还应包含范围约束。

设计一组小型档位对照

准备有代表性的任务，并写好预期输出或验收检查。固定模型版本、工具、输入和仓库初始状态。先跑基线，再在同样任务上测试高一档或低一档。如果不想让前一次答案影响后一次，应使用独立会话。

至少记录：

任务 | 请求的effort | 生效设置 | 是否验收通过 | 尝试次数
耗时秒数 | 输入token | 缓存分类 | 输出token
工具费用 | 总费用 | 范围外改动 | 审核备注

区分首次结果和重试后结果。设置时间或 token 上限时，明确标记被上限中断的运行，不要当成普通完整回答。保留失败样本；只展示成功案例的表格，无法证明哪个配置最可靠。

可以在看结果之前定一条规则：只有更高档位改善了足够重要的指标，值得增加费用或等待时间，才保留它。例如某团队更在意减少错误补丁，聊天产品可能更在意延迟。不要照搬别人基准里的统一阈值。

设置effort时避免生成无效请求

原生 API 的 adaptive-thinking 请求可以这样写：

{
  "model": "claude-sonnet-5-5",
  "max_tokens": 2048,
  "thinking": {"type": "adaptive"},
  "output_config": {"effort": "high"},
  "messages": [{"role": "user", "content": "List the acceptance checks for a CSV parser fix."}]
}

这是依据文档整理的请求体，不是真实 API 测试。max_tokens 限制思考与回答文本的总量；即使思考文本被省略，思考 token 仍按输出计费。它不是指定思考用量，也不是包含一切费用的美元预算。认证、版本请求头和响应处理仍需分别实现。

如果用 between_tools 关闭执行前思考，effort 应保持 high 或以下；该模式不支持 xhigh 和 max，对话中途修改档位也有约束。复制旧版 disabled 或手动预算配置前，先看迁移清单。

Claude Code 启动可用 --effort medium，交互时可用 /effort 选择受支持档位。托管设置可能限制实际生效值。没有检查客户端与账户行为之前，不能把请求值当作生效值。

分清 effort、输出上限和工具权限

这三个控制项解决不同问题：effort 影响模型投入的推理程度；max_tokens 限制包含 thinking 在内的响应 token 预算；工具权限决定应用能执行哪些动作。提高 effort 不能凭空增加文件工具，也不能授权访问私有仓库；提高输出上限同样无法解决相互矛盾的任务要求。

以“修复 CSV 总额并运行测试”为例：模型已有源码与可执行测试时，effort 才是有意义的比较变量。如果它只有错误截图、看不到源码，应先补输入。如果正确补丁已有，但测试命令被禁止，应先寻找获批验证路径。把这三种情况都归成“需要 max”，会掩盖真正原因。

调整档位前，先按结果选择处理方式：

这是编辑提出的诊断框架，不是某个档位一定能通过任务的测量结论。改善任务说明时应保留原始失败记录，否则新提示词的收益可能被错误归因于新 effort。

完成任务成本的具体算例

假设两种配置处理同样十个小任务。以下数字仅为合成教学数据，不是 Sonnet 实测。medium 的全部尝试花费 $0.40，八个任务验收通过；high 花费 $0.60，九个通过。每个通过任务的成本分别为 $0.40 ÷ 8 = $0.05，以及 $0.60 ÷ 9 ≈ $0.0667。

此例中，high 的单位通过任务成本高约三分之一，但多完成一个任务。是否值得取决于完成任务的价值与失败后的处理方式，不能直接概括成 medium“准确率低 25%”或 high“永远更好”。样本很小且是合成的，不能据此证明生产可靠性。

再看 medium 优先策略：先用 medium 跑全部十个，仅把失败的两个交给 high。若这两次升级共花 $0.12，且都成功，总支出是 $0.52，十个任务通过，单位成本 $0.052。这个算式说明升级策略为什么可能有价值，并不预测 high 会修好所有 medium 失败。如果升级后两个仍失败，支出同样升至 $0.52，通过数却仍是八，单位成本变为 $0.065。

所有尝试都应计入支出，包括中止和失败。工具费用与人工审核时间若计量单位不同，应单独记录。没有任何任务通过时，比例应为“未定义”，不能写 $0.00。订阅账户没有可信的逐任务账单时，应分别报告观察到的用量与延迟，不要套 API 价表捏造美元费用。

让另一位审核者能复查比较过程

查看模型输出前先选定任务。代码任务应包含描述、起始 commit、允许修改的文件、测试命令和明确成功标准。文档任务保留同一来源包及主张对照来源的要求。除非产品设计本来就是修复流水线，否则不能让一档解决原题，另一档先看到前一档的答案。

每个档位都从相同状态开启新会话。条件允许时交替执行顺序，因为临时服务状态或本地缓存预热可能偏向总是第二个运行的配置。记录缓存状态，不要假定它不变。同一任务重复多次属于同题重复试验，不能当作多个独立任务。

每条记录应含任务 ID、精确模型与 endpoint、请求 effort、可观察时的实际 effort、结束原因、耗时、用量分类、重试、测试结果和越界改动。保留足以审核的响应或 diff。如果 API 不暴露实际设置，填写“无法独立观察”；不要把请求值抄过去就标成已验证。

比较配对任务的结果，不只比较平均数。如果 medium 与 high 通过的恰好是相同任务，就没有在这组数据上证明 high 提高了完成率。如果 high 修好重要失败却拖慢所有简单任务，可以把该失败类型送入 high，而非自动提高所有请求档位。如果差异只有一个不确定的主观评分，应扩大评估或明确标准，再谈胜负。

运行前就规定升级与停止条件

一个可选策略是：边界明确的代码任务先用 medium，确认属于推理失败后，在完整输入不变的情况下用 high 重试一次，第二次仍无效则停止并交给审核。这是策略示例，不是 Anthropic 默认设置。先规定哪些错误能触发升级；权限缺失、参数不支持和输入缺失不应消耗 effort 升级重试。

只有额外推理确实可能解决已观察失败，且延迟与费用允许时，才试 xhigh 或 max。这些档位应使用 adaptive thinking。between_tools 文档支持的最高档是 high，而且同一会话内改变 effort 受到限制。比较模式时新建受控试验，不能拼出不合法的混合会话。

任务级停止条件应覆盖多次尝试。单次响应 token 上限约束不了可连续多次调用的 Agent。达到约定尝试数、时间或应用预算时停止，保留部分产物并标记“达到上限”。不能仅因最后一句语气确定，就把受限中止记成正常成功。

最后的建议应写明范围，例如“对这组已验证的 CSV 修复，以 medium 为基线，列出的失败再评估 high”。这样的规则比一个通用“最佳 effort”标签更有用，也便于模型版本或任务构成变化后复查。

什么时候应考虑换模型

任务一直很难时，可以比较提高 Sonnet effort 和换模型两条路线。Sonnet与Opus讨论 Claude 内部选择，Sonnet与Sol讨论跨厂商测试。改变配置时，任务与验收测试保持一致。

选定基线后，记录选择原因，以及哪些失败允许升级处理，下一次模型更新就更容易评估。Sonnet 5.5 相对 Sonnet 5 重新校准过 effort 档位，沿用旧名称却不测试，不能证明行为等价。