.png){kind=logo}
2026 年 3 月 20 日，Google 在其爬虫文档里悄悄加了一行新条目：Google-Agent。
仔细读完官方描述，你会发现这东西和 Googlebot 有本质区别——它不是来爬你的网站建索引的，而是代用户来你的网站上做事的。
同时，Google 确认正在试验一个叫 web-bot-auth 的新协议，用密码学签名来证明 "我真的是 Google 派来的代理"。这两件事放在一起看，信号很明确：web 的访问控制规则正在被重写。robots.txt 撑了 30 年的君子协定，可能要让位给一套全新的身份验证体系，为其后壮阔的 Agents 时代进行优化。
这篇文章会把这两件事讲清楚：Google-Agent 是谁、为什么来、为什么 robots.txt 管不住它、以及新的解决方案长什么样。如果你管理网站，尤其是电商站，这些变化直接影响你的流量和数据安全。
Google-Agent 是什么：Google 爬虫家族的新物种
要理解 Google-Agent 的特殊性，先得看它在 Google 爬虫体系里的位置。Google 这些年陆续推出了好几代抓取工具，每一代解决不同的问题（如果你对整个爬虫生态不熟悉，可以先看这篇好坏 BOT 区分指南）：
关键区别在 "User-Triggered Fetcher" 这个分类。Googlebot 是自主运行的——Google 的调度系统决定爬什么、什么时候爬。但 Google-Agent 只在用户主动发出请求时才触发。比如用户对 Google 的 AI 助手说 "帮我在这个网站上找一下最便宜的航班"，Google-Agent 才会去访问那个网站。
Google 用这个逻辑来论证一件事：既然是用户让我去的，那就等同于用户自己在浏览，所以不需要遵守 robots.txt 的限制。
技术细节
Google-Agent 的 User-Agent 字符串有两种形式：
移动端：
Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Google-Agent; +https://developers.google.com/crawling/docs/crawlers-fetchers/google-agent)桌面端：
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Google-Agent; +https://developers.google.com/crawling/docs/crawlers-fetchers/google-agent) Chrome/W.X.Y.Z Safari/537.36其中 W.X.Y.Z 是请求时实际使用的 Chrome 版本号。IP 地址来自 Google 专门为用户触发代理分配的范围，记录在 user-triggered-agents.json 文件中（注意不是 Googlebot 用的那个 IP 列表）。验证方法和 Googlebot 一样：反向 DNS 查询确认域名匹配 google.com，再正向 DNS 确认 IP。
Project Mariner：Google-Agent 背后的产品
Google-Agent 不是一个抽象的技术标识，它背后对应着一个真实的产品：Project Mariner。
Project Mariner 是 Google DeepMind 开发的浏览代理，基于 Gemini 2.0 驱动。它作为 Chrome 扩展运行，能理解屏幕上的文本、图像、表单和代码，然后根据用户的指令自动完成多步骤的网页操作。
举几个实际场景：
-
你给它一份食谱，它自动去 Instacart 上把所有食材加入购物车
-
你说 "帮我在 TaskRabbit 上找一个周六能来修水管的师傅"，它自动筛选、比价、预约
-
你让它 "查一下飞东京最便宜的机票"，它会跨多个航司网站比较
在 WebVoyager 基准测试中，Project Mariner 的任务完成率达到 83.5%，支持同时处理最多 10 个并行任务。2025 年 5 月 Google I/O 上正式扩大推出，目前面向美国的 Google AI Ultra 订阅用户开放。
不过 2026 年 3 月有一个值得注意的信号：WIRED 报道 Google 正在重组 Project Mariner 团队，部分成员转到了更高优先级的项目。这可能意味着产品方向在调整——但 Google-Agent 这个 User-Agent 标识已经正式落地，说明底层能力不会消失，只是可能换一种形态呈现，包括近期开放的 146 版本 MCP 就是其逐步开始扩展的证明。
但更重要的是，做浏览代理的不只 Google 一家。OpenAI 的 Operator、Anthropic 的 Computer Use 都在做类似的事。AI 代理代替用户浏览网页、执行操作，这不是某家公司的实验，而是一个行业级的趋势。
robots.txt 为什么管不住 AI 代理
如果你管理过网站的 robots.txt，看到上面那张表可能已经不淡定了——Google-Agent 不遵守 robots.txt？那我辛辛苦苦配的规则算什么？
Google 的回答是：user-triggered fetcher 是用户主动请求的操作，不是自主爬取，所以 "generally ignore robots.txt rules"。
这个说法在逻辑上说得通，但在实践中打开了一个口子。站长通过 robots.txt 限制了自主爬虫的访问，结果 AI 代理以 "用户触发" 为由直接绕过。如果每个 AI 公司都用同样的逻辑——"是用户让我去的"——那 robots.txt 作为访问控制工具就基本废了。
事实上，robots.txt 的问题不止于此。它从诞生之初就有三个根本缺陷：
-
基于荣誉的信任模型：robots.txt 本质上是一份 "请求"，不是一道 "命令"。爬虫可以选择遵守，也可以选择无视，没有任何技术手段能强制执行。
-
身份可以伪造：User-Agent 字符串是爬虫自己声称的身份，任何爬虫都可以把自己伪装成 Chrome 或 Googlebot。已经有报道指出，部分 AI 公司通过重命名爬虫来绕过封锁名单。
-
没有问责机制：如果一个爬虫违反了 robots.txt 的规则，站长很难追溯是谁做的，也没有有效的申诉渠道。
这些缺陷在搜索引擎时代可以忍受，因为 Google、Bing 这些大玩家有商誉压力，不守规矩的代价很高。但在 AI 代理时代，代理的数量和种类将爆炸式增长，靠 "大家都是好人" 的假设越来越站不住。
LLMs.txt 是一种尝试——用一个专门的文件告诉大模型 "这些内容你可以用"。但它本质上和 robots.txt 一样，还是君子协定，解决不了身份伪造和强制执行的问题。
我们需要的不是另一个文本文件，而是一套完全不同的机制。
Web Bot Auth：用密码学替代君子协定
Web Bot Auth（全称 HTTP Message Signatures for Automated Traffic Architecture）就是这套新机制。它的核心思路很直接：不再让爬虫 "声称" 自己是谁，而是要求它用密码学 "证明" 自己是谁。
工作原理
整个流程分四步：
-
生成密钥：Bot 运营商（比如 Google、OpenAI）生成一对非对称密钥——私钥自己保管，公钥发布到一个公开的密钥目录。
-
签名请求：每次发出 HTTP 请求时，用私钥对请求内容进行密码学签名，签名附在请求头里。
-
验证身份：网站（或其前端的 CDN/WAF）从公钥目录获取公钥，验证签名是否有效。
-
做出决策：验证通过，网站知道 "这真的是 Google Agent"，然后根据自己的策略决定允许、限速还是拒绝。
技术上，协议基于 RFC 9421（HTTP Message Signatures）构建，使用 Ed25519 或 RSA-PSS 等非对称加密算法。每个签名包含时间戳和过期时间（建议不超过 24 小时），防止重放攻击。
IETF 标准化进展
这不是某家公司的私有协议。Web Bot Auth 架构草案由 Cloudflare 的 Thibault Meunier 和 Google 的 Sandor Major 联合撰写，目前已进入第 05 版。IETF 已经为此成立了正式的工作组（webbotauth），计划在 2026 年 4 月提交认证技术规范，8 月提交运营最佳实践文档。
Google 的参与方式值得注意。除了是草案的联合作者，Google 还在实际部署中试验这个协议——使用 https://agent.bot.goog 作为其签名身份。也就是说，Google-Agent 在发出请求时，除了传统的 User-Agent 字符串（向后兼容），还会附带密码学签名（前向安全）。这是一个典型的双轨过渡策略。
谁已经在支持
协议还在草案阶段，但已经有不少厂商在跟进。Cloudflare 作为草案联合作者，把 web-bot-auth 集成到了自家的 Bot Management 产品。AWS WAF 在 2025 年 11 月宣布支持签名验证，Akamai 的 Bot Management 也已跟上。在代理侧，OpenAI 的 Operator 已经在所有请求中携带 RFC 9421 签名。开源实现方面，Python、Rust、PHP、Ruby 都有现成的库，服务端有 Caddy 插件和 Apache 模块可用。
robots.txt vs Web Bot Auth
简单说，robots.txt 时代是 " 请不要偷我的东西 "；web-bot-auth 时代是" 证明你是谁，然后我决定给不给你 "。
Agentic Commerce：为什么电商站长尤其要关注
如果你经营电商网站，Google-Agent 这件事对你的影响比内容站更直接。因为 AI 代理不只是来 "看" 你的网站——它们要来 "买" 东西。
Shopify 已经推出了 Agentic Storefronts，允许消费者直接在 AI 对话界面中完成购买，不需要离开聊天窗口。目前已接入 ChatGPT、Google AI Mode / Gemini 和 Microsoft Copilot。与此同时，Shopify 也在悄悄收紧对 AI 爬虫的访问控制，默认在 robots.txt 中屏蔽了 GPTBot、ClaudeBot、PerplexityBot 等主流 AI 抓取器。一边开门迎客，一边加固围墙——Shopify 的做法很能说明电商平台当前的矛盾心态。
背后的技术标准是 Universal Commerce Protocol (UCP)，由 Shopify 和 Google 联合开发，已获得 Etsy、Wayfair、Target、Walmart 等 20+ 零售商和平台背书。UCP 定义了 AI 代理如何发现商品、创建结账会话、完成支付——不需要爬取网页，而是通过标准化的 API 接口交互（关于 Google 的 Agent-to-Agent 协议如何与这套体系协作，可以看这篇 A2A 协议解读）。
这对商家意味着一个核心矛盾：
-
开放给 AI 代理：增加在 AI 搜索结果中的曝光，触达高购买意图的用户——这些用户已经对 AI 助手说了 "帮我买一个 XXX"
-
封锁 AI 代理：保护商品数据不被大规模抓取，防止价格被实时比较、竞品被精准监控
还有一个容易被忽略的风险：AI 选品趋同。研究发现 AI 代理在做购买推荐时，倾向集中推荐少数 "最优" 商品，忽略其他选项。如果你的产品不在 AI 的 "推荐名单" 上，即使有大量自然搜索流量，也可能在代理购物时代被边缘化。更麻烦的是，模型的一次更新就可能导致推荐排序剧烈变化——今天被推荐，明天就消失了。
这就是为什么 web-bot-auth 对电商站长特别重要：它提供了一种按身份差异化管理的能力。你可以允许经过验证的 Google Agent 和 ChatGPT Operator 访问你的商品页面，同时拦截未签名的不明爬虫。这比 robots.txt 的 "要么全开要么全关" 精细得多。
站长现在该做什么
说了这么多，回到最现实的问题：你现在能做什么？
1. 在服务器日志里识别 Google-Agent
Google-Agent 已经在逐步推出。在你的服务器日志中搜索包含 Google-Agent 的 User-Agent 字符串，看看它是否已经在访问你的网站。验证方式和 Googlebot 相同：对请求 IP 做反向 DNS 查询，确认解析到 google.com 域名。如果你不熟悉日志分析，可以参考爬虫预算与日志分析实战指南。
2. 理解你能控制什么、不能控制什么
明确一点：在 robots.txt 中添加 User-agent: Google-Agent + Disallow 规则不会生效。 Google 已经明确说明 user-triggered fetchers 不遵守 robots.txt。
你仍然可以在网络层面拦截——通过 IP 范围（user-triggered-agents.json）在防火墙或 CDN 规则中封禁。但在做这个决定之前，先想清楚你是否真的想拦截代表用户来浏览的 Google 代理。
3. 检查你的 CDN/WAF 是否支持 web-bot-auth
如果你使用 Cloudflare、AWS WAF 或 Akamai，好消息是它们已经或即将支持 web-bot-auth 签名验证。这意味着你不需要改任何代码——在控制面板里配置策略就行。
AWS WAF 甚至已经默认自动允许经过 web-bot-auth 验证的 bot 流量通过。检查一下你的配置，确保你知道当前的默认行为是什么。
4. 从 "允许 / 禁止" 转向基于身份的策略
过去管理 bot 只有两个选项：允许或禁止。web-bot-auth 让你可以做更精细的决策：
-
经过签名验证的 Google Agent → 允许全量访问
-
经过签名验证的 OpenAI Operator → 允许访问，但限速
-
未携带签名的不明代理 → 拦截或要求验证
具体策略取决于你的业务模式。内容站可能希望限制 AI 代理抓取全文，电商站可能希望允许代理浏览商品页但拦截价格批量抓取。
5. 关注 IETF 时间节点
2026 年是 web-bot-auth 标准化的关键一年。4 月将提交认证技术规范，8 月提交运营最佳实践文档。这些规范落地后，预计会有更多 CDN 和 WAF 厂商提供开箱即用的支持。如果你对技术 SEO 感兴趣，这是今年最值得跟踪的标准化进程之一。
总结
Google-Agent 的出现说明一件事：搜索引擎不再只是替你找信息，而是开始替你做事情。1994 年诞生的 robots.txt 协议管不了这个局面，web-bot-auth 用密码学给出了一个更靠谱的方案。
Google、Cloudflare、OpenAI、AWS 同时在推这件事。对站长来说，bot 管理正在从 "允许或禁止" 变成 "先验明正身，再区别对待"。2026 年 4 月和 8 月的 IETF 规范提交是两个值得盯的时间点。
现在可以做的事情很简单：去服务器日志里搜一下 Google-Agent，看看它是不是已经来过了。