Time is UP

墨天轮接力白求恩为用户提供了免费的 Oracle 巡检功能，从用户视角看，Oracle 离线巡检的操作并不复杂：在数据库环境中运行采集程序，得到一个 ZIP 巡检包，上传到 Bethune，等待平台生成分析报告。 真正复杂的是报告背后的处理链路。BTRobot 需要从不同版本、不同操作系统和不同部署架构的 Oracle 环境中采集数据库配置、对象、性能和 AWR 等信息；巡检包进入 Bethune 后，还要依次经过数据导入、规则分析和报告生成。Bethune 分析服务运行在两个应用节点上，过程数据与结果保存在 MogDB 中，采集端和分析端又分别由两套源码维护。 Oracle 数据库 → BTRobot 离线采集 → Oracle 巡检 ZIP 包 → Bethune Loader 导入 MogDB → Analyzer 分析 → Reporter 生成巡检报告 任何一个环节出现偏差，都可能让用户最终拿不到报告。应用日志中的一条 ERROR，背后可能是采集数据错误、ZIP 目录结构异常、Loader 解析缺陷、数据库字段宽度不足、分析规则不完整或应用源码问题。传统监控只能报告日志出现异常，维护人员仍需跨主机、数据库、数据包和代码仓库逐项还原现场。 Bethune Workspace 的 issue_174 展示了 Opsx 如何承接这项工作：Schedule 从应用日志发现异常并创建 Issue，Agent 沿 Asset Graph 跨多个 Runtime 收集证据，维护者在关键业务判断处提供正常样本，修复后的巡检包重新完成导入、分析和报告生成，经过验证的处理方法再进入 Knowledge。 一个服务故障，实际连接六个资产 Opsx 中的 svc-emcs-bethune 不是孤立的服务名称。Asset Graph 已经记录它与运行节点、数据库、采集程序和分析程序之间的关系： ...

墨天轮（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 索引条目。 ...

100 台主机、20 个数据库、30 个应用,谁在巡、谁没巡、上次检查是什么时候? 这个问题看起来简单,实际上很难持续回答。无论是专业监控平台、分散在主机上的 crontab,还是人工登录查看,它们都能发现一部分问题,但资产清单、检查规则、执行记录和后续处置往往分散在不同位置。某台机器的巡检脚本是否仍在运行、上次检查是正常还是已经告警、磁盘 92% 是今天的问题还是三个月前就存在——这些问题最终仍要靠人逐一确认。 真正困难的不是执行 df 或连接数据库,而是让检查结果成为系统可持续使用的运行事实: 发现"磁盘 92%“之后,这个状态如何进入系统认知,而不是只停留在某个终端输出? 异常出现时,如何自动关联到正确的资产、上下游关系、历史经验和可执行的处置路径? 主机、数据库、应用和云资源的健康标准完全不同,如何在统一框架下管理它们? 人工巡检的经验如何固化为可持续运行的机制,而不是每次都重新判断阈值? Opsx 接管全域资产巡检的方式,不是再增加一套"把检查结果发出来"的工具,而是把健康检查收拢到 Asset Graph: Asset 提供身份和运行拓扑 ↓ Schedule 按周期触发确定性检查 ↓ Shell 执行并计算健康状态 ↓ 结果回写 Asset metadata ↓ 异常自动进入关联资产的 Issue ↓ Agent 读取 Memory、Knowledge 和上下游关系继续诊断 巡检不再是某台机器上的孤立脚本,而是平台对真实资产持续建立运行认知的过程。本文从 MODB 和 Bethune 已经运行的主机、MogDB、应用和仓库巡检出发,说明 Opsx 如何让不同资产使用统一机制,并让健康状态成为后续诊断的确定性起点。 主机巡检:从负载、内存、磁盘到健康状态的完整链路 MODB Workspace 当前运行一条每日主机巡检 Schedule,覆盖生产环境中的关键主机资产。Schedule 配置如下: 名称: MODB Daily Host Health Check Workspace: modb 目标资产: 多个主机资产,包括 host-moapp-0002 等 Runner: shell Cron: 0 0 * * * (每日 00:00 UTC) 状态: active 每次执行时,Schedule 会为每个目标主机创建独立的执行记录,检查以下核心指标: ...

SSL 证书管理的难点并不在某一次申请或部署，而在整个生命周期的持续维护。证书数量增加以后，到期时间、域名控制权验证、证书签发、CDN 部署和公网生效验证分散在不同系统中；任何一个环节出现遗漏，都可能直接造成 HTTPS 访问失败。 墨天轮维护着多个需要独立轮换证书的域名。阿里云当前的个人测试证书免费版有效期为 90 天，个人测试证书 Pro 的服务周期为 6 个月。综合域名数量与长期成本后，我仍然选择使用免费证书，但也因此需要承担更高频的轮换任务；目前仅墨天轮就维护着约 10 张 SSL 证书。 免费证书降低了采购成本，却把压力转移到了运维环节。90 天有效期意味着每个月都可能有不同域名进入更换窗口；依赖日历提醒和个人记忆，无法形成稳定的长期机制。 过去确实发生过几次证书到期导致网站无法正常访问的情况。其中一次发生在通勤途中，我只能临时在地铁站处理证书更换。这次紧急处置暴露的问题并非缺少某一条操作命令，而是从申请、验证、签发到部署和公网验收的完整流程仍需由人跨平台串联。 这些步骤包含多个异步状态。证书审核和签发有时需要等待 3～5 分钟，DNS 记录需要等待解析生效，CDN 下发也需要等待边缘节点更新。人工操作不仅要完成每个动作，还要反复返回不同平台确认上一阶段是否成功。流程越长，遗漏和误操作的风险越高。 因此，这次实践的目标不是临时完成一张证书的更换，而是用 Opsx + AI + 阿里云 CLI 管理完整的 SSL 证书轮换过程：提前确定目标 Asset、执行 Runtime 和操作步骤，在计划时间自动唤醒同一个 Issue、启动已经保存的执行 payload，并以公网 TLS 端点的实际结果作为最终验收依据。 证书规模扩大后，运维成本来自流程协同 人工更换一张证书，通常需要依次完成以下步骤。不同证书类型和部署平台会省略其中部分环节，但整体状态依赖基本一致： 发现即将到期 → 确认域名、当前证书和实际部署平台 → 购买或创建证书 → 等待平台受理 → 提交证书申请并绑定域名 → 直接申请，或提交包含目标域名与 SAN 信息的 CSR → 完成域名控制权验证 └── 域名在其他平台时，通常需要增加 DNS TXT 记录 → 等待审核与签发（可能需要 3～5 分钟或更长） → 选择直接创建云端部署任务 或下载证书与私钥，再上传到目标平台 → CDN 下发，或重新加载配置 / 重启应用 → 等待边缘节点或应用生效 → 从公网验证证书链和有效期 → 记录下一次到期时间 单个步骤本身并不复杂，但只有上一阶段进入正确状态以后，下一阶段才能继续。证书数量增加后，人工维护的问题会被进一步放大： ...

应用日志监控擅长发现异常，却很少覆盖异常发生后的诊断与处置。关键词命中次数、错误率和响应时间一旦超过阈值，监控系统可以迅速发出告警；但错误是否来自同一根因、影响了哪些服务、是否需要立即控制影响，通常仍要由工程师接手判断。 墨天轮原有的日志监控也是如此。2026 年 7 月 10 日，外部监控只告诉我后端程序出现了 74 条 ERROR。我根据这条告警手工创建了 issue_49，初始信息只有报错数量和日志目录： 接到告警说后端程序 ERROR 报错 74 个， 请看看是什么报错。 issue_49 随后通过 Agent 连接两台应用节点，重新统计完整日志：一个节点有 113 条 ERROR，另一个节点有 80 条，合计 193 条。因此，Issue 标题中的 74 和分析结果中的 193 属于不同统计口径：74 是外部监控传来的初始告警值，193 是 Agent 扫描两台服务器后得到的完整 ERROR 总量。分析过程中又识别出 74 条短信验证码高频请求，但这是错误分类结果，不能代替完整日志总量。Opsx 继续完成错误分类和根因分析，但触发链路仍然存在断层：第三方平台发现异常，人把告警数量转述给 Opsx，再手工创建 Issue。只要人没有及时转述，后续分析和处理就不会开始。 单一的报错数量也不足以回答生产处置真正关心的问题： 74 条 ERROR 是 74 个不同问题，还是同一个问题重复了 74 次？ 错误来自哪个应用副本、哪个接口和哪个用户或 IP？ 是程序 Bug、数据库故障、外部依赖异常，还是攻击流量？ 服务是否已经恢复，是否需要立即介入？ 如果属于已知问题，能否直接复用历史结论和处置方法？ 因此，这次实践不只是增强告警后的分析，而是替换这条依赖第三方监控和人工转述的入口：由 Opsx 的 Shell Schedule 每 10 分钟直接扫描两台应用服务器的增量日志；ERROR 超过阈值后自动创建资产关联 Issue，对满足明确规则的已知问题先执行处置，再由 Agent 分析根因、验证结果，并把发现、动作和结论保存在同一个运维上下文中。 ...

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

生成式 AI 普及以后，技术用户获取答案的方式正在发生变化。一部分原本需要访问社区、搜索历史问答或发布新问题的需求，被 AI 对话直接承接。对技术社区而言，真实用户访问和 UGC 活跃度承受压力并不意外。Stack Overflow 也曾在官方流量分析中披露，GPT-4 发布后的 2023 年 4 月出现过约 14% 的超常流量下降。 墨天轮的数据一度呈现出相反现象：在行业真实流量承压的背景下，网站访问指标没有下降，反而增长了数倍。按照过去以日活、月活为核心的运营口径，这原本应该是一个非常好的结果；但同期 UGC 产出，以及用户登录、签到等能够确认的互动数据并没有同步增长，部分指标反而在下降。 继续核对 CDN、NGINX 和应用日志后，指标之间的矛盾才得到解释。传统搜索引擎蜘蛛的流量变化很小，对这轮指标增长的影响可以忽略；真正抬高访问量的是大量伪装成普通浏览器的程序化抓取请求。它们的目的无法从访问日志直接证明：可能是搬运网站内容，可能是构建本地知识库，也可能用于大模型训练。能够确认的是，这些请求没有带来相应的登录、签到或内容互动，却被计入了原有的流量、日活和月活指标。 第一阶段，我先用 User-Agent 黑名单处理能够明确识别的低价值抓取请求。当前实际规则如下，Googlebot 和 Bingbot 没有进入名单，因此不会在这一层被拦截。下面为了阅读做了换行，CDN 中保存的实际配置仍是一条连续规则： *YisouSpider*|*Baiduspider*|*python-requests*|*Go-http-client*|*okhttp*|*Apache-HttpClient*|*Sogou*|*Firefox/3.0*|*Windows NT 5.1*|*360Spider*|*AhrefsBot*|*Windows NT 6.1*|pc|axios/1.7.7|*Bytespider* 这份名单不只包含一搜、百度、搜狗、360、Ahrefs 和 Bytespider 等已知蜘蛛，也覆盖 python-requests、Go-http-client、okhttp、Apache-HttpClient、axios 等常见程序化客户端，以及根据当前业务访问特征确认不再需要的旧客户端标识。规则生效后，CDN 侧流量下降约 30%，说明这一层简单、确定且几乎没有运行成本的过滤已经处理了相当比例的非用户请求。 但这一步很快遇到边界。剩余 Bot 不再使用固定的爬虫 User-Agent，而是伪装成 Chrome 等普通浏览器；有些还使用 IP 池轮换来源，把请求分散到同一网段的多个地址。单看某一个 IP，请求量可能并不突出；聚合到 /24 网段后，持续抓取的特征才会显现。只依赖 User-Agent 或单 IP 黑名单，已经无法继续识别这部分流量。 问题因此不再只是“访问量太大”。爬虫流量一方面污染运营指标，使表面增长与登录、签到、UGC 等互动指标发生背离；另一方面持续消耗 CDN、源站服务器和 OSS 资源。对于以原创技术内容为核心的网站，它还带来内容被批量获取的风险： CDN、源站服务器和 OSS 都在为它们消耗流量、连接和计算资源； 原创内容被外部平台批量抓取和搬运，墨天轮承担内容生产与分发成本，内容价值却被外部平台直接复用。 云 WAF 和 Cloudflare 都是可以考虑的方案，但并不适合直接套用到当前场景。WAF 的 Bot 识别与定制能力难以完整覆盖内容型网站的业务规则，整体费用也比较高；Cloudflare 在中国大陆的接入还有额外条件，其官方 China Network 文档要求先使用 Enterprise Plan，再单独订阅中国网络，并由合作方审核域名。 ...

Opsx 支持将代码仓库作为 Repo Asset 管理，并让 Agent 在指定仓库中读取和修改代码。整个过程不依赖开发者本地 IDE，代码差异、提交记录和恢复路径仍由 Git 管理。 MES Workspace 下的 issue_50 和 issue_77 分别验证了仓库查询与代码修改能力。 从 Repo Asset 定位代码 Repo Asset 保存仓库的稳定身份和执行上下文，包括： 仓库类型、技术栈和默认分支； Runtime 中的工作目录； 源码仓库与应用服务的关联关系； 能够访问该仓库的 Runtime。 创建 Issue 时只需绑定目标 Repo Asset。Opsx 根据资产与 Runtime 的映射，将任务交给具备仓库访问能力的 Agent，无需在 Prompt 中重复提供主机、路径和分支信息。 issue_50 绑定 Java 后端仓库 repo-enmo-support。Claude Runner 读取 Asset Metadata 后，在对应 Runtime 中执行 Git 查询，确认仓库包含四个远端分支：dev、master、report 和 word，默认分支为 dev。 Execution 先执行 git fetch --all --prune 更新远端引用，再通过 git branch -r 返回分支清单。 ...

前言 上周在GitHub上一个BettaFish项目很火，再次看到MindSpider项目，以及之前看到的MediaCrawler项目，支持采集多个热门社交平台的相关数据，我将BettaFish在一台老MAC上部署跑起来了（主要逻辑就是在不同渠道不停的搜负面词语。不过针对数据量少的关键字效果一般，只要出现一点错误就会被无限放大），MindSpider & MediaCrawler实在跑不起来，项目太重，每次playwright调起Chromium都被反爬，尝试修复一段时候后担心账号被封还是放弃了。 回头想想垂直领域直接用浏览器插件就可以搞定，大的舆情监测直接花钱买服务或者API接口。 于是周末我用 Trae SOLO 花了半个下午，撸了一个 Chrome 浏览器插件，核心功能： 抖音 / 小红书 搜索页 和 详情页 均可一键采集 自动识别 一级 与 二级 评论，用 parent_id 关联 导出 CSV（UTF-8 BOM），Excel 直接打开即可透视 全程 0 后端，纯前端离线运行，隐私无上传 下面聊聊技术实现与踩坑。 一、整体架构 ├─ manifest.json // 权限声明 + 注入规则 ├─ content.js // 页面脚本，负责 DOM 解析、数据缓存、CSV 生成 ├─ background.js // 扩展后台，只负责下载文件 ├─ styles.css // 悬浮按钮样式 └─ README.md content 脚本 同时注入 douyin.com 与 xiaohongshu.com，按 hostname 自动路由 用 Map() 做内存数据库，键为 videoId / noteId，值为元数据 + 评论数组 采集完成后调用 chrome.runtime.sendMessage() 把 Blob 传给 background 触发下载 二、核心难点 1. 动态 DOM + 哈希 class 抖音&小红书前端都是 React 同构 + 随机类名，class="HtBH2h0B" 下次就变了。 解法： ...

作为一个专业领域的技术专家，我需要实时了解全面的信息。市面上的RSS工具要么功能复杂臃肿，要么部分需求不支持，最大的问题是不能在同一个平台浏览所有信息源。经过一番调研，我决定用Kiro写一个轻量级的RSS聚合工具。 令人惊喜的是，一个周末就完成了整个系统，并成功同步了近5000篇文章（标题+链接）。这篇文章将详细介绍整体架构和实现的技术难点，展示Kiro在复杂系统开发中的不凡能力。 先放一些截图吧。 Kiro开发界面，可以看到整个项目完成差不多只用了不到 200 Bonus，实际编码时间估计也就1天时间。 Web首页（没有做任何UI调教，自己凑合能用），支持浏览最新资讯，筛选搜索，采集特定文章。 网站管理页面，主要是指定标题、链接、时间的元素。且支持API方式获取，同样配置好JSON匹配规则。 微信公众号管理页面，公众号支持批量导入，图标转存到了腾讯云，否则防盗链无法展示，可以设置同步页数/同步间隔，同时记录了最后同步时间。 还有一个页面主要记录微信管理员cookie，比较简单就不展示了。另外针对部分文章会采集转换成markdown格式存储到本地，图片也做了处理，文章可以正常展示，后续打算基于有价值的文章做一个垂直领域的RAG。 （以下绝大部分直接用Kiro在项目中生成） 系统需求分析 核心需求 多源聚合：支持传统网站RSS、API接口、微信公众号文章 统一管理：在同一个平台浏览和管理所有信息源 智能处理：自动去重、内容清理、图片处理、HTML转Markdown Web界面：提供直观的管理和浏览界面 文章同步：将RSS文章同步到标准化的articles表 高性能：支持大量文章的存储和检索 技术挑战 异构数据源整合：不同平台的数据格式差异巨大 微信反爬虫：微信公众号的访问限制和安全机制 API网站支持：政府部门API接口的调用和数据转换 内容处理：HTML转Markdown、图片上传COS、推广内容清理 数据一致性：避免重复文章，保证数据完整性 性能优化：大量文章的存储和快速检索 多管理员机制：微信账号轮换和频率限制处理 系统架构设计 整体架构 ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ 数据采集层 │ │ 数据处理层 │ │ 应用服务层 │ ├─────────────────┤ ├─────────────────┤ ├─────────────────┤ │ • 网站爬虫 │ │ • 内容清理 │ │ • Web管理界面 │ │ • 微信爬虫 │ │ • 图片处理 │ │ • REST API │ │ • API接口 │ │ • 格式转换 │ │ • 文章同步 │ │ • 多管理员轮换 │ │ • HTML转MD │ │ • 一键采集 │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ │ │ └───────────────────────┼───────────────────────┘ │ ┌─────────────────┐ │ 数据存储层 │ ├─────────────────┤ │ • PostgreSQL │ │ • 腾讯云COS │ │ • 双表结构 │ └─────────────────┘ 数据流架构 原始数据源 → RSS采集表 → 内容处理 → 标准化文章表 → Web展示 ↓ ↓ ↓ ↓ ↓ 网站/API rss_articles 图片上传 articles 用户界面 微信公众号 _list HTML转MD 表 管理后台 核心模块 1. 数据库设计 (database.py) 采用PostgreSQL作为主数据库，设计了双表结构： ...