Azure Weekly：Python 获得一流 MCP 支持，Custom Agents 登上 Azure Boards

Source: Dev.to

请提供您希望翻译的正文内容，我将把它翻译成简体中文并保留原有的格式、Markdown 语法以及代码块和链接不变。

Source: …

Azure MCP Server：终于原生支持 Python

直到上周，使用 Azure Model Context Protocol (MCP) Server 需要 Node.js 或 .NET。对于构建 AI 代理的 Python 开发者——也就是 AI 生态系统的主体——这是一大障碍。现在，你可以直接通过 uvx 或 pip 从 PyPI 安装并运行 Azure MCP Server：

# 使用 uvx 按需运行（推荐）
uvx --from msmcp-azure azmcp server start

# 或者安装到你的项目中
pip install msmcp-azure

为什么重要

• MCP 正在成为 AI 代理与外部工具和服务交互的标准协议。
• GitHub Copilot SDK、Claude Desktop、VS Code、Visual Studio、IntelliJ 和 Eclipse 都已支持它。
• Python 开发者现在可以通过单一 MCP 服务器获得对 40 多个 Azure 服务的一流访问——无需 JavaScript 运行时。

该包支持与 Node.js 和 .NET 版本相同的服务器模式：

• namespace（默认）
• all
• single 工具模式
• 只读模式，以防止意外写入

你可以在 Docker 中运行它以用于 CI/CD 流水线，或直接在 IDE 中使用。

GitHub Copilot 自定义代理 + Azure Boards：AI DevOps 桥梁

Azure DevOps Sprint 269 推出了一个不声张却重要的功能：GitHub Copilot 自定义代理现已与 Azure Boards 集成。

工作原理

1. 在 GitHub 的仓库或组织层级创建自定义代理。
2. 该代理会自动出现在 Azure DevOps 中。
3. 当你从工作项创建拉取请求时，选择由哪个代理生成代码。
4. 代理编写代码，打开 PR，并将其链接回工作项。

这是一座首次真正连接 GitHub 原生 AI 能力与 Azure DevOps 工作跟踪的桥梁。使用 Azure Boards 进行项目管理但代码托管在 GitHub 上的企业，现在可以获得遵循其工作项结构的代理式代码生成。2,000 个仓库的连接上限提升（相较于之前的上限）意味着大型组织可以大规模使用此功能。

战略视角——微软并不是在与 GitHub 的 AI 功能竞争；它在将这些功能整合进 Azure DevOps。这是一种务实的认知，即 GitHub 是 AI 活动的中心，而 Azure DevOps 通过成为其之上的企业工作流层来生存。

新的 OpenAI 模型：GPT‑Realtime‑1.5 和 GPT‑Audio‑1.5

二月向 Azure 引入了两个新的 OpenAI 模型：

• GPT‑Realtime‑1.5 – 为低延迟、语音优先的应用进行优化。
• GPT‑Audio‑1.5 – 同样针对以语音为中心的使用场景进行调优。

相较于上一代的改进重点包括：

• 更好的指令遵循能力
• 扩展的多语言支持
• 增强的工具调用功能

两款模型均保持亚秒级延迟，非常适合 Copilot 语音模式、客服机器人或交互式语音助理。

通过现有的 Azure OpenAI 聊天完成 API 进行访问，因此如果您已经在使用 gpt‑4o 或类似模型，只需更改配置即可切换到这些模型。关键问题在于改进的工具调用和指令遵循是否值得额外的成本——但对于语音优先的应用来说，仅仅是延迟的提升可能已经足够。

Azure SDK 2026年2月发布：基础设施升级

February 2026 Azure SDK release 已发布多个重要的底层升级。

Azure.Core 1.51.0 for .NET

• 添加对 Microsoft.Extensions.Configuration 和 Microsoft.Extensions.DependencyInjection 的支持，使 Azure SDK 客户端能够无缝集成到 ASP.NET Core 的原生 DI 容器中。
• 在传输层引入 client‑certificate rotation 支持，使得在运行时可以动态更新证书而无需拆除 HTTP 管道，从而支持动态令牌绑定场景。这对于使用短期证书或出于合规要求进行轮换的工作负载至关重要。

corehttp 1.0.0b7 for Python

• 提供原生 OpenTelemetry tracing 支持。
• 新的 OpenTelemetryTracer 类封装了 OTel tracer 用于创建 span，SDK 客户端现在可以直接通过该类定义跟踪。

这些升级提升了 .NET 和 Python 开发者的使用体验，减少了样板代码，并改进了可观测性和安全性。

Azure 内容理解 1.0.0b1

这是 Azure 用于从文档、音频和视频中提取洞察的统一 API 的初始 Beta 版。如果您正在构建 多模态 AI 系统，这值得关注——内容理解是代码优先 AI 与真实业务数据之间的差距之一。

本周的信号

这些更新围绕一个主题聚集：Azure 正在迎合开发者的实际使用场景，而不是强迫他们使用 Azure‑特定的工作流。

• 对 MCP 的 Python 支持
• Azure Boards 中的 GitHub Copilot 代理
• Python SDK 中对 OpenTelemetry 的支持

这些都是迈向互操作性的举措。Azure 不再试图拥有整个技术栈；它正将自己定位为企业级的基础设施层，支持主要在 Python、GitHub 和开源工具中进行的 AI 开发。

对 Azure 来说，风险在于该策略只有在其 AI 能力和定价保持竞争力时才会奏效。如果 Claude Opus 4.6 on Azure Foundry 的运行速度明显更慢或成本更高于其他平台，那么再多的 MCP 集成也无济于事。

但就目前而言，Azure 正在做出正确的布局。通往智能化 DevOps 的道路 不是通过专有工具——而是通过协议、开放标准，让开发者使用他们已经熟悉的工具。

结论

Azure 本周表现强劲。

• Python MCP 支持 为最大的 AI 开发者社区消除摩擦。
• GitHub Copilot 在 Azure Boards 中的自定义代理 弥合工作跟踪与 AI 代码生成之间的鸿沟。
• SDK 更新 提供了生产 AI 系统真正需要的基础设施组件——DI 支持、证书轮换、OpenTelemetry 跟踪。

观察 Azure 如何应对下一波浪潮：如果代理工作流成为默认，Azure 的成功取决于成为运行这些代理的最佳平台，而不一定是构建它们的最佳平台。本周的表现表明他们已经理解了这一区别。

仪表化说明

使用 _instrumentation_config 类变量进行配置。这对于生产 AI 系统的可观测性至关重要——您需要在代理逻辑的同时跟踪 Azure SDK 调用，以诊断延迟或故障。