网站对AI Agent关上大门：自主代理遭遇互联网封锁

自主AI代理（AI Agent）正被OpenAI、Meta、Google等巨头描绘为下一代互联网入口——它们能替你预订晚餐、清理收件箱、购买球鞋。然而，当这些代理真正走出实验室，撞上的却是越来越多网站筑起的围墙。

当代理遇到“不欢迎”

据RSS来源报道，近期多个网站开始明确拒绝或限制AI代理的访问。这一趋势与AI代理能力的快速膨胀直接相关：OpenAI、Meta、Google以及Instinct等公司都在推动代理自主浏览网页、执行多步骤任务。问题在于，互联网的绝大多数站点并非为机器访客设计，更未准备好接受“代表人类行事”的自主程序。

网站运营方的担忧集中在三个层面：服务器负载与带宽成本、数据抓取与内容版权，以及安全风险——一个被授权“替你购物”的代理，同样可能被滥用为爬虫或攻击工具。

AI Agent（自主智能体） 是指能够感知环境、自主规划并执行多步骤任务以达成目标的软件程序，与传统的聊天机器人或API调用不同，它可以在最少人工干预下浏览网页、填写表单、点击按钮、完成交易。当前主流形态包括基于浏览器的“计算机使用”代理（如OpenAI的Operator、Anthropic的Computer Use）和基于API编排的任务代理。其技术底座通常是大语言模型负责推理与决策，配合工具调用、记忆机制和视觉理解能力。正因为代理会以“人类用户”的方式与网页交互，网站难以用传统区分爬虫与真人的手段加以识别，这也是封锁难题的根源。

封锁的三种形态

从目前的做法看，网站对AI代理的限制大致分为三类。

技术层面的拦截：通过robots.txt扩展、User-Agent识别、行为指纹检测等方式，区分人类浏览器与自动化代理。部分站点直接返回403或验证码挑战。

条款层面的禁止：在服务条款中明确禁止自主代理访问或交易，为后续法律行动留出空间。

商业层面的收费：要求代理运营方付费获取访问权限，将“代理流量”纳入API或数据授权体系。

这三种形态并非互斥，许多站点正在组合使用。

robots.txt 是网站根目录下的纯文本协议文件，自1994年起被搜索引擎等爬虫自愿遵守，用于声明哪些路径允许或禁止抓取。它本身没有法律强制力，但已成为互联网事实标准。随着AI代理出现，业界正在讨论扩展robots.txt语义，例如明确区分“搜索抓取”“训练数据抓取”和“代理代为操作”等不同用途，并配合IETF的AIPREF等工作组制定机器可读的偏好表达。User-Agent识别 则是服务器读取HTTP请求头中的客户端标识来判断访客类型，但该字段可被伪造，因此常与行为指纹（如鼠标轨迹、请求时序、TLS指纹）结合使用。验证码（CAPTCHA）则通过人机区分挑战来阻断自动化访问，但对多模态大模型驱动的代理而言，其防护效力正在下降。

谁在受损，谁在受益

对代理开发者而言，网站封锁意味着任务成功率下降、用户体验受损。一个无法完成预订的代理，很难说服用户长期使用。对网站而言，封锁虽然降低了成本和风险，却也失去了被代理推荐、比价、下单的潜在交易机会——尤其在电商和本地服务领域，代理可能恰恰是新的流量入口。

更深层的矛盾在于身份与责任：当代理代表用户执行操作时，网站无法确认背后是谁、是否获得授权、出了问题由谁负责。现有互联网的身份体系（账号、Cookie、验证码）是为人类设计的，代理的规模化出现让这套体系捉襟见肘。

代理身份与授权框架 是当前标准化的焦点。传统Web身份体系依赖账号密码、Cookie会话和OAuth授权，其前提是“人类在浏览器中操作”。当代理代表用户行动时，需要一套机器可验证的委托链条：用户如何授权代理、代理能执行哪些操作、权限何时失效、发生纠纷时如何追溯。已有提案包括为代理颁发可验证凭证（Verifiable Credentials）、在OAuth流程中引入代理角色、以及基于去中心化标识符（DID）的代理身份。这些方案的核心目标是让网站能够区分“获用户授权的善意代理”与“伪装成用户的恶意爬虫”，从而在可控前提下开放访问，而非一刀切封锁。

协议之争才刚开始

业界已有一些尝试，例如为代理设计专用身份标识、访问凭证和授权框架，让网站在可控前提下接纳代理流量。但这些标准远未统一。在协议和规则落地之前，网站与代理之间的“猫鼠游戏”大概率会持续。

自主代理的愿景很宏大，但互联网不会自动为它让路。谁来决定代理能否进门、以什么身份进门、承担什么责任，将是接下来一段时间AI与Web交汇处最值得关注的博弈。