Cloudflare提出新的网站技能标准，类似robots.txt是网站结构的说明书，技能标准是基于.well-known/skills/的标准化技能发现机制，使AI智能体可自动获取网站发布的技能列表，并通过三级渐进加载高效使用技能内容，推动Agent Skills生态走向开放与自动化。
如何说robots.txt是告诉别人我有什么，那么skills是告诉别人我能干什么。
也就是说：Cloudflare搞了个叫“agent-skills-discovery-rfc”的草案，说白了，就是给所有网站装个“技能公告栏”，位置统一放在“.well-known/skills/”下面。
这样一来，AI智能体一进门就能看到：“哦！这家有PDF处理、表单填写、API调用……行，我记下了。”不用猜、不用搜、不用求人，直接开干。
这套机制的核心，是借用互联网早已存在的“.well-known”标准（RFC 8615），把“skills”注册成一个官方认可的后缀路径。
为什么需要这个 RFC
AI 智能体的 技能（Agent Skills） 是一种模块化格式，用于扩展代理能力——这些技能包含结构化的说明、元数据和可选的可执行脚本，帮助智能体处理特定任务（如解析 PDF、调用工具 API、自动化流程等）。它们最初作为开放标准实现，广泛被多个平台采用。
目前，这些技能分散在 GitHub、文档站点或开发者网上资源中，智能体无法预测某个组织有哪些技能，必须手动查找。这个 RFC 就是为了解决 “我怎样让智能体自动发现某个域名下有哪些技能？” 这个问题。
RFC 核心概念
1. 使用 Well-Known URI 进行技能发现
该提案定义了一种基于 well-known URI 的技能发现路径：
https://example.com/.well-known/skills/
这个路径成为一个标准的、可预测的位置，用来列出该域名公开的所有技能。智能体及其工具链可以根据这个 URI 自动获取技能目录，而无需人工配置。
这个草案规定，每个支持技能发现的网站，必须在根域名下建一个固定路径：/.well-known/skills/。
2. 技能目录结构
在规范中，技能按如下目录结构组织：
/.well-known/skills/ |
这个路径里头，第一个必须有的文件是index.json。这个文件可不是随便写的，它是个“技能总目录”，列出了该网站发布的所有技能名称、简短描述，可能还有版本号或标签。比如，里面可能写着“pdf-processing：从PDF中提取文本和表格”、“cloudflare-deploy：一键部署到Cloudflare Workers”。有了这个清单，AI智能体启动时，只要访问一次这个JSON文件，就能快速扫描出有哪些技能可用，而不用一个个点进去看。
每个技能名字也不是随便起的，必须符合严格规则：长度1到64个字符，只能用小写字母、数字和短横线，不能以短横开头或结尾，也不能连着两个短横。比如“pdf-extract”合法，“PDF_Extract”就不行，“-bad-name-”也不行。
这种命名规范确保了路径的稳定性和可解析性，避免各种奇怪符号导致系统崩溃。每个技能名字对应一个子文件夹，比如/.well-known/skills/pdf-processing/，里面必须包含一个叫SKILL.md的文件，这是技能的“说明书”。
SKILL.md是每个技能的核心，它不是一篇随随便便的博客，而是一个结构化文档。开头必须有一段YAML格式的元数据，用三个短横线包围，里面至少包含name和description两个字段。比如：
name: pdf-processing
description: 从PDF文档中提取结构化文本、表格和元数据
接着才是真正的Markdown正文，详细说明这个技能怎么用、适用什么场景、输入输出格式是什么。这部分内容可以很长，但草案建议控制在5000个token以内，毕竟AI上下文窗口有限。
除了SKILL.md，技能文件夹还可以包含scripts/、references/、assets/等子目录：
scripts/里放可执行代码，比如extract.py，AI在需要时可以直接调用；
references/放补充文档，比如REFERENCE.md，解释技术细节或边界案例；
assets/则放模板、示例文件或JSON Schema。
这些资源不是一开始就加载的，而是按需拉取，大大节省了内存和计算资源。整个结构清晰得像乐高积木，主模块+扩展包，想用哪块拿哪块。
三级加载机制：先看菜单，再点菜，最后上配菜，绝不浪费AI的“脑容量”
最聪明的设计在于“渐进式披露”（Progressive Disclosure）策略。
AI智能体不会一上来就把所有技能内容塞进脑子里，那样会撑爆上下文窗口。
它分三步走：
第一步，只读index.json里的name和description，大概每个技能花100个token左右，相当于快速扫一眼菜单，知道店里有什么菜；
第二步，当用户提出一个任务，比如“帮我从这份PDF里抽表格”，AI发现“pdf-processing”技能描述匹配，就去下载对应的SKILL.md全文，把详细指令加载进来，这时候才真正理解怎么做；
第三步，在执行过程中，如果任务需要更复杂操作，比如要按特定格式填充表单，SKILL.md里可能写了一句“参考references/FORMS.md”，AI这时才去拉取那个文件。
这种“用多少拿多少”的机制，让技能可以打包海量参考资料而不影响启动速度，既灵活又高效。一个技能可以包含60个参考文件，但99%的任务可能只用到其中1个，其他99%的资源安静躺在服务器上，绝不拖累AI的思考。
意义与适用场景
自动化发现技能：智能体不再需要手动配置各个技能位置，只要目标网站遵循规范就能自动发现。
标准化技能生态：有助于形成一个统一的技能注册与发现生态，与现有的 Agent Skills 开放标准协同。
可扩展结构：技能目录支持脚本、参考文档等扩展内容，使技能更具实用性。
Cloudflare这套方案相当于给每个组织建了一个标准化的“技能公告板”，所有能力公开透明、位置固定。这对构建企业级AI代理系统尤其关键。
比如，一个客服AI代理接入公司系统后，自动发现/.well-known/skills/下有“订单查询”“退换货处理”“发票生成”三个技能，立刻就知道自己能做什么。
如果Claude、Copilot、OpenCode等平台支持这个标准，就能无缝集成任何遵循规范的第三方技能，形成真正的开放生态。
Cloudflare自家的技能包包含60多个产品文档，覆盖Workers、Pages、Durable Objects等复杂平台，如果没有这种结构化发现机制，AI根本没法驾驭如此庞大的知识体系。这套草案虽是草稿，却为AI代理的规模化协作铺平了道路。
草案当前状态：还在征求意见，但方向已定，未来可能成为行业基础设施
目前这个RFC标记为“Draft 0.1”，发布于2026年1月17日，说明它还在早期讨论阶段，尚未成为正式标准。
但它的设计思路非常务实：复用现有互联网标准（.well-known URI）、采用轻量级JSON+Markdown格式、强调向后兼容和渐进加载。
这些特点让它很容易被社区接受。一旦成熟，它可能像robots.txt或security.txt一样，成为网站的标准配置之一。
对开发者而言，实现成本极低：只需在Web服务器上配置一个静态路径，放几个文件即可。对AI平台而言，只需增加一个HTTP客户端，定期轮询目标域名的/.well-known/skills/index.json，就能动态更新技能库。这种低门槛、高回报的特性，正是它有望快速普及的关键。