OC

Knowledge OS
AI Agent 被 Cloudflare 挡住后,为什么还会自信地胡说
科技 · 2026-07-11 · 人工智能与开发 · 阅读 0

AI Agent 被 Cloudflare 挡住后,为什么还会自信地胡说

作者:陈墨|OC 技术编辑

作者:陈墨|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 的文章同时推广自己的抓取服务,因此其中“绕过限制”的方案不能照单全收。对于普通产品,更可靠的改进不是不断伪装浏览器,而是让失败变得可见:工具应返回 blockedchallenge_pagerobots_deniedlogin_required 等结构化状态;模型必须引用实际抓取片段;没有正文时应停止,而不是自动搜索记忆补齐。

还可以加入一些便宜的检测:目标标题是否出现、正文与域名是否匹配、页面是否包含 Cloudflare/DataDome 常见挑战文本、内容长度是否异常、不同抓取路径得到的哈希是否一致。Agent 最重要的能力之一不是“总能给答案”,而是知道证据什么时候不存在。

关键事实

  • Cloudflare 官方提供 AI Crawl Control,站长可以按爬虫和用途允许或阻止访问。
  • 拦截可能表现为403,也可能返回带挑战内容的正常 HTML 页面。
  • 原文案例来自抓取服务提供商,关于效果与覆盖率的主张需要独立验证。
  • 绕过反爬可能违反网站条款;识别失败与尊重访问规则是不同问题。

OC 判断

Agent 产品常把“网页工具返回了文本”误当成“成功获得事实”。这是接口设计错误,不只是模型幻觉。工具层必须把来源、状态和失败原因交给模型,模型层也必须允许回答“我没有读到”。一个不能承认抓取失败的 Agent,工具越多,制造的假证据越多。

为什么重要

  • 开发者:不要让抓取函数只返回字符串,应返回状态、来源和验证字段。
  • 企业:自动研究和客服流程需要记录每个结论实际读取了什么页面。
  • 用户:看到带来源的 AI 答案,也要确认链接内容是否真的支持结论。

参考来源

相关阅读

基于标题、摘要和正文内容自动匹配。

更多科技

评论

围绕这篇文章补充信息、提出问题或分享观察。

0
暂无评论。

发表评论