最近和很多同行交流，发现大家做运维 Agent 的思路出奇一致：先调研成熟方案，再梳理高频场景，最后搞架构和代码实现。这个"三步走"没毛病，但很多团队一猛子扎进去，Agent 却频频翻车——不是 AI 不行，是运维地基没打牢。

但你可能会问：地基好不好，拿什么标准判断？网上那些"XX模型"、"XX框架"到底靠不靠谱？

本文不做概念包装。我们直接看真正跑通运维 Agent 的公司实际在做什么，然后把这套方法论拆成可执行的步骤。

---

为什么必须做前期评估？

传统运维往往是"人肉 + 脚本"，Agent 要接管这些工作，需要一套完整的闭环。这个闭环里任何一环卡住，Agent 就转不起来。

字节跳动在实践总结中把它抽象为三个核心组件（来源）：

组件	职能	卡住的后果
控制端（Brain）	LLM 推理、记忆、任务规划与协调	Agent 不知道该怎么想
感知端（Perception）	采集指标、告警、日志等环境信息	Agent 看不到真实世界
行动端（Action）	执行重启、迁移、配置变更等操作	Agent 只能想不能动

三层必须形成闭环——感知→决策→执行→反馈→再决策——缺一不可。

举个例子，你让 Agent 去重启一台故障服务器，结果发现：

• 监控数据不全，无法判断故障根因 → 感知端瘫痪
• 变更通道还是手工 SSH，没有 API 化 → 行动端残废
• 审批全靠微信群吼，操作记录无处可查 → 控制端不敢动
• 老大的排障经验全在脑子里，AI 学不到 → 闭环断了

所以，真正跑通的公司都在做同一件事：在写第一行 Agent 代码之前，先确保运维底座够硬。

---

业界框架怎么说的？选三个最有代表性的看

市面上确实有不少评估方法论，但名字五花八门。我们挑三个最有代表性的，不求全但求真：

1. MAPE-K 闭环（IBM，2000年代）

这是运维自动化的"元模型"。几乎所有现代运维 Agent 的闭环设计都能追溯到它：

Monitor（监控）→ Analyze（分析）→ Plan（规划）→ Execute（执行）+ Knowledge（知识库）

一篇 2025 年的论文（arxiv 2506.22185）正是基于 MAPE-K 来设计 AI Agent 驱动的微服务自治管理——这说明这个框架不仅没过时，反而成了 Agent 时代的架构基石。

2. TM Forum 自治网络分级 L0-L5

TM Forum 定义了六级自治模型（来源），类比自动驾驶：

级别	描述	运维 Agent 含义
L0	全人工操作	人肉敲命令
L1	基础自动化	脚本自动执行，但需人工触发
L2	中级自动化	Agent 辅助分析，人做决策
L3	高级自动化	Agent 独立处理已知场景，异常转人工
L4	预测性自愈	Agent 主动发现问题并自愈
L5	完全自治	零人工介入

截至 2025 年，行业整体处于 L2→L3 过渡期，头部公司（如百度）在部分场景已做到 L3-L4。你的第一个 Agent 大概率瞄准 L2（辅助决策），而不是一上来就搞 L5。

3. 微软 Agent Readiness Framework（Ignite 2025）

微软在 2025 Ignite 大会上发布的就绪度框架（来源），面向所有 AI Agent 场景，包括运维：

支柱	运维对应
Business & AI Strategy	Agent 要解决的运维痛点是什么？
Business Process Mapping	运维流程是否文档化、标准化？
Technology & Data	监控数据、API、工具链是否就绪？
Org Readiness & Culture	团队是否接受 Agent 辅助运维？
Security & Governance	权限、审批、审计是否到位？

有意思的是，微软调查发现：自评就绪度高的组织，Agent 规模化速度快 2.5 倍——这直接解释了为什么"先做评估"不是废话。

---

真实公司的实操模板：四个地基检查项

综合字节、百度、SafeOps 等团队的公开实践，真正跑通运维 Agent 的公司都在这四件事上做了功课。每项 1-5 分打分，1 分 = 完全没有，5 分 = 完全就绪。

第一项：可观测性（Observability）

对应 MAPE-K 的 Monitor 环节。Agent 能看清世界吗？

• 指标 (Metrics)、日志 (Logs)、调用链 (Traces) 采集完整且标准统一（Prometheus + ELK + OpenTelemetry 是标配）
• 所有被管对象（服务器、服务、中间件）已统一建模，拥有唯一 ID 和关键属性（CMDB）
• 告警已分类分级，包含严重级别、所属服务、影响范围等标准化标签

百度实践：他们的"四维质量保障"要求数据完整性、一致性、时效性、准确性全部达标，数据质量评分从 62 分提升到 89 分后才敢让 Agent 介入推理（来源）。

第二项：安全执行通道（Safe Execution）

对应 MAPE-K 的 Execute 环节。Agent 动手是否安全可控？

• 所有需要 Agent 调用的系统能力，已经标准化为 API（RESTful / gRPC / MCP 协议封装）
• Agent 执行操作时，强制通过 GitOps、CI/CD 流水线等可追溯的通道，杜绝直接 SSH
• 已为 Agent 建立独立最小权限服务账号，并按操作对象精细授权
• 变更、发布等高危操作有清晰的审批流程和 HITL（人机协同） 模式

SafeOps 实践：他们明确了一条铁律——LLM 介入执行之前，必须先有四个条件：可中断恢复、审批流、权限分层、命令白名单。少一个都不让 Agent 碰执行（来源）。

字节实践：三端架构中"行动端"只执行白名单内的操作，不是 Agent 想干什么就干什么。

第三项：操作边界与审批（Guardrails & HITL）

对应 MAPE-K 的 Plan 环节。Agent 的决策有红线吗？

• 已明确定义允许 Agent 自动执行的只读/低风险操作白名单
• 重大变更和发布有严格的时间窗口约束，Agent 不可在窗口外自动执行
• 高风险操作必须通过审批工单，获得人工确认（LangGraph 的 interrupt 机制可原生支持）

百度实践：他们的"安全执行层"采用"三权分立"——操作沙箱（所有变更先预演）+ 审批矩阵（按风险等级触发人工确认）+ 审计追踪（完整记录前后状态快照），跑出了自动化执行零事故率的成绩。

第四项：知识闭环（Knowledge Loop）

对应 MAPE-K 的 Knowledge 环节。Agent 能越用越聪明吗？

• 团队的故障排查、部署流程等经验，已经结构化沉淀在系统中（至少要有故障复盘文档模板）
• 知识库具备版本管理和动态更新机制，能被 Agent 实时检索调用（RAG + 向量数据库是成熟方案）
• 存在一个从"事件闭环"到"知识入库"的自动化流程（哪怕暂时半自动）

字节实践：他们的控制端同时维护短期记忆（上下文学习）和长期记忆（外部向量存储），让 Agent 能"记住"历史案例并复用。

---

评估之后：从体检报告到行动路线图

做完这四项评估，拿到了一份"体检报告"。下一步不是立刻写 Agent 代码，而是把静态报告变成动态行动计划。

第一步：锁定核心短板

打分结果通常呈现"木桶效应"——最拖后腿的那一项，就是最大风险点：

短板	如果得分很低…	Agent 会怎样
可观测性	监控数据不全或标签混乱	Agent 看不清，瞎诊断
安全执行通道	没有 API 化，还在手工 SSH	Agent 动不了，或者乱动
操作边界	没有白名单和审批流	Agent 可能闯大祸
知识闭环	经验全在人脑子里	Agent 永远在"重复造轮子"

优先级判断很简单：如果连服务当前状态都拿不准（可观测性差），那其他事都免谈——先把监控补上。

第二步：制定就绪度提升计划

针对每个短板，有具体的工程手段：

短板	提升措施	典型工程手段
可观测性	统一监控与日志采集规范，补齐缺失指标并打标	Prometheus + ELK + OpenTelemetry；CMDB 建模；告警命名规范
安全执行通道	手工操作 API 化，打通 CI/CD 或 GitOps	RESTful/gRPC 封装；Ansible Tower / GitLab CI；MCP 协议
操作边界	固化"口头约定"为可执行策略	SLO 文件；操作风险分级矩阵；OPA/Kyverno 策略引擎
知识闭环	运维经验结构化、可检索、自动更新	向量数据库 + RAG；故障复盘模板；自动化知识入库流水线

不要追求完美——补到刚好够你的第一个 Agent 安全跑起来就行。比如第一个 Agent 只做"只读查询"，那执行通道和操作边界的改造可以先放一放。

第三步：选出最值得动手的 MVP 场景

地基补到一定程度后，用场景优先级矩阵选出第一个 Agent 要做什么。核心维度：

• 操作频率：高频场景 ROI 更高
• 操作风险：低风险场景先试水
• 技术难度：简单场景快速验证
• 实现成本：低成本场景试错空间大

一个聪明的选择：高频率 + 低风险。比如：

场景类型	示例	为什么适合做 MVP
只读查询	自动查询日志、生成巡检报告、监控告警分析	不需要写操作，没有安全风险
低风险操作	清理日志、重启无状态非核心服务、自动扩缩容	影响面小，失败了可快速回滚

这类场景对安全执行通道和操作边界的要求相对低，能在安全前提下快速验证 Agent 的核心能力。

第四步：设计 MVA（最小可行架构）

确定 MVP 场景后，设计最小可行架构。以"自动诊断并重启故障服务"为例，MVA 包含：

关键设计原则：

• LLM 负责分析和建议，不直接执行危险操作
• HITL 审批作为运行时强制机制（LangGraph interrupt、OpenAI Agents SDK needs_approval）
• 执行通道与 AI 分析层解耦——AI 只出方案，确定性 pipeline 负责执行
• 每一步都留审计日志

第五步：灰度验证与迭代

有了 MVA 蓝图，进入工程实现：

1. 原型开发：在实验环境用最少数据和工具集，快速走通闭环
2. 灰度发布：先让 Agent 接管一个非关键、影响面极小的服务
3. 收集反馈：重点看误报率、审批采纳率、MTTR 改善等
4. 迭代优化：调整提示词、工具集、知识库，甚至改动执行通道细节
5. 扩展场景：MVP 跑稳后，按优先级逐步推广到更多场景

这个演进过程天然沿着 TM Forum L2→L3→L4 的路径走，每一步都有明确的能力里程碑。

---

总结：一条完整的行动路线图

你可能会问：补短板要补到什么程度才算够？

刚好够你的第一个 Agent 安全、稳定地跑起来就行。 运维 Agent 的建设是螺旋上升的过程，不是一次性交钥匙工程。

---

参考资料

本文的方法论和案例基于以下公开来源（均有据可查，非 AI 虚构）：

• MAPE-K 模型：IBM Autonomic Computing 参考模型；arxiv 2506.22185 — Agentic AI + MAPE-K 微服务自治管理
• TM Forum 自治分级：Autonomous Operations Landscape — L0-L5 六级模型与认知能力评估
• 微软 Agent Readiness Framework：Kurt Shintaku’s Blog — 五大就绪度支柱
• 字节跳动运维 Agent 实践：CSDN 转载 — 三端协同架构
• 百度 Agentic AIOps 实践：百度开发者 — 四层架构 + 三大核心能力
• SafeOps 运维 Agent 学习笔记：garlicspace — StackStorm/Rundeck/LangGraph 等方案横向对比
• 微软 AIOpsLab：Microsoft Research — 运维 Agent 标准化评估框架

---

写在最后：别急着写代码。先用这四项检查给团队的运维地基做次全面体检。当你的底座足够扎实时，后续的 MVP 验证、场景扩展和成熟度跃升，都会是水到渠成的事。智能运维不是空中楼阁——它长在每一块深埋地下的基石之上。