AI Agent进不了网站了：反爬防线正在催生新的接入标准

AI Agent正在撞上一堵过去主要为爬虫准备、如今却可能误伤真实用户的新墙：网站的反机器人系统。

据 TechCrunch 10 月 6 日报道，能够替用户购物、订机票、订餐厅的个人 AI Agent，正在被验证码、JavaScript 挑战、浏览器指纹识别和访问频控挡在网站之外。问题不只在于某个 Agent 能不能“绕过”验证，而在于互联网现有的访问规则，几乎没有为“代表真人执行任务的软件”预留位置。

这也是新一轮 Agent 基础设施竞争的关键转折点：网站需要知道来访者是不是机器人，Agent 需要证明自己是否得到用户授权，用户则希望任务能完成而不是被迫接管鼠标。围绕这三件事，行业正在推动一种新的 Agent 网站接入标准，让访问从“伪装成人”转向“声明身份、验证权限、按规则行动”。

网站面对的不是普通爬虫，而是会做决策的代理

AI Agent 是能够理解目标、规划步骤并调用浏览器或外部工具执行任务的软件系统。它和传统爬虫的区别，不是访问速度更快，而是它可以在不确定条件下连续做决定。

传统爬虫通常按照固定规则抓取页面：打开列表页、提取链接、进入详情页、保存字段。Agent 则可能先比较价格，再判断配送时间，接着登录账户、填写地址、选择座位，最后在付款前询问用户是否确认。网站看到的仍是一串 HTTP 请求，但请求背后已经从“读取数据”变成了“代表一个人完成交易”。

这让传统反爬策略变得尴尬。

验证码可以拦住一部分脚本，却也会把视力障碍用户使用的辅助工具、企业内部自动化流程和用户主动授权的 Agent 一起挡住。JavaScript 挑战可以要求浏览器执行一段代码，但很多 Agent 使用的是无头浏览器、远程浏览器或受控操作环境，执行能力并不等同于恶意爬虫。至于 TLS 指纹、User-Agent 和鼠标轨迹，它们原本用来区分真人与程序，如今却越来越像一场双方都能模拟的猫鼠游戏。

更麻烦的是，Agent 的访问模式可能看起来“非常像真人”，也可能比真人更规律。一个帮助用户寻找便宜机票的 Agent，可能在几分钟内浏览数百个航班组合；一个替用户比较酒店的 Agent，可能连续打开几十个详情页。这些行为对任务是合理的，对网站的风控系统却很像高强度抓取。

反爬正在从“识别机器人”变成“管理访问意图”

反爬系统是通过访问行为、设备特征和请求模式判断流量是否值得信任的安全机制。问题在于，AI Agent 让“机器人”这个分类变得过于粗糙。

过去的网站通常把访问者分成两类：真人用户和自动化程序。前者允许进入，后者限制访问。Agent 的出现增加了第三类：自动化程序，但它可能受真人明确授权，并且愿意遵守网站的价格、库存、频率和支付规则。

这三类流量的差异，可以简单整理为：

| 访问类型 | 典型行为 | 网站关心的问题 | 更合理的处理方式 | |---|---|---|---| | 真人用户 | 手动浏览、点击、提交表单 | 账户安全、欺诈风险 | 正常访问，必要时二次验证 | | 未授权爬虫 | 批量抓取、复制内容、绕过限制 | 带宽消耗、数据滥用、竞争风险 | 限速、拒绝或法律追责 | | 用户授权 Agent | 代用户搜索、比较、预约、下单 | 权限边界、责任归属、交易安全 | 识别身份、验证授权、开放受控接口 |

真正需要改变的，不是网站简单地“放开机器人”，而是让网站能区分后两者。

目前最基础的身份声明仍然是 User-Agent。GPTBot、Google-Extended、ClaudeBot 等 AI 爬虫已经在公开文档中声明自身身份，并承诺遵守 robots.txt。robots.txt 是网站通过文本规则告知自动化程序哪些路径允许或禁止访问的机制，但它本质上是“君子协定”，不是强制认证系统。

例如，网站可以这样禁止特定抓取程序访问：

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: ClaudeBot
Disallow: /

这对训练数据抓取有一定作用，却无法解决 Agent 代表用户买票、订酒店时的授权问题。一个网站即使允许某个 AI 公司的爬虫读取公开内容，也不代表它愿意让该公司的 Agent 使用用户账户下单。

反爬技术已经进入“软封锁”阶段

AI 爬虫反制是通过访问轨迹、浏览器特征和内容策略降低自动化访问价值的技术体系。与直接返回 403 相比，越来越多网站开始采用更隐蔽的软封锁。

一种常见做法是分析访问路径。网站可以记录一个 IP 最近访问的 20 个 URL，观察它是否连续从列表页跳到列表页、从详情页跳到详情页。如果连续 10 次出现高度规则的同级页面直跳，系统就可能给请求增加 3 秒延迟，并移除结构化数据，只返回难以批量解析的纯文本。

这种策略的目的不是立刻把请求踢出去，而是让抓取成本变高，同时尽量不暴露检测规则。对需要实时完成任务的 Agent 来说，3 秒延迟会迅速累积：访问 100 个页面就是 300 秒，原本几分钟完成的比价任务可能拖到半小时。

另一类方法是行为生物特征识别。网站会观察鼠标轨迹、滚动节奏、点击间隔和页面停留时间。补充材料显示，部分实验中真人鼠标轨迹的方向熵通常高于 3.5，而程序生成的平滑轨迹可能低于 2.0；这并不是通用判定标准，但说明风控系统已经开始分析“行为的不完美”。

时间序列也会被纳入判断。真人上一页停留很久，下一页通常不会立刻关闭；连续跳过多页后，真人可能突然放慢速度。自动化程序常用相互独立的随机停留时间，表面上有随机性，却缺乏真实行为中的上下文关联。网站可以利用 LSTM 或 ARIMA 等模型捕捉这种差异。

更激进的做法是对高置信度自动化流量返回低价值甚至误导性内容，包括延迟页面、虚假链接、动态生成的无意义页面。这个策略对普通爬虫可能有效，但对 Agent 来说风险更高：如果 Agent 没有可靠的来源校验，它可能把错误价格、过期库存或伪造日期当成真实信息。

这也是为什么未来的 Agent 不能只会“看网页”，还必须能够判断网页是否可信、内容是否完整、页面是否处于异常环境。

新标准要解决什么问题

Agent 接入标准是一套让网站和 AI Agent 交换身份、权限、能力与执行结果的协议约定。它不应只是给 Agent 增加一个新的 User-Agent，而要回答四个实际问题。

第一，谁在访问？

Agent 需要声明服务提供方、软件身份、版本和联系方式。网站也需要验证这个声明是否可信，而不是接受任意脚本把 User-Agent 改成某个知名模型的名字。

第二，代表谁访问？

Agent 需要证明请求是否来自用户明确授权。这里的授权不应是一次性“我同意”，而应细分为任务范围、账户范围、金额上限、有效期和可执行动作。例如，用户可以允许 Agent 搜索低于 1000 元的机票，但不允许它直接支付；也可以允许它预约餐厅，但不能修改账户资料。

第三，能做什么？

网站需要向 Agent 明确公布机器可读的能力边界，包括搜索、报价、库存查询、预订、取消和支付等动作。每个动作都应携带参数约束、频率限制和是否需要人工确认的信息。

第四，出了问题谁负责？

如果 Agent 错订了日期、重复下单或读取了不该读取的个人信息，网站不能只面对一个模糊的“机器人”。协议需要保留操作日志、授权凭证和结果回执，方便用户、Agent 服务商和网站追溯责任。

从产品形态看，未来可能同时存在三层入口：面向人类的网页、面向软件的结构化接口，以及面向 Agent 的受控任务接口。三者不一定完全分开，但权限、价格和数据范围应该明确区分。

| 能力 | 普通网页 | 传统公开接口 | Agent 接入层 | |---|---|---|---| | 主要使用者 | 人类 | 开发者程序 | 用户授权的 Agent | | 数据形式 | HTML、图片、脚本 | JSON、XML 等结构化数据 | 任务、能力和结果的结构化描述 | | 权限粒度 | 登录态和页面权限 | API 凭证与配额 | 用户、任务、动作三级授权 | | 风险控制 | 验证码、风控、登录 | 访问令牌、限流 | 身份证明、动作确认、审计日志 | | 适合场景 | 浏览和手动操作 | 稳定的数据调用 | 搜索、比较、预订、执行任务 |

对开发者来说，最重要的是不要把网页当成永久接口

这场变化对 Agent 开发者的直接提醒是：浏览器自动化仍然有用，但不能再把“能打开网页”当成产品能力的全部。

第一，Agent 应优先寻找网站提供的官方结构化入口。网页上的按钮、CSS 选择器和 DOM 层级很容易变化，今天能点击的“立即预订”，下周可能已经改成异步组件。结构化接口、站点声明文件或公开的机器可读能力描述，稳定性通常更高。

第二，Agent 必须区分“读取”和“执行”。读取公开价格不等于可以创建订单，查询库存不等于可以锁定座位。产品设计上应把高风险动作拆开，在支付、提交订单、修改个人资料等节点要求用户再次确认。

第三，Agent 需要具备失败解释能力。遇到验证码、访问延迟、结构化数据缺失或页面内容前后矛盾时，系统应该告诉用户“网站拒绝了自动化访问”或“当前结果无法验证”，而不是继续猜测。

第四，缓存和频率控制会成为基础能力。一个用户问“帮我比较几家酒店”，不意味着 Agent 可以为每家酒店重复请求几十次。任务级缓存、请求去重、指数退避和结果复用，既能降低成本，也能减少被网站判断为异常流量的概率。

第五，Agent 应保存来源和证据链。价格、库存和时间信息都具有时效性，系统至少要记录数据来源、抓取时间、页面状态和关键字段。只有这样，用户才能判断结果是否仍然有效。

对网站来说，彻底封锁未必是好生意

网站选择封锁所有自动化流量，可以短期降低服务器压力，却可能错过下一代流量入口。

未来用户未必亲自打开十个电商网站比较商品，也未必在航空公司、酒店和餐厅之间来回切换。用户可能只告诉 Agent 预算、时间和偏好，然后让 Agent 代表自己完成发现和筛选。如果网站没有可被 Agent 理解的入口，它就可能从用户决策链中消失。

当然，开放 Agent 访问并不意味着免费提供全部数据。网站可以设定每分钟请求数、可读取字段、商业用途限制和高风险动作的人工确认，也可以为稳定的机器访问提供付费或合作机制。关键在于，这些规则需要被机器理解，而不是藏在一堆只能由人阅读的帮助文档里。

从商业角度看，网站真正需要的是“可计费、可追责、可撤销”的自动化访问。一个电商平台可以允许 Agent 搜索和比较，但要求订单创建必须经过平台认证；一家航空公司可以提供机器可读的航班和退改规则，但把支付、改签和证件信息更新放在更高权限层级。

这比把所有 Agent 都当成攻击者更精细，也比完全开放网页更安全。

新标准不会立刻终结反爬博弈

需要明确的是，Agent 接入标准不是验证码的替代品，也不可能自动消灭恶意爬虫。攻击者可以伪造身份、盗用授权、滥用合法接口，网站仍然需要风控、限流、账户保护和异常检测。

它真正改变的是默认的交互方式：从“Agent 想办法伪装成人”转向“Agent 先声明身份，再获得有限权限”。这类似从没有门牌和访客登记的建筑，转向有前台、分区权限和访问日志的办公楼。风险不会消失，但至少每次进入都有可验证的主体和边界。

短期内，行业可能处于混合状态：一部分网站继续依赖网页和验证码，一部分网站提供机器可读接口，平台型企业则尝试建立自己的 Agent 生态。不同协议、不同授权格式和不同商业规则之间，仍会存在竞争。

但趋势已经很清楚：AI Agent 的下一个瓶颈不只是模型是否足够聪明，而是互联网是否愿意让它们进入。

对开发者而言，真正有竞争力的 Agent 不应是最会绕过验证码的那个，而应是最能证明自己是谁、代表谁、被允许做什么，并且在失败时诚实停下来的那个。对网站而言，真正需要建设的也不是更复杂的“机器人识别迷宫”，而是一套能够把可信自动化访问纳入规则的入口系统。

如果这套新标准最终成熟，网页不会消失，反爬也不会消失。但用户与网站之间可能多出一个新的中间角色：拥有明确身份、有限权限和审计记录的数字代理。互联网的入口规则，正在从“人类点击网页”转向“人类授权软件完成任务”。