微软开发者周报：DirectX崩溃转储、Azure身份更新与Copilot Harness

微软开发者生态近期迎来多项更新：DirectX将GPU崩溃转储能力带入零售游戏，Azure SDK在身份认证上做出一系列调整，Microsoft Foundry则预览了托管的Copilot Harness，为复杂智能体提供执行环境。以下逐项拆解这些变化的实际意义。

DirectX：把主机级崩溃分析带给Windows游戏

长期困扰PC游戏开发者的一个问题是：GPU崩溃往往发生在玩家机器上，而开发者难以复现。DirectX通过Agility SDK 1.620和PIX 2.610.28改变了这一点——零售游戏现在可以生成.dxdmp崩溃转储文件。

当GPU崩溃发生时，DirectX会在Windows重置GPU之前捕获运行时状态、应用数据以及受支持的硬件驱动数据。工作室可以通过自己的崩溃上报管线取回.dxdmp文件，之后在PIX中分析，甚至可以在没有原始GPU或驱动的另一台机器上完成。

Studios can retrieve the .dxdmp file through their crash pipeline and analyze it later in PIX

这套机制还支持对挂起（hang）做记录，把工程师引向涉及的着色器和资源。你可能没注意到它区分了两种模式：默认的无额外开销模式面向日常零售游玩，更高细节的捕获模式则可在开发、QA或小范围追查罕见崩溃的玩家群体中开启。这种"默认轻量、按需加码"的设计，把类似主机的死后分析工作流带到了跨硬件厂商的Windows游戏上。

GPU崩溃与TDR机制：Windows上GPU崩溃通常由TDR（Timeout Detection and Recovery）触发——当GPU在约2秒内未响应，系统会重置显示驱动以避免整机死锁，但重置前应用状态往往丢失。.dxdmp转储正是在TDR重置发生前抓取的快照，因此包含了崩溃瞬间的GPU管线、命令缓冲与资源绑定信息。这与CPU侧的minidump思路类似，但针对的是显存与着色器状态。PIX作为微软的GPU调试工具，可离线加载.dxdmp重放事件流，这也是“换一台机器分析”得以成立的原因：分析不依赖原始硬件，只需转储文件与符号。

Azure SDK：围绕生产级身份做文章

Azure SDK的10月版本集中在.NET、Python和Java的身份认证变更，同时为Rust带来了首个稳定的Cosmos DB客户端库。

.NET侧的Azure Core新增了双向TLS、持有证明（proof-of-possession）以及托管身份与联合身份的流程，并改善了实例元数据服务不可用时默认Azure凭据的行为。Python和Java则开始支持Azure Arc启用服务器上的用户分配托管身份，并修复了超时与缓存凭据不正确的问题。

Python, and Java, plus the first stable Azure Cosmos DB client libraries for Rust

对Rust开发者来说，Cosmos DB 1.0提供了稳定的客户端、驱动和SDK宏。这些更新看似分散，主线其实一致：让身份在生产环境中更可预测。

The common thread is production identity. Fewer surprising credential chains

换句话说，减少意外的凭据链和失败情况，并在更多语言与混合环境中扩大托管身份的支持面。对于把服务部署到云上、又需要处理复杂身份拓扑的团队，这类改进的价值往往高于新功能本身。

持有证明与联合身份：持有证明（proof-of-possession）指客户端不仅出示令牌，还要证明自己持有对应私钥，从而降低令牌被窃取后重放的风险，常见实现为mTLS或DPoP。联合身份（federated identity）则允许工作负载用外部身份提供方（如Kubernetes服务账户令牌、GitHub OIDC）换取Azure访问令牌，免去长期客户端密钥。Azure Arc启用服务器指部署在本地或其他云、但通过Arc代理纳入Azure管理的机器；此前托管身份支持有限，Python/Java新增用户分配托管身份意味着这类混合环境也能使用无密钥凭据访问Azure资源。

Copilot Harness：托管智能体循环进入公开预览

第三条消息是Microsoft Copilot Harness在Foundry Agent Service中进入公开预览。它面向需要工具、文件、多步骤和长时间运行的任务，提供托管的智能体循环和沙箱。

开发者可以用声明式方式定义智能体，打包可复用的技能，在明确的认证与审批之下连接Foundry工具和MCP工具，把受限工作委派给内置子智能体，并让智能体定义与应用代码放在一起。

work in built-in sub-agents, and keep agent definitions with application code

官方给出的取舍很直接：当执行机制本身不是你的应用差异化所在时，用托管harness；当它是时，就把这套东西带进你自己的智能体运行时。这个判断标准对正在评估自建还是托管智能体基础设施的团队颇具参考价值。

智能体循环与MCP：所谓“智能体循环”是指模型反复执行“推理—调用工具—观察结果”直至任务完成的控制流，托管harness意味着这一循环的调度、重试、状态持久化与超时都由平台负责，开发者只声明目标与可用工具。**MCP（Model Context Protocol）**是连接模型与外部工具/数据源的开放协议，Foundry接入MCP工具后，智能体可复用已有MCP服务器而无需为每个工具写定制适配。沙箱则为执行代码与文件操作提供隔离边界，配合认证与审批控制，使长时间运行的任务不会越权访问。

这些更新放在一起看

三条消息分别指向游戏、云身份和智能体三个方向，但共同的信号是微软在把"生产可用"作为默认前提：崩溃诊断要能在真实玩家设备上默默运行，身份认证要在凭据链出错时给出可预期的行为，智能体执行要能在明确审批边界内跑长任务。对开发者而言，短期内最值得跟进的是DirectX转储的实际接入成本，以及Copilot Harness在自建运行时与托管方案之间的迁移代价。

另外，.NET Conf将于11月10日至13日举行，微软将在演播室进行直播，感兴趣的开发者可以关注。