从0到上线:一个由Claude+Codex开发完成的AIOps自动化智能运维平台

从0到上线:一个由Claude+Codex开发完成的AIOps自动化智能运维平台

Deng YongJie's blog 23 2026-06-27

从 0 到上线:一个由 Claude+Codex 开发完成的 AIOps 智能运维平台

AIOps 平台最难的地方,不是把页面做出来,也不是把接口跑通,而是把“运维入口、边缘资源、权限审计、巡检产物、发布升级”放进同一个可长期维护的体系里。

这个项目已经完成开发并上线。整个代码实现由 Claude+Codex 驱动完成,人工没有逐行手写业务代码,但这不代表没有门槛。真正的门槛在于:能不能把运维经验、架构判断、基础脚手架、提示词约束、测试验收和生产发布规则讲清楚。

本文不展开源码,而是从产品功能、架构分层和实现方法看这个平台是怎么落地的。它更像一篇“AI 驱动生产开发复盘”,不是一篇“小白复制提示词就能做平台”的教程。

image-20260702192223086
image-20260702192453140
image-20260702191939082
image-20260702192134220

1. 项目规模:不是 Demo 工程

这不是一个只有几个页面、几个接口的演示项目。按非空行粗略统计,在排除 node_modulestargetdist、缓存目录和博客图片资产后,项目仍约有 2,957 个文件、30.7 万行工程内容;如果按仓库文件清单看,全仓约 3,100+ 个文件。

9750927b1d71d20b9df38286c34fd818

这个数字不等同于“全部都是人工手写业务代码”,前端目录也包含部分静态运行时资产。但从模块数量、联动范围和发布物数量看,它已经是一个完整的生产级平台工程。

维度 规模与说明
后端工程 约 2,067 个文件,Java 非空行约 10.6 万行,包含 42 个 Maven 模块/聚合、69 个 Controller、112 个 Service 实现、143 个 DAO 接口
前端控制台 约 702 个文件,TS/TSX 非空行约 7 万行,src/pages 下约 258 个页面文件,覆盖仪表盘、告警、CI/CD、资产、边缘运维和系统设置
边缘 Agent 约 153 个文件,Python 非空行约 3.5 万行,src 下约 82 个 Python 文件,负责 PVE、Ceph、网络设备、裸金属和巡检执行
数据与交付 SQL 非空行约 5,600 行,YAML 非空行约 5,300 行,Markdown 文档约 2.3 万行,覆盖菜单权限、升级、部署、验收和设计记录

这意味着 Claude+Codex 不是在补一个页面,而是在同时维护前端体验、后端编排、权限模型、SQL 升级、边缘执行、审计闭环、发布文档和脱敏资料。

也正因为项目体量足够大,AI 开发的价值才体现出来:它能在清晰约束下快速推进多模块联动。但人的架构判断、领域知识和验收能力也必须同步放大,否则代码生成速度越快,失控范围也越大。

2. 先定义平台边界

这个 AIOps 平台不是单点脚本工具,而是面向多机房、多资源域、多角色的运维控制台。

它覆盖的能力包括告警、CI/CD、数据库、通知、资产、边缘运维、系统管理、用户设置等模块。其中最有生产价值的部分,是把边缘机房里的 PVE、Ceph、网络设备、裸金属、公网 IP 和巡检任务统一纳入中心平台。

平台的核心定位可以概括成一句话:

中心平台负责状态、权限、审计和编排;边缘 Agent 负责受控执行。

这个边界非常重要。只有中心平台掌握权威数据,后续的审计、权限、回滚、升级和多租户治理才不会散掉。

3. 总体架构

平台采用“中心编排 + 无状态边缘执行”的结构。前端控制台访问后端 API;后端保存机房、Agent、凭据、任务、产物和审计;edge-agent 部署在边缘机房内,负责访问本地 PVE、Ceph、网络设备和裸金属资源。

aiops-platform-production-architecture
aiops-platform-architecture

这张图里最关键的是 4 条线。

第一条是用户入口线。运维人员通过控制台发起操作,外部系统可以通过开放 API 对接告警、资产或自动化流程。

第二条是平台运行时线。Backend App 承载业务编排,Control Service 承载租户和权限能力,后端内部模块按 system、tenant、ops、asset、project、notice、plugins 等能力域组织,但它们不是独立部署服务。

第三条是数据与异步线。MySQL 保存业务数据、权限和审计;Redis 保存会话和权限缓存;MinIO 保存巡检产物、导入导出文件;RocketMQ 用于异步消息和任务解耦。

第四条是边缘执行线。中心平台通过受控 API 调用 edge-agent,edge-agent 在机房内网访问 PVE、Ceph、网络设备、裸金属等资源,并把结构化结果回传给中心。

4. 功能域怎么拆

AIOps 的菜单不是简单堆功能,而是按平台职责拆分。

EfficiencyManagement 用于效率看板和指标概览。它适合做管理视角的入口,让用户先看到告警存量、处理状态和团队效率趋势。

AlertNotification Center 承载告警、分派策略、通知渠道和通知记录。它们是运维事件进入平台后的第一层治理。

CI/CDAsset 负责交付和资产底座。代码源、制品、集群、模板、变量等能力都在这里沉淀,避免每个业务模块重复维护基础配置。

Edge Operations 是这个项目的重心,包含机房、Agent、PVE 集群、Ceph 集群、虚机清单、虚机操作台、裸金属节点、裸金属操作台、任务历史、自动化巡检和网络运维。

Settings 负责角色、用户、群组、系统日志、系统属性、SSO 配置和 AI 诊断配置。高风险动作都要进入这里的权限和审计体系。

5. 边缘 Agent 为什么必须无状态

边缘机房常见问题是网络边界复杂、内网地址重复、机房数量多、资源类型混杂。如果中心平台直接保存一堆临时脚本和本地缓存,很快会变成不可控的运维黑盒。

因此 edge-agent 被设计成无状态执行器:

组件 负责 不负责
AIOps 中心平台 机房、Agent、凭据、任务、审计、权限、产物 直接进入边缘内网执行命令
edge-agent 受控 API、只读采集、生命周期动作、结构化返回 保存平台配置、长期保存凭据、维护本地任务库
边缘资源 提供 PVE、Ceph、网络设备、裸金属状态和执行入口 平台权限、审计、报表和 AI 分析

这个设计带来一个直接好处:边缘侧可以横向部署多个 Agent,但权威状态始终在中心平台。Agent 出问题可以重启或替换,不会丢失任务历史和审计链路。

6. 生产功能不是“能点按钮”就结束

平台里很多能力看似只是按钮,但生产实现必须补齐闭环。

例如虚机操作台不是简单调用 PVE API。它需要先选择机房,输入虚机 IP,解析候选虚机,再让用户核对 VMID、节点、虚机名、IP、当前状态,最后执行启动、停止或重置。

公网 IP 管理也不是一张 Excel 表。它要支持 CIDR 规范化、父子段拆分、单 IP 状态、分配历史、回收、删除、批量导入、运营商识别和审计。

自动化巡检也不是跑一段脚本。它要支持 PVE、Ceph、网络设备等不同巡检类型,按机房和 Agent 分组执行,允许部分成功,保存 Excel、ZIP、JSON 等产物,并接入 AI 分析。

这些细节决定了平台能不能真的上线,而不是只停留在演示环境。

7. 一行代码不写,人的角色不是消失

这个项目的代码由 Claude+Codex 完成,但并不意味着“给一句需求,然后等它自己写完”。真正有效的方式,是把 AI 当成一个可以持续执行的工程团队,同时用人的经验给它搭好边界。

“一行代码不写”的含义,是不把人的精力消耗在重复编码上。人的工作前移到更高层:判断系统怎么拆、哪些动作危险、哪些数据不能泄露、哪些组件需要联动升级、哪些测试能证明上线安全。

人工主要做 5 件事:

人工职责 作用
知识储备 理解边缘运维、PVE、Ceph、网络设备、权限审计和发布链路
脚手架搭建 明确项目结构、菜单体系、权限模型、前后端边界和基础工程规范
需求澄清 明确功能目标、非目标、状态机和验收方式
约束编写 把版本、SQL、权限、构建、密钥、审计写成规则
过程验收 看页面截图、读日志、确认接口和权限是否符合预期
生产决策 判断是否升级 edge-agent、是否执行 SQL、是否进入发布

Codex 负责把这些约束转成代码、文档、测试、构建脚本和升级记录。

这种协作方式的重点不是让 AI “自由发挥”,而是把自由发挥限制在工程边界内。

8. 最关键的工程经验

第一,先有知识储备,再写提示词。提示词不是口号,而是把业务经验、架构经验和生产事故经验结构化表达出来。

第二,先搭基础脚手架,再让 AI 扩展功能。菜单、路由、权限、后端分层、SQL 规则、镜像版本、文档入口,这些地基不稳,AI 写得越快,返工越多。

第三,先写设计文档,再让 AI 开发。没有设计文档,AI 容易只补当前缺口,忽略状态机、权限、审计和发布路径。

第四,每个功能都要有开发流文档。开发流记录目标、修改范围、测试命令、测试结果、风险和下一步,避免长周期项目丢上下文。

第五,前端、后端、SQL、权限必须同步。只做页面按钮没有意义,后端不校验权限就有越权风险;只做后端接口也不够,菜单和角色权限不更新,用户看不到入口。

第六,edge-agent 相关能力必须单独判断发布影响。如果功能依赖 Agent runtime、capabilities、内置脚本或返回字段,就不能只升级 backend/frontend。

第七,发布版本必须有纪律。生产镜像 tag 使用 vX.Y.Z,不能使用 latestlocal、日期后缀或功能名后缀。

9. 小结

这个 AIOps 平台的落地经验可以总结为三点。

第一,平台架构要先把中心状态和边缘执行拆开。中心平台保存权威数据,edge-agent 做无状态受控执行。

第二,功能设计要围绕生产闭环。权限、审计、导入导出、失败处理、产物归档和升级回滚,和页面按钮一样重要。

第三, Claude+Codex 可以完成完整工程实现,但前提是知识储备、脚手架、需求约束、测试用例和发布纪律足够清晰。AI 负责产出,人负责判断和边界。

所以,这个项目的含金量不在“少写了多少代码”,而在**“把一个复杂运维平台拆成 AI 能稳定执行、能验收、能上线的工程系统”**。