- 博客(13)
- 收藏
- 关注
RSS订阅原创 OpsPilot Web 前后端设计：从 API 契约到用户界面
这次 Web 前后端对接，我对前端工程有几个更明确的认识。第一，API 契约文档是前后端的真话。不是可选的装饰品，是代码的一部分。没有它，前后端会各说各的话。第二，前后端分离的目的是让协议稳定，不是为了物理隔离。一旦 API 契约清晰，两端就可以并行开发，互不阻塞。第三，优先选择简单可行的方案。轮询比 WebSocket 简单，过渡的本地操作员标识比等完整用户系统简单。简单方案容易测试、容易调试，关键功能跑通后再优化。第四，前端的防御性设计很重要。
2026-06-22 14:57:27
170
原创 写完 OpsPilot CLI 后，我对命令行工具的几个判断
这次写完以后，我对运维类 CLI 有几个更明确的判断。第一，CLI 应该是产品操作模型，不是内部 API 目录。第二，运行时要先收口。没有稳定运行时，CLI 会变成散落的胶水代码。第三，远程控制能力要尽早设计。只会本地读内存的 CLI，很难进入真实使用场景。第四，安全和脱敏不是后期 polish，它们会决定接口边界。第五，表格和 JSON 都要有。人和脚本都是 CLI 的用户。
2026-06-22 14:33:46
372
原创 OpsPilot CLI 开发复盘：从命令包装到运行时控制面
OpsPilot 的 CLI 已经从早期设计稿进入可用状态。最初讨论 CLI 时，重点是避免把命令层绑死在 Agent 内部实现上。那时系统还处在重构中，很多能力只能先设计成目标接口。现在核心运行时收口以后，CLI 的定位也清楚了：它不是一组临时脚本，而是 OpsPilot 面向操作者的控制面。
2026-06-21 18:46:50
319
原创 OpsPilot 重构完成：从分散模块到可嵌入运行时
这轮重构完成后，OpsPilot 的核心形态已经从“多个能力模块的集合”收口成了一个可以被宿主嵌入的运行时。之前的项目状态更像一条正在铺设中的链路：配置、接入、调度、会话、Agent、工具、通知、存储都已经有各自的雏形，但这些模块之间还没有一个稳定的组合根。CLI、HTTP 服务、测试和后续前端都需要知道太多内部细节，尤其是 Agent 运行时还残留着旧框架的影子。现在这条链路的入口被收到了。
2026-06-21 18:45:28
157
原创 读一个重构中的 Agent 项目：我昨天如何拆解 OpsPilot
昨天主要做了一件事：把 OpsPilot 这个还在重构中的 Agent 项目从“看起来有很多模块”拆成一条能讲清楚的技术链路。这个过程和读一个已经稳定的项目不太一样。稳定项目通常可以顺着入口一路往下看，启动、配置、路由、业务逻辑、存储基本都能闭合。但 OpsPilot 当前处在中间态：有些模块已经重构到新接口，有些代码还停留在旧实现，有些文档描述的是目标状态而不是当前状态。
2026-06-20 11:31:13
180
原创 OpsPilot 技术状态复盘：从核心链路到 CLI 操作面
OpsPilot 当前处在核心架构重构阶段。项目已经拆出了配置、接入、调度、会话、Agent、工具、通知、存储等模块，但应用层装配和 Agent 运行时还没有完全收口。这个目标决定了 OpsPilot 不是普通的 LLM 工具调用 demo，而是一个需要明确运行状态、安全边界和操作界面的系统。
2026-06-20 11:30:07
345
原创 cli前端实现计划
有些能力当前还没有完成，CLI 也不能假装它们已经稳定。例如持久化层现在有 ORM 模型和 Repository，但运行时还没有完整接入。CLI 如果要做，最终应该基于 Repository 查询数据库。但第一版可以先把命令和返回结构定义好，内部实现可以暂时标记为 “not implemented” 或只支持内存态。审批也是类似。当前 LangGraph 版本里的审批依赖，但自研 runner 以后很可能会改成自己的待审批队列。
2026-06-14 21:45:26
211
原创 把 AI Agent 做成可扩展系统：OpsPilot 的配置化、插件化与安全重构
很多 AI Agent 项目第一版都能很快跑起来：写几个 prompt，接一个模型，注册几组工具，让模型根据上下文决定要不要调用工具。这个阶段最重要的是验证想法，代码里有一些 mock、硬编码和临时分支都可以接受。但 OpsPilot 的目标是运维辅助系统，不是一次性 demo。它要面对 Prometheus、Grafana、Kubernetes、数据库、Shell、通知渠道、MCP 服务和用户自定义工具。如果工具来源不统一，配置模型不稳定，安全边界不清楚，项目很快会从“能跑”变成“很难改”。
2026-06-06 21:53:12
349
原创 从告警到处置：我们如何设计一个 AI 运维助手 OpsPilot
做 OpsPilot 的起点不是“给运维系统接一个大模型”，而是一个更具体的问题：线上告警来了以后，能不能把人工排查里最重复、最依赖上下文的部分收敛成一条可控的工作流？在真实运维场景里，告警本身往往只是一个入口。Prometheus 告诉你某个服务延迟升高，Grafana 告诉你某条规则触发了，日志系统里可能还有一堆相关报错，Kubernetes 里还要看 Deployment、Pod、Events。处理人需要判断这是不是重复告警、是否影响生产、应该先看指标还是日志、能不能自动重启、是否需要人工审批。
2026-06-06 21:48:47
187
原创 测评大模型的PromQL能力
本次工作不是简单地“测试哪个模型会写 PromQL”，而是围绕 OpsPilot 的实际需求，构建了一套可复用的 PromQL 生成能力评测和选型流程。；；；。接下来，OpsPilot 可以在这个基础上继续推进 PromQL 生成服务的后端接入，把“自然语言问题 → PromQL 查询 → Prometheus 指标结果 → Agent 根因分析”这条链路真正打通。
2026-05-07 21:29:26
368
原创 OpsPilot 项目进展：基于 Docker Compose 搭建智能运维故障靶场
本阶段我主要完成了 OpsPilot 故障靶场的搭建和理解工作。通过 Docker Compose，我把模拟业务服务、数据库、Prometheus 和 Alertmanager 组织成了一个可以统一启动、统一测试、方便后续扩展的本地实验环境。这项工作看起来偏基础，但它是整个智能运维 Agent 平台的前提。因为只有先有真实可观测的业务系统、可触发的故障场景、可查询的监控指标和可转发的告警数据，后续的大模型分析、RAG 检索、根因判断、自动化处置才有实际意义。
2026-05-04 10:54:02
345
原创 想做OpsPilot但是不懂运维？天下文章一大抄。
检测/触发 → 规范化 → 去重/聚合 → Incident 声明 → 上下文收集 → 调查与假设 → 处置/缓解 → 监控恢复 → 解决 → 复盘与行动项。Google 把它概括为 prepare/respond/learn，Grafana IRM 把它概括为 detect/respond/learn，incident.io 和 FireHydrant 则把它具体化成 triage/active/post-incident 与一系列 milestones。Google SRE。
2026-04-16 14:28:28
404
原创 创新实训（1）
本文探讨了LangGraph框架在智能运维Agent系统中的应用。作者通过阅读官方文档，理解了LangGraph作为底层编排框架的核心价值：提供状态管理、流程编排和人工介入能力。文章分析了State在Agent系统中的核心地位，将其比喻为"共享白板"，记录流程中各节点的执行状态。作者结合OpsPilot项目，展示了如何将运维流程（告警分析、根因定位、处置执行等）映射到LangGraph的节点和状态流转中，特别强调了其在长流程、人工确认和故障恢复场景的优势。
2026-03-31 15:53:38
521
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人