支付链路在凌晨两点抖了一下。接下来五分钟，监控系统吐出了几百条告警：数据库连接池超时、风控服务变慢、网关错误率飙升、下游三个业务系统跟着报错。值班的人盯着屏幕，第一反应常常不是"哪里坏了"，而是"先看哪一条"。
金融行业的运维目标被总结成三个数字：1 分钟发现、5 分钟定位、10 分钟解决（来源：《金融级 AIOps 架构跃迁——从"1-5-10"快恢目标到 AI Agent 告警收敛的完整技术实践》，笔记同步助手，2026-10-07）。告警风暴面前，这三个数字最容易崩在第一环。
先有基座，再谈智能
这套体系有个容易被跳过的前提：底层监控得先扎实。
金融系统的难点是结构性的。一笔交易从客户端到核心系统，要跨网关、微服务、消息队列、数据库、外部接口十几个节点；一个数据库慢查询，可能在 30 秒内引起整个服务集群的线程池耗尽。要 1 分钟确认"确实出了问题"，就得三个维度交叉验证——操作系统监控、应用日志、业务指标，缺一个都会"看得见、定位慢"。
定位靠 traceId 全链路追踪：从网关入口生成，通过 HTTP Header 或消息队列透传到所有下游服务，最终打进每一条日志。一个反常识的工程决策是：金融系统的日志用管道符分隔而不是 JSON，因为排障时用的是 grep 和 awk，不是 JSON 解析器。路径是告警、错误日志、traceId、全链路日志、根因，五步走完。
规则引擎的三个天花板
基座搭好之后，传统方案会遇到结构性瓶颈。
老办法是"规则引擎加图数据库"：去重靠配置、分组靠维度、抑制靠规则、根因靠打分。它在规模化之后暴露三个问题（来源：《金融级 AIOps 架构跃迁》）。
一是规则膨胀：抑制规则从 20 条涨到 500 条以上，维护成本高，规则之间还互相冲突。二是未知故障盲区：没预先定义过的故障模式（比如 DNS 间歇性解析失败）不触发任何收敛规则。三是根因打分僵化：固定权重打分在高耦合拓扑里频繁误判，因为真实因果链是有条件的、跟上下文相关的。
图注：从规则数量到未知故障、再到根因误判，三个瓶颈都指向同一件事——规则只能匹配已知模式，无法推理未知因果。
四层漏斗，一层层往下筛
AI Agent 的加入，是在规则引擎之上叠一层自主推理，核心是一个四层收敛漏斗，把 1000 条/分钟的告警压到 1 到 3 个高置信度根因事件。
第一层是语义去重。传统去重靠字段完全匹配，但同一个故障在不同监控源里措辞完全不同：Prometheus 说"实例不可达"，Zabbix 说"端口不可达"，业务监控说"连接池全部超时"。Agent 用语义嵌入识别它们指向同一件事，配合时间窗口与拓扑位置二次确认。
第二层是上下文分组。Redis 集群故障引发支付链路雪崩时，传统分组会给出三个独立告警组，Agent 会把它们收成一个事件：根因层是 Redis 故障，传播层是支付、账户、风控的连锁超时，表现层是网关 5xx 升高，还带上业务影响——核心支付链路成功率掉到 92.3%，低于 99.9% 的阈值（来源：《金融级 AIOps 架构跃迁》，笔记同步助手）。
第三层是动态抑制，第四层是因果聚合：收到新告警时判断它是不是已有事件的衍生告警，置信度超过阈值才抑制，每一步推理都留痕、可回溯、能人工接管。
图注：四层漏斗依次做语义去重、上下文分组、动态抑制、因果聚合，最后吐出可审计的根因事件。
不是替代，是分工
有一点必须说清楚：Agent 不是来取代规则引擎的。规则引擎处理已知模式，快、确定、成本低；Agent 处理未知和复杂模式，慢一点、要推理、准确率更高。两者是分工，不是二选一。
这个判断决定了落地方式。如果一上来就把所有收敛逻辑交给大模型，等于让最贵的那条路径去干最便宜的活；如果 Agent 拿不到高质量的监控数据、准确的拓扑、可回滚的操作对象，推理就是空中楼阁。可观测性这条线也一样：一份事件轨迹能告诉你"发生了什么"，却未必能直接告诉你"哪些事件对核对某条结论才是要紧的"。落地经验里有三条铁律值得先做到——告警必须可执行、用静默策略避免告警风暴、把月度复盘误报率控制在 5% 以内（来源：研究报告《智能客服系统部署运维与生产优化实战》，11-AI-Fundamentals）。底座和数据得先到位。
源势AI观点
我们在金融、能源这类强合规客户身上反复确认一件事：Agent 进运维，瓶颈从来不是模型聪不聪明，而是它有没有权限、有没有证据、出事谁签字。所以我们的工程顺序是先做可观测、再谈自动化，把"结论到证据"的回放轨迹当交付物的一部分。
给两条落地建议。第一，权限按等级给：读取、建议、执行分开，涉及资金或生产的动作一律留人工审批闭环，Agent 只在被授权的范围内动手。第二，收敛结果的每一步都要可审计：保留推理链，而不是只给一个根因结论；否则运维团队不会真信它，最后又退回到人肉看告警。
话题标签：#AIOps #告警收敛 #智能体运维
