阿里故障复盘 Agent 系统
学习来源：别让故障复盘流于形式：用AI挖掘每一次"跌倒"的价值 | 原始链接：https://www.bestblogs.dev/article/b68d8384
一、故障复盘的业务思考
技术支持工作的本质目标是帮助业务方做好稳定性，提升 C 端用户体验，主张 blameless（无责） 的复盘文化。
复盘的核心价值在于：
- 准确深度发现当前系统的风险，并推动闭环解决
- 举一反三：将未发生故障但存在同样风险的系统也实现真正规避
- 数据资产沉淀：复盘结果作为稳定性工作的方向输入，经验不足的研发可从历史故障中学习故障树 FTA 路径、恢复手段和关键决策
复盘实操难点
- 变更操作导致的故障，当事人不太愿意深度编写原因
- 链路长的故障，各层都不愿串联整个过程
- 人性因素：故障恢复后报告从简，深入讨论要"写出来不是我的问题"
- 技术支持对技术理解力和稳定性领域知识不足，难以提出架构层面的关注点
- 开发认为技术支持不懂技术，即便提出真问题也不愿深入沟通
AI 赋能思路
借助 AI 的识别与生成和推理与规划能力解决复盘的专业性和深度问题，提供以下核心能力：
- 生成故障概述、时间线、影响面：连接监控和变更系统，提升事中信息协同效率
- 故障原因理解 → 生成故障树分析 FTA：生成更专业和深度的关注点
- 故障多维度标签化 + 复盘数据结构化：形成有效的数据资产
- 识别风险 → 系统健康中心：可视化产品线/业务线的系统健康度
- 故障问答：自然语言交互搜索、统计、分析故障相关信息
- 深挖共性风险：AI 的强项
二、智能复盘 Agent 整体介绍
目标用户
- SRE 团队
- DevOps 工程师
- 技术支持
- 业务稳定性负责人
AI 工具不是要替代工程师，而是要放大工程师的智慧。
核心价值
将传统的"人工填空题"转变为"AI 辅助的深度分析"。
智能复盘功能全景
- 全景数据聚合：自动从应急群聊（钉钉等）、在线会议、应急平台拉取所有相关信息
- 一键智能生成：故障恢复后自动/手动触发，生成覆盖"故障概述、时间线、影响面"的报告初稿
- 对话式深度挖掘：用户可追问，故障原因 Agent、关注点 Agent、改进措施 Agent 协同分析
- 情景化知识增强：结合模型上下文与内部知识（领域术语库、历史复盘文档知识库）
- 闭环式资产沉淀：报告归档后作为结构化知识沉淀到知识库
三、核心技术架构
3.1 Multi-Agent 协作架构
以"故障复盘 Multi-Agent"为核心，通过多个角色型 Agent 协作完成复盘任务的编排、意图识别与执行。
核心组件：
- Plan Agent：解析用户意图，决策是 Ask 任务还是专业 Agent 任务
- Task Expert（任务专家 Agent）：被委派执行深度挖掘，自主多轮与底层服务交互
- Report-Composer：收集所有碎片化结论和证据，整合成逻辑清晰、有理有据的回答
3.2 复盘时序流程
- 提问与规划：用户通过 Web UI 提问，Plan Agent 解析意图
- 编排与委派：将每个子任务精准委派给相应能力的 Task Expert
- 专家执行与深度交互：调用外部 API 获取实时数据，查询 RAG 知识库，请求大模型进行复杂逻辑推理
- 整合与响应：Report-Composer 模块整合所有结论，最终呈现给用户
四、核心技术实现
4.1 数据采集与预处理
挑战：多源异构数据存在格式不统一、表达方式多样、信息密度不均等问题。
目标：构建统一的故障数据层，赋能高效、精准的根因分析（RCA）。通过智能降噪、语音校准、多模态信息融合等预处理流程，将原始数据转化为包含"Who, When, Where, What"等要素的结构化统一事件流。
4.2 Memory 管理机制
对于 LLM 来说，记忆不是越多越好，而是要记得住关键，忘得掉干扰。
在多轮、长流程的故障复盘任务中，Agent 的上下文会迅速膨胀，可能导致 Token 溢出、关键信息被淹没、推理链断裂。
通用 Agent vs 智能复盘 Agent 的 Memory 差异
| 维度 | 通用 Agent | 智能复盘 Agent |
|---|---|---|
| 任务性质 | 单流程、单目标、交互独立 | 长流程、多阶段、强依赖历史抉择 |
| 上下文来源 | 用户输入+少量工具调用 | 多轮对话+应急系统日志+会议记录+多次工具调用 |
| 信息体量 | 百~千 Token 级 | 动辄数万 Token |
| 记忆粒度 | 关键意图/实体提取 | 需保留事件时序、因果链、责任归属等结构化线索 |
| 噪音比例 | 相对较低 | 极高（会议记录中大量口语化、重复、无关讨论） |
Memory 管理三步法
- 去噪：预处理阶段剔除冗余和噪声数据
- Summary（提要）：采用 ConversationBufferSummary 方式，当 Token 超过阈值，调用专门 LLM 将冗长对话历史提炼成结构化摘要，完整保留最近 N 条上下文和 System Prompt
- 保鲜：重要指令（System 消息、用户核心需求）重新注入模型记忆范围，防止被"遗忘"
8 段式 Summary 结构（模拟 SRE 复盘思维）：
- Primary Request and Intent（主要请求和意图）
- Key Technical Concepts（关键技术概念）
- Files and Code Sections（文件和代码片段）
- Errors and Fixes（错误和修复）
- Problem Solving（问题解决过程）
- All User Messages（所有用户消息）
- Pending Tasks（待处理任务）
- Current Work（当前工作状态）
4.3 意图识别：通用 Agent → 多 Agent 分流与嵌套
通用 Agent 的问题
- 工具混杂与提示词膨胀
- 交互风格难以兼顾（口语化交流 vs 专业化内容生产）
- 可维护性与可观测性差
- 成本与稳定性矛盾
多 Agent 体系设计
- 入口分流：Chat 模式 vs Work 模式，通过少样本意图识别自动路由
- ChatAgent：聚焦沟通与轻量分析，口语化系统提示词
- WorkAgent：聚焦任务执行与专业化产出，面向复盘的分析和数据聚合工具
- Agent 嵌套：将同一领域的工具与上下文聚合为独立"业务 Agent"，通过 selectAgent 在外层统一包装
4.4 Agent 动态页面交互界面
通用 Agent 交互问题
- 输出形态：整个推理过程折叠为单次或少量文本消息流，过程不可见
- 会话管理：以内存或简单持久化为主，消息生产和消费耦合
- UI 交互：纯文本为主，缺乏对前端组件的原生支持
智能复盘 Agent 的三大交互能力
- 流式交互的 Step 级执行与曝光控制：每个 step 完成后以流方式返回前端，通过显式可见性控制区分"可透出内容"和"内部隐私内容"
- 基于缓存的会话管理（生产者/消费者模式）：Agent 执行过程中将消息追加式写入缓存，前端聊天渲染侧按需读取并全量渲染，实现时序一致性、曝光粒度可控、异步与弹性
- 灵活 UI 交互（前端组件封装为 Tool）：将预开发的前端组件以"工具"形式注册给模型使用，识别"组件 JSON"后动态渲染卡片、表格、图表、表单、流程确认等高级交互
4.5 RAG 知识增强
在阿里巴巴大量私域知识环境下，RAG 至关重要：
- 私域知识缺失：企业特有的技术架构、业务流程、专有名词等信息不在通用大模型训练数据中
- 生成内容幻觉：缺乏准确知识支撑，模型可能产生与事实不符的臆测内容
知识增强闭环：知识发现 → 沉淀至专属知识库 → 通过 RAG 检索精准上下文 → 应用于后续复盘
4.6 评测机制
智能复盘 Agent vs 通用 Agent 评测差异
| 维度 | 通用 Agent | 智能复盘 Agent |
|---|---|---|
| 评估重点 | 答案正确性、响应速度 | 洞察深度、逻辑完整性、改进建议可执行性 |
| 输出形式 | 单轮、短文本 | 多模块长文档（时间线、根因、关注点等） |
| 标准答案 | 明确（如 FAQ 库） | 多解、开放 |
| 价值判断 | 是否"答对了" | 是否"挖的深""提的准""改得动" |
评测体系演进
| 阶段 | 方法 | 问题 |
|---|---|---|
| 第一阶段 | ROUGE/BLEU（词汇重合度） | AI 靠堆砌常用词汇"得高分"，但关注点采纳率不高 |
| 第二阶段 | BERTScore（向量语义相似） | 评分普遍较高，无法区分"表面相关"与"深度匹配" |
| 第三阶段 | LLM-as-Judge（让大模型做裁判） | 对"编造但听起来合理"的内容打分高 |
| 第四阶段 | 业务价值导向打分 | 结合"标准答案关注点"+"AI 生成关注点"+"复盘文档原文"，从洞察深度、逻辑完整性、可执行性、证据支撑四个维度打分 |
4.7 提示词调优历程
V1 - 泛化生成（期望 AI 靠"常识"输出价值）
让大模型理解故障背景后自动生成关注点。问题：Prompt 没有约束，AI 自由发挥，靠"常识"拼凑答案，关注点描述太泛。
V2 - 增加聚焦风险标签
引入风险标签库（容灾架构、高可用、可扩展性等），用规则"框住"AI。问题：大模型生搬硬套，没有架构问题也要吹毛求疵；忽略实际系统情况，强调时间上的不合理。
V3 - 工程化尝试（仍未跳出标签陷阱）
将标签库领域拆分为 5 个独立子集，并行调用各模型实例专注特定领域。问题：标签无法完全穷举，更新维护成本高；存在强行匹配现象。
V4 - 摒弃风险标签，回归问题本质
核心优化：
- 两阶段拆解：第一阶段 AI 从多维度提出具体问题（包含服务名、接口、配置项等实体），第二阶段严格基于文档分析原因和改进
- 摒弃标签库：将分类动作后置，让 AI 自由聚焦真实问题
- 鼓励上下文引用：要求问题包含具体实体，分析引用日志、配置、调用链等证据
- 防幻觉机制：若信息不足，【问题分析】和【改进措施】直接置空，宁可不说，不可乱说
五、实战案例：Agent 赋能各角色
5.1 技术支持视角
- 故障结束实时获取报告初版（P4/P5 可在 2~3 天 → 1 天内完成）
- 通过 Agent 生成故障关注点和改进措施，关注点采纳率 60%+
- 从"信息整合者"升级为"风险挖掘者"
5.2 研发视角
- Agent 自动生成初版复盘文档作为事实依据库，避免"凭记忆写复盘"
- 通过 Agent 进行故障原因质量分析，自动识别缺失维度并给出补全建议
- 发现分析盲区，提升故障原因质量下限
5.3 普通用户视角
- Agent 自动提取简洁、可读性强的故障摘要，10 秒内掌握全局
- 生成可视化故障链路时序图
- 提供可视化故障树（FTA 图），以自顶向下方式展示根因链
六、核心要点总结
- Blameless 文化：故障不是一个"如果"的问题，而是一个"何时"的问题，拥抱风险，理性客观解除风险
- Multi-Agent 架构：通过 Plan Agent + Task Expert + Report-Composer 协作，实现深度分析与结构化输出
- Memory 管理三步法：去噪 → Summary 提要 → 保鲜，确保 Agent 在复杂任务中"不迷路、不遗忘、不超载"
- 意图识别分流：Chat 模式处理沟通答疑，Work 模式处理专业化任务执行
- 提示词演进：从泛化生成 → 标签约束 → 两阶段拆解，本质是从"教 AI 该说什么"到"让 AI 真理解问题"
- 评测方法：无银弹，需结合相似性指标（监控退化）+ 业务价值导向打分（衡量优化效果）