当 Agent 从单点试用走向多团队、多场景和生产环境，挑战不再只是“能否完成一次任务”，而是如何统一托管 Agent 的配置、运行时、能力、权限、版本和执行反馈。如果缺少平台化管理，团队需要重复解决部署、通道接入、调试排查、版本发布、安全控制和故障恢复等外围问题，Agent 很难从个体实践演进为可复制的生产能力。

本次分享介绍百度运维部 AgentOps 的平台化建设实践：以 Runtime 全生命周期托管为基础，以安全管控守住执行边界，以场景仿真回放验证任务效果，以知识沉淀形成能力资产，并基于前述能力和用户反馈推动 Agent 自主进化。平台重点解决四类基础问题：如何让 Agent 快速接入并稳定运行，如何让每次变更可控可回滚，如何让执行过程可观测可验证，以及如何将分散经验沉淀为可复用资产。在此基础上，平台持续补充知识驱动的能力构建、规范审计、智能测试和运行时依赖切换等增量能力，推动 Agent 从“能用”走向“敢用、好用、可复制”。

演讲提纲

1. 从单点试用到规模化托管：企业 Agent 落地的新矛盾

• 接入与部署问题：不同团队重复准备环境、配置运行实例和接入消息通道，交付周期长
• 配置与版本问题：Agent、Skill、Prompt、工具和知识缺少统一版本边界，调试容易污染线上版本
• 运行与观测问题：实例状态、会话、工具调用和执行结果分散，出现 bad case 后难以定位
• 安全与权限问题：生产操作缺少统一的权限、审批、限流、审计和回滚控制
• 能力复用问题：公共工具、业务知识和历史经验难以沉淀，场景建设依赖少数专家
• 质量与演进问题：没有稳定的 Case、回放和评估体系，无法判断版本是否真的变好
• 平台定位：AgentOps 统一托管 Agent 的资产、运行时、执行路径和反馈闭环，让业务团队聚焦场景逻辑

2. AgentOps 总体架构：五项核心能力协同

• 接入层与平台 API 网关统一承载 Web、如流和第三方调用，提供鉴权、租户路由与配额控制
• 控制面由安全中心、变更中心、评估中心、知识管理和运行时管理组成，共享资产与观测数据
• 数据面区分正式 Agent 实例与调试沙盒，支持不同运行时以统一方式接入
• 五项核心能力协同：Runtime 全生命周期托管、安全管控、场景仿真回放、知识沉淀、自主进化

3. Runtime 全生命周期托管：让 Agent 稳定运行

• 统一管理 Agent 从创建、配置、部署、运行、升级、监控、故障恢复到下线的完整生命周期
• 统一管理配置、能力资产、运行实例、会话状态、版本发布与运行观测
• 通过健康检查、状态持久化、实例恢复和依赖切换保障 Agent 持续可用

4. 知识沉淀：让业务经验成为能力资产

• 统一管理 Agent、Skill、Prompt、工具、知识、Case 和运行时配置，明确资产之间的版本关系
• 通过知识库、公共能力和历史执行经验降低重复建设，形成可共享的能力供给
• 通过沙盒、Case、Trace 和回放建立从开发到上线的验证链路
• 知识沉淀的子主题包括：基于知识创建 Skill、Skill 规范审计、Skill 单测生成与知识检索引用
• 生成结果仍需经过规范审计、契约校验、场景回放和人工确认，不能直接进入生产

5. 安全管控：让 Agent 执行可控、可审计

• 安全链路：本地安全插件辅助拦截，中心式安全网关校验权限、参数和目标范围，统一审计
• 生产写操作：遵循审批、Dry-run、可回滚、可审计；安全监督 Agent 提供辅助判断，不替代强制控制
• 生产执行遵循风险分级、审批、Dry-run、可回滚和可审计
• 平台以统一网关、策略和 Hook 约束执行路径，不把安全责任交给 Prompt

6. 场景仿真回放：验证 Agent 是否真的有效

• 将线上 Trace 与人工反馈沉淀为 Case，在隔离沙盒中通过 API/HTTP Mock 重建外部依赖反馈
• 对比 Skill、模型和配置版本的任务表现，区分过程正确性、结果正确性与执行成本
• 把失败案例反馈到知识、Skill 和测试，生成候选改进，经审计、评估与发布审核后生效
• 自主进化指受控的能力迭代闭环，不是 Agent 自行修改生产配置或扩大权限

7. 自主进化：让用户反馈推动能力持续变好

• 自主进化建立在前四项核心能力之上，不是独立的模型自学习模块
• 线上执行结果、Trace、失败案例、用户修正和人工评价统一进入反馈链路
• 反馈形成知识、Skill、测试或配置的候选改进，经验证、审计、审批和版本发布后生效
• 形成“运行 → 反馈 → 沉淀 → 构建 → 回放 → 发布 → 再运行”的 Looping 闭环

8. 实践与工程权衡：贯穿一次 Agent 托管和演进

• 以一个真实线上异常场景为主线，贯穿知识准备、Agent 托管、故障处置、经验沉淀和后续复用，而不是分别展示平台功能按钮
• 展示 Agent 如何召回历史经验、组织现场证据、辅助收敛根因，并由工程师完成关键判断、动作授权和效果验收
• 展示一次故障结束后，如何将有效经验、失败尝试、业务知识、处置手册和工具改进回流资产
• 以 Trace、Case、复盘记录和用户反馈说明收益；明确哪些行为由 Agent 辅助，哪些决策仍由工程师负责

9. 总结与展望：从 Agent 托管走向经验共享与自主进化

• 整体目标：以知识沉淀和用户反馈为核心，提供一套标准、高可靠的百度 SRE Agent 建设方案
• Looping 闭环：通过“运行 → 反馈 → 沉淀 → 构建 → 回放 → 发布 → 再运行”，推动 Agent 能力持续改进和自主进化
• 最终愿景：让 Agent 实践从单点探索走向平台化建设、标准化复用和规模化落地

实践痛点

• 知识到可执行能力的转换难：文档常缺少前置条件、失败路径和权限边界，不能直接等同于可靠 Skill
• 生成与验证可能同源出错：同一模型生成 Skill 和测试时，可能把相同误解写进实现与断言
• 安全与处置效率存在权衡：生产操作必须受控，但审批、网关和审计链路不能成为新的故障放大点
• 高可用超出基础设施范畴：模型、密钥配置切换涉及授权、工具调用兼容、上下文连续性和重复执行风险
• 离线结果与线上表现存在差距：Mock 覆盖不完整、知识过期和模型变化都会影响回放结论的适用范围

演讲亮点

• 知识驱动的能力生产链路：打通知识沉淀、Skill 智能创建与单测智能生成，把专家经验变成可验证资产
• 分层质量保障：用规范审计、单测和场景回放分别解决合规、行为和任务效果问题，避免单一评分替代质量判断
• 面向模型依赖的 Agent 高可用：从实例与会话恢复扩展到模型、密钥配置快速切换，关注真实任务的连续性
• 可控的持续进化闭环：把生成、验证、发布、运行和反馈串联起来，能力更新可选择、可追溯、可回滚

听众收益

• 获得从业务知识到 Skill、单测和评估 Case 的建设方法，降低能力交付对个人经验的依赖
• 理解如何组合规范审计、单测和沙盒回放，构建分层质量门禁并避免“自证正确”
• 掌握 Agent 高可用的分层思路，以及模型与凭据切换中的兼容性、授权和重复执行边界
• 获得控制面与数据面分离的 AgentOps 架构参考，把安全托管和持续改进纳入统一工程体系

随着 AI 能力进入 SRE 领域，可靠性工程本身的不可靠因素也在增加。业界公开的 SRE Agent 实践大多停留在告警和故障分析这类只读场景避免对生产环境进行操作，价值有限。LLM 的概率性输出、存在幻觉且难以复现，与 SRE 要求生产环境的确定性、准确性、一致性存在尖锐的矛盾，并且这个矛盾不会因模型变强而消失。我们的解决方案不是让 LLM 变确定，而是用 Harness 工程管控它的不确定性，这也是“理性驾驭”的真实含义。

腾讯游戏基于已完成的游戏应用交付的代码化与 GitOps 引擎建设，发布变更本质上变成了改代码改配置，恰好落在 AI 当前最成熟的能力区间 — Al Coding。这套方案同时给了 Al 稳定的上下文，也给了它一条无法绕过的变更护栏：变更必经 Git 与人工 Review。在此之上，我们让多个 SRE Agent 与人协作，参与到发布变更、扩缩容、配置与基础设施调整、故障修复等基础运维执行的动作中；每次任务的过程被完整记录，经评估后沉淀为可跨业务共享的能力，从而提升整体 SRE Agent 的运维能力。

本次分享结合腾讯游戏的真实案例，分享 GitOps Harness 工程底座与不可绕过的变更护栏、人与多 AI Agent 的协作机制、先评估再沉淀的经验复用设计，以及可复用的落地经验与踩坑教训。

演讲提纲

1. 行业趋势与挑战

• 业界现状：SRE Agent实践普遍停留在只读分析层，本质是只看不动手
• 根本矛盾：LLM 概率性输出与生产环境确定性要求的冲突，不会因模型进化而消失
• 协作缺口：对话框式的单人单线程无法承载团队协作
• 经验难以复用：Agent 完成的任务缺乏质量判定，经验散落在个人与会话中，无法沉淀为组织资产

2. 案例：如何让 SRE Agent 敢碰生产环境

• 工程底座：全面代码化与 GitOps
• Agent 专家团编制
• Harness 四段闭环与变更护栏
• 实践案例：SRE Agent Team 协同完成云基础设施和游戏应用的扩容

3. 案例：如何让 SRE Agent 与人之间协作

• 看板与 Issue 的状态传递机制
• 面向业务而非个人的 Agent 记忆
• 实践案例：端到端告警自愈闭环—告警到达、自动建单、生成变更、人工审核、合并执行、观测验证

4. 案例：如何让经验越用越强

• 工单与 AI 工时
• 从工单到 Skill

5. 总结与展望

• 组织层面的提效路径：经验沉淀在业务而非个人手上，提效从个人推进到组织
• SRE 左移和上移：从过程中盯着纠偏，转向事前定义边界与验收条件
• 什么该被长期沉淀：不是操作技能，而是“什么算做完、什么情况必须停下来找人"的判断标准

实践痛点

• 不同业务的游戏架构差异很大，如何低成本建立并持续维护业务上下文，让 Agent 的记忆随使用增长而不失真、不过期
• 当 AI 能变更生产环境之后，如何自动生成足够充分的变更影响分析，让 SRE 在几十秒内判断风险
• 多个 Agent 接力时，如何固化诊断证据链，避免下游重复探路、误读上游结论，同时把上下文与调用的成本控制在可接受范围
• Skill 越积越多之后，如何做可见性分级与定期清理

演讲亮点

• 让 SRE Agent 参与基础运维的方案：结合 GitOps 引擎、多 Agent 专家团编制与评估治理体系的 SRE 执行方案
• 真实业务场景下的落地实践与踩坑经验：结合腾讯游戏的真实案例，分享 SRE Agent 从只读分析到代码变更的演进过程与实际效果

听众收益

• 了解如何让 SRE Agent 参与到基础运维的执行动作中：发布变更、扩缩容、配置与基础设施调整、故障修复
• 了解人与多 Agent 协作中状态传递、业务记忆和能力治理的真实难点
• 了解一套从代码化、GitOps、人工 Review 到观测验证的生产级的 Harness 架构

AI 正快速进入研发、测试与运维场景，但“给 SRE 加一个 AI”并不等于真正的 AISRE。尤其在大数据平台中，故障链路复杂、组件依赖繁多、运维知识高度依赖专家经验，AI 从“辅助分析”走向“生产执行”仍面临信任、知识与闭环等问题。本次分享将结合携程大数据平台的实践，围绕稳定性、运维效率与成本治理三个典型场景，分享 AI 如何真正进入 SRE 的生产闭环。

演讲提纲

1. 开场：AI 到底能不能接管 SRE？

从三个真实问题切入：

• 告警来了，AI 能不能自己判断？
• 服务异常，AI 能不能自己修？
• 存储成本上涨，AI 能不能自己找出浪费？

结论：AI 能回答 SRE 的问题，不代表 AI 能承担 SRE 的工作。

2. 从 AI 辅助到 AI 闭环：SRE 的 AI 化到底意味着什么？

• AI 看懂告警、日志、指标
• AI 关联上下文并定位根因
• AI 生成处置方案
• AI 调用工具执行操作
• AI 验证执行结果并形成反馈

结论：真正的 AISRE，不是增加一个 AI Copilot，而是让 AI 进入完整的运维闭环。

3. 实践一：从“告警”走向“自愈”——AI 如何参与生产故障处置？

• 痛点还原
  • 告警噪音大，定位慢，人工处置依赖经验
• 闭环体系设计
  • 告警收敛与分级策略
  • 根因定位：从"报警"到"给答案"
  • 自愈执行：预案库加自动触发机制
  • 人工审核兜底：人监督AI的落地形式
• 效果
  • 平台故障 MTTR 降低 50%
  • 关键踩坑点：自愈误操作的防护机制

4. 实践二：从“专家经验”到“智能诊断”——核心组件故障如何让 AI 真正理解？

• 痛点还原
  • 组件种类多，问题现象分散，诊断依赖资深专家
• 工具设计思路
  • 诊断知识的结构化沉淀，包含案例库、规则库
  • AI辅助分析：日志理解加指标关联
  • 工具化设计：诊断能力作为可调用服务
• 效果与经验
  • 新人上手时间缩短，on-call 压力下降
  • 踩坑点：AI 给出错误诊断建议的处理机制

5. 实践三：从“资源监控”到“成本治理”——AI 如何参与存储优化决策？

• 痛点还原
  • 存储成本持续膨胀，人工治理效率低
• 工具建设思路
  • 数据访问特征采集与冷热识别模型
  • 自动化分级存储策略推荐
  • 与业务方的协作闭环
• 效果
  • 存储单价下降 20%
  • 踩坑点：冷热判断误判对业务的影响及补救措施

6. 总结：从 AI 辅助走向 AI 原生运维

• AISRE ≠ AI + SRE 的简单叠加
• 三个实践背后的共同基础
• 演进路径与未来展望

实践痛点

1. 自动化执行的信任建立需要过程

• 告警自愈闭环上线初期，工程师对"AI自动操作生产环境"普遍存在顾虑。需要经历"只看不动→人工确认后执行→低风险操作自动执行"的渐进式信任建立过程，不能一步到位

2. 知识沉淀是需要建立闭环机制而非一次性工程

• 智能诊断工具的核心是知识库，但故障经验高度依赖老专家，提炼和结构化的过程阻力大、耗时长，且随着组件版本迭代需要持续维护，容易出现"知识库上线即过时"的问题。

3. 效果评估的量化存在难度

• 目前虽然通过 MTTR 可以进行一定程度的量化，但 MTTR 的影响因素不能完全归因于AISRE的相关实践

演讲亮点

SRE 相关实践具有普适性，对其他 SRE 团队有参考价值，不只是晒成果，而是给同行一套可复用的方法论

听众收益

1. 一个可复用的方法论框架

•  “数据友好→开发友好→运维友好”三层递进模型，帮助听众评估自身团队的 AI 落地成熟度，避免跳步建设的陷阱

2. 三个可落地的工程实践

• 告警+自愈闭环的设计思路与防误操作机制
• 大数据组件智能诊断工具的知识结构化方法
• Storage Insight 冷热数据识别的实现路径

每个实践均来自携程生产环境，有具体踩坑经验可借鉴。

3. 一个清醒的认知校准

• 明确“AISRE ≠ AI + SRE 简单叠加"，帮助听众识别团队当前瓶颈到底是 AI 能力不足还是基础设施不够成熟，避免在错误的层面投入资源

4. 真实的效果数据参照

• MTTR 降低 50%、存储单价下降 20%，为听众在内部推动类似项目时提供可引用的行业参照数据

AI 正快速进入 SRE 各环节，但"给 RCA 加一个AI"并不等于真正的智能定位。一次故障的根因排查，往往要跨多个平台取数、人工串联调用链、跨团队协同，慢且容易判错；而生产环境不容试错，根因一旦判错，止血动作随之偏离。直接把大模型放在 RCA上，几个问题很快冒出来：取数不稳时，模型容易把"查不到"当成"没问题"；因果容易倒置，自愈、重启这类恢复动作常被当成根因；来源容易污染，告警卡片里的结论会被模型直接采信。

为此，我们没有让大模型单挑 RCA，而是用 Agent 把工程和大模型各管一摊：代码负责确定性取数与规则判定，大模型只在多域证据的模式与因果推理上发力，再用因果校验、置信度、根因独立性把它约束在可靠范围内。蚂蚁SRE 围绕这套思路沉淀了完整方案——以统一可观测本体为数据底座，告警、客诉、端智能、业务归因四类场景各做一个可路由 Skill，告警触发后由云端 Agent 自动执行，数分钟内产出带置信度的根因报告。

本次分享讲方案设计与核心实现，也讲踩过的坑：减少外部依赖、动线接口间歇性返空、不同本体时间戳格式不一致。目前召回接近全覆盖，准确率经数月迭代超过既定目标，产出稳定在分钟级。这套方案未必最优，能力边界与未解问题也会如实讲清，作为一份真实实践，与同行探讨。

演讲提纲

1. 背景与问题：RCA 要什么，现在卡在哪

• AI 已快速进入 SRE 各环节，但“给 RCA 加一个 AI”并不等于真正的智能定位

• RCA 的真正诉求：可信根因 + 可执行止血决策 + 分钟级时效，不是给个原因

• 现状痛点：跨多个平台取数、人工串联调用链、跨团队协同，慢且容易判错；排查经验高度依赖人、难沉淀，新人上手慢

• RCA 不容试错：根因判错会直接污染止血决策，可能演变为事故

• 结论：可信优先于快，这是整套架构的出发点

2. 直接用大模型做 RCA，会遇到的三个问题

• 取数误判：取数接口不稳或返空时，模型容易把“查不到”当成“没问题”下结论

• 因果倒置：自愈、重启、摘机这类恢复动作，常被当成根因

• 来源污染：告警卡片里自带的结论被模型直接采信，失去独立判断

• 这三个问题决定了：不能让大模型单独承担 RCA

3. 解法与核心架构：把大模型关进确定性笼子

• 用 Agent 把工程与大模型各管一摊：工程负责确定性取数与规则判定（产出可复现的事实），大模型负责多域证据的模式匹配与因果推理，Agent 按排查动线把两者编排成一条可信流程

• 分层架构：代码取数（只产出事实，不产出结论）+ 大模型判断——取数可复现、结论可解释、模型不编造

• 数据底座：统一可观测本体，用一个本体模型抽象十余类可观测数据，替代跨平台人工取数

• 可信护栏：因果防倒置（自愈是恢复手段而非根因；变更按类型/环境/时序三维降权）、置信度评分（带置信度的判断而非单一答案，封顶约束）、根因独立性（不采信告警卡片结论，独立推导）、端到端双向实锤（客户端断崖与服务端同步异动相互印证才下结论）

• 方案跑通需要的基础设施：告警与事件平台、云端 Agent 执行环境、Skill 平台、MCP 与 CLI（优先 CLI 换稳定性）、统一可观测本体、鉴权、知识库、评测体系

4. 四类可路由 Skill 与从告警到报告的自动执行

• 服务端告警诊断：承载分层与护栏的完整方法论

• 客诉端到端定位：客户端与服务端双向实锤的闭环

• 端智能 / 移动端告警诊断：前后端对偶、按告警语义分级决定诊断深度、三角验证

• 单用户业务归因（以会员积分为例）：纯 CLI 零外部依赖、排除法归因

• 共性：取数与判断分离、端到端闭环、因果防倒置、客观反选不写死业务名、容错降级

• 运行链路：告警 / 事件触发 → Skill 路由 → 云端 Agent 自动执行 → 数分钟产出带置信度的根因报告（结论先行 + 证据 + 止血建议 + 错误传播链路图），推送应急群并通知 Skill 负责人形成反馈

5. 踩坑实录

• 减少外部依赖：外部工具超时、返回过大、间歇返空频发，去掉强依赖、优先走 CLI，换稳定性

• 动线接口间歇性返空：单次取空不等于无数据，需重试命中即停

• 不同本体时间戳格式不一致：毫秒 / 秒 / 字符串混用，导致取数时段错位

• 云端预加载耗时：每次诊断检查所有外部工具状态，拖慢整体时效

• 压测流量误判：未识别压测独立表族，把压测当暴涨，险些误建议熔断

• 自愈误作根因与采信卡片结论：因果倒置与来源污染的典型案例

6. 效果与评测

• 评价指标：召回率、准确率、端到端时效，对标既定目标、逐月跟踪

• 评测方案：AI 自动打标 + 人工抽检校准 + 三级下钻看板（整体 → 单 Skill → 单事件）+ 每周回测与数据回流

• 目前效果（定性）：召回接近全覆盖、准确率经数月迭代超过既定目标、产出稳定在分钟级

• 评测本身的局限：自动评测是方向标，人工复核是 ground truth

7. 能力边界与开放问题

• 能力边界：应急痛点中 Agent 只能解决一部分；影响面分母难以界定；端到端闭环依赖可观测数据齐全；本体存在覆盖缺口

• 护栏的代价：确定性边界在防误判的同时，也削弱了对未知新根因的发现能力

• 开放问题：这套流程是否最优？哪些环节其实不该交给 Agent？确定性护栏的边界应划在哪里？

• 演进方向：通用能力与业务专属能力的协同、护栏与发现力的平衡

实践痛点

• 确定性与灵活的取舍：代码取数可复现、可解释，但写死规则难覆盖长尾；大模型灵活却容易幻觉。分层让两边各取所长，代价是两套能力都要维护，且“边界划在哪”随业务持续校准

• 推理深度与分钟级时效的取舍：多轮推理更深入，但难满足分钟级产出。把并行取数交给代码、压缩大模型交互轮次，用部分推理深度换时效，是性能优化的核心动作，也是持续性取舍

• 护栏与发现力的取舍：确定性边界能有效防误判，却压制了对未知新根因的发现能力。护栏越紧越安全，也越难识别未见过的故障模式——这是“可信优先”路线的固有代价

演讲亮点

• 给大模型画确定性边界，而非追求更聪明的模型。业界 RCA 方案多为单一数据源（纯 trace 或纯日志）的 AI 总结，或检索增强后让模型直接读告警卡片下结论。本方案的区别在于：把取数与因果边界交给确定性代码——只产出事实不产出结论、自愈是恢复手段而非根因、变更按类型/环境/时序三维降权、不采信卡片结论，让大模型只做模式匹配与因果推理。这专治“把恢复动作当根因”这一 RCA 特有误判，也把“AI 可靠性护栏”从口号落到可执行范式

• 端到端双向实锤 + 客观反选，做到可跨业务迁移。业界客诉定位多停在前端或后端单侧，且依赖写死的应用/业务黑名单。本方案用客户端断崖 × 服务端同步异动相互印证、按断崖幅度与流量规模客观排序反选，全程不写死任何应用名或业务词，Skill 可跨业务复用——把专家经验沉淀为可路由、可度量的能力，而非一次性脚本

听众收益

• 一套可迁移的“Agent 做 RCA”架构范式：代码取数 + 大模型判断分层，配合因果校验、置信度、根因独立性等可信护栏，可对照自身业务落地

• 一份“跑通这套方案需要哪些基础设施”的清单：告警与事件平台、云端 Agent 执行环境、Skill 平台、MCP 与 CLI、统一可观测本体、鉴权、知识库、评测体系，便于自查短板与规划投入

• 一组真实踩坑与解法：减少外部依赖、动线接口间歇返空、跨本体时间戳不一致、压测流量误判、自愈误作根因——少走弯路