DoD Agent 完整设计文档:电商告警自动处理系统
文档说明
本文档整合了 DoD Agent 的两个设计版本:
- **v1 (2026-03-09)**:初始设计,基于纯 ReACT 架构,包含详细的技术实现
- **v2 (2026-04-03)**:重设计版本,采用状态机 + ReACT 混合架构,强调分级决策和渐进式学习
本文档结合了两个版本的精华,提供完整的设计方案和实施指南。
Part 1: 执行摘要和架构决策
1.1 项目背景
电商公司日常运维面临大量告警处理工作,包括基础设施告警、应用告警和业务告警。
当前痛点:
| 痛点 | 影响 |
|---|---|
| 告警量大(50-200条/天) | 值班人员疲劳,响应延迟 |
| 重复性问题多 | 80% 问题有标准处理流程 |
| 知识分散 | Confluence 文档难以快速定位 |
| 跨部门协作 | 告警升级和分发效率低 |
| 被动响应 | 现有 DoD Agent 仅提供查询功能 |
1.2 设计目标
重新设计 DoD Agent 为一个事件驱动的智能协调型 Agent,具备以下能力:
1 | ┌─────────────────────────────────────────────────────────────┐ |
1.3 设计原则
- 只读诊断优先:第一阶段只做诊断和建议,不执行危险操作
- 人机协作:Agent 辅助决策,关键操作人工确认
- 渐进增强:从简单场景开始,逐步扩展能力
- 可观测性:完整的日志、指标和追踪
- 状态可控:通过状态机保证流程可控、可监控、可恢复
1.4 核心架构选择
架构演进:
- v1 方案:纯 ReACT Agent(灵活但难以控制)
- v2 方案:状态机 + ReACT 混合架构(可控且智能)✅
最终选择:增强型 ReACT Agent with 状态机
- 基于现有 ReACT 框架,增加状态机管理和决策引擎
- 单体 Agent + 工具调用模式
- 状态机 + ReACT 混合工作流
- 分级自主决策 + 可配置策略
- 4阶段渐进式学习能力演进
1.5 技术选型
| 组件 | 选型 | 理由 |
|---|---|---|
| LLM | OpenAI GPT-4 / Claude-3.5-Sonnet | 推理能力强,工具调用成熟 |
| 实现语言 | Go | 现有系统技术栈,性能优秀 |
| 告警源 | Prometheus + Alertmanager | 已有系统,Webhook 集成 |
| 知识库 | Confluence + RAG | 利用现有文档 |
| 交互渠道 | Seatalk | 团队主要沟通工具 |
| 部署平台 | Kubernetes | 已有基础设施 |
| 向量数据库 | Chroma / Milvus | 本地部署,数据安全 |
| 状态管理 | 数据库 + 内存缓存 | 持久化 + 高性能 |
Part 2: 系统架构
2.1 整体架构图
1 | ┌─────────────────────────────────────────────────────────────────────────┐ |
2.2 核心组件
2.2.1 DoD Agent 核心结构
1 | type DoDAgent struct { |
2.2.2 告警上下文
1 | type AlertContext struct { |
2.3 数据流设计
1 | 告警触发 ──→ Alertmanager Webhook ──→ Gateway ──→ Alert Parser |
2.4 处理流程
1 | 告警接收 → [状态:NEW] → ReACT分析 → 决策引擎判断 → |
Part 3: 核心模块详细设计
3.1 Gateway 模块
负责统一接入和消息标准化。
1 | from dataclasses import dataclass |
3.2 Router 模块(意图识别)
根据输入类型路由到不同处理流程。
1 | class IntentType(Enum): |
3.3 Agent Core(ReACT 引擎)
基于 ReAct 模式的诊断引擎,与状态机集成。
1 | class DoDAgent: |
Part 4: 状态机和决策引擎
4.1 状态定义
1 | type AlertState string |
4.2 状态转换表
| From | To | Condition | Action | Timeout |
|---|---|---|---|---|
| StateNew | StateAnalyzing | alert != nil | 开始ReACT分析 | 30s |
| StateAnalyzing | StateAutoResolving | risk_level == Low && has_known_solution | 执行自动处理 | 5min |
| StateAnalyzing | StateWaitingConfirm | risk_level == Medium || risk_level == High | 发送确认请求 | 30s (Medium) / 无超时 (High) |
| StateAnalyzing | StateDoDNotified | risk_level == Critical | 立即升级DoD | 10min |
| StateAnalyzing | StateFailed | 分析超时或失败 | 记录失败原因 | - |
| StateWaitingConfirm | StateAutoResolving | 用户确认 && action == auto_resolve | 执行自动处理 | 5min |
| StateWaitingConfirm | StateExecutingSOP | 用户确认 && action == execute_sop | 执行SOP | 5min |
| StateWaitingConfirm | StateDoDNotified | 用户拒绝 | 升级DoD | 10min |
| StateWaitingConfirm | StateAutoResolving | 超时(仅Medium风险) | 自动执行建议操作 | 5min |
| StateAutoResolving | StateResolved | 自动处理成功 | 记录解决方案 | - |
| StateAutoResolving | StateExecutingSOP | 自动处理失败,尝试SOP | 执行SOP | 5min |
| StateAutoResolving | StateDoDNotified | 自动处理失败,无SOP | 升级DoD | 10min |
| StateExecutingSOP | StateResolved | SOP执行成功 | 记录解决方案 | - |
| StateExecutingSOP | StateDoDNotified | SOP执行失败 || 超时 | 升级DoD | 10min |
| StateDoDNotified | StateEventCreated | DoD响应超时 | 创建事件跟踪 | - |
| StateDoDNotified | StateResolved | DoD解决问题 | 记录解决方案 | - |
| StateEventCreated | StateClosed | 事件关闭 | 归档 | - |
| StateResolved | StateClosed | 人工确认关闭 OR 自动关闭(24小时无新告警) | 归档 | 24h(自动关闭) |
| StateFailed | StateDoDNotified | 需要人工介入 | 升级DoD | 10min |
| StateFailed | StateClosed | 标记为无法处理 | 归档 | - |
4.3 超时处理策略
| 状态 | 超时时间 | 超时处理 |
|---|---|---|
| StateAnalyzing | 30s | 标记失败,通知管理员 |
| StateWaitingConfirm (中风险) | 30s | 自动执行建议操作 |
| StateWaitingConfirm (高风险) | 无超时 | 持续等待人工确认 |
| StateAutoResolving | 5min | 转到ExecutingSOP或升级DoD |
| StateExecutingSOP | 5min | 标记失败,升级DoD |
| StateDoDNotified | 10min | 创建事件,升级团队负责人 |
| StateResolved | 24h | 自动关闭(如无新告警) |
注意:高风险告警的 StateWaitingConfirm 无超时机制,必须等待人工确认。
4.4 决策引擎设计
4.4.1 风险等级
1 | type RiskLevel int |
4.4.2 风险评估模型
风险评估基于以下因素的加权计算:
| 因素 | 权重 | 说明 |
|---|---|---|
| 环境 (environment) | 30% | 生产环境风险更高 |
| 严重程度 (severity) | 25% | Critical级别需要立即关注 |
| 影响范围 (impact_scope) | 20% | 多市场影响风险更高 |
| 历史模式 (historical_pattern) | 15% | 重复告警可能有已知解决方案 |
| 时间因素 (time_factor) | 10% | 高峰期风险更高 |
4.4.3 风险阈值
| 分数范围 | 风险等级 | 处理方式 |
|---|---|---|
| 0-30 | Low | 自动处理 |
| 31-60 | Medium | 建议+快速确认(30s超时) |
| 61-85 | High | 必须人工确认 |
| 86-100 | Critical | 立即升级DoD |
4.4.4 决策策略配置
1 | type DecisionPolicy struct { |
4.4.5 决策流程
1 | 1. 获取团队策略配置 |
Part 5: 工具集成和工作流
5.1 工具清单
5.1.1 现有工具(复用)
| 工具 | 功能 | 权限级别 |
|---|---|---|
get_dod_info |
获取DoD信息 | 只读 |
get_dod_by_team_id |
按团队ID查询DoD | 只读 |
get_dod_by_sub_team_name |
按子团队名称查询DoD | 只读 |
send_seatalk_message |
发送Seatalk消息 | 写入 |
create_jira_ticket |
创建Jira工单 | 写入 |
search_knowledge_base |
搜索知识库 | 只读 |
execute_sop |
执行SOP | 写入 |
5.1.2 新增工具
| 工具 | 功能 | 权限级别 | 说明 |
|---|---|---|---|
query_alert_history |
查询告警历史 | 只读 | 查询历史告警记录 |
analyze_logs |
分析日志 | 只读 | 搜索 ES/Loki 日志 |
check_metrics |
检查监控指标 | 只读 | 查询 Prometheus 指标 |
search_similar_alerts |
搜索相似告警 | 只读 | 基于相似度匹配 |
restart_service |
重启服务 | 写入(需确认) | K8s服务重启 |
clear_cache |
清理缓存 | 写入(需确认) | Redis/Memcached清理 |
update_config |
更新配置 | 写入(需确认) | 配置热更新 |
kubernetes_get |
查询 K8s 资源状态 | 只读 | Pod/Deployment/Service 状态 |
grafana_snapshot |
获取 Grafana 面板截图 | 只读 | 生成监控截图 |
5.2 工具实现示例
5.2.1 Prometheus 查询工具
1 | from typing import Dict, Any |
5.2.2 Kubernetes 工具
1 | class KubernetesTool(Tool): |
5.2.3 日志搜索工具
1 | class LogSearchTool(Tool): |
5.3 工具注册
1 | class ToolRegistry: |
5.4 告警处理工作流
1 | from enum import Enum |
5.5 咨询问答工作流
1 | class QueryWorkflow: |
Part 6: RAG 知识库系统
6.1 知识来源
1 | ┌─────────────────────────────────────────────────────────────┐ |
6.2 文档处理流水线
1 | from typing import List |
6.3 知识库更新策略
1 | class KnowledgeBaseUpdater: |
Part 7: 学习能力迭代路线
7.1 Phase 1:基础规则引擎(MVP)
时间:2-3周
目标:基于固定规则运行,不包含机器学习能力
功能:
- 基于规则的风险评估
- 预定义的自动处理规则
- 强制升级规则
- 固定的决策阈值
学习能力说明:
- Phase 1 不包含机器学习(模式识别、反馈优化、知识库自动构建)
- 所有决策基于预定义规则和配置
- 会记录处理历史数据,为Phase 2做准备
验收标准:
- ✅ 能够基于规则正确处理告警
- ✅ 准确率 > 85%(基于人工标注的测试集)
- ✅ 所有状态转换正常工作
- ✅ 决策过程可解释(能输出决策依据)
准确率定义:
- 离线测试:使用100个人工标注的历史告警作为测试集
- 标注内容:正确的风险等级、应该采取的行动
- 计算方式:(正确决策数 / 总告警数) × 100%
- 目标:> 85%
- 线上验证:灰度发布期间通过以下方式验证
- 影子模式运行,记录决策但不实际执行
- 人工抽样审查(每天抽查20条)
- 收集用户反馈(通过Seatalk交互按钮)
- 对比现有系统的处理结果
- 目标:抽样准确率 > 80%,用户负面反馈率 < 15%
7.2 Phase 2:模式识别学习
时间:4-6周
目标:从历史数据中识别告警模式,自动推荐处理方式
功能:
- 特征提取(环境、级别、文本、时间等)
- 告警聚类和模式识别
- 相似告警匹配(相似度 > 80%)
- 基于历史成功率的推荐
数据结构:
1 | type AlertPattern struct { |
验收标准:
- ✅ 能够识别重复模式
- ✅ 推荐准确率 > 75%
- ✅ 相似告警匹配准确率 > 80%
7.3 Phase 3:反馈驱动优化
时间:3-4周
目标:根据用户和DoD的反馈,动态调整决策阈值
功能:
- 收集用户和DoD的反馈
- 分析反馈模式(误判类型、频率)
- 计算最优阈值
- 渐进式调整(每次最多10%)
反馈类型:
- 决策是否正确
- 是否应该升级
- 响应时间是否合理
- 改进建议
验收标准:
- ✅ 根据反馈优化后,误判率下降 > 20%
- ✅ 阈值调整收敛(不再频繁变化)
- ✅ 用户满意度提升
7.4 Phase 4:知识库自动构建
时间:4-5周
目标:从成功的处理案例中自动生成知识库条目和SOP
功能:
- 识别值得沉淀的案例(DoD介入 + 快速解决 + 重复出现)
- 提取关键信息(问题、原因、解决方案)
- 使用LLM生成结构化知识库条目
- 自动生成SOP(如果有明确步骤)
- 待审核状态,需要人工确认
验收标准:
- ✅ 自动生成的知识库条目,人工审核通过率 > 60%
- ✅ 自动生成的SOP,可执行率 > 70%
- ✅ 知识库覆盖率提升 > 30%
7.5 迭代总结
1 | Phase 1 (2-3周): 基础规则引擎 |
Part 8: 部署和实施
8.1 Kubernetes 部署
1 | # dod-agent-deployment.yaml |
8.2 Alertmanager 配置
1 | # alertmanager.yaml |
8.3 灰度发布策略
Phase 1 部署策略:
Week 1-2: 内部测试团队(10%流量)
- 影子模式运行
- 记录决策但不实际执行
- 收集反馈和调优
Week 3: 扩大到试点团队(30%流量)
- 开始处理低风险告警
- 中高风险告警仍需人工确认
- 持续监控指标
Week 4: 全量发布(100%流量)
- 所有告警由Agent处理
- 保留人工确认机制
- 完整的监控和告警
每个阶段需要监控关键指标,出现问题立即回滚。
8.4 部署波次(渐进式接管)
注意:这里的”部署波次”与学习能力的”Phase 1-4”是不同的概念。
- 部署波次 1: 部署新系统,但不接管告警处理(仅记录日志,影子模式)
- 部署波次 2: 接管低风险告警(自动处理)
- 部署波次 3: 接管中风险告警(快速确认)
- 部署波次 4: 接管高风险告警(必须确认)
- 部署波次 5: 完全接管所有告警(包括Critical)
8.5 特性开关
使用特性开关控制新功能:
1 | type FeatureFlags struct { |
8.6 回滚计划
如果出现以下情况,立即回滚:
- 告警处理成功率 < 70%
- 误判率 > 20%
- 系统错误率 > 5%
- DoD升级率 > 40%
Part 9: 监控和可观测性
9.1 关键指标
| 指标 | 说明 | 目标 |
|---|---|---|
| 告警处理成功率 | 成功解决的告警比例 | > 85% |
| 平均处理时间 | 从接收到解决的平均时间 | < 10min |
| DoD升级率 | 需要DoD介入的比例 | < 20% |
| 误判率 | 错误决策的比例 | < 10% |
| 自动处理率 | 无需人工介入的比例 | > 60% |
9.2 监控指标实现
1 | from prometheus_client import Counter, Histogram, Gauge |
9.3 诊断质量追踪
1 |
|
9.4 日志记录
所有关键操作都需要记录结构化日志:
- 状态转换(包含原因和持续时间)
- 决策过程(风险评估、决策结果)
- ReACT循环(观察、思考、行动)
- 工具调用(参数、结果、耗时)
- 错误和异常(堆栈、上下文)
9.5 告警和通知
以下情况需要发送告警:
- 状态机超时(分析超时、SOP执行超时)
- 决策失败(无法评估风险、无法做出决策)
- ReACT循环异常(超过最大迭代次数、工具调用失败)
- 学习模块异常(Phase 2+:模式识别失败、反馈处理失败)
Part 10: 数据模型
10.1 告警状态记录
1 | type AlertStateRecord struct { |
10.2 决策记录
1 | type DecisionRecord struct { |
10.3 反馈记录
1 | type Feedback struct { |
10.4 模式记录(Phase 2+)
1 | type AlertPattern struct { |
Part 11: 配置管理
11.1 团队配置
每个团队可以独立配置:
1 | { |
11.2 全局配置
1 | { |
配置说明:
enable_learning: Phase 1 默认为false(无ML学习能力)learning_phase: 表示当前代码支持的学习阶段(1=规则引擎,2=模式识别,3=反馈优化,4=知识库构建)- Phase 2+ 部署时将
enable_learning改为true
Part 12: 扩展性设计
12.1 多部门适配
1 | class DepartmentAdapter: |
12.2 插件系统
1 | class PluginManager: |
Part 13: 安全和权限
13.1 操作权限
不同风险等级的操作需要不同权限:
| 操作 | 风险等级 | 需要权限 |
|---|---|---|
| 查询信息 | Low | 所有用户 |
| 执行SOP | Medium | Agent + 确认用户 |
| 重启服务 | High | Agent + 管理员确认 |
| 更新配置 | High | Agent + 管理员确认 |
| 升级DoD | Medium | Agent自动 |
13.2 审计日志
所有操作都需要记录审计日志:
- 操作类型和参数
- 执行者(Agent或用户)
- 执行时间和结果
- 影响范围
Part 14: 测试策略
14.1 单元测试
- 状态机转换逻辑
- 风险评估算法
- 决策引擎逻辑
- ReACT循环控制
- 工具调用
14.2 集成测试
- 完整的告警处理流程
- 状态机与ReACT的协作
- 工具集成
- 配置加载和应用
14.3 端到端测试
模拟真实告警场景:
- 低风险告警自动处理
- 中风险告警快速确认
- 高风险告警人工确认
- 严重告警立即升级DoD
- 超时处理
- 失败恢复
14.4 压力测试
- 并发告警处理能力
- ReACT循环性能
- 工具调用延迟
- 数据库查询性能
Part 15: 成本估算
15.1 LLM 成本
基于日均 100 次诊断,每次诊断平均 3 轮 Agent Loop:
| 项目 | 估算 |
|---|---|
| 每次诊断 Token | ~4000 (prompt) + ~1000 (completion) |
| 日均 Token | 100 × 3 × 5000 = 1.5M tokens |
| 月均 Token | 45M tokens |
| GPT-4 成本 | ~$1350/月($30/1M input + $60/1M output) |
| GPT-4-turbo 成本 | ~$450/月($10/1M input + $30/1M output) |
优化策略:
- 简单告警使用 GPT-3.5(成本降低 90%)
- 实现 Semantic Cache(相似问题复用)
- 优化 Prompt(减少 token 消耗)
15.2 基础设施成本
| 资源 | 规格 | 月成本(估算) |
|---|---|---|
| DoD Agent Pod | 2 × (1C/1G) | ~$40 |
| Chroma Vector DB | 1 × (2C/4G) + 50G SSD | ~$80 |
| Redis (缓存) | 1G | ~$30 |
| 合计 | ~$150/月 |
Part 16: 风险和缓解
16.1 技术风险
| 风险 | 影响 | 概率 | 缓解措施 |
|---|---|---|---|
| ReACT循环不稳定 | 高 | 中 | 严格的超时控制、最大迭代限制、完善的错误处理 |
| LLM响应延迟 | 中 | 高 | 缓存常见查询、异步处理、超时降级 |
| 决策误判 | 高 | 中 | 人工确认机制、反馈优化、渐进式部署 |
| 状态机死锁 | 高 | 低 | 超时机制、状态监控、手动干预接口 |
16.2 业务风险
| 风险 | 影响 | 概率 | 缓解措施 |
|---|---|---|---|
| 用户不信任自动决策 | 中 | 中 | 透明的决策过程、可解释的推理、人工确认选项 |
| DoD不满意自动升级 | 中 | 低 | 可配置的升级策略、反馈机制、人工审核 |
| 告警量激增 | 高 | 中 | 限流机制、优先级队列、降级策略 |
16.3 运维风险
| 风险 | 影响 | 概率 | 缓解措施 |
|---|---|---|---|
| 配置错误 | 高 | 中 | 配置校验、灰度发布、快速回滚 |
| 数据丢失 | 高 | 低 | 定期备份、主从复制、事务保证 |
| 性能下降 | 中 | 中 | 性能监控、资源预留、自动扩容 |
Part 17: 成功标准
17.1 Phase 1 成功标准
- ✅ 所有状态转换正常工作
- ✅ 决策引擎准确率 > 85%
- ✅ 告警处理成功率 > 80%
- ✅ 平均处理时间 < 15min
- ✅ 系统稳定性 > 99.9%
17.2 Phase 2 成功标准
- ✅ 模式识别准确率 > 75%
- ✅ 相似告警匹配准确率 > 80%
- ✅ 推荐采纳率 > 60%
- ✅ 告警处理成功率 > 85%
17.3 Phase 3 成功标准
- ✅ 误判率下降 > 20%
- ✅ 用户满意度提升
- ✅ 阈值调整收敛
- ✅ 告警处理成功率 > 90%
17.4 Phase 4 成功标准
- ✅ 知识库条目审核通过率 > 60%
- ✅ SOP可执行率 > 70%
- ✅ 知识库覆盖率提升 > 30%
- ✅ DoD升级率下降 > 15%
Part 18: 未来扩展
18.1 多Agent协作(未来)
当前设计是单体Agent,未来可以扩展为多Agent协作:
- Alert Analyzer Agent: 专门分析告警
- SOP Executor Agent: 专门执行SOP
- DoD Coordinator Agent: 专门协调DoD
- Knowledge Builder Agent: 专门构建知识库
18.2 跨团队协作(未来)
支持跨团队的告警处理和DoD协调:
- 自动识别告警涉及的多个团队
- 协调多个团队的DoD
- 跨团队的知识共享
18.3 预测性告警(未来)
基于历史数据和机器学习,预测可能发生的告警:
- 趋势分析
- 异常检测
- 提前预警
总结
DoD Agent 通过 AI 能力增强运维效率,核心价值:
- 降低 MTTR:自动诊断减少人工分析时间
- 知识沉淀:将专家经验转化为可检索知识
- 标准化处理:常见问题自动化处理流程
- 可控性:状态机保证流程可控、可监控、可恢复
- 学习能力:从历史数据和反馈中持续学习和优化
- 可扩展:插件化设计支持多部门复用
第一阶段聚焦只读诊断 + 基础规则引擎,验证价值后再逐步扩展学习能力和自动化操作能力。
附录
术语表
| 术语 | 说明 |
|---|---|
| DoD | Developer on Duty,值班开发人员 |
| ReACT | Reasoning and Acting,推理-行动循环 |
| MCP | Model Context Protocol,模型上下文协议 |
| SOP | Standard Operating Procedure,标准操作流程 |
| LLM | Large Language Model,大语言模型 |
| RAG | Retrieval-Augmented Generation,检索增强生成 |
参考文档
变更历史
| 版本 | 日期 | 作者 | 变更说明 |
|---|---|---|---|
| 1.0 | 2026-03-09 | AI Planner Team | v1 初始版本(纯ReACT架构) |
| 2.0 | 2026-04-03 | AI Planner Team | v2 重设计版本(状态机+ReACT混合架构) |
| 2.0-merged | 2026-04-03 | AI Planner Team | 合并v1和v2,创建完整设计文档 |
文档结束