阿里故障复盘 Agent 系统

学习来源：别让故障复盘流于形式：用AI挖掘每一次"跌倒"的价值 ｜ 原始链接：https://www.bestblogs.dev/article/b68d8384 文中效果数字（采纳率、耗时缩短）均归属该来源。

业务问题

技术支持的目标是帮业务方做好稳定性，主张 blameless（无责） 复盘文化。复盘实操的难点：当事人不愿深写原因、长链路无人串联、恢复后报告从简、技术支持难以提出架构层关注点。

AI 赋能的核心能力：生成故障概述/时间线/影响面（连接监控与变更系统）、生成故障树分析 FTA、复盘数据结构化沉淀、风险识别与可视化、故障问答、深挖共性风险。

Multi-Agent 架构

以「故障复盘 Multi-Agent」为核心：

• Plan Agent：解析用户意图，决策是 Ask 任务还是专业 Agent 任务
• Task Expert（任务专家 Agent）：被委派执行深度挖掘，自主多轮与底层服务交互
• Report-Composer：收集碎片化结论与证据，整合成有理有据的回答

时序：用户 Web UI 提问 → Plan Agent 解析意图 → 子任务委派给 Task Expert → 专家调 API / 查 RAG 知识库 / 大模型推理 → Report-Composer 整合响应。

Memory 管理三步法

长流程复盘任务中 Agent 上下文迅速膨胀（多轮对话 + 应急日志 + 会议记录，动辄数万 token，噪音极高）。原则：记得住关键，忘得掉干扰。

1. 去噪：预处理剔除冗余与噪声
2. Summary 提要：token 超阈值时用专门 LLM 把冗长历史提炼为结构化摘要，保留最近 N 条上下文与 System Prompt。采用 8 段式结构（模拟 SRE 复盘思维）：主要请求与意图 / 关键技术概念 / 文件与代码 / 错误与修复 / 问题解决过程 / 所有用户消息 / 待处理任务 / 当前工作状态
3. 保鲜：重要指令（System 消息、核心需求）重新注入记忆范围，防止遗忘

意图识别与交互

入口分流：Chat 模式（沟通答疑，口语化提示词）vs Work 模式（专业化产出），少样本意图识别自动路由；同一领域工具聚合为独立「业务 Agent」，外层 selectAgent 统一包装——解决单 Agent 工具混杂、提示词膨胀、可维护性差的问题。

三大交互能力：step 级流式执行与曝光控制（区分可透出/内部内容）；基于缓存的生产者/消费者会话管理（追加写入、按需读取）；前端组件封装为 Tool（识别「组件 JSON」后动态渲染卡片、图表、表单）。

评测机制

通用 Agent 评测（答案正确性）不适用——复盘的价值判断是「挖得深、提得准、改得动」。评测体系四阶段演进：

阶段	方法	问题
一	ROUGE/BLEU 词汇重合	堆砌常用词得高分，采纳率不高
二	BERTScore 语义相似	分数普遍偏高，区分不了表面相关
三	LLM-as-Judge	对「编造但听起来合理」的内容打分高
四	业务价值导向打分	结合标准答案关注点 + AI 生成关注点 + 复盘原文，从洞察深度、逻辑完整性、可执行性、证据支撑四维打分

提示词四轮演进

1. V1 泛化生成：无约束靠常识输出 → 关注点太泛
2. V2 风险标签：标签库框住 AI → 生搬硬套、吹毛求疵
3. V3 标签拆分：5 个子集并行 → 标签无法穷举、维护成本高
4. V4 回归问题本质：两阶段拆解（先提具体问题含服务名/接口/配置项实体，再严格基于文档分析）；摒弃标签库，分类后置；要求引用日志/配置/调用链证据；防幻觉——信息不足时宁可直接置空，宁可不说，不可乱说

核心要点

1. Blameless 文化是前提，AI 放大工程师的智慧而非替代
2. Plan + Task Expert + Composer 的 Multi-Agent 分工支撑深度分析与结构化输出
3. Memory 三步法（去噪 → Summary → 保鲜）保证长流程不迷路、不遗忘、不超载
4. 评测无银弹：相似性指标监控退化 + 业务价值导向打分衡量优化效果
5. 提示词演进的本质：从「教 AI 该说什么」到「让 AI 真理解问题」