Cloudflare Skill + GitHub Skill：让 Agent 进入真实运维闭环

让 coding agent 真的去操作线上环境——改 Worker 配置、读 GitHub Actions workflow、触发部署、验证结果——这件事放在半年前我是不敢想的。

但最近试下来，Cloudflare skills 加 GitHub skill 拼在一起，基本上把这条路走通了。

我平时用 Cloudflare 的地方很多：域名、DNS、Pages、Workers、D1、KV、R2、cron trigger、AI binding，还有 GitHub Actions 到 Cloudflare Workers 的自动部署。Cloudflare 的产品线很强，但也有一个很现实的问题：出问题的时候，不是“查一下文档”就能解决，而是要真的改配置、触发部署、读日志、确认线上状态。

同一个目标，可能要在 Dashboard、Wrangler、REST API、GitHub Actions、项目配置文件之间来回跳。只要中间出了一个小错误，比如 Worker 少了一个 D1 binding，或者 workflow 里初始化步骤拿不到正确的 workers.dev URL，就会开始进入经典环节：查文档、翻 Dashboard、找 API endpoint、猜字段名、试 Wrangler 命令。

所以我想聊的不是“Agent 怎么更懂 Cloudflare”，而是 Cloudflare skill + GitHub skill 组合在一起时，Agent 怎么从一个聊天助手变成能跨系统完成真实操作的东西。

它不是一份简单提示词

Cloudflare 这个 skills 仓库不是那种“告诉 AI 你是 Cloudflare 专家”的薄薄一层 prompt。它更像一套给 coding agent 用的操作手册和索引。

里面把 Cloudflare 的产品按任务拆开了：

• 要跑代码：Workers、Pages、Durable Objects、Workflows、Containers。
• 要存数据：KV、D1、R2、Queues、Vectorize。
• 要做 AI：Workers AI、Vectorize、Agents SDK、AI Gateway。
• 要处理网络和安全：Tunnel、WAF、DDoS、Turnstile。
• 要做运维和自动化：Wrangler、API、Terraform、Pulumi、Observability。

这个分类对人也有用，但对 agent 更有用。因为 agent 最怕的不是“不知道 Cloudflare 是什么”，而是不知道下一步该查哪条路径、该用哪个产品、该调用哪个 endpoint。

有了 skill，agent 会先把需求归类，再去找对应的参考资料和 API。它不会一上来就凭记忆硬写配置，也不会在 Workers、Pages、D1、KV、R2 之间乱跳。

Agent 不再凭记忆硬写——它知道先看 Spec

随手试了一下让 agent 查域名。以前做这种事，要么自己去 Dashboard 点几层，要么让 agent 猜 API endpoint。Cloudflare 的 API 面很大，“列出 zone”这种看起来简单的事情，也可能被一堆 account、zone、audit log、firewall、certificate endpoint 淹没。

用了 skill 之后区别很明显：agent 先加载 skill，再通过 API MCP 搜索 OpenAPI spec，找到接口定义，然后执行查询。重点不是它查到了什么，而是它知道“应该先找接口定义”。这让操作从“凭经验猜”变成了“按 spec 走”——写配置、改 binding、读部署状态都遵循同一个原则。

但查域名终归只是读操作。真正让我有感的，是一次需要 agent 动手改东西的场景。

一次 Worker 配置修复：Agent 不再是旁观者

一个部署在 Cloudflare Workers 上的服务报错：D1 查询里缺字段，Worker 运行不正常。更麻烦的是，这不是单纯改一行代码就能解决的事，它牵涉到 Worker 绑定、D1、KV、R2、cron trigger，以及 GitHub Actions 的部署流程。

这类问题如果手动排查，路径会很散：

• 看 Worker 当前部署版本。
• 看 D1 表结构和 migration。
• 查 Worker settings 里的 bindings。
• 确认 KV、D1、R2 是否还绑定在正确位置。
• 看 GitHub Actions 的部署日志。
• 判断是代码问题、数据库问题，还是部署流程把绑定覆盖掉了。

这次 agent 借助 Cloudflare skill 和 API 工具，直接把排查路径串起来了：先看 Worker settings，再确认 deployments，再查 binding 状态，最后定位到 D1/KV/R2 绑定缺失或被部署流程覆盖的问题。接着它不是停在“建议你去控制台改一下”，而是直接修改 Worker 配置，把缺失的 binding 补回去，并验证新版本已经部署，100% 流量指向修复后的版本。

这一步的核心变化是：agent 不是在对话里给你排障建议，而是通过 Cloudflare API 真实地读了 Worker settings、查了 deployments、改了 binding 配置、触发了新版本部署，最后还验证了线上状态。它完成了一次完整的线上变更操作，中间没有跳回 Dashboard，没有停下来问“要不要我帮你执行”。

GitHub Skill 把另一半补上了

Cloudflare 这边修完后，还有一个问题：如果 GitHub Actions 下一次部署又把配置覆盖掉怎么办？

这时 GitHub skill 接上了另一半链路。agent 读取仓库里的 workflow，理解 GitHub Actions 是怎么 deploy Cloudflare Worker 的，然后直接修改 .github/workflows 里的部署逻辑。它处理了几个实际坑：

• GitHub Actions 里 workers.dev URL 被当作 secret masking，导致 output 不可靠。
• 初始化步骤重复执行时会返回 500，让一次已经成功的部署被标红。
• workflow 触发条件没有覆盖配置文件自身修改，需要手动触发一次验证。
• 部署后还要回到 Cloudflare 侧确认 Worker settings、binding 和 latest deployment。

也就是说，这次不是 Cloudflare skill 单独完成任务，也不是 GitHub skill 单独完成任务，而是两个 skill 拼出了完整运维闭环：

1. Cloudflare skill 负责理解和操作 Worker、D1、KV、R2、cron、deployment——真实读状态、真实改配置。
2. GitHub skill 负责读取 workflow、修改 action、提交推送、触发 CI 并观察 run。
3. 最后再回到 Cloudflare API 验证线上 Worker 的真实状态——确认变更落地。

这就非常接近我理想里的 agent ops：不是只会聊天，不是只会写代码，而是能跨系统读状态、改配置、跑部署、看结果。

Cloudflare 的难点是“入口太多”

Cloudflare 平台本身不是难在单个功能复杂，而是入口太多、产品边界多。

比如一个 Worker：

• 代码可能由 Wrangler 部署。
• 环境变量和 binding 可能在 Dashboard 或 wrangler.toml。
• D1 migration 可能在项目脚本里。
• KV namespace 和 R2 bucket 是独立资源。
• cron trigger 又在 Worker settings 下。
• GitHub Actions 可能还有一套生产部署逻辑。

当问题发生时，你真正需要的不是“Cloudflare 百科全书”，而是一张操作地图：现在在哪个层面，下一步该看哪个资源，用什么方式读，什么动作是只读验证，什么动作会改生产。

Cloudflare skill 正好补上了这张地图，而 GitHub skill 则把“代码仓库和自动化流水线”这半张地图也接了进来。

对 Agent 来说，Skill 是上下文压缩

我现在越来越觉得，skill 对 agent 的意义不是“增加知识”，而是“压缩上下文”。

没有 skill 时，你得在对话里解释：

我这个是 Cloudflare Worker，用 D1/KV/R2，有 GitHub Actions 部署，可能要查 settings 和 deployments，不要乱动生产，先读状态。

有 skill 后，这些会变成 agent 的默认工作流：先识别产品，再找对应参考，再做只读检查，再决定是否执行变更。配合 GitHub skill，它还会自然地去读 workflow、看 run、查日志、提交修改、触发验证。

这对 Cloudflare 这种平台尤其重要。因为它的能力散布在很多地方：Dashboard、Wrangler、API、Workers runtime、GitHub Actions、各种 binding。skill 把这些散点连成了一条可执行路径。

以后，让 Agent 帮你跑完整个运维闭环

这次试完，我最大的感受是：Cloudflare skill + GitHub skill 组合起来，agent 能做的不再是“AI 帮我查资料”或者“AI 帮我写段代码”，而是“AI 帮我完成一次真实操作”。

文档是给人读的，API spec 是给程序读的，而 skill 是给 agent 做事用的。它既不像文档那样只解释概念，也不像 SDK 那样只暴露函数；它告诉 agent 在真实任务里应该怎么选路、怎么读状态、怎么改配置、怎么验证。

Cloudflare 这个 skill 目前已经覆盖了 Workers、Pages、D1、KV、R2、Workers AI、Vectorize、Agents SDK、Wrangler、Terraform、Pulumi 等常用路径。再配合 GitHub skill 和 Cloudflare API MCP，agent 的完整闭环就变成了：

1. 查状态——通过 Cloudflare API 读 Worker settings、deployments、bindings。
2. 改配置——修改 Worker 绑定、环境变量、cron trigger。
3. 修流水线——读 GitHub Actions workflow，修复部署逻辑。
4. 触发布署——推送代码，触发 CI，观察 run 结果。
5. 验证线上——回到 Cloudflare API 确认新版本已上线，流量正确。

以后操作 Cloudflare，不一定要先打开 Dashboard 到处找了。把目标说清楚，让 agent 带着 Cloudflare skill 和 GitHub skill 走一遍这五步。对于日常 ops 来说，这已经不是“AI 帮我查资料”，而是“AI 帮我完成一次真实操作”。