凌晨 2 点，K8s 集群 Pod 反复重启，告警群炸了。你登录服务器、查日志、定位根因、手动重启——40 分钟后服务恢复。第二天同样的告警又来了一次。
这个项目要解决的问题是：让 AI 完成“查状态 → 分析日志 → 执行修复 → 验证结果”的推理闭环，人只需要在高危操作前点一次“批准”。
项目地址：GitHub - scwjsdgs/AiOps: 基于 AI Agent + Spring Boot + Vue 3 的智能运维平台，实现告警自动分析、根因定位与修复执行的全链路闭环。 · GitHub
从 0 到 1 构建生产级 AIOps 平台：LangGraph 与 RAG 的深度实战闭环
💡 引言在云原生时代，传统的“告警触发 -> 人工排查 -> 手动修复”运维模式链路长、响应慢、极易出错。本文将分享一套基于Python LangGraph 多智能体与 Java Spring WebFlux构建的生产级 AIOps 智能运维平台。
系统不仅实现了从底层 Prometheus 告警到 K8s 自动修复的全自动闭环，更重点解决了企业级落地中的三大痛点:大模型幻觉控制、高危操作安全拦截、以及外部依赖崩溃时的系统级降级。
🏗️ 一、 核心架构设计
系统采用“决策与执行分离”的异构架构，确保 AI 物理上无法越权直接操作集群：
1. Java 中枢网关：负责高并发告警接入、降噪聚合、工具白名单校验、真实 K8s 执行与 WebSocket 推送。
2. Python AI 大脑：基于 LangGraph 构建状态机，负责多智能体协同推理、RAG 检索与反思审阅。
3. 双层安全防线：模型只能调用 Java 暴露的只读工具；涉及写操作（如重启、回滚）必须触发 `interrupt()` 挂起，等待人类审批。
🛡️ 二、 生产级高可用与容错机制（核心亮点）
在真实的运维场景中，AI 系统必须比传统脚本更“抗造”。
1. 物理级工具白名单 (Tool Allow-list)
系统严禁大模型拥有任意命令执行能力。即使发生提示词注入攻击，AI 也只能调用白名单内的安全工具。诸如 `generic_command` (任意 Shell 执行) 等高危工具，被永久隔离在 AI 权限之外，仅限人类在控制台手工执行。
2. 强制人机协同与 Fail-Closed 兜底
涉及扩缩容、回滚等写操作时，LangGraph 会触发 `interrupt()`，将图状态持久化至 Checkpointer 挂起。
实测数据：在模拟告警风暴场景下，系统瞬间积压了 **81 个待审批请求**。
兜底表现：系统严格执行 55 秒超时机制，**自动拒绝了 82 次超时的高危操作**。宁可放弃修复，也绝不带着风险执行变更。
3. 大模型级联降级验证 (Cascading Fallback)
由于外部 LLM 接口存在网络抖动或欠费风险，系统设计了多级降级策略：
Rerank 精排失败？降级使用 RRF 融合粗排。
Query 改写失败？降级使用原句检索。
Reflection 审阅失败？默认放行，保证主流程流转。
在实测中，当阿里云 API 突发 401 欠费报错时，系统依靠本地向量库与 DeepSeek 主模型，依然成功输出报告，并且大模型严格遵守了防幻觉约束，回答：“*证据不足，不予提供，也不编造*”。
🧠 三、 工业级 RAG 与自学习闭环
单纯的“向量检索”不足以支撑复杂的运维场景。
双路召回流水线：Query 改写 -> BM25 关键词 + Chroma 向量双路召回 -> RRF 融合 -> Rerank 精排 Top3。
文本切分策略：采用 `RecursiveCharacterTextSplitter`，按 500 字符切分，重叠 50 字符，防止语义截断。
案例自学习机制：每一次诊断闭环完成后，系统会自动将本次故障报告 Embedding 进 Chroma 案例库；下次遇到相似告警时，Agent 优先检索历史经验，实现系统越用越聪明。
💻 四、 核心排错实战记录
1. 惊险的“孤儿 ToolMessage”报错
在 LangGraph 多轮工具调用中，如果滑动窗口裁剪 (`trim_messages`) 逻辑不当，极易把 `AIMessage(tool_calls)` 和紧随其后的 `ToolMessage` 切断，导致大模型报错：`Messages with role 'tool' must be a response to a preceding message with 'tool_calls'。
解决方案：
在子图节点清洗阶段增加成对校验逻辑，自动过滤孤儿消息；同时在 `Send` 分发并行子图时，隔离局部状态（从干净的 System/Human 消息开始），确保上下文绝对干净。
2. 统计噪声导致的预测性误报
系统基于 `μ±3σ` 算法做基线预测时，曾遇到底层系统组件 `local-path-provisioner` 因为偶发调度导致 CPU 从 0.0012 核跳到 0.0347 核，触发严重警报。
AI 表现：Agent 综合了日志、K8s 事件与历史数据，不仅判定出这是“统计噪声”，甚至顺带查出了监控工具因命名空间传错导致的“查无此服务”的 Bug，主动放弃了无意义的修复。
🛠️ 五、 本地快速启动指南
1. 拉起基础依赖 (MySQL/Redis/K8s)
docker compose up -d
kind create cluster --config kind-config.yaml
bash apply-monitoring.sh
2. 启动 Java 中枢 (端口 8081)
cd ops_agent && ./mvnw spring-boot:run
3. 启动 Python 大脑 (端口 5000)
cd aiops-agent && python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt && uvicorn main:app --reload
4. 启动前端控制台 (端口 3000)
cd ops-agent-front && npm install && npm run dev
🔮 六、 后续演进规划
MCP Server 网关：将现有的 Java 工具网关封装为标准的 Model Context Protocol (MCP) Server，支持多端复用与动态工具发现。
