01｜AIOps 到 Agentic Operations：重新理解 AI 运维

1. 为什么这个问题重要

很多团队把"接入一个 LLM API"当成了 AIOps。结果是：机器人会聊天，但告警还是告警、故障还是人工排查。

这也是 ITOps Agent Platform 系列第 1 篇想要先解决的问题：在动手搭建任何 Agent 之前，先建立全局认知。只有先区分清楚 AIOps、AIOps 2.0、AgentOps 与 Agentic Operations 这几个概念，才能避免把预算和工程精力投向错误方向。

如果概念边界不清，团队很容易陷入两类典型误区：

• 误区一：把 LLM 当作监控系统的替代品。 以为给告警加一个自然语言问答入口，就完成了"智能化运维"，结果值班人员仍然要手动翻看指标、日志和链路。
• 误区二：把自动化等同于自治。 直接让 Agent 拥有重启服务、扩容、回滚等生产权限，却没有策略、审批和验证闭环。

因此，本篇的目标不是给出一个具体框架的实现细节，而是先画出一张"平台能力地图"，帮助后续每个章节都能落在地图上的正确位置。

2. 前沿技术趋势

如果把视角拉远，可以看到几个正在同时发生的趋势：

1. Observability 的信号边界在扩展。 传统可观测性只关注 Metrics、Logs、Traces，现在逐步扩展到 Profiles、Events 以及统一语义模型。OpenTelemetry 的语义约定让跨系统、跨服务的关联分析成为可能，也为后续的 Agent 推理提供了统一的数据底座。
2. AI Agent 自身需要被观测。 当一个 Agent 参与运维时，session、LLM 调用、tool call、token 消耗、延迟、失败原因等都需要被追踪。否则我们只能看到"Agent 做了某件事"，却无法回答"它为什么这样做、中间发生了什么"。
3. AIOps 的重心正在前移。 从"告诉你哪里有问题"，走向"帮你调查为什么有问题"。Azure Monitor 的 Agentic Operations、AWS CloudWatch Investigations 都把自然语言调查、跨信号关联、根因分析与 incident report 纳入工作流，让 AI 从告警展示者变成调查参与者。
4. 自治不等于无限权限。 主流方向是 controlled autonomy（受控自治），让 Agent 在受控边界内自主调查，在涉及高风险动作时强制进入审批或人类监督。
5. Agent 的生产可靠性需要单独评估。 传统 LLM benchmark 衡量的是"回答是否正确"，但运维场景关心的是"最终状态是否正确"。一个 Agent 可能每一步都回答得很聪明，最终却没有真正恢复服务。

这些趋势共同指向一个结论：Agentic Operations 不是简单地在监控系统上加一个聊天框，而是一条从信号到验证的完整能力链。

3. 核心概念

传统 AIOps 的能力主要围绕确定性分析和自动化展开，包括：

• 日志分析
• 指标异常检测
• 告警聚合
• 事件关联
• 根因分析（RCA）
• 预测
• 自动化 Runbook

Agentic Operations 在传统 AIOps 的基础上新增了 LLM 与 Agent 相关能力：

• 自然语言理解
• 上下文检索
• 工具选择
• 动态计划
• 多步骤执行
• 多 Agent 协作
• 结果验证
• 状态记忆
• 策略控制
• 持续评估

为了更清晰地对照两类能力，可以用下表快速区分：

维度	传统 AIOps	Agentic Operations
数据来源	Metrics、Logs、Traces、Events、Profiles 等遥测信号	在传统遥测基础上，增加自然语言输入、上下文检索、Agent session、LLM 调用、tool call 等数据
核心能力	日志分析、指标异常检测、告警聚合、事件关联、RCA、预测、自动化 Runbook	在传统能力上新增自然语言理解、上下文检索、工具选择、动态计划、多步骤执行、多 Agent 协作、结果验证、状态记忆、策略控制、持续评估
决策方式	以确定性规则和统计方法为主	LLM 推理 + 动态计划 + 工具调用，并受策略控制
自动化程度	自动化 Runbook、确定性自动化	受控自治（controlled autonomy），多步骤执行，高风险动作需审批或人类监督
验证机制	依赖阈值、规则和监控状态检查	强调 Verify：用 SLI、HTTP probe、容器状态、日志、业务交易等证据确认最终状态
典型工具	Prometheus、Grafana、ELK/Loki 等监控与日志分析工具	Azure Monitor Agentic Operations、AWS CloudWatch Investigations 等调查式运维能力

现代 AIOps 可以抽象为一条链：

Observe → Understand → Reason → Plan → Act → Verify → Learn

其中最关键的是 Verify。AI 说"服务已恢复"没有任何价值，必须用 SLI、HTTP probe、容器状态、日志、业务交易等证据确认最终状态。

这里有一个容易忽略的细节：Verify 不是最后才出现的步骤，而是贯穿整个链条的约束。 每一次推理、每一个工具调用、每一个状态变更，都应该能够被追踪和验证。否则 Agent 会变成一台"看起来很努力，但结果不可信"的机器。

4. ITOps Agent Platform 中的对应模块

把上面的概念映射到平台层面，可以得到四层能力：

Signal   → Metrics / Logs / Traces / Events / Profiles
AIOps    → Detection / Dedup / Correlation / RCA / Prediction
AgentOps → Planning / Tool Calling / Memory / Multi-Agent / Evaluation
Autonomous Ops → Policy / Approval / Execution / Verification / Rollback

这四层不是割裂的模块，而是一条从"感知"到"行动"再到"闭环"的价值链：

• Signal 解决"我们能看到什么"，它是所有智能的前提。
• AIOps 解决"发生了什么、为什么发生"，以确定性和统计方法为主。
• AgentOps 解决"如何调查、如何编排多步骤任务"，引入 LLM 和 Agent。
• Autonomous Ops 解决"如何安全地改变系统状态"，以策略、审批、验证和回滚为核心。

任何一层缺失，都会让整套体系变得不完整。例如跳过 AIOps 直接上 AgentOps，Agent 会缺乏可靠的告警上下文化和根因线索；跳过 Autonomous Ops 的安全控制，Agent 就会变成生产环境里的不可控变量。

下面用一张四层架构图展示它们之间的数据流与依赖边界：

各层之间通过明确的接口衔接，而不是互相穿透：

• ① Signal → AIOps：Signal 层输出统一语义的可观测数据（Metrics/Logs/Traces/Events/Profiles），AIOps 层消费这些数据做检测、去重、关联与根因分析。
• ② AIOps → AgentOps：AIOps 层输出告警、事件和 RCA 线索，作为 AgentOps 层调查与编排的输入上下文。
• ③ AgentOps → Autonomous Ops：AgentOps 层输出动态计划与工具调用请求，交由 Autonomous Ops 层执行。
• ④ Autonomous Ops → Signal：执行结果与验证证据回写到可观测信号，形成数据闭环。

Policy / Approval / Audit 是横切约束，贯穿 AgentOps 与 Autonomous Ops：Policy 在工具调用和执行前做策略校验，Approval 对高风险动作强制人工审批，Audit 对每一次执行留痕。任何动作只有通过策略校验或审批后才能进入 Execution，确保自治始终处于受控边界内。

Verification 是闭环的关键：U4 的验证结果一方面反馈给 AIOps 优化检测与根因逻辑（⑤），另一方面回写到 Signal 层作为新的可观测证据（⑥），对应「Verify → Learn」的持续学习路径。

5. 架构设计

平台按能力链组织，而不是按某个 AI 框架 API 组织。这样设计的好处是：底层框架可以替换，但能力链本身保持稳定。

系统可靠性 → Observability → 事件/告警工程 → 异常检测与降噪
→ Topology → RCA → Runbook/Knowledge/RAG → LLM/Tool Calling
→ Agent/Multi-Agent → Agent Observability & Evaluation
→ 安全/策略/审批/审计 → 自动修复与验证 → 自治运维 → 成本/容量/预测/持续学习

这条能力链有几点值得强调：

• 系统可靠性排在最前面。 没有可靠的遥测和系统基础，任何智能化都建立在流沙之上。
• RAG 与 Runbook/Knowledge 在 LLM 之前。 只有先沉淀好可检索的知识和操作手册，LLM 才能在正确的上下文中推理。
• 安全、策略、审批、审计在自动修复之前。 权限边界必须在自动化动作执行前被强制执行。
• 验证与持续学习形成闭环。 每次自动化动作都需要验证结果，并把验证结果反馈给后续的检测、分析和计划环节。

下面用一张分层架构图把四层能力的数据流和依赖关系串起来：

图中：

• 实线表示主数据流：从信号接入，经检测与定位、调查与编排，最终进入受控执行与闭环。
• 虚线表示策略依赖：Approval 对 Tool Calling 形成权限约束，确保高风险动作不能越过审批边界。
• 反馈线体现闭环：Verification 的验证结果反向驱动 AIOps 优化，并回写到可观测信号，对应「Verify → Learn」的持续学习路径。

6. 实战实验

本节的落地任务是建立 docs/aiops-capability-map.md，把四层能力逐项列出，并标注"已实现 / 规划中 / 不适用"，作为团队的基线地图。

建议的表格形式如下：

| 层级 | 能力 | 状态 | 备注 |
|------|------|------|------|
| Signal | Metrics | 已实现 | Prometheus + OpenTelemetry |
| Signal | Logs | 已实现 | Loki / ELK |
| Signal | Traces | 规划中 | 需补齐跨服务采样率 |
| AIOps | Detection | 已实现 | 阈值 + 统计异常检测 |
| AIOps | RCA | 规划中 | 依赖 Topology 数据 |
| AgentOps | Planning | 不适用 | 暂无多步骤调查场景 |
| Autonomous Ops | Approval | 规划中 | 需要接入审批流 |

做完这张地图后，团队就能清楚地看到：哪些能力已经具备、哪些能力需要补齐、哪些能力当前业务根本用不上。这也是后续章节技术选型的输入。

7. 代码 / API / 配置

下面给出一个最小"闭环"的伪代码骨架，用来表达 Agentic Operations 的核心流程：

def run_incident(incident):
    ctx = observe(incident)          # 收集遥测
    hyp = reason(ctx)                # 形成假设
    plan = plan_actions(hyp)         # 制定计划
    for action in plan:
        if not policy.allow(action):
            approval = request_approval(action)
            if not approval:
                continue
        execute(action)
    state = verify()                 # 关键：验证最终状态
    return report(incident, ctx, hyp, state)

这段代码虽然简单，但包含了几个关键的结构性设计：
下面把骨架展开成一个可运行的简化实现。各函数仍只是教学占位，但完整保留了「observe → reason → plan → check → execute → verify」的闭环：

from dataclasses import dataclass, field


@dataclass
class Incident:
    incident_id: str
    service: str
    summary: str
    severity: str


@dataclass
class Context:
    incident: Incident
    metrics: dict
    logs: list
    topology: dict


@dataclass
class Hypothesis:
    statement: str
    confidence: float
    evidence: list


@dataclass
class Action:
    name: str
    target: str
    action_type: str  # read / low_risk / high_risk
    params: dict = field(default_factory=dict)


@dataclass
class VerifyState:
    service: str
    healthy: bool
    sli: dict
    evidence: list


class Policy:
    """策略：只允许低风险动作自动执行，高风险动作必须审批。"""

    AUTO_ALLOW = {"read", "low_risk"}

    def allow(self, action: Action) -> bool:
        return action.action_type in self.AUTO_ALLOW


policy = Policy()


def observe(incident: Incident) -> Context:
    """第一步：收集事实上下文，所有后续推理都基于遥测而非猜测。

    生产环境对应：Observability / Signal 层中的 Context Builder，而不是一个简单函数。
    - 输入：来自告警平台（Alertmanager、PagerDuty 等）或 Incident 管理服务的 Incident，
      包含 incident_id、service、severity、发生时间窗口和关键标签。
    - 数据来源：
        * metrics 来自 Prometheus / VictoriaMetrics / Thanos 等指标查询服务；
        * logs 来自 Loki / ELK / OpenSearch 等日志检索服务；
        * traces 来自 Tempo / Jaeger / OpenTelemetry 等链路查询服务；
        * topology 来自 CMDB、Kubernetes 资源关系、服务网格或拓扑服务。
    - 输出：Context 对象，作为后续 reason 和 plan 的统一事实底座。
    - 实际项目中应携带 incident_id、start_time/end_time，并在查询失败时保留退化路径，
      避免 Agent 在缺少上下文时直接编造事实。
    """
    return Context(
        incident=incident,
        metrics={"cpu_usage": 0.93, "error_rate": 0.08, "latency_p99_ms": 1200},
        logs=[
            "ERROR downstream timeout from db",
            "WARN connection pool exhausted",
        ],
        topology={"service": incident.service, "depends_on": ["db", "cache"]},
    )


def reason(ctx: Context) -> Hypothesis:
    """第二步：基于上下文形成假设，真实系统可替换为 RCA 或 LLM 推理。

    生产环境对应：RCA 服务 / LLM Reasoning 服务，通常位于 AgentOps 的推理层。
    - 输入：observe 产出的 Context，包含指标、日志、链路和拓扑。
    - 推理依赖：
        * Runbook / Knowledge / RAG 提供历史案例和操作手册；
        * 确定性 RCA 负责生成可解释的根因候选；
        * LLM 负责归纳、补全和生成自然语言假设，但输出不能直接当作事实。
    - 输出：Hypothesis，包含 statement、confidence 和 evidence。
    - 注意：真实实现应要求 hypothesis 引用具体 evidence 来源，方便后续验证与审计。
    """
    if ctx.metrics.get("error_rate", 0) > 0.05:
        return Hypothesis(
            statement="数据库连接耗尽，导致下游超时与错误率上升",
            confidence=0.85,
            evidence=ctx.logs,
        )
    return Hypothesis(statement="指标正常，需进一步调查", confidence=0.3, evidence=[])


def plan_actions(hyp: Hypothesis) -> list[Action]:
    """第三步：把假设拆成可执行动作，并按风险等级标记。

    生产环境对应：Planner / AgentOps 的工具选择与编排模块。
    - 输入：reason 产出的 Hypothesis。
    - 规划来源：
        * Runbook / Skill Registry 提供可选动作和参数；
        * Tool Calling 决定调用哪个工具、参数如何填充；
        * Policy 在规划阶段参与，确保不会生成越权计划。
    - 输出：list[Action]，每项包含 name、target、action_type 和 params。
    - 输出去向：被 run_incident 的编排循环消费，并在执行前逐一经过策略和审批检查。
    - 真实实现中，如果 Planner 无法生成明确动作，应停止执行并升级给人，而不是继续猜。
    """
    return [
        Action("query_db_pool", "db", "read"),
        Action("restart_service", "api-server", "low_risk"),
        Action("scale_up", "api-server", "low_risk", {"replicas": 4}),
        Action("apply_network_policy", "prod-vpc", "high_risk"),
    ]


def request_approval(action: Action) -> bool:
    """第四步补充：高风险动作的审批入口，真实系统应接入工单、IM 或审批服务。

    生产环境对应：Autonomous Ops 层的 Approval / Human-in-the-loop 服务。
    - 输入：policy 校验未通过的高风险 Action。
    - 审批来源：
        * Jira / ServiceNow / Opsgenie 等 ITSM 工单系统；
        * Slack / Teams / PagerDuty 等值班沟通渠道；
        * 企业内部审批流或双人复核机制。
    - 输出：bool 审批结论，实际系统中通常还会返回 approval_id、审批人、超时时间等元数据。
    - 输出去向：审批结果回传给编排器，决定该 Action 是继续执行还是跳过。
    - 示例默认拒绝，避免演示脚本在交互输入中阻塞。
    """
    print(f"[approval] 人工审批：{action.name} -> {action.target}")
    return False


def execute(action: Action) -> None:
    """第五步：执行动作并在审计日志中留痕。

    生产环境对应：Autonomous Ops 层的 Execution / Executor 服务。
    - 输入：已通过策略或审批的 Action。
    - 执行后端：
        * 查询类动作调用 Prometheus、日志平台、CMDB 等只读 API；
        * 变更类动作调用 Kubernetes API、云厂商 API、Ansible/Terraform、数据库管理接口等；
        * 高风险执行必须绑定审批票据和服务号，避免无主变更。
    - 输出：真实实现应返回 execution_id、执行结果、耗时和错误信息，并写入审计日志与 Agent trace。
    - 输出去向：执行结果供 verify 和 report 使用，并同步进入可观测性链路。
    - 本示例只打印执行意图，不对真实基础设施做任何变更。
    """
    print(f"[audit] executing: {action.name} -> {action.target}")


def verify(ctx: Context) -> VerifyState:
    """第六步：验证最终状态，用 SLI / 探针证据判断服务是否真正恢复。

    生产环境对应：Verification / State Validator 服务，属于 Autonomous Ops 的闭环环节。
    - 输入：真实实现中不应直接使用变更前的 Context 快照，而应传入本次执行后的资源和时间窗口，
      并重新拉取当前遥测；此处为教学示例复用 ctx，仅用于展示结构化输出。
    - 验证来源：
        * SLI 指标（error_rate、latency、saturation 等）重新查询；
        * HTTP probe / 健康检查结果；
        * 容器就绪状态、进程状态、部署状态；
        * 业务交易探针和日志错误率检查。
    - 输出：VerifyState，包含 healthy、sli 和 evidence。
    - 输出去向：供 report 生成结论，并反馈给 AIOps/AgentOps 形成 Verify → Learn 闭环。
    """
    healthy = ctx.metrics.get("error_rate", 0) < 0.01
    return VerifyState(
        service=ctx.incident.service,
        healthy=healthy,
        sli={"error_rate": ctx.metrics.get("error_rate", 0)},
        evidence=["http_probe_ok"] if healthy else ["http_probe_timeout"],
    )


def report(incident: Incident, ctx: Context, hyp: Hypothesis, state: VerifyState) -> dict:
    """第七步：输出包含上下文、假设和最终状态的报告，便于审计与复现。

    生产环境对应：Incident Report / Audit Log 服务，面向复盘、审计和持续学习。
    - 输入：incident、Context、Hypothesis 和 VerifyState，以及过程中的动作执行记录和审批记录。
    - 报告去向：
        * 写回事件管理或工单系统，形成 incident timeline；
        * 写入数据分析平台，用于 Agent 评估、根因复盘和流程优化；
        * 同步到消息渠道，给值班人员提供结论和证据。
    - 输出：dict 报告，实际系统应包含 incident_id、session_id、trace_id，保证从告警到验证可回放。
    - 本示例保持简单，只聚合关键对象；真实实现会把 Context 内容转成可读、可检索的结构。
    """
    return {
        "incident_id": incident.incident_id,
        "context": ctx,
        "hypothesis": hyp,
        "final_state": state,
    }


def run_incident(incident: Incident) -> dict:
    """编排器：串联 observe → reason → plan → check → execute → verify 的完整闭环。

    生产环境对应：Autonomous Ops 的 Orchestrator / Workflow Runner，可由状态机或任务流实现。
    - 输入：从告警或事件入口传入的 Incident。
    - 内部流程：
        * observe 获取事实上下文；
        * reason 形成假设；
        * plan_actions 生成动作计划；
        * policy.allow 做自动放行判断，不满足则进入 request_approval；
        * execute 执行动作并留痕；
        * verify 验证最终状态；
        * report 输出闭环报告。
    - 数据流向：Incident → Context → Hypothesis → list[Action] → 执行与审批 → VerifyState → Report。
    - 生产实现需要补充：动作重试、超时控制、失败回滚、审批等待、状态持久化和全链路 trace。
    """
    ctx = observe(incident)                    # 先收集事实
    hyp = reason(ctx)                          # 再形成假设
    plan = plan_actions(hyp)                   # 拆分为动作计划
    for action in plan:
        if not policy.allow(action):           # 策略拦截高风险动作
            if not request_approval(action):   # 未获批准则跳过
                continue
        execute(action)                        # 执行并留审计
    state = verify(ctx)                        # 验证系统最终状态
    return report(incident, ctx, hyp, state)

这里的 reason 和 plan_actions 仍是简化示意；真实系统中可将 reason 替换为 RCA/LLM 推理，将 plan_actions 替换为规划器输出，但 observe、policy.allow、verify 这三个护栏不能省。

• observe 先行。 所有推理都基于事实上下文，而不是模型凭空猜测。
• policy.allow 强制策略。 任何动作执行前都先做权限检查，不满足时必须走审批。
• verify 收尾。 无论前序执行看起来多成功，最终都要验证系统状态。
• report 输出闭环。 把上下文、假设和验证结果完整记录下来，便于后续审计和学习。

真实生产实现中，这些函数会对应到具体的服务（如遥测查询服务、RAG、规划器、执行器、审批服务、验证探针等），但闭环结构不应改变。

8. 生产环境最佳实践

1. 先可靠性、再智能化。 坏遥测 + 好 LLM = 坏 AIOps。数据质量是一切的前提。
2. 让 LLM 做推理，不让 LLM 直接拥有权限。 LLM 适合生成假设、制定计划、组织信息，但不应该直接触碰生产系统的变更接口。
3. 所有自动化都必须可验证。 每一次自动修复，都要有明确的验证探针和预期状态。
4. 优先用确定性系统解决确定性问题。 RBAC、Schema、阈值、状态机这类问题，用确定性系统解决更稳定、更可解释，不要为了"智能"而硬塞 LLM。

9. 常见错误

• 把 LLM 当成 Source of Truth。 LLM 输出的是推理结果，不是事实本身；事实必须来自遥测、配置管理系统等可靠数据源。
• 跳过 Verify，直接相信"AI 说修好了"。 没有最终状态验证，自动化就失去了闭环。
• 一上来就追求全自动，没有权限边界和审计。 自治必须建立在受控和可审计的基础上，否则一旦出错，责任和影响都不可控。

10. 安全注意事项

全程贯穿 最小权限 + 审批 + 审计 原则：

AI 可以持续调查、生成方案，但凡涉及改变生产环境的动作，都必须经策略、审批或人类监督控制。

具体落地时，可以按动作风险分级：

• 只读动作（查询指标、拉取日志）可以自动执行。
• 低风险动作（重启无状态实例）可以在策略允许范围内自动执行，但必须记录审计。
• 高风险动作（数据库变更、网络策略调整、回滚）必须人工审批或双人复核。

权限边界不要等到 Agent 上线后再补，而是在架构设计阶段就固化下来。

11. 可观测性

从第一天就为 Agent 建立独立可观测性：

incident_id、session_id、trace_id、tool_call_id 要能串起来，否则后续无法回答 “Agent 为什么这样做”。

这意味着除了传统的服务可观测性，还需要额外收集：

• Agent 的完整推理链
• 每一步的输入与输出
• 工具调用的参数与返回值
• 每次决策所依赖的上下文
• 失败与重试的原因

只有把这些串成一条可回放的链路，才能做到事后审计、问题复现和持续改进。

12. Evaluation

正确性最终要定义为"系统是否到达预期状态（end-state correctness）“，而非"模型回答得好不好”。

评估 Agentic Operations 时，至少要区分两个层次：

• 过程质量：Agent 的推理是否合理、计划是否可执行、工具使用是否正确。
• 最终状态：系统是否真正恢复了健康，是否满足 SLI 目标，是否有额外副作用。

只有最终状态正确，一次自动化操作才算是成功。过程质量再高，如果最终状态错误，仍然是一次失败。

13. 验收标准

读完本篇后，应当能够回答以下问题：

• AIOps 与普通监控的区别是什么？
• 为什么 LLM ≠ AIOps？
• 为什么自动修复必须验证？
• 为什么 Agent 需要独立的 observability？
• 为什么生产 Agent 必须有权限边界？

如果这些问题都能用自己的语言回答清楚，就说明已经建立了对 Agentic Operations 的基本全局认知。

14. 思考题

• 你现在的"AI 运维"，处于 Observe → Reason → Act → Verify 链的哪一环？
• 如果去掉 LLM，你的 AIOps 还剩多少价值？

这两个问题值得团队一起讨论。第一个问题帮助定位现状，第二个问题帮助识别真正由 LLM 带来的增量价值，而不是把传统能力重新包装成"AI"。

15. 延伸阅读

• OpenTelemetry Signals
• Microsoft: AIOps and Agentic Operations
• AWS CloudWatch AIOps
• Google SRE Workbook

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/qq_31532979/article/details/164328201