OpenDeRisk：基于多智能体协作的AIOps根因分析系统实战

1. 项目概述：一个为系统稳定性而生的AI“风险管家”

如果你和我一样，长期泡在运维和SRE（站点可靠性工程）的圈子里，那你一定对“救火”这个词深有体会。半夜被报警电话叫醒，面对海量的日志、指标和链路追踪数据，像无头苍蝇一样试图定位一个线上问题的根因——这种经历绝对是职业生涯的“噩梦”时刻。传统的监控告警工具能告诉你“哪里病了”，但很少能清晰地告诉你“为什么病”以及“该怎么治”。OpenDeRisk的出现，正是为了解决这个痛点。它不是一个简单的监控面板升级版，而是一个彻头彻尾的、AI原生的风险智能系统，你可以把它理解为你应用系统的“AI风险管家”。

这个管家的核心能力，是进行根因分析。它通过多智能体协作，模拟了一个专业的SRE团队的工作流程：有负责整体感知和协调的SRE-Agent，有能深入代码层动态分析问题的Code-Agent，还有擅长生成报告和可视化的ReportAgent、Vis-Agent等。它们协同工作，对日志、追踪链和代码进行深度研究，最终不仅告诉你问题出在哪个服务、哪行代码，还能把整个分析过程的证据链清晰地展示给你。这相当于给运维工作装上了一副“AI透视镜”，让排查过程从依赖个人经验的“黑盒”变成了可追溯、可解释的“白盒”。

我花了一周多的时间，从源码部署到数据集测试，完整地跑通了它的核心流程。我的感受是，OpenDeRisk代表了AIOps（智能运维）的一个非常务实且先进的方向：它没有停留在用AI做简单的异常检测，而是深入到了最复杂、最需要人类专家智慧的根因分析环节，并且用开源、可扩展的架构把它实现了出来。接下来，我会结合我的实操经验，带你深入拆解这个项目，看看它到底是怎么工作的，我们又该如何把它用起来，甚至参与到它的生态建设中。

2. 核心架构与设计哲学：为什么是多智能体？

刚接触OpenDeRisk时，你可能会被它“多智能体协作”的宣传吸引，但心里也会打鼓：这会不会又是一个为了蹭热点而堆砌概念的“玩具项目”？在我深入代码和实际运行后，我发现它的多智能体设计并非噱头，而是由其要解决的核心问题——复杂的、跨层级的根因分析——所必然要求的。

2.1 单智能体的局限性与传统方案的瓶颈

在根因分析场景下，一个万能的全能型AI智能体几乎是不存在的。原因在于，问题的表征（如接口超时）和根本原因（如某行代码的数据库连接池配置错误）之间，往往隔着多层抽象：基础设施层（CPU、内存、网络）、中间件层（数据库、缓存、消息队列）、应用层（业务逻辑、代码Bug）、甚至组织架构层（发布流程、配置变更）。每一层都需要不同的专业知识和分析工具。

传统的AIOps方案，要么是做一个大而全的规则引擎（维护成本高，难以适应快速变化），要么是训练一个单一的预测模型（可解释性差，难以处理未见过的故障模式）。OpenDeRisk的设计者显然意识到了这一点，他们采用了“分而治之”的策略，为不同领域的分析任务设计了专属的智能体。

2.2 OpenDeRisk的多智能体角色分工

让我们看看项目中已经实现的几个核心智能体，它们的分工体现了非常清晰的SRE工作流思维：

• SRE-Agent（总指挥与协调者）：这是整个系统的“大脑”。它不直接进行深度代码或数据挖掘，而是负责任务规划与调度。当一个新的告警或分析任务进来时，SRE-Agent会根据问题的初步特征（例如，是性能问题还是错误率飙升），决定调用哪些下游专家智能体，并协调它们的工作顺序和结果汇总。这模仿了现实中SRE专家在事故处理中的指挥官角色。
• Code-Agent（代码侦探）：这是我认为最惊艳的部分。传统的运维工具很少能直接关联到代码层面。Code-Agent被赋予了动态编写和执行代码的能力。例如，当数据分析指向某个特定函数可能存在内存泄漏时，Code-Agent可以自动编写一段分析该函数内存使用模式的Python脚本，在安全沙箱中执行，并返回分析结果。这直接将运维洞察的深度推进到了源码级。
• Data-Agent（数据挖掘师）：它专门处理时序指标、日志流和分布式追踪数据。它的核心技能是与向量数据库交互，进行基于检索增强生成的关联分析。比如，它能从海量日志中，快速检索出与当前错误特征相似的历史事件及其解决方案。
• ReportAgent 与 Vis-Agent（文书与视觉专家）：前者负责将分析过程与结论整理成结构化的报告；后者则利用GPT-Vis等协议，将复杂的调用链、智能体间的协作关系、证据的推导过程，以流程图、拓扑图等可视化形式动态渲染出来。这对于团队复盘和知识沉淀至关重要。

我的实操心得：这种角色化设计的好处是“高内聚、低耦合”。每个智能体可以独立优化和升级。例如，你可以替换一个更强大的代码分析模型给Code-Agent，而无需改动其他部分。在测试中，我亲眼看到Vis-Agent生成的可视化证据链，它清晰地展示了从“API延迟升高”到“数据库连接池耗尽”再到“某段代码未释放连接”的完整推理路径，这对于向非技术背景的同事解释问题极具价值。

2.3 技术栈选型背后的考量

项目的技术选型也紧紧围绕“开源”和“实用”两个核心。

1. 底层框架与协议：

   • MCP：项目提到了对MCP的支持。MCP是一个新兴的、用于连接AI模型与外部工具和数据的协议。OpenDeRisk利用MCP，可以让各个智能体以标准化的方式调用外部的监控系统（如Prometheus）、日志平台（如ELK）或自研工具，极大地增强了系统的扩展性。这意味着你可以轻松地将它接入你现有的运维体系。
   • RAG：这是Data-Agent能力的基石。项目默认使用ChromaDB作为向量数据库。将历史告警、处理手册、知识库文档进行向量化存储后，智能体在分析新问题时，能快速找到相关的上下文信息，从而做出更准确的判断，避免了“大模型幻觉”在严肃运维场景下的风险。

2. 数据集：为什么是OpenRCA？项目强烈依赖微软开源的OpenRCA数据集进行演示和训练。这是一个包含真实运维场景下指标、日志、追踪的庞大数据集（解压后约26GB）。选择它有两个关键原因：一是真实性，基于真实数据训练的智能体更贴近生产环境；二是开放性，为学术界和工业界提供了一个统一的评测基准。我在部署时下载了其电信场景的子数据集，里面的故障注入非常全面，从网络分区到服务雪崩，很适合用来验证系统的分析能力。

3. 从零开始部署与核心配置详解

理论讲得再多，不如亲手跑起来。OpenDeRisk提供了多种安装方式，为了彻底理解其组成，我选择了从源码部署。下面是我的完整操作记录和踩坑总结。

3.1 环境准备与依赖安装

项目推荐使用uv这个新兴的Python包管理器和安装器，它的速度比传统的 pip 快很多，并且能很好地处理依赖冲突。

# 1. 安装 uv (Linux/macOS) curl -LsSf https://astral.sh/uv/install.sh | sh # 安装完成后，需要重启终端或执行 source ~/.bashrc (或对应shell的配置文件) 来让 uv 命令生效。 # 2. 克隆代码仓库 git clone https://github.com/derisk-ai/OpenDerisk.git cd OpenDerisk # 3. 使用 uv 安装所有依赖 # 这一步是关键，--extra 参数激活了不同的功能模块 uv sync --all-packages --frozen \ --extra "base" \ # 基础核心 --extra "proxy_openai" \ # OpenAI API代理支持（用于接入各类大模型） --extra "rag" \ # 检索增强生成模块 --extra "storage_chromadb" \ # 向量数据库存储 --extra "derisks" \ # 核心风险分析引擎 --extra "storage_oss2" \ # 阿里云OSS存储支持（可选，用于存储大型文件） --extra "client" \ # 客户端库 --extra "ext_base" \ # 扩展基础模块 --extra "channel_dingtalk" # 钉钉通知通道（可选）

重要注意事项：

• --frozen参数会锁定依赖版本，确保环境一致性，强烈建议使用。
• channel_dingtalk是可选依赖。如果你的团队不用钉钉，可以去掉它，否则安装过程中可能会因为缺少钉钉SDK的某些系统依赖而报错。
• 安装过程会下载Python包并编译一些本地依赖（如ChromaDB需要的onnxruntime），根据网络和机器性能，可能需要5-15分钟。

3.2 模型配置：连接AI的“大脑”

OpenDeRisk本身不提供大模型，它需要一个“大脑”。项目通过proxy_openai模块，以兼容OpenAI API的方式接入各种大模型。这是系统运作的核心配置。

安装完成后，你会发现在用户目录下自动生成了配置文件夹：~/.openderisk/configs/。里面有一个默认配置文件derisk-proxy-aliyun.toml。我们需要编辑它来配置模型端点。

vi ~/.openderisk/configs/derisk-proxy-aliyun.toml

配置文件的核心部分是[[openai_proxies]]，你需要根据自己使用的模型服务进行修改。以下是几种常见场景的配置示例：

场景一：使用 OpenAI 官方 API

[[openai_proxies]] name = "openai" api_type = "openai" api_key = "sk-your-openai-api-key-here" # 替换为你的真实Key base_url = "https://api.openai.com/v1" # 官方端点 model = "gpt-4o" # 指定默认使用的模型

场景二：使用国内通过 OpenAI 兼容接口的模型服务（如阿里云灵积、DeepSeek等）

[[openai_proxies]] name = "aliyun" api_type = "openai" api_key = "sk-your-aliyun-api-key-here" # 服务商提供的Key base_url = "https://dashscope.aliyuncs.com/compatible-mode/v1" # 阿里云灵积的兼容端点 model = "qwen-max" # 指定通义千问模型

场景三：使用本地部署的模型（如通过 Ollama、vLLM 等）

[[openai_proxies]] name = "local" api_type = "openai" api_key = "sk-no-key-required" # 本地部署通常不需要key，但需要填一个占位符 base_url = "http://localhost:11434/v1" # Ollama 的 OpenAI 兼容端点 model = "llama3.2" # 你本地部署的模型名称

我的踩坑记录：

1. base_url格式错误：最容易出错的地方。很多国产模型服务商的兼容端点路径末尾必须包含/v1，漏了就会报404错误。一定要仔细查看服务商的文档。
2. api_key权限：确保你的API Key有调用所选模型的权限。例如，OpenAI的Key分类型，有些不能调用GPT-4。
3. 网络连通性：如果你配置的是云端模型，确保你的服务器可以访问对应的base_url。有时需要配置网络代理，项目本身支持通过环境变量HTTP_PROXY/HTTPS_PROXY设置。
4. 多模型支持：配置文件中可以配置多个[[openai_proxies]]段落。这样，在Web UI中你可以切换使用不同的模型，例如用GPT-4做复杂推理，用便宜的GPT-3.5做简单总结。

3.3 启动服务与初探Web UI

配置好模型后，就可以启动服务了。项目提供了极简的启动方式：

# 进入项目根目录 cd OpenDerisk # 使用快速启动命令，它会自动加载默认配置 uv run derisk quickstart

默认服务会启动在http://localhost:7777。如果你想指定端口，可以加-p参数：

uv run derisk quickstart -p 8888

访问Web UI，你会看到一个简洁的界面。首次使用，系统可能会引导你进行初步的模型设置。在这里，你可以选择刚才在配置文件中定义好的模型代理（如openai或aliyun）。

界面核心功能区域预览：

1. 对话/任务输入区：你可以直接输入自然语言描述问题，如“分析一下昨晚订单服务延迟升高的原因”。
2. 模式选择：通常会有“AI-SRE”、“Flame Graph Assistant”、“DataExpert”等模式切换。
3. 会话历史：保存每次分析的任务和结果。
4. 可视化面板：展示智能体协作流程图和证据链图。

启动并看到界面，只是万里长征第一步。要让系统真正“动”起来，我们需要数据。

4. 核心功能实战：三大使用模式深度体验

OpenDeRisk目前主要提供了三种实战模式，分别对应不同的输入数据类型和分析场景。我逐一进行了测试。

4.1 模式一：AI-SRE模式（基于OpenRCA数据集）

这是项目的旗舰功能，也是最复杂、最能体现其价值的部分。它需要一个结构化的数据集作为“战场”。我们以OpenRCA的“银行系统”数据集为例。

第一步：下载并准备数据集

# 在项目根目录下，安装gdown工具（如果未安装） pip install gdown # 下载银行数据集（约数GB，请确保磁盘空间充足） gdown https://drive.google.com/uc?id=1enBrdPT3wLG94ITGbSOwUFg9fkLR-16R # 下载完成后是一个压缩包，解压它 unzip -q bank_dataset.zip -d pilot/datasets/ # 最终确保数据在 `OpenDerisk/pilot/datasets/bank/` 目录下，包含 metrics, logs, traces 等子文件夹

第二步：启动服务并加载数据集确保你的配置文件derisk-proxy-aliyun.toml中正确配置了数据集路径（通常默认指向pilot/datasets）。然后以配置文件方式启动服务，这样系统才能找到数据。

uv run derisk quickstart -c ~/.openderisk/configs/derisk-proxy-aliyun.toml

第三步：发起一次根因分析在Web UI中选择“AI-SRE”模式。你可以尝试输入：

“分析数据集‘bank’中，在时间窗口2023-10-27 14:00:00到2023-10-27 14:30:00期间，为什么transfer_service服务的错误率（error_rate）突然飙升？”

接下来，你会看到界面左下角或任务列表中，智能体开始被调度。这个过程可能会持续几分钟，因为系统需要：

1. Data-Agent从数据集中加载指定时间窗口的指标、日志和追踪数据。
2. SRE-Agent根据错误率飙升这一现象，规划分析路径（例如，先看关联服务，再查资源指标，最后钻取日志）。
3. Code-Agent可能会被调用，去编写特定的数据分析脚本，例如计算某个数据库连接池的使用率时序相关性。
4. 各个智能体将发现提交给ReportAgent和Vis-Agent，最终生成一份包含根本原因结论、支持证据和可视化链路的报告。

我的实测观察：

• 耗时：一次完整的分析，根据数据量和模型响应速度，大约需要2-5分钟。这比人类专家手动排查要快得多。
• 输出质量：报告不仅会指出根因服务（如account_db），还会给出置信度和关键证据（如“在14:05时刻，该数据库的活跃连接数达到最大值，与transfer_service错误率峰值时间吻合”）。
• 可视化：生成的证据链图非常直观，用节点和箭头清晰地展示了从现象到根因的推理过程，不同颜色的节点代表不同类型的实体（服务、指标、日志条目）。

4.2 模式二：火焰图助手（Flame Graph Assistant）

这个模式针对的是性能分析场景。火焰图是性能剖析的利器，但解读需要经验。这个模式让AI来帮你读图。

操作流程：

1. 在Web UI切换到“Flame Graph Assistant”模式。
2. 上传你从生产环境抓取的火焰图文件（支持常见的.svg,.json等格式）。可以是Java的async-profiler结果，也可以是Python的py-spy输出。
3. 输入你的问题，例如：“请分析这个火焰图，找出最耗时的函数调用路径”或“是否存在可疑的自旋锁或阻塞调用？”

背后原理：系统会解析火焰图的栈信息，提取函数调用关系和耗时占比，然后结合Code-Agent对代码的理解（如果项目源码已接入），分析哪些函数是性能瓶颈，并可能给出优化建议，比如“json.dumps函数耗时占比30%，建议检查是否在循环中频繁序列化大对象”。

4.3 模式三：数据专家（DataExpert）

这是一个更通用的交互式数据分析模式。你可以上传各种格式的数据：

• 时序指标CSV：例如，从Prometheus导出的CPU、内存数据。
• 日志文件：纯文本或结构化的日志。
• 追踪数据：Jaeger或Zipkin格式的JSON。
• Excel表格：业务数据。

上传后，你可以像和数据分析师对话一样提问：

“帮我找出过去24小时内，响应时间P99大于500毫秒的所有API端点。” “对比一下A服务和B服务在流量高峰期的错误率变化趋势。” “从这份销售数据Excel中，分析一下哪个产品线的环比增长最高？”

模式特点：这个模式极大地降低了数据查询和分析的门槛。它背后的Data-Agent会自动理解数据的结构（schema），将你的自然语言问题转换成数据查询或分析语句（可能是Pandas操作，也可能是SQL），执行并解释结果。对于不熟悉复杂查询语言的业务人员或新手运维来说，这是一个强大的工具。

5. 开发与扩展：打造你自己的智能体

OpenDeRisk的开源魅力不仅在于使用，更在于扩展。它的架构允许你开发自定义的智能体（Agent）和工具（Skill），以适应你公司内部特定的系统或流程。

5.1 自定义智能体开发指南

假设你们公司使用自研的配置管理中心ConfigCenter，你想创建一个Config-Agent，专门用于分析配置变更与故障间的关系。

步骤1：创建智能体类在derisk-ext.agent.agents目录下（或在你自己的扩展包中），新建一个Python文件，例如config_agent.py。

from typing import Optional, Any from derisk.agent.base import BaseAgent from derisk.agent.registry import register_agent from pydantic import BaseModel, Field # 定义智能体接收的输入参数模型 class ConfigAnalysisInput(BaseModel): service_name: str = Field(description="需要分析配置的服务名") time_window_start: str = Field(description="开始时间，格式：YYYY-MM-DD HH:MM:SS") time_window_end: str = Field(description="结束时间") # 注册你的智能体，并指定它能处理的任务类型 @register_agent("config_analyst") class ConfigAnalystAgent(BaseAgent): """专门分析配置变更与系统故障关联的智能体""" # 智能体的元数据：名称、描述、输入模型 name: str = "ConfigAnalyst" description: str = "分析指定时间段内服务的配置变更历史，并与系统指标进行关联分析。" input_model = ConfigAnalysisInput async def run(self, input_data: ConfigAnalysisInput, context: Optional[Any] = None) -> dict: """ 核心执行逻辑 """ # 1. 从公司的ConfigCenter API获取配置变更记录 changes = await self._fetch_config_changes( input_data.service_name, input_data.time_window_start, input_data.time_window_end ) # 2. 从Data-Agent获取同一时间段内该服务的异常指标（通过context或直接调用） metrics = await self._fetch_service_metrics( input_data.service_name, input_data.time_window_start, input_data.time_window_end ) # 3. 进行关联性分析（这里可以引入简单的规则或调用模型判断） analysis_result = self._correlate_changes_with_metrics(changes, metrics) # 4. 返回结构化的结果 return { "status": "success", "data": { "config_changes": changes, "correlation_analysis": analysis_result, "recommendation": "建议回滚在XX时间由‘userA’提交的‘数据库连接超时参数’变更。" } } async def _fetch_config_changes(self, service: str, start: str, end: str): # 实现调用真实配置中心API的逻辑 # 示例：使用requests或aiohttp # ... return [{"time": "...", "user": "...", "key": "db.timeout", "old_val": "5s", "new_val": "1s"}] async def _fetch_service_metrics(self, service: str, start: str, end: str): # 可以通过context获取其他智能体的能力，或者直接调用项目内Data-Agent的接口 # 这里为简化，返回模拟数据 return {"error_rate": [{"timestamp": "...", "value": 0.05}]} def _correlate_changes_with_metrics(self, changes, metrics): # 实现关联分析逻辑 # ... return {"suspected_change": changes[0] if changes else None, "confidence": 0.85}

步骤2：注册并集成你需要确保你的智能体包被正确加载。通常需要在项目的扩展配置或入口点中声明。参考已有智能体的注册方式，将你的ConfigAnalyst加入到智能体注册表中。

步骤3：测试与调用重启OpenDeRisk服务后，你的ConfigAnalyst智能体就可以被SRE-Agent在合适的场景下调度了。例如，当分析一个服务故障时，SRE-Agent可能会自动调用ConfigAnalyst来检查故障前是否有相关的配置发布。

5.2 自定义工具（Skill）开发

除了完整的智能体，你还可以开发更细粒度的“工具”。这些工具可以被任何智能体调用。例如，开发一个“查询公司内部工单系统”的工具。

from derisk.skills.base import BaseSkill, skill @skill(name="query_internal_ticket") class InternalTicketQuerySkill(BaseSkill): """查询内部运维工单系统的技能""" description = "根据服务名和时间范围，查询相关的运维变更工单。" async def execute(self, service_name: str, start_time: str, end_time: str) -> list: # 调用内部工单系统REST API # ... return tickets

开发完成后，将这个Skill注册到系统中。之后，Code-Agent或SRE-Agent在分析问题时，就可以在它的“工具箱”里找到这个新技能，并决定是否使用它来获取更多上下文信息。

5.3 参与社区与生态

OpenDeRisk有一个独立的技能仓库derisk-skills。如果你开发的Skill具有通用性，可以考虑提交PR到这个仓库，贡献给社区。同样，在项目的GitHub Issues和Discord社区中，开发者们非常活跃，讨论架构、分享使用案例、共同解决难题。参与进去，是快速学习和提升的最佳途径。

6. 常见问题、故障排查与性能调优

在实际部署和测试过程中，我遇到了不少问题。这里将典型问题和解决方案整理成表，希望能帮你绕过这些坑。

性能调优建议：

• 模型选择：对于复杂的推理任务（如根因分析），使用能力更强的模型（如GPT-4、Claude-3、DeepSeek-V3）效果更好，但成本更高、速度更慢。对于简单的数据查询和总结，可以使用轻量级模型（如GPT-3.5-Turbo、Qwen-Plus）来平衡速度和成本。
• 数据预处理：如果使用自己的数据，在导入前做好清洗和结构化。杂乱的日志会极大影响RAG检索的准确性和分析效率。
• 并发控制：在配置文件中，可以调整智能体池的大小和任务队列长度，以适应不同硬件资源。避免在资源有限的机器上设置过高的并发度。
• 持久化与缓存：充分利用项目的存储扩展。将频繁访问的向量索引、分析结果缓存到磁盘或OSS中，可以显著提升重复查询的速度。

经过这一番深入的折腾，OpenDeRisk给我的感觉更像是一个“引擎”而非“产品”。它提供了强大的多智能体框架、与现有运维数据对接的能力以及可视化的呈现方式，但它的最终效果很大程度上取决于你喂给它的数据质量、你配置的模型能力以及你根据自身业务定制的智能体和工具。它可能不会立刻解决你所有的问题，但它为你构建一个自动化、智能化的风险防控体系，提供了一个坚实且高度可扩展的起点。对于有一定研发能力的运维团队来说，投入时间学习和定制它，长远来看可能会带来运维效率和系统稳定性的革命性提升。