从私域知识到智能 Agent：构建智能运维知识库

在 InfoQ 举办的 QCon 全球软件开发大会（北京站）上，抖音算法工程师王宁做了“从私域知识到智能 Agent：构建智能运维知识库”的演讲分享，他介绍了通过创新的知识沉淀、学习、生成与更新机制，将私域知识与 LLM 深度融合，构建更加智能和自主的运维系统的方法。并详解了 SOPAgent 这一全新架构，如何解决传统 AIOps 中遇到的难题，通过大语言模型的自主学习能力，让企业能够高效、智能地处理复杂的运维场景，从而大幅提升运维效率与准确性。

内容亮点

• 智能 Agent 的自主学习能力：LLM 如何从私域知识中自主学习、生成 Agent，减少业务人员的直接参与。

• 多模态数据的智能处理：如何有效整合图像、文本等多种形式的私域数据，提升知识的应用效果。

• 闭环的知识管理体系：知识的自动收集、学习、生成与更新，推动智能化运维的不断发展。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

随着现在基本已经进入大模型时代，人人都在谈论大模型，整个软件工程领域的人也基本都想用大模型去改造传统工作流。无论是公司内部还是整个行业，从目前趋势来看，似乎大模型将重构所有工作。我们也在尝试把大模型引入 AIOps 领域。从过去一段时间的经验来看，大家引入大模型的场景和方向中，最多的可能是智能客服。这是最接近自然语言模型能力的应用场景，也是最容易想到的用于提升效率、代替人工的场景。

在排障领域，利用大语言模型进行根因诊断。大语言模型在学习过程中已经掌握了故障专业知识，当系统指标状态出现异常，如 CPU 突增、流量突增，或者提供一段错误日志时，它能尝试推理出简单根因，助力排障流程自动化。

另一方面，我们利用大语言模型的生成能力。在日常工作中，如文档生成、周报生成、事故复盘报告等生成领域，大语言模型可以发挥作用。例如，让它整合多篇文档，分析过去一周的群聊内容，生成周报。此外，日志分析、告警分析、影响面分析、变更分析等场景也适合大语言模型。这些日志和变更事件工单是类自然语言数据，介于自然语言和代码之间，大模型对这类数据结构的分析更具优势。

我们还可以利用大语言模型自动化调用工作流，类似于现在提出的 Agent 概念。它能自动理解用户意图，比如在公司内部，通过自然语言指令唤起原本需要手动提交表单或填写准确参数调用 API 的功能，从而实现改造和提效。

在代码生成方面，现在大家写代码都会借助大语言模型辅助，不再使用辅助生成 IDE 的程序员会被视为落后。

我们之前尝试搭建诊断流程平台，试图将大语言模型引入工作流，但发现很难比专业团队构建出更简单易用、设计更合理或 UI 更好看的大语言模型工作流平台，因为开源方案众多，难以形成绝对领先优势。我们原本认为，作为运维团队，积累的传统运维工具，如 AIOps 算法、线上诊断小工具（如拉取日志、判断机器问题的工具）等，可以在短期内构建壁垒。但随着 MCP 概念的出现，未来这些工具可能都会成为通用的 MCP Server，供人开放式调用，从长期来看，运维工具也无法成为壁垒。

那 SRE 团队的竞争优势是什么呢？我们觉得，公司内经验丰富的 SRE 同学在收到报警时，只需查看曲线、扫一眼日志，就能大概知道问题所在，而新人 SRE 则需要对照 SOP 文档逐行排查，耗时较长。这种依靠 长期工作积累下来的经验和数据，才是真正的护城河。

过去一段时间，我们一直推广大语言模型的接入，但遇到了新挑战：可供大语言模型学习的专家经验已不够。大模型的优势在于自主学习决策、调用工具、推理，解决新问题和难题。然而，目前构建 Agent 时，需要 SRE 同学编写完善的 SOP 文档，这与我们设想的让 Agent 自主工作不符，Agent 的效果也完全依赖于 SRE 的专业程度。而且，让 SRE 投入时间写文档，难以判断是否真正实现了降本增效，Agent 的上限也受限于编写文档的 SRE 同学的经验。此外，并非所有 SRE 都是资深的，新人可能无法提供有效支持。因此，SRE 同学也需要一个统一平台来沉淀、管理、更新运维领域的知识。

具体来看，第一个方向是知识的沉淀和更新。在公司内部，私域知识通常散落在各平台文档、群聊（如收到严重告警时的故障群、oncall 群）以及视频会议记录、系统工单（如扩容工单）中。这些知识需要统一框架收集和处理，防止遗漏，因为随着时间推移，可能找不到当时的群聊记录或会议记录，且业务不断发展，知识也需要持续更新。同时，群聊中可能有图片，视频会议也需要多模态能力支持。

在知识学习方面，知识散落、新旧不一、重复、碎片化等问题突出。例如，去年的故障群知识可能已过时，老日志对线上无价值，不同同学写的文档内容重复，群聊中只有零星提及的知识碎片等。人工梳理成本高，我们考虑用大语言模型收集海量信息，做成向量数据库形式，方便后续检索和 SRE 同学使用。

我们收集海量知识后，可以通过私域知识生成排障领域特定问题的参考文档，尝试生成技术类文档（如复盘、架构设计文档），辅助提高工作效率。有了这些文档后，我们打算让 SOP 文档指导后续 Agent 搭建，同时在很多场景中，通过 Chat OPS（聊天操作）形式让大家进行知识检索和使用。

我们提出了一套 Agent 框架，涵盖知识采集、处理、生成和应用，是一套运维知识管理系统。我们希望通过这套系统提升 OnCall、故障处理、知识生成和工具使用的效率与准确性。这套系统的核心是依托大语言模型，处理图像文本等多模态数据，以及在群聊中总结、提取关键知识。

在知识收集方面，我们从运维场景中收集了多种来源、多种结构的数据，包括文本、图片、日志、工单等。在知识处理阶段，我们利用大语言模型进行数据清洗、分类、抽取和翻译，将其转化为结构化知识。在生成阶段，我们基于处理后的数据生成标准参考文档、工单摘要、历史知识库等运维知识。在应用方面，目前主要应用于自动化诊断、智能助手和知识推荐等场景。

我们还提出了一些关键技术。首先是图片识别技术。我们发现，在群聊中，大家打字时间较少，发生故障时，通常会截取系统监控图片，框选机器 IP 或特定集群后直接发送到故障群。传统知识问答系统很难处理这种场景，因此我们探索了图片识别技术，使用多模态大模型将图片翻译成自然语言形式。对于视频文件，我们也进行了类似处理。此外，我们还注意到很多人懒得打字，只是在原始消息上点击 OK 表情表示故障处理完成，我们也对这种类型的消息进行了特殊处理。

第二项技术是参考了 React 的 prompt 结构，对群聊中的知识进行抽取。排障类对话通常围绕固定结构展开，即第一个人提出问题，运维人员分析问题并不断迭代，直至解决问题或继续尝试。这种结构与 React 的思维链结构相似，因此我们利用类似结构让大模型抽取群聊中的关键知识。

第三项技术是参考了 GraphRAG 形式。这种形式对碎片化知识的处理更为友好，我们通过图构建知识图谱，将散落的知识进行关联，对其进行聚类，并为每个聚类定义主题，以便在检索和使用时更加方便。

最后一项是对上下文窗口进行了限制。由于汇总的知识量很大，甚至可能超过 32K 模型的 token 上限，因此我们设计了一套迭代架构，通过不断总结、分步生成，最后依据生成的大纲迭代补全信息。

整个架构图的设计如下：对于 SRE 同学而言，他们仅需在第一个环节配置系统内定义的订阅信息，例如明确订阅的 OnCall 主题、告警主题，以及系统工单链接的位置。一旦这些订阅信息提供给我们，后续的自动化处理即可展开。在知识加工领域，我们会对图片数据进行处理，对群聊进行知识抽取，然后通过大语言模型将这些数据构建成传统向量知识库或 GraphRAG 知识图谱，并将它们存储在知识库中。之后，可能需要 SRE 同学对知识进行 review 或打标，经过他们确认后，这些知识就可以在线上用于知识回答或文档生成。经过持续迭代，大语言模型会将新生成的知识重新注入到信息收集场景中，从而形成数据的飞轮效应，推动整个架构的迭代发展。

在架构的具体细节方面，我们与公司内多个数据源进行了对接。例如，我们对接了 CMDB 的配置信息，通过它可以了解线上系统架构、硬件配置和网络拓扑等基础数据，这些数据是运维工作的支撑。同时，我们也对接了 OnCall 和告警平台，获取所有历史 OnCall 记录和告警处理记录。此外，事故会议纪要，尤其是重大故障处理后的会议纪要，其中包含运维专家的讨论和根因分析，是非常宝贵的知识。我们还对接了工单系统，通过它记录了通过白屏操作的运维工作流，包括工单之间的流转和解决事件的工单参数。最后，我们关注线上日志和监控指标，进行日志和指标的监控。

在图片翻译方面，我们注意到很多同学在提报故障时，不会用自然语言详细描述故障细节，而是直接将监控看板截图发到群里。截图中可能包含曲线突增和受影响的数据库名称，他们还会框选出关键数据库。对于人类来说，这很容易理解故障要求，但对于大语言模型来说，目前很难直接处理图片并自动调用后续工作流。我们的做法是，在提 OnCall 工单时，利用背景群信息前置了解组件问题和常见情况，通过前置系统 prompt 的形式提供给大语言模型，并将上下文一起提供给模型。这样，大语言模型可以尝试对图片进行简单翻译，例如介绍用户请求路径、具体耗时和图片描述的问题，然后通过这种方式调用后续工作流，提取诊断参数，使整个过程更加顺畅。

在知识抽取方面，我们定义了一个类似 React 的架构，让大语言模型持续对对话进行知识抽取。我们定义了一些结构体，包括 question（用户最初提出的问题）、告警或问题的表现、Action（用户在特定场景下采取的具体排查或止损措施，例如检查监控看板、查看指标或检查日志中的信息）、工具（抽取用户在群聊中频繁提到的平台工具或链接，以便后续大语言模型自动调用）、observation（执行 Action 后的观测结果，例如告警的具体问题描述，如高延时或慢 SQL，或者执行操作后的结果，如重启操作后 CPU 负载下降和流量恢复正常）以及思考过程。Action、观测和思考过程可能是持续循环的，因为群聊中很难通过一轮排查解决问题。我们会抽取多轮排查的表现，最终确定问题的具体根因。

以一个知识抽取的 demo 为例，原始群聊记录中提到磁盘空间告警，用户磁盘使用率低但仍收到告警，怀疑是共享库的原因。抽取的 question 是磁盘空间告警但用户资源使用率低。第一个 Action 是用户发送一张图片，描述数据库关键信息，排查数据库详情，图片上的跳转链接和数据库状态信息被转译成自然语言。后续用户可能会去平台排查共享库问题，迭代出下一步 Action 是查看磁盘中是否有可清理空间，观测发现有可删除的表，计划下午 2 点删除，并思考清理后再次检查磁盘利用率是否正常。这种结构化的抽取结果适合指导 Agent 操作，下次遇到类似问题时，Agent 可以清楚每一步 Action 和排查思路。唯一需要改造的是抽取到的工具，例如将其改造成 MCP Server 形式或函数，以便大模型灵活调用，从而实现 Agent 的自动化执行。

在抽取大量知识后，便涉及到构建知识图谱的过程。这其中包括命名实体识别以及不同实体之间关系的抽取。例如，通过规划可以明确排查操作需要在数据库平台上进行，而排查后删表的操作也可能在平台上通过某个链接执行。我们将这些关系抽取出来后，尝试构建整个知识图谱，并且还需要建立知识图谱的动态更新机制。

Demo 图谱是针对某个组件抽取的结果。虽然这只是一个小场景的知识图谱，但其核心是通过一个问题节点展开的。这个问题节点是“整个集群处于 Pod pending 状态的节点过多，且持续时间超过 5 分钟”。从这个节点出发，会引发其他许多节点，而这些节点大多对应着收到问题后的下一步止损操作。止损操作的下一个节点通常是操作后系统的下一步表现。通过构建这种知识图谱，我们可以快速地构造整个排障链路的思维链。

在实际场景中，我们分享一下几个案例。

如果用户拥有完整的 SOP（标准操作程序），我们会尝试通过自动化方式构建 Agent。用户可以将 SOP 文档上传到我们的知识库。我们定义的 SOP 结构包括：所需工具、排障流程、思路以及观测指标等。整个解析过程由大语言模型驱动的 Agent 分步完成。例如，它会解析文档中的指标并自动更新到运维平台，同时推测指标描述；识别文档中提到的工具（如查询集群状态和变更事件的工具），并在我们的平台上将这些工具注册为可调用的函数；对于诊断项配置，由于其是简单的 API 接口，可以正确注册。不过，更复杂的效果目前还不够理想。后续，Agent 会抽取故障描述、常见根因、止损操作以及故障表现，并将这些信息准确写入知识库。在实际运行时，它会生成一段类似伪码的思维链流程，如第一步检测指标，第二步分析指标是否存在问题等，将文档转化为类似可执行的伪码结构，以此指导 Agent 进行自动化执行。

我们意识到，让 SRE 团队自行编写 SOP 文档可能会陷入“先有鸡还是先有蛋”的困境。因此，我们尝试利用知识库中的大语言模型自动生成 SOP 文档。目前，虽然在结构化内容生成方面表现良好，但在可读性方面仍有提升空间。大语言模型生成的文档往往较为啰嗦，为了涵盖所有关键信息，可能会重复表述，而人工编写的文档则更加简洁、精炼。因此，在这一领域还有许多工作需要开展，以提升文档的可读性。

我们尝试从知识图谱中召回特定故障场景的关键信息，以此为基础形成类似操作手册的 SOP。例如，当任务失败时，系统会查看知识图谱中最频繁的节点，先关联到查看任务信息的操作。系统会提取具体的操作工具，并告知用户在哪个平台上查看哪些信息，如应用名、具体 ID 和日志状态等。根据查询结果，系统会提供分析思路，如使用 SQL 分析等。按照这种图示结构，用户可以逐步进行排查。然而，我们发现许多 SRE 同学更倾向于思维导图形式，因为它比文档形式更容易理解。因此，我们也在探索是否可以让大语言模型后续生成树状结构，自动导出类似的思维导图，以满足用户的需求。

在一些具体的应用场景中，我们不仅关联了离线数据，还整合了在线数据库。例如，在一次故障发生时，故障信息存储在我们的在线数据库中。此时，系统可以同时从群聊和数据库中召回相关信息。当询问故障表现时，系统能够准确总结；当询问故障影响范围时，系统会自动关联故障数据库，查询当时哪些组件受到影响，例如监控指标 SLI 有相同波动的组件，从而实现自动化的知识问答。此外，对于长时间的群聊记录，为了避免新加入的故障处理人员因不了解背景而需要逐条查看消息，系统能够快速总结并同步所有相关信息。

在生成 OnCall 和告警周报方面，我们会对所有的 OnCall 和告警进行自动化总结。具体来说，左边是 OnCall 告警的原始信息，右边则是通过大语言模型基于一些提示（prompt）进行分类知识抽取或其他功能提升后的信息。例如，模型会判断问题是否真正得到处理，并可能将未处理的问题标记出来。同时，我们还处理了特殊含义的文字，如 OK 表情或其他点赞手势，这些通常表示问题已解决。最终，总结内容类似于 React 结构，会抽取故障表现、问题根因、解决措施等信息，并自动迭代到数据库中，为下一次的 OnCall 和告警处理提供指导。

如果将上一周所有的告警和 OnCall 通过大语言模型进行基础分析，就可以形成自动化的周报。例如，在告警分析方面，系统会自动识别在同一周期内触发的多个告警，并考虑是否可以将它们聚合。同时，系统还会提出一些优化处理的建议，例如对于持续时间过长的告警（如持续 8 小时未处理），系统会通过大模型分析告警配置和当时的指标表现，给出优化建议。

我们希望运维知识图谱能够作为中间层，整合底层的各种数据资源。底层数据包括 SRE 日常工作中可能遇到的所有数据类型，如结构化数据（各类数据仓库、在线数据库、故障数据库、工单数据库、告警数据库）和非结构化数据（离线文档、知识文档、群聊中的实时数据等）。通过在中间层进行数据的统计调度与分析，我们期望运维知识图谱能够支撑多种场景的发展，包括但不限于：

• 新人培训：为新入职的 SRE 提供系统化的知识支持，帮助他们快速了解运维工作流程和常见问题处理方法。

• 知识的持续迭代：不断更新和优化运维知识库，确保知识的时效性和准确性。

• 自动化运维：利用大语言模型实现对话式的诊断运维，提高运维效率和准确性。

• 智能体构建：支持构建更复杂的智能体，以应对复杂的运维场景，提升整体运维能力