Opsx 与 Codex 跨五个代码库的产品级研发：交付 PostgreSQL 巡检和 AWR 分析

在上一篇代码瘦身实践中，我把 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，而不再围绕单一数据库类型组织。

这次改造将 MySQL 专用服务逐步抽象为通用 Skill Service：保留各类输入的解析与校验，将专业分析方法交给对应 Skill，结合 LLM 生成报告，再通过业务后端对接任务状态、记录与前端展示。目录和重复文件的整理是其中一部分，更重要的是明确了公共服务能力与各项专业分析逻辑的边界。

PostgreSQL 巡检首先验证了这套抽象，随后 AWR 分析与报告对比分析继续复用已有任务和报告流程。后续增加其他数据库的巡检，或接入巡检之外的 Skill 服务，可以沿用这些基础，将研发重点放在新场景的数据输入、专业方法和结果验收上。不同 Skill 仍可能需要解析器、接口或页面适配，但无需为每项能力重新搭建整套服务。

其中，AWR 涉及一次核心分析方式的重构：原来由 Java 程序中写死的规则给出判断，现在由 Skill 组织分析方法与要求，LLM 根据报告中的性能证据生成 Markdown 格式的分析报告。文件解析和必要的输入校验仍由程序完成，分析结果则需要通过新的任务接口、持久化逻辑和报告页面交付。

因此，AWR 的改造既涉及分析执行器，也涉及新旧报告兼容和前后端衔接。Skill Service 承担业务报告生成，Opsx 则组织这次研发和远程操作；两者职责不同。

围绕一份报告的流转，五仓职责逐渐明确：

新增 PostgreSQL 需要接通两个前端、业务网关和分析服务，Oracle 导出恢复才涉及 emcs_app。这次不是对五个仓库分别增加功能，而是围绕同一份报告，确定各层的接口、数据与兼容边界。

在同一个任务中完成设计、实施与验证

方案确定后，Codex 还需要知道代码在哪里、服务如何关联、到哪台主机执行。它本身可以编程并配置远程工具，Opsx 的作用则是提供已经接入的资产与执行条件，以及持续积累的系统知识：

部分环境事实仍需要我补充，再由 Codex 核验并写入 Knowledge。本轮的分工是：我确定产品范围与验收要求，Codex 审查方案、检查进度并复核结果；连续的调查与编码通过 issue_205 派发给 Claude Code，明确的 Git 检查、数据库查询或日志读取则直接调用 Runtime Shell。Codex 根据执行反馈继续调整任务，必要时也直接修改代码。

向 Issue 写消息使用 POST /api/v1/issues/{issue_id}/messages，启动任务使用 POST /api/v1/issues/{issue_id}/execute。前者保存指导内容，后者才发起执行。知识通过 GET/PATCH /api/v1/knowledge/{knowledge_id} 查询和更新，直接 Shell 则使用 Runtime 的 exec 接口。

这些已有 API 足以支持本次协作，不需要再为 Codex 专门开发一套 Opsx CLI。外部 Agent 可以直接组合使用平台能力；直接 Shell 调用的结果需要主动写回 Issue，经过验证的方法再更新到 Knowledge，才能供后续任务接续使用。

Runtime 根据目标资产和执行条件选择：应用四仓在 motest-01 构建部署，Skill Service 在 mes-app-01 运行。Claude Code 可以在支持 Agent 的主机上运行，再调用只有 Shell 能力的测试 Runtime。查询数据库时，还需确认目标 Runtime 的网络、客户端与账号权限，不能仅凭主机在线就认为具备执行条件。

下面以检查测试环境中前端仓库的最新提交为例，展示 Codex 调用 Opsx API 的请求与响应。路径已脱敏，提交哈希与内容为模拟数据，响应字段沿用实际接口格式：

POST /api/v1/runtimes/<test-runtime-id>/exec
Content-Type: application/json
X-Workspace-Id: <workspace-id>

{
  "command": "git -C /path/to/modb-front log -1 --format='commit: %h%nsubject: %s'",
  "timeout": 30
}

{
  "stdout": "commit: 7e4c9a2\nsubject: feat(awr): add comparison upload and report view\n",
  "stderr": "",
  "returncode": 0,
  "error": ""
}

执行仍受部署与账号权限约束：X-Workspace-Id 只是范围声明，不能代替身份认证，管理入口必须控制访问，具体操作权限由目标账号决定；当前直接 Shell 接口也没有逐命令审批。失败时，Codex 分别检查接口的 error 与命令退出码；若等待超时，先核对远端进程和日志，再决定是否重试，因为同步等待结束不代表远端进程已经终止。

第一轮交付：让 PostgreSQL 巡检真正进入两套产品

对我而言，第一轮的验收目标很具体：用户能够在墨天轮和 MES 下载工具、上传采集文件，并看到完整的 PostgreSQL 分析报告。用户在数据库环境运行只读脚本，生成 TXT 文件，再通过墨天轮或 MES 上传 TXT 或 ZIP；后端校验采集类型并提交异步任务，Skill Service 预处理数据、调用 Skill 与 LLM，结果进入对应的历史列表和报告页面。

采集器还补充了操作系统、CPU、内存、磁盘和资源限制等主机信息，分析规则同步调整。数据库参数和统计需要结合运行环境解释；如果脚本运行在容器内部，相关检查反映的则是容器视角。离线方式无需开放远程数据库连接，但采集负载与文件中的环境、业务信息仍需按实际要求处理。

两个前端复用了共同的业务契约，并保持各自的产品入口。MySQL、PostgreSQL 和 AWR 默认采用标准模式，墨天轮可选快速和标准，MES 还可选择完整模式；选择值必须传递到实际执行器。验收也要从页面上传开始，经过状态轮询，最终确认报告内容可读，而不能只检查接口返回成功。

这一阶段还用到了系列第一篇留下的经验。PostgreSQL 采集器需要供用户下载，我要求将它与已有工具统一放到 OSS。Codex 查询此前 Sitemap 实践沉淀的 kw_168，复用已确认的工具、执行位置与校验方法，通过 ossutil 上传，再重新下载比较文件大小和 SHA-256，两个前端统一引用公共下载地址。

从 Sitemap 到数据库巡检，业务对象已经变化，云资产操作方法仍然适用。本次需要重新判断的是采集器的目标路径、公开方式和页面引用；工具配置等已有事实则有据可查。知识由此参与了另一项业务的交付。

这也延续了 009 接入测试环境的思路。墨天轮 Nuxt 前端采用测试构建与镜像发布，MES 前端构建后发布静态目录；正式源码与依赖缓存目录分开，代码先在仓库提交，再同步构建。页面、接口或样式不符合预期时，Agent 可以继续检查代码和日志，修复后重新部署验证。我的反馈面对的是已经运行的功能，Git 则保留每次代码变化，使修改可以审阅和追溯。

第一阶段结束后，Codex 将五仓职责整理为 kw_192，将构建部署方法与功能契约分别写入 kw_196、kw_197。下一项需求随即检验了这些知识是否能够继续使用。

新的需求到来时，第一轮经验已经可以使用

第一轮完成了 PostgreSQL 巡检接入和 AWR 单报告分析重构。在此基础上，我又提出 AWR 报告对比分析：上传同一数据库两个不同时段的报告，比较指标、Top SQL、等待事件与风险变化。墨天轮和 MES 都需要支持，重构后的单报告分析也要继续可用。我让 Codex 通过 Opsx API 创建 issue_213，尝试让平台在已有经验上完成新的分析、计划与研发。

这项能力的复杂度主要在分析本身。两份 HTML 需要被正确解析，数据库身份、快照和时间窗口需要可靠识别，还要将两个时段的证据组织成可比较的内容，分析性能变化及其可能原因。结果最终通过同一任务记录和报告页面交付，既要有分析价值，也要具备输入校验、错误反馈和历史查询等完整的使用流程。

任务中明确引用了第一阶段的仓库、功能与部署知识。已有工作台、任务记录和报告组件可以继续使用，新增工作集中在双文件输入、对比校验与分析内容上。最终上传契约保持为：

单报告分析：file + mode
报告对比分析：file + file_compare + compare=1 + mode
一次对比：一个 batch、一个分析任务、一条业务记录

前后端必须对这些字段保持一致。两份报告进入同一任务后，Skill Service 先按 HTML 表格结构提取 DBID 与快照窗口，检查报告格式、数据库一致性，以及窗口是否有效、不同且不重叠，再交给 LLM 分析变化。真实 Oracle AWR 存在多种表格布局，实际报告样本也因此进入解析测试。

Codex 的验收继续沿这条业务路径进行：有效对比能够返回完整结果，不同数据库、相同或重叠窗口及无效文件被拒绝，原有单报告仍能使用。报告生成后，还要检查两个前端的上传交互、列表和详情。

原始 AWR 与结果 Markdown 的私有 OSS 留档也在这轮补充。临时目录随任务结束清理，持久保存输入能够支持失败复现和结果核对；指定真实批次已有补存与校验记录，历史任务则不会自动补齐。业务表最终仅为报告对比分析增加对比类型和两个文件名字段，DBID、窗口等信息在分析时校验，避免为没有明确用途的数据继续扩充表结构。

这一轮进入实施时，已经具备明确的仓库职责、部署方法和功能契约，但页面交互、实现取舍和实际报告仍需要我的反馈与 Codex 的修复。新的定位与验收经验又整理为 kw_199，原有知识中的过时约定也按最终实现更新。

前端设计尤其体现了当前的能力边界。页面布局、交互与色彩比旧版有所改善，但距离经过专业设计、可规模化维护的成熟产品界面仍有差距。我也花了一些时间指导 Agent 调整前端细节。贯通研发执行，并不意味着已经具备同等成熟的产品设计能力。后续可以考虑接入设计类 Agent 或工具，或先通过 v0、Google Stitch 等工具形成设计方案，再交由 Opsx 与编码 Agent 实现、联调和验证，将视觉与交互要求更早明确下来。

两轮改造合计涉及五仓新增 8,654 行、删除 460 行，统计已排除重复采集器副本、依赖锁文件和无关改动，包含源码、测试、配置与 Skill 文档。按 9 月 12 日核对的 Git 状态，五个应用仓库的本轮提交已包含在远端 master，上线部署到了生产环境。

按我对现有系统和改造范围的经验估算，即使不计页面功能设计，由一名前端和一名后端工程师共同完成这批需求，也大约需要一个月。本次在已有资产接入、测试环境和业务基础上，Opsx 与 Codex 在不到一周内完成了方案规划、研发、验证和上线，我在其中持续参与需求判断与验收。这个对比不是同等条件下的工时测量，但它体现了此次协作的实际价值：提速不仅来自代码生成，也来自源码、数据库、构建部署与运行反馈之间的连续衔接。

从能够维护系统，到能够继续建设系统

009 验证了 Opsx 对已有代码进行大规模改造的能力，010 则进一步交付了可作为独立产品方向的数据库巡检与性能分析能力，覆盖方案设计、前后端编码、数据库调整、构建部署和业务测试。

这次跨越的基础，是研发所需的主要节点已经贯通。Agent 能从方案进入源码，从接口进入数据库，从构建进入部署，再根据日志和页面反馈继续修复。因此，在目标、权限和验收条件明确的任务范围内，Opsx 可以支持自主推进全流程研发。本次仍由我与 Codex 共同审核和调整产品，并非无人干预的产品开发；但执行链路已经不再要求人逐站传递材料和代做操作。

这也是本次最让我重视的变化：我可以围绕用户需要什么、页面应该怎样工作、报告是否达到要求继续提出判断，Opsx 与 Codex 则共同把这些要求落实到源码、数据和运行环境中。此前积累的运维能力，开始支持系统继续增加新的业务能力。

Opsx 与 Agent 解耦的价值，也在这次协作中具体体现出来。Codex 接入后，可以直接使用已有 Runtime、读取知识，并将新的经验写回平台；已经接入的资产与执行条件不必随工具重新组织。从 Sitemap 的 OSS 方法，到本次的五仓职责与验收规则，经验在不同任务间延续。

这次交付还留下了一个可以继续扩展的业务基础：通用 Skill Service。它让数据库巡检版图的扩展不再意味着逐项重建服务，也为更多基于 Skill + LLM 的专业服务留下了接入路径。进一步完善输入输出约定、依赖管理与执行权限后，还可以演进为运行自定义 Skill 的通用服务；这是后续方向，并非本次已经交付的能力。业务服务在这套基础上扩展，研发和维护它们的经验则继续积累在 Opsx 中。

因此，我更愿意把 Opsx 看作一套能够持续积累系统认知的工作基础。人的产品判断、Agent 的推理和编码、Shell 的实际执行，各自发挥作用；经过验证的结果继续进入平台。模型与工具会演进，而对自身系统的理解能够保留下来，使下一次更复杂的需求也有条件被接住。