构建智能运维代理：基于 Elastic Agent Builder 与 MCP 的 Agentic 参考架构实践

将运维任务分解为多个自治智能体（Agents），每个 Agent 拥有明确目标、上下文感知能力和有限行动权限，通过协作完成复杂运维任务。目标驱动：如“保障支付服务 SLO > 99.95%”；感知环境：实时摄入日志、指标、链路、配置等数据；推理决策：基于规则或 LLM 判断根因与应对策略；安全执行：在授权范围内自动执行修复动作（如重启 Pod、扩容实例）；反馈学习：记录行动结果，用于后续优化。💡

大尚来也

678人浏览 · 2026-01-23 14:02:00

大尚来也 · 2026-01-23 14:02:00 发布

在 AIOps（人工智能运维）加速落地的今天，企业不再满足于“被动告警 + 人工响应”的传统模式，而是追求一种更主动、自适应、具备决策能力的运维范式——Agentic 运维（Agent-Centric Operations）。在这种范式中，系统不再是静态监控工具的集合，而是由多个具备感知、推理、执行能力的“智能代理”（Agents）协同工作，实现从“发现问题”到“理解问题”再到“解决问题”的闭环。

Elastic 作为可观测性领域的领导者，近期推出的 Elastic Agent Builder 与 MCP（Model Control Plane） 正为构建此类 Agentic 架构提供了强大支撑。本文将详解如何结合二者，设计并实现一个可扩展、安全、可审计的 Agentic 参考架构。

一、什么是 Agentic 架构？

Agentic 架构的核心思想是：将运维任务分解为多个自治智能体（Agents），每个 Agent 拥有明确目标、上下文感知能力和有限行动权限，通过协作完成复杂运维任务。

典型特征包括：

目标驱动：如“保障支付服务 SLO > 99.95%”；
感知环境：实时摄入日志、指标、链路、配置等数据；
推理决策：基于规则或 LLM 判断根因与应对策略；
安全执行：在授权范围内自动执行修复动作（如重启 Pod、扩容实例）；
反馈学习：记录行动结果，用于后续优化。

💡 与传统自动化脚本不同，Agentic 系统强调上下文理解与动态适应，而非固定流程。

二、Elastic 的两大关键组件

1. Elastic Agent Builder

允许用户通过 YAML 或 UI 自定义 Elastic Agent 的采集行为；
支持集成 自定义输入（inputs）、处理器（processors） 和 输出（outputs）；
可打包为独立 Agent Policy，一键部署到成千上万节点；
内置对 OpenTelemetry、Prometheus、Journald、Windows Event Log 等原生支持。

✅ 作用：定义“感知层”——让 Agent 知道该采集什么数据。

2. MCP（Model Control Plane）

Elastic 新一代 AI 控制平面，用于管理 LLM 提示（prompts）、工具调用（tools）、记忆上下文（context）和执行策略；
支持将 自然语言指令 转化为结构化操作（如 “排查最近 5 分钟 CPU 突增的服务” → 查询指标 + 关联日志）；
提供 工具注册中心，可安全暴露运维动作（如 Kubernetes API、Ansible Playbook）；
所有交互可审计、可回放，符合企业安全合规要求。

✅ 作用：定义“认知与执行层”——让 Agent 知道该做什么、怎么做。

三、Agentic 参考架构设计

下图展示了一个典型的三层 Agentic 架构：

┌───────────────────────┐
│   Orchestration Layer │ ← 用户指令 / SLO 目标 / 告警事件
└──────────┬────────────┘
           │
┌──────────▼────────────┐
│    MCP (Model Control Plane)  │
│  - LLM 推理引擎        │
│  - 工具注册中心        │
│  - 上下文记忆管理      │
│  - 安全策略执行        │
└──────────┬────────────┘
           │ 调用工具 / 查询数据
┌──────────▼────────────┐
│   Elastic Agent Fleet │
│  - Agent Builder 定义的策略 │
│  - 实时采集日志/指标/trace │
│  - 执行 MCP 下发的动作     │
└───────────────────────┘

关键交互流程（以“服务延迟突增”为例）：

触发：Elastic Observability 检测到 http.latency.p99 > 2s，生成事件；
路由：事件送入 MCP，激活“延迟排查”Agent；
推理：MCP 调用 LLM，结合当前拓扑、变更记录、资源水位，生成排查计划；
执行：
- 调用 Agent 查询相关 Pod 的 CPU/Mem 指标；
- 拉取慢请求的 Trace 链路；
- 若发现 DB 连接池耗尽，则调用预注册的“扩容 DB Proxy”工具；
反馈：执行结果写回 Elastic，更新事件状态，并记录到 Audit Log。

四、实战：用 Agent Builder + MCP 构建“自愈型”监控代理

步骤 1：定义数据采集策略（Agent Builder）

# policy.yaml
inputs:
  - type: logfile
    paths: ["/var/log/app/*.log"]
  - type: metrics
    metricsets: ["cpu", "memory", "diskio"]
    period: 10s
  - type: otel/traces
    endpoints: ["http://localhost:4318"]
outputs:
  - elasticsearch:
      hosts: ["https://es-cluster:9200"]

步骤 2：在 MCP 中注册运维工具

{
  "tool_name": "k8s_scale_deployment",
  "description": "Scale a Kubernetes deployment",
  "parameters": {
    "namespace": "string",
    "deployment": "string",
    "replicas": "integer"
  },
  "security_policy": "require_approval_for_prod"
}

步骤 3：编写 Agentic Prompt（MCP 管理）

“当服务延迟 P99 超过阈值且 CPU 使用率 > 80%，自动将副本数增加 1，但生产环境需人工确认。”

MCP 将此 prompt 编译为可执行逻辑，并在条件满足时触发工具调用。

五、优势与价值

维度	传统运维	Agentic 架构（Elastic 方案）
响应速度	分钟级（人工介入）	秒级（自动推理+执行）
决策依据	告警规则	多维上下文 + LLM 推理
可扩展性	脚本堆砌，难维护	模块化 Agent + 工具注册
安全合规	权限粗放	MCP 细粒度策略 + 审计日志
学习能力	无	行动结果反馈至模型，持续优化