1. AIOps Agent 项目概述最近在运维圈子里AIOps 技术正逐渐从概念走向落地。我花了三周时间搭建了一个能自动分析线上告警的 AI Agent 原型系统代码量不到 200 行但已经实现了从告警识别到根因分析的完整闭环。这个项目最让我兴奋的是它证明了用 LLM 处理运维问题不是天方夜谭——只要设计好数据流和约束条件。这个 Agent 的核心工作流程非常直观当用户询问线上状态时它会先检查当前活跃告警然后拉取相关服务日志最后将所有证据组织成结构化 Prompt 交给大模型分析。整个过程就像有个经验丰富的 SRE 在帮你排查问题但响应速度是人类的十倍以上。2. 核心架构解析2.1 四层架构设计整个系统采用分层设计每个模块职责明确monitor_agent/ ├── main.py # 入口层 ├── agent.py # 编排层 ├── llm.py # 模型层 └── tools.py # 数据层入口层只负责接收问题并输出结果保持极简设计。我在 main.py 里就做了两件事构造用户问题字符串然后调用 agent 函数获取分析结果。这种设计让后续扩展其他交互方式如 API 或命令行变得非常容易。编排层是整个系统的大脑。agent.py 文件包含了完整的处理逻辑链意图识别先过滤掉非运维问题告警查询获取当前活跃告警日志收集根据告警关联服务获取日志Prompt 构建组织分析框架模型调用获取最终分析结果2.2 关键实现细节在意图识别环节我采用了最简单的关键词匹配if 线上 not in question: return 我只能回答线上运行状态相关问题虽然看起来简陋但在 MVP 阶段非常有效。后续可以升级为基于 embedding 的语义匹配但当前版本已经能过滤掉 80% 的非相关提问。告警查询模块返回了结构化数据示例{ alertname: nginx_5xx_high, service: backend-service, since: 2026-03-02 09:41, severity: critical }这个设计让后续处理流程可以精准定位问题服务。在生产环境中这里应该对接真实的告警系统 API。3. 数据处理流程3.1 日志收集策略系统会同时收集两种 Nginx 日志error.log包含 upstream timed out 等关键错误信息access.log统计 5xx 状态码出现频率我特别设计了日志查询函数的参数传递error_log query_nginx_error_log(alerts[service]) access_log query_nginx_access_log(alerts[service])通过告警中的 service 字段进行关联查询确保日志与告警的上下文一致性。这个设计避免了拿着锤子找钉子式的盲目分析。3.2 Prompt 工程实践Prompt 构造是整个项目的灵魂所在。我的设计遵循了几个原则明确角色设定你是一个经验丰富的 SRE提供完整上下文告警详情错误日志访问日志结构化输出要求分四点回答关键问题事实约束请基于日志不要编造不存在的事实完整的 Prompt 模板如下你是一个经验丰富的 SRE。 当前检测到告警 {alerts} Nginx error.log {error_log} Nginx access.log {access_log} 请分析 1. 当前是否存在真实故障 2. 故障发生在哪一层nginx / upstream / network 3. 根因是什么 4. 给出修复建议 请基于日志不要编造不存在的事实。4. 模型调用优化4.1 模型配置要点在 llm.py 中我做了几个关键配置response client.chat.completions.create( modelMODEL, messages[ {role: system, content: 你是一个严谨的 SRE...}, {role: user, content: prompt} ], temperature0.2 # 排障一定要低温度 )特别需要注意的是 temperature 参数设为 0.2。在创意场景可以设为 0.7-1.0但在故障分析场景低温度值能显著减少模型的胡言乱语。4.2 系统提示词设计System Prompt 的设计往往被忽视但其实至关重要。我用了两重约束角色定位严谨的 SRE分析原则只能基于给定事实进行分析这相当于给模型戴上了紧箍咒。实测表明这种约束能让模型输出的分析结果更加聚焦和可靠。5. 生产环境适配建议5.1 数据源对接方案要将这个 demo 升级为生产级系统需要对接以下数据源数据类型推荐对接方案数据用途指标告警Prometheus Alertmanager触发分析流程应用日志ELK/Loki获取错误详情性能指标Grafana/Prometheus辅助根因分析链路追踪Jaeger/SkyWalking定位慢请求5.2 安全防护措施调用外部 LLM 时必须注意数据安全敏感字段脱敏IP、账号、token等设置 API 调用频率限制关键业务数据建议使用本地化模型实现审计日志记录所有查询我常用的脱敏方法包括正则替换敏感信息使用哈希值替代原始数据移除非必要字段6. 典型问题排查实录在实际测试中我遇到了几个典型问题问题1模型输出过于笼统现象分析结论都是可能是上游服务问题解决方案在 Prompt 中明确要求引用具体日志行作为证据问题2误报率高现象将正常波动识别为故障解决方案在告警查询环节增加严重度过滤阈值问题3响应延迟现象完整分析耗时超过15秒解决方案实现日志查询缓存设置模型调用超时对历史相似问题建立答案库7. 性能优化技巧经过多次迭代我总结出几个提升效率的方法并行查询优化# 串行查询旧 error_log query_nginx_error_log() access_log query_nginx_access_log() # 并行查询新 with ThreadPoolExecutor() as executor: error_future executor.submit(query_nginx_error_log) access_future executor.submit(query_nginx_access_log) error_log error_future.result() access_log access_future.result()结果缓存机制对相同告警的分析结果缓存5分钟使用服务名时间范围作为缓存键分级响应策略简单问题直接返回预置解决方案中等复杂度使用轻量级模型快速响应复杂问题调用高级模型深度分析8. 扩展应用场景这个基础框架稍加改造就能支持更多运维场景变更影响分析获取最近部署记录关联监控指标变化评估变更与异常的相关性容量规划建议分析历史负载趋势识别资源瓶颈给出扩容建议故障自愈识别已知故障模式执行预定义修复动作验证修复效果在实际部署时建议先从辅助分析场景开始逐步过渡到自动处置场景。每次迭代都要设置明确的回滚机制和人工复核点。