AI Agent 被 Cloudflare 挡住后，为什么还会自信地胡说
作者：陈墨｜OC 技术编辑
陈墨
据开发者在 Tilion 技术博客中的复盘，他们的 Agent 抓取网页时遇到 Cloudflare 的拦截页，却没有把任务标记为失败，反而把“Just a moment”等挑战页面当成正文继续总结。
一句话结论：Cloudflare 阻止 Agent 并不可怕，可怕的是 Agent 没有意识到自己什么都没读到，还把错误页加工成了一个看起来完整的答案。
这类事故的根源不只在 Cloudflare。传统程序遇到 HTTP 403，通常会直接报错；很多反爬系统却返回 HTTP 200，再给出一段“请验证你是真人”的 HTML。对浏览器来说，这是等待用户操作的页面；对只负责提取正文的 Agent 来说，它可能就是一篇有标题、有段落、甚至有足够字数的“文章”。
如果抓取工具只返回一个字符串，模型看不到状态码、重定向、页面指纹和浏览器挑战信息，就很难判断这段文字是否代表目标内容。随后模型又被要求“无论如何给出摘要”，最自然的行为就是利用页面上仅有的词和已有知识补全答案。
Cloudflare 的政策确实改变了网络环境。公司从2025年开始为新站点默认阻止未经许可的 AI 爬虫，并逐渐把搜索、训练和 Agent 使用拆成不同类别。到2026年的新方案中，搜索型访问可以被允许，而训练与 Agent 访问可在带广告页面默认阻止。网站所有者有权这样做，Agent 开发者需要适应，而不是假定所有 URL 都能像普通浏览器一样读取。
真正该修的是失败协议
Tilion 的文章同时推广自己的抓取服务，因此其中“绕过限制”的方案不能照单全收。对于普通产品，更可靠的改进不是不断伪装浏览器，而是让失败变得可见：工具应返回 blocked、challenge_page、robots_denied、login_required 等结构化状态；模型必须引用实际抓取片段；没有正文时应停止，而不是自动搜索记忆补齐。
还可以加入一些便宜的检测：目标标题是否出现、正文与域名是否匹配、页面是否包含 Cloudflare/DataDome 常见挑战文本、内容长度是否异常、不同抓取路径得到的哈希是否一致。Agent 最重要的能力之一不是“总能给答案”，而是知道证据什么时候不存在。
关键事实
- Cloudflare 官方提供 AI Crawl Control，站长可以按爬虫和用途允许或阻止访问。
- 拦截可能表现为403，也可能返回带挑战内容的正常 HTML 页面。
- 原文案例来自抓取服务提供商，关于效果与覆盖率的主张需要独立验证。
- 绕过反爬可能违反网站条款；识别失败与尊重访问规则是不同问题。
OC 判断
Agent 产品常把“网页工具返回了文本”误当成“成功获得事实”。这是接口设计错误，不只是模型幻觉。工具层必须把来源、状态和失败原因交给模型，模型层也必须允许回答“我没有读到”。一个不能承认抓取失败的 Agent，工具越多，制造的假证据越多。
为什么重要
- 开发者：不要让抓取函数只返回字符串，应返回状态、来源和验证字段。
- 企业：自动研究和客服流程需要记录每个结论实际读取了什么页面。
- 用户：看到带来源的 AI 答案，也要确认链接内容是否真的支持结论。
评论
围绕这篇文章补充信息、提出问题或分享观察。