运维 + AI，你得先搞懂这些

很感谢夜莺提供如此优质的平台，让我有机会和行业内顶尖技术大佬面对面交流。这个会议让我学习到很多有趣、有深度的内容，也给我未来继续探索运维 + AI 提供了新的方向。

同时感谢夜莺社区的邀请，在这里再做一次关于 AI 方向的交流。坦白讲，我目前也仍然是 AI 这条赛道上的探索者，如果有不专业的地方，还希望各位手下留情；也希望借此结识更多同行，一起在 AI 这条赛道上做一些更高级、更有趣的事情。

在会议现场，我分享了 Zenlayer 在 AI 方向的一些实践效果。但有些 AI 基础知识、技术选型思考、运维落地背景，并没有在大会现场展开。这篇文章就是对这些内容做一次补充。

它不是一套固定化的实现方案，而是提供一条理解运维 + AI 的思路：先把基础概念、应用架构、Prompt 工程、推理框架和运维场景之间的关系搞清楚，再去判断哪些能力值得投入，哪些能力暂时不适合自己的团队。

核心摘要

• 运维 + AI 不是简单把大模型接入告警系统，而是要让大模型理解运维对象、上下文、推理依据和可执行动作。
• Semantic Kernel、LangChain 这类框架可以帮助构建 AI 应用，但选型要看团队规模、维护成本和后续迭代压力。
• RAG、Function Calling、Fine-Tuning 分别解决不同问题：知识检索、工具调用、长期能力沉淀，不能混为一谈。
• Prompt 工程决定了大模型能否理解任务边界、输入信息、输出格式和推理步骤，是运维 AI 落地的基础能力。
• CoT、Auto-CoT、ToT、ReAct 代表不同的推理和行动框架，其中 ReAct 更适合需要结合外部工具的复杂运维场景。
• 在告警分析、故障处理、资源优化和可观测性建设中，AI 的价值不是替代人，而是统一判断视角、减少重复劳动、提升决策效率。

运维 + AI 必备概念总览

构建 AI 化能力前，先理解知识体系

运维团队要做 AI 化，不能只盯着模型本身。真正影响落地的，是模型之外的一整套工程体系：如何组织技能，如何维护提示词，如何接入知识库，如何让模型调用工具，如何判断结果是否可靠。

Semantic Kernel：用技能组织 AI 应用

Semantic Kernel 是 Microsoft 推出的开源框架，目标是帮助开发者构建和部署 AI 应用，尤其是需要理解和生成自然语言的应用。它提供了一种结构化方式，用来定义和管理技能。

这些技能可以是简单的函数调用，也可以是复杂的 AI 模型交互。放到运维场景里，可以把“查询指标”“拉取告警上下文”“检索知识库”“生成故障总结”等动作抽象成可复用能力。

Semantic Kernel 的核心组件包括：

• Kernel：框架核心，负责技能的管理和执行。
• Skills：定义应用可以执行的一系列操作，可以是本地函数，也可以是远程服务调用。
• Prompt Templates：用于生成和修改自然语言的模板，支持变量和函数调用。
• Memory：提供存储和检索应用状态的能力，可以是简单键值对，也可以连接更复杂的存储形态。

LangChain：组合大模型能力的应用框架

LangChain 也是一个开源框架，重点在于构建利用大型语言模型（LLMs）的应用。这类应用可以做问答、文本生成、代码执行等任务。LangChain 提供了比较灵活的方式，用来组合和调用不同的 LLM，并管理与模型之间的交互。

LangChain 的核心组件包括：

• Chains：定义模型调用的逻辑流程，可以是简单单步调用，也可以是复杂多步流程。
• Prompts：用于指导模型生成特定类型输出的模板。
• Memory：提供存储和检索应用状态的能力，可用于上下文理解和历史记录。
• Agents：基于给定目标和约束，自动执行任务的实体。

框架选型：不要只看能力，还要看维护成本

Semantic Kernel 和 LangChain 都是为了简化 AI 应用开发，但侧重点不同。

Semantic Kernel 更注重技能的定义和管理；LangChain 更侧重 LLM 的组合、调用和链路编排。选择哪个框架，本质上取决于具体应用场景、团队规模和后续维护能力。

在我们的场景里，我们更多考虑使用 Semantic Kernel 的方式来构建。不是说 LangChain 不好，而是 LangChain 在代码侧的抽象比较重，整体架构也偏复杂。对于后期开发、运维和迭代来说，成本会更高。我们现在的体量还比较小，感觉自身玩不太动。

大模型应用架构：从 Prompt 到 RAG、FT

大模型应用不是单一形态。不同技术架构解决的问题不同，适用边界也不同。运维团队在做 AI 化时，要先判断自己缺的是“对话能力”“工具调用能力”“知识检索能力”，还是“长期学习某类对象和关系的能力”。

典型业务架构

纯 Prompt：最基础的人机对话

纯 Prompt 就像和一个人对话：你说一句，ta 回一句；你再说一句，ta 再回一句。

这种方式最容易开始，但它对上下文、指令清晰度和模型本身能力依赖很高。用于简单总结、解释、格式化输出时还可以；但如果要做复杂运维判断，只靠纯 Prompt 往往不够。

Agent + Function Calling：让 AI 提要求并调用函数

Agent 可以理解为 AI 主动提出下一步需求；Function Calling 则是 AI 要求执行某个函数。

举个简单例子：你问“过年去哪玩”，ta 不是直接给答案，而是先反问“你有几天假”。在运维场景里，这个逻辑可以变成：模型发现告警信息不足，就要求查询指标、拉取日志、检索变更记录或调用诊断工具。

RAG：把外部知识带进回答过程

RAG（Retrieval-Augmented Generation）可以理解为 Embeddings + 向量数据库 + 检索增强生成。

• Embeddings：把文字转换为更容易做相似度计算的编码，这种编码叫向量。
• 向量数据库：把向量存起来，方便后续查找。
• 向量搜索：根据输入向量，找到最相似的向量。

一个直观类比是：考试时，看到一道题，先到书上找相关内容，再结合题目组织答案。答完以后，不一定长期记住。

在运维体系里，RAG 可以把故障手册、告警规则、排障 SOP、历史事件、知识库文档引入问答过程，让模型回答时不只依赖预训练知识。

目前我们还使用了 rerank model 对 RAG 的结果进行重排序，使得最终得到的答案更精准。

Fine-Tuning：让模型长期学习某类能力

Fine-Tuning 可以类比为努力学习考试内容，长期记住，并能够活学活用。

但在运维体系中，传统 Fine-Tuning 对抽象对象的训练效果并不一定理想。特别是服务、实例、指标、告警、拓扑、依赖关系这类抽象对象，如果只用普通文本训练，很难直接达到很好的理解效果。

所以我们也在尝试基于 DeepKe 的抽象方式，把运维体系中的数据和文本用于 Fine-Tuning，看看是否能让模型把抽象对象之间的关系理解清楚。

Prompt 工程：提升 LLM 理解与响应能力

有了应用架构以后，还要解决一个更基础的问题：如何让 LLM 理解你的推理依据、任务边界和输出要求。

不同 LLM 的 chat template 并不完全一样，这会导致同一种 Prompt 在不同模型上的表现不一致。甚至同一个模型，多次重复同一个问题，也可能出现答案差异。

所以 Prompt 工程不是“写一句提示词”这么简单。它更像是给模型设计任务说明书：告诉模型要扮演什么角色、处理什么输入、遵守什么约束、按什么步骤推理、输出成什么格式。

Prompt 设计原则

从个人实践来看，Prompt 设计主要有几条原则：

• Write clear instructions：写出清晰的指令。
• Provide reference text：提供参考文本。
• Split complex tasks into simpler subtasks：将复杂任务拆分为更简单的子任务。
• Give the model time to “think”：给模型时间“思考”。
• Use external tools：使用外部工具。
• Test changes systematically：系统地测试变更。

1. 把话说详细

尽量提供重要的详细信息和上下文。说白了，就是把话说明白，不要太笼统。

不要只说：“总结会议记录。”

可以改成：“用一个段落总结会议记录。然后写下演讲者的 Markdown 列表以及他们的每个要点。最后，列出发言人建议的后续步骤或行动项目（如果有）。”

对于运维场景也是一样。如果只是说“分析这个告警”，模型很难知道要看指标、日志、变更、依赖关系还是历史事件。Prompt 需要把可用信息和判断目标讲清楚。

2. 让模型充当某个角色

可以把大模型想象成一个演员。你要告诉它演什么角色，它才更容易给出专业、明确、风格一致的回答。

例如：充当一个喜欢讲笑话的喜剧演员，每当我请求帮助写一些东西时，你会回复一份文档，其中每个段落至少包含一个笑话或有趣评论。

在运维场景中，角色可以是“资深 SRE”“值班工程师”“告警分析助手”“故障复盘助手”等。但角色本身不够，还要继续明确任务、上下文和输出格式。

3. 用分隔符划分输入内容

三引号、XML 标签、节标题等分隔符，可以帮助划分需要区别对待的文本内容，也能让大模型更好理解输入结构。我个人比较喜欢用 """ 把内容框起来。

例如：用 50 个字符总结由三引号分隔的文本。"""在此插入文字"""

在告警分析中，也可以用分隔符区分“告警内容”“指标片段”“日志片段”“变更记录”“历史处理记录”，减少模型混淆输入来源。

4. 指定完成任务所需步骤

有些任务能拆就拆，最好指定为一系列步骤。明确写出步骤，可以让模型更容易实现。

例如：

步骤 1：用户将提供三引号中的文本。用一个句子总结这段文字，并加上前缀“Summary:”。

步骤 2：将步骤 1 中的摘要翻译成西班牙语，并添加前缀“翻译：”。

运维故障处理也类似：先识别影响范围，再判断可能原因，再列出需要补充的上下文，再给出排查顺序，最后输出处理建议。

5. 提供例子

这就是经典的少样本提示，也就是 few-shot prompt。先给大模型一些例子，再让它按例子输出。

例如：按这句话的风格来写 XX 文章："""落霞与孤鹜齐飞，秋水共长天一色。渔舟唱晚，响穷彭蠡之滨"""

在运维场景中，可以提供历史告警分析样例、故障总结样例、巡检报告样例，让模型学习你希望的输出结构和表达方式。

6. 指定输出长度

可以要求模型生成给定目标长度的输出。这个长度可以按单词、句子、段落、要点数量来指定。

中文里，“多少个字”的效果不一定精准，但“多少段”“多少个要点”通常更稳定。

例如：用两个段落、100 个字符概括由三引号分隔的文本。"""在此插入文字"""

常见提示框架

是不是只要遵循一套方式就可以一路梭？显然不是。不同任务背景下，需要使用不同提示词框架来实现具体任务。

下面这些框架不需要死记硬背，关键是理解它们背后的共性：明确任务、说明背景、拆分动作、定义目标、约束输出。

这些提示框架需要在实际应用中灵活使用。天下没有一招鲜的武功。要用好大模型，底层逻辑和框架理解是必不可少的。否则 LLM 只是一个聊天工具，并不能为工作带来质的提升。

让 LLM 理解逻辑推理：从 CoT 到 ReAct

前面讲的是大模型应用的主要技术方式。但如果想让 LLM 作为 Agent 或 Copilot 存在，还需要解决一个关键问题：如何让 LLM 理解你的推理方式。

LLM 能缓解技术能力差距，但不能替你解决“如何提出问题”的源头。对于今天的 LLM 来说，有想法且逻辑清楚的人，确实可能因为 LLM 的加持而提升很快。你能提出好问题，才更可能得到好答案。

下面只讲一些相对常用，尤其是在运维、运营场景中比较容易落地的推理方式。

CoT：用思维链拆解复杂推理

CoT（Chain-of-Thought Prompting）通过中间推理步骤，让模型具备更强的复杂推理能力。它可以与少样本提示结合，用于回答之前需要先推理的复杂任务。对于数据分析等具体落地问题，CoT 可以显著提高大模型的推理能力。

区别于传统 Prompt 从输入直接到输出的映射，即 <input -> output>，CoT 完成的是从输入到思维链再到输出的映射，即 <input -> reasoning chain -> output>。

例如，如果问题是“纽约到洛杉矶的距离是多少？”，模型可能先检索纽约和洛杉矶的坐标，再计算两点之间的距离，最后给出答案。这个过程中，模型不仅提供答案，也展示推理过程，从而增强答案可信度。

Auto-CoT：自动生成推理链

Auto-CoT 可以理解为利用 LLMs 的“让我们一步一步地思考”提示，自动生成一个接一个的推理链。

这种自动过程仍然可能在生成链路中出现错误。为了减轻错误影响，演示的多样性很重要。Auto-CoT 主要包含两个阶段：

• 阶段 1：问题聚类，将给定问题划分为几个聚类。
• 阶段 2：演示抽样，从每组数组中选择一个具有代表性的问题，并使用带有简单启发式的 Zero-Shot-CoT 生成推理链。

例如，如果问题是“如果一个苹果的重量是 150 克，那么 10 个苹果的总重量是多少？”，Auto-CoT 模型可能会生成这样的思维链：“10 个苹果的总重量 = 10 * 150 克 = 1500 克”。用户不仅得到答案，也能理解模型是如何得出答案的。

在运维告警源头判断、故障处理建议等方面，Auto-CoT 可以产生不错的效果，也能降低新人技能培训投入，更容易让运维人员统一视角与标准。

ToT：用思维树探索多种可能

这里需要特别说一下 ToT（Tree of Thoughts）思维树。严格来说，“ToT 思维树”不是一个在所有语境中都被完全统一使用的术语，因此具体定义可能会随上下文变化。

可以基于“思维树”的概念理解它：思维树是一种用于表示和组织思考过程的结构化方法，以树状图形式展示思考层次和分支。在决策制定、问题解决、创意生成等场景中，思维树可以帮助人们系统探索各种可能性，评估不同选项，从而做出更明智的决策。

在思维树中：

• 根节点：通常代表问题或决策起点，也就是需要解决的核心问题。
• 分支：从根节点开始，每个分支代表一个可能的思考方向或解决方案。分支可以进一步细分，形成更详细的子分支。
• 叶节点：树的末端，代表思考过程的最终结果或结论。

通过构建思维树，可以带来几个价值：

• 系统探索：确保尽量考虑所有可能方向，避免遗漏重要信息或解决方案。
• 评估和比较：通过比较不同分支结果，评估选项优劣，做出更合理的决策。
• 增强理解：通过可视化思考过程，增强对复杂问题的理解。

目前针对 ToT，我们还没有得到特别好的效果。可能是在构建过程中仍然存在不合理定义，或者解析问题不够精准。但从资源合理投入、供应链管理、提升决策质量和效率来看，它应该有天然优势。如果有哪位大佬对 ToT 有深度尝试并有合理化建议，请给出更多好的建议，在此先谢过了。

ReAct：让模型同时推理和行动

ReAct 可以理解为一种结合推理和行动的 AI 框架，主要用于增强 AI 系统在复杂环境中的决策能力和执行效率。

ReAct 的核心思想是：通过实时检索相关信息，并执行基于这些信息的行动，来辅助 AI 系统进行更准确的推理和决策。

在 ReAct 框架中，AI 系统不只依赖预训练知识。遇到新情况时，它会主动检索外部信息，例如数据库、网络资源等，并将这些信息整合到决策过程中。

这个过程可以看作 AI 系统在 Reasoning 和 Acting 之间循环：

• 思考（Reasoning）：AI 系统基于当前状态和目标进行推理与规划，确定下一步要采取的行动或需要检索的信息。
• 行动（Acting）：根据推理结果执行相应行动，例如检索信息、执行任务等。
• 反馈：AI 系统根据行动结果更新状态和知识，然后再次进入思考阶段，形成闭环。

ReAct 的优势在于，它让 AI 系统能适应不断变化的环境，处理之前未见过的情况，而不是只依赖预训练数据。通过实时检索和整合新信息，AI 系统可以做出更准确、更灵活的决策，提高复杂任务表现。

简单总结：ReAct 是 Reason + Action，而 CoT、ToT 更多只是 Reason。ReAct 与 CoT、ToT 的本质区别，就是 ReAct 不止在推理，还在利用外部工具实现目标。不知道这里解释大家是不是能明白。

运维场景中的落地方式

把上面的概念放回运维场景，可以得到一个更清晰的判断：运维 + AI 的目标不是“让模型什么都知道”，而是让模型能基于上下文、知识库、工具和推理框架，给出更稳定、更可执行的辅助判断。

告警分析与故障处理

告警分析与故障处理适合结合 CoT、Auto-CoT 和 RAG。

RAG 用于检索知识库、历史故障、告警规则和处理手册；CoT 或 Auto-CoT 用于拆解判断过程；Prompt 工程负责约束输出结构，让模型按照影响范围、可能原因、排查步骤、处理建议来组织答案。

这样做的价值，不是让模型直接替人拍板，而是帮助值班人员快速建立统一视角，减少重复分析工作。

资源管理与优化

资源管理与优化更适合引入 ToT 这类多分支推理思路。

比如资源投入、供应链管理、容量规划、成本优化，通常不是单点判断，而是多因素权衡。思维树可以帮助系统化展开可能方案，再比较不同分支的收益、风险和执行成本。

不过我们目前对 ToT 的实践效果还不算特别理想，因此更适合把它当作持续探索方向，而不是直接当成成熟方案。

动态决策与执行

复杂运维场景通常需要模型一边推理，一边调用外部工具。这正是 ReAct 更适合发挥作用的地方。

例如模型先判断需要补充哪些信息，再通过 Function Calling 查询监控指标、拉取日志、检索知识库或获取变更记录，然后根据结果继续推理，最终给出下一步建议。

这类方式更接近 Agent 或 Copilot，也更符合真实运维环境中“信息不完整、状态不断变化、需要持续反馈”的特点。

可观测性建设

通过深度探索与实践，我们正在逐步构建基于 LLM 的运维体系，目标是提升运维效率与可观测性。

可观测性本身关注指标、日志、链路、事件等信号。AI 可以在这些信号之上做归纳、检索、推理和辅助决策，让人更快理解系统状态。但前提是基础数据、知识沉淀、工具接口和 Prompt 结构都要先做好。

FAQ：运维 + AI 常见问题

1. 运维团队做 AI，应该先做 RAG 还是 Fine-Tuning？

如果目标是把现有知识库、故障手册、告警规则、历史事件带入回答过程，优先考虑 RAG。RAG 更像“查资料再回答”，适合补充模型不知道的上下文。

Fine-Tuning 更像“长期学习某类能力”。但在运维体系里，抽象对象和对象关系比较复杂，传统 Fine-Tuning 不一定能直接得到理想效果，需要结合具体数据结构和训练目标评估。

2. Prompt 工程是不是只适合简单对话？

不是。Prompt 工程是运维 AI 落地的基础能力。无论是告警分析、故障总结、知识问答还是诊断建议，都需要清晰定义角色、任务、上下文、步骤和输出格式。

如果 Prompt 不清楚，模型很容易给出泛泛而谈的答案。

3. Semantic Kernel 和 LangChain 应该怎么选？

两者都能帮助构建 AI 应用。Semantic Kernel 更注重技能定义和管理，LangChain 更侧重 LLM 组合与调用。

在我们的场景里，因为团队体量和维护成本的考虑，更倾向 Semantic Kernel。LangChain 的抽象和架构能力很强，但也意味着后续开发、运维和迭代成本更高。

4. ReAct 为什么适合运维场景？

运维问题通常不是一次问答就能解决。模型需要先判断缺什么信息，再调用工具获取信息，然后根据反馈继续推理。

ReAct 的特点就是 Reason + Action。它不只推理，也能结合外部工具实现目标，因此更贴近复杂运维场景中的动态决策和闭环执行。

5. AI 能直接替代运维人员做故障决策吗？

从这篇文章的实践思路来看，不应该这样理解。AI 更适合做辅助分析、统一视角、减少重复劳动和提高效率。

真正的故障处理仍然需要结合系统上下文、业务影响、变更风险和人的经验判断。AI 的价值是帮助人更快、更系统地做判断，而不是直接替代人的责任。

结论

运维 + AI 的核心，不是把某个大模型接进系统就结束了，而是建立一套能让模型理解上下文、调用工具、检索知识、进行推理并输出可执行建议的工程体系。

Semantic Kernel、LangChain、RAG、Fine-Tuning、Prompt 工程、CoT、Auto-CoT、ToT、ReAct 这些概念，看起来分散，其实都指向同一个问题：如何让 LLM 从“聊天工具”变成真正能参与运维工作的智能助手。

未来，我们会继续探索更多创新场景，推动 AI 技术在运维领域的应用。也期待与更多技术探索者和实践者一起，把运维智能化这件事做得更扎实、更有意思。