Meta指控Claude工具超速爬取：124行Python给AI代理立规矩

Meta与Anthropic之间的一场小风波，意外揭开了AI代理部署中一个被长期忽视的问题：当模型在循环中调用浏览器工具时，没有任何机制让它的行为举止像一个"有礼貌"的访客。本文介绍一套124行标准库Python方案，用于给AI代理的HTTP行为套上缰绳。

事件回顾：一次误封引发的机制讨论

据The Next Web与AI Weekly的报道，Instagram曾短暂封禁No Kings Coalition的账号约90分钟。Meta传播副总裁Andy Stone随后解释，一个与Anthropic旗下Claude相关的工具以约人类四倍的速度访问了该联盟的档案、帖子和话题标签，短促而密集的请求模式与自动化机器人流量高度相似。Meta承认封禁是误操作并致歉，但没有披露具体是哪个工具、由谁运行、目的是什么。

事件本身仍有未解之处，但多家来源交叉印证的核心事实是：平台的风控系统并不关心流量是否来自"乐于助人的助手"，它只看突发请求的形态，并针对账号或IP采取行动。这一点，正是所有涉及网页访问的代理项目需要正视的。

为什么"礼貌"需要写进代码

作者的观点很直接：模型本身没有"慢一点"的概念，浏览器或HTTP工具也不会主动限速，两者之间缺少一层理解节流的中间件。这套中间件被他称为"护栏层"，由七个小型机制组成：

• 按主机令牌桶：每个站点有稳定的请求节奏（默认每分钟12次、突发2次），防止模型一时兴起"检查所有档案"时瞬间打出几十个请求。
• 随机抖动：人类不会每5.000秒精确点击一次，固定间隔本身就是机器人特征。
• 429与503退避：服务器返回Retry-After时严格按其要求等待（支持秒数和HTTP日期两种格式），否则采用带抖动的指数退避。
• robots.txt：请求前用urllib.robotparser检查，Crawl-delay会降低令牌桶速率。
• 诚实的User-Agent：标明机器人身份并提供联系URL和邮箱，让站点运营者能联系你，而不是直接封锁整个IP段。
• 每日动作上限：失控循环无法突破的硬天花板，重试也计入，因为服务器同样看得到。
• 只追加的动作日志：每个动作一行JSON，包括被拒绝的请求，出问题时能秒答"代理到底做了什么"。

几个值得解释的设计决策

令牌桶允许"透支"：两个线程同时取令牌时，第二个会睡得更久，这样锁持有时间短、节奏依然正确。如果服务器要求的等待时间超过max_backoff，客户端选择放弃而非提前重试——在Retry-After到期前重试，恰恰是把限流升级为封禁的典型行为。每日上限在启动时从日志重建，作者第一版把计数放在内存里，崩溃重启就会清零，读日志才让上限变得真实。

robots.txt获取失败时的处理也偏保守：404表示"没有规则"，但网络故障意味着"我不知道"，此时一律禁止。

作者还分享了一个测试中发现的bug：在__init__中写self.today, self.count = utc_day(), self._count_today()，Python会先求值整个右侧，导致_count_today()在self.today存在之前运行，重启且日志已存在时崩溃。首次演示因为日志为空而通过——这提醒开发者要测试重启路径，而不只是顺利路径。

令牌桶（Token Bucket） 是一种经典的限流算法：桶中按固定速率持续补充令牌，每个请求需消耗一个令牌，桶满即停止补充。其关键特性是允许一定程度的"突发"——桶的容量决定了短时间内可透支的请求数，此后请求必须等待新令牌生成。文章中的"每分钟12次、突发2次"即指补充速率为每分钟12个令牌、桶容量为2个。相比固定间隔的简单限速，令牌桶既能平滑长期速率，又能容纳少量合理突发，因此成为API客户端与网关限流的主流实现。

指数退避（Exponential Backoff） 是应对临时性故障的重试策略：每次失败后将等待时间按倍数增长（如1秒、2秒、4秒、8秒），并通常叠加随机抖动以避免多个客户端同步重试造成"惊群"。配合服务器返回的Retry-After头使用时，客户端优先遵循服务端指定的等待时长，仅在缺失该头时退回到指数退避。文章强调的"在Retry-After到期前重试会把限流升级为封禁"，正是这一机制存在的现实理由。

robots.txt 是站点根目录下的纯文本协议文件，通过User-agent、Disallow、Allow、Crawl-delay等指令告知爬虫哪些路径可以访问、访问频率应如何控制。它并非强制性的技术屏障，而是一种行业惯例与授权声明，遵守它是爬虫"守规矩"的基本标志。Python标准库的urllib.robotparser可解析该文件并回答"某URL是否可抓取"。需要区分的是：robots.txt的404响应意味着站点未设置规则（默认允许），而网络故障或超时意味着"规则未知"——后者在保守策略下应视为禁止，因为无法确认自己是否被允许。

User-Agent 是HTTP请求头中标识客户端身份与版本的字符串。诚实的User-Agent通常包含机器人名称、用途说明及联系URL或邮箱，使站点运营者在流量异常时能先联系而非直接封禁。与之相对，伪装成常见浏览器的User-Agent属于规避检测行为，与限速的初衷背道而驰。

实测：一个会"反抗"的模拟服务器

演示用一个本地模拟服务器验证全部规则：robots.txt禁止/private并设置Crawl-delay: 1，/profile/*每第三次请求返回带Retry-After: 2的429，/busy首次请求返回无提示的503。客户端设为每分钟120次请求，以便观察爬取延迟如何把它压到每秒一次，每日上限设为8次以便快速耗尽。

实际输出清晰展示了每条规则：请求间隔约一秒而非0.5秒，因为Crawl-delay覆盖了配置；429精确等待了服务器要求的2秒；无头的503获得了约1.1秒的抖动退避；/private请求从未离开本机；最后一个档案请求在重试中途撞上上限，因为重试也是真实请求。日志同样记录了被拒绝的动作，包括robots.txt禁止和达到每日上限两种情况。

接入代理的方式很简单：把agent.get注册为模型唯一可调用的HTTP工具，并把Blocked异常当作正常的工具结果（"不允许，停止"）而非可绕过的错误。

诚实的局限：礼貌不等于许可

作者在这一部分的态度值得尊重。他指出，礼貌不是许可：如果平台条款禁止自动访问，一个缓慢且标注清晰的机器人依然违规，这套工具减少的是附带损害，不是让被禁止的自动化变得可接受。

优先使用官方API是更优解——Meta、X、LinkedIn等大平台都提供带明确配额的API，被告知的限流胜过猜测的限流。登录态抓取则是另一类风险：robots.txt管的是公开页面的爬虫，一旦代理使用真人会话，平台账号规则开始生效，通常不论节奏都禁止自动访问，而丢失的账号可能属于你的客户。

人类节奏也不是伪装：抖动的存在是为了避免冲击服务器，而非规避检测，诚实的User-Agent是刻意为之——如果你动了去掉它的念头，这本身就是该任务不应被自动化的信号。此外，这套方案只覆盖HTTP，不覆盖浏览器；如果代理驱动无头浏览器，每次页面加载都会触发几十个子请求，需要把令牌桶放在导航和点击之前，并把每次操作计为一个动作。它还是单进程的：五个worker就是五份预算，集群场景需要把令牌桶和计数器移到Redis或数据库。

官方API与网页抓取的本质差异在于授权与可预期性。官方API通常要求注册应用、获取密钥，并在服务条款中明确速率配额、数据用途与再分发限制；超额时返回结构化的错误码与配额头，客户端可据此精确调度。网页抓取则没有任何契约保障：页面结构可能随时变更，风控策略不透明，且平台条款往往以"禁止自动化访问"覆盖此类行为。因此文章主张"被告知的限流胜过猜测的限流"——当存在官方API时，抓取不仅技术上更脆弱，法律与合规风险也更高。

登录态抓取指代理复用真实用户的会话Cookie或凭证访问站点。此时robots.txt不再适用，取而代之的是平台账号规则，通常无论请求节奏如何都禁止自动化操作；一旦触发风控，受损的是真实用户账号而非匿名IP，后果可能是数据丢失、账号封停乃至客户关系破裂。

部署前的检查清单

在代理触碰他人站点之前，作者建议逐项确认：是否存在官方API可替代；服务条款是否允许该用途的自动访问；是否所有出站请求都经过同一个限流客户端；User-Agent是否标明机器人并提供有效联系方式；是否检查robots.txt及Crawl-delay；是否遵守Retry-After并在429/503时退避；是否有重启后仍有效的硬性每日上限；是否能从日志重建每一个动作；若运行在用户登录会话中，用户是否同意且平台规则是否允许。

限流只是让代理可安全部署的一半，另一半是控制模型被允许决定什么。一个只能访问必要工具的代理，比一个礼貌但权限过大的代理更安全。