在微服务与云原生架构成为主流的今天，生产系统的监控告警数量呈指数级增长。运维工程师每日淹没在来自 Prometheus、Datadog、APM 以及各类日志平台的告警洪流中，其中大量是重复、关联或可自动处理的噪音。单纯依赖人工 24/7 值守不仅成本高昂，且响应速度与准确性难以保障。近年来，大型语言模型（LLM）展现出的强大上下文理解与推理能力，为自动化告警处理带来了新的可能。然而，将 LLM 直接应用于生产环境的风险极高 —— 其固有的 “幻觉” 倾向、不可预测的输出以及高昂的延迟与成本，要求我们必须为其套上确定性的 “缰绳”。
因此，构建一个规则引擎与 LLM 协同工作的混合系统，成为当前工程实践中最具可行性的路径。本文旨在为 MLOps 及运维工程师提供一个可落地的设计蓝图，重点阐述如何分层设计、需要监控哪些指标，以及必须遵守的安全清单，而非泛泛而谈概念。
一、分层架构：确定性规则与概率推理的精准协作
混合系统的核心思想是 “让规则的归规则，让 LLM 的归 LLM”。一个健壮的生产级流水线通常分为三层：预过滤规则层、LLM 智能推理层、后处理与执行层。
1. 预过滤规则层（Fast Path） 这是系统的第一道防线，由完全确定性的规则引擎（如 Drools、自研引擎或简单代码逻辑）构成，处理速度在毫秒级。其核心职责是执行安全护栏与快速分类：
- 环境过滤：自动丢弃来自测试、预发等非生产环境的告警。
- 关键系统旁路：对于支付、鉴权等 P0 核心服务的致命错误（如 5xx 持续超过阈值），绕过复杂分析，直接触发最高优先级告警并通知值班人员。
- 静默规则管理：根据已知的 “噪音模式”（如特定实例重启期间的预期抖动）自动抑制相关告警。
- 元数据附着：为告警注入所有者团队、服务拓扑关系、近期变更记录等上下文信息，为后续 LLM 分析提供素材。
此层的关键设计参数是零容忍的误杀率。规则必须保守，宁可错放（交由下层处理），不可错杀（丢弃真实告警）。所有规则变更应走严格的代码评审与金丝雀发布流程。
2. LLM 智能推理层（Smart Path） 通过预过滤的告警将进入本层。此处 LLM（如 GPT-4、Claude 3 或专用微调模型）扮演 “资深值班员” 的角色，进行深度分析与决策。输入是一个结构化的上下文包，通常包括：原始告警载荷、过去 15 分钟内相关服务的指标趋势、最近一次部署信息、以及知识库中类似的历史事故记录。
LLM 被要求完成以下具体任务，并以严格的 JSON 格式输出：
- 去重与聚合：判断当前告警是否与已存在的事件同属一个根因，并将其归并。
- 严重性评估：综合影响面、用户感知、业务损失等因素，给出 P0 至 P4 的定级。
- 根因推测：基于提供的指标和变更数据，给出最可能的故障方向（如 “数据库连接池耗尽”、“新版本代码回归”）。
- 行动建议：生成具体的下一步操作清单，例如 “查看 A 服务的错误日志 B”、“考虑回滚部署 C”、“扩容 D 组件的实例数至 E”。
为了保证输出质量与可控性，必须实施以下工程约束：
- 提示词工程：设计系统提示词（System Prompt）明确角色、任务边界和输出格式，使用少样本示例（Few-shot）引导模型行为。
- 工具调用（Function Calling）：LLM 不应 “空想”，而是通过调用封装好的工具 API 来获取实时数据，例如 “查询服务 X 在过去 10 分钟的 P99 延迟”。
- 思维链（Chain-of-Thought）：要求模型输出其推理过程的简短摘要，便于后续审核与调试。
3. 后处理与执行层（Action Path） 本层接收 LLM 的 JSON 输出，并再次通过规则引擎进行最终校验与执行分发。这是另一道关键的安全阀：
- 策略合规检查：例如，无论 LLM 如何建议，规则禁止对生产数据库执行 “重启所有节点” 这类高风险操作。
- 信心阈值过滤：如果 LLM 对自身判断的 “信心度” 低于预设阈值（如 0.7），则自动降级为 “需人工复核” 状态。
- 行动路由：根据决策结果，将任务分派到不同渠道：创建 Jira 工单、在 Slack/PagerDuty 中打开高优事件、触发自动化修复剧本（Ansible、Terraform），或仅仅是记录后关闭。
二、生产就绪：监控你的 “监控者”
引入 AI Agent 本身就是一个新的分布式服务，必须对其建立完善的监控与可观测性体系。这包括两个维度：系统基础设施的监控，和 AI 决策质量与行为的观测。
系统级监控指标（SRE 视角）
- 延迟：告警从接入到最终处理的端到端 P99 延迟。目标应设定在秒级（如 < 30 秒）。需细分各阶段耗时（规则引擎、LLM API 调用、工具调用）。
- 吞吐与积压：每秒处理告警数（TPS），以及消息队列中积压告警的年龄分布。积压超过 5 分钟即应告警。
- 错误率：各组件调用失败率（HTTP 5xx，超时，JSON 解析失败）。LLM 提供商 API 的失败率需单独监控。
- 成本：每月 LLM API 调用费用、Token 消耗量。设置预算告警，防止因流量突增或提示词设计不当导致成本失控。
AI 行为观测指标（MLOps 视角）
- 追踪（Tracing）：为每一个处理的告警生成完整的追踪链路，记录输入、LLM 的完整请求与响应（含思维链）、调用的工具、以及最终执行的动作。这是事后复盘与模型优化的黄金数据。
- 在线评估（Online Evaluation）：对一小部分流量（如 5%）运行轻量级评估器，实时打分。关键评分项包括：
- 忠实度：LLM 给出的建议是否基于其接收到的真实数据，而非捏造（Hallucination）。
- 有效性：事后通过人工标注或自动化脚本判断，其建议的行动是否指向了正确的解决方向。
- 格式合规：输出是否严格遵守指定的 JSON Schema。
- 反馈闭环：建立渠道让值班工程师对 AI 的处理结果进行 “thumbs-up/down” 评分。这些反馈数据应自动进入标注管道，用于定期微调模型或优化提示词。
三、实施清单与安全红线
在启动第一个 PoC 之前，请与你的团队共同确认以下清单：
架构与实施清单
- 选择编排框架：评估使用 Temporal、Airflow、或自建状态机来管理复杂的多步骤推理工作流，确保其具备重试、超时和持久化能力。
- 设计降级策略：当 LLM 服务或规则引擎完全不可用时，系统应能降级至纯规则模式或直接将所有告警路由至人工处理。
- 实现幂等处理：告警可能重复触发，系统必须基于告警 ID 实现去重，确保同一告警不会被分析多次或执行重复动作。
- 缓存策略：对频繁查询的元数据（如服务拓扑、团队信息）和 LLM 对相似告警的分析结果进行短期缓存，以降低延迟和成本。
安全与合规红线
- “无自动修复” 原则（初期）：在系统获得充分信任前，LLM 的输出仅限于 “建议”，所有实质性的运维动作（重启、回滚、扩容）必须由人类工程师点击确认后触发。
- 关键系统隔离：定义一份 “关键系统清单”（如核心数据库、支付网关）。任何涉及这些系统的告警，其分析结果必须强制抄送二级审批人。
- 审计日志全覆盖：系统所有的输入、内部决策、输出以及执行结果，必须打入不可篡改的审计日志，并保留至少一年，以满足合规要求。
- 定期攻防演练：每季度进行一次红蓝对抗，尝试通过构造特殊告警载荷来 “欺骗” 或 “误导” AI Agent，以发现潜在的逻辑漏洞或提示词缺陷。
结语
将 AI Agent 引入生产告警分类，并非为了取代工程师，而是将其从重复、低价值的警报噪音中解放出来，聚焦于真正的复杂问题诊断与解决。成功的混合系统，其标志不是 “零人工干预”，而是 “人工干预的价值最大化”—— 工程师处理的事件更少，但每个事件的信息浓度和可操作性显著提升。
正如一位实践者所言，构建此类系统的核心是 “在 LLM 的创造性之上，叠加工程学的确定性与韧性”。始于规则，精于 LLM，终于安全可控的执行，这条路径正指引着运维智能化走向成熟。
参考资料
- Reddit 社区实践分享：I built an agent to triage production alerts，提供了混合系统的初步架构思路。
- Detection at Scale 文章：How AI Agents Transform Alert Triage，从工程视角分析了 AI Agent 在告警分类中的变革性作用。