生产支持新范式：AI Agent从告警到自动根因分析

当前的 production support 仍然高度依赖工程师。

告警进来 → 工程师检查日志 → 搜索历史事件 → 定位可能的 RCA → 验证方案 → 执行操作。

在研究这个问题的过程中，我开始探索一个简单的问题：

Agentic AI 能否在不让 AI 获得生产环境无限制访问权限的情况下，降低这种依赖？

这就是我的 Agentic Production Support 项目的出发点。

从告警到 AI 辅助的 RCA

我正在构建的基本流程是：

Incident → Clean Layer → RAG → AI Agent → RCA → Validation → Human Approval → Action

系统不会将每个事件直接发送给 LLM，而是先对上下文进行准备和管控。

RAG（Retrieval-Augmented Generation）会搜索历史事件和知识库，提供相关上下文。

AI Agent 然后利用这些上下文生成可能的根因分析（RCA）和推荐操作。

但这里有一个重要的挑战。

AI 治理先于 AI 智能

生产日志可能包含：

• IP 地址和主机名
• AWS 资源 ID 和 ARN
• 项目/环境信息
• 邮箱地址和 PII
• API 密钥、JWT 和 bearer token
• 基础设施容量信息

LLM 并不需要这些信息中的大部分来理解"服务失败是因为磁盘满了"这一事实。

因此我引入了 Model Egress Governance Layer（模型出口治理层）。

Production Incident
  ↓
Clean / Sanitization Layer
  ↓
RAG + Embeddings
  ↓
AI Agent
  ↓
RCA + Validation
  ↓
Human-in-the-Loop
  ↓
Action

原则很简单：

给 AI 它需要的技术上下文，但不暴露生产环境的身份信息。

同样的管控应该应用于 LLM 调用、embedding 生成、RAG 索引、检索查询和 AI 可观测性之前。

对于高风险信息（如密码、API 密钥或授权 token），我的做法是 fail close（默认拒绝）：

仍检测到敏感信息 → 阻止模型调用。

为什么需要 Agentic Production Support？

我不认为 Agentic AI 会取代 production 工程师。

我认为它的作用是减少以下重复性工作：

Incident Detection → Correlation → Knowledge Retrieval → RCA → Validation → Recommended Action

同时在高频操作上保持治理和 Human-in-the-Loop（HITL）管控。

这个项目仍在演进中，我以开放的方式构建它，以便架构能够被测试、质疑和改进。

实现包含 Python、LLM 集成、RAG、embeddings、AI agents、事件管理、RCA 和 AI 治理。

👉 GitHub: https://github.com/devhazare/agentic-production-support

如果你正在从事 AIOps、Agentic AI、SRE 自动化、LLMOps、RAG 或 AI 治理方面的工作，我很期待你的反馈和贡献。