“会的不难难的不会”——这句话用在当下的运维 Agent 身上再贴切不过。我在生产环境里见过太多次这样的场景AIOPS 平台里的 Agent 在演示阶段行云流水从告警分析到定位根因再执行止损操作一气呵成。可隔了两周同一类型的故障再次出现Agent 却像失忆了一样连最基本的排查路径都要重新推演一遍。整个圈子都在谈 Agent 的自学习能力但真到了落地环节大家发现一个尴尬的真相模型不缺、算力不缺、工具链也不缺真正卡住所有人的是怎么让 Agent 把一次完整的运维经历变成一份它能反复咀嚼、消化吸收的学习样本。这个环节行话叫证据补全。它才是自学习从口号走向实战的那道分水岭。1. 会的还会、不会的永远学不会当前运维 Agent 的自学习困局1.1 从一次让人后背发凉的失忆说起先讲个我踩过的真实场景。某次压测环境里一个负责 MySQL 连接数治理的 Agent 表现得非常优秀。它发现连接数飙到上限立刻拉取了SHOW PROCESSLIST的结果识别出一批长时间处于Sleep状态的空闲连接然后按阈值分批清理最后观察连接池曲线平稳回落。整个过程逻辑缜密每一步都有据可依。当时团队所有人都觉得这玩意儿已经学会了处理连接数风暴。两周后生产环境发生同类型告警Agent 的第一反应居然是先调了一版通用的排查预案然后对着告警详情发了半天呆最后又从头开始执行那套先杀空闲连接的操作。它没有调用上次的经验没有跳过那些已经验证无效的中间步骤甚至连自己两周前成功用过的脚本都要重新问一遍工具层才能调用。问题出在哪不是模型没有记忆能力也不是框架没做长期存储。而是——Agent 上次执行过程中留下的记录根本不足以支撑它完成一次真正的学习。1.2 Agent 不是没有记录而是没有可学的样本绝大多数 Agent 框架都会留下日志。工具调用记录、命令输入输出、执行完成状态一个都不少。可你把这些日志翻出来看就会发现一件扎心的事里面记录的是做了什么却完全没有回答为什么这么做和做完之后到底发生了什么。有命令没有当时的监控指标快照——Agent 决定清理连接时看到的连接数曲线是往上冲还是横盘原始日志里没有。有操作没有中间的推理依据——它为什么先筛Sleep状态而非Locked状态是因为读过某篇文档还是因为上次复盘时专家提过一句日志里没有。有结果没有终态验证的闭环——执行完清理后连接池是 5 分钟恢复的还是 30 分钟恢复的恢复是因为操作生效还是因为流量自然回落日志里还是没有。你把这堆东西甩给再强的模型它也学不出个所以然。就好比给一个实习生看了三个月的工作日报日报上只写今天我重启了某个服务、今天我改了某个配置却从不写我为什么判断要重启、重启之后有没有解决。这个实习生三个月后还是啥也不会。这就是当前运维 Agent 自学习困局的本质大量的操作记录但极度缺乏可学习的证据样本。1.3 自动化不等于自学习很多人会把Agent 能自动做事和Agent 能自己进步混为一谈。这俩完全是两回事。自动化是静态的一套脚本、一套规则定义好了就按部就班执行。规则里没有的情况出现它就傻眼。自学习是动态的遇到新情况、做完一次决策、拿到一次反馈之后能力会有实质性的增量下次再遇到类似问题它的判断会更准、动作会更稳。维度自动化自学习知识来源预先定义的规则和脚本历史决策过程与结果反馈面对新场景无法覆盖直接失守基于相似经验进行迁移决策依据固定条件判断多维度证据交叉验证失败之后原地重试同样的错继续犯复盘归因避免同类错误演进方式靠人工改代码、改规则靠高质量样本驱动模型迭代如果自动化是肌肉记忆自学习就是脑子会思考。而让一个 Agent 长出思考能力的前提是先给它足够多的、高质量的思考案例——也就是经过证据补全的完整经验样本。2. 想清楚一个前提Agent 的自学习到底要学什么在讨论证据补全之前得先把目标定义清楚。很多团队把把历史命令喂给模型当成自学习这从一开始就跑偏了。Agent 要从运维经历中学习的东西其实是分层的。2.1 技能层面知道怎么执行这是最基础的一层——掌握工具的使用方法。比如告警来了要先查目标主机的 CPU 和内存指标要清理磁盘得先看分区占用率要重启服务得先确认进程都在。这些本质上是API 调用能力和操作规范。这一层今天已经不算难点。LLM 天然擅长把自然语言转成工具调用Function Calling 和各类 Agent 框架把工具注册、参数解析、返回结果格式化都做得很成熟。Agent 学这一层就像新员工熟悉内部系统一样翻翻文档就能上手。2.2 判断层面知道什么时候选哪个方案这层就要难不少了。同样是数据库连接数告警处置方案可能有三条清理空闲连接、扩容连接池上限、定位并修复连接泄漏。选哪条取决于当时的场景特征。如果慢查询堆积导致连接持有时间过长那清空闲连接只是治标压根本的优化 SQL 才能救命。如果流量突然翻倍导致连接池容量不足那扩容才是第一优先级。如果代码里有连接泄漏 bug那清理再多、扩容再大连接数迟早还会打到天花板。判断层面的学习学的是环境特征到决策方案之间的映射关系。Agent 需要从历史样本中总结出什么样的指标组合、什么样的日志特征指向了什么样的根因最终应该采用哪套处置方案。这个映射关系不是靠人写规则写出来的而是在一次次复盘、一次次结果验证中沉淀出来的。2.3 认知层面知道环境变了该怎么办运维环境的动态性决定了Agent 不能只会照搬历史。同样是内存告警在虚拟机环境和容器环境里的处置思路完全不同同一个应用在版本升级前后的表现可能截然两样。认知层面的学习是让 Agent 理解自身决策的前提条件在环境发生变化时主动调整策略。打个比方一个老师傅能在一个新的机房环境里很快适应是因为他脑子里的不是固定套路而是一套看现象→猜原因→验证假设的思维框架。这个框架很难用几百条规则表达出来但它可以从大量包含前提条件、决策过程、执行结果的完整经验中抽象出来。2.4 为什么通用 RAG 和模型微调解决不了这个问题讨论到现在总会有人问想给 Agent 积累经验直接把历史文档、历史工单扔进向量库做 RAG检索增强生成不就行了吗再进阶一点拿历史数据微调一下模型参数行不行RAG 解决的是查得到资料却解决不了判断该查什么、查到的资料怎么和当前环境对上号。历史文档不会告诉你你眼前这个正在告警的系统跟上周那个故障的系统有哪些不同。你需要的是把当前场景的关键特征和历史场景逐一比对从中选出最可参考的经验——这个比对并选出的过程恰恰是证据补全之后才可能发生的事情。微调就更难落地了。一次故障处理涉及的信息形态非常复杂时间序列指标、系统拓扑关系、脚本执行输出、人工评审意见。把这些多模态信号统一转化成模型的权重更新训练数据的质量要求极高不是把日志吐给模型就行。而生产环境的故障又是长尾分布很多场景一个月也碰不上几次靠微调去记住这些低频样本性价比很低。所以更务实的路径不是让模型去背历史而是给 Agent 建一个结构化的经验库。每次故障处理完毕后通过证据补全生成一份可检索、可比对、可修正的结构化记录。下次遇到新问题时Agent 先做场景匹配把最相似的历史经验拉出来作为推理参考。这就像给每个新来的运维工程师配发了一套前辈的手写笔记——但前提是这套笔记得写得足够完整、足够准确。3. 证据补全到底补的是哪四条链所谓证据补全就是把 Agent 一次完整任务执行过程中缺失的关键信息从各个数据源里找回来、补上去形成一份闭环的证据记录。具体拆开来看需要打通的证据链有四条。3.1 时间维证据把离散事件拼成完整时间线一次故障从发生到恢复涉及告警触发、指标突变、Agent 介入、操作执行、效果验证、人工兜底等多个环节。这些事件散落在不同的系统里各有各的时间戳。证据补全的第一件事是把它们按统一时基串成一条完整时间线。比如这么一条时间线14: 03: 12 告警系统发出连接数超阈值告警14: 05: 30 Agent 首次拉取连接数指标14: 06: 18 Agent 执行连接数明细查询14: 08: 45 Agent 终止可疑空闲连接14: 12: 20 连接数指标回归正常水位14: 30: 00 复盘人工确认了初步根因有了这条时间线才能判断Agent 的操作是否是恢复的直接原因、中间是否存在明显的时间空窗、指标恢复和操作之间的时延有多长。时间线是证据补全的地基其他维度的证据都要锚定在这条线上。3.2 因果维证据在操作和结果之间搭桥时间线只告诉我们先发生了 A后发生了 B因果维则要回答A 到底是不是 B 的原因。打个比方Agent 执行了一个脚本20 分钟后业务指标恢复了。如果这 20 分钟里业务流量本来就在自然回落那恢复这件事可能跟 Agent 的操作毫无关系。证据补全要干的事是找到额外的佐证来支撑或推翻这个因果判断——比如脚本执行前后关键指标的突变点是否对齐、是否存在同类故障在其他未被操作的节点上同时恢复、SQL 慢查询的消失时间是否与操作时间吻合。因果维是整个证据补全中最硬核、也最容易偷懒的环节。很多团队为了省事直接以告警解除操作成功作为判断依据结果就是 Agent 记住了大量无害但无效的操作路径甚至会把系统自愈归功于自己。3.3 环境维证据没有上下文的学习等于盲人摸象同样的操作在 A 环境里是有效的在 B 环境里可能是破坏性的。环境维证据记录了故障发生时系统的身世背景当前是哪套集群、哪个命名空间、哪台主机应用的版本号、配置项、最近是否有变更记录上下游依赖的健康状态当前流量模型是正常的日常波动还是促销/压测造成的异常峰值没有环境维证据Agent 学到的东西就是脱离语境的碎片。它可能把一次针对老版本 MySQL 的修复经验套用到了已经升级完补丁的新版本上也可能在流量洪峰期间做出一个平时看来合理、当时却非常危险的决策。3.4 反馈维证据谁说了算的最终裁决前面三条链补的都是Agent 看到的世界反馈维补的是真实世界给出的最终答案。这是自学习和自动化最大的分水岭——没有反馈就没有学习的方向。反馈维包括几类信息Agent 操作的直接结果连接池指标是否回落、错误率是否降为零业务层的中长期影响故障是否在后续一段时间内复发、用户体验指标是否有变化人工专家的复盘结论最终定位到的根因是什么、Agent 的判断是否准确、哪些动作是多余的、哪些动作是关键的人工专家的复盘结论尤其重要。因为很多决策的对错短期内根本看不出来。Agent 清了一堆空闲连接指标确实恢复了但根因是连接泄漏——如果不靠专家复盘把这层真根因补进去Agent 学到的就是清理空闲连接可以解决连接数告警这个肤浅且不完整的经验。四条链全部打通之后一份证据记录才真正具备了学习样本的价值。它不再是日志的堆砌而是一个完整的、可以由后续 Agent 去检索和推演的案例。4. 为什么这么难证据补全里的四个硬骨头理解了证据补全要补什么下一个问题是这件事为什么这么难落地我在不同规模的团队里观察到一个共性规律——技术方案的落地难度往往不在方案本身而在那些平时注意不到、一旦做起来就疯狂拖后腿的细节。证据补全的难点正好集中在四个地方。4.1 日志只记录发生了什么不告诉你为什么发生运维体系里有大量的日志和告警但它们的定位是事实记录不是因果解释。连接池耗尽的告警只会告诉你连接数超过了阈值不会告诉你是因为慢查询拖住了连接、还是代码里出现了连接泄漏、还是流量突然暴增。Agent 要学会归因必须先有人或系统帮它把当时有哪些迹象分别指向了哪些可能性这个推理过程补全。可怕的是这个过程在 Agent 执行的时候是存在的只是它以隐性的方式存在于大模型的权重计算里压根没被持久化。4.2 推理过程不落盘Agent 自己都不知道自己为啥这么干这是最容易被忽略、又最致命的一个坑。现在主流的 Agent 框架基本都基于 ReAct 模式——让模型推理一步、执行一步、观察一步。但在实际工程落地时绝大多数框架只保存了模型最终调用的工具和参数模型在调用之前的内部推理文本默认是不落盘的。带来什么后果呢事后复盘时你知道 Agent 执行了清理空闲连接这个动作但完全不知道它为什么选择清理空闲连接而不是排查慢查询。这个为什么如果丢了整个样本的因果链就是断的。要解决这个问题必须在框架层面做改造让 Agent 在每个关键决策点输出结构化的推理依据——我观察到了什么现象我当前的假设是什么我要通过什么操作来验证这个假设我预期看到什么结果。这相当于逼着 Agent 把自己的思考过程写下来即使不用于用户展示也要完整存留作为训练料。4.3 长延迟因果业务恢复不代表故障结束很多运维操作的效果不是即时的。你重启了一个服务可能 10 分钟后 load 才降下来你清理了一批脏数据可能两小时后慢查询才彻底消失你加了一条索引可能需要几天的业务流量采样才能验证它是不是真的缓解了问题。这种长延迟的因果链路对证据补全提出了很大的挑战——什么时候才算最终结果如果 Agent 当天操作完就认为任务结束了后续几天里出现的复发现象就永远不会被关联到这次操作上从而丢失掉一批最有价值的负反馈样本。比较好的实践是给每个 Agent 任务设置验证窗口。比如一个变更类任务操作完成只是前半段任务要在 24 小时甚至 48 小时后做一次效果回访把后续的指标波动、告警记录一并拉回合并成完整的样本。没有这个回访机制证据补全永远只能补到表面上的成功。4.4 正样本容易高质量负样本千金难买如果翻一翻运维 Agent 的执行记录你会发现一个规律凡是流程跑通的都被完完整整地记下来了凡是流程中断的、执行报错的、结果不达预期的记录往往残缺不全甚至直接没有下文的。但恰恰是这些没有成功的记录才是自学习最宝贵的养料。Agent 需要知道哪个判断是错的、哪条路是死胡同才能在下一次避开。只有正样本没有负样本学出来的 Agent 会非常自信但全是盲目的自信——它不知道自己的判断边界在哪里。有一类更难获取的负样本假阳性操作。Agent 判断失误但误打误撞把问题解决了或者根因判断错了但一个盲目的重启恰好让系统恢复了。这类样本在结果上是成功的在因果上是错误的。如果不靠专家评审把这些假阳性样本识别出来并打上负标签Agent 很可能会把侥幸当成实力在错误的路线上越走越远。5. 拿一个真实场景练手数据库连接池故障的证据补全演示理论说得再多不如拉一个场景具体过一遍。我用最常见的数据库连接池告警来做演练把原始日志 vs 补全后的证据放在一起对比你就能直观感受到差距在哪。5.1 从原始日志看缺了什么假设你有一个运维 Agent 在 14 点左右处理了一次数据库连接数超限告警框架留下的原始日志长这样[14:03:12] WARN db-conn-threshold: 当前连接数 850/800 (阈值触发) [14:05:30] INFO agent-tool-call: list_connections(hostprod-db-01) [14:06:20] INFO agent-tool-call: kill_connection(session_id1024, 2048, 3072) [14:08:15] INFO agent-tool-call: check_connection_pool() [14:09:20] INFO task-completed: 数据库连接数告警已处理这段日志看着也有时间线、也有操作记录但作为学习样本几乎不合格。缺了太多关键信息Agent 当时查到的连接明细里到底有哪些特征为什么选中了那三个 session 而不是别的清理之后连接数回落的具体曲线是什么样这个过程中有没有出现新告警后续 24 小时有没有复发这些都是空白。5.2 补全后的结构化证据长什么样经过证据补全之后理想状态下它应该长这样时间维14:03:12 告警触发连接数 850/80014:03:18-14:05:20 监控显示连接数快速上升平均每 10 秒增加 15 个连接14:05:30 Agent 拉取连接明细14:06:18 Agent 判断存在连接泄漏迹象大量Sleep状态连接持有超过 30 分钟14:06:20 执行清理按空闲时长超过 30 分钟条件分批终止14:08:15 复查连接数降到 600 以下14:09:20 任务标记完成进入 24 小时观察窗口次日 10:00 观察窗口关闭无复发、无新告警因果维清理操作执行后 2 分钟内连接数从 850 降至 600与操作动作高度相关慢查询日志中未发现该时段有大查询堆积排除慢 SQL 致因连接数在告警前 20 分钟开始持续上升与应用近期发布的新版本v2.3.1存在时间关联复盘结论该版本代码存在连接未释放 bug清理操作是治标升级修复版本才是治本环境维主机prod-db-01MySQL 8.0.28连接池上限 800应用服务 3 个实例当日 13:40 完成 v2.3.1 灰度发布上下游流量模型与往日同时段基本持平反馈维短期反馈清理后 1 小时无告警中期反馈24 小时观察窗口内未复发专家评审Agent 的清理操作有效缓解了指标压力但根因判断不完整正确的根因是应用层连接泄漏后续应由应用团队修复发布样本标签操作有效但根因定位不完整建议下次遇到同类告警优先检查近期变更和连接持有时间这份补全后的样本才真正具备可学习的属性。Agent 下次再遇到类似场景能从上一次的经验里知道先查近期变更、再判断连接持有时间分布、清理只是应急手段、要想根治必须找到持有连接的源头应用。5.3 怎么判断一份样本是不是优质学习样本在实际操作中团队没必要对每一条记录都做完整补全那样成本太高。重点盯三类任务一个周期内发生频次最高的、影响面最大的、以及 Agent 判断和专家判断出现分歧的。对这类任务用下面三条标准来验收样本质量。可复现读样本的人或者 Agent能不能复现出当时的场景如果一份样本只告诉你清理了连接却没说清楚当时连接数的走势和连接特征那就是不可复现——换个环境这套经验就没法用。可归因结果到底是怎么来的是 Agent 的操作起效了还是系统自愈了如果答不上来谁导致了恢复这个样本就是带病的因果。可对比这份样本有没有明确的错误标记专家当时纠正了什么Agent 的哪个判断被验证是多余的只有把对在哪、错在哪标出来样本才能成为训练的养料。满足这三条才称得上优质学习样本。否则它只是一段有头无尾的流水账。6. 从补样本到能进化自学习闭环里的五个关键环节证据补全不是一次性的行为它只是整个自学习流水线的第一环。要让 Agent 真的越用越强需要把五个环节串成一个闭环并且持续运转。6.1 采集与对齐这是证据补全前面那道工序。把散落在监控系统、日志平台、CMDB、变更系统、Agent 框架、工单系统里的数据先归集起来同时做好时间对齐。时间对齐非常关键——不同系统各有一套时间戳如果不先做统一时基后面所有的时间线分析都是空中楼阁。这一环的实际成本往往比想象中高。很多系统都缺接口、缺权限、缺详单需要一份一份去打通。建议先从最有价值的两三个数据源入手先跑通再扩展。6.2 补全与关联这是核心环节。把归集到的数据按时间维、因果维、环境维、反馈维四条链去做关联补齐。这个环节里人工专家的角色非常重——至少在前中期不要指望全自动补全能完全替代人工评审。我的建议是建一个半自动补全 人工确认的流水线系统自动把时间线和环境上下文串好Agent 决策日志自动汇入最后把一份待评审的完整证据记录推给运维专家由专家补充因果判断和评价标签。人工只做判断题不做填空题效率就能上去。6.3 清洗与标注补全完的证据还不能直接用要经过清洗和标注。清洗的意义在于去噪——有些告警跟本次故障毫无关系有些指标波动是系统维护任务造成的需要打上排除标记。标注则是给样本打标签有效操作无效操作误判根因侥幸成功真根因等等。这里要特别提醒清洗和标注的质量直接决定了自学习的上限。宁可样本量少一些也不要为了让模型看起来学得多而放宽标注标准。一份错误标注的样本可能让模型往回倒退了十份正确样本带来的收益。6.4 模式提炼清洗标注完的样本要转成 Agent 可以检索、引用的知识形态。我的做法是建立三层结构案例层完整证据记录供深度推演规则层从案例中提炼出的候选模式比如连接数告警 大量长连接 近期有变更 → 优先怀疑变更引入的泄漏策略层与具体场景绑定的处置建议比如泄漏场景下先临时清理 同步通知应用团队 升级版本验证日积月累下来这就像一个层层递进的专家库Agent 在处理新任务时按需取用。6.5 验证与注入新提炼出的模式不能直接注入到 Agent 的推理链路里必须先经过离线和在线的双重验证。离线验证的做法是拿历史数据回放看注入新模式后Agent 在历史场景中的决策是不是更优了。在线验证的做法是选一个小流量场景先让部分 Agent 实例用新模式跑一段时间跟旧模式的实例做对比。我踩过的坑是跳过验证直接全量上线。结果新注入的模式里有一条隐性的错误关联导致 Agent 在白天高峰期里做了几次不必要的重启操作。从那以后我给自己定了一条铁律没有经过验证的知识不允许进入生产 Agent 的决策链路。7. 别急着造平台三条可落地的起步路径证据补全这件事听着复杂但完全没必要一开始就铺一个大平台。很多团队死就死在第一步就把摊子铺得太大设计了一堆模块结果半年看不到一个可用的样本项目就被拍死了。更务实的方式是先用轻量手段跑通最小闭环让团队尝到甜头。7.1 路径一把人工复盘报告改造成结构化证据所有做过运维的团队都有复盘文化。事故处理完之后总会有个人写一份复盘文档记录时间线、影响面、根因、改进措施。这是现成的、质量最高的证据来源。你要做的不是造一个复杂的补全系统而是先给复盘报告定一个结构化模板把时间维、因果维、环境维、反馈维四个板块固化下来。每次复盘必须按模板填填完自动归档到知识库。这件事一个星期就能落地而且马上就能为 Agent 提供第一批高质量历史样本。7.2 路径二给 Agent 加上决策日志输出如果你的 Agent 还处于没有结构化推理记录的阶段先别想复杂的补全。直接在 Agent 框架里加一个 hook让模型在每个关键决策点时额外输出一段结构化推理字段。不需要给用户展示纯粹为了留存。示例格式{ observation: 连接数850/800大量Sleep连接持有超30分钟, hypothesis: 疑似连接泄漏先验证后清理, action: list_connections, 按空闲时长排序, expected: 确认是否存在异常长连接, actual: 发现多个超30分钟空闲连接 }这一步改造其实很小但收益巨大——它让 Agent 第一次把思考痕迹留了下来。未来做证据补全时就再也不用靠猜来还原决策意图了。7.3 路径三选一个场景做垂直闭环不要试图让自学习能力覆盖所有运维场景。选一个你团队最头疼、发生频率最高的场景比如数据库连接数治理、磁盘空间告警、应用慢响应定位先把采集、补全、标注、提炼、验证的闭环在这个场景里完整跑通。跑通之后你会发现虽然它只是一个垂直场景但团队已经具备了一套方法论。再往第二个、第三个场景扩展时成本会低很多。事实证明从窄场景起步的团队最后都走在了前面而那些一开始就想要全场景覆盖的大多还停在 PPT 阶段。7.4 先别做的事一份反面清单最后分享几个基于个人经验的不要做清单不要一上来就建大数据平台。证据补全的瓶颈从来不是存储和计算而是数据质量和组织流程。用一张 MySQL 表都能起步。不要指望纯靠大模型自动完成因果判断。现阶段 LLM 对复杂运维数据流的因果推理能力还不到火候人工确认环节不能省。不要用告警解除当唯一的结果标签。后面 24 小时的复发情况一定得看否则你积累的样本里会混入大量假成功。不要追求样本量。几千条低质样本不如几十条经过严格补全和标注的高质样本。我在多个团队里看到过一个共同规律凡是能把证据补全做实做细的团队它们的 Agent 演进速度惊人地快半年时间就能从做演示都要看运气进化到处理日常告警基本靠谱凡是跳过这一步直接拿日志灌模型的团队几乎都会在同一个地方反复撞墙。所以如果你正在做运维 Agent 的自学习建设别急着上大模型、别急着搞微调。先回去看看你们团队的历史故障记录试着把最近一次故障的完整证据链补出来。你会发现这一步走通了后面所有的路都顺了。