企业官网建设流程全解析

“会的不难，难的不会”——这句话用在当下的运维 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(host=prod-db-01) [14:06:20] INFO agent-tool-call: kill_connection(session_id=1024, 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/800
• 14: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-01，MySQL 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 的自学习建设，别急着上大模型、别急着搞微调。先回去看看你们团队的历史故障记录，试着把最近一次故障的完整证据链补出来。你会发现，这一步走通了，后面所有的路都顺了。