团队在生产环境出问题时，通常先从用户那里知道。用户说页面打不开、下单失败，这才发现服务已经挂了一阵子。然后才去翻日志、查监控，顺着报错找原因。
这类检查其实不难：读几个指标、查几段日志、和昨天对比一下，十几分钟能做完。难的是想起来做、并且天天做。
AI 工具都能定时干活了
定时执行一段指令，现在的 AI 编程工具基本都自带：WorkBuddy 有定时任务，到点自动跑一段提示词；Claude Code 可以把固定检查写成 routine；OpenAI Codex 有 scheduled task；Cursor 有 automation；再不济，用一个外部 cron 定时拉起一个无头 agent 也算。
也就是说，「每天早上 9 点自动检查一次」这个动作，各家工具都做得到。真正缺的是后面两件事：到了点查什么，以及怎么判断「比上次差了」——总不能让它每小时把所有指标原样甩给你一遍，那样用不了两天你就会把它静音。
这两件事 CloudBase 替你准备好了。装上 CloudBase 连接器或 skill，agent 就能读你环境里的指标和日志；再用 ops-inspector 这个巡检 skill，查什么、按什么频率查、什么情况才上报，规则都已经写好。
巡检能查什么
ops-inspector 内置四类巡检，各有默认频率：
| 巡检 | 查什么 | 默认频率 |
|---|---|---|
| 健康 | 云函数错误率、限流，环境 QPS，CLS 日志里的 429 和 5xx | 每小时 |
| 性能 | PostgreSQL 慢查询和连接数，云托管的 CPU 与错误率，日志里的超时 | 每小时 |
| 资源 | PostgreSQL 库大小、调用量相比上次的增长、套餐余量 | 每天 |
| 安全 | ACCESS_TOKEN_INVALID、401 / 403，存储 ACL 变更 | 每天 |
每条问题会给出三样东西：测到的值、对应的阈值、一个下一步动作。阈值用的是公开的解读基线——比如函数错误率 1% 算 warning、5% 算 critical——你也可以在对话里让它改。
关键是上报规则：只报新增或恶化的问题。一次运行只会报四种情况——没见过的问题、数值比上次涨超一半且仍超基线、级别升高的问题、上次能跑这次跑不了。全绿时只回一行「这段时间检查过这些项，没超基线」，不发表格。一次最多列 5 条，超过 5 条说明环境有普遍性问题，它会直接这么告诉你，而不是把三十行表格甩过来。
要做到「只报变差」，agent 得记住上次报过什么。这些状态写在项目根目录的 cloudbase-patrol-state.json 里，你可以把它加进 .gitignore。
连接器提供了哪些工具
巡检背后，是 CloudBase 连接器提供的四个查询工具，分工如下：
五个工具各管一摊：queryEnv 读时序指标，一次取一个指标；queryLogs 查跨服务的日志，用的是 CLS 语法，不是 SQL，但支持 select ... group by 聚合，一条查询就能定位到哪个函数在出错；queryPgDatabase 执行只读 SQL，查 pg_stat_activity 和 pg_database_size() 拿连接数和库大小；PG 的 CPU、磁盘、内存、慢查询这些指标不在 queryEnv 清单里，但控制台能看到的整套平台监控，用 callCloudApi 调云监控的 GetMonitorData（命名空间 QCE/POSTGRES）同样能拉到；queryFunctions 看单个函数的执行日志，一次最多覆盖一天、100 行。
还有一个前提：环境要先开通 CLS 日志服务。没开通时 queryLogs 会直接报错；开通了但没采集到某个来源，返回的是空。两种情况都容易被当成「没有错误」，所以每次巡检的第一步都是 checkLogService 确认日志可用。
三步把它跑起来
第一步：连接
复制这句话给你的 AI 工具，它会照着文档把 CloudBase 接好：
帮我把 CloudBase 接好，按下面做：
1. 打开 https://docs.cloudbase.net/skill.md，按说明完成接入。
2. 接入完成后告诉我，并建议最相关的下一步。
WorkBuddy 用户也可以直接点输入框左下角的「连接器」，搜 cloudbase，把「腾讯云 CloudBase」的开关打开，效果一样。
第二步：巡检一次
接好之后，先手动跑一遍，看看报告长什么样：
用 CloudBase 的 ops-inspector skill，巡检一下这个环境的健康状况
不用指定环境 ID，也不用说明先调哪个接口——skill 里都写好了。报告第一行是整体结论，后面每条问题带着测到的值和下一步建议。看完这份报告，再决定要不要排班。
第三步：定个时间，让它自己跑
觉得报告有用，就让它定时：
以后每天早上 9 点，用 ops-inspector 巡检一遍这个环境，只报变差的。
巡检报告整理成一页 markdown，发到我的邮箱。
报告去哪随你定：回对话、生成文件、发邮件、推到企业微信群，都可以。定时任务在后台跑，agent 中途没法找你确认，所以只给它读权限就够了——巡检本身也只需要读，发现问题它会写建议，然后停手。
一次真跑的结果
一个测试环境，24 小时窗口：
| 指标 | 结果 |
|---|---|
环境 QPS（GatewayTraceEnvQPS） | 峰值 21，均值 14.7 |
函数调用（FunctionInvocation） | 合计 100 次，峰值 17 / 小时 |
函数错误（FunctionError） | 合计 31 次，最差一小时 6 次 |
QPS 峰值 21，单看这个数字没什么问题。把后两行放在一起看：100 次调用错 31 次，错误率 31%。最差的一小时 17 次调用错 6 次，35%，发生在 10-22 18:00。
对着 1% / 5% 的基线，31% 不是「有点高」。
到这里，巡检只知道三分之一的请求失败了，还不知道错在哪。下一步查日志，范围立刻缩小：
function_name: user-login-register
status_code: 430
TypeError: First argument must be a string, Buffer, ArrayBuffer, Array...
at WXBizDataCrypt.decryptData (/var/user/WXBizDataCrypt.js:10:20)
31 次错误全部来自这一个函数、这一行——小程序解密用户数据的代码在拿非字符串的入参去解密。指标回答「哪段时间不对」，日志回答「哪一行不对」，两步就到了能动手改的地方。
第二天同一时间，巡检报告里这行消失了。你不需要去翻日志确认昨天改的东西有没有生效——它没再报，就是生效了。
