大模型驱动的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 100
• query_metrics：查询 Prometheus 指标，用 PromQL
• query_logs：搜索日志平台（Loki 或 Elasticsearch）中的关键字
• query_api：调用各类平台 API，比如 K8s 的 pod 状态、云厂商的监控数据
• lookup_doc：从知识库中检索相关文档

每个工具都要用函数描述（Function Calling 格式）暴露给大模型，让模型知道这个工具是干什么的、有什么参数。核心技巧是在描述里写清楚使用场景和注意事项，比如 run_command 只接受只读命令，execution timeout 默认 10 秒。这样能减少模型乱调用工具的概率。

这里我想特别强调命令白名单的重要性。在工具内部实现里，run_command 不能直接接收原始命令字符串就丢给服务器执行，必须做一层命令解析：只允许执行预设的几个只读命令和它们的标准参数组合，其他一律拒绝。比如 df 命令只允许 df -h，ps 只允许 ps aux --sort=-%mem，tail 只允许 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 的动作必须是可逆的或者影响范围可控的。清理日志文件时，不会直接 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_code=400, detail="missing 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_steps=8): messages = build_initial_messages(alert) for step in range(max_steps): response = openai.ChatCompletion.create( model="your-model", messages=messages, tools=TOOLS, temperature=0.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 常见问题速查表

最后整理一份我在实践中经常遇到问题的速查表，方便大家对照排查。

我在实际调试中最深的体会是：AI 运维 Agent 的价值不在于“省掉了人”，而在于把人的精力从重复劳动中解压出来，让人有时间去处理真正需要创造力和经验的事情。如果你也准备做这套方案，我建议你先从小范围场景开始跑，不要急着追求全自动，逐步积累数据、沉淀知识库，这个过程本身就是团队运维能力的一次大整理。等知识库足够丰富、Agent 的置信度长期稳定之后，再慢慢放开更多权限，这条路我走下来是通的，也希望这个方案能帮你少踩一些我踩过的坑。