thaocao1/incident-response-agent

# 事件响应 Agent LangGraph 多智能体系统，可自主调查真实的基础设施事件——监控实时的 Prometheus 告警，查询 kubectl，交叉比对 runbook，并在采取任何修复措施之前，通过 human-in-the-loop 检查点生成结构化的事件报告。 ## 为什么会有这个项目 事件调查遵循着一个可重复的模式：告警触发，运维人员检查指标，阅读日志，交叉比对 runbook，与近期的变更进行关联，撰写报告。这个 Agent 做的也是同样的事情——只不过它调用的工具是真实的，所在的集群是真实的，而且错误调用工具带来的后果也是真实的。 平均调查时间：**约 3 分钟**（而人工基线为 15 分钟）。 ## 架构 ``` ┌──────────────────┐ │ Prometheus Alert │ └────────┬─────────┘ │ ▼ ┌─────────────────────────┐ │ ALERT_RECEIVED │ │ Parse, classify, │ │ set severity │ └────────┬────────────────┘ │ ▼ ┌─────────────────────────┐ │ TRIAGE │ │ PromQL deep-dive, │ │ scope blast radius │ └────────┬────────────────┘ │ ▼ ┌─────────────────────────┐ │ INVESTIGATE │ │ kubectl logs/describe,│ │ recent deployments │ └────────┬────────────────┘ │ ▼ ┌─────────────────────────┐ │ CORRELATE │ │ Runbook lookup (RAG), │ │ change correlation │ └────────┬────────────────┘ │ ▼ ┌─────────────────────────┐ │ REMEDIATE (gated) │◄── Human-in-the-loop │ Proposed action + │ checkpoint. Agent │ rollback plan │ STOPS here until └────────┬────────────────┘ operator approves. │ ▼ ┌─────────────────────────┐ │ REPORT │ │ Structured markdown, │ │ timeline, root cause │ └─────────────────────────┘ ``` ## 工具 | 工具 | 功能 | 安全性 | |------|-------------|--------| | `promql_query` | 针对 Prometheus 执行 PromQL | 只读 | | `kubectl_get` | kubectl get/describe/logs | 只读 | | `kubectl_restart` | kubectl rollout restart | **受控**——需要人工批准 | | `runbook_search` | 通过 psap-rag-engine API 进行 RAG 检索 | 只读 | | `recent_deploys` | 查看近期 Helm/ArgoCD 变更的 Git log | 只读 | | `alert_history` | 查询 Alertmanager 获取关联告警 | 只读 | ## 关键设计决策 - **默认只读。** 只有 `kubectl_restart` 可以更改状态，并且它需要通过检查点获得明确的人工批准。 - **真实工具，而非模拟。** 该 Agent 查询的是实时的 RKE2 集群和实时的 Prometheus。如果它构建了错误的 PromQL 查询，它会收到报错并自我纠正——这些自我纠正的情况都已记录在案。 - **Runbook 集成。** CORRELATE（关联）阶段会调用 [psap-rag-engine](../psap-rag-engine) API 来检索相关的 runbook 部分。该 Agent 不仅仅是进行调查；它还会将调查结果与已记录的流程联系起来。 - **结构化 trace。** 每次工具调用、每次状态转换、每次 LLM 决策都会记录到 Langfuse 中。这些 trace 与报告一样有价值。 ## 已记录的失败模式 | 场景 | 发生情况 | 解决方式 | |----------|-------------|------------| | Prometheus 无法访问 | Agent 重试 3 次，然后使用现有数据报告降级的调查结果 | 自动 | | 格式错误的 PromQL | Agent 收到报错，重新构建查询（已记录的自我纠正） | 自动 | | kubectl 超时 | Agent 记录超时，跳至下一步调查步骤 | 自动 | | Runbook API 宕机 | Agent 在不进行 runbook 关联的情况下继续执行，并在报告中标记缺失 | 自动 | | Agent 建议了错误的修复方案 | human-in-the-loop 检查点会在执行前捕获它 | 设计使然 | ## 运行 ``` # 前提条件：访问配置了 Prometheus 的 K8s 集群，Python 3.11+ cp .env.example .env # Configure cluster access, Prometheus URL, LLM API key pip install -r requirements.txt python -m agent.main --watch # Continuous alert monitoring mode # 或触发单个调查 python -m agent.investigate --alert "PodCrashLoopBackOff" --namespace production ``` ## 演示（3 分钟） 1. 终止一个 pod：`kubectl delete pod nginx-xxx -n demo` 2. Prometheus 中触发告警 3. Agent 接收告警，进行分类、调查（kubectl logs, PromQL），并与 runbook 进行关联 4. Agent 提出修复方案 + 回滚计划，等待批准 5. 生成包含时间线、根本原因和 trace 链接的报告 ## 项目状态 | 阶段 | 状态 | |-------|--------| | LangGraph 状态机 | 进行中 | | 工具实现 | 进行中 | | Human-in-the-loop 检查点 | 计划中 | | Langfuse 集成 | 计划中 | | 自我纠正文档 | 计划中 | | 演示视频 | 计划中 | *属于 [public-sector-ai-reference-arch](../public-sector-ai-reference-arch) 作品集的一部分。调用 [psap-rag-engine](../psap-rag-engine) 进行 runbook 检索。另请参阅：[airgap-llm-framework](../airgap-llm-framework)*

标签：AIOps, LangGraph, PyRIT, 多智能体系统, 子域名突变, 库, 应急响应, 自定义请求头, 运维自动化, 逆向工具