企业Agent最昂贵的失败，往往不是答错一句话，而是跑了半小时、调用多个系统、等待一次人工批准后突然中断，重启时又从第一步开始。Microsoft Agent Framework在8月21日发布Python 1.15.0正式版，把检查点、重试恢复、审批状态和遥测契约集中补强。它没有推出新模型，却直指Agent从演示走向生产时最难绕开的故障语义。

这次升级处理的是“失败后怎么办”

1.15.0为Foundry托管Agent加入可恢复后台任务与可引导会话。官方合并记录给出的验证场景很直接：让本地工作流强制崩溃，再从检查点恢复；运行中的会话也可以接受新的引导信息。框架同时增加MiddlewareFailure，把中间件故障提升为一等致命信号，避免异常被吞掉后继续产生看似完整、实际污染的结果。

这改变了交付团队的设计顺序。过去的原型通常先连模型和工具，再补异常处理；生产系统则应先定义可重试错误、不可重试错误、检查点位置和补偿动作。例如合同审查Agent完成文档提取后写入检查点，调用风控系统超时时只重跑该段；如果授权失效，则立即停止并交给人工，而不是把整条链路重新执行一遍。

检查点与审批，终于被放进同一条状态链

新版本加入进程级工作流检查点类型注册表，并登记Cosmos检查点状态类型；同时持久化人工审批状态。对跨小时、跨班次甚至跨天任务而言，这比单纯“保存聊天记录”更重要：系统不仅要记住说过什么，还要记住执行到哪一步、哪项批准已经给出、哪些工具调用不能重复。

但检查点本身也是新的信任边界。官方文档要求把存储后端视为私有可信基础设施，限制可反序列化类型，并对Cosmos DB优先采用托管身份和RBAC。FDE在部署时还应测试进程重启、跨节点恢复、重复消息、过期批准和幂等写入；“能够恢复”不等于“恢复后不会重复扣款、发信或改数据”。

可观测性契约变清楚，迁移成本也真实存在

1.15.0把OpenTelemetry生成式AI语义约定收敛为稳定与实验两种模式，并增加消息事件开关。价值在于监控平台终于能预期字段和事件格式，代价是依赖旧属性的查询、告警与成本看板可能失效。版本还修复了扇入节点追踪上下文丢失、历史消息超线性增长、远程MCP工具重名遮蔽、流式工具调用重复等问题，这些都属于上线后才会放大的工程毛刺。

升级不能只看单元测试通过。团队需要回放真实链路，核对跨度、消息事件、工具ID和审批记录是否连续，并把旧版与新版的任务完成率、P95时延、重复调用率、人工接管率逐项对照。尤其是遥测字段迁移，应先并行观察再切换告警，避免Agent已经失败而监控系统因为字段改名保持沉默。

编辑判断：可靠性正在成为Agent框架的分水岭

这次发布还加入A2UI可选支持、流式工具调用索引，以及更完整的自建Agent Harness样例，但它最值得企业关注的仍是恢复链。一个Agent会调用十个工具不难，难的是第七步失败后知道该从哪里继续、哪些动作不可重放、谁批准过什么，以及如何向审计人员解释整条路径。

限制同样明确：发布说明没有给出具名客户、生产可用率、延迟开销或ROI数据，样例也不能替代业务压力测试。ATYUN认为，1.15.0更像一套值得验证的生产地基，而不是“开箱即用”的可靠性承诺。企业试点的验收标准应从“能完成一次”升级为“故障注入后仍能正确恢复，并且全过程可追踪、可撤回、可计费”。还应记录每次恢复丢失的步骤数、重复副作用数量和人工处置时长，避免只用最终成功率掩盖恢复成本。这才是Agent真正进入核心流程的门槛。