【AIOPS】当运维 Agent 开始自己学：证据补全才是自学习的真门槛

早期 AIOps 的标准范式是"知识库 + Yes/No + 人工补充"------这套东西在样本已知、特征明确的场景还行，但真实故障从不按历史剧本走 。AI 真正"自学习"的临界点不是"知识库越长越大"，而是学会在证据不足时自己追问、自己判断、自己剪枝 。下面拆开讲"能问 / 能裁 / 能判"这三种能力各自怎么提升------L1 知识库只是起点，L2 行为校准才是核心。

写在前面

上一篇我们讲了"AI 不放权，只借权"------讲的是执行层的安全。执行层保安全，决策层保准确------AI Agent 才算真正能用。

这一篇我们切到决策层。运维 AI 落地的真正分水岭，不是"能不能查日志"，而是"在证据不全的时候，AI 会不会自己追问"。

我先讲一个让我自己下不去手的事故------它就是这篇文章存在的全部理由。

【事故回放】

那是我们 AIOps 平台上线后的第二个月。生产环境某核心服务报错率突增，AI 在两次推理循环里依次暴露了三种"不会"：

不会问：假设根因是"上游数据库慢查询"，调了一次慢查询工具，没拿到证据，但没去追问变更、配置、依赖拓扑同样会引发雪崩的源头------默认"数据库是高频根因，那它就是"。
不会裁：慢查询返回"未发现明显异常"------这明明是反向证据，AI 却当成"我没找对工具"，继续在这条错误假设上，又空转调了三次工具。
不会判：6 次调用全部阴性，AI 仍要进第 7 次循环------不知道"该停了、把上下文交回给老王"。

老王接管，10 分钟手查发现真因：前一天晚上一个配置中心把下游 RPC 超时从 500ms 改成了 1ms，导致全链路雪崩------变更记录、配置 diff 全在那，AI 一次都没问过。

我盯着那段日志看了一个小时，没怪 AI 推理得不准------我想明白的是另一件事：

AI 的失败不是"知道得不够多"，是三种能力同时缺位------不会问、不会裁、不会判------这跟"往知识库反哺多少案例"完全无关。

那天之后我推翻了一版设计稿、拆掉"反哺 LLM"那条线，开始重写一版"行为校准"------让 AI 学会三件事：证据不够时该问什么、证据反驳时该切假设、推理走不下去时该停。下面就是这一版的完整设计。

一个细节说明 ：上面事故里 AI 推的根因没有触发任何执行（kill SQL / 重启）------这是上一篇《AI 不放权只借权》里四层闸门 + HITL 兜底 的结果。所以那次损失是「AI 推错 + 浪费老王 10 分钟」，不是"误执行" ------上一篇保住了"不会出大事"，这一篇要解决"别再让老王替 AI 擦屁股"。

我自己的 AIOps 平台是去年（2025）下半年跑起来的。一开始我也没想太远，塞知识库、跑 RAG，不行就靠人补。但真实生产里的故障从不会按"命中关键字"的方式发生------知识库里没完全一样的案例，AI 要么瞎推一个、要么直接说"我不知道"。

越往后做我越发现，"自学习 = 知识库反哺"这个等式是错的 。反哺再多案例，AI 也只是更会复述，不会更会推理。真正的自学习，是推理能力本身在变强------具体就是下面要拆的「能问 / 能裁 / 能判」三种能力。

一、先说结论：自学习的核心不是知识库，是"能问 / 能裁 / 能判"

如果让我重新定义"AI 是不是在自学习"，我会问三个问题：

能问：证据不足时，AI 会不会主动调工具去取证，而不是直接认输？
能裁：取到一批证据后，AI 会不会快速否决错误假设，而不是在错路上死磕？
能判：推理到一半，AI 会不会自己判断"该不该停"，而不是非要撞到工具耗尽才停？

这三种能力，单独看每一种都跟"知识库大小"无关。把向量库塞到 100 万条历史事件，也提升不了"会不会问"------因为"问什么"是推理能力，不是检索能力。

L1 知识库还停留在"找历史最像的"框架里打转，真正的自学习发生在 L2------证据补全的推理循环里。下面把"能问 / 能裁 / 能判"三种能力拆开讲。

二、L1 知识库检索：起点，但不是自学习

L1 的范式大家应该都熟：把历史故障、Runbook、解决方案塞进向量库；新告警来了，Top-K 召回最相似的几条；让 LLM 基于召回的"已知案例"回答。

这条路有两个致命短板：

知识库覆盖度是硬天花板------历史没见过的故障类型，AI 直接哑火
相似度匹配是"找过去最像的"，不是"找现在最对的"------同一种症状（比如 CPU 95%）在不同业务、变更、上下游下，根因天差地别

更关键的问题 ：L1 提升的只是"AI 知道什么"，跟"AI 会不会推理"是两码事。一个塞满 100 万条故障的知识库，不会让 AI 学会在"找不到相似案例"时自己去找证据------它只会让 AI 学会更自信地复述错误结论。

所以 L1 只能做"打底"------给 L2 提供"初始假设"，让 L2 在这些假设上接着去验证。L1 单独撑不起生产，更撑不起"自学习"这个标签。

L1 的真正定位："我已经知道什么"，不是"现在发生了什么"------也跟"会不会推理"无关。

三、L2 证据补全：自学习的真正发生地

L2 才是真正的核心。核心思想只有一句话：

AI 在证据不足时，会主动调工具去追问。

但"会追问"这三个字拆开看，是三种独立的能力。下面分别讲。

3.1 能问------证据池 + 怎么知道"该问什么"

要让 AI 能"追问"，前提是它得知道"能去哪儿问"。我把 AI 可调用的"证据源"分成 6 类------这是行业内比较通行的分法（Microsoft AI SRE 用了类似分类）：

指标（Metrics）：CPU、内存、QPS、延迟、错误率、连接数
日志（Logs）：Error 日志、堆栈、Drain 聚类
链路（Traces）：调用链、慢 Span、错误 Span
变更（Changes） ：最近发布、配置变更、扩容、灰度、回滚------70% 以上的故障跟近期变更有关 （NIDA 白皮书数据）
配置（Configs）：环境变量、特性开关、资源配额
拓扑（Topology）：服务依赖、CMDB、DAG

这 6 类证据，都通过 MCP 工具暴露给 Agent。每个 MCP Server 封装一类数据源的查询能力，返回结构化 JSON------这是 LLM 与外部系统的"受控通道"。

但"能问"的关键不是"知道有哪些工具"，是"知道下一步该调哪个工具"。这个能力直接决定了循环的效率------问对了，可能 3 次循环就收敛；问错了，可能 10 次还在原地打转。

3.2 能裁------快速否决错误假设

推理过程中，最浪费时间的不是"问不到证据"，是"在错误假设上空转"。

一个典型的反面案例：AI 假设 H1 = "OOM 导致 CPU 高"，于是调了 GC 工具、堆内存工具、线程栈工具------每个工具都返回"未发现明显异常"。AI 继续调、继续调，第 5 次循环才发现假设 H1 不对。这 5 次循环全白跑。

真正老练的 SRE 看到前两个工具返回阴性，第 3 次就该切假设了------这是经验，也是"能裁"的能力。

"能裁"怎么实现？我用一个简单的设计：每次循环后做反向证据检测------

python 复制代码

# 伪代码：反向证据检测
def should_switch_hypothesis(hypothesis, evidence_pool):
    """
    Critic 角色：判断"假设是否被证据反驳"
    ★ 关键：不是"无矛盾 = 被支持"，是"无矛盾 + 无支持 = 待定"
    """
    support_count = count_supporting(hypothesis, evidence_pool)
    contradict_count = count_contradicting(hypothesis, evidence_pool)

    if contradict_count > 0 and support_count == 0:
        return True, "假设被反驳"
    if support_count == 0 and len(evidence_pool) >= 2:
        return True, "未获支持，循环 2 次仍无正面证据"
    return False, ""

这里有个微软 AI SRE 项目踩过的真实坑特别值得提：他们最早的 Critic 把"SUPPORTED"定义为"无矛盾"------结果是没数据就什么都没矛盾，零证据的假设被洗成"已验证"。所以我把"无矛盾 ≠ 被支持"写成伪代码里的一行注释，这是真实的教训。

"能裁"提升的方向 ：不是塞更多历史案例，是让 Critic 更懂"什么算反驳、什么算未支持" 。这里有个进阶版的工程实践------Samsung Research 2026-08 的 Latent Critic：用 LoRA adapter 把"哪里 grounding 不足"内嵌到 base LLM 的生成过程 （near-zero latency，0.966 AUROC），而不是"生成完再调一个独立 LLM 二次评判"------后者慢、还容易在 surface text 上漏判。我们工程上做不到那么深，但 §3.2 的"反向证据检测"伪代码是同样的思路：Critic 必须挂上"证据"这个外部信号，不能纯靠 prompt 让 LLM 自己反思------这跟 §3.4 开头说的"生成器-验证器差距"完全一致。

3.3 能判------什么时候该停

L2 不是万能的。三种情况必须停下来交人：

置信度达到 0.85------证据链闭合，可以下结论
循环次数耗尽------AI 自己也拿不准，再问下去也是空转
多假设无法区分------H1/H2/H3 置信度都差不多，没法收敛

这三种情况都触发 HITL 兜底------不是上一篇那种"写操作人工批准"的 HITL，是**"AI 把已搜集的证据 + 待证假设 + 推荐方向整理成简报，推送给工程师"**。工程师补证据或选定假设，再回到循环。

"能判"的能力体现在"AI 知道什么时候该停"------不是非要撞到工具耗尽、不是非要等到循环用完才交人。优秀的 SRE 知道"这个故障我看不出根因，停一下、让老王看看"------AI 也要学会这个判断。

3.4 这三种能力怎么"自学习"

这才是全文最关键的一节------因为很多文章会写"AI 自学习"，但一问到"具体怎么学"，就含糊地说"通过事件反哺知识库"。

我的观点 ：三种能力各自有独立的提升路径，而且不靠"知识库变大"。

这里我得先说一个被业内反复验证过的反直觉结论 ：让 LLM 「检查自己的工作」（即纯 prompt 让它自己反思）会让准确度变差 。Huang et al. (ICLR 2024) 在多个推理 benchmark 上反复验证了这一点。但 Reflexion (Shinn et al., NeurIPS 2023) 看起来就是同一种机制、却能把 HumanEval pass@1 从 80% 推到 91%------这个悖论怎么解？

解法是"生成器-验证器差距"（generator-verifier gap） ：Reflexion 的反思锚定了外部 oracle 信号 （单元测试 pass/fail）------验证器知道的比生成器多，纠正才有效；同模型、同 context、同信息量、纯 prompt 反思 = 多花 2x token、结果更差 。我们的 Critic 也一样------必须挂上外部证据信号，不能纯 prompt。

工业界给"自学习"起了个更准确的名字------「行为校准」(Behavior Calibration)：提升信号不是"知识量"，是"行为模式"。下面按「能问 / 能裁 / 能判」分别讲怎么落地行为校准。

3.4.1 「能问」的提升------工具选择策略优化

AI 每次"该问什么"，本质是一个策略选择问题：当前状态（假设 + 证据池）→ 下一步动作（调哪个工具、问什么参数）。

这个策略的提升路径是：

收集"工具调用轨迹"：每次循环里，AI 调用了哪个工具、传了什么参数、得到了什么结果、最终有没有帮助收敛------这些数据全部落库
离线分析"哪种调用模式最有效" ：同样的假设+证据状态，调 jvm_gc 工具 10 次后能收敛的，跟调 top 工具 10 次后还空转的，模式完全不同
把"有效模式"喂回 prompt 上下文 ：不是塞进向量库检索，而是作为 few-shot 例子直接放进 LLM 的 system prompt

关键区分 ：这种"学习"是调整 LLM 的工具选择偏好 ，不是"积累更多故障案例"。100 万条历史故障不会教 AI 下次问对工具，但 100 条"什么调用模式有效"的轨迹会 。这正好是 Microsoft ARTIST (2025) 的做法------不用 step-level 监督、用 outcome-based RL 直接训练"什么时候调什么工具"，比 baseline 高 22%。

3.4.2 「能裁」的提升------Critic 校准

「能裁」靠的是 Critic 模块。Critic 的校准路径：

收集"假设切换记录"：每次推理里，AI 切了哪几次假设、每次切换是因为"被反驳"还是"未支持"、切完之后的循环次数有没有减少
评估 Critic 的判断质量：把"实际结论"作为标签，反查 Critic 当初的"该切/不该切"判断对不对
调整 Critic 的判定阈值：通过率低的判定规则（比如"无矛盾 = 支持"）要么改掉、要么加重惩罚

这个过程也不需要"知识库变大"------它需要的是"推理轨迹 + 结论标签"这种带反馈信号的数据。

3.4.3 「能判」的提升------停止策略校准

「能判」靠的是"什么时候该停"的判断。校准路径：

收集"提前停 vs 耗尽循环"的效果对比 ：AI 在第 3 次循环就停 + 推 HITL，跟第 5 次循环耗尽再停，哪个最终结论更准、哪个用户接受度更高
回归"提前停的阈值"：在 0.85 / 0.7 / 0.6 三个置信度阈值上分别跑、对比效果
调整 prompt 里的停止规则

这条线正好对应"验证即生成"的不对称------DeepVerifier 提出的 asymmetry thesis："验证比生成便宜 "。把"该不该停"这件事交给一个轻量级验证器（置信度评估 + HITL 兜底），而不是让 LLM 继续生成更多 token 来"算"该不该停------这本身就是自学习方向上的工程优化。

三种能力的自学习，共享一个底层动作------"把推理轨迹 + 结论标签结构化落库"------但落库之后不是塞进向量检索，而是用来调整 LLM 的 prompt / Critic 的判定规则 / 停止阈值。

这才是"自学习"的真正含义：不是"AI 看到更多案例"，是"AI 的推理策略本身在变好"。

整条链路串起来看是这样：L1 给出初始假设，L2 在 ReAct 循环里用"能问/能裁/能判"三条主张取证、切假设、判停，证据不足就交给人；而三能力的"学习信号"最终反哺回 L2 的三个校准点。

四、那"反哺"放哪？------目标是 L2 的校准点，不是知识库

你可能会问：3.4 说自学习靠"推理轨迹 + 结论标签"来调整，那这些数据最后反哺到哪里？难道不是回填知识库、让下次召回更准吗？

这正是最容易翻车的地方。 如果你把轨迹回填进 L1 知识库------那就又绕回"案例越多 = 推理越好"的老路，而且会撞上两个坑：

反哺的是"案例"，不是"策略"------知识库召回的是"上次类似的故障"，对当前这次推理帮助有限，因为证据完全不同
"知识"会过期------生产根因模式随版本、业务、流量特征漂移，反哺越频繁、污染越快

我自己在设计稿里也走过这个弯路：最早把"事件反哺"当独立的一层来做，结果发现只要它单独成层，就容易往"反哺知识库"上引 。后来我把反哺的终点收敛回 L2------自学习的反哺，目标是 L2 的三个校准点：

事件日记里的"这次假设切换有/无效" → 校准「能问」的 prompt 规则
轨迹数据里的"什么调用模式有效" → 校准「能裁」的 Critic 输出
停止记录里的"提前停 vs 耗尽" → 校准「能判」的停止阈值

也就是说：并没有一个独立的"反哺层"，反哺就是 L2 行为校准自身在持续迭代 。工业界对这件事有更严谨的说法------NSER (arXiv:2605.09419) 区分"被动复用（passive reuse）"和"主动推理（active reasoning）"，主张 LLM 在 replay 阶段做规则归纳 + 符号 grounding，而不是把旧轨迹当"知识"塞回去；Self-Synthesized Rehearsal (SSR, 2024) 更进一步------不存真实数据，让 LLM 自己合成伪样本 。两者的共同点都是：反哺的是抽象出的"模式/规则"，不是历史原话。

反哺不是"越多越好"，是"越准越好"------把轨迹错投进知识库，等于让下次 AI 更自信地复述错误。

五、行业对比：4 套方案横向看

我把行业里几套有代表性的方案横向对比一下：

维度	Microsoft AI SRE	RunbookHermes	网宿安全 AI 反哺	本文方案
证据策略	多 Agent 分头取证，Supervisor 协调	动态 MCP + RAG 同循环融合	知识库 + MCP 服务配套	L1 召回 + L2 假设-取证循环
自学习的重点	Critic Agent 校准（学怎么判断证据够不够）	MCP+RAG 同循环（学怎么动态取证）	AI 反哺安全产品能力	L2 三种能力：能问/能裁/能判
HITL 触发	强证据不足即人工兜底	置信度低 / 工具耗尽即停	高风险操作人工介入	置信度 ≥ 0.85 停 / 循环耗尽 / 多假设均分
学习数据	推理轨迹 + 结论标签	推理循环的同循环融合	AI 反哺安全产品	工具调用轨迹 + Critic 判定 + 停止策略
反哺终点	事件日记结构化记录	回填知识库（待完善）	AI 反哺安全产品	L2 三个校准点（非知识库）
核心亮点	Glass-box 多 Agent 推理	MCP+RAG 同循环	80% 效率提升（公开数据）	推理策略本身可校准
适用场景	金融/合规强场景	通用 AIOps 落地	安全运营	通用运维 + 可扩展到合规场景

对比资料来源：

Microsoft AI SRE --- PraveenaKumaran/ai-sre-agent
RunbookHermes --- 腾讯云开发者
网宿安全 AI 反哺 --- 2025 乌镇互联网之光

三家都走到"自学习"的临界点 ------但路径不同：Microsoft 走"多 Agent 协同 + 严格 Critic"、RunbookHermes 走"MCP+RAG 同循环"、网宿走"AI 反哺安全产品"。本文的差异点 是明确反对"自学习 = 知识库变大"------把自学习定位在 L2 推理能力本身的校准，反哺的终点是 L2 的校准点，不是知识库。

六、和上一篇怎么分工：自学习是决策层，借权是执行层

两篇连起来看是个完整的图景。

层级	上一篇（执行层）	这一篇（决策层）
关注点	怎么让 AI 安全执行	怎么让 AI 准确推理
核心机制	身份/授权/管控/审计四层闸门	L2 证据补全 + 能问/能裁/能判
HITL 触发	写操作 / 灾难命令	证据不足 / 多假设均分
风险上限	越权 / 误操作	误判 / 推理策略僵化

执行层保安全，决策层保准确------两条腿都站住了，AI Agent 才算真正能在生产跑。

（一句话预告：L2 调的所有证据池，都是 MCP Server 暴露的------工具层设计是 L2 能不能稳的根，这块可以在另一篇展开。）

附录 · 给技术管理者的「读完就能学走」清单

如果你不需要"AI 会推理"的技术细节，只想拿走可落地的判断框架，这一份清单给你------每条都有可验证的门槛，不是"凭感觉"的判断：

阶段	关键判断	验证门槛（怎么算做到）	反模式（一定别这么做）
认知	自学习 = 行为校准，不是知识库反哺	团队成员能口头讲清"能问/能裁/能判"三种能力的差异	把"案例越多 = AI 越准"当默认假设
立项	L1 知识库是起点，L2 行为校准是核心	立项书里必须有"L2 行为校准"这一项的预算和人头	立项时只规划 L1，跳过 L2 推理能力校准
设计	Critic 必须挂外部 oracle 信号（真实证据、真实切换），不能纯 prompt	Critic 输出有可追溯的"引用证据" + 人工复核发现"无矛盾 ≠ 被支持"的判定	让 LLM 自己反思、用自己的反思当 Critic 输出
落地节奏	先把 L2 三能力的推理轨迹落库跑通，再校准	至少积累 N 条真实事件推理轨迹 + 结论标签（N 取决于你们告警量，但少于 100 条别谈"自学习"）	一上来就训模型、调 prompt；没数据就调 = 赌
风险门	校准用的轨迹必须过质量关：0.85 置信度 + 人工抽检 5-10%，错轨迹会带偏「能问/能裁/能判」	校准前后跑准确度对比报告（A/B），校准后更准才算数	任何事件都自动反哺------ICLR 2024 (Huang et al.) 已经验证过"无外部信号的反思会让准确度退化"
团队能力	至少 1 个懂 Critic 设计 + 1 个懂轨迹分析	团队里至少有 1 人能独立写出 §3.2 那种"反向证据检测"伪代码	全员 prompt 工程师------没有 Critic 能力 = 上 L2 就是在赌

一句话带回去："自学习"不是"案例库变大"，是"AI 行为可校准"------前者是数据问题，后者是工程问题。

写在最后

回到开头那个问题：AI 真正"自学习"的拐点是什么？

不是"知识库越长越大"，是"AI 的推理策略本身在变好"。具体就是三种能力：

能问：知道下一步该调哪个工具、问什么参数
能裁：能快速否决错误假设、不在空转里浪费时间
能判：知道什么时候该停、把上下文清晰地交回人

这三种能力，都不靠"案例积累"来提升，靠的是"推理轨迹 + 结论标签"这种带反馈信号的数据，用来调整 LLM 的 prompt、Critic 的判定规则、停止阈值。

L1 知识库检索是起点，但不能撑起生产；L2 证据补全才是核心，才是自学习的真正发生地------反哺的终点收敛在 L2 的三个校准点上，而不是回填知识库，这样才不会被"过期案例"反向污染。

这套东西目前在我们内部 AIOps 平台里规划落地中 ------L1 已经跑着、L2 推理策略校准在设计稿阶段。它不是最省事的方案，但路径对了，能力提升是结构化的，不是赌出来的。

如果你也在做运维 Agent，我的建议就一句：

别只教它"会什么"，要教它"不会的时候怎么去问、怎么判断"------推理能力本身的可校准，比案例库的可膨胀重要得多。

项目信息这套"证据补全 + 能问/能裁/能判"的设计在我们内部 AI 运维平台（ksjms · ai_platform）规划落地中。执行层方案见《【AIOPS】给运维 Agent 配高权账号之前，先想清楚一件事：AI 不放权，只借权》。 GitHub：github.com/magicCzc