DevOps-ChatBot：DevOps开源端到端智能AI助手

1. 项目背景

随着ChatGPT等通用大模型以及各类垂直领域大模型的出现，各个领域的产品交互模式、用户信息获取模式都在逐步发生改变。但通用大模型自身存在的生成内容不可靠、信息内容不及时、领域任务不完善的问题始终存在，面向DevOps这个对于事实的准确性、信息的及时性、问题的复杂性、数据的安全性要求都比较高的领域，大模型该如何赋能？为此，我们发起并开源DevOps-ChatBot端到端AI智能助手，专为软件开发的全生命周期而设计：通过DevOps垂类知识库 + 知识图谱增强 + SandBox执行环境等技术来保障生成内容的准确性、及时性并让用户交互修改代码编译执行，确保答案的可靠性；通过静态分析技术 + RAG检索增强生成等技术来让大模型感知上下文，实现代码库级别的组件理解、仓库项目级的代码文件修改、生成，不单单只是函数片段级的代码补齐；通过完善链路级的Multi-Agent调度设计、协同知识库、代码库、工具库、沙盒环境，来让大模型可以实现DevOps领域复杂多步骤的任务；并且通过DevOps领域专属的领域模型和评测数据构建支持私有化部署来保障数据的安全性，以及特定任务的高可用性。

我们期望通过本项目逐步改变原有的开发运维习惯，从各处资料查询、独立分散平台操作的传统开发运维模式转变到大模型问答的智能化开发运维模式，让“天下没有难做的Coder”。

GitHub项目地址：https://github.com/codefuse-ai/codefuse-chatbot

Arxiv论文地址：ICSE投稿中，敬请期待，稍后放出

2. 核心功能

项目整体架构简图如下：

• 🕷️ Multi Source Web Crawl：网络爬虫，提供对指定url爬取相关信息的能力
• 🗂️ Data Process：数据处理模块，提供文档加载器、数据清洗、文本切分的功能，处理和整合多源格式的数据文档
• 🗄️ Text Embedding Index：文档分析核心，通过文档上传即可实现文档检索
• 📈 Vector Database & Graph Database：向量数据库和图数据库，用于数据管理
• 🧠 Multi-Agent Schedule Core：多智能体调度核心，通过简易配置即可构建所需交互智能体
• 📝 Prompt Control：Prompt控制与管理模块，定义Agent的上下文管理
• 🚧 SandBox：沙盒模块，提供代码编译执行和动作执行的环境
• 💬 LLM：智能体大脑，可支持多种开源模型和LLM接口范围
• 🛠️ API Management：API管理组件，快速兼容相关开源组件和运维平台

在上述功能模块的组装协同下，本项目核心差异技术、功能点：

• 智能调度核心：体系链路完善的调度核心、多模式一键配置，详见2.1章节
• 代码整库分析：仓库级代码理解、项目文件级代码编写生成，详见2.2章节
• 文档分析增强：文档知识库结合知识图谱的检索、推理增强，详见2.3章节
• 垂类专属知识：DevOps专属知识库、垂类知识库自助一键构建，详见2.4章节
• 垂类模型兼容：DevOps领域小模型、DevOps周边平台兼容，详见2.5章节

2.1. Multi-Agent Schedule Core/智能调度核心

在处理复杂问题时，我们可以通过ReAct过程来选择、调用和执行工具反馈，同时实现多轮工具使用和多步骤执行。但对于更复杂的场景，例如复杂代码的开发，单一LLM Agent难以胜任。因此，社区开始发展出多Agent的组合玩法，比如专注于开发领域的metaGPT、GPT-Engineer、chatDev等项目，以及专注于自动化构建Agent和Agent对话的AutoGen项目。

经过对这些框架的深入分析，发现大多数Agent框架的整体耦合度较高，其易用性和可扩展性较差。在预设场景中实现特定场景，但想要进行场景扩展却困难重重。因此，我们希望构建一个可扩展、易于使用的Multi-Agent框架，通过简易的配置即可辅助完成日常办公、数据分析、开发运维等各种通用任务。

* 本项目的Mutli-Agent框架汲取兼容了多个框架的优秀设计，比如metaGPT中的消息池（message pool）、autogen中的代理选择器（agent selector）等。

以下将从6个方面介绍Multi Agent框架核心要素：

1. Agent Communication：Agent之间有效的信息交流对于上下文管理以及问答效率提升至关重要。

1. 遵循简洁直观易于理解的链式对话原则，将Agent以线性方式排列串连成一个执行链路。
2. 借鉴metaGPT的Message Pool框架，允许Agent对Message Pool进行推送和订阅，使链路更加灵活。

2. Standard Operation Process（SOP）：对LLM的生成结果进行标准化解析和处理。

1. 定义Agent的 Input 和 Output 范围，能够组装和解析相关Action和Status，保证框架运行的稳定性。
2. 定义多种SOP标识，如Tool、Planning、Coding、Answering、finished等，满足Agent的基本需求。

3. Plan and Executor：增加LLM的Tool使用、Agent调度、代码的生成。设置了几种基本链路，例如：

1. 单轮问答，也可以扩展到CoT、ToT、GoT等形式。
2. ReAct，基础的响应决策过程，模型设置SOP 状态以终止循环。
3. TaskPlaning - Executor，任务完成即可结束。

4. Long-short term memory Management：为了模拟人类团队协作过程，增加一个专门负责内容总结（类似于会议助理）的Agent，对长期记忆进行总结并提更有效的信息进行传递。
5. Human-agent interaction：面对复杂场景，由人类介入Agent交互过程并提供反馈，使LLM能准确理解人类的意图，从而更有效地完成任务。
6. Prompt Control and Management：负责协调和管理各Agent间的Prompt交互，提升系统的复杂性控制和交互效率

1. Prompt输入采用Markdown结构化设计，分为角色描述、用户问题与任务、相关检索信息、输出格式、历史记录与记忆管理等，提高Prompt的透明度和易操作性，简化用户交互。
2. 输出同样使用Markdown结构化设计，以实现清晰规范的结果展示，方便用户阅读和后续解析，支持系统扩展和与其他平台的集成。
3. 引入标准化的代码块隔离机制（使用三个反引号"```"），优化Code和Json数据输出与解析，增强用户的可读性和交互体验。

总体来说，这6个核心要素共同组成Multi Agent框架，确保Agent之间的协作更加紧密和高效，同时也能够适应更复杂的任务需求和更多样的交互场景。通过组合多个Agent链路来实现一个完整且复杂的项目上线场景（Dev Phase），如Demand Chain（CEO）、Product Arguement Chain（CPO、CFO、CTO）、Engineer Group Chain（Selector、Developer1~N）、QA Engineer Chain（Developer、Tester）、Deploy Chain（Developer、Deploer）。

2.2. Code Repo RAG/代码整库分析

现阶段LLM面向开发的主要使用在代码的生成、修复以及组件的理解任务上，通过各类网络文档类&代码类数据（计算机书籍、计算机论坛等）的收集、然后针对模型进行加训以及特定代码类任务微调来实现，以这条思路构建了各种开源/闭源的通用LLM、专有LLM。但这类大模型面临的一个挑战就是训练数据往往只包含某个时间节点之前的公开代码数据，针对频繁更新的开源/私有仓库存在数据信息的不及时以及LLM天然存在的幻觉，同时LLM往往无法感知代码仓库的上下文以及天然的代码库依赖结构，导致生成的结果往往不符合用户的要求。

我们首先通过对于周边开发工程师的调研，归纳开发中遇到的主要问题如下图所示，可以看到在开发的过程中，除开代码逻辑的开发（这往往占用的耗时并不长），现有代码库、依赖包的理解，代码检索、元信息查询等占用的时间也许更长（这里面没有列举需求的理解以及系分文档等的编写，这块也会作为接下来演进的重点）：

针对如上问题，我们期望通过结合程序分析获取代码的逻辑结构并存入知识图谱，在此基础上通过RAG迭代查询增强获取必要的上下文信息，并结合multi-agent分角色扮演，来实现大模型和代码库的有机结合，做到让大模型真正成为面向实际业务使用的万能助手，而不仅仅是刷各种benchmark的工具。整体框架如下：

核心模块介绍：

• 代码结构分析

• 代码分析中，我们会针对代码原文进行清洗和去重（比如单测文件），这是为了保留住有价值的代码部分。然后我们会通过静态分析的手段，从代码库中挖掘到代码之间的依赖图，同时我们通过还会借助于大模型的理解能力来针对代码进行解读，在生成的结构化信息图谱中作为重要的补充。这些手段的目的都是要从代码库中将尽可能多的代码信息挖掘出来以供后续检索模块来通过不同的方式来检索信息。

• 代码检索生成

• 在代码检索模块中，我们当前提供了三种不同的检索模式，分别会针对用户问题的侧重点不同来自动选择最适合的检索模式。Cypher检索生成重要面向用户对于代码库结构的理解（比如元信息查询等），图谱检索主要面向用户对于代码类&方法的检索定位以及代码的自动生成。由于程序分析整体的拓展性会比较差，面向新的编程语言、面向私有化的中间件等都会涉及到定制需求的开发，同时从人的角度出发，在开发的过程中并不会用到程序分析的信息，我们同时也在探索通过multiagent的模式，迭代搜索代码仓库获取上下文信息，同时有另其他agent来负责阶段性提炼总结信息以及结果生成等其他任务，目前还在实验中，敬请期待。

2.3. Doc Repo RAG/文档分析增强

大模型具备强大的生成能力，但在涉及到专业领域知识问答（比如医疗、通讯等），以及私有知识问答（私域数据），容易出现幻觉导致生成的答案不可信。最直观的解决方案是通过将特定/私有领域的数据加训来增强模型相关的知识，但训练大模型开销巨大，且生成结果不稳定&幻觉仍然比较严重，第二条路是结合搜索（比如Bing的做法），但面向海量的私域文档以及领域的限定，单独构建搜索引擎仍然不是一条靠谱的路径。我们最终选择知识库外挂的手段，通过检索增强生成的方式，将与问题相关的数据从数据库中检索出来，作为额外知识输入到大模型中，保障结果的可靠性&实时性，同时避免训练开销。

如果更精准的搜索检索是本模块核心要解决的问题？为此，我们整体的架构图如下：

整个 DocSearch 含有三种检索链路

1. 传统的文档向量数据库查询

文档向量数据库是当前最主流的知识库构建方法。其特点在于每一个原子单位是自然语言文档。在构建知识库时，需结合Text Embedding 模型对文档进行Embedding并在向量数据库中存储。本项目采用私有化Embedding模型，支持其它私有部署和隐私相关场景，并提供其它专有模型接入和选择。在此之后，则需根据不同情况，选择不同的检索策略将知识库中相应的知识抽取出来，后续本项目将结合学术界上下文学习（in-context learning）的最新成果，提供多种数据库检索方式，包括Similarity、Random 、Auto-CoT、Complex-CoT、Meta-CoT等。

2. 知识图谱查询

知识图谱（Knowledge Graph）主要是用于描述现实世界中的实体、概念及事件间的客观关系，擅长处理事物之间的多种复杂关系网络，在搜索/问答/大数据分析中具有重要作用。本项目采用Nebula图数据库对知识图谱进行存储和管理，支持导入现有知识图谱进行进行知识检索。当只有文本数据时，也支持通过大模型的方式自动抽取实体和关系来生成知识图谱，从而挖掘出数据中多种复杂关系。同时我们在实际实验中观测到，在不少场景中，相比纯文本的搜索生成，通过图谱可以获得更精准的问答效果。

3. 知识图谱推理 + 向量数据查询

当用户同时存在文档数据库和知识图谱数据时，本项目也提供两者的融合搜索。具体的，对每篇文档提取tag，然后根据用户的提问，知识图谱上搜索相关的tag同时基于其领域得到扩充到tag集合。最后，基于扩充版本的tag集合以及文档向量数据库中的相似度距离，检索出与原问题相关的文档。这种结合能有效的解决很多“行话”可能只有特定专业领域的人才熟悉，而大模型由于没有这个知识背景而检索出错误的结果，后续我们也会为devOps领域来构建专门的“行话图谱”

用户可以选择自己想要采用的链路，也可以三个都进行选择来获取三种不同的结果。

2.4. DataHub Auto-Construction&DevOps DataHub/知识库构建&DevOps知识库

如2.3章节的介绍，通过知识库外挂的手段可以很好的解决专有/私域知识问答的问题，构建智能助手/智能客服等业务应用。同时，我们介绍了增强检索生成的方案。接下来的核心问题是如何更好的构建知识库。

直接梳理海量数据源并构建知识库时常常会面对以下问题：

1. 数据的获取和整合：不同的数据源之间存在格式不一致、质量参差不齐的问题
2. 数据清洗：在数据量巨大的情况下，如何自动化地识别和剔除错误、重复或无关紧要的数据
3. 垂直领域知识的整合：在专业或技术性强的领域，知识库构建需要依赖于专业知识，从而使系统能够参照专业知识来自动化地理解复杂的术语和概念。
4. 知识库的更新和维护：知识库需要定期更新，保持信息的准确性和时效

基于此，我们的整体架构如下：1）通过Crawler模块实数据的搜集；2）通过Loader模块实现多源异构数据的导入；3）Filter Func模块实现数据的过滤清洗；4）TextAnalyzer模块实现对数据的智能化分析；5）Pipeline模块串联整个过程。整体的架构图如下所示：

模块具体功能为

1. Crawler/爬虫：定期网络文档爬取，保障数据更新的及时性，由于DevOps数据的广泛分布，也期望大家能持续贡献网页来源
2. Loader/文档加载器：处理和整合来自不同渠道的爬取数据，并支持用户私有文档库、代码库、知识图谱等的导入，灵活应对多样化的数据需求
3. Filter Func/清洗过滤：通过对数据中的文本内容、代码段和特殊字符进行仔细的清洗和去重处理，确保后续分析的准确性和高效性。
4. TextAnalyzer/文本分析器：进行深入的文本分类、信息提取、文档切割以及摘要和总结，这一模块是智能化处理的体现，它将复杂的文本数据转化为结构化（包含知识图谱）、易于理解的信息。
5. Pipeline/管道：将上述模块紧密串联，形成连贯的处理流。优化数据处理的过程，实现了数据输入到清洗完毕输出的端到端自动化。

我们接下来会注重于DevOps领域数据的收集和构建，同时这条标准化的数据获取&清洗能力&智能化处理也期望为更多的私有知识库构建提供帮助。

2.5. DevOps Model&Platform Compatible/DevOps平台&模型兼容

随着大型语言模型（LLM）的出现，我们不仅见证了问题解决方式的变革，比如智能客服系统从依赖小规模模型微调和固定规则转向更为灵活的智能体交互，而且产品交互模式也正在经历重大的转变。我们期望和周边开源的DevOps平台打通兼容，通过API的注册、管理和执行能够实现对话式交互，驱动完成各种特定任务（数据查询、容器操作等）。

同时我们也该意识到大模型目前并非适用于所有领域。在面对特定的领域任务，尤其是数值计算类任务（如异常检测/智能告警、组合优化/容器调度等），小型模型仍然占有独特的优势。它们在效果、计算效率和资源消耗方面经常领先于大型模型。因此，我们也通过将这些专门的模型以API的形式进行注册、管理和执行，来实现它们的集成和应用。为了能够让本项目快速兼容相关开源组件和运维平台，我们通过python注册模板可快速接入各种Restful API的注册和执行，也可以转换为Swagger结构。

通过继承`BaseToolModel`类，可编写相关的tool_name、tool_description、ToolInputArgs、ToolOutputArgs、run等相关属性和方法即可实现工具的快速注册。

1. 通过FastChat启动私有模型的推理服务或者其它Restful风格的API，如Qwen2.0、文心一言等，也可以注册成可用工具，给到LLM进行调度使用
2. 也可注册蚂蚁集团相关开源项目和运维平台的API，通过Multi-Agent框架与LLM简单对话即可完成相关运维操作和API能力调用，帮你解决相关开发、运维问题！

目前已封装工具清单如下：k-sgima异常检测、代码检索、文档检索、duckduckgo搜索、百度ocr识别、股票信息查询、天气查询、时区查询。

2.6. 总结&未来展望

ChatGPT面向公众开放将近一年的时间里，涌现了许多优秀的开源与闭源模型及框架。从今年4月份开始，我们团队便深入探索DevOps领域大模型和业务落地，这个过程中我们经历了不少挑战。从最初搜集内部文档、代码以及网络开源数据进行模型的加强训练，到现阶段模型与框架的紧密结合。我们认为大模型在DevOps领域最可靠的落地方式或者说在真正意义上替代人工完成任务，还需结合面向知识库&代码库的RAG（增强事实问答和逻辑推理的能力），解决特定领域任务的专有能力（领域任务微调增强）以及逻辑推理&语义理解的通用能力。这正是我们构建ChatBot的初衷，我们通过完善链路级的Multi-Agent调度设计，协同知识库、代码库、工具库、沙盒环境，来让大模型能够在DevOps领域处理复杂的多步骤任务。

目前我们开源的DevOps框架还处于初期，还有很多不完善的地方，接下来我们会在如下方面做核心演进。

1）Multi-Agent Schedule Core/多智能体调度核心

• 通过Agent-Selector 实现Agent的智能调度
• 实现代码自动编写、代码测试等功能
• 支持用户私人定制的个性化使用场景

2） Agent&Prompt工程

• Agent Prompt 解耦，后续只需编写Agent的Task Prompt，即可实现整体功能运转
• 将知识库信息、代码库信息、搜索信息、工具信息、以及各种Agent、Chain、Phase的历史交互信息进行综合管理并构造prompt
• 提供Agent Manager，在UI上可实现Agent、Chain、Phase的定义、注册、串联
• 通过LLM自动构建和编排Phase、Chain、Agent的交互逻辑

3） 知识库构建

• 提供数据获取、清洗、结构化管理等多种能力
• 构建面向不同垂直领域的知识库数据

4） 知识库检索&知识图谱增强

• 基于用户提供的文档，实现文本类知识库构建功能，并提供 List Index、Vector Store Index等多种文本知识库索引方式
• 对用户查询提供多种修正方式，包括且不限于意图识别/意图补充/意图修复等
• 结合学术界知识图谱的最新成果，提供多种知识图谱检索方式，包括TOG（think on graph）等。

5） 代码整库分析

• 细化代码解析提取功能，丰富代码图谱 schema
• 知识图谱数据库选型+实现
• 文档数据库选型+实现

* 为了减少本项目非核心工作的开发，避免重复造轮子，对Github上与LLM相关的热门项目进行调研分析后，通过复用以下项目（不局限于下图所展示的内容）来构建本项目的其它非核心组件。

• LLM框架类

• langchian：LangChain是一个用于开发由语言模型驱动的应用程序框架。作为本项目的组件串联模块，负责Prompt、LLM、Vector Database、Knowledge Graph Database之间的交互调度。

• LLM模型类：可接入Qwen、LLaMa、Opeani，作为Agent的大脑，提供文本问答、行为决策的能力

• Qwen：阿里云研发的通义千问大模型系列的70亿参数规模的模型
• LLaMa：是Meta发布的大型语言模型，旨在提供一种高性能、开源的文本生成工具。
• Openai：提供chatGPT模型服务

• 向量数据库

• Faiss：faiss是一个Facebook AI团队开源的库，针对高维空间中的海量数据（稠密向量），提供了高效且可靠的相似性聚类和检索方法。本项目基于此库支持知识库检索的功能

• LLM训练推理

• FastChat：FastChat是一个智能易用的大型语言模型推理服务。本项目可基于FastChat为其它私有模型或涉及隐私的场景提供专有模型选择和部署支持，本项目默认使用GPT-3.5-turbo

• 其他功能组件

• SandBox：提供了一个交互验证环境（基于Jupyter NoteBook），帮助用户判断LLM生成代码的真实性，并支持用户通过接口完成代码调整和内容交互。还可通过容器实现环境隔离，保证代码执行安全。

3. 功能介绍

3.1. 功能页面

文本知识库管理

• 文本切换、文本向量化服务、知识库的向量检索服务
• 提供多个知识库的创建、管理、下载等功能，支持PDF、TXT、JSON、JSONL、MD等文件的上传
• 还支持爬虫进行实时url内容爬取功能，可自动对爬取数据进行自动清洗和知识库加载

知识图谱管理

• 支持知识图谱文件上传和管理

代码知识库管理

• 支持通过 ZIP 上传代码文件

代码知识库展示页面

• 展示这个代码知识库包含的代码文件数和节点数
• 支持删除知识库功能

基于Agent问答

我们通过上述页面去构建文本知识库和代码知识库，在本项目中可采用Multi-Agent框架来构建多种多样的Agent链路，从而实现各种复杂场景的执行。

目前我们提前封装了一些Agent场景，诸如chatPhase、docChatPhase、searchChatPhase、codeChatPhase、toolReactPhase、codeReachPhase，可支撑知识库问答、代码问答、工具调用、代码执行等功能。

同时每一个场景我们支持是否进行知识库检索、代码库检索、信息搜索等配置过程，同时可配置相关的工具以供工具进行调度使用。

3.2. 更多玩法

我们在构建DevOps-ChatBot的过程中发现这套体系化的能力，除了应用在DevOps领域，任何领域貌似也是适用的！大模型解决问题无外乎通过自身知识、知识库增强事实问答、API解决特定领域任务、代码编程解决计算不足，同时在Multi-Agent的调度下可以延伸出很多有意思的玩法。以下玩法可以通过本项目的模块组装构建完成！

3.2.1. 代码解释器（Code Interpreter）

场景描述：上传一个数据文件，自动进行数据分析

演示demo

3.2.2. 工具使用

场景描述：查询某个服务器的基本时序，传入到监控工具中，并进行分析

演示demo

3.2.3. 智能股票分析（工具+代码解释器）

场景描述： 用户希望通过简单的自然语言查询来获取特定股票的详细信息，包括历史股价图表、市场表现和可能的市场走向。例如，用户想要了解贵州茅台的股票历史及未来走势。

演示demo

3.2.4. 根据上传代码生成测例

场景描述：针对代码库中的某个方法生成测试用例。导入代码库、选择检索方式为基于标签检索、询问问题

演示demo

• 代码内容
  

• 不加代码知识库
  
• 加代码知识库
  

3.2.5. 玩家拯救者（知识库问答）

场景描述：回答与具体的网络游戏相关的问题。包含英雄信息、登场时间、所属城邦等。

演示demo

英雄联盟的英雄关系知识图谱

知识图谱问答演示

4. 关于DevOpsGPT

DevOpsGPT是我们发起的一个针对DevOps领域大模型相关的开源项目，主要分为三个模块。本文介绍的DevOps-ChatBot是其中的问答机器人模块，其目标是基于LLM来实现DevOps 领域LLM行业标准评测。此外，还有DevOps-Model、DevOps-ChatBot两个模块，分别为DevOps领域专属大模型和DevOps领域智能助手。我们的目标是在DevOps领域，包含开发、测试、运维、监控等场景，真正地结合大模型来提升效率、成本节约。我们期望相关从业者一起贡献自己的才智，来让“天下没有难做的coder”，我们也会定期分享对于 LLM4DevOps 领域的经验&尝试。

欢迎使用&讨论&共建
（1）ChatBot - 开箱即用的 DevOps 智能助手：https://github.com/codefuse-ai/codefuse-chatbot
（2）Eval - DevOps 领域 LLM 行业标准评测：https://github.com/codefuse-ai/codefuse-devops-eval
（3）Model - DevOps 领域专属大模型：https://github.com/codefuse-ai/CodeFuse-DevOps-Model

 (4)  CodeFuse官网：https://codefuse.alipay.com