运维智能体不再每次从零查故障：把处置经验写成检测器和手册，复发故障解决快2.1倍
核心概要
面向Kubernetes分布式应用的运维智能体SDO把每次故障处置沉淀为可复用的运维记忆：手册记录可参数化的诊断与修复步骤，检测器用非LLM代码在集群状态上判断何时该调用哪本手册，架构摘要则把手册中的角色绑定到当前应用。在11个开源微服务应用上，SDO在复发故障上把解决时间降低52%，中位解决时间从584秒降到282秒、token从540万降到220万；从源码部署应用时，运维记忆把部署时间与token用量降低47.5%。
深度剖析
运维智能体开始把处置过的故障变成可复用的运维记忆，而不是每次事件都重新推导原因。 此前的LLM运维智能体按单次事件工作，事件结束后丢弃工作上下文，无法区分应用是否已降级，需要人工或外部告警触发，遇到相似故障仍要从头排查。 在11个开源微服务应用上，SDO在复发故障上把解决时间降低52%，中位解决时间从584秒降到282秒、token从540万降到220万，解决速度快2.1倍、token少2.5倍。
记忆由三类可读、可版本控制的产物组成，检测器负责在稳态下低成本判断何时该调用哪本手册。 此前把历史事件原文存入向量库或让模型自行检索的做法，会因症状相似而召回根因不同的记录，检索开销还随事件数线性增长。 在固定手册语料上，检测器检索的精确率0.48、召回率0.73，与让模型自行检索的0.53和0.77接近，但单次检索耗时10.8秒、消耗0个token，而模型检索为483.4秒和14.8万token。
从源码把应用部署到Kubernetes也纳入同一套记忆，部署经验跨应用复用。 没有运维记忆时，部署智能体在构建与依赖排查中反复重新发现服务角色和构建命令，长会话会耗尽上下文窗口。 在11个开源应用上，带运维记忆的部署把部署时间与token用量降低47.5%，迭代次数减少2.5次；独立健康裁判把通过外部负载生成器验证的部署从4/11提升到11/11。
启示与展望
这套结果针对Kubernetes上运行的微服务应用，评测覆盖11个开源应用，其中故障解决实验使用其中4个应用、200个事件的确定性事件流，部署实验使用全部11个应用。检测器以固定接口写成Go代码，手册与架构摘要以版本控制文件存放在应用仓库中，因此适用场景是具备源码仓库与集群状态可读的部署。
在无重叠的新故障上，30个事件中有9个触发了检测器，但召回的每本手册都是误报，智能体需要检查并丢弃它们；此时中位token比无记忆配置高17.7%，解决时间与准确率相近。测试期间记忆被冻结，智能体无法像在线运行时那样修剪误触发的检测器。