深入解析 DevOps Agent + MCP Server 架构：混合云 BGP 排障的自动化实现
混合云网络排障有个老大难问题：云侧和 IDC 侧的可观测性是割裂的。CloudWatch 告诉你 BGP 会话状态变了，但具体是对端路由器哪条策略改了、什么时候改的，你得 SSH 上去手动查。
亚马逊云科技最近发布了 DevOps Agent + MCP Server 的集成方案，通过 MCP 协议让 Agent 能直接调用 IDC 设备的只读命令，实现跨界自动取证。我搭完整套环境跑了两个测试场景，这篇文章把架构细节、安全设计和实测数据整理出来。
先说核心思路：MCP Server 当 Agent 的"手"
传统做法是写一堆 Lambda 采集脚本，定时拉数据回来。问题是：告警千变万化，你不可能预判所有需要的命令组合。
MCP Server 换了个思路——把路由器的只读命令封装成标准化的 Tool，暴露给 AI Agent。Agent 根据告警上下文，自己决定调哪些命令、按什么顺序调。
说白了，MCP Server 就是 Agent 伸进 IDC 机房的"手"，而且这只手被严格限制：只能执行 show 和 dir 开头的命令，连个 config 都碰不了。
整体架构长什么样
画个简单的数据流：
CloudWatch 告警
↓
EventBridge 规则触发
↓
DevOps Agent（Agent Space）
↓ Private Connection（VPC Lattice）
MCP Server（EC2）
↓ SSH
IDC Cisco 路由器
↓
Agent 生成调查结论
↓
EventBridge Scheduler + Lambda
↓
飞书群通知
几个关键点：
- Private Connection 基于 VPC Lattice，Agent 到 MCP Server 的流量全程走亚马逊云科技骨干网，不过公网。
- MCP Server 跑在 EC2 上，通过 SSH 连接 IDC 路由器。这台 EC2 既在 VPC 内被 Agent 调用，又能通过 Direct Connect/VPN 触达 IDC。
- Agent Space 三级模型：Service → Association → Skill，把 MCP Tool 组织得很清晰。
10 个 MCP Tool 的设计
这套方案定义了 10 个只读 Tool，分三类：
BGP 状态类
{
"name": "get_bgp_summary",
"description": "获取 BGP 邻居摘要信息",
"inputSchema": {
"type": "object",
"properties": {
"router_id": { "type": "string", "pattern": "^router-[a-z0-9]+$" }
},
"required": ["router_id"]
}
}
{
"name": "get_bgp_neighbor_detail",
"description": "获取指定邻居的详细 BGP 会话信息"
}
{
"name": "get_bgp_prefix_count",
"description": "获取当前接收的前缀数量"
}
路由策略类
{
"name": "get_route_map",
"description": "查看 route-map 配置"
}
{
"name": "get_prefix_list",
"description": "查看 prefix-list 条目"
}
{
"name": "get_running_config_section",
"description": "查看指定 section 的 running-config"
}
变更历史类
{
"name": "get_config_changelog",
"description": "获取配置变更记录"
}
{
"name": "get_log_events",
"description": "获取设备日志中的关键事件"
}
{
"name": "get_interface_status",
"description": "获取接口状态和流量统计"
}
{
"name": "get_directory_listing",
"description": "列出设备存储中的文件（用于查看历史配置备份）"
}
注意看 inputSchema 里的 pattern 字段——入参用正则白名单限制，防止注入。
安全边界设计：四道防线
这是我觉得方案里设计得很讲究的部分：
第一道：命令前缀白名单
MCP Server 只允许执行 show 和 dir 开头的命令。哪怕 Agent 幻觉了想执行 configure terminal，直接被拦。
第二道：入参白名单正则
每个 Tool 的输入参数都有正则校验。比如 router_id 必须匹配 ^router-[a-z0-9]+$，你传个 ; rm -rf / 进来，正则就挡住了。
第三道：输出脱敏
MCP Server 返回结果前，会把敏感信息（比如邻居 IP、AS 号以外的细节）做脱敏处理。Agent 拿到的是"够用但不过量"的信息。
第四道：IAM 权限收紧
Agent 调用 MCP Server 走的 IAM Role，只开了 bedrock:InvokeAgent 和 vpc-lattice:Invoke 两类权限。连 EC2 的 SSH 密钥都碰不到。
# IAM Policy 示例（简化版）
Statement:
- Effect: Allow
Action:
- bedrock:InvokeAgent
- bedrock:Retrieve
Resource: "arn:aws:bedrock:*:*:agent/*"
- Effect: Allow
Action:
- vpc-lattice:Invoke
Resource: "arn:aws:vpc-lattice:*:*:service/*"
实测：两个告警场景
场景一：BGP Prefix High
模拟对端路由器突然宣告 92 条前缀（正常是 20 条以内）。
Agent 收到告警后的动作链：
- 调用
get_bgp_prefix_count→ 确认前缀数异常 - 调用
get_bgp_neighbor_detail→ 看邻居会话状态 - 调用
get_prefix_list→ 检查过滤规则 - 调用
get_route_map→ 核实路由策略 - 调用
get_config_changelog→ 查最近变更 - 调用
get_log_events→ 翻设备日志
20 秒识别症状，8 次 MCP 调用，总耗时约 2 分钟。
Agent 的结论："对端在 14:32 修改了 prefix-list，移除了前缀数量限制，导致全表泄漏。建议联系对端恢复原始 prefix-list 配置。"
换成人来做，光是 SSH 上去跑完这些命令、肉眼比对输出，少说半小时。
场景二：BGP Prefix Asymmetry
去程走 Direct Connect，回程却绕到了公网。用户报延迟飙高。
Agent 的诊断路径不一样——它重点看了 get_route_map 和 get_running_config_section，发现是 Local Preference 配置不一致导致的路径不对称。
这个场景更能体现 Agent 的价值：它不是按固定脚本跑，而是根据症状动态调整排查策略。
Agent Space 的三级集成模型
亚马逊云科技的 Agent Space 用三级结构管理能力：
Service（MCP Server 注册为一个 Service）
↓
Association（绑定到某个 Agent）
↓
Skill（Agent 可调用的具体能力集合）
好处是解耦。同一个 MCP Server 可以被多个 Agent 共享，不同 Agent 可以被授权使用不同的 Tool 子集。比如一线 On-Call 的 Agent 只开放状态查询类 Tool，高级排障 Agent 才开放变更历史类。
自动通知：EventBridge + Lambda 推飞书
Agent 跑完调查后，结论会写入一个结构化的 JSON。然后：
- EventBridge Scheduler 定时（或事件触发）启动 Lambda
- Lambda 读取调查结论，格式化成飞书消息卡片
- 推送到指定飞书群
import json
import urllib.request
def lambda_handler(event, context):
conclusion = event.get("conclusion", "")
severity = event.get("severity", "info")
card = {
"msg_type": "interactive",
"card": {
"header": {
"title": {"tag": "plain_text", "content": " 网络排障结论"},
"template": "red" if severity == "critical" else "blue"
},
"elements": [
{"tag": "markdown", "content": conclusion}
]
}
}
req = urllib.request.Request(
url=WEBHOOK_URL,
data=json.dumps(card).encode("utf-8"),
headers={"Content-Type": "application/json"}
)
urllib.request.urlopen(req)
return {"statusCode": 200}
这样 On-Call 的同事不用盯着 Agent 跑，结论自动推到群里。凌晨三点的告警，Agent 自己查完、自己通知，人只要看结论决定是否需要人工介入。
我的判断
这套方案解决了混合云排障里一个很现实的痛点：Agent 不止看云侧指标，还能跨到 IDC 设备取证。
以前的 AIOps 工具大多只能分析自家平台的数据。一旦问题出在云下，还是得人工去 SSH。现在 MCP Server 把这个"跨界取证"的能力标准化了，而且安全控制做得很严。
迭代速度也挺快的——从 Agent 只能调云服务 API，到现在能跨到任意设备，这个能力边界的扩展节奏让人期待后面还能接什么。
当然也有局限：目前 MCP Server 还是需要自己写和部署，Tool 的定义也需要手动维护。如果路由器型号多、命令差异大，维护成本不低。但作为起步，这个方向是对的。
浙公网安备 33010602011771号