智能运维与SRE变革_Agent驱动的稳定性保障-2026北京站_QECon全球软件质量效能大会-橙柚科技

优惠倒计时

8折票抢购中

团购享更多优惠

北京站 · 10月16-17日

上海站 · 9月4-5日

深圳站 · 5月22-23日

专场：智能运维与 SRE 变革：Agent 驱动的稳定性保障

在系统架构持续演进、业务复杂性指数级攀升的今天，大模型的应用催生了AgentOps新范式，运维与SRE正经历从人工值守向Agent-driven的根本性跨越。以大模型、AIOps为核心的AI技术深度渗透，正在重构DevOps故障排查核心工作流。面向未来的系统，将是智能体深度嵌入的可编程自治体系。以LLM+Agent为大脑的智能体运维框架，正在成为保障系统稳定性的核心引擎。本次专场，我们将聚焦Agent驱动的稳定性保障。重点剖析AI与DevOps融合在稳定性保障中的实际价值，深入探讨智能体运维（AgentOps）在真实业务场景中的落地应用，并解读传统运维人员向智能运维专家转型的关键路径。我们将携手探索在Agent驱动下，构建更可靠、更高效的运维新未来。

专场出品人：马鑫

京东零售架构师

拥有10年以上互联网及传统行业丰富测试经验，2010年底入职京东，一直专注于业务质量测试、自动化测试、性能测试以及持续集成等多个领域；现在负责京东零售618/双11以及大型项目的压测推动与实施、前沿压测技术的探索与实践，以及带领团队构建适用于京东的分布式压测平台；同时也在探索研发效能提升的工程实践与平台的建设。

罗岚丹

bilibili 测试开发工程师

测试开发工程师，硕士毕业于西南交通大学，主要研究方向为自然语言处理（NLP），主攻实体、关系抽取与知识图谱补全。现就职于哔哩哔哩，主要负责车载端业务测试（涵盖Android与Web应用）及客诉AI自动处理系统的开发与质量保障工作。在工程落地中，设计了结合BM25与向量混合检索、需求RAG防误判、Badcase自动化回归及高可用降级机制。立足于一线测试开发实践，持续探索大模型与RAG技术在质量保障右移与智能运维中的落地价值。

待定

基于混合检索与 LLM 双轨决策的智能客诉闭环实践：

从精准分流到高置信自动化处置

议题背景：

随着哔哩哔哩智能终端业务的发展，大屏TV、车载等场景的客诉处理面临多终端差异、业务规则变化与反馈分散等挑战。传统依赖人工检索和经验判断的处理方式，逐渐暴露出以下问题：

历史相似问题反复排查，处理经验分散在工单和群聊中，难以有效沉淀与复用
产品设计与版本持续变化，难以快速区分软件异常、功能限制和业务规则调整，增加研发与测试的核查成本
客诉反馈零散、责任归属复杂，重复问题消耗处理精力，需要重点关注的问题难以及时获得跟进

在研发迭代加快的背景下，如何及时响应客诉、复用已有知识，并控制自动化处置风险，成为质量保障的重要课题

为此，我们以工单系统为基础，构建了历史案例知识库与业务逻辑知识库共同支撑的智能客诉处理体系：通过混合检索复用历史经验，通过业务知识检索核查需求变更，由大模型生成综合建议，再通过程序校验执行条件，衔接自动处置、责任分发与人工核实，形成从知识沉淀到工单执行、效果反馈的完整闭环，从而提高高优客诉问题识别率和解决率。

内容大纲：

1.背景与痛点

1.1 研发迭代加速下的客诉响应挑战

面向多终端业务与持续变化的线上环境，分析客诉及时跟进、问题核查与快速止损的现实需求

1.2 重复排查与分散反馈带来的处理瓶颈

剖析历史经验难复用、重复问题消耗人力以及严重反馈易被淹没等治理痛点

1.3 客诉治理目标：及时跟进、经验复用与重点聚焦

通过AI辅助分析和自动化处理减少重复操作，为人工深入排查关键问题释放精力

2. 落地细节

2.1 系统整体架构：知识供给、在线处理与反馈支撑

以历史案例知识库与业务逻辑知识库提供处理依据，串联客诉接入、混合检索、大模型分析、处置校验与执行协同
将建议生成与实际执行分离：大模型负责结合证据形成判断，程序负责校验处理条件、确定责任人并执行工单操作

记录检索依据、分析建议与执行结果，将人工确认的处理经验沉淀为知识，支撑后续复用与回归验证

2.2 历史案例知识库：经验沉淀与混合检索

从已处理工单中提取问题描述、适用范围、真实处理结论及处理人，区分人工确认记录与模型建议，保留来源以便追溯

按业务与应用范围限定候选，BM25 词面检索与向量语义检索分别召回Top 20，通过RRF排名融合、去重后选取Top 5，兼顾关键词匹配与不同表达下的语义关联
大模型逐条比较故障对象、触发场景与处理条件，后端继续校验引用及结论有效性，避免将描述相似直接等同于处理方案可复用

2.3 业务逻辑知识库：需求变更提炼与适用性核查

定时同步已上线需求，按来源标识去重并清洗富文本、附件及过程记录，由大模型提炼核心业务变更，同时保留适用范围、生效条件与例外限制

将业务知识分片、向量化并关联来源，结合业务、终端与版本等信息限定检索范围，完成语义召回、文档去重与适用性核查

对缺少可靠历史匹配的客诉补充检索，必要时读取来源正文，核实片段中未完整呈现的条件，为区分业务变更与疑似缺陷提供依据

2.4 AI综合建议生成：融合案例经验与业务依据

将当前客诉、候选历史案例、业务资料组织为模型输入，明确区分问题事实、历史结论和业务规则

通过提示词限定判断范围与输出结构，生成问题匹配类型、综合建议、引用依据、置信度及建议处理动作，对信息不足的部分列出待核实事项

后端校验引用是否来自本次候选、处理结论是否真实有效；补查获得新增依据时再进行综合分析，减少重复调用与无依据推断

2.5 自动处置：从模型建议到校验后执行

将模型置信度作为准入条件之一，联合检查引用有效性、处理依据、适用范围与建议动作，避免仅凭高评分触发工单操作

检索不完整、模型失败或依据存在冲突时，阻止自动处置并保留建议；满足条件后，根据建议动作执行对应的工单流转

执行前重新核对工单状态与分析结果是否仍然适用，防止旧建议写回和重复操作，并记录执行结果或阻断原因，支持后续核查

2.6 责任分发与人工采纳：形成协同处理闭环

通过提示词限定算法、产品、运营及其他领域，输出结构化分类字段，由程序映射配置中的责任人；未命中时进入业务模块匹配

模块匹配采用业务自定义关键词计分与排除词过滤，最高分并列时由AI在候选模块内辅助判断，再依次使用有效历史处理人和配置的默认负责人兜底

转交工单时同步携带综合建议、参考依据与待核实事项，通过企微通知支持人工查看和一键采纳，将确认后的处理结果用于知识维护与后续复用

3. 问题优化与系统质量保障

3.1 自动处置正确率保障

围绕依据真实性、适用条件和执行资格建立校验机制，对不满足条件的结果保留建议并明确待确认事项

3.2 大模型幻觉与错误引用防控

从输入资料、生成约束和输出核验三个环节，减少虚构原因、错误处理结论与无效引用

3.3 Token消耗与重复调用优化

通过入库清洗、检索收敛、输入预算和有效结果复用，控制长文档与多轮分析带来的累计开销

3.4 分析质量回归验证

构建典型客诉与易混淆场景的回归集，在模型、提示词和检索策略调整后，核对召回质量、分析结果及执行决策

3.5 异常场景自动化测试

覆盖知识检索超时、资料不完整、无效引用与工单状态变化，验证系统在异常条件下的降级和操作拦截能力

4. 案例与成果量化

4.1 典型客诉的闭环处理实践

结合历史问题自动处置、相似问题责任分发、业务规则补充核查及产品建议转交，展示系统在不同场景下的实际应用

4.2 响应效率与处理质量的量化评估

围绕首次跟进时效、AI分发与处理覆盖、分发准确率和处理准确率，呈现业务落地成效

4.3 引入AI前后的处理方式对比

从历史经验复用、业务规则核查、工单协同和人工投入等方面，展示客诉处理流程的变化与收益

5. 总结与未来展望

5.1 落地前提与渐进式建设路径

以可追溯的历史记录、可核查的业务规则和可验证的工单流程为基础，逐步从辅助分析推进到自动处置

5.2 核心实践经验

总结处理记录规范、双知识库分工、分环节问题定位，以及分发时携带建议与依据的工程价值

5.3 后续能力演进

探索新客诉中的缺陷识别、结合日志与配置的诊断智能体，以及真实客诉向回归用例的转化，进一步连接线上反馈与质量保障

听众收益：

1.掌握双知识库驱动的客诉分析方法，理解历史经验与业务规则的互补关系，学会通过混合检索与大模型综合分析，将分散知识转化为可追溯的处理依据

2.获得AI客诉闭环的工程实践经验，理解自动处置校验、责任分发与人工采纳的协同机制，掌握从模型建议到工单执行的落地方法

3.学习兼顾分析质量与调用成本的优化策略，通过幻觉防控、引用核验、Token控制及自动化回归，提升AI应用的可靠性与运行效率

隰宗正

阿里云可观测技术专家

专注于可观测全栈研发、统一数据建模与 AI Agent 工程化，是 UModel（阿里云可观测数据建模模型）核心开发者。围绕日志、指标等多源异构数据，深度参与 UModel 语义模型、实体关系、映射规则和查询能力的架构设计与落地，推动从数据源发现、自动建模、关系推断，到计划生成、验证、发布及结果回写的端到端闭环。具备 UnifiedModel、STAROps等平台实践经验，持续探索大模型工具调用、人机协同、评测与状态追踪在企业级可观测场景中的应用，致力于将领域知识沉淀为可复用、可验证、可持续演进的智能能力。

待定

从数据驱动到建模驱动

——UModel面向 Agent 智能运维的通用可观测建模

议题背景：
随着微服务和云原生的普及，传统"Metrics-Traces-Logs"三支柱模式面临根本困境：从海量异构数据中反向推理系统状态是极其困难的逆向工程问题。阿里云可观测团队基于 6 年 AgentOps 实践，提出 UModel——基于本体论思想的 IT 世界统一建模框架，融合数据、知识、行动三位一体，实现从"被动收集数据"到"主动建模世界"的范式迁移。UModel 已成功支撑阿里云可观测 2.0 产品体系，覆盖数十万企业客户，将故障定位效率提升 60%+，为 AI 智能体提供可推理、可交互的结构化上下文，让 AgentOps 真正拥有了落地的土壤。

内容大纲：
1. 大模型时代的 AgentOps 认知挑战

1.1 大模型带来的新应用形态与运维模式

从单体应用、分布式应用、云原生应用演进到 AI 应用，AI 应用可观测与智能运维成为新一轮可观测变革。

1.2 Agent 演化即将突破临界点

介绍 Workflow、ReAct、Orchestrator、Tools、Skills、Multi-Agent、Memory、Sandbox、长时任务等 Agent 关键能力。

1.3 通用大模型与运维领域知识之间的鸿沟

分析三类认知难题：运维领域的语义鸿沟、复杂系统拓扑的认知迷宫，以及根因分析过程中数据关联缺失导致的逻辑断链。
【霜键】UModel：构建AI时代的可观测模型.pptx (幻灯片 4)

2. 引入 UModel，统一描述可观测世界

2.1 通过统一模型构建系统“数字孪生”

以观测实体、实体关联和观测数据为基础，统一描述应用、数据库、容器、云资源、用户会话及其关系。

2.2 基于 UModel 重构可观测数据体系

介绍 CommonSchema、CommonSchemaRef、UModel PaaS、SPL 统一计算框架、实体存储计算引擎和关系存储计算引擎，以及 UModel Explorer、Entity Explorer、Data Explorer 和 UModel MCP。

2.3 UModel Explorer 与全局实体拓扑

展示基于统一模型形成的全局实体拓扑，以及从实体视角探索系统资源和关系的方式。

2.4 基于实体拓扑进行问题排查

展示从异常实体出发，沿系统拓扑查看上下游关系、关联数据和影响范围的排查过程。

2.5 以图为中心的 UModel 建模概念

介绍 EntitySet、TelemetryDataSet、LogSet、MetricSet、TraceSet、Storage，以及 EntitySetLink、DataLink、StorageLink。

2.6 UModel 架构全景与应用示例

说明模型层、存储层和可观测应用之间的关系，以及实体、日志、指标、链路、事件、变更和代码仓库如何共同支撑故障定位。

3. EntityStore 与多源数据融合查询

3.1 EntityStore 整体架构

介绍 Put & Pull、FIFO Queue、Scheduler、EntityStore Worker，以及行存、列存、MCSR、时间与 ID 索引、全文索引、向量索引等能力。

3.2 多查询引擎与数据管理

通过 SPL、Cypher、PromQL 支撑不同查询方式，并提供 Quota、Cache、Retention、Compaction 等数据管理能力。

3.3 图逻辑模型与图存储查询

对比递归 SQL 与 Cypher 图查询，展示后代节点查询、技能关系查询和多跳路径查询。

3.4 日志、指标、事件与拓扑的融合查询

展示从错误日志提取 IP 并关联指标进行异常检测、从告警实体查询五跳范围内事件，以及将动态构建的外部图与 EntityStore 图进行合并查询。

4. UModel PaaS 数据模型与接口能力

4.1 Tabular 与 Objective 两种数据模型

Tabular 模式面向 EntitySet、LogSet、MetricSet、TraceSet 等数据集合；Objective 模式以 Service、Host、DB 等实体对象为中心组织数据。

4.2 Tabular 查询与面向对象调用

展示 MetricSet 的表式查询，以及通过 .entity_set | entity-call 调用实体方法、发现可用能力的方式。

4.3 从实体访问关联数据

通过 list_data_set 获取实体关联的数据集，通过 get_golden_metrics 获取实体黄金指标；PPT 同时展示了对象化调用展开后约 6K 的底层查询内容。

4.4 UModel PaaS 功能集合

包括实体和相邻实体查询、指标与 Label 查询、日志与 Trace 查询、关系黄金指标、知识检索、观测执行和行动执行。

4.5 UModel 知识结构

以“图模型＋分层”的方式组织领域模型、实体关系、观测数据和知识能力。

5. 基于 UModel 重构智能运维场景

5.1 智能运维助手的能力版图

覆盖日志分析、应用分析、指标分析、可视化增强、智能告警、根因洞察和智能巡检，并结合异常检测、根因分析、智能预测、自然语言处理和通用算子。

5.2 统一接入多类可观测数据

面向日志、指标、链路、事件、剖析数据和实体拓扑构建统一的智能运维入口。

5.3 智能运维助手实际示例

展示自然语言交互、多轮对话、全场景嵌入、上下文感知、拓扑分析和指标联动，并强调依托内置算法支持亿级可观测数据查询分析。

听众收益：
1. 理解大模型应用于 AgentOps 时面临的语义、拓扑和根因链路三类认知问题，以及 UModel 如何用实体、数据和关系进行统一建模。
2. 了解 UModel 从模型定义、EntityStore、图查询、数据融合到 PaaS 对象化接口的完整技术架构。
3.了解统一模型如何连接日志、指标、链路、事件、知识和行动，并支撑智能告警、根因分析和智能巡检等 AgentOps 场景。

肖杰韬

阿里云技术专家

肖杰韬（花名：六滔），阿里云基础软件团队技术专家，长期参与阿里云Alinux操作系统运维控制台建设，聚焦云主机与容器的稳定性、资源效能与智能化运维。当前投入 SysAgent 核心机制建设，涵盖小模型时序异常检测、多源证据链、OS 问题评测数据集与离线自进化评审，致力于让诊断结论准确、可靠、可落地。

待定

巡检结论如何可追溯、可验证：

SysAgent 的证据链与自进化评审实践

议题背景：
巡检/SRE Agent 落地最大的障碍，往往不是“发现不了异常”，而是“发现了却难以保证结论准确、可靠”：指标、告警、日志、配置彼此孤立，LLM 直接归因容易产生幻觉，用户既无法判断根因对不对，也难以确认处置建议能不能照着做。要让结论准确、可靠，必须守住两条防线。第一条是让证据可追溯：用小模型/统计算法做时序异常检测产出第一手证据，再与告警、指标基线、配置变更等多维数据交叉验证，形成每条结论都能回溯到具体证据、彼此互证的证据链，从源头保证归因准确。第二条是让方案可验证：用 OS 问题评测数据集把真实故障沉淀成可回归的基准，再通过离线 SKILL 自进化系统让评审 Agent 持续进化，让每条处置建议都有历史成功案例支撑、可回归、可验证，保证方案可靠。在覆盖大规模云主机、每天数百次自动调用的生产环境下，这两条防线是巡检 Agent 能否真正闭环的前提。

内容大纲：
1. 问题起点：巡检 Agent 的结论为什么难以准确、可靠

1.1 从“发现异常”到“准确可靠的结论”之间的鸿沟
1.2 两条防线：让证据可追溯（保准确）+ 让方案可验证（保可靠）
1.3 生产环境的现实约束：大规模实例、高频自动调用，误判会被成倍放大

2. 第一条防线 · 可追溯的证据链：让归因准确

2.1 谁生产证据：小模型/统计算法做时序异常检测，大模型只做语义归因
2.2 技术抉择：为什么不用时序基础模型（TimesFM/Chronos 等）做异常检测——稳定性与开销的权衡
2.3 多维证据源：告警、指标基线、配置变更、日志、进程、调用链、Profiling 各补什么盲区
2.4 关键一环：配置变更时间线 × 指标异常时间线对齐（变更是稳定性根因的高频来源）
2.5 可追溯与横向互证：每条结论都挂在具体证据上（趋势 + 横向对比 + memgraph 三源互证）
2.6 主动补证：证据不足时的受控补证、停止条件与收敛判据
2.7 案例拆解：tcp_mem 逼近 max 的 TCP socket 内存泄漏定位全过程

3. 第二条防线 · 可验证的自进化评审：让方案可靠

3.1 OS 问题评测数据集：怎么把真实故障沉淀成可回归的 benchmark（案例 + 标准根因 + 标准处置 + 证据）
3.2 离线 SKILL 自进化系统：误判/未解决案例 → 复盘标注 → 沉淀 SKILL（规则/知识/诊断脚本）→ 回归评测 → 灰度回灌
3.3 评审 Agent 的进化：用评测集校准评审标准，每次误判都成为新样本
3.4 让处置方案可靠：建议有历史成功案例支撑、可回归、可验证，而非模型即兴生成
3.5 独立评审的上下文隔离与评审三问（证据完整性、结论准确性、建议可执行性）
3.6 踩坑：评审沦为“橡皮图章”、评测集覆盖偏差、自进化过拟合到历史案例

4. 闭环：处置 → 复检 → 回流评测集

4.1 处置后自动复检（回检 tcp_mem / 错误率 / 延迟），确认恢复再收单
4.2 复检结果回流，成为评测数据集与自进化的新燃料
5. 收益与复盘
5.1 量化收益：告警降噪比例、诊断准确率、闭环率的提升
5.2 什么场景适合 Agent 化巡检、什么场景别硬上
5.3 下一步：从单实例到集群，资源效能 / 稳定性 / 安全 CVE 的跨域一体化

听众收益：
1. 一套让证据“可追溯”的多源证据链设计方法：如何用小模型异常检测 + 告警 + 指标 + 配置变更交叉验证，让每条诊断结论都能回溯到具体证据、彼此互证，保证归因准确，而不是让大模型凭感觉下判断。
2. 一套让方案“可验证”的自进化工程范式：如何用 OS 问题评测数据集 + 离线 SKILL 自进化系统，让评审 Agent 持续进化、让处置建议可回归、可验证、可靠落地。