上个月，我们团队花了整整一个周六，手动处理横跨三个 Azure 区域的级联故障。当时，Azure Monitor 的告警疯狂刷屏，散落在 Wiki 上半年没人更新的运维手册，还有三个工程师互相抢活儿，都在搞不清楚到底谁在重启哪个服务。等我们把一切稳定下来时，我整个人都精疲力尽，满心挫败。肯定有更好的办法，能把故障响应中那些繁琐的环节——抓取日志、检查状态、执行运维手册——自动化，同时在关键决策上保留人工干预。
那个周末，我开始折腾 Microsoft Agent Framework。之前我看到了他们主推“Agentic DevOps”的公告，很好奇这个新的开源 SDK 到底能不能搞定真实的基础设施任务，还是说它只是个只能在 Demo 里耍耍的玩具。下面就是我从零开始搭建一个故障缓解 Agent 的经验之谈。
入门：第一个 Agent
Microsoft Agent Framework (MAF) 支持 .NET、Python 和 Go。我选了 Python，因为我们现有的 DevOps 脚本基本都是 Python 写的。框架目前还是预览版，所以你需要安装预发布版的包。
pip install microsoft-agents-core --pre
pip install microsoft-agents-ai-foundry --pre
第一个惊喜：这个框架需要你自己提供 LLM 端点。它支持 Azure OpenAI、OpenAI、Anthropic、Ollama 和 Microsoft Foundry。我把它指向了我们的 Azure OpenAI 实例：
from microsoft.agents.ai import AIAgent
from azure.identity import AzureCliCredential
agent = AIAgent(
endpoint="https://your-foundry-service.services.ai.azure.com/api/projects/your-foundry-project",
credential=AzureCliCredential(),
model="gpt-4o-mini"
)
response = agent.invoke("What Azure services are running in our subscription?")
print(response.content)
这段代码跑得很顺，挺让人鼓舞的。但是，一个只会聊天的机器人算不上 DevOps Agent——它顶多是个高级点的 FAQ。真正的威力在于你给它配上工具。
添加 DevOps 工具
框架教程的第二步讲了函数工具，这对我的用例来说太有搞头了。我定义了一些工具，让 Agent 能真正和我们的 Azure 基础设施交互：
from microsoft.agents.ai import tool
@tool
def get_alerts(severity: str = "Sev1") -> str:
"""Fetch active Azure Monitor alerts filtered by severity."""
# 实际实现使用 Azure SDK
from azure.mgmt.monitor import MonitorManagementClient
client = MonitorManagementClient(credential, subscription_id)
alerts = client.alerts.list_by_subscription()
active = [a for a in alerts if a.properties.severity == severity]
return str([{"name": a.name, "state": a.properties.monitor_condition} for a in active])
@tool
def restart_app_service(resource_group: str, app_name: str) -> str:
"""Restart an Azure App Service."""
from azure.mgmt.web import WebSiteManagementClient
client = WebSiteManagementClient(credential, subscription_id)
client.web_apps.restart(resource_group, app_name)
return f"Restarted {app_name} in {resource_group}"
@tool
def check_runbook(runbook_name: str) -> str:
"""Retrieve steps from our incident runbook wiki."""
# 从内部文档 API 获取数据
import requests
resp = requests.get(f"https://wiki.internal/runbooks/{runbook_name}")
return resp.text
框架会自动处理模式解析和工具定义。我不用再手写 JSON Schema 了——它会自动检查函数签名和文档字符串。这省下了一大堆样板代码，出乎意料地爽。
多轮对话与状态管理
真实的故障处理不是问一个问题就完事了。你要排查、采取行动、检查结果，然后再不断循环。MAF 使用“会话（sessions）”来管理多轮状态：
from microsoft.agents.core import AgentSession
session = AgentSession(agent=agent)
# 第一轮：发现问题
response1 = session.invoke("Check for Sev1 alerts in production")
# Agent 调用 get_alerts，发现 "app-api-prod" �挂了
# 第二轮：排查原因
response2 = session.invoke("What does the runbook say about app-api-prod failures?")
# Agent 调用 check_runbook，获取缓解步骤
# 第三轮：采取行动
response3 = session.invoke("The runbook says to restart. Go ahead and restart app-api-prod in rg-production")
# Agent 调用 restart_app_service
会话会自动维护对话历史。比起把一个个独立的 API 调用硬拼在一起，这绝对是个巨大的进步。
记忆与持久化：别再重复自己
我们以前手动处理故障时，最让我抓狂的一点就是反复交代相同的上下文。“那个在哪个资源组里来着？”“测试环境的数据库连接串是啥？”MAF 的上下文提供者能让你注入持久化的信息：
from microsoft.agents.core import ContextProvider
class InfrastructureContextProvider(ContextProvider):
async def get_context(self) -> str:
return """
Production Resource Group: rg-production
Staging Resource Group: rg-staging
Primary Region: eastus
Secondary Region: westus2
On-Call Rotation: Check https://pagerduty.internal/current
Escalation Policy: Sev1 requires manager approval before database changes
"""
agent.add_context_provider(InfrastructureContextProvider())
现在，Agent 不用每次被提问，就能自动知道我们的资源组名称和区域。更关键的是，我把升级策略直接嵌在了上下文里——这样 Agent 就知道，没有批准它是绝对不能动数据库的。
工作流：真正的杀手锏
单个 Agent 虽然有用，但框架基于图的工作流才是 DevOps 自动化真正发力的的地方。我搭了一个工作流，把告警检测、运维手册查找和故障缓解串在一起，并且加了人工干预审批环节：
from microsoft.agents.workflows import Workflow, step
@step
async def detect_alerts(context):
alerts = get_alerts(severity="Sev1")
context["alerts"] = alerts
return "investigate"
@step
async def investigate(context):
for alert in context["alerts"]:
runbook = check_runbook(alert["name"])
context["runbook_steps"] = runbook
return "approve"
@step
async def approve_action(context):
# 人工干预：暂停并等待审批
print(f"Proposed action based on runbook: {context['runbook_steps']}")
approval = input("Approve? (yes/no): ")
if approval.lower() == "yes":
return "execute"
return "abort"
@step
async def execute_remediation(context):
# 执行已批准的步骤
restart_app_service("rg-production", "app-api-prod")
return "done"
workflow = Workflow()
workflow.add_step("detect", detect_alerts)
workflow.add_step("investigate", investigate)
workflow.add_step("approve", approve_action)
workflow.add_step("execute", execute_remediation)
workflow.add_transition("detect", "investigate")
workflow.add_transition("investigate", "approve")
workflow.add_transition("approve", "execute")
workflow.add_transition("approve", "abort")
这种带检查点的人工干预功能，简直是我以前都不知道自己有多需要的东西。当 Agent 想重启生产服务时，它会暂停并等待我的批准。我可以检查它打算做什么以及为什么，然后再决定同意还是拒绝。这对 DevOps 来说至关重要——你绝不能让一个 Agent 在没有人工签字确认的情况下，擅自重启生产服务。
处理复杂任务的 Agent Harness
对于耗时较长的多步操作，MAF 提供了一个“Harness”Agent，内置了规划、待办事项跟踪和上下文压缩功能。我用一个复杂的部署验证场景测试了一下：
from microsoft.agents.harness import HarnessAgent
harness = HarnessAgent(
agent=agent,
tools=[get_alerts, check_runbook],
enable_planning=True,
enable_todo_tracking=True
)
response = harness.invoke("""
Validate that the v2.3.1 deployment to production is healthy:
1. Check for any new Sev2+ alerts
2. Verify the health check endpoints are returning 200
3. Compare error rates to the pre-deployment baseline
4. If any issues found, look up the rollback runbook
""")
Harness Agent 制定了一个计划，跟踪了每一步的进度，并在对话变长时压缩了上下文。这在部署验证时真的非常实用，因为这种多步操作需要你在大量检查项中保持专注。
实话实说的局限性
用了几周 MAF 来做 DevOps 任务后，这是我的真实评价：
框架还在预览阶段。 我碰到了一些小毛病——有些文档链接 404 了，而且 Go 版本缺失了好几个功能（目前还没有声明式 Agent、没有 RAG、也没有 CodeAct）。如果你是主要用 Go 的团队，建议再等等。
工具的安全性需要慎重考虑。 那个“不再询问”的工具批准功能用起来很方便，但在 DevOps 场景下很危险。我就不小心把一个本该只批准一次的工具给永久放行了。现在，对于会修改基础设施的工具，我一律使用单次批准模式。
本地开发与云端部署并不能完美对应。 框架承诺可以顺畅地部署到 Azure，但我发现在迁移到 Azure Functions 托管时，还是得重写一些本地工具的实现。托管体验正在改善，但还没做到无缝衔接。
成本可能会悄悄失控。 当 Harness Agent 用 GPT-4o 做多步规划时，Token 消耗得飞快。我现在把常规检查都换成了 GPT-4o-mini，只有在处理复杂的故障分诊时才上 GPT-4o。一定要盯紧你的 Azure OpenAI 用量。
它不能替代你现有的 IaC。 MAF 是用来做动态的、基于推理的自动化——比如故障响应、部署验证、执行运维手册。它取代不了 Terraform、Bicep，也取代不了你的 CI/CD 流水线。把它当成一个互补层，专门处理那些需要判断力和灵活性的任务就对了。
实用建议
从只读工具起步。 在给 Agent 修改基础设施的权限之前，先让它以观察模式跑一周。让它抓取告警、检查状态、展示信息。慢慢建立信任。
在上下文提供者里加防护栏。 把你的升级策略、变更冻结期和受限操作直接写进上下文里。大模型在大多数时候会遵守这些指令（虽然不是绝对，这也是为什么人工干预很重要）。
用好工作流检查点。 对于任何多步的 DevOps 流程，都要构建带明确审批步骤的工作流。检查点还意味着你可以恢复中断的工作流——这在你处理长达数小时的故障时非常关键。
记录所有日志。 MAF 内置了可观测性，但你会想把 Agent 的操作接入到现有的监控体系中。我把所有 Agent 的工具调用都发到了 Application Insights，和我们的其他 Azure 遥测数据放在一起。
对 Agent 配置进行版本控制。 把你的 Agent 定义、工具配置和上下文提供者当成代码来对待。放进 Git 里，在 PR 中审查变更，通过 CI/CD 流水线部署。Agent 也是基础设施。
Microsoft Agent Framework 并不完美，但这是我用过的第一个感觉是为生产级 DevOps 负载设计的，而不只是个 Demo 玩具的 Agent 框架。结构化的工作流、人工干预审批和持久化记忆的组合，切实解决了我应对故障时的痛点。花点时间折腾一下是值得的——只是在你建立起足够的信任、让 Agent 更加自主地工作之前，千万记得把人留在闭环里。