首先，我们来探讨几个核心判断。抖音的算法工程师团队近期在 QCon 上分享了一套方案，核心思路是将大语言模型（LLM）与私域运维知识深度结合，构建一个具备自学习能力的智能运维系统。该系统中有一个名为 SOPAgent 的架构，专门用于解决传统 AIOps 的长期难题——例如知识碎片化、人工维护成本高昂、新人上手缓慢。他们的做法是让大语言模型自主学习和生成 Agent，而不是依赖人工反复编写 SOP 文档。

本次演讲的亮点主要集中在三个维度：第一，LLM 如何从私域知识中自主进行学习，降低人工干预；第二，如何将图像、文本等多模态数据整合，提升知识利用率；第三，构建一个闭环的知识管理体系——自动收集、学习、生成、更新，使智能化运维能够自主运转。

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

背景与挑战

大模型时代已经全面来临，人人都在谈论，软件工程领域的人也都希望利用大模型改造传统工作流。从公司内部到整个行业，似乎所有工作都值得被大模型重构一次。我们也在尝试将大模型引入 AIOps 领域。过去一段时间的经验表明，大家用得最多的场景是智能客服——这是最接近自然语言模型能力的应用，也是最容易想到的提效场景。

在排障领域，用大模型进行根因诊断是另一个热门方向。大语言模型在学习过程中已经掌握了大量故障专业知识，当系统指标异常——比如 CPU 突增、流量突增，或者一段错误日志被丢过来，它就能尝试推理出简单的根因，推动排障流程自动化。

另一方面，我们利用大模型的生成能力。文档生成、周报生成、事故复盘报告这些场景，大模型都能发挥作用。例如，让它整合多篇文档，分析过去一周的群聊内容，直接生成周报。日志分析、告警分析、影响面分析、变更分析也很适合——这些日志和变更工单是类自然语言数据，介于自然语言和代码之间，大模型处理起来反而有优势。

还可以利用大模型自动化调用工作流，也就是现在常说的 Agent 概念。它能自动理解用户意图——在公司内部，通过自然语言指令就能唤起原本需要手动填表单或者精确调用 API 的功能，直接改造流程、提升效率。

代码生成就更不用说了，现在写代码不借助大模型辅助，简直会被当成异类。

我们之前尝试搭建诊断流程平台，想把大模型引入工作流，但很快发现——很难比专业团队做得更好。开源方案太多了，想形成绝对优势基本不可能。我们原本还想着，作为运维团队，积累的传统运维工具——比如 AIOps 算法、线上诊断小工具（拉日志、判断机器问题）——短期内能构成壁垒。但 MCP 概念一出来，这些工具未来可能都变成通用 MCP Server，供人开放式调用，长期来看，运维工具也守不住。

那 SRE 团队的竞争优势到底在哪？答案是经验。公司里资深的 SRE，收到报警后扫一眼曲线、翻几行日志，就能猜到问题在哪儿。而新人 SRE 得对照 SOP 文档一行行排查，时间差距非常大。这种长期工作积累下来的经验和数据，才是真正的护城河。

过去一段时间，我们一直在推广大模型的接入，但遇到了新挑战：可供大模型学习的专家经验不够了。大模型的优势在于自主学习、决策、调用工具、推理，解决新问题。但现在的做法是，构建 Agent 需要 SRE 同学写完善的 SOP 文档——这和我们设想的“让 Agent 自主工作”完全不是一个方向。Agent 的效果完全取决于 SRE 的专业程度，而且让 SRE 花时间写文档，到底是不是降本增效也很难说，Agent 的上限还受限于写文档那个人的经验。更关键的是，不是所有 SRE 都是资深的，新人写出来的东西未必有效。所以，SRE 同学也需要一个统一的平台，来沉淀、管理、更新运维领域的知识。

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

知识学习层面，问题更突出：知识散落、新旧不一、重复、碎片化。比如去年的故障群知识可能已经过时了，老日志对线上没什么用，不同同学写的文档内容重复，群聊里只有零星提到的碎片知识。人工梳理成本太高，我们考虑用大模型收集海量信息，做成向量数据库，方便后续检索和使用。

把海量知识收集起来之后，可以用来生成排障领域的特定参考文档，还能尝试生成技术类文档——比如复盘、架构设计文档——辅助提高工作效率。有了这些文档，下一步就是让 SOP 文档指导 Agent 搭建。同时在很多场景里，通过 Chat OPS（聊天操作）的形式让大家进行知识检索和使用。

方案与创新点

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

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

我们还开发了几项关键技术。首先是图片识别技术。群聊里大家打字的时间很少，发生故障时，通常是直接截系统监控图，框选机器 IP 或特定集群扔到故障群里。传统知识问答系统很难处理这种场景。我们探索用多模态大模型把图片翻译成自然语言。视频文件也做了类似处理。另外，很多人懒得打字，直接在原始消息上点一个 OK 表情表示问题处理完了——这类消息我们也做了特殊处理。

第二项技术借鉴了 React 的 prompt 结构，专门用来抽取群聊里的知识。排障类对话通常围绕固定结构展开：第一个人提出问题，运维人员分析问题并不断迭代，直到解决或继续尝试。这个结构和 React 的思维链结构非常像，我们就用类似结构让大模型抽取群聊中的关键知识。

第三项技术参考了 GraphRAG 的形式。这种形式对碎片化知识的处理更友好，我们通过图结构构建知识图谱，把散落的知识关联起来，进行聚类，为每个聚类定义主题——后续检索和使用就更方便了。

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

SOP Agent 架构细节

整个架构的设计流程是这样的：SRE 同学只需要在第一个环节配置系统内的订阅信息——比如订阅的 OnCall 主题、告警主题，以及系统工单链接的位置。这些信息提供进来之后，后续的自动化处理就可以展开了。在知识加工阶段，我们会处理图片数据，对群聊做知识抽取，然后通过大模型把这些数据构建成传统向量知识库或 GraphRAG 知识图谱，存到知识库里。之后可能需要 SRE 同学 review 或打标，确认过后，这些知识就能用于线上知识回答或文档生成。经过持续迭代，大模型会把新生成的知识重新注入信息收集场景，形成数据飞轮效应，推动整个架构不断迭代。

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

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

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

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

抽取大量知识后，就开始构建知识图谱了。这包括命名实体识别和不同实体之间关系的抽取。比如通过规划可以明确排查操作需要在数据库平台上进行，排查后删表的操作也可能在平台上通过某个链接执行。把这些关系抽取出来后，构建整个知识图谱，还要建立动态更新机制。

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

实践效果与案例分享

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

自动化构建 Agent 的探索

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

SOP 文档生成的挑战

我们也意识到，让 SRE 团队自己写 SOP 文档可能陷入“先有鸡还是先有蛋”的困境。所以尝试用知识库中的大模型自动生成 SOP 文档。目前，结构化内容生成方面表现不错，但可读性还有提升空间。大模型生成的文档容易啰嗦——为了覆盖所有关键信息，可能会重复表述；而人工编写的文档更简洁、精炼。这个领域还有很多工作要做。

基于知识图谱生成操作手册

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

故障处理与知识管理的自动化应用

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

OnCall 和告警周报的自动化生成

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

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

不足与展望

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

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

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

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

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