智能体驱动运维：2024年DevOps故障修复与基础设施维护权威指南
智能体化 DevOps 正在将自主 AI 智能体深度嵌入代码编写、构建维护和运维三大核心阶段，从而实现从需求规格到生产故障自动修复的完整闭环工作流。Azure MCP Server 让任何智能体都成为 Azure 专家，GitHub Copilot 编码智能体异步处理基础设施更新，Azure SRE Agent 则自动检测、调查和修复生产故障。这三者在人类监督下协同工作，正在彻底改变软件的构建和运维方式。
原文：Agentic DevOps Is Here: How Azure MCP Server, GitHub Copilot, and SRE Agent Are Rewriting the Software Lifecycle[1]
AI 智能体如何重塑云应用的构建、部署与运维，一直是业界探索的前沿。如今，工具链的成熟度似乎已经抵达了一个关键的转折点。微软近期将 Azure MCP Server、GitHub Copilot 编码智能体、SpecKit 以及 Azure SRE Agent 整合进一个统一的工作流，覆盖了从编写第一行代码到自动修复生产故障的整个软件生命周期。本文将深入解析这个技术栈的各个组件，阐明其架构设计，并展示各部分如何无缝衔接。无论你是开发者、平台工程师还是 SRE，这套方案都能为你节省大量时间，解决实际工作中的诸多麻烦。
什么是智能体化 DevOps？
智能体化 DevOps 标志着 AI 参与软件开发生命周期的方式发生了根本性转变。
它不再将 AI 视为编辑器中孤立的代码补全工具，而是将自主 AI 智能体嵌入三个截然不同的阶段：代码、构建维护和运维。
在深入具体工具之前，有必要先理解其背后的三个核心理念：
从 AI 增强转向 AI 原生。这意味着不是简单地将 AI 功能硬塞进现有工具，而是将智能体直接集成到工作流、IDE、代码仓库和运维仪表盘中。这些智能体能够理解 Azure 上下文、订阅资源、部署目标乃至故障响应流程。
提升整个生命周期的生产力。生产力的提升不再局限于代码生成，而是延伸到了基础设施配置、异步代码审查、Pull Request 生成、故障检测、根因分析和修复等各个环节。
加速 AI 应用和智能体的交付。当开发工具本身是 AI 原生时，构建 AI 驱动的应用会显著加快，因为这些工具天然理解它们将要部署到的 AI 服务。
为了更具体地说明，不妨设想这样一个场景：一个应用使用 SpecKit 从规格文档开始构建，最终部署到 Azure Container Apps。当 PagerDuty 检测到生产故障时，Azure SRE Agent 会利用 Datadog 的遥测数据自动进行分诊和缓解。随后，一个包含长期修复方案的 GitHub issue 被创建，并由配置了 Azure MCP Server 的 GitHub Copilot 编码智能体接手，通过更新基础设施即代码的 Pull Request 来解决问题。整个过程几乎无需人工干预。下面，我们来逐一拆解每个部分。
架构：全闭环智能体工作流
在深入单个工具之前，先看看它们是如何连接成一个闭环系统的。整个流程大致如下：
Azure Container Apps 托管应用。这是运行时环境。一旦应用崩溃或开始抛出 500 错误，就会影响线上服务的可用性。
PagerDuty 检测到故障并创建 P1 级别警报。这是故障管理层的入口。
Azure SRE 智能体 接收 PagerDuty 故障并开始自主调查。它通过 Azure Native Integration for Datadog 和 Datadog MCP 服务器拉取 Datadog 的遥测数据，也可以通过 Azure CLI 获取 Azure Monitor 日志。
SRE 智能体 通过一个专门构建的 PagerDuty 子智能体，生成 AI 驱动的操作手册并将其附加到 PagerDuty 故障单中。
SRE 智能体 执行短期缓解措施，例如扩缩 Container Apps 的计划以应对 CPU 和内存压力。
SRE 智能体 随后会打开一个 GitHub issue，其中包含了用于长期修复的完整故障上下文。
配置了 Azure MCP Server 的 GitHub Copilot 编码智能体 接手这个 issue，更新 Bicep 等基础设施即代码文件，并创建一个 Pull Request。
这个 PR 经过人工审查、合并后，基础设施定义便与修复措施保持同步。
至此，一个完整的闭环形成：从代码编写、部署、检测、调查、缓解、修复到基础设施更新，全部由智能体编排完成，人类仅在关键决策点进行监督。接下来，我们详细看看每个阶段。
阶段 1：使用 Azure MCP Server 编写代码
Azure MCP Server 是整个技术栈的基础组件，它的核心作用是让任何智能体都成为 Azure 专家。MCP 代表模型上下文协议，这是一个开放标准，旨在让大语言模型能够与外部服务交互。Azure MCP Server 专门为 Azure 实现了这个协议，为任何兼容 MCP 的智能体提供关于 Azure 订阅、已部署资源和 Azure 最佳实践的深层上下文。
Azure MCP Server 提供什么
Azure MCP Server 向 LLM 提供了四大类关键能力：
Azure 上下文和资源感知。服务器赋予 LLM 访问 Azure 订阅的能力。它可以枚举已部署的资源，按区域分组，识别你在 Azure AI Foundry 中部署了哪些 AI 模型，查找存储账户 URL，并为正在工作的任何资源组提供直接跳转到 Azure 门户的链接。
始终最新的文档和最佳实践。服务器内置了最新的 Azure 文档、最新的 SDK 版本和当前的最佳实践。例如，当它生成代码时，会通过 DefaultAzureCredential 使用托管身份，而不是硬编码密钥。它了解 Bicep 的 Azure Verified Modules，能够引用保护应用的最新架构模式。
控制平面和数据平面操作。MCP 服务器暴露的工具既能查询资源状态（控制平面），也能与它们进行交互（数据平面）。你可以通过要求它创建一个禁用公共访问的新 Blob Storage 容器来测试这一点，智能体会调用适当的存储工具并在实时环境中创建容器。
基础设施即代码生成。服务器通过引用 Azure Verified Modules 和当前架构定义，帮助编写 Bicep 和 Terraform 模板。它创建的 Bicep 文件遵循推荐模式，包括针对目标计算服务的托管身份配置和推荐的资源设置。
GA 发布和覆盖范围
Azure MCP Server 现已正式发布（GA），覆盖了 47 种不同的 Azure 服务，横跨资源管理、诊断、监控、计算、数据服务等多个领域。所有访问都通过 Azure Identity 进行保护，这意味着其身份验证方式与常规开发者工具一致。
它适用于 VS Code、Visual Studio 2026（开箱即用）、IntelliJ、GitHub Copilot 编码智能体和 Copilot CLI。你也可以用它来构建自己的自定义智能体。
实际中的样子
下面是在 VS Code 智能体模式下使用 Azure MCP Server 的几个典型场景：
资源发现。询问“我部署了哪些 AI 模型？”，智能体会调用 Azure MCP Server 的 Foundry 能力，枚举我的资源，并按区域和模型类型（如 GPT-4 Mini、GPT-4.1 等）返回清晰的列表。仅此一项功能，就让我在需要快速查询时无需再登录门户。
资源创建。要求智能体为照片创建一个新的存储容器。它会了解可用的存储能力，调用创建工具，并确认容器已以禁用公共访问的方式创建。无需登录门户，也无需编写 CLI 脚本。
最佳实践代码生成。要求创建 Python 脚本将文件上传到特定存储容器，并包含错误处理和托管身份。智能体会首先调用最佳实践工具，然后使用带有 DefaultAzureCredential 的 Azure SDK 生成代码。没有硬编码密钥，也没有过时的模式。
基础设施即代码。要求生成配置 Azure Container Apps 的 Bicep 文件。智能体会获取最佳实践，引用 Azure Verified Modules，并生成生产就绪的 Bicep 代码。如果你更喜欢 Terraform，同样的工作流也适用。
阶段 1.5：使用 SpecKit 进行规格驱动开发
在进入构建阶段之前，有一个工作流值得一提，它真正改变了处理新应用的方式。它结合了 VS Code、GitHub Copilot、Azure MCP Server 和 SpecKit——一个 GitHub 上用于规格驱动开发的开源项目。
什么是 SpecKit？
SpecKit 帮助你创建为 LLM 工作优化的结构化规格。与其输入模糊的提示词并寄希望于智能体理解你的意图，不如通过一个结构化过程来定义你想要构建的内容，然后智能体会生成忠实遵循该规格的代码。
以下是其关键命令及其功能：
Constitution（/speckit.constitution）：这是为项目定义不可协商原则的地方，可以把它想象成架构护栏。例如，你可以指定：始终使用 Azure MCP Server，始终检查最佳实践，托管在 Azure Container Apps 中，始终使用托管身份，使用 Microsoft Agent Framework 构建 AI 智能体。Constitution 命令会将这些简短语句扩展为智能体能够遵循的详细、结构化指令。
Specify（/speckit.specify）：在这里描述你想要构建什么。例如，描述一个包含类别、教练、工作室、推荐 AI 智能体和基本页面导航的健身工作室查找应用。SpecKit 会将其扩展为详细的用户故事和功能规格。
Clarify（/speckit.clarify）：这是最受欢迎的功能之一。规格生成后，Clarify 会对照 constitution 和所有现有上下文进行分析，识别歧义或缺失的信息，并提出针对性的问题。例如，它可能会询问教练与地点之间的关系，或者如何处理性能需求失败。每个答案都会自动更新规格。仅这一步就能避免你和智能体之间产生大量误解。
Plan（/speckit.plan）：创建技术实现计划，根据 constitution 和需求选择特定的技术栈。
Tasks（/speckit.tasks）：将工作分解为多个检查点，让你有机会在每个阶段进行审查、本地测试和引导实现。
结果
使用这个工作流，可以构建一个功能完整的健身工作室查找应用，具备可浏览的工作室、教练资料、详情页面以及一个能根据活动偏好推荐教练的集成 AI 智能体。整个过程无需手写一行代码，整个应用都通过需求引导从规格生成。当智能体进行到部署步骤时，它会从 constitution 中获知要使用 AZD（Azure 开发者 CLI），从而创建所有 Bicep 模板并为部署做好一切准备。
阶段 2：使用编码智能体构建和维护
GitHub Copilot 编码智能体以异步模式运行，就像团队中的另一位开发者。你可以将 GitHub issue 分配给它，它会在代码仓库中独立工作，并生成供审查的 Pull Request。
将编码智能体连接到 Azure
这里的关键推动器是 Azure 开发者 CLI 的 azd coding-agent config 命令。此命令会自动在 GitHub Copilot 编码智能体和 Azure MCP Server 之间建立安全连接。它会在你的 Azure 订阅中创建托管身份，为 GitHub Actions 配置联合凭据，并提供一个 JSON 片段，让你粘贴到仓库的 Copilot 编码智能体设置中。
配置完成后，编码智能体就能访问你在 VS Code 中使用的相同 Azure MCP 工具。你可以指定它能访问哪些工具，还可以创建具有特定指令和提示配置的自定义智能体。例如，可以创建一个“Azure 智能体”，让它始终使用 MCP 工具，并为项目提供定制的提示词。
如何使用
你可以在仓库中为生成示例数据、添加新 API 端点或更新基础设施等任务创建 issue。将这个 issue 分配给你自定义的 Azure 智能体，编码智能体就会开始在后台异步工作。完成后，你会收到一个待审查的 Pull Request。这使你能够解放出来，专注于架构和设计决策，而让智能体处理具体的实现工作。
异步模型至关重要，因为它意味着编码智能体可以并行处理例行任务、基础设施更新和样板代码工作。
阶段 3：使用 Azure SRE 智能体运维
这是整个技术栈真正展现威力的地方。Azure SRE 智能体是一个专为站点可靠性工程设计的 AI 驱动服务，能够自动化故障响应，用遥测数据增强工单，并在获得批准后执行缓解措施。
为什么存在这个功能
如果你曾经在凌晨两点被叫醒去检查仪表盘，等待图表恢复正常，然后再回去睡觉，你就会理解 SRE 智能体旨在解决的痛点。运维大规模 Azure 基础设施的团队面临着巨大的工单量。处理单个工单可能需要几分钟到几小时的手动分诊，需要查询五个不同的界面，从多个来源关联日志，在开始修复之前先弄清楚发生了什么。
SRE 智能体已被微软工程师内部使用了九个月。从内部使用中获得的关键经验很明确：工程师们不想要一个取代他们的黑盒，而是想要一个助手，通过自动化故障响应中的重复部分来帮助他们，同时保持对流程的控制。内部数据显示，95% 的解决方案由智能体主动发起，这意味着智能体监听传入的工单并开始自主调查和修复。
关键功能
子智能体构建器。这个功能直接来自客户反馈。你可以构建自己的子智能体，覆盖特定类型故障的默认行为。每个子智能体都有自定义指令、交接规则和特定的工具集。例如，可以构建一个 Datadog 子智能体，使用 Datadog MCP 服务器工具获取日志、指标和跟踪；或者构建一个 PagerDuty 子智能体，用于生成操作手册并管理故障生命周期。你完全控制故障响应的发生方式。
MCP 服务器支持。SRE 智能体现在支持消费任何拥有 MCP 服务器的第三方工具的数据：Dynatrace、New Relic、Datadog 等。这非常关键，意味着你无需迁移现有的可观测性技术栈就能满足需求。
计划任务。SRE 智能体可以按照定义的计划运行任务，从而实现主动介入，而不仅仅是被动响应。例如，可以设置一个计划任务，在缓解措施执行后，每五分钟查询一次 Datadog 日志，持续两小时，以验证修复是否有效。你也可以在每周发布窗口后运行健康扫描。
知识库上传和 Azure DevOps Wiki 集成。你可以将文档上传到 SRE 智能体的知识库，或直接将其连接到 Azure DevOps 开发者 wiki。这让智能体能够访问组织内部关于如何处理特定类型故障的制度知识，使其变得越来越智能。
调试跟踪视图。在构建子智能体时，你可以使用调试跟踪视图在测试环境中测试和改进提示词，然后再部署到生产环境。这对于在智能体接触真实故障之前正确调整其行为至关重要。
智能体间集成。SRE 智能体与 PagerDuty 和 New Relic 等供应商集成，用于跨云的故障管理工作流。
完整故障生命周期实战
下面通过一个真实场景来了解所有这些组件是如何连接的。
设置：一个应用在 Azure Container Apps 上运行，并开始在其中一个端点上抛出 500 错误。PagerDuty 检测到故障并创建了一个 P1 级别的故障单。Azure Native Integration for Datadog 将应用级和基础设施级的日志都流转到 Datadog。Datadog MCP 服务器和我的 PagerDuty 子智能体已在 SRE 智能体中配置好。
Datadog 的 Azure Native Integration 的新门户面板现在允许你直接从 Datadog 集成页面启用 SRE 智能体及其关联的 MCP 服务器，你可以选择 SRE 智能体并直接在那里添加 MCP 服务器，这大大简化了设置过程。
PagerDuty 子智能体生成操作手册。使用 SRE 智能体聊天中的 @agent 命令，调用 PagerDuty 子智能体，并要求它为我的特定故障 ID 生成操作手册并找到分派人员。子智能体会生成一份综合操作手册，包含分步故障排查、缓解步骤、缓解后验证、回滚指导和分派人员信息。无需额外提示，它就会将此操作手册附加回 PagerDuty 故障单，为它自己和其他响应者提供上下文。
Datadog 子智能体获取遥测数据。在单独的线程中，Datadog 子智能体会检索与 PagerDuty 故障单相关的所有 Datadog 日志。它会向我展示 500 错误和请求数据，然后提议设置一个计划任务，每五分钟查询一次 Datadog，以监视错误是否复发。这个验证循环确保 SRE 智能体应用的任何修复措施确实有效。
自主缓解。SRE 智能体确认 PagerDuty 故障，使用 Azure CLI 搜索 Container App 日志，发现过去 30 分钟的 500 错误，运行关联分析以识别相关问题，生成错误模式可视化，并确定需要扩缩 Container Apps 的计划以处理 CPU 和内存压力。执行扩缩命令后，它会搜索关联的 GitHub 仓库中与此更改相关的基础设施即代码文件。找到相关的 Bicep 文件后，它会打开一个包含完整故障上下文的 GitHub issue：PagerDuty 故障 ID、订阅信息、Azure 实时日志以及长期修复的具体建议。
Copilot 闭环。这个 GitHub issue 被分派给 GitHub Copilot 编码智能体。由于编码智能体配置了 Azure MCP Server，它会接手这个 issue，开始会话，使用 MCP 服务器获取 Bicep 架构，更新基础设施即代码以匹配修复方案，并打开一个 Pull Request。经过人工审查和合并后，基础设施定义便与修复措施保持同步。
至此，闭环完成。
最终思考
在 Azure 上构建应用已有相当长的时间，可以明确地说，我们现在看到的不仅仅是一次增量工具更新，而是软件构建和运维方式的真正转变。
想想刚才描述的工作流实际上意味着什么。你写下想要构建的内容的简短描述，一个智能体将其转化为完整的规格，并通过提问来填补空白，生成内置安全最佳实践的生产就绪代码，然后部署。当生产环境出现问题，另一个智能体检测到问题，从可观测性平台拉取日志，编写操作手册，修复即时问题，并为长期解决方案打开工单。第三个智能体接手该工单，更新基础设施即代码，并提交供审查的 Pull Request。你在每一步都保有控制权，但所有繁琐、重复、易出错的工作都已被处理妥当。
最令人兴奋的部分在于其可扩展性。MCP 协议意味着这不会锁定单一供应商。如果团队使用 Datadog，可以插入 Datadog MCP 服务器。如果使用 Dynatrace 或 New Relic，同样可以。子智能体构建器意味着你可以将团队的知识和流程编码进去，而不是依赖通用的通用剧本。SpecKit 的 constitution 意味着架构标准会随着每个项目、每个智能体、每个 Pull Request 一起演进。
你可以选择这个技术栈的一部分，在真实项目上试用，亲眼看看效果。可以从 VS Code 中的 Azure MCP 服务器开始，快速获得反馈。如果团队被运维琐事淹没，可以尝试设置 SRE 智能体。如果厌倦了 AI 智能体构建出错误的东西，不妨试试 SpecKit。
参考资料
[1]Agentic DevOps Is Here: How Azure MCP Server, GitHub Copilot, and SRE Agent Are Rewriting the Software Lifecycle:https://medium.com/codex/agentic-devops-is-here-how-azure-mcp-server-github-copilot-and-sre-agent-are-rewriting-the-0a9d18632a28