导读
过去一年，做出一个 Agent 其实不难：它能听懂问题、调几个工具、把一段任务跑完，有时候效果还挺惊艳。但当我们真的把 Agent 放进生产环境，关心的问题立刻就变了------它部署在哪、谁维护、配置怎么更新、出了问题怎么查、调一次会不会污染线上、调用生产工具安不安全、这次处理的经验能不能留下来给下一个 Agent 复用......
也就是说，难点已经不再是"能不能做出来"，而是"能不能稳定地托管起来、能不能安全地跑起来、能不能持续地变好"。QCon 上海2026 百度运维部出品的《百度SRE Agent 规模化落地实践------大模型 Agent 的安全托管与自主进化探索》分享详细介绍了AgentOps业务落地经验。
全文 5194 字，预计阅读时间 8 分钟
01 背景与规模化挑战
一个团队只有一个 Agent 的时候，很多问题靠人就能解决：找台机器起个实例、配个消息通道、准备几份 Skill，出问题登录机器看日志------不优雅，但能跑。
可一旦 Agent 多了、团队多了、场景复杂了，这套做法会迅速失效。我们把它归成六类问题：
- 接入与部署：每个团队都重复准备环境、配实例、接通道，大量时间花在"让 Agent 跑起来"，而不是让它的业务能力变好。
- 配置与版本：一个 Agent 不只有 Prompt，还有 Skill、工具、知识、运行时配置，这些没有统一的版本边界，调试里的改动很容易污染线上，出了问题也不知道是哪次变更。
- 运行与观测：一次执行包含意图理解、规划、Skill 选择、多次工具调用，如果只看最后一句回答，根本判断不出问题出在模型、知识、工具还是流程。
- 安全与权限：Agent 一旦能碰生产，就可能触发查询、变更、写操作，光靠 Prompt 告诉它"别干危险的事"远远不够，必须有平台级的权限、审批、限流、审计和回滚。
- 能力复用：公共工具、业务知识、历史经验难沉淀，场景建设高度依赖少数专家。
- 质量与演进：没有稳定的 Case、回放和评估体系，你根本没法判断新版本是不是真的变好了。
一句话收口------当 Agent 从"单点试用"走向"规模化生产"，接入、版本、观测、安全这些缺失会集中爆发，结果就是：企业用得起来，却管不住、不敢放大。AgentOps 要解决的，就不是某一个 Agent 的问题，而是这一组规模化问题。
02 AgentOps 整体架构
自下而上五层：
- 基础设施层，算力、存储、网络；
- 能力供给层，模型、工具、知识库、公共 Skill；
- 平台层，也就是整个 AgentOps 的核心；
- 网关层，统一入口、鉴权、路由、限流；
- 接入层，如流、数字员工、Web、消息机器人、OpenAPI 这些入口。
这里有一个我们特别想强调的设计思想：控制面和数据面分离。控制面负责"定规则、管治理"------配置、版本、发布、评估、知识、安全策略；数据面只专注"执行"------正式实例跑真实业务，调试沙盒跑草稿和回放，两者隔离。为什么要分开？因为解耦之后才好独立演进、好扩展，业务团队专注场景逻辑，外围工程能力交给平台。
而平台层里，我们用五大中心 统一把 Agent 管起来：Agent 管理、安全、变更、评估、知识 一起纳管，五层架构让 Agent 从"能跑"走向"敢用"。
AgentOps 的五大核心能力，是一条从"稳定运行"到"持续进化"的主线：Runtime 全生命周期托管 → 安全管控 → 场景仿真回放 → 知识沉淀与能力闭环 → Agent 自主进化。
03 Runtime 全生命周期托管
我们不希望每个团队都自己维护运行实例，而是平台统一管 Agent 从创建 → 配置 → 部署 → 运行 → 升级 → 监控 → 故障恢复 → 下线的全过程。这里的"托管"不只是起个进程，它至少包含四块：
- 全周期托管，一站式纳管；
- 统一资产与状态，配置、能力资产、运行实例、会话状态、版本发布、运行观测集中管理，实例迁移重建后上下文也不丢；
- 高可用保障，健康检查、状态持久化、实例恢复、依赖切换，做到故障自愈；
- 弹性与多租，按负载伸缩、多团队隔离、配额成本可控。
这块带来的直接变化是：新 Agent 的交付周期，从"周级"降到"天级"，而且稳定性有 SLA 兜底。说白了------Agent 的"可用"不是某个组件的状态，而是配置、能力、实例、依赖共同可用，这件事交给平台兜底。
04 安全管控
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，天然可审计、可回滚。
05 场景仿真回放
也就是为什么需要评估中心？ 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 不是一次性用例，而是能持续沉淀、安全可控的资产。
06 知识沉淀与能力闭环
我们的看法是：知识沉淀不是把一堆文档塞进知识库就完了，而是要让经验沉淀成合规可信、可复用的 Agent 能力。
- 多源沉淀：业务文档、运营经验、Case 记录、会话、用户反馈统一汇入。
- 合规校验把关： 源知识入库前，要过权限、脱敏、质量三道校验：权限上按来源和访问权限管控、敏感知识隔离；脱敏上入库前自动脱敏，账号、密钥、隐私信息都要处理掉；
- 质量上要求知识带来源、适用条件、版本和验证状态，还做去重、冲突检测和时效校验。机制上，是断言设计做结构化自动校验 + 人工评审把关主观质量与边界，双重把关、不达标不入库。过了这关，知识才会走"知识 → Skill 候选 → 规范审计与单测 → 场景回放 → 发布复用"变成能力；
- 线上用起来的反馈再回流知识库，用回放通过率、采纳率来衡量，持续提升。
为什么强调合规？因为会议纪要、群聊这类来源在大会上特别容易被追问数据权限和脱敏，我们宁可少而准，不要多而误导。
07 Agent 自主进化
这里的自主进化，不是让 Agent 自己改生产配置，也不是让模型无约束地扩权，而是一种受控的能力优化 。更新的是什么 ？我们只调 Prompt（主要是 md）、Skill、知识、安全策略这些能力组件，不动模型权重------成本低、可回退。
- 怎么评估 ？由评估中心基于灵活的 Case 集做回放，判定靠三样：用户断言、Case 通过率，再加一层专家人工评审去确认"实际效果到底符不符合预期"，三样都过才进发布。
- 怎么管控风险 ？安全沙盒隔离、支持可控放行、版本管控，加上热更新带来的秒级回滚。整体就是：优化而非重训、评估门禁把关、安全兜底、数据与知识回流形成飞轮。
再看一轮优化具体怎么跑， 触发有三种：
- 生产或评估里的 Bad Case、知识更新、以及人工按需触发。触发后由 Agent 优化智能体生成候选------问题分析、定向优化、产出候选；
- 候选进可靠评估，按断言 + Case 通过率回放，退化即拦；
- 然后是可回退闭环------不通过就回炉，通过就灰度，异常就秒级回滚。
这样每一次优化都是"可触发、可评估、可回滚"的闭环，而不是黑盒自动变更。
08 实践与沉淀 - 平台赋能
业务用 AgentOps，只需要关注自己的差异，运行、安全、变更、评估、知识都交给平台统一托管。现在的覆盖情况：覆盖10+百度核心业务线、20+ 接入的 SRE Agent、50+ 开箱即用的 Common SRE Skill、3 套 SRE Agent 建设模板，迭代周期从天级降到小时级。
对比一下过去和现在就很直观：
- 接入，从各自搭环境到选模板一键迁移；
- 稳定，从自己做 fallback 到默认高可用；
- 安全，从各自鉴权到标准鉴权透传；
- 工具，从重复开发到 50+ Skill 开箱即用；
- 迭代，从天级发版到小时级热更新；
- 进化，从经验散落到沙盒评估加知识沉淀、自主进化。
09 最佳实践 · Agentic 故障处置
用一个例子把前面的能力串起来------业务基于 AgentOps 的能力，快速组织出一个 SRE Agent，把某类故障的 MTTR 打了下来。场景是"某核心服务实例批量故障"。流程是这样的：
- 感知，根据异常对象、服务拓扑、时间范围，采集告警、日志、近期变更，Agent 自动拉群并汇总上下文；
- 召回 + 分析，召回 3 条相似历史案例和处置手册，生成"变更 / 机房 / 流量"多个猜想，并组织证据链；
- 验证收敛，逐一排除，证据指向一次配置变更导致连接池耗尽、请求超时；
- 判断授权，工程师确认根因、授权回滚，平台按审批执行、全链路留痕；
- 止损恢复，回滚后超时率回落、服务恢复；
- 复盘沉淀，自动生成复盘，新增 1 条 Case 和 1 个"实例健康巡检"的预案 Skill。
效果上，这是一个示例案例：同类 Case 的 MTTR 从 60 分钟降到 10 分钟 。我们特意强调"示例"------这是单次案例的口径，不是统计平均；正式对外的效率数字，都应该说明样本范围、统计口径和对照基线。这页真正想说的不是某个数字多亮眼，而是：业务能基于平台快速搭出一个 Agent 并见效，而且经验还能沉淀下来给下次复用。
10 经验沉淀 · 四大核心权衡
做 Agent 平台，真正难的不是某个单点能力，而是一组互相拉扯的权衡。我们的做法是"用机制让两端协同"，而不是二选一。四组权衡：
- 智能性 × 确定性------规划和执行解耦，高风险动作收口到工具和控制面，既留灵活、又守可预测。
- 安全 × 效率------按风险分级处置，自动放行 / 人工确认 / 强制审批 / 强制阻断，低风险快、高风险稳。
- 知识多 ≠ 高质量------知识必须带来源、适用条件、版本和验证状态，宁可少而准、不要多而误导。
- 生成 × 验证分离------引入独立验证机制，外部证据加多方评审，避免同一个模型自证正确。一句话：好的平台不是消灭矛盾，而是把每一组权衡都变成可控的工程选择。
11 总结与展望
回到最开始的问题：Agent 从单点试用走向规模化，缺的到底是什么？我们的答案是------缺的不是更多孤立的 Agent，而是一套能把 Agent 托管起来、安全地跑、验证效果、沉淀经验、持续改进 的平台。我们把它分成三个阶段：
- 阶段一 · 统一托管（已落地）：一套平台托管 Agent 全生命周期，解决"能跑、敢用"。
- 阶段二 · 持续进化（进行中）：知识闭环加场景回放驱动自主优化，用回放通过率、采纳率来衡量、持续提升。
- 阶段三 · 自治运维（未来）：让 Agent 辅助管 Agent，人只定目标和边界，运维走向自治。
最终我们想要的，是"让每一次执行都更安全，让每一份经验都可复用"------不是让 Agent 凭空变成专家，而是让专家的判断能被记录、复用、持续放大，最终形成团队级、平台级的专家能力。
更多智能运维产品，欢迎联系：sre.baidu.com/