一次Agent运行还没选好模型，超时预算就可能已经用完。PydanticAI 2.60把首次模型选择也纳入运行计时，这个看似很小的顺序变化，会改变慢路由的失败表现；对于少数把选择过程本身写成持久步骤的任务，还需要检查升级前留下的执行历史，而不只是看新任务能不能启动。

快速看点：模型选择上下文现在可读取用量限制、截止时间及运行标识；首次选择不再处于超时计时之外；MCP能力的默认标识也从包含路径尾段改为主机名。版本变更记录日期为10月22日，发行页于23日发布。这不是一款新模型，而是企业Agent运行边界的调整。

先建立预算，再让路由器做决定

应用常常在真正调用模型之前，先根据任务类型、可用服务或策略选一个模型。这个选择器可能读取配置，也可能等待外部系统。2.60把deadline、usage_limits、run_id和conversation_id提前放入ModelSelectionContext，让首次选择就能看到本次运行的约束，而不是进入模型调用后才拿到。

需要区分“能读到限制”和“自动替你优化”。框架提供上下文，并不等于默认实现了一套低成本模型调度器。企业仍要决定何时用哪个模型、剩余时间不足时是否停止，以及怎样记录选择依据。把这些规则写成可检查的应用策略，比只在提示词里要求“快一点、便宜一点”更容易复现。

实际影响是，首次选择耗费的时间现在也计入超时。旧版本中一个选择很慢、随后很快完成的任务，升级后可能抛出RunTimedOut。它不一定意味着模型突然变慢，而可能是原来没有计入的等待终于进入预算。排查时应分别记录选择耗时与模型耗时，避免把路由问题全算给推理服务。

历史任务的顺序，比新任务的成功更难验证

持久执行会保存步骤，恢复时需要与原来的历史对应。上游明确描述了一种窄范围兼容问题：首次选择器内部执行了DBOS持久步骤，同时运行设置了超时，旧任务恢复到新版本时，run_start_time步骤的位置变化可能触发DBOSUnexpectedStepError。这不是所有DBOS应用都会遇到的故障。

不包含内部DBOS步骤的常见选择器，不属于上述同一种顺序变化；没有超时的相关任务，还需注意默认运行标识可能改变。实施团队应先识别哪些工作流真正符合条件，再安排受影响的在途任务完成或取消。显式指定run_id能够稳定标识，但不能修复带超时任务的步骤顺序不匹配。

这也解释了为什么“启动一个新任务成功”不是充分的升级验收。新任务从新顺序开始，可能运行正常；旧任务则要读过去的历史。一个小规模回归可以分别覆盖新启动、执行中断后恢复、超时退出三条路径，并保留旧版本环境作为排查对照。这里是实施建议，不是本文已跑出的测试结果。

MCP标识不再带路径，同域服务需重新区分

另一个容易被忽视的变化发生在MCP能力的默认ID。此前自动生成的标识包含主机名及路径尾段；新默认值只保留主机名。原因是路径可能携带敏感内容，而这个ID会进入持久操作名称或观测记录。少带一段路径，降低了把路径内容扩散到其他系统的风险，但没有自动解决全部凭据管理问题。

代价是，同一主机下的不同MCP服务可能得到相同默认ID，需要明确设置不同且不含秘密的标识，否则可能在构建或运行开始时遇到UserError。团队不能只检查服务器是否连通，还要检查活动、步骤或任务名称是否与旧执行记录一致，尤其是之前依赖自动标识恢复的流程。

若为了兼容历史而保留旧ID，前提必须是它不包含凭据或其他秘密；不能为了恢复成功，又把敏感路径复制回日志和步骤名。更稳妥的交付做法，是建立服务端点到稳定安全标识的映射，并把映射变更纳入版本评审。身份名称、连接地址和授权内容是三件事，不应因为一个字符串方便就混在一起。

小编判断：升级清单要写到恢复路径

2.60的价值，不只是给选择器增加几个字段，而是把“开始计时”“决定模型”“标识外部能力”之间的隐含约定摆到了台面。对企业实施团队，优先检查两类地方：首次选择有没有慢依赖；同一域名下是否接了多个MCP服务。它们往往不在演示主路径上，却可能决定故障时能不能解释清楚。

目前没有证据表明所有持久框架都会出现同样问题，也没有本轮独立延迟或成本对照数据。不能把上游列出的特定DBOS兼容边界扩大成全行业故障。更实用的判断是：让新任务、旧任务恢复和失败退出一起进入升级验收，明确哪些变更能靠配置处理，哪些必须先处理在途执行，再决定上线节奏。