告警太多没人看之后：我们把排障拆成了快思考和慢思考

我们团队负责公司内部的 AI 应用平台。平台跑起来的第一年，接得最多的是问答类场景：知识库问答、制度查询、接口文档答疑。这类场景上手快，用量数字也拿得出手，但有个共同的毛病：用户问完就走，AI 到底替谁省下了哪一件具体的事，说不清楚。所以 2024 下半年我们做了件挺笨的事，挨个找业务线和值班团队聊，问他们每天最烦、最重复、又最不敢不做的事情是什么。告警是我们发现值得做的一个点。

我们和某条业务线的同学一起盘过一次他们的告警。结论不太好看：告警多到没人能逐条看完，其中有很大部分是正常波动、重复触发或者短时抖动，值班同学长期处在告警疲劳的状态里。这不能怪谁不负责。告警量一旦超过人能处理的上限，人会自动降低对每一条的敏感度，而在这种状态下漏掉一条真实事故，往往事后才知道。

三期，每一期都是业务痛点

我们最初支持业务线时只做了一件事：告警降噪。上线之后业务反馈里冒出第二个问题：有效告警确认完，值班同学还得盯每个事件有没有人认领、影响面确认了没有、到时限了没有，这部分重复劳动一点没少。于是有了第二期，把应急跟进的固定动作沉淀成流程机器人。在前面两期都能明显解决业务诉求的前提下，与业务开始尝试更深度合作的排障流程：一个客诉或者接口异常，要跨日志、链路、配置、发布记录和业务接口来回查，经验散在少数几个人脑子里，换个人就得重新摸一遍。这条链路是我们陪着业务一起挖掘出来的，没有先搭一个「智能运维平台」再去找场景往里填。平台能力一直跟在实际业务场景迭代，每一期都对着业务当时正在为之加班的具体问题，验收人就是那群加班的人。

第一期：告警分析，先保证不漏

做告警分析之前我们先明确了一个前提：这件事的收益和代价是不对称的。多放过一条噪音，值班同学多看一眼；错抑制一条真实告警，可能就是一次事故的发现延迟。所以设计上第一条原则是控制漏报，降噪率排在后面。

链路是三段式，顺序很重要。

第一段是确定性规则先跑。业务对某些类型的告警要求人工必看，比如资金相关的接口异常、错误日志量超标、带特定业务语义的告警名称，这些在预处理阶段就直接标成「需关注」，不给模型抑制的机会；规则由业务自己定，我们只提供配置入口。另一类确定性判断是短时重复：配置的时间窗内相同告警出现多次直接触发，不再分析。重复本身就是信号。

第二段才是模型，只负责真正模糊的趋势判断。这里踩过一个坑：小流量指标不能直接套同比环比，稀疏指标稍微波动一下同比就是几倍，模型很容易判成暴涨暴跌。所以小流量规则显式忽略同环比，改看触发前后有没有波动、有没有跌到零，大流量规则看触发前一段时间的区间。这些阈值是特定业务、特定阶段的规则，上线后靠业务抽检来调，不能跨业务照搬数字。

第三段是失败时的默认处理，也是我认为最关键的一段。模型返回异常、输出格式不对、分析超过设定时限，一律按「需关注」处理，告警原样发出，也就是 fail-open。只有经过业务确认的低风险规则和场景，才允许抑制。

配套还有两件事：每次分析都落日志，规则命中了什么、拿到了哪些指标、模型给了什么结论都能回放；新业务接入有缓冲期，抑制开关什么时候打开由业务决定，打开之后也随时可以关。

结果上，进入自动分析并被治理的无效告警大约占 50%。这个数字的口径是业务场景基准：被标注或抽检为无效、可抑制的告警，进行了重新配置和治理。根据业务接入前的人工验证数据评估，告警分析准确率达 90%+。到去年底盘点时，告警抑制大约接入了 70% 的业务，日处理 1800+。

第二期：应急跟进，确定的流程用状态机

第一期上线一段时间后，噪音确实少看了，但值班同学的工作量没有明显下降，因为有效告警之后的认领、影响面确认、时限提醒这些固定动作还是人在盯。所以第二期我们把精力从告警判断挪到了下游。

我们和值班团队一起把这套 SOP 沉淀成钉钉群机器人里的状态机：事件创建拉群 → 认领或转派 → 确认影响面 → 判定应急还是非应急 → 应急走处理与升级，非应急限时处理 → 事件结论 → 完结。每个节点有时限，到点由机器人提醒和规则事件推动。

AI 在这一段的角色刻意收得很窄。一是把群里的自然语言转成受控命令，命令集封闭：认领、转派、应急、非应急、事件结论、完结。口语映射不上的时候机器人必须提示合法话术，不能静默忽略；完结这类会改变事故生命周期的动作，只有授权角色能执行，模型可以建议，执行必须命中授权接口并留审计。二是召回历史相似事件供参考，不自动改工单字段。三是在节点上辅助总结，减少值班手写。

这里最容易出的问题是「群里完结了、平台没完结」。我们的处理是群里的状态只作交互层，问题管理系统才是真相源。确定的流程用状态机，不用自由 Agent。

后来还多交付了一个子集：变更分析。值班同学在群里触发后，机器人拉取给定时间窗内的变更记录，结合事件描述做相关性排序，给一份报告。交付的是关联分析加报告，回滚和改配置仍然由人做。

这一段的指标看闭环节点有没有按时发生。值班同学在固定跟进上的压力确实降下来了，原本需要一个全职同学的投入，缩减为只需最后确认。

第三期：排障，快思考和慢思考

排障是三段里最容易被讲成「让模型自己去查」的部分。我们最早也为一条业务线写过定制脚本，在特定数据源上跑得还行，也确实把一批工单查出了结论，但排查逻辑和数据源都焊死在代码里，换一个业务就得重写。这个经验决定了后面的拆法：业务把不同场景的排查经验写成业务 SOP，MCP 承载工具协议，运行时管状态、轮次、终止和人工出口，三者各管一段，互不替代。

当时的技术方案把整个系统分成四层。对接层把工单系统、监控告警、钉钉群和开发者工具（IDE 里的 MCP）进来的问题统一转成排障任务；诊断层就是下面要讲的快慢思考；反馈层负责报告生成、人工采纳 / 拒绝 / 重排，以及一个审批工作流；修复层规划的是从根因到修改建议，再到提交代码、改配置、回滚发布。

业务先把 SOP 写成可执行的

先说一个看起来不像技术问题的前置条件：业务侧要把常见问题写成可执行的 SOP，接口入参怎么准备、返回值输出什么，流程分成取数据源、链路分析、结果输出几步。没有这一步，后面的执行只会「说思路、不调工具」。早期真实遇到过，模型输出一段很像排查方案的文字，一个接口都没查。

平台给 SOP 定了一个固定结构，业务按这个结构往库里录：领域（前端 / 服务端 / 客户端）、业务线和业务场景、责任团队、问题类型、排查路径，以及这条 SOP 允许调用的 MCP 工具组。工具组覆盖 SRE 服务层的日志、指标、链路追踪、配置变更记录，和业务侧的订单、支付、退款等现场数据。

快思考：先决定值不值得花预算

一个排障任务进来，编排层先组输入：工单标题、问题描述；人工重排时再拼上反馈记录里最近一次「重新排障」的方向，然后交给快思考 Agent。

快思考做的是问题增强和路由。它结合知识库召回和历史相似案例，把口语化的工单改写成结构化的问题理解，返回一份约定的 JSON：增强后的问题描述、信息是否完整及缺失项、可解性判断（是否可解、理由、置信度），可解时再附上直接答案。增强后的描述要补齐领域（前端 / 服务端 / 客户端）、业务线、问题类型、已知线索和缺失信息。一条「用户说退款没到账」的客诉，经过这一步会变成「普惠业务线、服务端、退款类问题，已知订单号和时间，缺支付渠道回执」。可解的直接标成「AI 分析已解决」，任务完成，进入等人确认；不可解的进入慢思考。

快思考还有一个预检的作用。工单说不清楚、关键信息缺失的问题在这一步就被过滤：Agent 判定信息不完整时，直接以「需要补充哪些信息」作为结论收口，任务进入等人确认，人补齐信息后带方向重排，一个说不清的问题不会进入后面的多轮取证。

慢思考：有界循环，四步固定顺序

慢思考是一个受运行时控制的循环，每轮固定跑四步：匹配 SOP → 执行取证 → 汇总报告 → 结果裁决。四步由运行时按数组顺序推进，模型不控制流程。 四个阶段背后是平台上各个独立配置的 Agent，提示词放在平台侧，运行时只负责组问题、发请求、解析约定的 JSON、落库；改提示词、发新版本都在平台上做，运行时代码不用动。

四个 Agent 之间没有共享的对话记忆，每次调用都是一次独立的无状态请求，带独立的 requestId。上下文全部由运行时保管：每个阶段跑完，结果文本和解析出的结构化字段按「深度思考次数 - 轮次 - 阶段」三元组写进阶段记录表，任何一次执行都能回放到具体哪次调用。下一个 Agent 需要什么，运行时从这张表里挑出来拼进它的输入，不把前面的内容原样转发，避免提示词上下文爆炸。

挑法分两种：同一轮内，阶段只看本轮已完成的前序阶段；跨轮次的信息按需单独取，比如快思考的增强描述、历史所有轮次用过的 SOP、上一轮裁决给的方向。每个 Agent 只拿到它这一步需要的最少上下文，拼什么、拼多少由运行时的代码决定。

匹配 SOP

输入是快思考增强后的问题描述，里面已经带着领域、业务线和已知线索，再拼上三类上下文：上一轮采用的 SOP 描述、历史所有轮次已用过的 SOP 列表（提示词里明确要求不要重复推荐）、上一轮裁决给出的「继续排查」方向；人工重排时再加上人写的反馈。匹配先按业务线收窄候选，再用问题描述做语义匹配，一条普惠的退款问题不会匹配到两轮车的 SOP 上。Agent 返回一组候选，每个带 SOP ID、名称、描述、置信度和推理依据，运行时按置信度排序只取第一条。匹配不到就失败退出，报错信息直接引导业务去 SOP 库补建，不空跑。

执行取证

这一步有两类执行者。

一类是通用排障 Agent，按领域各一个，由对应的团队维护：SRE 的服务端根因分析（宿主机抖动、数据库和缓存慢查询、HTTP 错误数和响应时长上升），前端团队的前端基础排障（扁鹊监控告警、前端发布平台错误），客户端团队的客户端基础排障（客户端监控告警、客户端发布平台错误）。它们不懂具体业务，只回答一个领域里最常见的基础问题：这个服务这段时间有没有抖、有没有慢查询、有没有刚发过版。另一类是业务 SOP，由业务自己写，懂具体场景和业务接口，查的是订单状态、退款流水、支付回执这类只有业务才知道去哪里看的东西。

执行时会根据问题自动匹配需要调用的通用 Agent，如服务端根因分析要先由一个解析 Agent 从问题描述里抽出应用名和时间，再调 SRE 的根因分析接口。然后在执行业务 SOP 是另外一个 Agent，把增强问题、人工反馈、本轮 SOP 描述拼成输入，调 SOP 执行接口跑业务排查步骤，SOP 里配置的工具以 MCP 形式被调用。通用 Agent 和 SOP Agent拿到的是同一份输入，两部分结果各自成段，一并作为证据交给汇总，由汇总 Agent 对照着看。原则是业务 SOP 主导、通用 Agent 增强：SOP 决定查什么、按什么顺序查，通用 Agent 负责先把领域里的基础事实摆出来。业务写 SOP 时不用重复写这些领域判断，各领域团队也只维护一份基础能力。

汇总报告

运行时把原始工单标题和描述、本轮采用的 SOP 描述、两段执行结果，再加上这条 SOP 当前版本的原文，一起交给汇总 Agent；喂 SOP 原文是让模型对照着检查步骤有没有走完、证据够不够。返回一份约定结构的报告：标题、问题定位、排查步骤、证据支撑、排查结论、流转方式、后续步骤，运行时转成 Markdown。如果快思考当初判断信息不完整，报告开头会自动加一行「问题信息输入不完整，可能影响排障准确性」和缺失项。报告既给人看，也给下一步裁决用，不直接甩原始工具日志。

结果裁决

裁决 Agent 看到的只有三样东西：本轮汇总报告的全文、本轮 SOP 的名称，以及一份可流转的业务线清单（供「流转」动作对照）。它看不到原始工具输出、匹配阶段的候选和推理，也看不到上一轮的裁决；这些要么已经被汇总压进报告，要么和这一步的判断无关。要求模型只输出一个四字段 JSON：

{
  "credibility_status": "high | medium | low",
  "next_action": "END | TRANSFER | CONTINUE_TROUBLESHOOT | RETRY",
  "action_detail": "动作说明",
  "reasoning": "决策依据"
}

运行时拿到返回后先做归一化：next_action 统一大小写和连接符后必须命中四个枚举之一，否则这一阶段判失败；四个动作对应四种运行时行为。

• 结束、流转：任务收口，结果判定记为「AI 分析已解决」，创建反馈记录，进入等人确认。
• 继续排查：运行时把 action_detail 和 reasoning 打包成一条方向提示挂在任务上下文里，轮次加一，从匹配 SOP 重新开始。下一轮匹配 Agent 的输入里多出一节「上一轮裁决建议的方向」，和上一轮用过的 SOP、历史所有轮次用过的 SOP 列表一起送进去；匹配成功后这条提示即被清空，只影响一次匹配。轮次已到上限还要求继续，结果判定记为「AI 分析未解决」，任务按失败收口。
• 重试：不换 SOP 也不加轮次。运行时删掉本轮的汇总和裁决两条记录，从执行取证重跑；匹配记录保留，所以取证、汇总、裁决三个 Agent 拿到的仍是同一条 SOP。

流程会根据最终的裁决结果进行路由，再进行后续步骤，如果大于最大限制步骤还没有解决，当前任务将标记为结束，并通知人工介入。

人是出口，也是起点

诊断收口后默认等人。运行时创建一条反馈记录，把报告发出去：任务来自钉钉群的，往群里发一条消息，带排查结论和任务详情链接；来自工单或平台的，给创建人发一张工作通知卡片。人可以采纳、拒绝，或者补一个方向重新排障。采纳，任务记为「用户反馈已解决」；拒绝，记为「用户反馈未解决」，任务也算完成，只是结论不同；重新排障，任务重新进入执行队列，带着人写的方向回到快思考，重新组输入、重新理解整个问题。重排和慢循环里的「换方向再匹配」刻意分成两层：一层是运行时自动的，一层是人驱动的。人不确认，AI 的结论不算结案。

对接了工单系统的场景，这个出口还会和工单状态联动。客诉工单创建时，AI 先把工单标成「AI 处理中」；诊断完成，工单转到「AI 结果确认中」，失败则直接转「处理中」交给人。工单侧的采纳、拒绝、要求 AI 重新处理，都会作为事件回流到运行时，和群卡片上的动作走同一套处理。

后来才发现，SOP 库和 Skill 是同一种解法

上面反复出现的 SOP 库，内部名字叫「排障技能库」。设计这套慢思考的时候，业界还没有 Agent Skills 这个概念，我们只是把一条排查经验拆成了三样东西：一段说明适用场景的描述、一份排查步骤、一组允许调用的工具。2025 年底 Anthropic 把 Skills 定成一种约定，一个目录里放一份说明适用场景的 SKILL.md、几份参考文档和脚本，Agent 按需加载。回头对照，技能库里一条记录和一个 Skill 的结构几乎一样：靠描述被匹配，靠步骤约束执行，靠工具清单限定能做什么。我们没有预判到这个方向，只是被同一类问题推到了同一种解法上：把领域经验从 Prompt 里拿出来，做成可以单独维护、单独匹配的东西。这个巧合直接影响了后面修复层和场景接入的走向。

取舍与结果

这条链上有三个关键取舍，各对应一个当时的真实问题。

快慢分层：只在入口判断一次

所有问题都进多轮工具链，代价是延迟、成本和错误累积：常见问题几秒能答却要跑几分钟，每轮都是模型调用加多次 MCP 查询，链越长模型在证据不足时硬给结论的概率越高。只靠快思考召回历史案例，没见过的问题又只能「说思路不调工具」。两层缺一个都不行。

分层也和实现方式有关。整条链建在平台上配置的多个 Agent 之上，在当时的时间场景下一个 Agent 配置的越简单，职责越单一就越准确。所以单独抽离了快思考 Agent 挂的是知识库和历史案例，一次调用就出结果；慢思考的四个阶段各是一个 Agent，取证 Agent 挂的才是 MCP 工具组。把两类能力放进同一个 Agent，增加成本也会降低准确率，所以最终的方案是：快思考在入口判断一次，慢思考在有界循环里取证。

修复与审批：不在平台重做

方案里的审批工作流（结论经业务确认后才触发修复，结论、审批、执行各有记录）和修复层的自愈（改代码、改配置、回滚发布，由 IDE 里的 MCP 工具执行）均暂停投入了。起初是谨慎：诊断仍有不确定性，生产写操作的损失远高于多一次人工确认。真正让它们退出路线图的是 2025 年下半年通用 Agent 的变化：Cursor 这类 IDE Agent 加上 Skills 已经能读代码、改代码、调工具，且每一步天然有人确认。修复的本质是在明确根因和证据下改一处再验证，正是通用 Agent 最擅长的事，在平台里再造执行器、审批流和 IDE 联动，成本高，效果也不会更好。能在通用 Agent 里用 Skill 做好的事，就不在平台上重做。

场景接入：平台只留公共运行时

已接入的业务线跑得不错，往其他业务场景铺时瓶颈在业务侧：SOP 的质量和维护、业务数据接口的接入、有没有稳定的 Owner 持续标注和验收。这几件事平台替不了业务：排查逻辑、接口权限、数据口径和结论对错都在业务手里。所以收尾时的决定是：公共运行时保留（任务管理、状态、轮次控制、工具接入、人工出口），新场景由业务自己维护 Skill 交付，准入看频次、SOP 稳定度、工具成熟度和 Owner 是否稳定。这和修复侧的迁移是同一个判断的两面：平台只留公共运行时，领域经验以 Skill 由业务维护。

交付结果

目前普惠、租车业务线的客诉工单和值班告警两条（非开发）路径接入了这套运行时，快慢思考、SOP 匹配、MCP 取证和人工反馈闭环产品化；前端排障 Agent 接入扁鹊监控页面日报，交付发布变更分析等 6 项以上辅助能力。对已有 SOP 且工具可用的常见问题，排查耗时缩短约 50%。去年底盘点时日处理 40+，准确率达 81%+。

另一个体会和技术无关：三期的选题都来自上一期上线后业务的反馈。平台想解决真问题，得先交付一个能被使用、能被吐槽的东西，持续迭代才能有真正解决问题的产品。以上是一个前端团队在稳定性场景里的一点摸索，有不对的地方欢迎指正。