我原以为自己很聪明。我写了一个辅助函数，为我们的 AI 流水线预留了上下文窗口中正好 30% 的空间作为思考预算（thinking budget）。它简洁、可预测，在 Opus 4.5 上运行得非常完美。然而，当我切换到 Opus 4.8 时，每一个请求都因为 400 错误而挂掉了。我精心设计的 Token 计算逻辑一夜之间变成了垃圾。

旧模式很简单。你设置一个 budget_tokens 值，模型就会限制其思考量以符合该上限。如果我交付 128K 的上下文，我的代码会为推理预留大约 38,000 个 Token，剩下的留给答案。这感觉很负责任，就像开车不超速一样。

那种模式已经过时了。像 Opus 4.7 和 4.8 这样的新版本采用了自适应思考（adaptive thinking）。你不再需要选择一个数字，而是传递一个“努力程度”旋钮（effort knob）。这听起来像是改个名字，但这两者截然不同。budget_tokens 为模型允许思考的量设定了一个硬上限；而 Effort 则从根本上控制模型如何思考和行动。一个是加油泵的计价器，另一个则是发动机的映射图（engine map）。

将 Effort 映射到实际工作

当控制方式发生变化时，我旧有的直觉失效了。我必须重新学习每个设置究竟能换取什么。我通过内部流量进行了测试，以找出每个 effort 级别在实践中的实际表现。

分类与路由（Classification and routing） 几乎应该始终使用 low effort。这些任务是快速决策。这是退款请求还是销售咨询？这条日志条目是否需要升级？你不需要一段长篇大论。低 effort 可以降低延迟，并将成本降至极低。

大多数应用流量，即摘要、改写、支持回复和内容提取等日常工作，适合 medium 到 high effort。这是平衡点。模型有足够的空间来解决真实的歧义，而不会在不需要长链条推理的任务上浪费 Token。

编程与智能体循环（Coding and agentic loops） 需要 xhigh effort。这是错误会产生连锁反应的地方。如果模型在工具调用循环的第一轮就写了一个错误的计划，它接下来的三步都会在修复错误上浪费时间。更糟的是，它可能会调用错误的工具，幻觉出参数，让用户面对一个损坏的工作流。前期更好的推理可以防止这种恶性循环。

关键任务 应该分配 max effort。不要对所有事情都使用它。请将其保留在那些“错误答案带来的代价超过任何 Token 账单”的时刻。财务对账、安全检查、架构决策和医疗分诊是合适的场景。如果一个错误意味着人类必须花费数小时来收拾残局，那就为额外的思考付费。

成本惊喜

这是打破我认知模型的部分。我原以为 max effort 总是会让成本飙升。在单次交互中确实如此，推理轨迹（reasoning trace）会更长。但在多步骤的智能体任务中，总账单往往反而下降了。

模型在第一次尝试时计划得更好。它进行的工具调用更少。它能阻止自己陷入死胡同。我观察到一个数据提取智能体，通常需要五轮往返，现在只需两轮就能完成，因为模型在开始时有足够的推理空间来正确解析 Schema。当你衡量成本时，请看任务的完成情况，而不是单次请求。每一步更大的思考预算可能意味着更少的总步骤。

如何在不破坏其他功能的情况下进行迁移

如果你的代码库中仍有 budget_tokens 在流转，以下是准确的迁移路径。不要跳过第三步和第五步。我跳过了，结果让我浪费了一个下午去调试。

在代码中搜索 budget_tokens。 每一个实例都需要删除。这个参数在新模型上已失效，并会触发 400 错误。

用自适应思考块替换预算对象。 使用 thinking: { type: "adaptive" }。

为每次调用添加带有明确 effort 级别的 output_config。 如果你的流量是混合的，不要将其留给全局默认值。你的轻量级分类端点不应该意外地继承与编程智能体相同的 effort 设置。请在调用处明确指定。

删除你的预算计算辅助函数。 我知道，它可能还有单元测试。我的也有。但它现在是累赘。平台不需要你的 Token 计算逻辑。模型会自行控制其节奏。

移除 temperature、top_p 和 top_k。 在 Opus 4.7 和 4.8 上，这些采样参数会抛出 400 错误。平台已在这一代模型中移除了它们。你以前的温度调节技巧在这里不再适用，保留它们会导致迁移过程在无声中失败。

单独测试每个模型。 Opus 4.5 和 4.8 是截然不同的东西。在一个模型上有效的配置不一定在另一个模型上有效。如果你支持多个版本，请分支你的逻辑，或者将它们视为独立的后端。

修复 UI 卡顿

如果处理不当，有一种流式传输行为会困扰你的用户。在新模型上，思维块（thinking blocks）会流式输出，但默认情况下文本内容为空。在你的界面中，这看起来像是一个漫长且尴尬的停顿，没有任何可见的进度。用户会认为应用挂起了。

要修复此问题，请传入 thinking: { type: "adaptive", display: "summarized" }。这样你就可以获得一个可见的进度指示器，而无需将原始思维流倾倒到聊天窗口中。你的前端保持响应，用户也能知道后台正在运行。

真正的教训

我基于一个供应商从未打算长期保留的参数构建了整个抽象层。我将他们的设置封装在自己的逻辑中，因为我以为自己比平台更了解其中的权衡。但我错了。Adaptive thinking 是更好的选择，因为模型可以真正决定何时需要深度推理，何时可以轻松应对。我的代码库现在更精简了，结果也更加精准。有时，正确的工程做法是删除那些“聪明”的代码，让平台发挥其作用。

如果你想阅读原始的迁移笔记，可以在这里找到。想要参与更多类似的实战讨论，请加入 Telegram 上的 GyaanSetu AI 社区。