Pydantic AI 2.62.0：调整推理强度，细分模型错误

1. 在对话中调整推理强度

推理强度是决定模型生成答案时投入多少推理精力的设置。此次变更允许在对话进行中调整强度，而不必全程维持相同设置。OpenAI 通过 configuration_update 传递变更，Anthropic 则在每条消息中发送 output_config。两家提供商的请求格式不同，但用途都是在运行时调整设置。

变更后的设置会以 ModelSettingsDeltaPart 的形式保存到对话记录中。因此，推理强度的变更时间及内容会作为独立条目记入对话历史。处理现有对话记录的代码需要考虑这种新条目。发行说明也将这一变更列入兼容性注意事项。

通过 OpenAI 兼容提供商使用 Claude 的路径也得到了修改。对于不采用该提供商原生格式的推理信息，现在会将其放入用户消息中传递，涉及 OpenAIChatModel 和 OpenAIResponsesModel。也就是说，除了推理强度设置功能，推理信息本身的传递路径也经过了调整。

2. 按原因区分模型请求错误

新增的错误类别包括请求被拒绝时的 ModelRequestRejectedError，以及认证失败时的 ModelAuthenticationError。应用程序可以根据这些类别划分后续处理流程，而不再将所有失败归为同一种错误。

针对找不到模型的情况，新增了 ModelNotFoundError。例如，需要检查认证信息和需要检查模型名称时，可以据此给出不同提示。新分类的实际意义在于，为应用程序按失败原因设计应对方式提供了更多依据。

3. 同时考虑缓存保留与记录变更

调整推理强度的好处是，不必在每次对话中固定使用同一设置。OpenRouter 的修复通过 configuration_update 系统消息传递变更，以保留提示缓存，即复用重复输入的临时存储功能。在提高设置灵活性的同时保留缓存，是此次修复的具体效果。

相应地，开发者需要管理的内容也会增加。保存或读取对话记录的代码需要适配设置变更条目，直接构造请求的代码则需要适配各提供商的传递方式。灵活调整设置带来好处的同时，也增加了调整记录及请求处理逻辑的负担。

发行说明介绍了缓存保留修复和新增错误类别，但未提供成本、响应时间的测量值，也未提供按提供商响应划分的异常处理对照表。

4. 同时检查错误分类与重试流程

在 Azure 上，负责备用模型处理的 FallbackModel 现已能对分段接收响应期间出现的 too_many_requests 错误进行分类。这项修复针对的是不同错误返回路径下转交备用模型的流程。在 Azure 上使用此功能的开发者，除了新增错误类别，也值得一并检查这条路径。

后台工具，即独立于用户对话运行的工具，其步骤结束后发生的 ModelRetry 现在也会计入 max_retries 次数。这项修复解决了因重试请求发生时机不同而漏计次数的路径问题。

应用更新时，适合将设置变更写入对话历史的流程与接收并处理各类错误的流程分开检查。发行说明已将推理强度变更和新增错误类别都列为兼容性注意事项，因此最好在添加功能的同时，安排对现有记录及错误处理逻辑的检查。

2.62.0 提供了在对话中更改各提供商推理设置的路径，并为按原因处理模型失败增添了基础。