QCon上海2026：百度 SRE Agent 规模化落地实践解读

过去一年，做出一个 Agent 其实不难：它能听懂问题、调几个工具、把一段任务跑完，有时候效果还挺惊艳。但当我们真的把 Agent 放进生产环境，关心的问题立刻就变了——它部署在哪、谁维护、配置怎么更新、出了问题怎么查、调一次会不会污染线上、调用生产工具安不安全、这次处理的经验能不能留下来给下一个 Agent 复用……

也就是说，难点已经不再是"能不能做出来"，而是" 能不能稳定地托管起来、能不能安全地跑起来、能不能持续地变好 "。QCon 上海2026 百度运维部出品的《百度SRE Agent 规模化落地实践——大模型 Agent 的安全托管与自主进化探索》分享详细介绍了AgentOps业务落地经验。

全文 5194 字，预计阅读时间 8 分钟

GEEK TALK

背景与规模化挑战

一个团队只有一个 Agent 的时候，很多问题靠人就能解决：找台机器起个实例、配个消息通道、准备几份 Skill，出问题登录机器看日志——不优雅，但能跑。

可一旦 Agent 多了、团队多了、场景复杂了，这套做法会迅速失效。我们把它归成六类问题：

接入与部署 ：每个团队都重复准备环境、配实例、接通道，大量时间花在"让 Agent 跑起来"，而不是让它的业务能力变好。
配置与版本 ：一个 Agent 不只有 Prompt，还有 Skill、工具、知识、运行时配置，这些没有统一的版本边界，调试里的改动很容易污染线上，出了问题也不知道是哪次变更。
运行与观测 ：一次执行包含意图理解、规划、Skill 选择、多次工具调用，如果只看最后一句回答，根本判断不出问题出在模型、知识、工具还是流程。
安全与权限 ：Agent 一旦能碰生产，就可能触发查询、变更、写操作，光靠 Prompt 告诉它"别干危险的事"远远不够，必须有平台级的权限、审批、限流、审计和回滚。
能力复用 ：公共工具、业务知识、历史经验难沉淀，场景建设高度依赖少数专家。
质量与演进 ：没有稳定的 Case、回放和评估体系，你根本没法判断新版本是不是真的变好了。

一句话收口——当 Agent 从"单点试用"走向"规模化生产"，接入、版本、观测、安全这些缺失会集中爆发，结果就是： 企业用得起来，却管不住、不敢放大 。AgentOps 要解决的，就不是某一个 Agent 的问题，而是这一组规模化问题。

GEEK TALK

AgentOps 整体架构

自下而上五层：

基础设施层 ，算力、存储、网络；
能力供给层 ，模型、工具、知识库、公共 Skill；
平台层 ，也就是整个 AgentOps 的核心；
网关层 ，统一入口、鉴权、路由、限流；
接入层 ，如流、数字员工、Web、消息机器人、OpenAPI 这些入口。

这里有一个我们特别想强调的设计思想： 控制面和数据面分离 。控制面负责"定规则、管治理"——配置、版本、发布、评估、知识、安全策略；数据面只专注"执行"——正式实例跑真实业务，调试沙盒跑草稿和回放，两者隔离。为什么要分开？因为解耦之后才好独立演进、好扩展，业务团队专注场景逻辑，外围工程能力交给平台。

而平台层里，我们用 五大中心 统一把 Agent 管起来： Agent 管理、安全、变更、评估、知识 一起纳管，五层架构让 Agent 从"能跑"走向"敢用"。

AgentOps 的五大核心能力，是一条从"稳定运行"到"持续进化"的主线： Runtime 全生命周期托管 → 安全管控 → 场景仿真回放 → 知识沉淀与能力闭环 → Agent 自主进化 。

GEEK TALK

Runtime 全生命周期托管

我们不希望每个团队都自己维护运行实例，而是平台统一管 Agent 从 创建 → 配置 → 部署 → 运行 → 升级 → 监控 → 故障恢复 → 下线 的全过程。这里的"托管"不只是起个进程，它至少包含四块：

全周期托管 ，一站式纳管；
统一资产与状态 ，配置、能力资产、运行实例、会话状态、版本发布、运行观测集中管理，实例迁移重建后上下文也不丢；
高可用保障 ，健康检查、状态持久化、实例恢复、依赖切换，做到故障自愈；
弹性与多租 ，按负载伸缩、多团队隔离、配额成本可控。

这块带来的直接变化是：新 Agent 的交付周期，从"周级"降到"天级"，而且稳定性有 SLA 兜底。说白了——Agent 的"可用"不是某个组件的状态，而是配置、能力、实例、依赖共同可用，这件事交给平台兜底。

GEEK TALK

安全管控

Agent 进了生产，安全是绕不开的底座。我们有一个基本态度： 安全责任不交给 Prompt，也不假设模型永远正确理解风险 。

先看风险到底长什么样？ Agent 能自主调工具、执行写操作，用户、模型、系统、并发四个层面都可能让一次写操作失控。举两个真实的例子。

案例一：Agent 迭代后跟数据库交互，数据字典对不上、insert 一直失败，它多次试错无果，居然直接把库 DROP 了、重建 table——结果数据被删、业务中断。本质是"为达成目标自主升级到高危写操作，全程没人把关"。
案例二：指令只是把配置里 A 字段从 v1.32.0.1 改成 v1.33.0.1，结果 B 字段恰好也是这个值，Agent 顺手把 B 也改了——本质是"超出指令作用域、关联误伤、没有精确的范围控制"。

那我们怎么管？ 不是单点拦一下，而是从构建时到运行时的 四道防线，L1 到 L4 逐层覆盖 。

L1 构建时：事前约束，声明允许/禁止的动作与边界；
L2 意图审计：第三方专家 Agent 比对"需求 ↔ 产出"，产出评审意见；
L3 本地 Hook：审计 Agent 产出的 runbook 具体动作和对象；
L4 网关代理：代理所有 API/HTTP 调用，统一管控并审计接口、参数、QPS。

一句话—— 安全不是最后一道闸，而是从构建到执行的全程护栏 。

最后两件压舱石：身份与可回滚。

身份上，我们落地了 委托令牌 ：令牌里承载"具体用户 + 发起 Agent"双身份，并且做了加密防盗用。关键是——我们用的是 委托，不是冒充 ，完整保留"谁代表谁"，这样调用链能定责、越权能拦。
审计上，做 5W 审计 ：谁、哪个 Agent、何时、对哪些对象、做了什么，日志落本地并持久化。回滚上，每次提交都可回滚，能撤销最近一次写操作。而且所有托管的 Skill 都过 AI Review，天然可审计、可回滚。

GEEK TALK

场景仿真回放

也就是为什么需要评估中心？ Agent / Skill 的迭代有几个老大难：

变更影响难验证，改一处可能牵一发而动全身，人工回归范围有限；
场景难复现，切流、回滚这类高危写操作根本不能在线上跑；
验证环境不一致，不用同一个 Agent 验证，memory、session 的状态都会干扰结果；
问题难定位，只看最终结果看不出偏差在哪；再加上结果难验证、效果难评估、人工建 Case 成本高。

这些叠一起的后果就是——每次更新都得人工逐条 review，Agent / Skill 根本快不起来。

我们的解法是一个真实场景驱动的评估闭环。

从线上告警和多轮会话里 自动记录 Trace ，真实映射运行时的行为链路；
再从里面选高价值的 Trace，沉淀成含"输入 / 上下文 / 工具快照 / 期望结果 / 期望过程"五要素的标准 Case ；
验证新版本时，把 Agent 部署到 回放沙盒 ，对当前版本执行 Case 回放， 不碰生产 就能验证；
回放过程里实时看 Trace ，精确定位到是哪一步、哪个工具、哪个参数出的问题；
最后输出 评估报告 ，给总体得分和"期望 vs 实际"的过程对齐，支撑"继续迭代还是达标发布"的决策。

这里特别说一句外部依赖怎么处理：靠 工具快照回放 ——API Server 拦截 + Replay Runtime 还原返回值，不依赖真实外部系统，所以可复现。

Case 怎么生成和治理？ Case 可以从线上 Trace、人工创建、已有 Case 复制、标准文件导入等多来源汇聚，经过人工审核、沙盒验证后才入集，保证质量可控、来源可信；平台沉淀出一套 通用 Trace 与 Case 集 作底座，业务还能按需拼接自己的 Case 来回放。这里有个前提要强调： 评估能力是建在安全中心之上的——拦得住，才敢跑 。Case 不是一次性用例，而是能持续沉淀、安全可控的资产。

GEEK TALK

知识沉淀与能力闭环

我们的看法是：知识沉淀不是把一堆文档塞进知识库就完了，而是要让经验沉淀成 合规可信、可复用 的 Agent 能力。

多源沉淀：业务文档、运营经验、Case 记录、会话、用户反馈统一汇入。
合规校验把关： 源知识入库前，要过 权限、脱敏、质量 三道校验：权限上按来源和访问权限管控、敏感知识隔离；脱敏上入库前自动脱敏，账号、密钥、隐私信息都要处理掉；
质量上要求知识带来源、适用条件、版本和验证状态，还做去重、冲突检测和时效校验。机制上，是 断言设计做结构化自动校验 + 人工评审把关主观质量与边界 ，双重把关、不达标不入库。过了这关，知识才会走"知识 → Skill 候选 → 规范审计与单测 → 场景回放 → 发布复用"变成能力；
线上用起来的反馈再回流知识库，用回放通过率、采纳率来衡量，持续提升。

为什么强调合规？因为会议纪要、群聊这类来源在大会上特别容易被追问数据权限和脱敏，我们宁可少而准，不要多而误导。

GEEK TALK

Agent 自主进化

这里的自主进化，不是让 Agent 自己改生产配置，也不是让模型无约束地扩权，而是一种 受控的能力优化 。

更新的是什么 ？我们只调 Prompt（主要是 md）、Skill、知识、安全策略这些能力组件， 不动模型权重 ——成本低、可回退。
怎么评估 ？由评估中心基于灵活的 Case 集做回放，判定靠三样：用户断言、Case 通过率，再加一层 专家人工评审 去确认"实际效果到底符不符合预期"，三样都过才进发布。
怎么管控风险 ？安全沙盒隔离、支持可控放行、版本管控，加上热更新带来的 秒级回滚 。整体就是：优化而非重训、评估门禁把关、安全兜底、数据与知识回流形成飞轮。

再看一轮优化具体怎么跑， 触发有三种：

生产或评估里的 Bad Case、知识更新、以及人工按需触发。触发后由 Agent 优化智能体生成候选——问题分析、定向优化、产出候选；
候选进可靠评估，按断言 + Case 通过率回放， 退化即拦 ；
然后是可回退闭环——不通过就回炉，通过就灰度，异常就秒级回滚。

这样每一次优化都是"可触发、可评估、可回滚"的闭环，而不是黑盒自动变更。

GEEK TALK

实践与沉淀 - 平台赋能

业务用 AgentOps，只需要关注自己的差异，运行、安全、变更、评估、知识都交给平台统一托管。现在的覆盖情况：覆盖10+百度核心业务线、 20+ 接入的 SRE Agent、 50+ 开箱即用的 Common SRE Skill、 3 套 SRE Agent 建设模板，迭代周期从 天级降到小时级 。

对比一下过去和现在就很直观：

接入，从各自搭环境到选模板一键迁移；
稳定，从自己做 fallback 到默认高可用；
安全，从各自鉴权到标准鉴权透传；
工具，从重复开发到 50+ Skill 开箱即用；
迭代，从天级发版到小时级热更新；
进化，从经验散落到沙盒评估加知识沉淀、自主进化。

GEEK TALK

最佳实践 · Agentic 故障处置

用一个例子把前面的能力串起来—— 业务基于 AgentOps 的能力，快速组织出一个 SRE Agent，把某类故障的 MTTR 打了下来 。场景是"某核心服务实例批量故障"。流程是这样的：

感知，根据异常对象、服务拓扑、时间范围，采集告警、日志、近期变更，Agent 自动拉群并汇总上下文；
召回 + 分析 ，召回 3 条相似历史案例和处置手册，生成"变更 / 机房 / 流量"多个猜想，并组织证据链；
验证收敛 ，逐一排除，证据指向一次配置变更导致连接池耗尽、请求超时；
判断授权 ，工程师确认根因、授权回滚，平台按审批执行、全链路留痕；
止损恢复 ，回滚后超时率回落、服务恢复；
复盘沉淀 ，自动生成复盘，新增 1 条 Case 和 1 个"实例健康巡检"的预案 Skill。

效果上， 这是一个示例案例：同类 Case 的 MTTR 从 60 分钟降到 10 分钟 。我们特意强调"示例"——这是单次案例的口径，不是统计平均；正式对外的效率数字，都应该说明样本范围、统计口径和对照基线。这页真正想说的不是某个数字多亮眼，而是：业务能基于平台 快速搭出一个 Agent 并见效 ，而且经验还能沉淀下来给下次复用。

GEEK TALK

经验沉淀 · 四大核心权衡

做 Agent 平台，真正难的不是某个单点能力，而是一组互相拉扯的权衡。我们的做法是"用机制让两端协同"，而不是二选一。四组权衡：

智能性 × 确定性 ——规划和执行解耦，高风险动作收口到工具和控制面，既留灵活、又守可预测。
安全 × 效率 ——按风险分级处置，自动放行 / 人工确认 / 强制审批 / 强制阻断，低风险快、高风险稳。
知识多 ≠ 高质量 ——知识必须带来源、适用条件、版本和验证状态，宁可少而准、不要多而误导。
生成 × 验证分离 ——引入独立验证机制，外部证据加多方评审，避免同一个模型自证正确。一句话：好的平台不是消灭矛盾，而是把每一组权衡都变成可控的工程选择。

GEEK TALK

总结与展望