OpsPilot 的 CLI 已经从早期设计稿进入可用状态。最初讨论 CLI 时，重点是避免把命令层绑死在 Agent 内部实现上。那时系统还处在重构中，很多能力只能先设计成目标接口。现在核心运行时收口以后，CLI 的定位也清楚了：它不是一组临时脚本，而是 OpsPilot 面向操作者的控制面。

很多 AI Agent 项目第一版都能很快跑起来：写几个 prompt，接一个模型，注册几组工具，让模型根据上下文决定要不要调用工具。这个阶段最重要的是验证想法，代码里有一些 mock、硬编码和临时分支都可以接受。但 OpsPilot 的目标是运维辅助系统，不是一次性 demo。它要面对 Prometheus、Grafana、Kubernetes、数据库、Shell、通知渠道、MCP 服务和用户自

很多 AI Agent 项目第一版都能很快跑起来：写几个 prompt，接一个模型，注册几组工具，让模型根据上下文决定要不要调用工具。这个阶段最重要的是验证想法，代码里有一些 mock、硬编码和临时分支都可以接受。但 OpsPilot 的目标是运维辅助系统，不是一次性 demo。它要面对 Prometheus、Grafana、Kubernetes、数据库、Shell、通知渠道、MCP 服务和用户自

做 OpsPilot 的起点不是“给运维系统接一个大模型”，而是一个更具体的问题：线上告警来了以后，能不能把人工排查里最重复、最依赖上下文的部分收敛成一条可控的工作流？在真实运维场景里，告警本身往往只是一个入口。Prometheus 告诉你某个服务延迟升高，Grafana 告诉你某条规则触发了，日志系统里可能还有一堆相关报错，Kubernetes 里还要看 Deployment、Pod、Event

本次工作不是简单地“测试哪个模型会写 PromQL”，而是围绕 OpsPilot 的实际需求，构建了一套可复用的 PromQL 生成能力评测和选型流程。；；；。接下来，OpsPilot 可以在这个基础上继续推进 PromQL 生成服务的后端接入，把“自然语言问题 → PromQL 查询 → Prometheus 指标结果 → Agent 根因分析”这条链路真正打通。

本阶段我主要完成了 OpsPilot 故障靶场的搭建和理解工作。通过 Docker Compose，我把模拟业务服务、数据库、Prometheus 和 Alertmanager 组织成了一个可以统一启动、统一测试、方便后续扩展的本地实验环境。这项工作看起来偏基础，但它是整个智能运维 Agent 平台的前提。因为只有先有真实可观测的业务系统、可触发的故障场景、可查询的监控指标和可转发的告警数据，后续