做运维这几年最折磨人的其实不是故障本身而是半夜两点被告警吵醒爬起来翻半天日志才发现是虚惊一场又或者明明是个三分钟就能解决的问题却要花半小时回忆、翻文档、翻历史工单。所以从去年开始我一直在琢磨一件事能不能用大模型做一个真正能落地的 AI 运维 Agent把告警自动诊断和修复这条链路彻底跑通让人从重复性劳动中解放出来。这篇文章就是我把这套方案从零搭到生产环境的完整记录包括架构设计、核心模块实现、参数细节和踩坑经过适合正在做运维平台、SRE或者想在企业内部引入 AI 智能化运维的团队参考。我尽量少讲虚的多讲能抄走的方案。1. 先搞清楚AI 运维 Agent 到底在解决什么问题1.1 传统告警处理模式的三大痛点告警处理这件事表面上是个流程问题本质上是信息过载和知识断层的问题。大部分团队的现状是Zabbix、Prometheus 或者云监控每天产生几千条告警值班同学收到通知后先登录跳板机再看 Grafana 面板再查日志然后根据个人经验判断要怎么处理。这套流程至少有三个非常明显的痛点。第一响应速度完全取决于值班人员的经验水平。老手可能三分钟定位问题新手可能半小时还在原地打转。第二知识沉淀极其困难故障处理经验都存在个人脑子里一旦人员流动等于把企业最值钱的故障知识带走了。第三重复性工作占比太高磁盘快满、服务假死、进程重启这类问题处理套路其实是固定的完全可以自动化却依然在消耗人的精力和耐心。我见过太多团队试图用传统脚本解决这个问题写一堆 Shell 或 Python 脚本挂在告警上但效果普遍不好。原因很简单告警的形态千变万化脚本只能处理预设的路径一旦故障特征和脚本预设对不上脚本就成了摆设。而大模型擅长的是从非结构化信息中理解上下文、推断意图这正好补上了传统自动化脚本的短板。1.2 为什么是 Agent而不是更复杂的自动化脚本很多人会问直接用告警触发一个脚本不就行了吗为什么非要上 Agent我刚开始做的时候也这样想但实践下来发现脚本和 Agent 有一个本质区别脚本是“死”的Agent 是“活”的。传统脚本的逻辑是 if-then-else比如“如果磁盘使用率超过90%则清理 /tmp 目录”。但如果故障是日志文件占满了 inode或者某个进程没有释放已删除文件的内存句柄脚本就无能为力了。而 Agent 不一样它可以在接到告警之后自主决定下一步要执行哪个命令、查看哪份日志、调用哪个接口整个过程是动态的。它像是一个有经验的运维工程师在处理故障而不是一个按剧本执行的机器人。这也是为什么我在这套方案里坚持用大模型驱动工具调用而不是简单写分支逻辑。Agent 可以通过 ReAct 模式不断循环观察工具返回的结果思考下一步行动再执行新的工具调用直到得出诊断结论并完成修复。这种东西脚本写不出来或者说写出来之后你根本维护不了。1.3 哪些场景适合、哪些场景先别急不是所有告警都适合交给 Agent 处理这个边界必须提前划清楚。以我自己的经验以下三类场景收益最高一是规则明确、操作风险低的场景比如磁盘空间清理、日志轮转、服务状态检查二是需要跨系统查证的场景比如告警来自某台主机但要查上游应用日志、数据库连接池、网络连通性才能定位根因三是高频重复、人类处理已经形成肌肉记忆的场景比如进程假死后的重启。而以下场景至少在初期不要交给 Agent 全自动处理涉及资金操作和数据删除的、影响面覆盖核心交易链路的、以及安全权限敏感的变更操作。这类场景在架构设计上可以保留 Agent 的诊断能力但修复动作必须走人工审批。后面我会详细讲如何用分级机制做到这一点。2. 整体架构设计让 Agent 既有脑子又有手2.1 核心链路拆解告警接入、诊断、修复、复盘这套 Agent 的核心链路可以概括为四个环节告警接入、自动诊断、修复执行、复盘沉淀。四者环环相扣任何一个环节断裂整套系统都跑不起来。告警接入是入口解决了“Agent 怎么知道出了问题”的问题。诊断是大脑解决的是“故障是什么、根因在哪”的问题。修复是手脚解决的是“怎么把问题处理掉”的问题。复盘是记忆让每一次故障处理的经验都沉淀到知识库下次同类问题可以更快定位。链路设计上我建议用消息队列把几个环节解耦。告警网关收到告警后写入队列诊断模块消费队列进行处理。这样做的好处是就算大模型接口突然超时或者 Agent 服务重启告警消息也不会丢可以积压在队列里事后补处理。我用的是 RabbitMQ如果团队熟悉 Kafka 或者就是内网部署直接用 Redis Stream 也没有问题。2.2 Agent 框架选型别一上来就选最重的Agent 框架这块市面上的选择很多LangChain、LlamaIndex、Dify、Coze、自研 ReAct 循环我都试过。坦白说没有绝对的好坏只有合不合适。如果团队已经有比较完善的工程能力我建议直接自研轻量级 Agent 循环核心代码不超过两百行调用大模型的标准接口自己控制工具调用逻辑。这样做可控性最强出问题方便排查也方便按企业安全规范做定制。我当时就是被 LangChain 的版本升级搞怕了很多接口说变就变出了问题社区搜索也搜不到靠谱答案后来干脆自己维护了。如果团队希望快速验证效果不太在意框架依赖可以用 Dify 这类可视化编排工具把告警接入、工具调用、审批节点都拖拽出来。但要注意可视化编排的热链路性能比较差并发量一高容易成为瓶颈。我建议的选型标准只有三条优先看 AI 模型使用的便捷性再看工具注册和权限控制是否灵活最后看故障排查是否方便。与其选一个社区最火的项目不如选一个团队能维护住的项目。2.3 安全兜底设计上线前必须想清楚的底线安全是我建议所有做运维 Agent 的人第一条要思考的问题。Agent 拿到了一台服务器的执行权限就得防止它“带着思考犯大错”。我在这套方案里做了三层兜底。第一层是“最小权限”Agent 默认使用一个低权限账号连接服务器这个账号只允许执行只读命令比如 df、ps、ss、tail 等所有需要写操作、重启服务的命令必须通过单独的提权通道。第二层是“命令白名单”无论是大模型自主调用还是人工审批后的执行最终落到服务器上的命令都要经过一个白名单过滤白名单之外的命令直接拒绝。第三层是“操作留痕”Agent 的每一次思考、每一步工具调用、每一条最终执行命令都写入审计日志确保出了问题可以回溯到完整上下文。这三层兜底听起来简单但实现起来要花不少功夫。尤其是白名单的设计不能只做字符串匹配因为同一条命令可能有无数种写法比如 rm -rf 换个参数顺序就绕过黑名单了。更稳妥的做法是把工具封装成固定函数Agent 只能调用有限的几个函数不能直接拼接 Shell 命令。关于这一点我会在第五章详细展开。3. 告警接入与预处理这一步做不好后面全是坑3.1 用 Webhook 打通告警源告警接入方式决定了 Agent 能感知到多丰富的信息。大多数监控系统都支持 Webhook 推送Zabbix 可以配置媒介类型Prometheus 可以通过 Alertmanager 的 webhook_config 发送腾讯云、阿里云监控也可以把告警推送到自定义 Webhook。我推荐的做法是单独写一个告警网关服务接收所有来源的 Webhook 请求然后统一格式化成内部标准的告警对象。千万不要让各种告警源的原始格式直接灌进后端逻辑因为不同来源的字段差异太大Zabbix 的 key 跟云监控的 metric 命名习惯完全不一样后端代码如果直接兼容这些差异会变得又臭又长。网关服务本身要做得足够轻只做三件事接收请求、解析字段、扔进队列。用一个 FastAPI 服务就能搞定秒级响应即可。不过有个细节需要注意大部分 Webhook 在发送失败后都会重试所以网关接口要做到幂等用告警 ID 去重。3.2 告警统一格式化给模型喂结构化的数据告警到达 Agent 之后第一件事是把它转换成一个结构化的 JSON 对象。我定义的告警对象长这样{ alert_id: alert-x7k2m9, source: zabbix, severity: warning, title: disk usage high, message: Filesystem /dev/vda1 mounted on / has reached 92% capacity, host: web-prod-01, time: 2025-01-12 02:13:45, tags: [disk, capacity, prod] }为什么一定要结构化因为大模型对结构化的输入比对自然语言段落的理解更准确尤其是告警内容千奇百怪模型需要快速定位哪个字段是主机名、哪个字段是阈值、哪个字段是触发时间。把这些信息单独抽出来放进 JSON 里模型一眼就能看懂减少幻觉概率。这里有一个实操技巧message 字段尽量保留原始文本不要过度清洗。原始文本可能包含重要的环境信息比如某个具体的文件路径、进程 ID清洗太狠反而会丢信息。结构化的字段负责给模型指路原始的 message 负责兜底两个配合效果最好。3.3 上下文增强只凭告警消息根本不够用告警对象本身的信息量是很有限的。一个“磁盘使用率92%”的告警只能告诉 Agent“磁盘可能有问题”但 Agent 要诊断为什么磁盘会满还需要知道当前哪些目录占空间最大、最近有没有部署新服务、或者有没有日志文件在疯狂增长。这就需要把告警对象关联到更丰富的上下文。我在告警进入诊断模块之前会先做一步上下文增强把以下信息塞进诊断的初始上下文里主机元信息IP、所属应用、负责人、所属环境生产/预发/测试最近一小时的监控指标CPU、内存、磁盘、网络 IO最近的变更记录是否有发布、是否有配置修改、是否有扩容关联告警同一台主机或同一个应用在过去 30 分钟内是否还有其它告警这些信息从哪里来通常企业内部都有配置管理数据库CMDB和发布平台写几个接口把数据拉出来即可。如果信息化基础比较薄弱也可以用 Agent 的工具主动去查调用查询 CMDB 的接口、查 Prometheus 的指标、查发布平台的工单。关键是让 Agent 的初始状态尽可能接近一个真实工程师打开电脑看到的信息量。3.4 告警去重与限流防止风暴打垮 Agent生产环境经常出现的情况是某个基础层故障引发连锁反应短时间内产生几百上千条告警。如果每条告警都丢给大模型去诊断不仅消耗大量 token还会让 Agent 陷入互相矛盾的上下文里最后谁也没诊断明白。我的做法是在入口处加一道去重合并逻辑。核心思路是同一台主机、同一个告警 key在去重窗口内比如10分钟只保留一条但把触发次数和首次触发时间记下来。对于明显由同一个根因引发的告警集合比如同一时刻大量主机都报了“连接超时”还可以按告警特征做分组把整个分组当成一个事件来处理让 Agent 只分析根因而不是逐条分析同一个问题。限流也要同时做。我给告警网关设置了一个令牌桶每秒最多处理 N 个告警事件超出部分直接合并进当前批次。这样做虽然会让告警信息有点延迟但能保证 Agent 处理的告警一定是有效信息而不是被风暴淹没。4. 诊断引擎让 Agent 真的会“看病”4.1 知识库与 Runbook给 Agent 补上历史经验一个刚入职的运维工程师是不可能独立处理故障的因为他没有经验。AI 运维 Agent 同理如果只是把大模型直接接上它会像一个没受过运维训练的人一样胡说八道。所以知识库和 Runbook 的建设是诊断引擎最核心的底座。我把企业内部的历史故障记录、处理手册、变更文档全部清洗并向量化存入向量数据库。当告警进来时先用告警内容检索出最相近的几条历史记录连同告警上下文一起发给大模型。这一步的作用非常明显模型在参考了历史处理方案之后给出的诊断建议质量会高很多因为它有了“先例”可以依托。知识库建设看起来只是文档切片加向量化真正做起来却特别耗时。文档格式五花八门有的 Word有的 PDF有的是老工程师手写的 Markdown。我建议初期只挑故障复盘文档和历史告警处理记录这两类先跑起来再逐步扩充。如果企业内部连文档都没有那就让 Agent 每处理完一个真实故障自动生成一篇复盘记录存入知识库三个月后沉淀就很可观了。4.2 工具调用设计可观测性是诊断的基础诊断过程必须要“眼见为实”。大模型不能凭空判断它必须通过工具去收集证据。我这里设计的核心工具不多主要是这几类run_command在目标主机上执行只读命令如 df -h、ps aux、ss -lnp、tail -n 100query_metrics查询 Prometheus 指标用 PromQLquery_logs搜索日志平台Loki 或 Elasticsearch中的关键字query_api调用各类平台 API比如 K8s 的 pod 状态、云厂商的监控数据lookup_doc从知识库中检索相关文档每个工具都要用函数描述Function Calling 格式暴露给大模型让模型知道这个工具是干什么的、有什么参数。核心技巧是在描述里写清楚使用场景和注意事项比如 run_command 只接受只读命令execution timeout 默认 10 秒。这样能减少模型乱调用工具的概率。这里我想特别强调命令白名单的重要性。在工具内部实现里run_command 不能直接接收原始命令字符串就丢给服务器执行必须做一层命令解析只允许执行预设的几个只读命令和它们的标准参数组合其他一律拒绝。比如 df 命令只允许 df -hps 只允许 ps aux --sort-%memtail 只允许 tail -n 200 指定日志文件。用白名单而不是黑名单是安全上的基础底线。4.3 提示词与推理约束把思考过程限定在轨道上大模型虽然有推理能力但在生产环境里还是容易出现“自由发挥”。我建议在提示词中给 Agent 立几条硬性规矩。系统提示词一般长这样你是运维诊断助手只能使用提供的工具收集证据。 严禁在没有工具输出支撑的情况下猜测根因。 你的输出必须包括根因、证据列表、置信度分数、建议修复方案。 以下操作需要申请人工审批重启服务、删除文件、修改配置、执行扩容。 如果工具返回结果异常或超时如实说明不要编造输出。写提示词的时候要特别注意“禁止编造数据”这条。大模型在上下文中见过太多命令输出它会不自觉地把记忆里的输出当成当前工具的真实输出这是幻觉的主要来源。我处理的办法有两个一是每次工具调用返回时都标注一个 timestamp 和 execution_id明确告诉模型这是真实的执行结果二是在提示词里反复强调“只能引用本次工具调用的返回内容作为证据”。另外建议让模型以结构化 JSON 输出诊断结论而不是自然语言。结构化的结论方便后端代码做拦截和决策。比如诊断结论包含 risk_level、confidence、evidence 这样三个字段后端可以根据 risk_level 自动决定是否需要走人工审批而不是等到模型生成完大段文字再解析。这里同样有一个简单的 JSON 解析容错逻辑模型偶尔会输出不完整的 JSON后端要能够容忍并重试一次。4.4 置信度与证据链结论需要能溯源我给诊断结论设置了置信度分数从 0 到 1 分。这个分数的意义不是给模型看的而是给下游修复模块做决策用的。修复模块可以配置一个阈值比如置信度达到 0.8 才允许自动执行低风险修复动作低于 0.6 则直接转人工。置信度分数完全由模型自评。为了让自评靠谱我在提示词里给了明确的评分标准只有拥有直接证据比如命令输出明确显示磁盘目录被大文件占满才允许给 0.8 以上如果只是间接推测比如“可能是磁盘满了因为没有看到其他异常”无论如何不能超过 0.6。证据链是比置信度更重要的东西。我在设计上要求每次诊断结论必须附上证据索引列表也就是哪些工具调用返回了哪些关键数据。假设 Agent 说要清理某个日志文件就必须能指出来“哪条命令的输出证明了占用率达到 92%”“哪条命令的输出定位到了具体目录”。这套证据链除了让结论可信还有一个作用方便事后审计出了问题可以追溯到 Agent 到底是看了什么才做出的决策。5. 自动修复执行与容错这里必须谨慎再谨慎5.1 修复动作分级什么能自动、什么要审批修复是整个方案里风险最高的环节。我的做法是建立修复动作分级制度而不是一刀切“全部自动执行”或者“全部人工”。分级标准主要看两个维度操作的影响范围和是否可逆。我用了一个三级分类级别修复动作示例执行方式L1清理日志文件、重启非核心应用、删除临时文件自动执行L2重启核心服务、磁盘扩容、回滚发布版本人工审批L3修改安全组规则、操作数据库数据、变更生产配置禁止自动执行L1 的动作必须是可逆的或者影响范围可控的。清理日志文件时不会直接 rm 原文件而是先 truncate把文件大小截断为 0这样就算有问题也不至于立刻丢数据。L2 的动作哪怕影响面大一点只要有明确的审批机制也可以跑通。L3 我直接禁止 Agent 自动执行甚至不允许它提出相关修复建议一旦模型探测到这类需求只输出“建议联系平台权限管理员”即可。这套分级不只写在提示词里还要在代码里做硬校验。也就是说即使模型输出说要执行 L3 操作后端拦截逻辑也会拒绝执行。提示词约束的是“软边界”代码校验才是“硬边界”。5.2 修复命令封装与白名单机制有了分级之后具体到修复命令的执行就要解决“怎么让 Agent 的工具不变成攻击面”的问题。我的方案是把所有修复操作封装成有限集合的原子动作Agent 只能从里面选择动作并填入参数不能自由生成 Shell。比如我定义了这些修复动作cleanup_logs(host, path, threshold)清理指定目录下超过 N 天的日志文件restart_service(host, service)通过 systemctl restart 重启服务truncate_file(host, path)截断大文件到空内容remove_temp_file(host, path)删除明确的临时文件set_file_permission(host, path, mode, owner)修复文件权限每个动作的底层实现是写死的。cleanup_logs 内部就是 find path -mtime N -delete 这条命令Agent 只能传 path 和 N 参数。这样即使大模型被恶意提示词攻击或者纯粹抽风它的破坏半径也是被限制住的。整台服务器在 Agent 面前不是一个需要保护的黑盒子而是一个只暴露了几个按钮的操作面板。这个设计在运维 Agent 落地时非常关键。我见过一些团队直接把 SSH 命令执行权限交给大模型完全靠提示词约束结果在一次模型升级后出现过一次工具调用混乱差点把生产文件删了。所以我在自己的方案里一律用白名单加参数化封装不给模型自由发挥的空间。5.3 修复验证与自动回滚自动执行完修复动作后没有验证就等于白修。我规定 Agent 在每次修复后必须重新调用一次监控查询工具或者只读命令确认告警指标是否回到正常范围。比如修复了磁盘空间执行完清理动作后需要重新执行 df -h 查看对应的分区使用率确认数据确实下降了。如果指标没有变化说明修复没有生效Agent 需要重新诊断或者升级阶段处理。这个循环和前面诊断的 ReAct 循环是同一套机制只是把目标从“找出根因”变成了“验证修复效果”。对于可以回滚的操作比如重启服务后新版本起不来的情况我在流程里增加了自动回滚逻辑Agent 重启服务后 30 秒检查服务进程状态如果进程不存在或者健康检查失败自动执行回滚动作把上一个已知正常的版本重新拉起。回滚操作本身也写入审计日志并额外触发一条高优先级告警通知人类值班告知 Agent 执行了一次自动回滚请尽快介入。5.4 全过程留痕可观测性也是审计底线最后一点整个 Agent 的处理过程从告警接入到最终修复完成每一步都需要留痕。我构建了一个事件流日志每条记录包含告警 ID、时间戳、处理阶段、模型思考内容、工具调用请求与返回、中间决策、最终执行动作、结果验证。这些日志不仅仅是给技术排查用的更是给合规和安全团队看的。因为运维 Agent 本质上是一个有生产环境操作权限的程序它的行为必须能够被审计否则出了问题责任说不清楚。我建议一开始就把审计日志接口设计好每天对日志做一次完整性校验确保任何一条操作记录都没有被篡改或删除。6. 从零跑通最小可用版本完整实操记录6.1 环境准备与项目骨架下面进入实操环节我梳理一下从零搭建最小可用版本需要准备的东西。这里简化了生产环境的复杂依赖只保留核心链路告警接收、诊断循环、工具调用、修复执行。基础环境方面我用一台 Linux 测试机CentOS 7 或 Ubuntu 20.04 以上跑 Agent 服务Python 3.10安装必要的依赖即可。大模型我用的是 OpenAI 兼容接口企业内网部署也大多支持这种形式替换 Base URL 就行。用到的库主要就是 fastapi、uvicorn、openai、pyyaml 和 pydantic。项目骨架大致如下agent/ ├── main.py # 告警网关入口FastAPI ├── agent.py # ReAct 循环主逻辑 ├── tools.py # 工具注册与执行白名单 ├── config.yaml # 模型、队列、审批等配置 ├── knowledge.py # 知识库检索 └── logs/这里我特别想提醒一个新手常见的坑模型 API Key 一定不要写死在代码里。我见过不止一次团队把 Key 提交到 Git 仓库结果代码泄露导致账号被刷爆。统一从环境变量读取或者从本地独立的配置文件读取并且这个配置文件要加进 .gitignore。6.2 告警接收服务的实现告警网关用 FastAPI 写最省事核心代码就几十行from fastapi import FastAPI, Request, HTTPException import asyncio app FastAPI() async def handle_alert(alert: dict): # 关键步骤归一化告警、写日志、推入队列 normalized normalize_alert(alert) asyncio.create_task(agent.process(normalized)) return {status: accepted} app.post(/webhook/alert) async def alert_webhook(request: Request): payload await request.json() # 校验必要的告警字段防止不规范数据直接进入链路 if alert_id not in payload or host not in payload: raise HTTPException(status_code400, detailmissing fields) return await handle_alert(payload)实际生产里我会用 RabbitMQ 或 Redis Stream 做队列而不是直接 asyncio.create_task因为后者在服务重启时会丢失未处理的任务。但在最小版本里这样已经能跑通链路了。告警归一化函数 normalize_alert 做的事情就是前面提到的从不同来源的告警原始数据中提取统一字段填充到内部结构化对象里。6.3 诊断循环与工具注册的实现Agent 核心循环是我自己写的一个简化版 ReAct避免引入重量级框架。伪代码如下import openai TOOLS load_tools() # 读取 tools.py 里注册的工具定义 def agent_loop(alert, max_steps8): messages build_initial_messages(alert) for step in range(max_steps): response openai.ChatCompletion.create( modelyour-model, messagesmessages, toolsTOOLS, temperature0.2 # 固定低温度减少幻觉 ) msg response.choices[0].message if not msg.tool_calls: # 模型没有调用工具说明已经给出结论 conclusion parse_conclusion(msg.content) return conclusion for call in msg.tool_calls: result execute_tool(call.function.name, call.function.arguments) # 工具执行结果回填到上下文让模型基于真实输出继续推理 messages.append({ role: tool, tool_call_id: call.id, content: json.dumps(result) }) return {error: max_steps }这个循环的核心机制就是把每次工具执行的真实结果作为新的上下文消息让模型在下一次调用时基于这些信息继续推理。循环终止的条件是模型不再请求工具调用直接输出了诊断结论。设置 max_steps 是为了防死循环我一般设 8 到 10 步。如果超过步数还没得出结论默认转人工处理并记录告警。温度参数也很有讲究我直接固定为 0.2保证每次推理结果尽量稳定。虽然低温度会让回答稍微保守但在运维场景里稳定压倒一切。6.4 模拟磁盘告警的端到端测试搭建完成后我用一个模拟磁盘告警做了端到端测试。我在测试机上写了一个占满磁盘的临时文件然后手动构造一条告警推送看看 Agent 从接警到处理完的完整表现。告警内容和前面示例类似主机 web-prod-01磁盘使用率 92%。Agent 收到告警后第一步 query_metrics 查看了该主机的磁盘指标确认使用率确实是 92% 而不是误报。第二步调用 run_command 执行 df -h看到 /dev/vda1 使用率异常。第三步再调用 run_command 执行 du -sh /var/log发现日志目录占了将近 70% 的空间。到这里整个证据链已经清楚了。模型随后给出了结论根因是 nginx 的 access.log 增长过快建议 truncate 该文件置信度 0.9。这个动作属于 L1 低风险级别配置允许自动执行。于是我这边封装了一个 truncate_file 工具Agent 调用它把 access.log 截断后重新执行 df -h 验证发现使用率降到了 61%流程结束生成复盘记录存入知识库。整个过程大概两分钟如果换成人工处理光定位日志目录这一步就可能需要五分钟。测试结果让我比较满意至少证明了这套链路是真实可用的不是一个停留在概念层面的演示品。7. 实际运行中的高频问题与排查技巧7.1 大模型幻觉导致误诊幻觉是 AI 运维 Agent 落地过程中最头疼的问题因为运维场景对准确性要求极高。我遇到的典型情况是Agent 在分析磁盘占满时明明应该去查进程持有的文件句柄却因为上下文里出现过类似案例直接跳到了“可能是日志轮转出了问题”这个结论而这个结论并没有当前环境证据支撑。针对这个问题我在提示词里加大了“只能引用工具输出”的约束力度同时引入了一个机制叫“证据链完整性校验”如果结论声称某个目录占用高但对应的 du 或 df 命令输出里没有出现这个目录的路径结论就不能被下游执行模块接受。这个校验在代码里实现相当于给模型套了一个硬性护栏。用了之后误诊率明显下降。7.2 工具调用超时与截断问题Agent 在执行工具调用时经常遇到两个问题一是命令执行时间过长导致超时二是返回内容太长导致上下文塞满。磁盘扫描这种命令尤其容易超时全盘 du 在大目录上可能要跑几分钟远超普通命令的 10 秒超时。我的处理方案是给所有工具设置独立的超时参数比如 run_command 默认 10 秒query_metrics 默认 30 秒对可能超时的命令比如磁盘扫描我会用 timeout 命令包裹并提示模型分目录执行不要一次扫描整个根目录。对于上下文过长的问题工具返回内容超过一定长度就要做摘要截断比如日志查询只返回时间窗口内前 200 条匹配而不是全量拿回来。7.3 配置解析错误的特殊情况在模型 API 接入过程中我遇到过很多配置解析错误的问题。区分呢最典型的是大模型 API 配置文件格式不正确导致 Agent 服务启动时直接报错退出。有一次我折腾了很久最后发现是 config.toml 里的 model 字段填写有误和 API 服务端支持的模型名对不上导致持续调用失败。这类问题排查起来其实有套路先把配置文件整体 dump 出来人工检查一遍看看有没有多余字符、缩进是否正常、引号是否闭合然后再对照 API 服务端的模型列表确认填写的模型名完全一致。这个排查思路放到其他开源工具的配置上也适用。为了避免反复踩坑我在项目里加了一个启动自检脚本启动时自动检查关键配置项有问题直接提示而不是等运行时才报错。7.4 告警风暴下 Agent 被击穿告警风暴是最考验架构设计容错能力的场景。有一次生产环境出现网络抖动短时间内产生了上千条告警我的告警网关直接被打满了后续告警全部积压Agent 处理速度跟不上最终导致大量告警延迟处理被值班同学吐槽还不如原来的纯人工模式。这次事故让我补了两个功能一是告警分组去重同一个根因衍生的告警在入口处合成一条“事件”而不是逐条处理二是增加了一个滑动窗口限速器当积压数量超过阈值时自动降低新告警的处理优先级优先处理已经积压的事件。这两个功能上线之后再遇到风暴场景Agent 至少不会崩了虽然无法及时处理每一条告警但能保证核心事件不漏。7.5 多语言日志解析乱成一锅粥大模型处理多语言日志的能力其实很强但如果日志格式太混乱比如 Java 堆栈、Go panic、Python traceback 混在一起模型也会被搞晕。问题的根源往往不在模型而在于工具返回的日志片段里缺少足够的上下文。我的做法是改善日志查询工具的设计除了返回匹配行的原始内容还会额外返回日志所在文件的文件路径、最近 5 行的上下文、以及时间戳范围。这些附加信息能让模型更准确地判断日志是来自哪个服务、哪个版本有效减少因为日志片段割裂导致的误判。7.6 常见问题速查表最后整理一份我在实践中经常遇到问题的速查表方便大家对照排查。常见问题可能原因处理办法Agent 诊断结论明显错误上下文缺失或提示词约束不足检查告警上下文增强是否完整增加证据链完整性校验工具调用一直超时命令太重、超时设置过短分目录执行调高超时用异步执行代替同步阻塞模型反复调用同一工具ReAct 循环缺少状态记忆在上下文里明确标注已经执行过的操作增加循环步数上限配置文件解析报错格式、字段名或体积有问题增加启动自检脚本人工检查关键配置项告警风暴导致积压缺少去重限流机制增加分组去重增加滑动窗口限速器修复后指标没有变化修复动作未生效或判断依据错误增加修复验证环节检查修复工具底层命令是否正确执行权限校验过于严格导致修复失败白名单过于保守在安全可控的前提下逐条放宽白名单不要一次性全放开我在实际调试中最深的体会是AI 运维 Agent 的价值不在于“省掉了人”而在于把人的精力从重复劳动中解压出来让人有时间去处理真正需要创造力和经验的事情。如果你也准备做这套方案我建议你先从小范围场景开始跑不要急着追求全自动逐步积累数据、沉淀知识库这个过程本身就是团队运维能力的一次大整理。等知识库足够丰富、Agent 的置信度长期稳定之后再慢慢放开更多权限这条路我走下来是通的也希望这个方案能帮你少踩一些我踩过的坑。 
长河君 · 2026/9/19 11:54:11 · 阅读 1.2k 大模型驱动的AI运维Agent：告警诊断与自动修复实战
做运维这几年最折磨人的其实不是故障本身而是半夜两点被告警吵醒爬起来翻半天日志才发现是虚惊一场又或者明明是个三分钟就能解决的问题却要花半小时回忆、翻文档、翻历史工单。所以从去年开始我一直在琢磨一件事能不能用大模型做一个真正能落地的 AI 运维 Agent把告警自动诊断和修复这条链路彻底跑通让人从重复性劳动中解放出来。这篇文章就是我把这套方案从零搭到生产环境的完整记录包括架构设计、核心模块实现、参数细节和踩坑经过适合正在做运维平台、SRE或者想在企业内部引入 AI 智能化运维的团队参考。我尽量少讲虚的多讲能抄走的方案。1. 先搞清楚AI 运维 Agent 到底在解决什么问题1.1 传统告警处理模式的三大痛点告警处理这件事表面上是个流程问题本质上是信息过载和知识断层的问题。大部分团队的现状是Zabbix、Prometheus 或者云监控每天产生几千条告警值班同学收到通知后先登录跳板机再看 Grafana 面板再查日志然后根据个人经验判断要怎么处理。这套流程至少有三个非常明显的痛点。第一响应速度完全取决于值班人员的经验水平。老手可能三分钟定位问题新手可能半小时还在原地打转。第二知识沉淀极其困难故障处理经验都存在个人脑子里一旦人员流动等于把企业最值钱的故障知识带走了。第三重复性工作占比太高磁盘快满、服务假死、进程重启这类问题处理套路其实是固定的完全可以自动化却依然在消耗人的精力和耐心。我见过太多团队试图用传统脚本解决这个问题写一堆 Shell 或 Python 脚本挂在告警上但效果普遍不好。原因很简单告警的形态千变万化脚本只能处理预设的路径一旦故障特征和脚本预设对不上脚本就成了摆设。而大模型擅长的是从非结构化信息中理解上下文、推断意图这正好补上了传统自动化脚本的短板。1.2 为什么是 Agent而不是更复杂的自动化脚本很多人会问直接用告警触发一个脚本不就行了吗为什么非要上 Agent我刚开始做的时候也这样想但实践下来发现脚本和 Agent 有一个本质区别脚本是“死”的Agent 是“活”的。传统脚本的逻辑是 if-then-else比如“如果磁盘使用率超过90%则清理 /tmp 目录”。但如果故障是日志文件占满了 inode或者某个进程没有释放已删除文件的内存句柄脚本就无能为力了。而 Agent 不一样它可以在接到告警之后自主决定下一步要执行哪个命令、查看哪份日志、调用哪个接口整个过程是动态的。它像是一个有经验的运维工程师在处理故障而不是一个按剧本执行的机器人。这也是为什么我在这套方案里坚持用大模型驱动工具调用而不是简单写分支逻辑。Agent 可以通过 ReAct 模式不断循环观察工具返回的结果思考下一步行动再执行新的工具调用直到得出诊断结论并完成修复。这种东西脚本写不出来或者说写出来之后你根本维护不了。1.3 哪些场景适合、哪些场景先别急不是所有告警都适合交给 Agent 处理这个边界必须提前划清楚。以我自己的经验以下三类场景收益最高一是规则明确、操作风险低的场景比如磁盘空间清理、日志轮转、服务状态检查二是需要跨系统查证的场景比如告警来自某台主机但要查上游应用日志、数据库连接池、网络连通性才能定位根因三是高频重复、人类处理已经形成肌肉记忆的场景比如进程假死后的重启。而以下场景至少在初期不要交给 Agent 全自动处理涉及资金操作和数据删除的、影响面覆盖核心交易链路的、以及安全权限敏感的变更操作。这类场景在架构设计上可以保留 Agent 的诊断能力但修复动作必须走人工审批。后面我会详细讲如何用分级机制做到这一点。2. 整体架构设计让 Agent 既有脑子又有手2.1 核心链路拆解告警接入、诊断、修复、复盘这套 Agent 的核心链路可以概括为四个环节告警接入、自动诊断、修复执行、复盘沉淀。四者环环相扣任何一个环节断裂整套系统都跑不起来。告警接入是入口解决了“Agent 怎么知道出了问题”的问题。诊断是大脑解决的是“故障是什么、根因在哪”的问题。修复是手脚解决的是“怎么把问题处理掉”的问题。复盘是记忆让每一次故障处理的经验都沉淀到知识库下次同类问题可以更快定位。链路设计上我建议用消息队列把几个环节解耦。告警网关收到告警后写入队列诊断模块消费队列进行处理。这样做的好处是就算大模型接口突然超时或者 Agent 服务重启告警消息也不会丢可以积压在队列里事后补处理。我用的是 RabbitMQ如果团队熟悉 Kafka 或者就是内网部署直接用 Redis Stream 也没有问题。2.2 Agent 框架选型别一上来就选最重的Agent 框架这块市面上的选择很多LangChain、LlamaIndex、Dify、Coze、自研 ReAct 循环我都试过。坦白说没有绝对的好坏只有合不合适。如果团队已经有比较完善的工程能力我建议直接自研轻量级 Agent 循环核心代码不超过两百行调用大模型的标准接口自己控制工具调用逻辑。这样做可控性最强出问题方便排查也方便按企业安全规范做定制。我当时就是被 LangChain 的版本升级搞怕了很多接口说变就变出了问题社区搜索也搜不到靠谱答案后来干脆自己维护了。如果团队希望快速验证效果不太在意框架依赖可以用 Dify 这类可视化编排工具把告警接入、工具调用、审批节点都拖拽出来。但要注意可视化编排的热链路性能比较差并发量一高容易成为瓶颈。我建议的选型标准只有三条优先看 AI 模型使用的便捷性再看工具注册和权限控制是否灵活最后看故障排查是否方便。与其选一个社区最火的项目不如选一个团队能维护住的项目。2.3 安全兜底设计上线前必须想清楚的底线安全是我建议所有做运维 Agent 的人第一条要思考的问题。Agent 拿到了一台服务器的执行权限就得防止它“带着思考犯大错”。我在这套方案里做了三层兜底。第一层是“最小权限”Agent 默认使用一个低权限账号连接服务器这个账号只允许执行只读命令比如 df、ps、ss、tail 等所有需要写操作、重启服务的命令必须通过单独的提权通道。第二层是“命令白名单”无论是大模型自主调用还是人工审批后的执行最终落到服务器上的命令都要经过一个白名单过滤白名单之外的命令直接拒绝。第三层是“操作留痕”Agent 的每一次思考、每一步工具调用、每一条最终执行命令都写入审计日志确保出了问题可以回溯到完整上下文。这三层兜底听起来简单但实现起来要花不少功夫。尤其是白名单的设计不能只做字符串匹配因为同一条命令可能有无数种写法比如 rm -rf 换个参数顺序就绕过黑名单了。更稳妥的做法是把工具封装成固定函数Agent 只能调用有限的几个函数不能直接拼接 Shell 命令。关于这一点我会在第五章详细展开。3. 告警接入与预处理这一步做不好后面全是坑3.1 用 Webhook 打通告警源告警接入方式决定了 Agent 能感知到多丰富的信息。大多数监控系统都支持 Webhook 推送Zabbix 可以配置媒介类型Prometheus 可以通过 Alertmanager 的 webhook_config 发送腾讯云、阿里云监控也可以把告警推送到自定义 Webhook。我推荐的做法是单独写一个告警网关服务接收所有来源的 Webhook 请求然后统一格式化成内部标准的告警对象。千万不要让各种告警源的原始格式直接灌进后端逻辑因为不同来源的字段差异太大Zabbix 的 key 跟云监控的 metric 命名习惯完全不一样后端代码如果直接兼容这些差异会变得又臭又长。网关服务本身要做得足够轻只做三件事接收请求、解析字段、扔进队列。用一个 FastAPI 服务就能搞定秒级响应即可。不过有个细节需要注意大部分 Webhook 在发送失败后都会重试所以网关接口要做到幂等用告警 ID 去重。3.2 告警统一格式化给模型喂结构化的数据告警到达 Agent 之后第一件事是把它转换成一个结构化的 JSON 对象。我定义的告警对象长这样{ alert_id: alert-x7k2m9, source: zabbix, severity: warning, title: disk usage high, message: Filesystem /dev/vda1 mounted on / has reached 92% capacity, host: web-prod-01, time: 2025-01-12 02:13:45, tags: [disk, capacity, prod] }为什么一定要结构化因为大模型对结构化的输入比对自然语言段落的理解更准确尤其是告警内容千奇百怪模型需要快速定位哪个字段是主机名、哪个字段是阈值、哪个字段是触发时间。把这些信息单独抽出来放进 JSON 里模型一眼就能看懂减少幻觉概率。这里有一个实操技巧message 字段尽量保留原始文本不要过度清洗。原始文本可能包含重要的环境信息比如某个具体的文件路径、进程 ID清洗太狠反而会丢信息。结构化的字段负责给模型指路原始的 message 负责兜底两个配合效果最好。3.3 上下文增强只凭告警消息根本不够用告警对象本身的信息量是很有限的。一个“磁盘使用率92%”的告警只能告诉 Agent“磁盘可能有问题”但 Agent 要诊断为什么磁盘会满还需要知道当前哪些目录占空间最大、最近有没有部署新服务、或者有没有日志文件在疯狂增长。这就需要把告警对象关联到更丰富的上下文。我在告警进入诊断模块之前会先做一步上下文增强把以下信息塞进诊断的初始上下文里主机元信息IP、所属应用、负责人、所属环境生产/预发/测试最近一小时的监控指标CPU、内存、磁盘、网络 IO最近的变更记录是否有发布、是否有配置修改、是否有扩容关联告警同一台主机或同一个应用在过去 30 分钟内是否还有其它告警这些信息从哪里来通常企业内部都有配置管理数据库CMDB和发布平台写几个接口把数据拉出来即可。如果信息化基础比较薄弱也可以用 Agent 的工具主动去查调用查询 CMDB 的接口、查 Prometheus 的指标、查发布平台的工单。关键是让 Agent 的初始状态尽可能接近一个真实工程师打开电脑看到的信息量。3.4 告警去重与限流防止风暴打垮 Agent生产环境经常出现的情况是某个基础层故障引发连锁反应短时间内产生几百上千条告警。如果每条告警都丢给大模型去诊断不仅消耗大量 token还会让 Agent 陷入互相矛盾的上下文里最后谁也没诊断明白。我的做法是在入口处加一道去重合并逻辑。核心思路是同一台主机、同一个告警 key在去重窗口内比如10分钟只保留一条但把触发次数和首次触发时间记下来。对于明显由同一个根因引发的告警集合比如同一时刻大量主机都报了“连接超时”还可以按告警特征做分组把整个分组当成一个事件来处理让 Agent 只分析根因而不是逐条分析同一个问题。限流也要同时做。我给告警网关设置了一个令牌桶每秒最多处理 N 个告警事件超出部分直接合并进当前批次。这样做虽然会让告警信息有点延迟但能保证 Agent 处理的告警一定是有效信息而不是被风暴淹没。4. 诊断引擎让 Agent 真的会“看病”4.1 知识库与 Runbook给 Agent 补上历史经验一个刚入职的运维工程师是不可能独立处理故障的因为他没有经验。AI 运维 Agent 同理如果只是把大模型直接接上它会像一个没受过运维训练的人一样胡说八道。所以知识库和 Runbook 的建设是诊断引擎最核心的底座。我把企业内部的历史故障记录、处理手册、变更文档全部清洗并向量化存入向量数据库。当告警进来时先用告警内容检索出最相近的几条历史记录连同告警上下文一起发给大模型。这一步的作用非常明显模型在参考了历史处理方案之后给出的诊断建议质量会高很多因为它有了“先例”可以依托。知识库建设看起来只是文档切片加向量化真正做起来却特别耗时。文档格式五花八门有的 Word有的 PDF有的是老工程师手写的 Markdown。我建议初期只挑故障复盘文档和历史告警处理记录这两类先跑起来再逐步扩充。如果企业内部连文档都没有那就让 Agent 每处理完一个真实故障自动生成一篇复盘记录存入知识库三个月后沉淀就很可观了。4.2 工具调用设计可观测性是诊断的基础诊断过程必须要“眼见为实”。大模型不能凭空判断它必须通过工具去收集证据。我这里设计的核心工具不多主要是这几类run_command在目标主机上执行只读命令如 df -h、ps aux、ss -lnp、tail -n 100query_metrics查询 Prometheus 指标用 PromQLquery_logs搜索日志平台Loki 或 Elasticsearch中的关键字query_api调用各类平台 API比如 K8s 的 pod 状态、云厂商的监控数据lookup_doc从知识库中检索相关文档每个工具都要用函数描述Function Calling 格式暴露给大模型让模型知道这个工具是干什么的、有什么参数。核心技巧是在描述里写清楚使用场景和注意事项比如 run_command 只接受只读命令execution timeout 默认 10 秒。这样能减少模型乱调用工具的概率。这里我想特别强调命令白名单的重要性。在工具内部实现里run_command 不能直接接收原始命令字符串就丢给服务器执行必须做一层命令解析只允许执行预设的几个只读命令和它们的标准参数组合其他一律拒绝。比如 df 命令只允许 df -hps 只允许 ps aux --sort-%memtail 只允许 tail -n 200 指定日志文件。用白名单而不是黑名单是安全上的基础底线。4.3 提示词与推理约束把思考过程限定在轨道上大模型虽然有推理能力但在生产环境里还是容易出现“自由发挥”。我建议在提示词中给 Agent 立几条硬性规矩。系统提示词一般长这样你是运维诊断助手只能使用提供的工具收集证据。 严禁在没有工具输出支撑的情况下猜测根因。 你的输出必须包括根因、证据列表、置信度分数、建议修复方案。 以下操作需要申请人工审批重启服务、删除文件、修改配置、执行扩容。 如果工具返回结果异常或超时如实说明不要编造输出。写提示词的时候要特别注意“禁止编造数据”这条。大模型在上下文中见过太多命令输出它会不自觉地把记忆里的输出当成当前工具的真实输出这是幻觉的主要来源。我处理的办法有两个一是每次工具调用返回时都标注一个 timestamp 和 execution_id明确告诉模型这是真实的执行结果二是在提示词里反复强调“只能引用本次工具调用的返回内容作为证据”。另外建议让模型以结构化 JSON 输出诊断结论而不是自然语言。结构化的结论方便后端代码做拦截和决策。比如诊断结论包含 risk_level、confidence、evidence 这样三个字段后端可以根据 risk_level 自动决定是否需要走人工审批而不是等到模型生成完大段文字再解析。这里同样有一个简单的 JSON 解析容错逻辑模型偶尔会输出不完整的 JSON后端要能够容忍并重试一次。4.4 置信度与证据链结论需要能溯源我给诊断结论设置了置信度分数从 0 到 1 分。这个分数的意义不是给模型看的而是给下游修复模块做决策用的。修复模块可以配置一个阈值比如置信度达到 0.8 才允许自动执行低风险修复动作低于 0.6 则直接转人工。置信度分数完全由模型自评。为了让自评靠谱我在提示词里给了明确的评分标准只有拥有直接证据比如命令输出明确显示磁盘目录被大文件占满才允许给 0.8 以上如果只是间接推测比如“可能是磁盘满了因为没有看到其他异常”无论如何不能超过 0.6。证据链是比置信度更重要的东西。我在设计上要求每次诊断结论必须附上证据索引列表也就是哪些工具调用返回了哪些关键数据。假设 Agent 说要清理某个日志文件就必须能指出来“哪条命令的输出证明了占用率达到 92%”“哪条命令的输出定位到了具体目录”。这套证据链除了让结论可信还有一个作用方便事后审计出了问题可以追溯到 Agent 到底是看了什么才做出的决策。5. 自动修复执行与容错这里必须谨慎再谨慎5.1 修复动作分级什么能自动、什么要审批修复是整个方案里风险最高的环节。我的做法是建立修复动作分级制度而不是一刀切“全部自动执行”或者“全部人工”。分级标准主要看两个维度操作的影响范围和是否可逆。我用了一个三级分类级别修复动作示例执行方式L1清理日志文件、重启非核心应用、删除临时文件自动执行L2重启核心服务、磁盘扩容、回滚发布版本人工审批L3修改安全组规则、操作数据库数据、变更生产配置禁止自动执行L1 的动作必须是可逆的或者影响范围可控的。清理日志文件时不会直接 rm 原文件而是先 truncate把文件大小截断为 0这样就算有问题也不至于立刻丢数据。L2 的动作哪怕影响面大一点只要有明确的审批机制也可以跑通。L3 我直接禁止 Agent 自动执行甚至不允许它提出相关修复建议一旦模型探测到这类需求只输出“建议联系平台权限管理员”即可。这套分级不只写在提示词里还要在代码里做硬校验。也就是说即使模型输出说要执行 L3 操作后端拦截逻辑也会拒绝执行。提示词约束的是“软边界”代码校验才是“硬边界”。5.2 修复命令封装与白名单机制有了分级之后具体到修复命令的执行就要解决“怎么让 Agent 的工具不变成攻击面”的问题。我的方案是把所有修复操作封装成有限集合的原子动作Agent 只能从里面选择动作并填入参数不能自由生成 Shell。比如我定义了这些修复动作cleanup_logs(host, path, threshold)清理指定目录下超过 N 天的日志文件restart_service(host, service)通过 systemctl restart 重启服务truncate_file(host, path)截断大文件到空内容remove_temp_file(host, path)删除明确的临时文件set_file_permission(host, path, mode, owner)修复文件权限每个动作的底层实现是写死的。cleanup_logs 内部就是 find path -mtime N -delete 这条命令Agent 只能传 path 和 N 参数。这样即使大模型被恶意提示词攻击或者纯粹抽风它的破坏半径也是被限制住的。整台服务器在 Agent 面前不是一个需要保护的黑盒子而是一个只暴露了几个按钮的操作面板。这个设计在运维 Agent 落地时非常关键。我见过一些团队直接把 SSH 命令执行权限交给大模型完全靠提示词约束结果在一次模型升级后出现过一次工具调用混乱差点把生产文件删了。所以我在自己的方案里一律用白名单加参数化封装不给模型自由发挥的空间。5.3 修复验证与自动回滚自动执行完修复动作后没有验证就等于白修。我规定 Agent 在每次修复后必须重新调用一次监控查询工具或者只读命令确认告警指标是否回到正常范围。比如修复了磁盘空间执行完清理动作后需要重新执行 df -h 查看对应的分区使用率确认数据确实下降了。如果指标没有变化说明修复没有生效Agent 需要重新诊断或者升级阶段处理。这个循环和前面诊断的 ReAct 循环是同一套机制只是把目标从“找出根因”变成了“验证修复效果”。对于可以回滚的操作比如重启服务后新版本起不来的情况我在流程里增加了自动回滚逻辑Agent 重启服务后 30 秒检查服务进程状态如果进程不存在或者健康检查失败自动执行回滚动作把上一个已知正常的版本重新拉起。回滚操作本身也写入审计日志并额外触发一条高优先级告警通知人类值班告知 Agent 执行了一次自动回滚请尽快介入。5.4 全过程留痕可观测性也是审计底线最后一点整个 Agent 的处理过程从告警接入到最终修复完成每一步都需要留痕。我构建了一个事件流日志每条记录包含告警 ID、时间戳、处理阶段、模型思考内容、工具调用请求与返回、中间决策、最终执行动作、结果验证。这些日志不仅仅是给技术排查用的更是给合规和安全团队看的。因为运维 Agent 本质上是一个有生产环境操作权限的程序它的行为必须能够被审计否则出了问题责任说不清楚。我建议一开始就把审计日志接口设计好每天对日志做一次完整性校验确保任何一条操作记录都没有被篡改或删除。6. 从零跑通最小可用版本完整实操记录6.1 环境准备与项目骨架下面进入实操环节我梳理一下从零搭建最小可用版本需要准备的东西。这里简化了生产环境的复杂依赖只保留核心链路告警接收、诊断循环、工具调用、修复执行。基础环境方面我用一台 Linux 测试机CentOS 7 或 Ubuntu 20.04 以上跑 Agent 服务Python 3.10安装必要的依赖即可。大模型我用的是 OpenAI 兼容接口企业内网部署也大多支持这种形式替换 Base URL 就行。用到的库主要就是 fastapi、uvicorn、openai、pyyaml 和 pydantic。项目骨架大致如下agent/ ├── main.py # 告警网关入口FastAPI ├── agent.py # ReAct 循环主逻辑 ├── tools.py # 工具注册与执行白名单 ├── config.yaml # 模型、队列、审批等配置 ├── knowledge.py # 知识库检索 └── logs/这里我特别想提醒一个新手常见的坑模型 API Key 一定不要写死在代码里。我见过不止一次团队把 Key 提交到 Git 仓库结果代码泄露导致账号被刷爆。统一从环境变量读取或者从本地独立的配置文件读取并且这个配置文件要加进 .gitignore。6.2 告警接收服务的实现告警网关用 FastAPI 写最省事核心代码就几十行from fastapi import FastAPI, Request, HTTPException import asyncio app FastAPI() async def handle_alert(alert: dict): # 关键步骤归一化告警、写日志、推入队列 normalized normalize_alert(alert) asyncio.create_task(agent.process(normalized)) return {status: accepted} app.post(/webhook/alert) async def alert_webhook(request: Request): payload await request.json() # 校验必要的告警字段防止不规范数据直接进入链路 if alert_id not in payload or host not in payload: raise HTTPException(status_code400, detailmissing fields) return await handle_alert(payload)实际生产里我会用 RabbitMQ 或 Redis Stream 做队列而不是直接 asyncio.create_task因为后者在服务重启时会丢失未处理的任务。但在最小版本里这样已经能跑通链路了。告警归一化函数 normalize_alert 做的事情就是前面提到的从不同来源的告警原始数据中提取统一字段填充到内部结构化对象里。6.3 诊断循环与工具注册的实现Agent 核心循环是我自己写的一个简化版 ReAct避免引入重量级框架。伪代码如下import openai TOOLS load_tools() # 读取 tools.py 里注册的工具定义 def agent_loop(alert, max_steps8): messages build_initial_messages(alert) for step in range(max_steps): response openai.ChatCompletion.create( modelyour-model, messagesmessages, toolsTOOLS, temperature0.2 # 固定低温度减少幻觉 ) msg response.choices[0].message if not msg.tool_calls: # 模型没有调用工具说明已经给出结论 conclusion parse_conclusion(msg.content) return conclusion for call in msg.tool_calls: result execute_tool(call.function.name, call.function.arguments) # 工具执行结果回填到上下文让模型基于真实输出继续推理 messages.append({ role: tool, tool_call_id: call.id, content: json.dumps(result) }) return {error: max_steps }这个循环的核心机制就是把每次工具执行的真实结果作为新的上下文消息让模型在下一次调用时基于这些信息继续推理。循环终止的条件是模型不再请求工具调用直接输出了诊断结论。设置 max_steps 是为了防死循环我一般设 8 到 10 步。如果超过步数还没得出结论默认转人工处理并记录告警。温度参数也很有讲究我直接固定为 0.2保证每次推理结果尽量稳定。虽然低温度会让回答稍微保守但在运维场景里稳定压倒一切。6.4 模拟磁盘告警的端到端测试搭建完成后我用一个模拟磁盘告警做了端到端测试。我在测试机上写了一个占满磁盘的临时文件然后手动构造一条告警推送看看 Agent 从接警到处理完的完整表现。告警内容和前面示例类似主机 web-prod-01磁盘使用率 92%。Agent 收到告警后第一步 query_metrics 查看了该主机的磁盘指标确认使用率确实是 92% 而不是误报。第二步调用 run_command 执行 df -h看到 /dev/vda1 使用率异常。第三步再调用 run_command 执行 du -sh /var/log发现日志目录占了将近 70% 的空间。到这里整个证据链已经清楚了。模型随后给出了结论根因是 nginx 的 access.log 增长过快建议 truncate 该文件置信度 0.9。这个动作属于 L1 低风险级别配置允许自动执行。于是我这边封装了一个 truncate_file 工具Agent 调用它把 access.log 截断后重新执行 df -h 验证发现使用率降到了 61%流程结束生成复盘记录存入知识库。整个过程大概两分钟如果换成人工处理光定位日志目录这一步就可能需要五分钟。测试结果让我比较满意至少证明了这套链路是真实可用的不是一个停留在概念层面的演示品。7. 实际运行中的高频问题与排查技巧7.1 大模型幻觉导致误诊幻觉是 AI 运维 Agent 落地过程中最头疼的问题因为运维场景对准确性要求极高。我遇到的典型情况是Agent 在分析磁盘占满时明明应该去查进程持有的文件句柄却因为上下文里出现过类似案例直接跳到了“可能是日志轮转出了问题”这个结论而这个结论并没有当前环境证据支撑。针对这个问题我在提示词里加大了“只能引用工具输出”的约束力度同时引入了一个机制叫“证据链完整性校验”如果结论声称某个目录占用高但对应的 du 或 df 命令输出里没有出现这个目录的路径结论就不能被下游执行模块接受。这个校验在代码里实现相当于给模型套了一个硬性护栏。用了之后误诊率明显下降。7.2 工具调用超时与截断问题Agent 在执行工具调用时经常遇到两个问题一是命令执行时间过长导致超时二是返回内容太长导致上下文塞满。磁盘扫描这种命令尤其容易超时全盘 du 在大目录上可能要跑几分钟远超普通命令的 10 秒超时。我的处理方案是给所有工具设置独立的超时参数比如 run_command 默认 10 秒query_metrics 默认 30 秒对可能超时的命令比如磁盘扫描我会用 timeout 命令包裹并提示模型分目录执行不要一次扫描整个根目录。对于上下文过长的问题工具返回内容超过一定长度就要做摘要截断比如日志查询只返回时间窗口内前 200 条匹配而不是全量拿回来。7.3 配置解析错误的特殊情况在模型 API 接入过程中我遇到过很多配置解析错误的问题。区分呢最典型的是大模型 API 配置文件格式不正确导致 Agent 服务启动时直接报错退出。有一次我折腾了很久最后发现是 config.toml 里的 model 字段填写有误和 API 服务端支持的模型名对不上导致持续调用失败。这类问题排查起来其实有套路先把配置文件整体 dump 出来人工检查一遍看看有没有多余字符、缩进是否正常、引号是否闭合然后再对照 API 服务端的模型列表确认填写的模型名完全一致。这个排查思路放到其他开源工具的配置上也适用。为了避免反复踩坑我在项目里加了一个启动自检脚本启动时自动检查关键配置项有问题直接提示而不是等运行时才报错。7.4 告警风暴下 Agent 被击穿告警风暴是最考验架构设计容错能力的场景。有一次生产环境出现网络抖动短时间内产生了上千条告警我的告警网关直接被打满了后续告警全部积压Agent 处理速度跟不上最终导致大量告警延迟处理被值班同学吐槽还不如原来的纯人工模式。这次事故让我补了两个功能一是告警分组去重同一个根因衍生的告警在入口处合成一条“事件”而不是逐条处理二是增加了一个滑动窗口限速器当积压数量超过阈值时自动降低新告警的处理优先级优先处理已经积压的事件。这两个功能上线之后再遇到风暴场景Agent 至少不会崩了虽然无法及时处理每一条告警但能保证核心事件不漏。7.5 多语言日志解析乱成一锅粥大模型处理多语言日志的能力其实很强但如果日志格式太混乱比如 Java 堆栈、Go panic、Python traceback 混在一起模型也会被搞晕。问题的根源往往不在模型而在于工具返回的日志片段里缺少足够的上下文。我的做法是改善日志查询工具的设计除了返回匹配行的原始内容还会额外返回日志所在文件的文件路径、最近 5 行的上下文、以及时间戳范围。这些附加信息能让模型更准确地判断日志是来自哪个服务、哪个版本有效减少因为日志片段割裂导致的误判。7.6 常见问题速查表最后整理一份我在实践中经常遇到问题的速查表方便大家对照排查。常见问题可能原因处理办法Agent 诊断结论明显错误上下文缺失或提示词约束不足检查告警上下文增强是否完整增加证据链完整性校验工具调用一直超时命令太重、超时设置过短分目录执行调高超时用异步执行代替同步阻塞模型反复调用同一工具ReAct 循环缺少状态记忆在上下文里明确标注已经执行过的操作增加循环步数上限配置文件解析报错格式、字段名或体积有问题增加启动自检脚本人工检查关键配置项告警风暴导致积压缺少去重限流机制增加分组去重增加滑动窗口限速器修复后指标没有变化修复动作未生效或判断依据错误增加修复验证环节检查修复工具底层命令是否正确执行权限校验过于严格导致修复失败白名单过于保守在安全可控的前提下逐条放宽白名单不要一次性全放开我在实际调试中最深的体会是AI 运维 Agent 的价值不在于“省掉了人”而在于把人的精力从重复劳动中解压出来让人有时间去处理真正需要创造力和经验的事情。如果你也准备做这套方案我建议你先从小范围场景开始跑不要急着追求全自动逐步积累数据、沉淀知识库这个过程本身就是团队运维能力的一次大整理。等知识库足够丰富、Agent 的置信度长期稳定之后再慢慢放开更多权限这条路我走下来是通的也希望这个方案能帮你少踩一些我踩过的坑。