说实话，第一次在 Smithery 上看到 Cloudflare 这个 Skill 的时候，我的第一反应是”这不就是个文档索引吗”。它声称覆盖的产品线光是列出来就够让人窒息的：
计算：Workers、Pages 存储：KV、D1、R2 AI：Workers AI、Vectorize、Agents SDK 网络：Tunnel、Spectrum 安全：WAF、DDoS IaC：Terraform、Pulumi
但翻了几遍它的 SKILL.md 之后，我意识到自己搞错了一件事。它的核心价值不是”把这些产品的用法都教给你”，而是在你不知道该用什么产品的时候，用一组决策树把你推到正确的方向上。它解决的不是技术实现问题，是选型时的决策成本。
Cloudflare 平台现在的产品数量已经超过 30 个。对新人和中等经验的开发者来说，最大的障碍从来不是某个产品本身很难上手，而是在这么多选项中不知道该走哪条路。这个 Skill 的设计思路是把最常遇到的 7 类需求整理成 7 个决策树，按场景匹配产品、按需加载子 Skill 的详细知识。
说真的，这篇文章不打算把每个子产品都翻一遍，那等于把 Cloudflare 的文档照抄了一遍。我就想聊一聊这个 Skill 是怎么用一个 SKILL.md 把整个平台串起来的，决策树这个设计为什么在 Agent Skill 的语境下特别对，以及这种”平台级 Skill”的天然边界在哪。
环境准备
Cloudflare Skill 的安装不复杂，但前提是你得有一个支持 Agent Skill 标准的 AI 编程工具。目前主流选项包括 Claude Code、Cursor、OpenAI Codex 和 Pi，各自的安装路径略有差异。
Claude Code 用户最省事，直接从插件市场添加：
/plugin marketplace add cloudflare/skills
/plugin install cloudflare@cloudflare
用 npx skills 的话一行命令也能搞定：
npx skills add https://github.com/cloudflare/skills
Cursor 用户可以在设置里找到 Rules，选 Add Rule 后切到 Remote Rule (Github)，填入 cloudflare/skills。这几种安装方式本质上都是在 Agent 的技能目录下创建一个指向 Cloudflare 仓库的引用。
装好之后，还有一个容易被跳过的步骤：认证。Skill 不会自动帮你登录 Cloudflare 账号，任何涉及 wrangler deploy 的操作都需要你提前验证身份。本地开发直接跑一次 npx wrangler login 就行，走的是浏览器 OAuth 流程。CI/CD 环境则需要设置 CLOUDFLARE_API_TOKEN 环境变量，用 API Token 做无交互认证。
有一个细节挺值得注意：这个 Skill 不只是被动被 Agent 加载，它还带了两条用户可以直接调用的 slash command。安装后你可以在对话里输入 /cloudflare:build-agent 来搭建一个 AI Agent 项目，或者 /cloudflare:build-mcp 来创建一个 MCP 服务器。这个设计让 Skill 从”查资料的参考书”变成了”能帮你执行操作的工具”，两者的体验差别不小。
操作流程
Cloudflare Skill 的工作方式跟大多数 Skill 不太一样。它不会一次性把所有产品文档都塞进上下文，而是用决策树做入口层，按需加载。
整个流程大体上是三步：
-
需求匹配：你告诉 Agent 你想做什么，Agent 把你的需求跟 7 个决策树做匹配。比如你说”我想给我的应用加个数据库”，Agent 会自动走到”存储数据”那棵决策树上 -
范围收窄：决策树根据你的描述进一步缩小范围，从 KV、D1、R2、Queues、Vectorize 这些选项中挑出最匹配的两个 -
知识加载：Agent 加载对应的子 Skill 详细 reference，开始给你具体的操作指导
这套机制的聪明之处在于，它把认知负担从”你需要了解 30 个产品才能选对”降到了”你只需要说清楚你想干什么”。Agent 负责把需求翻译成正确的产品名称，然后从子 Skill 库里拉出对应的知识。整个过程你几乎感觉不到 Skill 的存在，它不像一个工具，更像一个懂 Cloudflare 产品矩阵的同事在你旁边说”你这个场景应该用 D1 而不是 KV，因为你需要 SQL 查询能力”。
不过有一个场景它处理得不够好：如果需求同时跨了多个决策树，Agent 需要自己做上下文拼接。比如你要搭一个”有 AI 推理能力的全栈应用”，这个需求同时触发了”运行代码””存储数据”和”AI/ML”三棵树，每棵树指向不同的子 Skill。Agent 能不能把这三条路径的知识串成一个完整方案，很大程度上取决于底层模型的推理质量，Skill 自身没有提供跨树的组合逻辑。
关键设计
拆开这个 Skill 的结构之后，我觉得有两个设计决策特别值得聊：一是决策树而不是全文注入，二是子 Skill 引用而不是全部内置。
先说决策树。Cloudflare 平台的产品太多了，如果这个 Skill 把所有产品的详细文档都写在一个 SKILL.md 里，保守估计也会有三四千行。一次性注入到 Agent 上下文里，Token 浪费还在其次，更致命的是模型注意力会被分散，关键指令淹没在大段文档里。决策树做前置过滤，每次只加载真正相关的产品 reference，上下文始终可控。
再说子 Skill 引用。这个 Skill 不是孤立的，它属于一整个 Cloudflare Skill 家族。除了主 Skill cloudflare，还有几个独立子 Skill：
-
agents-sdk：构建有状态 AI Agent 的完整指南 -
durable-objects：有状态协调、RPC、WebSocket 的深入参考 -
sandbox-sdk：安全代码执行环境 -
wrangler：CLI 部署和管理工具 -
web-perf：Web 性能审计
主 Skill 的决策树指向的是这些子 Skill，每个子 Skill 维护自己领域的专业深度和最新实践。
这种”联邦式”架构有几个明显的好处。每个子 Skill 可以独立更新，agent-sdk 加了几页新文档不影响 wrangler 那一部分。每个子 Skill 也可以独立深度发展，不用担心把主 Skill 撑爆。但反面也得说清楚：如果子 Skill 更新了接口或最佳实践，而主 Skill 的决策树推荐路径没有同步调整，就会出现”路径能通但内容过时”的情况。这是分布式知识维护的经典问题。
还有一个设计容易被忽略：这个 Skill 不只是”文档”，它还配了一套 MCP 服务器。cloudflare-api 能直接操作你的 Cloudflare 资源，cloudflare-docs 能拉最新文档，cloudflare-observability 能读日志和监控数据。Skill 负责导航和知识，MCP 负责执行，两层的分工很清晰。这种”Skill + MCP”的组合，比单纯的参考手册式 Skill 实用得多。
使用场景
Cloudflare Skill 最直观的场景，是带刚接触 Cloudflare 平台的人穿越”产品迷宫”。Cloudflare 有 30 多个产品，排列在导航栏里的感觉就像机场的航班信息牌，知道有这些选项但不知道该选哪个。
但我认为更实用的场景其实是增量选型。你已经用了 Workers 处理 API，现在需要加一个数据库，KV 和 D1 到底选哪个。文档会告诉你 KV 是键值存储适合配置和缓存、D1 是关系型数据库适合结构化查询，但它不会根据你现有的 Workers 架构给你推荐。Skill 的决策树能在这个场景下帮你快速缩到两个选项，你再针对性地做深入对比。
还有一个让我比较意外的用法：slash command 的脚手架能力。/cloudflare:build-agent 这条命令本质上是一个结构化的项目创建工作流，Agent 会引导你逐步完成：
-
创建项目目录结构 -
配置 wrangler.jsonc 的 AI binding -
设置 RPC 通信链路 -
处理持久化状态
对于还没摸过 Cloudflare Agents SDK 的人来说，这比先啃几十页文档再写第一行代码快了至少一个数量级。
当然也得说实话，这个 Skill 有一个明确的边界：它不是”怎么调参”类的 Skill。如果你已经知道自己要用 Workers AI，只是不确定模型参数怎么设、最佳实践是什么，决策树这一步对你来说是多余的。这时候直接跳到 workers-ai 子 Skill 或者官方文档更高效。它的价值在”我应该用什么”这个环节，不在”这个怎么用”那个环节。
洞察与反思
Cloudflare 做这个 Skill 的动作本身，我觉得比这个 Skill 更有信息量。它传递了一个挺清楚的信号：大型技术平台在 Agent 时代的竞争力，不再是文档写得有多好，而是文档能不能被 Agent 直接消费。
传统文档是为”人读”优化的，有侧边栏、有搜索框、有目录树。Agent 读文档的方式完全不同，它需要的是结构化的决策路径和可引用的知识片段。Cloudflare Skill 的决策树加 references 架构，本质上就是把”给开发者看的导航页”翻译成了”给 Agent 用的路由逻辑”。
顺着这个思路往下想，我觉得未来每个大型技术平台都需要一个”Agent 友好层”。它不只是 API 文档的 Markdown 版本，而是把产品选型逻辑、场景匹配规则和常见踩坑经验这些隐性知识显性化，变成 Agent 可以执行的推荐路径。Cloudflare 是第一批认真做这件事的平台之一，而且是用 Agent Skill 这个开放标准做的，不是自己搞个封闭格式。
但这里也有一个绕不开的结构性问题。平台方自己写 Skill，天然有推广自家产品的倾向。决策树告诉你的永远是 Cloudflare 生态内的最优解，但它永远不会告诉你”这个场景用 Supabase 可能比 D1 更合适”。这本身不是错误，一个 Cloudflare Skill 推荐 Cloudflare 产品天经地义。但作为使用者你得清楚：Skill 是一个有预设立场的导航员，不是一个没有立场的百科。
这也引出另一个问题：当 Agent 越来越依赖这类平台级 Skill 时，它的技术选型视野会不会被 Skill 的推荐路径限制住。Skill 的边界就是 Agent 认知的边界，这个风险不局限于 Cloudflare，而是所有平台级 Skill 的共同挑战。
资源地址
| 资源 | 地址 |
|---|---|
| Smithery | https://smithery.ai/skills/cloudflare/cloudflare |
| GitHub | https://github.com/cloudflare/skills |
| 安装指南 | https://skillsclaude.com/guides/skills/cloudflare |
总结
Cloudflare Skill 做对了一件事它没有试图把 30 个产品的用法塞进你的脑子里，而是帮你搞清楚你应该用哪一个。这个取舍在 Agent Skill 的设计里是一个值得重视的分水岭。
如果你刚开始接触 Cloudflare 平台，或者正在一个项目里纠结 Workers 还是 Pages、KV 还是 D1 这类选型问题，装上这个 Skill 能让对话省掉不少试错。如果你已经很清楚自己要什么了，直接跳子 Skill 或官方文档更干脆。
但说回来，这个 Skill 让我最感兴趣的其实不是它本身好不好用。它让我看到了文档的一种新形态的可能性，不是更长的 README、不是更炫的交互式教程，而是一套能被 Agent 理解和执行的决策逻辑。这个方向如果能走下去，文档的价值衡量标准就不再是”写得有多好”，而是”Agent 能从中提取出多少正确的行动建议”。