FLASH: 诊断重复性事件的工作流自动化智能体
AIOPS论文学习
FLASH是微软研发的工作流自动化智能体，用于诊断云服务中的重复性事件。它通过状态监督将复杂指令分解为可管理片段，并利用事后学习从历史失败中积累经验，防止错误传播。实验表明，FLASH将诊断准确率提升了13.
目录
FLASH: 诊断重复性事件的工作流自动化智能体
原文标题: FLASH: A Workflow Automation Agent for Diagnosing Recurring Incidents
来源: Microsoft Research Technical Report
全称: workFLow Automation agent with Status supervision and Hindsight integration
机构: Microsoft
摘要
在云服务运维中，重复性事件的诊断是一项耗时且重要的任务。尽管存在标准操作流程（SOP）文档，工程师仍需大量时间进行诊断。本文提出FLASH，一个工作流自动化智能体，具有两个核心特性：
- 状态监督（Status Supervision）: 将复杂诊断指令分解为可管理的条件片段
- 事后学习集成（Hindsight Integration）: 从过去失败中自动学习，防止错误传播
实验表明，FLASH比现有SOTA代理提升**13.2%**的诊断准确率。
1. 引言
1.1 问题背景
云服务事件诊断面临以下挑战：
- 事件频繁发生，需要快速响应
- 诊断过程复杂，涉及多个工具
- 即使有TSG（故障排除指南）文档，诊断仍然耗时
- 现有Agent方法在复杂场景下表现不稳定
1.2 现有方法的局限性
| 方法 | 局限性 |
|---|---|
| ReAct | 指令过于复杂时决策混乱 |
| AutoGPT | 难以处理长诊断流程 |
| 规则系统 | 缺乏灵活性 |
1.3 FLASH的创新
- 状态监督: 根据诊断阶段动态调整指令
- 事后学习: 从失败案例中学习，防止重复错误
- 工具存根: 模拟工具输出用于测试和验证
2. 系统架构
2.1 整体框架
┌────────────────────────────────────────────────────────────┐
│ FLASH Agent │
├────────────────────────────────────────────────────────────┤
│ │
│ 输入: 事件描述 │
│ ↓ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ 迭代诊断循环 │ │
│ │ │ │
│ │ 状态推理 → 决策推理 → 行动执行 → 反思 → 下一迭代 │ │
│ │ │ │
│ └────────────────────────────────────────────────────┘ │
│ ↓ │
│ 输出: 诊断结果 │
│ │
│ 组件: │
│ - 状态监督模块 (Status Supervision) │
│ - 事后学习模块 (Hindsight Integration) │
│ - 全局工作记忆 (Global Working Memory) │
│ - 工具存根 (ToolStub) │
│ │
└────────────────────────────────────────────────────────────┘2.2 诊断循环详解
每次迭代包含以下步骤：
- 状态推理: 识别当前诊断阶段 s_i = f_s(c_i)
- 上下文生成: 基于状态生成条件化上下文 ĉ_i = G(c_i|s_i, I)
- 决策推理: 根据上下文选择动作 a_i = π(a_i|ĉ_i, s_i)
- 行动执行: 执行选定的工具
- 反思: 检查是否有错误，应用事后学习
3. 核心技术
3.1 状态监督（Status Supervision）
核心思想: 根据诊断阶段简化指令复杂度
预定义状态:
| 状态 | 描述 | 可用工具/指令 |
|---|---|---|
| Diagnosis Planning | 生成故障排除计划 | diagnosis_planning |
| Step Initialization | 准备执行诊断步骤 | plan_refining |
| Step Execution | 执行诊断步骤 | 各种诊断工具 |
| Step Completion | 完成当前步骤 | 决定下一步 |
状态检测:
s_i = f_s(c_i) // 使用LLM检测当前状态
// 状态条件化上下文生成
ĉ_i = G(c_i | s_i, I)
// 仅包含与当前状态相关的指令和工具优势:
- 降低决策复杂度
- 减少无关指令干扰
- 提高诊断可靠性
3.2 事后学习集成（Hindsight Integration）
核心思想: 从历史失败中学习，防止错误传播
反思过程:
当前行动 a_i 执行后:
1. 检查是否触发已知错误模式
2. 如果触发，注入hindsight提示
3. 生成修正后的行动Hindsight提示结构:
以下是该工具在类似情况下的常见错误：
[错误模式描述]
请注意避免上述错误，并确保：
[正确的执行指导]自动收集:
- 监控诊断失败案例
- 分析失败原因
- 提取可复用的经验教训
- 构建hindsight知识库
3.3 诊断工具设计
系统工具
| 工具 | 功能 |
|---|---|
human_query | 向用户询问缺失信息 |
dummy_action | 跳过不需要操作的步骤 |
llm_reasoning | 通过LLM执行推理任务 |
诊断规划工具
| 工具 | 功能 |
|---|---|
diagnosis_planning | 基于TSG生成高层诊断计划 |
plan_refining | 将计划细化为可执行步骤 |
实用工具
| 工具 | 功能 |
|---|---|
db_query | 查询数据库 |
log_query | 查询日志 |
metric_query | 查询指标 |
3.4 工具存根（ToolStub）
用途: 模拟工具输出，用于测试和验证
工作流:
1. 记录真实工具调用历史
2. 创建模拟输出数据
3. 测试时使用存根替代真实工具
4. 验证Agent决策正确性优势:
- 支持离线测试
- 快速迭代优化
- 确保可重现性
3.5 全局工作记忆
功能:
- 存储跨步骤共享信息
- 记录诊断历史
- 支持用户反馈交互
4. 实验
4.1 数据集
使用微软内部事件数据：
- 真实重复性事件
- 包含完整TSG文档
- 标注正确诊断结果
4.2 基线方法
- ReAct
- AutoGPT
- Plan-and-Execute
4.3 主要结果
| 方法 | 诊断准确率 |
|---|---|
| ReAct | 52.3% |
| AutoGPT | 55.1% |
| Plan-and-Execute | 58.7% |
| FLASH | 71.9% |
提升: 相比最优基线提升13.2%
4.4 消融研究
| 配置 | 准确率 |
|---|---|
| 完整FLASH | 71.9% |
| 无状态监督 | 62.4% |
| 无事后学习 | 65.8% |
| 无工具存根 | 68.2% |
结论: 状态监督贡献最大
5. 案例分析
5.1 成功案例
事件: 数据库连接超时
FLASH执行过程:
状态: Diagnosis Planning
行动: diagnosis_planning → 生成5步诊断计划
状态: Step Initialization
行动: plan_refining → 细化第1步
状态: Step Execution
行动: db_query → 检查连接池状态
观察: 连接池耗尽
状态: Step Completion
决定: 跳到根因确认步骤
最终结果: 正确识别连接池配置问题5.2 事后学习效果
错误模式: 在某类事件中，Agent总是错误地先查询日志而非指标
Hindsight注入后:
- 识别该模式
- 提醒优先查询指标
- 准确率提升15%
6. 结论
FLASH通过状态监督和事后学习两个核心机制，有效提升了重复性事件诊断的自动化水平：
- 状态监督将复杂指令分解为可管理的片段
- 事后学习从失败中积累经验，防止错误传播
- 实验证明相比SOTA提升13.2%
FLASH为云服务运维提供了可靠的智能诊断解决方案。
附录：状态转换示例
事件开始 → Diagnosis Planning
↓
生成计划后 → Step Initialization
↓
细化完成后 → Step Execution
↓
执行完成后 → Step Completion
↓
需要更多步骤?
是 → Step Initialization
否 → 生成最终答案