Codex

在上一篇代码瘦身实践中，我把 Opsx 参与代码工作的范围分成了几个层次：修复 Bug、调整小功能、跨模块改造，以及更进一步的新模块研发。当时，前三类已有实践支撑；对于新模块，我仍然认为需要人的业务判断、更强的 Agent，以及贯穿实施过程的审核和验证。 需求来自我一直维护的数据库服务。此前，数据库巡检长期只有 Oracle 一种，近期才上线基于 Skill + LLM 的 MySQL 巡检，PostgreSQL 仍是待补齐的一环。AWR 报告分析虽然已有入口，背后却还是一套较早开发、依赖固定规则的 Java 程序，也缺少报告对比分析能力。我希望逐步完善数据库巡检的覆盖范围，同时更新已有的性能分析方式。 这些能力通过两个入口提供：墨天轮面向数据库社区用户，MES 仅供内部员工使用。两者服务的人群不同，但可以复用底层分析能力，让用户沿用离线采集、上传分析、查看报告的方式获得新服务，同时保留已有 Oracle 巡检和历史报告。 这一次，我开始用 Opsx 与 Codex 协作推进这项改造：将原来专用于 MySQL 巡检的服务抽象为通用 Skill Service，先实现 PostgreSQL 巡检，再利用这套基础快速完成 AWR 分析重构，并上线 AWR 报告对比分析。它需要同时处理前后端交互、分析服务、数据库记录与测试部署，改动范围涉及五个源码仓库。 这次研发没有要求我在本机搭建这五个仓库对应的开发环境，也无需在本地安装业务依赖、编译和部署各项服务。前后端与分析服务涉及不同的技术栈，如果都在本机运行，需要准备相应的工具链、服务配置与计算资源，还要维护它们之间的连接。Opsx 让 Agent 直接使用已接入的远程研发和测试环境，省去了在个人电脑上重建整套环境的负担，也不必同时打开多个 IDE 来组织这次跨仓库改造。 我通过 Opsx Issue 和 Codex 提出要求、审核方案、查看运行结果，再根据实际使用继续调整。源码阅读与修改、数据库查询、构建、部署和测试，由 Agent 通过已接入的工具与环境完成；产品范围和最终验收仍由我判断。 这些能力已经具有独立工具产品的完整形态。PostgreSQL 巡检需要连接采集工具、数据库与主机检查、上传解析、异步分析和报告管理；AWR 分析需要从复杂报告中提取性能证据，形成诊断建议；AWR 报告对比分析则进一步判断同一数据库在不同时段的变化。每项都可以作为独立的产品方向，本次将它们整合进已有业务，并共享用户体系与服务基础。 对 Opsx 而言，这是一次新的里程碑：此前接入的资产、源码和执行环境，已经能够支撑具有独立产品形态的能力从设计走向上线。 研发过程中需要触达的主要节点——前后端仓库、数据库、测试主机、构建工具、部署服务、日志与文件存储——基本贯通，Agent 可以在明确目标和授权范围内连续推进设计、编码、构建、部署、测试与修复。人的判断集中在产品取舍与验收，不必逐个环节代为操作。 将 MySQL 巡检服务抽象为通用 Skill Service Bethune Workspace 中的 issue_205 最初提出的需求，是分析服务器上已有 MySQL 巡检的逻辑和流程。在此基础上，我希望将其中可复用的执行机制抽离出来，使服务能够承载不同 Skill，而不再围绕单一数据库类型组织。 ...