DevOps团队花了多年时间把手工操作变成YAML文件。CI能在每次拉取请求时自动运行，部署可以通过提交触发，Kubernetes能调和期望状态，Terraform能在变更前规划基础设施。这些确实有用。但大量DevOps工作仍游离在流水线之外：阅读失败的CI日志、判断部署是否安全、关联追踪数据与告警和近期提交、决定是继续推进还是回滚、反复编写相同的运维手册步骤、为同一个故障上下文询问五个不同的工具。
AI自动化在这里变得有趣。不是作为DevOps工程师的魔法替代品，而是作为运维工作的更好界面。
最强的技术栈不是简单的"AI进CI/CD"，而是一个围绕三个核心构建的AI原生DevOps层：MCP服务器用于工具访问、技能用于可复用的专家工作流、插件用于公司特定的基础设施操作。如果构建得当，流水线会更快，因为无聊的胶水工作消失了。如果构建糟糕，你会得到一个拥有生产凭证且判断力模糊的AI机器人——那不是自动化，那是一份未来的事故报告。
MCP，即模型上下文协议，为AI应用提供连接外部系统的标准方式。官方文档描述了三种主要的服务端原语：工具（AI应用可调用的函数，如文件操作、API调用、数据库查询或部署动作）、资源（AI应用可读取的上下文，如文档、模式、日志、运维手册或服务元数据）、提示词（结构化工作流的可复用模板）。
这与DevOps完美映射。平台团队可以为GitHub或GitLab、CI/CD日志、Kubernetes、Terraform或OpenTofu、Argo CD、Prometheus与Grafana等可观测性后端、云成本数据、事件管理、内部服务目录分别暴露MCP服务器。AI代理不需要抓取随机仪表盘或从部分截图猜测，它可以直接向真实工具询问真实状态。
例如，当用户问"为什么生产部署失败了"，代理会执行：读取失败的GitHub Actions作业日志、检查拉取请求中的变更文件、查询Argo CD的同步状态、读取受影响命名空间的Kubernetes事件、从可观测性系统拉取近期错误追踪、总结可能的故障原因并建议最小安全修复。这不是取代DevOps工程师，而是消除不断切换标签页的税负。
MCP赋予代理访问能力，技能则告诉它如何工作。技能是特定任务的可复用程序。在DevOps中这很重要，因为生产工作有规则——你不希望代理每次被问问题时都发明一套部署策略。好的DevOps技能可能像这样：调试失败CI的技能，步骤包括获取失败作业、按阶段分组日志、识别常见错误模式、对照已知问题数据库检查、输出根因和修复建议。
热门跟贴