AI 运维

墨天轮（MODB）的这套系统一直由我维护。过去，Sitemap 也主要靠人工更新：从多张业务表取数、拆分文件、更新前端仓库，再跟随发布流程上线。随着内容规模不断增长，这项工作越来越复杂。在人手有限、其他业务优先级更高的情况下，我中断了 Sitemap 的持续维护。 这不是维护意愿的问题，而是原来的维护方式已经很难靠有限人力长期坚持。Opsx 第一期完成后，我想用这个真实任务验证一件事：当 AI 能通过 Opsx 连接源码、主机、数据库和 OSS，它能不能帮我重新启动 Sitemap 维护，并把一次复杂操作变成以后可以持续运行的机制？ 这次实践的真正目标，不是一次性补齐 120 万个 URL，而是建立一套不再持续占用工程师时间、能够让原创内容稳定进入搜索发现链路的长期机制。 先说说 Sitemap 是什么 Sitemap 是网站提供给搜索引擎的一份 URL 清单。它通常由一个 sitemap.xml 索引文件和若干 URL 分片组成，用来告诉 Google、Bing 等搜索引擎：网站有哪些页面、这些页面最近何时更新。 它不能直接保证页面被收录，但对内容量大、更新频繁的网站非常重要。搜索引擎不必只靠站内链接慢慢爬，可以从 Sitemap 快速发现新内容。 搜索引擎目前还是网站流量的第一大入口，虽然AI对搜索引擎有一定的冲击，但是基础的搜索引擎SEO对网站，尤其原创内容社区是非常必要的。 MODB 正是这样的站点。文章、问答、文档、标签、专题、招聘等内容来自不同的数据表，URL 数量已经超过 120 万。随着规模增长，Sitemap 早已不是生成一个 XML 那么简单。 我一开始只是让 Opsx 回答一个问题： 看看前端源码 /static 下的 XML 文件。这些是网站的 Sitemap，最新更新时间是什么时候？ 这个尝试很快从核对更新时间扩展成一次完整的生产改造：迁移旧文件、补齐中断期间的数据、纠正数据源、重新设计存储结构、记录增量水位，再创建每周自动运行的 Shell Schedule。AI 负责解决重新启动时的复杂性，后续正常运行不再依赖 LLM，也不再消耗推理 Token。 整个过程都发生在同一个 Issue 中。Opsx 共记录了 27 次对话、888 个 Agent turns、1,761 个执行事件。Claude Code 调用 MiniMax-M3 完成本次治理，可归属到该 Issue 的已记录用量为 752,506 Token；期间还发生了 701 次 Shell 类工具调用。最终核对和处理 10 类内容、1,204,599 个 URL、45 个 Sitemap 索引条目。 ...

最近我在 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 的本地目录中，就会出现新的孤岛： ...