AIOps实践中的隐秘挑战：如何有效管理MCP、Skill与Agent？
实践分享：借助Obsidian为AI注入业务知识，OpenClaw根因分析准确率从70%跃升至90%
此前系列文章探讨了OTel数据治理与Obsidian知识库如何助力OpenClaw将根因分析准确率提升至90%。然而，近期与多位基础设施领域同行交流时，我们发现一个普遍存在的瓶颈：
AI Agent已具备实际工作能力，但其依赖的MCP Server、Skill以及CLI工具分散各处，缺乏统一管控。今天接入一个Grafana MCP，明天整合一个SkyWalking MCP，后天某个Skill的提示词模板改动导致分析结果变化——谁修改的？何时修改的？影响了哪些业务场景？无人能清晰回答。
这一问题在团队仅有一两人探索AI时并不突出。但当AIOps在组织内规模化推广，十几位运维工程师共同使用同一套Agent进行巡检与故障排查时，MCP与Skill的管理便演变为一个典型的基础设施问题。
而基础设施问题，理应由基础架构团队负责解决。
在探讨管理方法前，需先厘清相关概念。许多人容易混淆这三者，但它们实际解决不同层面的问题。
MCP（模型上下文协议）解决的是“连接”问题——使AI Agent能够访问外部系统与数据。例如，Grafana MCP让Agent查询仪表盘与指标，SkyWalking MCP让Agent追踪链路，CMDB MCP让Agent获取资产信息。MCP本质上是Agent的“手”，使其能够触达外部环境。
Skill解决的是“方法论”问题——指导Agent在特定场景下如何操作。一个巡检Skill定义了巡检步骤、检查项与输出格式；一个根因分析Skill定义了从现象到根源的推理流程与模板。Skill本质上是Agent“脑中的标准作业程序”，是运维专家经验的结构化封装。
CLI工具解决的是“执行”问题——kubectl、helm、promtool等命令行工具，Agent通过Bash调用来执行具体操作。CLI是Agent的“脚”，使其能够实际操作基础设施。
三者关系如下：Agent通过MCP获取信息，依据Skill定义的流程进行推理，调用CLI执行操作。缺失任何一层，Agent都仅是一个聊天机器人。
团队曾有同事手动修改了Prometheus MCP的连接地址，指向测试环境Prometheus。修改后未及时通知他人。导致连续三天的巡检报告中，所有指标数据均来自测试环境——CPU利用率5%，QPS仅为个位数，一切显示“健康”。直到有人察觉异常：“线上明明出现告警，为何巡检报告显示一切正常？”
排查耗时两小时才发现是MCP配置被改动。整整两小时。
我们的根因分析Skill经历了多次迭代，从v1到v3输出格式不断变化。v1输出纯文本，v2改为结构化JSON，v3增加了置信度评分。某次有人将Skill回退至v1版本（因调试其他问题），未及时恢复。后续所有分析结果均变为纯文本格式，下游企业微信推送解析直接报错——消息无法发出，等同于巡检链路静默失效。
一位同事为Agent配置了kubectl的集群管理员权限，以“方便调试”。Agent在某次自动修复流程中，因边界条件判断错误，执行了kubectl delete pod --all -n production命令。所幸有人实时监控并手动拦截。但若无人值守呢？
这三个场景具备共同特征：问题并非出自Agent本身，而是Agent所依赖的基础设施（MCP、Skill、权限）未被视作基础设施进行管理。
明确这一点后，我们在内部DevOps平台（SxDevOps）构建了统一管理方案。核心思路简明：将MCP、Skill与CLI的管理从“每人自行配置”转变为“平台统一管控”。
第一步是将所有MCP Server配置收归平台层面管理。
上图展示了SxDevOps平台的智能体配置页面。顶部四个数字一目了然：2个模型供应商、10个已配置MCP、4个启用中Skill、59个今日会话。
下方表格列出了所有已接入的MCP Server：
其中包含几项关键设计决策：
MCP分两类管理。平台内置MCP（CMDB、事件中心、工单系统等）直接通过内部API接入，无需额外部署。外部系统MCP（Grafana、SkyWalking、NR监控等）通过HTTP或STDIO方式接入，需在平台配置连接参数。
连接参数统一管控。所有MCP的连接地址、认证信息均在平台层面配置，个人无法覆盖。前述“某人手动修改Prometheus地址指向测试环境”的失误，在此模式下不可能发生——你无权修改。
权限与角色绑定。并非每个人都能查看所有MCP。值班人员仅需查看10个只读MCP即可完成巡检与排障；仅SRE负责人可查看具备写权限的MCP（如执行重启、扩容操作）。
仅配置完善还不够，还需可视化Agent如何实际使用这些MCP与Skill。
此图展示了Agent处理某个问题时的完整运行过程——有人询问“数据平台生产环境月成本是多少”。右侧面板清晰呈现了Agent的每一步操作：
底部还可查看具体调用了哪个MCP工具：query_cmdb_items开始调用，返回2个结果分组，附带1个引用。
此运行时面板解决了“可审计”问题。每次Agent分析所使用的MCP、调用的工具、Skill模板如何整形，均有迹可循。出现问题无需猜测即可回溯。
配置管理到位后，Agent的分析质量也得到提升。
这是一次真实的巡检分析场景——Agent正在分析“order-center近期异常”。观察其输出：
结论：已定位order-center近期异常：发现4条相关告警，5条相关日志，1条异常链路，2条相关发布记录。异常点主要集中在订单服务调用库存校验链路，现象包括库存校验服务超时、重试风暴或发布后健康检查失败。
随后附上依据：
分析持续深入：Agent关联了发布记录，发现order-center最近有一次发布变更，将发布记录与inventory-service的异常时间线进行比对。最终给出建议排查路径与Trace ID，值班人员可直接跳转至具体链路验证。
注意此分析过程——Agent并非从单一MCP获取答案，而是跨越四五个MCP整合信息：告警数据来自事件中心MCP，日志来自可观测性MCP，发布记录来自任务中心MCP，资产信息来自CMDB MCP，链路来自SkyWalking MCP。
这正是统一管理MCP的价值所在——当所有数据源均以标准化方式接入平台，Agent才能实现跨源关联分析。若MCP各自为政，Agent的分析也只能是碎片化的。
总结我们在实践中沉淀的管理原则。
MCP Server的生命周期（部署、配置、升级、下线）应遵循与中间件相同的变更管理流程。新增MCP需有人评审连接配置与权限范围，修改需保留变更记录，下线需确认无Agent依赖。
听起来繁琐？其实并不比管理Redis集群复杂。问题在于许多团队未将MCP视为基础设施——它不过是一个JSON配置文件，谁都能改。但其影响范围不亚于任何中间件——一个MCP配置错误，所有依赖它的Agent分析结果都可能出错。
Skill本质上是“给Agent看的标准作业程序”。SOP改变，Agent行为即变。因此Skill变更需像代码一样进行版本管理：
我们的做法是将Skill文件存放于Git仓库，通过PR流程管理变更。每次PR要求附带测试用例——使用若干历史告警场景运行新版Skill，比对输出是否符合预期。
Agent可调用的工具（MCP + CLI）必须遵循最小权限原则：
权限分层后，类似“Agent误执行kubectl delete pod --all”的失误不可能发生——因为巡检Agent根本不具备kubectl的执行权限。
Agent本身也是基础设施的一部分，同样需要可观测性：
这些指标应与业务服务指标一同展示在Grafana看板上，并设置告警阈值。Agent的MCP调用失败率突增、Token消耗异常飙升、分析结果格式异常——这些都是需要关注的信号。
此事为何应由基础架构团队负责？因为它本质上是一个平台工程问题。
以往，基础架构团队提供的是Kubernetes集群、中间件、CI/CD流水线、监控告警——这些是“人使用的工具平台”。
如今，新增一层：MCP Server、Skill库、Agent运行时、权限管控——这些是“AI Agent使用的工具平台”。
两者的管理逻辑完全一致：标准化接入、统一配置、权限管控、可观测性、变更管理。仅服务对象从人变为AI Agent。
若团队已具备成熟的平台工程实践，实施Agent的基础设施管理几乎是水到渠成。你已会管理中间件，管理MCP Server便是同一方法论的延伸。你已会管理CI/CD流水线，管理Skill版本与灰度发布便是同一工具链的复用。
换个角度，若基础架构团队不承担此责，谁来承担？让每位运维工程师各自管理自己的MCP与Skill？那将重回前述的失误场景。
为有意开展类似工作的团队提供一条最小可行路径：
第一步：收口MCP配置。收集团队中所有手动配置的MCP Server信息，统一至一个配置中心（即使是一个Git仓库中的JSON文件亦可）。确保每个MCP连接信息仅存一份，修改走PR流程。此步无需任何平台建设，使用Git即可实现。
第二步：Skill入库管理。将团队沉淀的Skill文件（提示词模板、分析流程、输出格式）存入Git仓库，添加版本号与更新日志。新人入职无需口口相传，直接查阅仓库中的Skill即可了解团队的巡检与分析流程。
第三步：权限分级。根据场景定义三个权限级别（只读巡检、排障辅助、自动修复），为不同角色的Agent配置相应级别的MCP与CLI权限。
第四步：增加可观测性。在Agent运行链路上添加日志与指标，至少做到每次分析可回溯“调用了哪些工具、使用了哪些Skill、给出了什么结论”。
前两步一周内即可完成，后两步取决于团队规模与现有平台成熟度，需一至三个月不等。
AI Agent在运维场景的落地，正从“个人工具”阶段进入“团队基础设施”阶段。这一转变与当年Docker从开发者玩具演变为企业基础设施的路径如出一辙——一旦使用者增多，管理问题必将浮现。
MCP是Agent的数据通道，Skill是Agent的方法论，CLI是Agent的执行能力。管好这三层，Agent才能从“偶尔可靠偶尔失误的助手”蜕变为“团队可信赖的基础设施”。
此事无需重造轮子。你已有的平台工程能力——配置管理、权限管控、变更审计、可观测性——直接迁移应用即可。Agent的基础设施管理，正是平台工程的自然延伸。
扫码咨询优惠（粉丝优惠力度大）
↑↑↑点击关注，分享IT技术|职场晋升技巧|AI工具