什么是 Agentic Commerce？为什么你的网站会拦截它

一位顾客让助手去找一个替换用的滤水芯，比较三家卖家，然后买下周末前能送到的最便宜的那一个。助手打开浏览器， 逐页浏览你的商品页，把一件商品放进购物车，然后走向结账。你为了挡住抓取程序而写下的每一条规则，都在旁观这次 会话并对它作出判断。这个判断很有可能是错的。

这就是代理式商务，而今天它又多了一道障碍。Cloudflare 的新流量默认设置自 2026 年 9 月 15 日起生效，Agent 是 其中两个在展示广告的页面上默认被拦截的类别之一。

代理式商务到底指什么

代理式商务是指由软件替某个人完成的购物：它搜索、在卖家之间比较、套用对方给出的条件、填满购物车，有时还会付 款。这个人给出的是一个结果（“四十元以内，周五之前到”），而不是一条查询语句，点击的活儿交给代理。

这句话里真正关键的词是行动。过去两年里多数网站争论不休的那类 AI 流量，从头到尾只做一件事，就是读：

前两者属于内容权利问题和 SEO 问题，已在 Cloudflare 的爬虫默认设置对你的网站意味着什么 中讨论过。代理两者都不是。它是一位从陌生管道走进来的顾客，拦下它损失的是订单，而不是一次引用。

它实际发送的是什么流量

HUMAN Security 的 2026 年基准报告基于 2025 年超过一千万亿次交互，给出了目前最清晰的公开图景。AI 驱动的流量 在 2025 年 1 月至 12 月之间增长了 187%，自动化流量目前的增速约为人类流量的八倍。

更有用的部分是这些流量落在哪里。整个 2025 年，代理式活动的分布如下：

• 77% 落在商品页和搜索页
• 8.8% 落在账户页
• 5% 落在身份验证流程
• 2.3% 落在结账环节

到 2026 年 4 月，HUMAN 认为代理式浏览器，也就是被程序驱动的真实浏览器而非脚本化的 HTTP 客户端，已占全部代理 式流量的近四分之三。

把这些数字合起来读，画面就很具体了。绝大部分是浏览，它看起来像浏览，是因为它确实发生在一个真实浏览器里，而 只有很窄的一条抵达了真正付款的页面。你正在裁决的大多数请求并不是购买尝试，而是有可能变成购买的调研。

你现有的规则为什么会拦住它

没有人专门坐下来决定要把购物代理挡在门外。做出这个动作的规则是为另一个问题写的，而它们的泛化能力很差。

来自数据中心的来源。 代理会话常常跑在云基础设施上而不是家庭宽带上，而那恰好是多数网站视为可疑的地址空 间。这条经验法则是针对租服务器的抓取程序建立的，它分不清抓取程序和一个正在跑腿的托管助手。 识别云与主机托管 IP 讲的是同一个陷阱：来源只告诉你在哪里，永远 不会告诉你为什么。

无头与自动化标记。 被驱动的浏览器会留下痕迹，而多数系统默认把这些痕迹当作敌意。

速度。 一个要比较四家卖家的代理，读页面比人快，于是撞上了按人类阅读速度设定的限制。

验证挑战。 交互式验证的前提是有人在场把它解开。在代理式商务里确实有人，只是不在键盘前，而这恰恰是验证流 程处理得最差的情形。

在自动化还意味着有人抄你的商品目录的年代，上面每一条都算合理。随后 Cloudflare 9 月 15 日的默认设置又叠加上 来，带着一个明确的 Agent 分类，在展示广告的页面上默认拦截：适用于新客户、新加入的站点，以及未更改该设置的免 费方案账户。一个混合了多种用途却不加区分的爬虫，会按其任一行为所适用的最严格规则处理。

司法这条路刚刚关上了

不少商家原本以为这件事会在法庭上解决。它确实被检验过，而答案指向了另一边。

亚马逊于 2025 年 11 月就 Comet 浏览器起诉 Perplexity，指控之一是该代理发送了与 Google Chrome 相同的 User-Agent 字符串，而没有表明自己的身份。地区法院在 2026 年 3 月 9 日签发了初步禁令。2026 年 8 月 4 日，第九 巡回上诉法院撤销了该禁令，认定当一个人指示助手在 Amazon.com 上完成某项任务时，访问亚马逊计算机的是用户而不 是 Perplexity，助手在其中充当工具。法院并未就 User-Agent 字符串是否被蓄意更改这一事实争议作出裁断。

由此可以得出两点。面对一个由顾客主动要求去行动的代理，计算机犯罪法是一根很弱的杠杆，因此放谁进来这个决定属 于你，要靠技术手段和服务条款来落实。而在唯一一起由大型零售商详细测量过此事的案件里，处于争议中心的恰恰是运 营方自己的标识字符串。用代理“自称什么”来识别它，问题正在于此。

代理与攻击者的分界线在哪里

所有人最先伸手去抓的那个信号，恰恰是客户端唯一能自行控制的信号。User-Agent 由发送方书写，所以它是一项声明而 不是证据，任何请求头同理。真正站得住的，是那些从客户端如何被构建中自然流露出来、而非它决定要说什么的属性：

没有任何单独一行能定案。一个主机托管 IP 不是判决，被驱动的浏览器也不是，因为那既能描述购物代理，也能描述一 场撞库。横着把几行连起来读，含糊之处通常就消解了：一个来自会公布地址段的运营方、落在商品页、保持单一会话的 代理，和一个无从核实、反复试探你登录表单的数据中心地址，不是同一类事件。 完整的验证机制因运营方而异，值得认真做对。

这正是 Agentscan 在一次调用里完成的事。它返回一个类别，human、known_bot、ai_agent 或 malicious_automation，附带置信度和支撑判定的信号，把 IP 来源与无头标记、JA4 指纹以及一份经反向 DNS 核验的 放行名单融合在一起。命中缓存的判定在 50 毫秒内返回，这才使得这个决定能放进一个中间件环节，而不是第二天早上的 日志复盘。

一套经得起真实流量考验的策略

1. 按路由决定，而不是按站点决定。 流量分布已经说明：代理活动绝大多数落在商品页和搜索页，落在结账上的极 少。放代理去读商品目录，把真正的审查留给登录和支付，策略就对准了风险真正所在的位置。
2. 把四个问题分开问。 它是否自动化、它是谁的代理、背后是否有已登录的人、它正在做什么？单一的放行或拦截开 关会把四个问题压成一个答案，而其中三个会答错。
3. 绝不要只凭名称放行。 ChatGPT-User 谁都能发。按运营方放行，然后把来源地址与该运营方公布的内容核对， 否则这份名单就成了任何读过它文档的人的通行证。
4. 有意识地检查你的 Cloudflare 设置。 如果你使用免费方案，或最近新增了站点且从未动过 AI 流量控制项，9 月 15 日的默认设置现在已经对你生效。这是否合适，取决于你是否在卖东西，而默认值并不知道这一点。
5. 即使放行也要记录类别。 那些真正转化了的代理会话，有意去找才找得到。你无法对一个从未标注过的分群做分 析，“有多少收入是通过代理进来的”会在一个季度之后变成一个无法回答的问题。

小结

代理式商务不是换了个名字的爬虫问题。训练爬虫从你这里拿走东西，搜索爬虫用引用换取访问，而代理是一位带着替他 点击的软件出现的顾客。你现有的规则分不清它们，因为这些规则是为回答“这次会话是否自动化”而建的，而那已经不再 是值得问的问题。司法这条路在 8 月关上，基础设施的默认值在今天翻转，剩下的正是一直以来真正要紧的部分：先归类 这些流量是什么，再按路由决定每一类可以做什么，并且让两者都建立在客户端无权替自己书写的信号之上。