一次模型调用迟迟不返回，整轮评测也跟着等；但给等待加上截止时间，并不等于后台工作已经停止。Pydantic AI 2.63的新变化，把这个区别直接摆到离线评测接口上：可以为每次任务尝试设置超时，让慢样本被记录为失败，其他样本继续。对于需要反复比较提示、模型和工具链的团队，这是一条实用却不能误读的可靠性边界。

快速看点：新参数task_timeout作用于单次任务尝试，默认仍不设限；重试会获得自己的计时窗口，等待退避不计入该窗口；同步任务超时后，其工作线程可能继续运行，不能把失败报告当作外部请求或业务动作已撤销的凭证。

先让慢样本退出等待，再继续评测

该能力列入2.63.0正式发布说明：版本标题日期为10月27日，GitHub发布记录为10月28日，相关改动27日合入。它针对Pydantic Evals的Dataset.evaluate与同步入口，不是给整个智能体平台添加统一总超时，也不是之前模型选择器超时功能的重复发布。

过去，任务内部若没有自行设置网络或模型客户端超时，一个卡住的调用会拖住评测结束。现在调用方可以给任务尝试明确秒数；超过期限会产生TimeoutError，失败样本进入报告。仍然正常完成的样本可以保留结果，不需要因为一个慢调用而把整批评测一并丢弃。

默认值是None，旧调用不会因为升级就突然开始计时。参数需要是大于零的有限数值；零、负数、无穷大、NaN及布尔值会被拒绝。这样的校验避免了“看起来配置了超时，实际却没有形成有效截止线”的情况，也提醒团队把参数作为可审阅配置保存。

阅读回归测试可以看到，慢样本与快样本被放在同一数据集，预期慢样本失败、快样本正常产出；任务自己抛出的TimeoutError则保留原有消息。本文核对了这些测试代码，并未执行测试，不能把上游断言改写成本站完成的可靠性实测。

每次重试都计时，不是整轮只有一个倒计时

超时控制放在单次尝试内部。假设团队自己配置每次30秒并允许最多三次尝试，不能因此承诺整个样本一定在30秒内结束：新的尝试会重新计时，重试之间的退避等待也在窗口之外。这个例子只解释参数关系，不是推荐所有业务使用同一组数值。

超时会像其他异常一样参与任务重试条件。如果希望某次超时后直接失败，就需要在条件里明确排除TimeoutError。是否重试还应看任务有没有副作用、供应商是否已经接收请求，以及重复执行是否安全，不能把评测框架允许重试理解为业务动作可以无条件重复。

生命周期钩子与评分器不受这个参数约束。任务已经返回后，如果评分器又调用一个缓慢的外部模型，仍需独立处理；初始化和清理也不是同一条期限。因此，团队应画清任务、评分器、客户端和整批作业的超时层级，避免只加一个参数就宣称整条评测链路不会再卡住。

同步线程还在，资源与副作用就未必结束

Python无法直接中断执行中的同步工作线程。设置超时后，评测可以按期报告该样本失败，但线程仍可能在后台跑到完成，最后的结果被丢弃。数据库写入、远端请求或文件操作若已发出，不会因为本地不再等待而自动回滚；判断这些动作是否成功，需要另行核对外部状态。

这还会影响资源控制。被放弃等待的线程不再占用评测端原先的并发位置，后续样本或重试可能与它重叠运行。只盯max_concurrency的配置值，不能推导所有仍在运行的同步工作都被同样限制。对有昂贵调用或写入动作的任务，团队需要额外观察真实并发和积压。

文档建议使用异步任务，或在被调用的HTTP、模型客户端设置自己的超时。异步取消也需要底层调用配合，不是强杀外部服务的保证。对有状态任务，还应设计幂等标识、查询结果与人工接管路径，让“本地超时但远端结果未知”成为可处理状态，而不是直接重复提交。

该变更针对离线数据集评测路径，在线评测不共享这段实现，不能一并承诺生效。版本还包含其他兼容性调整，本文只核准这一项具体增量，不代表所有升级迁移已审查。相关发布标签文档、接口签名、改动与测试均作内部核对，未安装新包或在生产环境升级。

实际验收时，至少应分别设计正常完成、异步慢调用、同步慢调用和带重试的样本，并检查失败报告、客户端状态与外部副作用。这里给出的是实施检查方向，不是已经跑过的测试结果；超时减少等待与生产成本、任务成功率是否改善，仍需企业自己建立基线验证。

小编判断

可靠的评测，不应只统计答对多少，也要说明失败发生在哪一层、等待何时结束，以及后台还有什么没有结束。Pydantic把任务尝试的期限显式化，是更清楚的工程契约；把它误读成取消一切、撤销一切，反而会让重试和资源管理产生新的盲区。