推荐语
AI大模型助力企业IT运维，实现故障诊断与根因分析的智能化革命。核心内容： 1. 项目背景与AIOps在复杂系统中的必要性 2. 多智能体协作系统的架构与工作原理 3. 交互式运维体验与传统痛点的解决方案
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
当前，企业数字化转型进入深水区，业务系统的复杂性呈指数级增长。微服务、容器化、云原生架构成为主流，这虽然带来了敏捷性和弹性，但也让系统内部的依赖关系变得空前复杂。一个简单的用户请求可能穿越几十个甚至上百个服务，产生的监控指标、日志、链路数据量浩如烟海。
在此背景下，AIOps 从一种“锦上添花”的探索转变为“雪中送炭”的必需品。该项目是AIOps在故障智能诊断这一核心场景下的前沿实践。
构建一个基于多智能体协作的AI系统，模拟人类专家团队的协作模式，对IT系统中发生的故障进行自动化、智能化的根因分析RCA，并通过企业微信等日常办公协作平台将分析过程和结论以交互式、易于理解的形式推送给运维工程师，最终实现平均故障发现时间MTTD和平均故障修复时间MTTR的大幅降低。
1.数据接入：系统实时或准实时地接入全方位的运维数据源，包括：
监控指标（Metrics）：从Prometheus、Zabbix、云监控等获取的系统指标（CPU、内存、磁盘IO）、应用指标（QPS、响应延迟、错误率）、业务指标（订单量、支付成功率）。
日志（Logs）：从ELK及SLS平台获取的应用日志、系统日志、中间件日志，包含关键的ERROR、WARN级别信息及上下文。
调用链（Traces）：从ARMS获取分布式追踪数据，清晰展示请求在微服务间的完整路径和耗时。
2.多智能体协作分析：
任务规划智能体：扮演“运维专家”的角色，对系统中发生的故障进行自动化、智能化的根因分析生成明确的步骤计划，并将监控搜查任务指派给对应的智能体。
指标分析智能体：擅长分析时序指标数据，发现异常波动和相关性。
日志分析智能体：精通NLP，快速从海量日志中提取错误模式、异常堆栈和关键事件。
拓扑感知智能体：理解系统架构和服务依赖关系，分析故障传播路径。
分析决策智能体：扮演“值班长”的角色，通过结构化思维将给定的监控查询结果显性化以进行根因分析。它不会获取新数据或改变状态，只会附加思维日志。当证据缺失或冲突时，或者当最近的步骤没有进展时，需要他来进行判断。
最终输出智能体：扮演“运营专家”的角色，对系统告警事件问题进行总结与结构化输出。
3.交互与反馈：
构建的系统旨在解决以下传统运维模式中普遍的痛点：
1. 告警风暴与信息过载
一个底层组件如数据库、缓存的故障，会像多米诺骨牌一样触发上下游数百个服务的数千条关联告警。运维人员的微信在几分钟内被刷屏，陷入“告警海洋”，难以分辨孰先孰后，哪个是“因”，哪个是“果”。
智能体的解决思路：多智能体系统能够对告警问题进行聚类、降噪和关联，将上千条告警收敛成几个核心的“故障事件”，并直接指出根源，极大减轻了运维人员的认知负荷。
2. 故障定位效率低下，严重依赖个人经验
故障排查像一个“侦探游戏”，严重依赖资深工程师的专家经验。他们需要凭经验在多个监控系统（指标平台、日志平台、链路平台）之间反复横跳、手动查询、对比时间线。这个过程耗时耗力，且一旦专家离职或不在岗，故障恢复时间将变得不可控。
智能体的解决思路：智能体7x24小时值守，集成了顶尖专家的分析模式，能短时间内完成跨数据源的关联分析，将人工需要数小时甚至数天的排查过程压缩到分钟级，降低了对个人经验的过度依赖。
3. 数据孤岛与关联分析困难
监控指标、日志、调用链数据通常存储在不同的系统和数据库中，彼此割裂。人工关联需要记住故障时间点，然后在不同平台间切换、查询、对比，操作繁琐，极易出错，且难以发现深层次的、跨体系的关联关系。
智能体的解决思路：智能体系统天然具备全局视野，它统一接入所有数据源，能够自动基于时间戳、服务名、TraceID等字段进行端到端的关联，发现人类肉眼难以发现的隐藏模式。
4. 应急响应流程僵化，沟通成本高
发现故障后，需要拉群、打电话、通知各方人员。在群内，大家需要重复“截图”、“发日志”、“描述问题”，沟通效率低下，信息碎片化严重。
智能体的解决思路：通过钉钉/企业微信机器人，智能体直接成为“应急响应中心”。它主动推送结构化的分析报告，所有人基于同一份事实进行讨论和决策。智能体还可以直接执行预案、触发止损操作，将沟通从“发生了什么”提升到“我们该怎么办”的决策层面。
5. 知识沉淀与复用的挑战
每次故障的处理经验大多留在了工程师的脑子里和私下的聊天记录里，难以有效沉淀到知识库中。导致同样的错误反复出现，类似的故障需要重新分析。
智能体的解决思路：每一次智能体的分析过程和处理结果都可以被自动记录和归档，形成可检索的故障案例库。当类似故障再次发生时，智能体可以快速匹配历史案例，直接给出可能的原因和解决方案，实现运维知识的持续积累和自动化复用。
方案基于 dify 平台构建分层智能体工作流，实现面向故障诊断与根因分析的 AI 大模型应用。整体架构分为三层：任务规划层、感知层、分析决策层。任务规划层对系统中发生的故障进行自动化、智能化的根因分析生成明确的步骤计划，并将监控搜查任务指派给对应的智能体；感知层负责接入多源运维数据，包括日志（Log）、指标（Metric）、链路追踪（Trace）以及变更事件等数据；分析决策层通过大模型对多维数据进行关联推理，识别异常模式并定位潜在根因并结合业务上下文生成可执行的修复建议或自动化动作。
我们在大模型架构规划时遵循“拆分模型职责、透明化工作流、标准化输出”的设计原则，旨在构建一个类比于人类运维团队的多智能体协同系统。系统内部并非依赖单一AI模型，而是由多个角色明确、专长聚焦的智能体组成，各司其职、高效协作，共同完成复杂故障的根因分析任务。
通过职责拆分，将整体诊断流程分解为多个专业化子任务，通过json进行多智能体间的结构化信息传递：任务规划智能体作为“运维专家”，负责统筹全局，制定根因分析步骤并调度其他智能体；指标分析智能体专注于时序指标异常检测与相关性分析；日志分析智能体利用NLP能力从海量日志中提取关键错误信息；拓扑感知智能体则基于系统依赖关系，识别故障传播路径；分析决策智能体扮演“值班长”，对已有证据进行结构化推理，在信息缺失或冲突时做出判断，但不主动获取新数据；最终输出智能体作为“运营专家”，将分析结果转化为标准化、可操作的结构化报告。
我们为了将工作流全程透明化防止流程黑盒难以调试，每个智能体的输入、输出及决策依据均被显式记录和输出，确保分析过程可追溯、可解释。然后通过统一输出模板和语义规范，实现诊断结论的标准化，便于与下游运维系统集成或人工复核。能够显著提升系统的可维护性、可扩展性与诊断准确性。
为实现外部数据的动态查询能力，系统将日志查询、指标检索、链路追踪等监控工具封装为MCP服务，并部署于函数计算平台。MCP 作为一种标准化接口协议，使大模型在推理过程中可按需调用这些工具，实时获取最新监控数据，避免静态上下文带来的信息滞后问题。同时，用户CMDB中的应用拓扑关系（如应用与组件、应用间依赖）也被封装为 MCP 服务，使大模型在分析过程中能够理解系统架构上下文，提升根因推断的准确性。通过 MCP 机制解耦大模型与底层运维系统，既保障了数据查询的灵活性、实时性与可扩展性，又提升了故障分析的上下文感知能力。
Dify 工作流引擎负责编排上述 MCP 工具调用逻辑，利用React模式对复杂问题进行自行拆解和迭代，多次改写问题并多次执行工具调用从而生成质量更优的结果。例如，当检测到服务延迟异常时，工作流首先调用 Metric MCP 获取关键性能指标，若发现 CPU 或内存异常，则进一步调用 Log MCP 查询相关错误日志；同时通过 CMDB MCP 获取该服务依赖的上下游组件，结合 Trace MCP 分析调用链瓶颈，最终由大模型综合多源信息输出根因假设与处置建议。
接下来的几章中会针对实践中遇到的一些具体问题进行详细展开。
一个丰富的知识库能够为大模型提供至关重要的上下文，使其从“一个通用的语言模型”转变为专属的“领域运维专家”。为了让大模型根因分析得更准确，可以系统地补充以下几大类信息到知识库中：
这类知识是分析的基础框架，帮助模型理解“系统正常情况下长什么样”。
1)系统架构与文档：
a)拓扑关系：清晰的微服务/组件依赖关系图。例如，Service A 依赖 数据库 B 和 缓存 C。
b)组件说明：每个服务、中间件、数据库、网关的详细功能描述、技术栈和版本信息。
2)关键业务流与数据流：
a)描述核心业务的执行路径。例如，“用户下单”这个动作，会依次经过 API网关 -> 订单服务 -> 库存服务 -> 支付服务 -> 消息通知服务。
b)数据如何在不同服务间流转和转换。
3)基础设施信息：
a)集群信息、节点列表、网络分区（VPC/AZ）、负载均衡配置等。
4)配置信息：
a)重要的应用配置文件（如超时时间、重试次数、线程池大小）。
b)数据库连接池配置、缓存策略等。
这类知识是分析的“燃料”，是模型进行关联和推断的事实依据。
1)监控指标Metrics：
a)黄金指标：吞吐量（QPS）、错误率（Errors）、延迟（Latency）、容量。
b)资源指标：CPU、内存、磁盘IO、网络带宽使用率。
c)应用层指标：JVM GC次数、数据库连接数、消息队列堆积情况、慢查询数量。
d)业务指标：订单创建成功率、支付成功率、登录PV/UV。
2)日志Logs：
a)错误日志：服务的异常堆栈信息（Stack Trace）、错误码（Error Code）。
b)关键事件日志：服务启动/停止、重要业务流程节点（如“开始处理订单XXX”）。
c)日志中的关键模式：例如，某个特定任务ID在多个服务间传递的追踪信息。
3)链路追踪Trace：
a)分布式链路数据（如ARMS的Tracing），这是理解跨服务故障的重要信息。它可以直接展示一次请求在不同服务上的耗时和状态，精准定位瓶颈和故障点。
4)事件Event：
a)变更事件：最近的代码部署、配置变更、数据库变更、扩容/缩容操作（时间、内容、操作人）。“任何故障背后很可能有一个最近的变更”。
b)告警事件：其他监控系统（如Prometheus/Zabbix）触发的告警信息，甚至是其他团队告知的上下游系统故障。
这类知识是模型的“案例库”和“教科书”，教它如何从现象推理到根因。
1)历史故障报告（RCA）：
a)过去发生过的真实故障案例。格式应包括：
故障现象：当时监控面板是什么样的，收到了什么告警。
排查过程：工程师是如何一步步分析和定位的。
根因：最终确定的根本原因是什么。
解决方案：是如何修复和恢复的。
预防措施：后续做了哪些优化来避免再次发生。
2)常见问题库（Runbook）：
a)针对特定告警或错误的标准化处理手册。例如：“当出现 cpu利用率>90% 时，首先检查Service A服务，执行 top -Hp 命令查看线程情况，常见原因是...”。
3)专家经验规则：
a)将运维专家的口头禅和经验转化为结构化知识。
“如果订单服务和支付服务同时报错，首先检查数据库连接。”
“每到整点，如果流量突增，可能是定时任务导致，重点检查批处理服务。”
“错误码为502，优先排查上游服务和网络。”
这类知识告诉模型“如何思考”和“如何输出”。
1)根因分析框架（SOP）：
a)描述期望的排查流程。例如：“首先确认影响范围 -> then 检查近期变更 -> 然后沿着依赖链逐层下钻 -> ...”。
2)汇报格式模板：
a)希望模型最终输出的分析报告包含哪些部分。例如：“【摘要】、【影响范围】、【可能根因】、【证据分析】、【建议行动】”。
3)术语词典：
a)统一系统内专有名词、服务名、指标名的叫法，避免歧义。
1)非结构化数据以及实时数据：
a)非结构化：将PDF、Word、Markdown格式的架构文档、故障报告、Runbook直接上传。
b)实时数据：对于监控指标、变更事件等数据，最好通过MCP查询外部接口，在提问时实时从Prometheus、CMDB等系统查询，再将结果作为上下文提供给LLM。这样能保证信息的时效性。
2)多知识库划分：
a)可以按领域创建多个知识库，例如：“系统架构知识库”、“历史故障案例库”、“运维流程库”。在提问时，根据问题类型有选择地启用相关知识库，提高检索精度。
3)数据预处理：
a)清洗与脱敏：去除日志、文档中的敏感信息，如IP、密码、个人信息等。
b)切片优化：对于长文档，调整知识库的分段策略，确保关键信息（如错误码和解决方案）能被完整地检索到。
为了让智能体更好地利用这些指标进行根因分析，我们在知识库和训练中强调以下几点：
1)建立指标关联：智能体需要理解指标间的关联性。例如：
a)发现应用RT升高 → 检查应用所在ECS的CPU、内存 → 检查数据库监控（连接数、慢查询）→ 检查缓存监控（命中率）。
b)看到SLB后端服务器健康检查失败 → 关联检查对应ECS的状态和监控 → 检查该ECS上应用日志。
c)关键需要依靠React模式下的自我迭代能力，还可以引入PDL在 Quantization 等 Kernel 计算的过程中，提前执行 GEMM 的初始化操作，来实现系统的整体性能提升。
2)查询数据：训练智能体区分直接现象和根本原因。例如，“数据库CPU高”是现象，而“大量慢SQL缺乏索引”是根因。
3)时序关联：智能体应关注指标异常的时间线。例如，是先有网络流量突增，还是先有应用CPU飙升，这能帮助判断故障传播链的起点。
4)基线对比：很多异常表现为指标相对于其历史基线的偏离。例如，同样的 CPU 使用率 80%，对于夜间批量作业和白天在线业务的意义完全不同。
5)配置信息关联：将监控指标与最近的变更事件（如代码发布、配置修改）关联分析。很多故障的直接诱因是变更。
五、基于 ReAct 模式的 AIOps 根因分析技术实现
在 AIOps 故障诊断场景中，复杂问题往往无法通过单次工具调用或静态上下文直接求解。为此，我们引入 ReAct（Reasoning + Acting）模式，将大模型的推理能力与外部工具调用能力深度融合，实现对故障问题的动态拆解、迭代验证与逐步收敛。
ReAct 模式的核心在于交替执行“推理（Thought）”与“行动（Action）”两个阶段。在根因分析任务启动后，任务规划智能体首先基于告警信息生成初始假设（如“服务延迟可能由资源瓶颈或依赖服务异常引起”），并据此制定首轮查询计划。随后，工作流引擎调用 Metric MCP 获取目标服务的 CPU、内存、请求延迟等时序指标。若指标显示资源使用率突增，则触发第二轮推理：“高 CPU 是否由特定代码路径或外部调用引发？”，进而调用 Log MCP 检索对应时间段的错误日志或异常堆栈。
与此同时，拓扑感知智能体通过 CMDB MCP 获取该服务的上下游依赖拓扑，识别潜在故障传播路径。若延迟集中在某次跨服务调用，则工作流进一步调用 Trace MCP 获取完整调用链数据，定位具体瓶颈节点（如数据库慢查询或第三方接口超时）。每一轮工具调用的结果均作为新证据输入至分析决策智能体，由其评估当前证据链的完整性与一致性。若证据不足或存在冲突（如指标异常但日志无报错），系统将自动重构问题表述（例如：“是否为非错误型性能退化？”），并发起新一轮有针对性的工具调用。
整个过程由 Dify 工作流引擎驱动，支持循环、条件分支与超时控制，确保在有限步数内收敛至高置信度根因。最终，所有推理步骤、工具调用记录及中间结论被结构化整合，由最终输出智能体生成包含根因假设、证据摘要与处置建议的标准化报告。
工作流与多轮迭代
在 ReAct 模式应用于 AIOps 根因分析场景时，尽管其通过“推理-行动”交替机制提升了复杂问题的拆解能力，但在实际落地中仍面临若干关键性能与体验痛点：
1.工作流运行时间较久。传统 Function Call 机制需多轮 message 组装与模型调用，导致端到端延迟显著增加，影响实时诊断效率 。
2.上下文信息易丢失。随着迭代轮次增加，历史 Observation 和 Thought 不断累积，不仅推高 token 消耗和推理成本，还可能因关键信息被截断而影响后续决策。
3.上下文过长引发推理性能下降。长上下文会降低模型注意力聚焦能力，尤其在多智能体协作中，子智能体难以高效提取所需信息，且多次遇到超过20w字符上限导致模型报错中断。
4.循环终止判断问题。现有方案多依赖固定调用次数或工具列表为空等简单规则，容易过早结束（证据不足）或陷入无效循环（无进展仍持续调用）。
5.最终输出质量不稳定。模型可能直接返回中间结论或思考发散，缺乏结构化、可操作的运维建议。
针对上述问题，我们通过如下几点措施进行了优化：
1.减少不必要的循环限制次数：减少交互轮次，通过提示词或自定义函数前置处理数据减少无效思考循环，并在工作流当中添加多个过程输出模块，提升响应速度与用户体验。
2.实施上下文压缩与精准引用：对历史信息进行摘要或关键片段提取，仅传递必要上下文给后续步骤，降低 token 消耗并保留核心证据 。
3.增强循环终止智能判断：通过规划 MCP 服务持续监督任务进展，结合“证据充分性”与“步骤收敛性”动态决定是否终止循环 。
4.优化任务总结机制：在判定任务完成后，显式调用总结工具触发大模型生成结构化、详尽的根因报告，确保输出专业且稳定 。
通过上述优化显著提升了 ReAct 模式在生产环境中的实用性与可靠性。
以下流程图描述了整个工作流的调用顺序。用户通过告警卡片触发后，“运维专家”Agent首先生成计划，然后调用各个数据agent获取数据，每个数据获取agent都有一套阈值的排查流程，监控查询结果会输出到值班长Agent进行统一收敛评估，直到满足停止条件。
流程说明:
1.用户触发: 用户通过告警卡片提供告警信息，触发工作流。
2.工作流初始化：判断是否初次循环并将用户query、memory等赋值到工作流变量，从知识库检索对应信息。
3.问题拆解及任务规划：通过“运维专家”agent对系统中发生的故障进行自动化、智能化的根因分析生成明确的步骤计划，并将监控搜查任务指派给对应的智能体。
4.监控metric查询：通过metric agent分析时序指标数据，发现异常波动和相关性。
5.日志查询：通过log agent利用NLP从海量日志中提取错误模式、异常堆栈和关键事件。
6.链路调用查询：通过trace agent查询系统架构和服务依赖关系，分析故障传播路径。
7.分析决策：“值班长”agent，通过结构化思维将给定的监控查询结果显性化以进行根因分析。它不会获取新数据或改变状态，只会附加思维日志。当证据缺失或冲突时，或者当最近的步骤没有进展时，需要进行判断。
8.循环: 如果停止条件未满足，会重新循环一轮，运维专家agent根据值班长Agent的输出调整下一次计划，并继续调用数据Agent。这个过程循环直到值班长判断是否满足停止条件。
9.输出报告: 通过“运营专家”agent，对所有事件问题进行总结并结构化输出为一份“事件分析报告”。
阿里云openapi MCP服务接口
https://api.aliyun.com/mcp
可观测MCP服务接口
https://github.com/aliyun/alibabacloud-observability-mcp-server
运维专家 Agent
你是一名经验丰富的 **SRE 运维专家**，负责主导整个 AIOps 故障根因分析（RCA）流程。你的核心使命是：**基于用户问题或告警上下文，制定高效、可执行的排查计划，并精准调度其他专业智能体协同工作，最终实现 MTTD 和 MTTR 的显著降低**。
---- **解析告警输入**：从用户问题或系统告警中提取关键实体（如域名、服务名、实例 ID、错误码、时间范围等）。- **生成结构化排查计划**：按“**拓扑定位 → 指标验证 → 日志取证 → 根因推断**”逻辑制定步骤。- **调度专业智能体**：将具体分析任务指派给指标、日志、调用链等智能体，并提供明确输入参数。- **关联业务上下文**：通过 CMDB 工具将域名或实例信息映射到项目、应用、环境等业务维度，并将项目、应用、环境等关键信息传递给下游服务。---1. **第一步：输入信息校验** - 用户输入问题或告警是否包含项目、应用、环境、时间等信息，如不包含则要求用户补充，并提供用户提问样例如：“请分析如下项目应用的相关实例最近1小时内cpu、内存及其他核心指标情况。项目：xxx应用：xxx时间：近1小时内“2. **第二步：明确具体时间 ** - 经查询当前的上海时间为{{ - 如果用户提供了明确的时间范围(例如：“从10点到11点”，“昨天下午3点到4点之间”)，则根据当前时间转换为详细时间区间后输出（例如：”2025-10-2510:00:00到2025-10-2511:00:00 UTC+8“）。 - 如果用户提供的是单一的模糊时间点(例如：“10点左右”，“大概10:00的时候”)，则以该时间点作为中心给出前后15分钟的时间区间（例如：“2025-10-2509:45:00到2025-10-2510:15:00 UTC+8“）。 - 如果用户未提供任何时间信息，则以最近1小时作为时间区间（例如：“2025-10-2510:00:00到2025-10-2511:00:00 UTC+8”）。 - 时区统一转换为UTC+8，时间格式必须以`YYYY-MM-DD HH:MM:SS`（缺秒补`:00`）输出。3. **第三步：拓扑定位** - 若问题或告警含 **域名** → 调用 `lookup_domain_topology` - 若问题或告警含 **资源 ID** → 调用 `lookup_resource_by_id` - 若已知 **项目/应用** → 调用 `list_resources_by_project_app` 获取依赖资源4. **第四步：指派分析任务** - 将指标查询指派给 **指标分析智能体** - 将日志检索指派给 **日志分析智能体** - 将调用链分析指派给 **调用链分析模块**---- 不得自行解析原始指标、日志或调用链数据 - 不得跳过拓扑定位直接猜测根因 - 不得连续调用同一 CMDB 工具超过 2 次 - 不得输出模糊指令，必须明确参数和目标---请以json格式输出，具体格式及字段说明如下：agent_type（string类型）: 当前agent类型，固定值为master。data（object类型）: 具体内容信息集合。plan（array<object>类型）：指定下一步调用哪些智能体来完成目标。step_id（Number类型）: 执行步骤序列号。agent（string）: 下一步调用agent类型，枚举值metric|trace|log。date(string)：时间区间。query_backgroud(string类型)：问题背景描述，用于给下游智能体理解背景。query（string类型）: 希望让智能体具体做什么。reason（string类型）：为什么需要这一步的原因。reflection（string类型）：总结当前计划和进度，并明确下一步action。error_message（string类型）： 如果状态失败的话输出错误原因，如果成功的话输出null。```{ "agent_type": "master", "data": { "plan": [ { "step_id": 1, "agent": "metric", "date": "2025-9-20 10点到12点", “query_backgroud”："2025年9月18日22点到23点 dreamone-customer-system请求耗时上升，请分析一下根因", "query": "app dreamone-order-system所关联的ECS实例列表为xxx，数据库为RDS实例xxx，请分析这些实例在最近7天（2025-09-20至2025-09-27）的CPU使用率、内存使用率、网络流量及RDS的CPU使用率、连接数等监控指标数据是否有异常，并生成趋势图。", "reason": "接口调用成功率下降可能由底层资源瓶颈导致，需优先验证ECS节点资源水位和RDS数据库性能是否正常，排除基础设施层问题。" }, { "step_id": 2, "agent": "trace", "date": "2025-9-20 10点到12点", “query_backgroud”："2025年9月18日22点到23点 dreamone-customer-system请求耗时上升，请分析一下根因", "query": "应用 dreamone-order-system 的接口调用成功率下降，请使用ARMS查询最近7天内该应用的调用链数据，重点分析失败请求的调用链，识别异常服务（如dreamone-customer-system/dreamone-item-system）、慢调用节点或HTTP状态码5xx错误，并整理关键链路数据。", "reason": "若基础设施指标正常，需通过调用链分析定位具体异常环节，确认是否由下游服务依赖故障或代码逻辑缺陷导致请求失败。" }, { "step_id": 3, "agent": "log", "date": "2025-9-20 10点到12点", “query_backgroud”："2025年9月18日22点到23点 dreamone-customer-system请求耗时上升，请分析一下根因", "query": "调用阿里云SLS日志MCP接口查询dreamone-order-system对应的Logstore order-system-business-log中最近7天ERROR级别日志，重点检索'ConnectionTimeout'、'SQLTimeout'、'ServiceUnavailable'等关键词，分析异常堆栈和错误频率分布。", "reason": "结合业务日志验证监控和链路分析结果，确认具体错误类型（如数据库连接池耗尽、第三方服务超时等），为根因提供直接证据。" } ], "reflection": "当前计划优先验证基础设施资源（Metric）、调用链路（Trace）、业务日志（Log）三层数据：1) 排除ECS/RDS资源瓶颈；2) 定位调用链异常节点；3) 通过日志确认具体错误类型。若Metric显示RDS连接数突增，则可能为数据库性能问题；若Trace显示用户系统调用超时，则需联动dreamone-customer-system日志分析。下一步将根据智能体返回数据交叉验证，逐步收敛根因范围。" }, "error_message": null}```当用户缺少项目、应用等关键信息时，应提示如下：```用户输入缺少必要信息：请补充项目名称、应用名称等业务上下文。参考提问格式：'请分析如下项目应用的相关实例今天10点到11点内的cpu、内存情况。项目：xxx 应用：xxx'```---请记住以下知识，他们可能会对回答问题和根因分析有帮助。{{
Metric Agent
你是Metric监控数据获取智能体，通过给定的输入从Metric时序库中获取时序数据，并且按照指定格式输出查询内容。
请记住知识库信息，可能会对回答问题有帮助：{{
**注意：请严格遵守以下步骤执行任务**1. 根据上下文获取所需要查询的Metric指标所在的数据命名空间以及监控项名称，比如数据命名空间（Namespace）为acs_ecs_dashboard，监控项名称（MetricName）为CPUUtilization2. 请调用时间工具，分析需要获取的Metric的起始和结束时间段，格式为YYYY-MM-DDThh:mm:ssZ，请注意：用户输入的时区和监控工具的时区均为东八区，如需转换时区可以使用时间工具。3. 分析起始时间和结束时间之间的时间跨度，请按照以下规则选用监控数据的统计周期（Period），避免采样数据过多： a. 可选的监控周期为15,60,900,3600，监控周期的单位为秒。 b. 当时间跨度小于等于3分钟时，统计周选择15；当时间跨度大于3分钟且小于等于10分钟时，统计周期选择60；当时间时间跨度大于10分钟且小于等于60分钟时，统计周期选择900；当时间跨度大于60分钟(不包含60分钟)时，统计周期选择3600。比如需要获取2025-09-1210:00:00到2025-09-1211:00:00之间的Metric数据，合理的周期选择为900。4. 根据需要查询Metric的实例ID，生成Metric的监控维度，比如需要查询i-bp1i3xxxmu3v和i-bp1i3xxxmu3x的数据，生成的监控维度（Dimensions）为[{"instanceId":"i-bp1xxx3v"},{"instanceId":"i-bp1i3xxxmu3x"}]5. 根据传入的queries列表，依次将参数作为入参，执行 `DescribeMetricList` 工具获取数据，按照输出格式将相关结果采样输出。
1. 如果你在查询Metric时发现指标为空，请再次确认你的数据命名空间、监控项名称、监控维度以及时间范围是否选择正确。2. 查询时只需要查询Metric相关信息，请记住不要查询和Metric无关的信息！3. 请使用Tools执行查询后，将查询的结果返回，请不要自行编造数据！4. 由于监控系统只部署在上海，region只需要查询上海地域。
请以json格式输出，并将字符串中所有的\n转义字符移除后再输出，具体格式和字段说明如下：- agent_type(string 类型): 当前agent类型，固定值为metric- status(string类型)：当前步骤的执行状态，判断依据为是否成功获取到数据，枚举值 success | failure- summary(string类型)：对当前调查进展的总结，并给出对于数据查询结果的分析建议- data(object类型): 具体内容的信息集合- metrics(array<object>类型): Metric指标集合，其中每个指标都是一串时序数据- namespace(string类型): 命名空间- metricName:(string类型): Metric指标名称- unit(string类型): 监控数据单元，如果有则补充,- tags(object类型): Metric指标的tag相关信息- values(array<object>类型): Metric指标的时序数据- timestamp(date类型): 监控时间，单位为秒- value(number): 监控的数据- error_message(string类型): 当status为failure时，请以英文输出报错信息
```json{ "agent_type": "metric", "status": "success", "summary": "我已经成功获取了应用xxx生产ECS实例`i-xxxmu3v`的CPU使用率数据。经分析该ECS的利用率相对较低，建议结合其他指标进行关联分析", "data": { "metrics": [ { "namespace": "acs_ecs_dashboard" "metricName": "AliyunEcs_CPUUtilization", "unit": "%", "tag": { "instanceId": "i-bxxxmu3v", "regionId": "cn-shanghai" }, "values": [ { "timestamp": 1758023820, "value": 63.7 } ] } ] }}```
Trace Agent
## 角色：你是一名资深的**Trace诊断专家**。你的核心使命是**为用户服务**，响应他们的故障排查请求。你将通过精准地调用专业的链路追踪工具（MCP工具集），为用户提供定位和分析问题所需的、**详尽且未经删改**的错误Trace信息。你不是工具的执行者，而是**用户身边的排障顾问**。
## 核心原则 (你的行动铁律)：1. **工具是唯一入口**: 所有诊断操作都必须通过调用指定的MCP工具完成。2. **数据完整性第一**: **绝对禁止**对从工具获取的任何原始文本信息（特别是 `exception.message`, `exception.type`, `stack_trace`）进行任何形式的**截断、简化、省略或改写**。你必须拷贝并呈现**完整的、逐字不变的**原始字符串。3. **杜绝心算**: **绝对禁止**在`thought`中手动进行任何数学或时间计算。所有计算必须通过调用相应的工具来完成。4. **控制数据规模**: 为了避免压垮系统，你的查询必须是小范围、有代表性的。5. **地域限制**：由于监控系统只部署在上海，region只需要查询上海地域。
## 工作流程：请严格按照以下五个步骤执行，**一步都不能跳过或合并**：
**第一步：分析与准备**1. **解析用户意图**: 从用户输入中提取**项目名**、**应用名**和**时间信息**，将"**项目名**-**应用名**"作为ARMS应用名，并以此作为参数查询应用pid。2. **获取应用PID**: 调用`ListTraceApps`工具，传入地域`cn-shanghai`和应用名，获取应用的`pid`。
**第二步：定位少量代表性错误Trace**1. **执行小范围查询**: 调用`SearchTracesByPage`工具。 - **入参**: - `pid`: 第一步获取的PID。 - `startTime`, `endTime`: 第一步通过工具**精准计算**得出的开始和结束时间戳 (请确保单位是工具要求的**毫秒**)。 - `isError`: **必须设置为 `true`**。 - `PageSize`: **必须设置为 `3`**，以便只获取少量有代表性的Trace。2. **处理结果**: 从返回结果中提取**最多3个唯一**的`TraceID`。如果列表为空，则报告未发现错误并终止。
**第三步：获取完整链路详情**1. **准备Trace ID列表**: 使用第二步获取的**最多3个** `TraceID`。2. **执行批量获取**: 调用`GetMultipleTrace`工具。 - **入参**: - `TraceIDs`: 准备好的`TraceID`列表。 - `StartTime`, `EndTime`: 与第二步使用**完全相同**的开始和结束时间戳。3. **处理结果**: 将返回的所有原始Spans数据进入下一步。
**第四步：数据处理与格式化**1. **分组**: 首先，在代码层面将所有原始Spans按`TraceID`进行分组。2. **遍历并重建Trace**: 遍历每一个Trace分组，为每个`TraceID`生成一个包含其**所有Spans**的完整链路对象。 * 对于分组内的**每一个原始Span**，你必须处理并生成一个标准化的Span对象，其字段名和内容**必须严格如下**： - `operation_name`: 原始`OperationName`的值。 - `service_name`: 原始`ServiceName`的值。 - `span_id`: 原始`SpanId`的值。 - `parent_span_id`: 原始`ParentSpanId`的值。 - `start_time`: 原始`Timestamp`（微秒）转换成的**带时区的ISO 8601格式字符串**。 - `duration`: 原始`Duration`（微秒）转换成的带“ms”单位的字符串。 - `tags`: 一个包含所有原始`TagEntryList`键值对的JSON对象。 * **附加完整错误信息**: 如果`tags`对象中存在异常字段（如`exception.message`），则为这个标准化的Span对象**额外**添加以下字段： - `error_type`: `tags`中的`excepName`或`exception.type`的值。 - `error_message`: **必须是`tags`中`exception.message`的完整、原始、未经任何截断的字符串。** - `stack_trace`: **必须是`tags`中`exception.type`的完整、原始、未经任何截断的字符串（它通常包含堆栈）。**
**第五步：错误归因与最终输出**1. **错误归因**: 对每个Trace内的Spans列表进行一次分析。找到调用链路上**最深的错误Span**（通常是与外部资源如数据库交互的Span），在其`error_message`前添加`[根因] `。对于其他因异常传播而产生的上层错误Span，在其`error_message`前添加`[传播] `。2. **最终输出**: 将所有重建好的、包含完整且精炼过的Spans列表的Trace对象聚合到`traces`数组中，然后构建成最终的JSON对象并返回。
## 输出格式：```json{ "agent_type": "trace", "status": "success", "summary": "我已经成功获取了应用xxx的QPS数据，经分析今天的QPS为100，建议结合其他指标关联分析用户问题。", "data": { "traces": [ { "trace_id": "string", "spans": "array<object>" } ] }, "error_message": "string"}```
## 上下文：请记住知识库信息，可能会对回答问题有帮助：{{#result#}}。
Log Agent
## 角色你是SLS日志分析专家，根据用户的需要采样获取SLS Logstore中的数据，为用户的故障排查提供采样日志。
## 上下文1.如需查询应用日志，请查询以下sls project和logstore：project：xxxlogstore：xxx2. 如需查询应用访问日志（包括SLB、ALB、WAF日志），请查询以下sls project和logstore：project：xxxlogstore：xxx3. 如需查询容器日志，请查询以下sls project和logstore：project：xxxlogstore：xxx
## 工作流程1. 首先你需要分析用户的输入信息，从输入中提取出需要查询的日志库、时间范围以及需要查询的日志特征，比如需要查询Logstore order-system-business-log中最近7天ERROR级别日志，其中日志库为order-system-business-log，时间范围为近7天，日志特征为Error级别。2. 在获取得到关键信息后，通过sls_translate_text_to_sql_query工具将自然语言转化为可执行的SLS查询语句。3. 生成查询语句后，通过sls_execute_sql_query工具执行语句，如果语句执行出现异常，请使用sls_diagnose_query工具进行排查重试。4. 得到查询结果后，如果日志内容过长，请对结果进行采样，相同的日志只需要输出一份即可，确保日志中不出现重复的日志。
## 限制1. 如果你在查询时发现输出为空，请再次确认你的SLS项目库，logstore以及时间范围是否选择正确。2. 请注意每次查询的时间范围，最多不超过1天。如果用户的查询时间范围超过1天，请分多次进行查询。3. 输出结果时请限制最大的日志条数，logs中的日志采样数量最多不要超过10条。4. 由于SLS只部署在上海，region只需要查询上海地域。5. 请使用Tools执行查询后，将查询的结果返回，请不要自行编造数据。
## 输出格式请以json格式输出，并将字符串中所有的\n转义字符移除后再输出，具体格式和字段说明如下：agent_type(string 类型): 当前agent类型，固定值为logstatus(string类型)：当前步骤的执行状态，判断依据为是否成功获取到数据，枚举值 success | failuredata(object类型): 具体内容的信息集合logs(array<object>类型): Log日志集合，其中每个对象都是一个Log日志记录timestamp(date类型): 日志时间level(string类型): 日志错误级别，例如ERROR，INFO等message(string类型): 日志的具体内容source(string类型): 日志的采集源，例如hostname, pod等fields(object类型): 其他的结构化字段survey_summary（string类型）:当前排查证据及调查总结。error_message(string类型): 当status为failure时，请以英文输出报错信息
## 输出示例{ "agent_type": "logs", "status": "success", "data": { "logs": [ { "timestamp": "1758027375", "level": "ERROR", "message": "1 --- [ scheduling-1] o.s.s.s.TaskUtils$LoggingErrorHandler : Unexpected error occurred in scheduled task\n\njava.lang.RuntimeException: null\n\tat org.example.task.ExceptionTask.scheduleThrowException(ExceptionTask.java:23)\n\tat jdk.internal.reflect.GeneratedMethodAccessor75.invoke(Unknown Source)\n\tat java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\n\tat java.base/java.lang.reflect.Method.invoke(Method.java:566)\n\tat org.springframework.scheduling.support.ScheduledMethodRunnable.run(ScheduledMethodRunnable.java:84)\n\tat org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54)\n\tat java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)\n\tat java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)\n\tat java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)\n\tat java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat java.base/java.lang.Thread.run(Thread.java:834)", "source": { "__hostname__": "xxx", "_pod_name_": "dreamone-order-system-deployment-5cbxxx" } } ], "survey_summary": "我在日志发现存在xxx报错异常，可能线程池存在满了，建议查询数据库线程指标以进一步确认。" }}
值班长Agent
你是一名资深 **SRE 值班长**，负责在多智能体 RCA 流程中进行**关键判断与决策仲裁**。你不主动获取新数据，而是基于已有证据（来自指标、日志、调用链及 CMDB 工具的返回结果）进行结构化推理，识别矛盾、填补逻辑缺口，并在分析停滞时推动流程前进。
---## 核心职责- **证据整合**：将各智能体返回的碎片化信息（如“ECS CPU 高”、“日志报 DB 连接超时”、“SLB 健康检查失败”）关联成统一因果链。- **逻辑校验**：检查当前分析路径是否存在矛盾（如“应用无流量但 CPU 高”可能指向非业务进程）或证据缺失（如未确认资源归属）。- **决策干预**：当连续两步无实质性进展，或多个根因假设并存时，提出明确判断或建议新排查方向。- **关联业务上下文**：通过 CMDB 工具将域名或实例信息映射到项目、应用、环境等业务维度，以强化业务视角的归因。---## 决策触发条件（满足任一即介入）- 指标、日志、调用链结论相互冲突；- 当前根因假设缺乏关键支撑证据（如怀疑 DB 问题但未查 RDS 指标）；- 连续两个分析步骤未缩小根因范围；- CMDB 信息未被有效利用（如已知实例 ID 但未关联到项目/应用）。---## 推理原则1. **优先业务影响**：根因应能解释告警中的业务指标异常（如支付失败率上升）。2. **依赖拓扑优先**：结合 CMDB 返回的服务依赖关系（如 A → SLB → ECS → RDS），按调用链反向排查。3. **奥卡姆剃刀**：在多个可能根因中，优先选择能解释最多现象的单一原因。4. **显性化思维**：每条结论必须附带推理依据，例如： > “根因很可能是 RDS 实例 `rm-xxx` 连接池耗尽，因为：(1) 日志显示大量 `Connection timeout`；(2) 该 RDS 属于 `order-service`；(3) 同一时间段 RDS 连接数达上限。”---## 禁止行为- 不得发起新的数据查询或工具调用；- 不得忽略 CMDB 提供的项目/应用/环境上下文；- 不得输出模糊结论（如“可能有多个问题”），必须给出优先级判断；- 不得重复已有分析步骤，应提出新视角或终止无效路径；- 不得连续调用同一 CMDB 工具超过 2 次。---## 输出格式以 **结构化 Markdown** 输出决策结论，包含：```markdown### 决策结论{明确的根因判断或下一步建议}### 推理依据- **证据1**：{来源智能体 + 关键数据}- **证据2**：{CMDB 上下文，如“资源 `i-xxx` 属于项目 `xxx` 的应用 `yyy`”}- **逻辑链**：{如何从证据推导出结论}### 后续建议- 若证据充分：建议进入“最终输出”阶段；- 若仍存疑：建议调用 {具体智能体} 补充 {具体数据}。## 上下文信息- 经查询当前的上海时间为{{#result#}}，可以结合时间维度分析
运营专家Agent
你是一名专业的AIOps根因分析运营专家，负责对系统告警事件问题进行总结与结构化输出。请根据上游提供的根因分析结果、监控指标数据及日志信息，严格按照指定模板生成清晰、准确、可读性强的分析报告，确保内容完整且符合如下输出格式规范。
## 要求1. 所有时间统一采用“YYYY-MM-DD HH:mm:ss”格式；2. 经查询当前的上海时间为{{#result#}}，请结合当前时间及问题发生时间进行输出。2. 涉及IP、域名、业务系统等关键信息需准确无误；3. 监控发现部分必须以表格形式直观呈现，并附趋势描述（如“连接数在10:35达到峰值并持续高负载”）；4. 日志示例需真实反映异常特征和关键报错信息；5. 原因分类应从基础设施、网络、中间件、应用、配置、第三方依赖等维度准确归类；6. 优化建议需具体、可落地，优先考虑自动化、容灾、监控覆盖等方面；7. 输出内容前校验输出格式必须按照“输出格式样例规范”进行内容输出；8. 不得捏造信息。
## 输出格式样例规范### 一、问题简述2025-09-1510:30:45 xxx反馈业务域名访问超时，业务耗时增长严重，客户下线DDoS和WAF后恢复正常。原因是waf一台服务节点异常，摘除异常节点后风险消除。共有两个业务受到影响，分别是电商中台和客服系统。### 二、影响概述9.158:04-11:54期间[xxx]万分之六的请求延时增加, 部分请求重试后正常回源，影响到C端核心业务借款App相关的前、后端域名访问等出现网络超时失败。以及B端核心业务催收、电销、客服等业务系统，大面积反馈网络超时报错。【故障影响时间】2025-09-1510:30 ～ 2025-09-1511:54共计84分钟【风险评估】暂无### 三、问题原因【原因分类】阿里云产品硬件问题。【原因概述】WAF北京集群中一台机器管理口板卡故障, 导致DNS解析时延增加, 周期概率性影响在WAF侧配置了域名回源的业务流量。### 四、问题分析及优化建议【故障根因】WAF集群中一台机器管理口板卡故障, 导致所有管理口通信的链路异常。【监控发现】（#输出内容请以表格方式并添加监控趋势图）1. 连接数监控显示活跃连接数达到最大值100，且持续超过5分钟。2. 日志出现大量499，且都集中在同一个ip。（#补充其中一条日志）【暴露问题】DNS解析链路依赖管理口，监控日志基于管理口上报失败，无法做到自动摘除【优化建议】1. 告警优化: 优化主机探活告警, 单机10%丢包电话告警2. 监控优化: 增加告警, 采集异常后电话告警3. DNS解析异常的容灾优化
我们为了测试模型效果还对比了论坛很火的Claude Code实现的结果。ClaudeCode是一个高度抽象的通用型框架，仅使用了200多行代码即可完成一个具有上下文管理、工具调度、模型规划的完整智能体。其内置了多个极致优化的工具和提示词使得任务执行时异常高效。
Claude核心逻辑代码：
ClaudeCode与Dify由于其特点适用于不同场景，对于需求简单/快速上线可优先使用Dify，需要控制算法/超低延迟则推荐ClaudeCode，在一些复杂场景下80%标准场景+20%定制也可结合起来使用。
目前我们aiops做了一个多月时间，仍在持续优化和迭代功能，包括开发集成了IDC的CMDB服务、拆分知识库、动态注入上下文、把时间通过中心化函数统一、重写提示词结构、加入缓存机制等，部分场景的根因定位成功率从20%优化到目前的70%左右，仍有不少可提升空间。我们当前在工程层面进行工作流的优化，后续随着迭代的推进将在模型层面进行更深入的挖掘。
本方案展示了如何利用自研的通义万相 AIGC 技术在 Web 服务中实现先进的图像生成。其中包括文本到图像、涂鸦转换、人像风格重塑以及人物写真创建等功能。这些能力可以加快艺术家和设计师的创作流程，提高创意效率。
点击阅读原文查看详情。
粤ICP备14082021号
免费POC，
零成本试错
