AIOps 系统如何与软件共同演进：从 CloudMate 看知识库自进化
上一篇文章中，我们回顾了目前 AIOps 的前沿进展。从排查性能的角度讲，Context Engineering（上下文工程）成为 AI 运维领域的核心方法论。其核心思想优雅而直接：通过结构化的方式收集系统状态、历史经验、专家知识等上下文信息，让大语言模型能够像经验丰富的工程师一样理解问题并给出解决方案。当下的系统状态加上一个稳定的历史知识库，就可以极大地释放大语言模型的潜力。
智能运维与知识库的关系极为密切。以 RCACopilot 为例，它的成功依赖于微软邮件服务过去积攒的庞大根因分析数据库——不使用这个数据库的话，性能会骤降为原来的几十分之一，变得几乎不可用。然而，目前已披露的基于知识库的系统几乎都忽视了软件工程中的一个底层问题：软件本身的迭代。在高速发展的软件系统中，文档会过期，知识会过期，这让所有基于知识库的智能运维系统都面临着巨大的挑战。
挑战来自两个维度：一方面，怎么让知识库跟上急速演进的代码？另一方面，软件系统的演进如何避免破坏智能运维的有效性？
腾讯云的 CloudMate 运维系统第一次在这两个维度上做出了系统化探索。
本文基于 CloudMate 在 2025 年 GOPS 上海站的分享。由于披露的技术细节有限，本文专注于高层设计和带来的启示。期待团队未来分享更多实践细节。
知识库自进化的困境
“知识库需要自动更新”这个想法并不新鲜。
早在 AI 运维兴起之前，许多团队就意识到手工维护知识库的局限性。总有团队提出要建立”自进化的知识系统”，试图让文档跟上软件系统的演进。在 LLM 横空出世后，RAG 的兴起又带来了一波”动态更新知识库”的热潮。喊着要做的人很多，真正落地的成功案例却寥寥无几。究其根本，在于知识验证本身充满了复杂性——对知识库更新的质量难以量化，最终大量无序的更新反而让知识库失去控制。
考虑一个典型场景：系统进行了一次服务拆分，将原来的单体监控 API /metrics/query 拆分为 /metrics/service/query 和 /metrics/infrastructure/query。工程师按规范更新了 API 文档，将新的调用方式写入知识库。
这个简单的更新在知识库中的影响是难以被估计的：
- 某个”CPU 异常排查手册”中引用的旧 API，现在会返回 404 错误
- 某个”服务响应慢诊断流程”假设监控数据是统一的，现在需要分别查询两个端点
- 一年前的”告警规则配置指南”中的示例代码全部失效
每增加一份新文档，这些潜在的冲突点以 O(n) 的速度增长——它可能与任何一份旧文档产生语义冲突、接口冲突或假设冲突。而要验证这些冲突，需要理解每份文档的上下文、依赖关系和隐含假设，这远超人工维护的能力边界。
这个难题还有另一个维度。从被运维软件的角度看，系统本身的可运维性同样难以评估——虽然我们有各种原则如运维左移、可观测性等，但具体到某个软件系统，我们很难准确判断它对 Agent 是否友好、是否适合自动化运维。当软件持续演进时，如何确保每次变更都不会引入破坏 Agent 可运维性的问题？
这正是 CloudMate 区别于其它已有产品最重要的差异，也是本文讨论的核心：在动态演进的环境中，如何建立稳定可靠的 AI 运维能力。
CloudMate 的解决方案
CloudMate 的核心思路是：既然我们难以有效验证知识库本身的质量，那就直接验证最终结果。这个思路同时解决了两个维度的迭代稳定性问题——软件系统的更新无法破坏 Agent 的可运维性，知识库的更新无法降低 Agent 的问题解决能力。
CloudMate 采用了双层架构设计，将在线故障排查与离线知识进化分离：
上层：在线故障排查系统
这是传统的 Agent 循环，包含三个核心组件：
- 知识库：存储 Agent 执行任务所需的领域知识，包括业务拓扑、故障模式库、专家诊断逻辑以及标准化的排障流程等
- Agent 循环：经典的”规划-执行-观察”循环，Agent 根据知识库的指导制定排查计划，调用工具执行，观察结果并继续迭代
- 工具库：提供日志工具、指标工具、DB 工具等实际的排障能力
下层：离线验证与进化系统
这是 CloudMate 的核心创新。它基于一个简单的原则：最好的验证环境是实践本身——知识是否有效，最可靠的检验方式来自真实任务中的使用。系统通过三个组件在沙箱环境中实现这一目标：
沙箱环境提供隔离的验证空间，确保知识更新无法影响线上服务。案例库存储 Agent 在历史任务执行时产生的完整轨迹（规划-执行-观察），包括思考过程、调用的工具、返回的结果等。这些轨迹有两个作用：一是作为知识进化的基准案例，二是作为系统可运维性的回归测试。
探索闭环是整个系统的关键机制。CloudMate 团队为不同场景设置了基准案例，每个案例都有明确可验证的完成条件。具体流程是：多个 Agent 在沙箱中并行重试基准案例 → 评分系统根据成功或失败的尝试总结出新知识 → 这些知识不会直接 commit，而是触发基准案例的重新验证 → 只有达到相似或更好性能时，更新才会被接受。这确保了知识库的每次迭代都是进步。
与此同时，案例库中的历史轨迹还用于另一个维度的保障：当被运维系统推送变更时，这些轨迹会重新运行，使用最新的系统状态获取工具调用结果。如果结果与历史记录存在显著差异，说明变更可能破坏了系统的可运维性，需要进一步调查——可能需要更新文档，甚至调整变更本身。
整个系统形成双重保障：探索闭环确保知识库进化不退化，案例库确保系统演进不破坏可运维性。
从设计看本质
介绍完 CloudMate 的设计，那么这套系统真的有效吗？
遗憾的是，分享中未披露具体的性能数据。但即使缺少量化指标，我们仍然可以从设计本身看出 CloudMate 解决问题的核心思路。
回顾本文开头提出的两个挑战：
- 知识库如何跟上代码演进？→ CloudMate 通过探索闭环让知识库自动更新，并用基准案例验证更新后能力不会降低
- 软件演进如何避免破坏可运维性？→ CloudMate 通过案例库将历史执行轨迹作为回归测试，及时发现破坏性变更
探索闭环关注的是”用了这个知识后，Agent 能否解决基准任务”。案例库关注的是”变更后 Agent 的执行轨迹是否发生异常变化”。两个机制都聚焦于最终效果的验证。
启示与实践
传统思路试图验证知识的”正确性”：这份文档写得对不对？这个诊断逻辑符不符合规范？这个流程有没有漏洞？但”正确性”是主观的、难以量化的、依赖上下文的。
CloudMate 换了一个角度：无论知识库里写了什么，只关心 Agent 最终能否解决问题。这个转变代表了范式的跃迁——从验证”输入”（知识）转向验证”输出”（能力）。
这种思路在软件工程中早已证明有效：我们用测试、benchmark、压测来验证系统能力，而不是争论代码、算法或架构的”理论正确性”。
CloudMate 将同样的工程哲学应用到 AI 系统：用基准案例定义能力标准，用自动化测试验证达成情况，用回归测试保证不退化。这为”知识质量”这个模糊概念找到了可操作的度量方式——问题从”这个知识好不好”变成了”用了这个知识后，Agent 能力有没有提升”。前者无解，后者可测。
这正是业界反复提及却从未说清的”AI-Native”原则之一：将 AI 系统的质量保障建立在可验证的能力输出上，而非难以量化的知识输入上。CloudMate 的设计恰恰反映了这个原则。
尚未回答的问题
CloudMate 展示了 AI 系统自进化的一种可行路径，但由于演讲信息有限，一些关键机制的细节未被披露。这里讨论几个与核心主题紧密相关的问题。
评估机制的悖论
CloudMate 使用”客观指标 + 监督模型打分”的综合评估体系。客观指标（如耗时、工具调用次数）相对可靠，但监督模型打分引入了一个根本性的悖论。
CloudMate 的核心洞察是”验证能力而非知识”，因为我们难以评估知识本身的好坏。但在探索闭环中，监督模型本质上还是在试图评价 trajectory 好不好——判断 Agent 的执行过程、推理路径、工具选择是否合理。这和评价”知识好不好”面临同样的困境：如果我们真的知道什么样的 trajectory 是好的，还需要 LLM 做什么？直接写规则就行了。
监督模型的标准从何而来？它如何避免引入新的偏见？当业务场景演进时，这些标准如何更新？演讲中未披露 CloudMate 如何解决这个悖论，这些细节对于理解系统的可靠性至关重要。
验证的边界
沙箱是验证的基础，但并非所有故障都能安全重放。技术上，并发竞争导致的间歇性故障、依赖真实用户行为的问题、分布式系统的复杂交互都难以完整复现。这些边界直接限制了验证的完备性。
自动化的边界
即使大部分流程自动化，完全去除人类参与可能既不现实也不可取。关键问题是：如何识别”需要人工介入”的临界点？如何在自动化程度和可控性之间找到平衡？
CloudMate 展示了 AI 系统自进化的可能性，也让我们看到了根本性的挑战：评估机制的可信度、验证能力的边界、自动化与可控性的平衡。我们期待 CloudMate 团队分享更多技术细节，帮助行业理解这些挑战的解决路径。