让Agent运维随着软件稳定进化：拆解腾讯云CloudMate

引言

上一篇文章中，我们回顾了目前AIOps的前沿进展。从排查性能的角度讲，Context Engineering（上下文工程）成为AI运维领域的核心方法论：通过结构化的方式收集系统状态、历史经验、专家知识等上下文信息，让大语言模型能够给出解决方案。当下的系统状态加上一个稳定的知识库，就可以极大地释放大语言模型的潜力。然而，目前已披露的基于知识库的系统都忽视了软件工程中的一个底层问题：软件本身的迭代。在高速发展的软件系统中，文档会过期，知识会过期，这让所有基于知识库的智能运维系统都面临着巨大的挑战。

挑战来自两个维度：怎么让知识库跟上急速演进的代码？如何确保软件演进不破坏智能运维的有效性？腾讯云CloudMate首次在这两个维度上做出系统化探索。

本文基于CloudMate在2025年GOPS上海站的分享。由于披露的技术细节有限，本文专注于高层设计和带来的启示。

知识库自进化的困境

"知识库需要自动更新"这个想法并不新鲜。

早在AI运维兴起之前，许多团队就意识到手工维护知识库的局限性。总有团队提出要建立"自进化的知识系统"，试图让文档跟上软件系统的演进。在LLM横空出世后，RAG的兴起又带来了一波"动态更新知识库"的热潮。喊着要做的人很多，真正落地的成功案例却寥寥无几。究其根本，在于知识验证本身充满了复杂性——对知识库更新的质量难以量化，最终大量无序的更新反而让知识库失去控制。

考虑一个典型场景：系统进行服务拆分，API接口变更。工程师更新了API文档，但知识库中引用旧API的排查手册、诊断流程、配置指南可能遍布各处。

每增加一份新文档，这些潜在的冲突点以 O(n) 的速度增长——它可能与任何一份旧文档产生语义冲突、接口冲突或假设冲突。而要验证这些冲突，需要理解每份文档的上下文、依赖关系和隐含假设，这远超人工维护的能力边界。

这个难题还有另一个维度。从被运维软件的角度看，系统本身的可运维性同样难以评估——虽然我们有各种可观测性的原则，但具体到某个软件系统，我们很难准确判断它对运维Agent是否友好、是否适合自动化运维。当软件持续演进时，如何确保每次变更都不会引入破坏Agent可运维性的问题？

这正是CloudMate区别于其它已有产品最重要的差异，也是本文讨论的核心：在动态演进的环境中，如何建立稳定可靠的AI运维能力。

CloudMate的解决方案

CloudMate的核心思路是：既然我们难以有效验证知识库本身的质量，那就直接验证最终结果。这个思路同时解决了两个维度的迭代稳定性问题——软件系统的更新无法破坏Agent的可运维性，知识库的更新无法降低Agent的问题解决能力。

下图是笔者根据分享重绘的CloudMate的完整架构：

CloudMate采用了双层架构设计，将在线故障排查与离线知识进化分离：

上层：在线故障排查系统

这是传统的Agent循环，包含三个核心组件：

知识库：存储Agent执行任务所需的领域知识，包括业务拓扑、故障模式库、专家诊断逻辑以及标准化的排障流程等

Agent循环：经典的"规划-执行-观察"循环，Agent根据知识库的指导制定排查计划，调用工具执行，观察结果并继续迭代

工具库：提供日志工具、指标工具、DB工具等实际的排障能力

下层：离线验证与进化系统

这是CloudMate的核心创新。它基于一个简单的原则：最好的验证环境是实践本身——知识是否有效，最可靠的检验方式来自真实任务中的使用。系统通过三个组件在沙箱环境中实现这一目标：

沙箱环境提供隔离的验证空间，确保知识更新无法影响线上服务。案例库存储Agent在历史任务执行时产生的完整轨迹（规划-执行-观察），包括思考过程、调用的工具、返回的结果等。这些轨迹有两个作用：一是作为知识进化的基准案例，二是作为系统可运维性的回归测试。

探索闭环则是系统进化的核心。CloudMate团队为不同场景设置了基准案例，每个案例都有明确可验证的完成条件。系统综合客观指标（如耗时、工具调用次数）和监督模型的主观评分来衡量方案质量。

具体流程是：多个Agent在沙箱中并行重试基准案例 → 评分系统根据成功或失败的尝试总结出新知识 → 这些知识不会直接commit，而是触发基准案例的重新验证 → 只有在Agent在所有基准案例上达到相似或更好性能时，更新才会被接受。这个闭环把难以完成的知识库质量分析转换成了可测量可维护的最终结果。并以这个方式确保知识库的质量。

与此同时，案例库中的历史轨迹还用于另一个维度的保障：当被运维系统推送变更时，这些轨迹会重新运行，使用最新的系统状态获取工具调用结果。如果结果与历史记录存在显著差异，说明变更可能破坏了系统的可运维性，需要进一步调查。

整个系统从两个维度保证了整套运维系统的稳定演进，探索闭环确保知识库进化不退化，案例库确保被运维系统的演进不会破坏运维系统的性能。从两个角度构建了这么一个AI-Native的系统架构。

从设计看本质

介绍完CloudMate的设计，那么这套系统真的有效吗？

遗憾的是，分享中未披露具体的性能数据，比如知识库更新的通过率、案例库捕获问题的数量、或Agent能力的提升幅度。但即使缺少量化指标，我们仍然可以从设计本身看出CloudMate解决问题的核心思路。

回顾本文开头提出的两个挑战：

知识库如何跟上代码演进？→ CloudMate通过探索闭环让知识库自动更新，并用基准案例验证更新后能力不会降低

软件演进如何避免破坏可运维性？→ CloudMate通过案例库将历史执行轨迹作为回归测试，及时发现破坏性变更

探索闭环关注的是"用了这个知识后，Agent能否解决基准任务"。案例库关注的是"变更后Agent的执行轨迹是否发生异常变化"。两个机制都聚焦于最终效果的验证。

启示与实践

传统思路试图验证知识的"正确性"：这份文档写得对不对？这个诊断逻辑符不符合规范？这个流程有没有漏洞？但"正确性"是主观的、难以量化的、依赖上下文的。

CloudMate换了一个角度：无论知识库里写了什么，只关心Agent最终能否解决问题，从验证"输入"（知识）转向验证"输出"（能力）。

这种思路在软件工程中其实应用颇多，用测试、benchmark评估系统能力。CloudMate将同样的工程哲学应用到AI系统：用基准案例定义能力标准，用自动化测试验证达成情况，用回归测试保证不退化。为"知识质量"这个模糊概念找到了可操作的度量方式。从而引出了一个极为重要的原则：

将AI系统的质量保障建立在可验证的能力输出上，而非难以量化的知识输入上。

CloudMate的设计恰恰反映了这个原则。

在架构设计上，它采用了双库分离的策略，将"应该知道什么"（知识库）和"实际能做什么"（案例库）分离，类比软件工程中的规格说明与测试用例。知识库定义期望，案例库验证现实。这代表思维方式的根本转变：Agent需要像API、数据库一样，得到同样严格的管理和质量保障。

在流程集成的角度，CloudMate将Agent能力管理融入DevOps中。在CI/CD pipeline中加入Agent能力验证、知识库同步、能力回归测试；在监控系统中跟踪Agent能力健康度（基准任务通过率）和知识库时效性（更新时间与系统变更的时间差）。

在质量保障层面，CloudMate将持续验证作为必需的基础设施。CloudMate的探索闭环确保知识库进化不退化，案例库确保系统演进不破坏可运维性。

尚未回答的问题

评估机制的悖论

CloudMate使用"客观指标+监督模型打分"的综合评估体系。客观指标（如耗时、工具调用次数）相对可靠，但监督模型打分引入了一个根本性的悖论。

CloudMate的核心洞察是"验证能力而非知识"，因为我们难以评估知识本身的好坏。但在探索闭环中，监督模型本质上还是在试图判断Agent的执行过程、推理路径、工具选择是否合理。这和评价"知识好不好"面临同样的困境：如果我们真的知道什么样的执行过程是好的，还需要监督LLM做什么？

这个悖论指向了评估机制的核心问题：我们用LLM是因为问题太复杂，人类难以定义"好的方案"；但要验证LLM的输出，又需要另一个模型来定义"好的方案"。监督模型的标准从何而来？它如何避免引入新的偏见？当业务场景演进时，这些标准如何更新？

演讲中未披露CloudMate如何解决这个悖论，也未说明监督模型的评估标准是如何确定的。这些细节对于理解系统的可靠性至关重要。

验证的边界

沙箱是验证的基础，但并非所有故障都能安全重放。技术上，并发竞争导致的间歇性故障、依赖真实用户行为的问题、分布式系统的复杂交互都难以完整复现。安全上，涉及用户隐私数据的场景、包含高风险操作的排查过程、可能影响外部系统的测试也不宜在沙箱中重放。

这些边界直接限制了验证的完备性。对于超出边界的场景，可能仍需要人工审核或其他补充手段，这在某种程度上制约了自动化的程度。

结语

传统AI系统假设知识静态、环境稳定，但现实恰恰相反——软件在迭代，知识会过期。CloudMate的先锋探索将这个问题拉到了我们眼前。

CloudMate为AI运维的稳定进化提供了一个清晰的思路：验证能力而非知识。通过双层架构，它让知识库能够自我进化的同时保持可控——探索闭环确保进化不退化，案例库确保系统演进不破坏可运维性。这个设计揭示了AI-Native系统的核心原则：用可验证的能力输出，替代难以量化的知识输入。

但CloudMate也让我们看到了挑战：评估机制的可信度、验证能力的边界。这些问题需要整个行业共同探索。我们期待CloudMate团队分享更多技术细节。这些问题也需要我们作为实践者去亲自寻找答案。