Meta封禁事件警示：Claude工具读取过快，AI Agent需限速

Meta 在周末封禁了 No Kings 联盟的 Instagram 账号，随后将原因归咎于一个基于 Anthropic Claude 构建的工具以“爆发式”频率读取数据。这件事的政治争议很热闹，但对于构建或运行 AI Agent 的开发者来说，真正的教训既小又实际：当 Agent 在已登录会话中工作时，它在平台眼中就是账号本身，触发风控后，被封的是账号。

Meta 的说法与未说的部分

据 Bloomberg 报道，Meta 传播副总裁 Andy Stone 在周日的解释中称，Instagram 工程师发现一个 Claude 工具以约正常速率四倍的速度，密集地请求个人主页、帖子和话题标签。Stone 表示这些请求“更像是自动化机器人流量，而非普通人类在浏览我们的系统”。

Meta 的解释在周末发生了转变。周六，Stone 将问题归咎于异常高的发帖、分享或评论频率，并承认 Meta 的自动化系统“采取了错误行动”。周日，他在 X 上发布了修订后的说明并道歉：“我们再次为这个错误致以诚挚的歉意。”一个自动化复审在大约一小时后发现该账号不应被移除，联盟表示周六纽约时间下午 5:33 全面恢复访问。

但关键信息仍然缺失。Stone 的声明没有说明涉及哪个 Claude 工具、由谁操作、以及它与该账号有何关联。所引用的报道中均未包含 Anthropic 的声明。因此，“一个 Claude 工具”应被视为 Meta 的单方面描述，而非关于谁做了什么的确凿事实。目前没有人公开日志。

为什么你的 Agent 看起来像机器人

对 Instagram 而言，不存在什么 Agent。存在的只是一个会话 cookie、一个账号和一连串请求。人类浏览话题标签时速度自然，有停顿；而一个被要求“看看今晚大家都在说什么”的 Agent，会以工具循环允许的最快速度打开一个主页、一个帖子、一个话题标签页，再下一个主页。这正是 Meta 描述的爆发模式。

Instagram 的使用条款对此很直白：“你不能试图以未经授权的方式创建账号或访问、收集信息。这包括未经我们明确许可，以自动化方式创建账号或收集信息。”按我的理解，一个通过你已登录会话浏览的 Agent，很难不被描述为“以自动化方式收集信息”。

浏览器 Agent 让这一切在不知不觉中变得容易。Anthropic 的 Claude in Chrome 权限指南列出了三种模式，在标为“跳过所有批准”的模式下，指南写道：“Claude 不会暂停询问，也没有任何机制自动检查其操作。”Meta 并未指明涉事工具就是 Claude in Chrome。但要点是通用的：页面加载之间没有审批步骤，就没有任何东西能让 Agent 减速到人类速度。

同一份指南还给管理员提供了一个值得了解的杠杆：“阻止列表可防止 Claude 访问特定网站，无论用户权限如何。”如果一个组织的主要社交账号位于一台也运行浏览器 Agent 的笔记本电脑上，这是一个成本低廉的防护措施。

会话 cookie 是网站用来识别用户身份的一段凭证，第一次登录后由服务器下发并保存在浏览器里，之后每次请求都会自动携带它。对平台而言，谁持有这个 cookie，请求就来自谁——它看不到浏览器后面是人还是脚本。因此，当 Agent 运行在一个已登录的浏览器会话中，它发出的每一个请求都自带你的账号身份，平台的风控系统不会区分“账号主人在浏览”和“脚本在用这个账号浏览”。这也是文章所说的“Agent 在平台眼中就是账号本身”的技术基础：封禁的对象是账号这一身份，而不是某个可识别的程序。理解这一点，才能理解为什么限速、审批步骤这类减速机制必须落在工具层或会话层，而不是指望平台去识别“这是合法 Agent”。

浏览器 Agent（browser agent） 指通过控制真实浏览器（而非直接发 HTTP 请求）来操作网页的 AI 工具，它能点击、滚动、填表，读到的也是渲染后的页面。这类工具的优势是能处理登录态、JavaScript 渲染和复杂交互，代价是它的行为轨迹与人类极为相似却又快得多，平台几乎无法从请求特征上把它和真实用户区分开，除非观察节奏。Anthropic 的 Claude in Chrome 就是这类工具的一个例子，它以浏览器扩展形式运行并继承用户的登录状态。正因如此，浏览器 Agent 一旦进入没有审批门槛的自动模式，就会把“人类速度”这个隐形的安全阀彻底拆掉，风险从“被抓到”变成“毫无摩擦地撞上阈值”。

为 Agent 的每次读取设定节奏

如果你自己编写浏览或抓取工具，请把节奏控制写进工具代码。一个被告知“慢一点”的模型没有时钟概念。

下面这个包装器在等待前为每个主机预留一个时间槽，因此并行的工具调用会排队，而不是同时发射：

const nextSlot = new Map<string, number>();

export async function paced(
  url: string,
  init?: RequestInit,
  minGapMs = 4000,
): Promise<Response> {
  const host = new URL(url).host;
  const now = Date.now();
  const jitter = Math.random() * minGapMs * 0.5;
  const slot = Math.max(now, nextSlot.get(host) ?? 0);
  nextSlot.set(host, slot + minGapMs + jitter);
  const wait = slot - now;
  if (wait > 0) {
    await new Promise((r) => setTimeout(r, wait));
  }
  return fetch(url, init);
}

4 秒的间隔是我选的起点，并非来自 Meta。Meta 没有公布“正常速率”是多少，也不应期望它公布，因为公开的阈值会被机器人作者恰好卡在下面。保持按主机限速、加入抖动，并限制单个任务总共可以读取多少页面。

平台有 API 时就使用 API

更干净的解决方案是根本不浏览。Meta 的 Graph API 有文档化的限流规则：对于 Instagram 平台，页面给出的公式是“24 小时内的调用次数 = 4800 × 展示次数”，按应用和应用用户计数。它还会在 X-Business-Use-Case-Usage 响应头中向你报告使用情况，包括被限流后的 estimated_time_to_regain_access（以分钟计）。

Agent 工具可以读取该响应头并自动停止：

type BucEntry = {
  type: string;
  call_count: number;
  estimated_time_to_regain_access: number;
};

export function bucBackoffMs(res: Response): number {
  const raw = res.headers.get("x-business-use-case-usage");
  if (!raw) return 0;
  const usage = JSON.parse(raw) as Record<string, BucEntry[]>;
  let minutes = 0;
  for (const entries of Object.values(usage)) {
    for (const e of entries) {
      const wait = e.estimated_time_to_regain_access;
      minutes = Math.max(minutes, wait);
    }
  }
  return minutes * 60_000;
}

通过 API，你会触达一个有文档的限制，得到一个数字然后等待。通过已登录的浏览器，你收到的第一个信号可能就是账号被停用。

平台 API 与网页抓取的本质区别在于前者是一份有契约的接口：调用配额、计费方式、错误码都写在文档里，超限时平台会明确告诉你“等多久”，而不是直接惩罚账号。Meta Graph API 的 X-Business-Use-Case-Usage 响应头就是这种契约的体现——它把“你用了多少、还剩多少、被限后要等几分钟”以结构化字段返回，让客户端可以实现确定性的退避逻辑。相比之下，通过已登录浏览器读取页面时，平台没有任何渠道向你报告配额，风控只能事后以封号、验证码或临时限制的形式表达，误差和代价都被放大。因此“有 API 就用 API”不只是合规姿态，更是让 Agent 获得可预测反馈的唯一途径。

记录请求，才能回答“哪个工具”

再看一眼 Meta 声明中的空白：哪个工具、谁运行的、在做什么。如果平台某天对你的账号提出同样的问题，这些就是你在一小时内需要回答的问题。

所以，把 Agent 工具发出的每个请求记录为一行结构化日志：时间戳、主机、路径、工具名称、触发它的会话或任务、以及背后的 Agent 和模型。这样，“四倍正常速率，爆发式”就可以用你自己的数据去核对，而不是一个你只能接受或忽略的说法。没有这些日志，你只能像所有看新闻的人一样猜测。

在关键日子让 Agent 远离账号

如果一个账号在某一天特别重要（抗议活动、产品发布），在那天结束前，让 Agent 远离它的登录会话。

本文基于公开报道编译，观点仅代表原作者。