PostgreSQL

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

最近我在 Opsx 中导入了一套 PostgreSQL 巡检 Skill。 它不是一段单独的提示词，而是一个完整目录：里面有 800 多行的 SKILL.md、一份 2,000 多行的 Shell 脚本，还有数据库连接配置示例。过去，这类东西通常放在 DBA 的电脑、运维仓库或者某台服务器上。谁要用，谁就把文件复制过去，再根据目标数据库调整环境。 这一次我想验证的是另一件事：能不能让 Opsx 保存完整的巡检方法，在任务发生时，把 Skill、数据库资产和执行环境组合起来，再交给 OpenCode 和 LLM 使用？ 如果这条链路成立，留下来的就不只是一份健康报告，而是一项可以继续交给不同 Agent、不同 LLM 和不同 PostgreSQL 资产使用的平台能力。 这次实践使用了两个真实对象： kw_156：导入 Opsx 的 db-server-healthcheck-postgresql Skill； issue_122：使用该 Skill 执行 PostgreSQL 健康巡检的 Issue。 巡检已经完成，整体结论为 Warning。数据库当时没有阻塞、长事务、严重表膨胀或 XID 回卷风险，但磁盘、WAL 归档、日志、安全配置、部分表结构以及 PostgreSQL 版本都存在需要继续处理的问题。 Skill 是 Multi-Agent 平台的基础设施 对于任何 Multi-Agent 或 AI 平台，Agent 和 LLM 只解决了“由谁思考、由谁执行”的问题。平台还必须回答另一个问题：专业能力从哪里来，又怎样被不同执行端复用？ 这个承载专业能力的基本单元就是 Skill。数据库巡检、Kubernetes 排障、日志分析、备份校验等任务，都不应该每次只依靠 LLM 临时生成命令，而需要已经验证过的说明、脚本、参考资料、阈值和安全边界。 因此，内置 Skill 和导入外部 Skill 不是锦上添花，而是 Multi-Agent 平台的基础能力。如果 Skill 仍然分别安装在 OpenCode、Claude Code 或其他 Agent 的本地目录中，就会出现新的孤岛： ...