Claude 支持在对话中切换推理投入

Claude API 新增一项 Beta 能力：开发者可以在同一段对话里调整 effort，让简单问答和复杂分析采用不同的资源投入。调整通过消息序列完成，无需修改顶层配置，原文称提示缓存仍可命中。

对做 AI 应用的程序员来说，它的价值是让资源配置跟着任务变化。不过，effort 不只是控制回答长短，设置也不会立即作用于所有内容。接入前，需要先弄清它影响什么，以及从哪一条消息开始生效。

effort 调的是投入，不只是回答长度

据 IT之家 11 月 12 日报道，Anthropic 为 Claude API 增加了在消息中调整 effort 的 Beta 功能。这里的 effort，可以理解为模型处理任务时愿意投入多少功夫。

它影响的不只有最终输出多少字，还包括思考、调用工具和组织回答等环节的资源投入。开发者借此在回答充分程度、响应速度和使用成本之间做取舍。

因此，不能把 effort 当成一个「详细回答」开关。要求模型多写几段，约束的是输出形式；调整 effort，涉及的是完成任务过程中的投入。回答更长，也不能直接证明模型投入更多或结果更可靠。

原文没有列出可选等级、默认值、支持的模型，也没有提供不同等级下的耗时、费用和质量对比。我们能确认的是配置机制，具体收益还缺少数据。

中途调整，要看下一条用户消息的位置

这项能力的操作入口是消息序列：插入一条内容为空的 system 消息，再通过新的 output_config.effort 设置目标等级。整个过程无需改动顶层配置，原文称提示缓存仍可命中。

这适合一段对话里任务难度发生变化的情况。例如，前半段只是简单问答，后半段转向复杂分析，就可以在切换处设置新的 effort，而不必让整段对话始终沿用相同设置。

但生效边界需要记牢：

新的 effort 从下一条带有新输入的用户消息起，作用于后续回答。

它不会修改已经生成的内容。对接入方来说，插入调整消息和出现下一次用户输入，是两个需要一起考虑的时点。若只记录「配置已改变」，却没有核对消息顺序，就可能误判某次回答究竟使用了哪套设置。

原文没有给出完整请求示例，因此还不能据此确定所有字段的嵌套方式，也不适合直接拼出一份号称可运行的请求代码。

我的判断

我认可按任务调整 effort 的方向。同一段对话里的工作量会变化，允许在任务切换处改变投入，比始终固定一套设置更灵活。通过消息调整、无需修改顶层配置，也给应用提供了更明确的控制入口。

但「可以调节」和「调节后更划算」是两件事。原文没有给出实测，更没有与固定 effort 的做法进行对照。节省多少成本、响应能快多少、复杂分析是否更准确，目前都不能下结论。

缓存也一样。原文说「仍可命中」，不等于每次调整都必然命中，更没有承诺固定比例的费用节省。

如果应用始终处理同一种任务，固定设置可能更容易管理；如果经常从闲聊切换到复杂分析，这个功能才更有试验价值。至于如何自动识别切换时机，原文没有提供方案，需要应用自己决定。

能拿来做什么

• 在已有 Claude API 对话应用中，先找出明确的任务切换点，例如从简单问答进入复杂分析，再评估是否需要调整 effort。
• 如果由 Node 服务端组装消息序列，把调整消息与下一条用户输入的顺序一起检查，避免把设置后的首次回答归属判断错。
• 用同一批任务比较固定 effort 和中途调整两种做法，记录回答质量、响应时间、实际费用及缓存命中情况，再决定是否推广。