terms.txt 协议：AI 抓 28.6 万页仅换 1 次点击，网站可按用途收费
AI 抓 28.6 万页才带回 1 次点击，开放网络的账先倒挂了
你向 AI 助手问一句"这家店靠谱吗"。在平台级统计账上，爬虫请求几十万页网页，才给站点带回一次访问。网站主看得见这一串串爬虫请求，却几乎看不见任何回报。开放网络默认过一笔老交易：内容公开可爬，爬虫带走内容，也把点击流量引回来。如今这笔账彻底倒挂了。
先看一个指标，Crawl-to-Refer（爬取-回访比）：一个平台的爬虫每请求多少页 HTML，才为站点带来 1 次页面访问。传统搜索引擎常年稳在 5:1 附近，爬 5 页能带回 1 次回访，这在站长眼里是划算的引流。Anthropic 的爬虫呢？2025 年 1 月是 286,000:1，7 月降到 38,000:1，2026 年 6 月底约 4,600:1，7 月跌破 2,000:1。就算按改善后的数字，爬两千页才换来 1 次回访，和搜索引擎的 5:1 差着三个数量级。标题里那句"抓 28.6 万页仅换 1 次点击"，说的就是峰值时点的比值。
| 平台 | 2025年1月 | 2025年7月 | 2026年6月底 | 2026年7月 |
|---|---|---|---|---|
| Anthropic（Cloudflare 自报） | 286,000 : 1 | 38,000 : 1 | 约 4,600 : 1 | 低于 2,000 : 1 |
| 传统搜索引擎（参照） | 常年约 5 : 1 |
这些数字全部来自 Cloudflare Radar 自报口径，论文转引时自己都提醒：不同窗口的比率不可直接比较，也没有单独切分出 AI 代理流量。但量级足以说明问题。同一数据源 2026 年 6 月：其网络内 HTML 页面流量 57.5% 为自动化；在 Cloudflare 分类的 AI 爬虫请求中，训练类占 52%、混合用途爬虫超 36%（分母不同，论文注明不可直接相加）。Imperva（Thales）2026 年《Bad Bot Report》称，自动客户端在其客户网络流量中（含 API 请求）2025 年占比超过 53%。
"爬虫多吃多占"不只是 Cloudflare 这家"卖解药的公司"的一面之词。2024 年有一项独立学术审计，用 Wayback Machine 的月度快照扫了 14,000 个域名、时间跨度 2016 到 2024 年，观察 robots.txt 和服务条款对 AI 爬虫的限制如何爬升。下面的图就来自这项审计，图中能清楚看到 2023 年 ChatGPT 等事件之后，限制比例如何陡峭上扬。
图注：2016 至 2025 年时间轴上三幅纵向堆叠图。上图是 robots.txt 对 AI 爬虫的限制比例，中图是服务条款（ToS）限制，下图为按机构分组的限制率，图例列出 2024 年 4 月各机构数值。2024 年后的灰色区域是 SARIMA 预测，不是实测。Consent in Crisis
审计的结论数字是：一年之内，也就是从 2023 年 4 月到 2024 年 4 月，整个语料库里被 robots.txt 限制的 token 从近乎为零涨到 5% 以上，最活跃的那批头部域名里超过 25%；被服务条款限制的 C4 语料占 45%。增幅是 500% 以上。Consent in Crisis
流量被爬走只是半边账，另半边是用户的点击也在消失。Pew Research 2025 年 7 月的观测：Google 结果页出现 AI 摘要时，用户点击传统结果的比率是 8%，没有摘要时是 15%；26% 的用户看完摘要直接结束会话，无摘要时是 16%。Pew 明确声明这不构成因果证明，方法是对 900 名美国成年人的 68,879 次真实搜索重放记录。但方向是一致的：AI 把答案直接端到用户面前，网页充其量成为脚注。
把这些拼在一起，就是这篇论文的出发点：开放网络的分账逻辑已经被 AI 代理打破。这不是道德争论，而是可以量化的失衡。terms.txt 站点主想对这串请求说点什么，却发现手里那把用了三十年的钥匙根本拧不动锁。下一章看它到底缺什么。
robots.txt 用了 30 年，为什么 AI 一来就不够用
管爬虫的规矩三十年没变过。1994 年 Martijn Koster 提出 robots.txt，2022 年 IETF 把它正式化为 RFC 9309。词汇表只有三件套：user-agent 声明是哪个爬虫，allow / disallow 决定放行还是禁止，路径前缀圈定哪一段 URL。整套协议用"路径 × 客户端身份"两个轴描述一切，没有任何字段能回答"你拿我的内容去干嘛"。
反常的是，标准文本自己把话说得很白。RFC 9309 开篇就写：These rules are not a form of access authorization（这些规则不是一种访问授权形式）。RFC 9309 也就是说，协议层就承认它只是偏好信号，执行全靠爬虫自觉。这份词汇表表达不出的，恰好是 AI 时代最要紧的四个问题：目的、价格、身份、委托。
| robots.txt 能说的 | AI 时代问不出口的 |
|---|---|
| user-agent：声明你是谁 | 目的：训练 / 索引 / 实时回答，词表里没有 |
| allow / disallow：让不让爬 | 价格：能爬，但每种用途不同价 |
| 路径前缀：哪一段 URL | 身份：谁能证明这份声明是真的 |
| （没有第四个了） | 委托：用户授权的代理 vs 来路不明的爬虫 |
表达力不足只是第一层，论文接着诊断出四个失败模式。第一，政策自相矛盾。审计发现 35.1% 的网站写了反爬服务条款却没有 robots.txt，另有 20.3% 反过来：没有 ToS 却有部分限制的 robots.txt，两个渠道经常互相打架。第二，格式被要求干它干不了的谈判。Cloudflare Radar 的指令分析发现，GPTBot 既是明文禁止最多的 AI 爬虫，也是明文允许最多的 AI 爬虫。同一个格式既当禁令又当通行证，说明人们正拿 robots.txt 做协商，而它没有协商的语法。第三，不被可靠遵守。2025 年 8 月 Cloudflare 记录到 Perplexity 在被明确禁止的站点上，改用未声明的 user agent 和轮换的网络来源继续抓取。这套机制的前提是客户端如实自报身份，而"自觉声明"恰恰是最脆弱的一环。第四，一刀切误伤。超过三分之一的被分类爬虫请求来自混合用途机器人，一条"禁训练"规则同时把站点从搜索引擎的发现里抹掉了。
顺着这条路，ai.txt 把声明做成了更细的 DSL 语法，用动词表规定"能不能总结、能不能改写"，但论文自己承认它是 declared rather than enforced（声明而非强制）。ai.txt 整个文本声明家族都卡在同一堵墙上：文件写得再漂亮，守不遵守全看对方。
所以这篇论文的诊断很锋利：robots.txt 缺的不是有人去执行它，而是它的词汇表根本说不出"目的"和"价格"这两个词。既然旧协议说不出口，AI 时代有没有现成能说出口的东西？
身份、目的、定价都有人做了，缺的是哪一格
要回答这个问题，得先看一张全图。论文把现存机制排成一张坐标表，九个方案横跨六个维度：身份、目的、条款/价格、委托、执行位置、状态。简化后的关键行如下：
| 机制 | 身份 | 目的 | 条款/价格 | 委托 | 执行位置 | 状态 |
|---|---|---|---|---|---|---|
| robots.txt | 无 | 无 | 无 | 无 | 无，仅建议 | RFC 9309 |
| ai.txt / llms.txt | 无 | ai.txt 有动词表 | 无 | 无 | 无，仅偏好 | 社区提案 |
| AIPREF 词表 | 无 | train-ai / search | 无 | 无 | 无，章程排除执行 | IETF 草案 |
| Content Signals use= | 无 | 部分（use 层级） | 无 | 无 | 无，仅偏好 | 厂商约定 |
| Web Bot Auth | 有 | 每机器人一张卡 | 无 | 无 | origin 或代理 | IETF 工作组草案 |
| Pay Per Crawl | 有 | 按机器人分类 | 按次定价 | 无 | 仅代理（Cloudflare 网络内） | 商用 beta |
| terms.txt | 有 | 每次请求签名声明 | 按路径和用途 | 有 | 任意 origin | 本论文 |
另外还有两条不碰源站的代理侧路线：基于 Forwarded 头的逐跳传递信任，以及走 402 的网关方案 Fairfetch。
过一遍这张表，三个结论浮出来。第一，身份验证已经在标准化路上。IETF 的 Web Bot Auth 工作组在 2026 年 9 月 1 日把协议草案接管为工作组文档，走 Standards Track 路径，起草人来自 Cloudflare 和 Google 两家头部运营商。注意这是"被工作组采纳的草案"，不是已发布的 RFC。它的做法是在 RFC 9421 消息签名之上加一层 profile：请求带一个 Signature-Agent header 声明操作员是谁，源的公钥放在固定位置的 JWKS 目录里，验证方按需解析。Web Bot Auth
图注：Web Bot Auth 整体架构。左侧 User 框中内嵌 Agent，向右侧 Origin 发出带签名的请求与 URL；图下方是 Directory（密钥目录），Agent 向其发布（publishes）公钥，Origin 向其解析（resolves）验证密钥。Web Bot Auth
第二，目的词表也在标准化。AIPREF 工作组把用途收敛成两个核心标签：train-ai 表示训练模型，search 表示建索引并引荐回访，并且明确不含生成摘要。标签序列化成一个字符串，比如 train-ai=y, search=n。AIPREF 但它的章程明确排除了强制执行、爬虫认证、注册中心和审计，等于只管"说"，不管"验"。第三，凡是能强制的，都绑在代理上。Cloudflare 的 Pay Per Crawl 把 HTTP 402 状态码做成了商用计费，但它生效的前提是流量穿过 Cloudflare 网络；同样在根目录放文本文件的 llms.txt 则只管内容索引、根本不碰访问控制。llms.txt
拼图都齐了，唯独"源站自己能在 HTTP 边界强制执行"这一格是空的。Web Bot Auth 草案的 Section 4.6 明确把授权、委托和意图词表划在工作组范围之外，等于亲手把这一格空出来。要填它，得先回答一个问题：一条请求里，网站怎么知道你是谁、来干嘛、愿付多少？
一条 HTTP 请求，怎么装下同意与付费
terms.txt 的答案由两件套组成：一个声明文件，加六个 header 的签名交换。声明文件放在 /.well-known/terms.txt，风格和 robots.txt 一样，抓一次顶很久。它是发现层，把规条写到明面上；真正的强制发生在 HTTP 边界，那是执行层。论文给出了一份完整示例：
# /.well-known/terms.txt
Terms-Id: 2026-09-01
Receipt-Keys: https://origin.example/.well-known/http-message-signatures-directory
Payment: voucher https://settle.example/.well-known/settlement
Path: /articles/
Unsigned: allow
Purpose: search allow use=reference
Purpose: agent allow use=reference delegation=read:articles
Purpose: train-ai charge 0.002 USD/request
Purpose: archive allow use=full
Path: /premium/
Unsigned: challenge
Purpose: agent charge 0.01 USD/request use=reference delegation=read:premium
Purpose: train-ai deny
文件头三行是全局信息：Terms-Id 是版本号，Receipt-Keys 指向源站的验签公钥目录，Payment 列出可接受的付款方式。每个 Path 块按路径声明规则：Unsigned 决定没签名的请求怎么办，放行或者弹出签名挑战。之后每一行 Purpose 绑定一种用途的处置，放行、按单价收费（charge）还是拒绝（deny）。可选的 use= 限制内容使用深度，delegation= 圈定委托代理的作用域。用途词汇直接对齐 AIPREF 的标签。
为什么按用途分开？因为它区分四类客户端，它们的账完全不同。训练爬虫来构建模型，搜索爬虫来建索引、顺带引流，服务型代理替某个服务实时取内容，比如回答引擎，用户委托代理替某个人取内容。这四类客户端的价值交换不同，站点可分别决定免费、收费或拒绝；用户委托代理还可继承用户权益。
请求端怎么把这些声明绑定到一次真实的访问？六个 header：Signature-Agent 声明操作员是谁，Signature-Input 和 Signature 是 RFC 9421 的消息签名，Access-Intent 是用途声明，Access-Delegation 是委托令牌，Access-Payment 是付款凭证。RFC 9421 签名覆盖请求方法、主机、路径、操作员标识和意图头，有效期五分钟，带一次性 nonce 防重放。要点是：terms.txt 没有发明任何新密码学，签名来自 RFC 9421，用途标签来自 AIPREF，它只做组合。
可以把这套交换想成一次过门禁。Signature-Agent 是身份证，证明"是哪家公司派你来的"；Access-Intent 是进门时申报的用途，你说来参观，就不能在展厅里搬货；Access-Payment 是押金，收费区域先付钱；Access-Delegation 是业主给家政的授权，只在指定房间、指定时段有效；Access-Receipt 是出门时盖的章，把你申报的用途、实际取的路径、时间全部记下，双方都赖不掉。这个对应不是表面相似，而是结构上一一对应：验身份、核申报、查委托范围、按用途计价、最后留痕。
源站收到请求后按固定顺序核验：签名在五分钟内有效；nonce 没被用过，靠原子预留挡住重放；用途和路径匹配 terms.txt 的声明；委托在作用域内；该收费的已付款。结果有四种：200 带签名回执 Access-Receipt（访问回执）、402 带价格和条款、401 身份失败、403 策略拒绝。没签名的请求，公开路径照常服务，受保护路径返回 403 并附 Accept-Signature 挑战，请对方用签名来谈。
委托令牌是这套设计里最讲究的一块。它绑死三样东西：一个成对的假名主体，源站不知道具体是谁；一个特定操作员；一个具名作用域，比如 read:premium。令牌被偷走，换一个操作员用就是废纸；一个订阅权益也解锁不了其他内容。源站最终学到的只有"某个订阅者的代理在场"，而不是订阅者身份。
Access-Receipt 由源站自己的密钥签发，包含操作员、假名主体、申报的用途与使用层级、Terms-Id、路径、请求签名的哈希和时间戳。每张回执追加进一条哈希链账本，链头哈希承诺了全部历史记录，任何一方都改不了账。论文特意点明：协议不替结算模型选择计量单位，它让单位变得可度量。
缓存层也配合这套设计：带回执的响应标记为 Cache-Control: private，并按操作员、意图和委托三个 header 做 Vary，共享缓存没法把一个操作员的回执错发给另一个。CDN 可以原样转发请求让源站验证，也可以自己验证后附一条 Forwarded 断言。中间人一旦改写被签名的组件，签名立刻失效，这正是设计想要的。下面这张架构图就是整套交换的全貌。
图注：terms.txt 在 HTTP 边界的授权与补偿交换。operator identity（操作员身份）、identity provider delegation（身份提供方委托）、settlement service payment（结算服务）与 origin（源站）四个角色；实线箭头是请求路径（六 header 与 200 / 401 / 402 / 403 返回），虚线箭头是请求前完成的带外预备，比如签发签名密钥、委托令牌与付款凭证。terms.txt
文件本身不强制，强制发生在 HTTP 边界。terms.txt 把"谁、拿内容干什么、该付多少"变成了一次请求里机器可验证的事实，而不是爬虫的自觉。但紧接着的问题是：这套东西到底能管住什么？
能强制的、能审计的、只能靠合同的，边界画在哪
论文对自己能力的边界划分得异常诚实，一共三层：可执行、可审计、可签约。
交付之前，HTTP 边界能强制的有五件事：请求真的来自声明的操作员、是新鲜的而不是重放的；意图确实被签过名，而不是中间人塞进去的；委托有效、在作用域内、绑定在同一个操作员身上；路径和用途匹配 terms.txt 的条款；收费请求带着有效且未花过的付款。原型拒绝一切失败，它的测试还专门抓出了三个早期版本放过的绕过路径。
交付之后，能审计：申报的用途可以用行为对账。声明 use=reference 却整篇转载，声明 search 却从不引荐回访，都会在回执、引用和流量里留下痕迹。处罚手段是撤销资格，Cloudflare 撤销 Perplexity 的 verified 状态，就是现实里已经发生过的同类动作。反过来也成立：伪造用途声明本身无法被阻止，能做的只有事后审计和撤销资格；凭证被盗的影响被五分钟窗口、密钥轮换和代理绑定压到最小。
拿到内容之后呢？模型真的拿它训练了没有，HTTP 层管不着。论文原话：A protocol can make terms explicit, attributable, and priced, but it cannot make them self-executing. A header layer does not prevent training, and this design does not assume that it can.（协议能让条款明确、可归责、可定价，却无法让条款自我执行。一层 header 阻止不了训练，这个设计也不假设它能。）terms.txt
| 边界 | 能做什么 | 手段 |
|---|---|---|
| 交付前：可执行 | 身份新鲜、意图未被改写、委托有效、条款匹配、付款有效 | 签名验证 + nonce 原子预留 |
| 交付后：可审计 | 声明与行为对账，违规可归责 | Access-Receipt 哈希链账本 + 撤销资格 |
| 拿到内容后：可签约 | 拿到内容后是否真的不训练 | 合同与法律，协议不假装能管 |
注意这里有个容易误读的点：协议不能自我执行，不是这个设计的失败，而是它的设计选择。整个声明家族对此心知肚明，AIPREF 草案开头就写"偏好不是安全机制"。规范性层面，另一篇论文主张光是合同也不够，还需要立法确立用户的委托权、强制双向透明、用比例原则审查代理封锁，所以"可签约"这一格是规范缺口，不是工程失败。Agentic Web Norms
性能账怎么算？论文给了一份 600 行无依赖的 Node.js 实现，在回环接口、无 TLS、单 vCPU 上跑了七个场景：
| 场景 | 结果 | p50 延迟 (ms) | 新增开销 (ms) | 吞吐 (req/s @32 并发) |
|---|---|---|---|---|
| 直通（基线） | 200 | 0.054 | 0 | 15,892 |
| 未签名放行路径 | 200，无回执 | 0.069 | 0.015 | 8,920 |
| 仅身份验证 | 200 | 0.255 | 0.201 | 3,027 |
| 签名搜索 + 回执上链 | 200 + 回执 | 0.392 | 0.339 | 2,424 |
| 委托代理 + 回执上链 | 200 + 回执 | 0.548 | 0.494 | 1,846 |
| 收费路径，无付款 | 402 + 条款 | 0.426 | 0.373 | 2,227 |
| 收费路径，凭证付款 + 回执 | 200 + 回执 | 0.704 | 0.650 | 1,438 |
| 伪造签名 | 401 | 0.266 | 0.212 | 3,554 |
三个反直觉点。第一，身份验证是最大单笔开销，光签名验证就要 0.201 ms；在此之上叠加意图解析、条款匹配、回执签发和记账，总共只再加约 0.14 ms。第二，拒绝比服务便宜：拒绝的 402 路径是 0.426 ms，真正收钱放行的路径是 0.704 ms。这意味着成本型 DoS 的杠杆被压住了，攻击者想用签名请求耗死源站，源站回绝的成本比服务还低。第三，论文摘要里的"0.20 到 0.65 ms"是全域范围，对应伪造签名下限到付费路径上限，最常见的搜索路径实际是 0.392 ms，别把 0.20 当成典型值。单次 Ed25519 验证的中位数是 120 微秒，这是 RFC 9421 注册算法给的底子。
吞吐量从基线 15,900 req/s 掉到最重场景的 1,400 到 3,000 req/s，因为单核单线程跑 Ed25519，但常见搜索路径的 2,400 req/s 已经超过大多数源站的真实负载。论文老实交代：这些是回环接口上的边际开销，不是互联网延迟，真实流量下的部署还有待研究。
这套方案不是纸上协议，每请求只贵零点几毫秒。而它对自己管不住训练这件事，比谁都诚实。那它真能改变游戏吗？反对的人怎么说？
反对声最大的三点，和三个能证伪的承诺
论文把最大的三声反对摆上台面，逐条回应。
反对一：回访是错的指标。论文答："部分同意，而这恰恰加强了论证。"代理可能比完二十家店、从一家下单，全程没留下任何可引荐的回访轨迹。如果价值不再主要通过点击流动，记账就必须移到所有参与方共享的那一个点上：请求本身。Cloudflare 把计量从按次爬取挪向按使用付费，寻找的正是同一个价值单位。Pay Per Crawl
反对二：给访问定价会封闭开放网络。回应是：封闭其实已经在以粗糙的方式发生了。现有工具区分不了研究型爬虫和商业管线，站长只能一刀切。一个让站点对档案馆、研究者、索引说"好"，对商业训练说"不"或"付钱"的协议，反而能减少这种过度封锁。
反对三：运营商不会遵守。回应分两层。签名让不守规矩从"看不见"变成"可检测"，而且只有带签名的请求才能拿到委托权益、付费内容和回执。欧盟 AI 法案第 53(1)(c) 条要求通用模型提供方尊重机器可读的权利保留，一个统一的标准信号，总比一堆各家私有的格式好办。
三条反驳成立与否，被落成三个可证伪的承诺：签名意图真能减少混合用途爬取吗？发布 terms 和回执的站点，一年内能看到运营商行为或爬取-回访比的变化吗？回执账本能和回答引擎的引用报告对上账吗？前两条，一个大型出版商部署一年内就能检验。问题的性质就这样从"信不信"变成了"测得出来测不出来"。
最后一层对照来自 Cloudflare 自己的产品。Pay Per Crawl 把"按爬取付费"做成了生意，但它的执行点绑在 Cloudflare 网络里，看这张图就明白。
图注：Cloudflare 栈内爬虫请求的流向。AI Crawler Request 进入 Cloudflare 范围（虚线框）后，依次经过 WAF 自定义规则与 AI Audit: Crawler Blocking、Bot Solutions，再到 AI Audit: Pay Per Crawl，最终抵达 Website Content。它是一层必须穿过 Cloudflare 网络才能生效的机制，源站没有等价物。Pay Per Crawl
terms.txt 的差异化正在于此：把同一件事交还给出源站自己，不换网络、不搬机房，在 HTTP 边界就能验签、计价、开回执。
回到开头那笔账。286,000:1 的失衡不是某一家公司的故障，而是三十年旧协议遇上新客户的自然结果。terms.txt 改变的不是"能不能拦"，而是把同意与补偿从道德口号变成了可度量的单位：机器可验证、行为可审计、账本可对账。剩下的问题是开放问题，是可以被数据回答的问题，不是信仰之争。协议不会自我执行，但至少，它第一次让"该付多少"有了一个能被回答的语法。
想深入可以读原文：terms.txt: A Consent and Compensation Protocol for Agentic Web Access — arXiv:2609.11152
参考文献
- terms.txt: A Consent and Compensation Protocol for Agentic Web Access（arXiv:2609.11152）：https://arxiv.org/abs/2609.11152
- Consent in Crisis: The Rapid Decline of the AI Data Commons（arXiv:2407.14933）：https://arxiv.org/abs/2407.14933
- RFC 9309: Robots Exclusion Protocol：https://www.rfc-editor.org/rfc/rfc9309.html
- RFC 9421: HTTP Message Signatures：https://www.rfc-editor.org/rfc/rfc9421.html
- draft-ietf-webbotauth-httpsig-protocol-00（IETF Web Bot Auth 工作组）：https://datatracker.ietf.org/doc/draft-ietf-webbotauth-httpsig-protocol/
- draft-ietf-aipref-vocab-07（IETF AIPREF 工作组）：https://datatracker.ietf.org/doc/draft-ietf-aipref-vocab/
- ai.txt: A Domain-Specific Language for Guiding AI Interactions with the Internet（arXiv:2505.07834）：https://arxiv.org/abs/2505.07834
- /llms.txt — a proposal to provide information to help LLMs use websites（Answer.AI）：https://www.answer.ai/posts/2024-09-03-llmstxt.html
- Cloudflare Introducing Pay Per Crawl 及 Content Independence Day 一年报：https://blog.cloudflare.com/introducing-pay-per-crawl/
- The Agentic Web Requires New Normative Infrastructure（arXiv:2606.10711）：https://arxiv.org/abs/2606.10711