“The Cloudflare AI Psychosis”并不是一个官方术语我把它用来描述 AI 应用部署到 Cloudflare 之后最常见的两类“疯癫”现象流量层的 Bot 混乱以及模型层的幻觉输出。很多团队把模型接口接入 Cloudflare 后先遇到的是后台 Security - Bots 面板里 AI 爬虫数量忽高忽低再遇到接口出现 403、超时、返回内容前后矛盾最后才发现问题并不是模型选型而是整条链路缺少可控的入口和可回滚的策略。这篇文章会以 Cloudflare 作为入口围绕“AI 流量治理”和“AI 幻觉治理”两条主线讲清楚怎么配置 Bots 管理、接入 Workers AI 或自建模型网关、用 AI Gateway 统一请求以及如何把幻觉问题变成可观测、可验证、可回归的工程问题。全文会从概念解释、环境准备、配置步骤、代码实现、故障排查到生产检查清单展开。读者无论是正在做 AI 应用开发还是负责 AI 服务的稳定性都可以按照这篇文章的顺序先在测试环境跑通最小链路再逐步补充生产需要的限流、缓存、日志和回滚机制。1. 先理解 “AI Psychosis” 在实际项目中指什么1.1 流量层的“疯癫”AI 爬虫和 Bot 请求难以分辨AI 应用对外提供服务后外部流量并不只有真实用户。GPTBot、ClaudeBot、Google-Extended、CCBot 等 AI 爬虫会按自己的策略访问站点有的用于训练数据采集有的用于检索增强有的只是扫描公开接口。Cloudflare 后台的 Security - Bots 页面会把这类流量单独归类但如果 Bots Management 模式设置不当就会出现两种相反的问题设置过严时正常搜索引擎和 AI 摘要服务也被拦截设置过松时恶意扫描器又混在 AI Agent 流量里打满接口。这种“乱了”的状态就是流量层的 AI Psychosis。它并不是模型本身的问题而是入口策略没有匹配当前流量特征。正常 AI Agent 调用接口时一般在请求头中带有明确的 User-Agent 或 Bearer Token恶意爬虫则经常伪造 UA或者直接扫描/v1/chat/completions、/api/generate这类路径。如果不在 Cloudflare 边缘层做区分所有请求都会进入模型服务最后表现为并发飙升、账单异常、接口超时。1.2 模型层的“疯癫”AI 幻觉如何变成线上故障模型层的“疯癫”就是大家熟悉的 AI 幻觉。模型为了生成连贯文本可能编造不存在的 API、错误的日期、虚假的引用来源。在对话演示中幻觉只是看起来不够聪明在线上故障中幻觉可能被用户截图、被客服系统直接发送、被下游流程当成事实写入数据库问题就会放大。幻觉并不是模型单独造成的。同一个 Prompt 在不同温度、不同上下文长度、不同模型版本下输出差异可能很大。如果应用层没有输出校验也没有把用户反馈返回给评估链路那么每次模型更新都可能带来新的“疯癫”内容。更麻烦的是一旦 AI Gateway 或 CDN 把包含幻觉的响应缓存下来错误内容会被反复返回排查时很难判断是模型问题还是缓存问题。1.3 为什么用 Cloudflare 治理这两类问题Cloudflare 在 AI 应用链路中的价值是提供一个统一的边缘入口。Bots Management 可以区分 AI 爬虫和普通用户WAF 可以按路径、UA、ASN 做访问控制AI Gateway 可以统一模型调用、缓存、限流和日志Workers AI 可以直接运行模型而不用管理 GPU。这些能力解决的是“入口可控、请求可审计、错误可回滚”并不会直接消除幻觉但幻觉治理需要的请求日志、响应记录、回放能力和灰度能力Cloudflare 这一层都能提供。所以治理 AI Psychosis 的正确思路是先用 Cloudflare 把外部流量管住再在应用层建立模型输出的校验和回归机制。这样即使模型产生幻觉也只是单个请求的局部问题不会扩散成全站故障。2. 从 Cloudflare 后台 Bots 管理开始确认流量入口是否可控2.1 先理解 Bots Management 的三种常见模式进入 Cloudflare 后台后在 Security - Bots 页面可以配置 Bots Management。不同套餐显示的选项会稍有差异但核心逻辑可以归纳为三种模式严格、宽松、自定义。理解这三种模式比直接点按钮更重要。模式默认行为适用场景主要风险严格高置信度 Bot 直接拦截验证过的搜索引擎也可能被判为可疑核心 API、登录接口、支付回调误伤正常 AI Agent 和搜索引擎爬虫宽松只对明显恶意 Bot 做质询验证过的爬虫和 AI Agent 可以放行内容站点、AI 应用入口恶意流量可能混入需要依赖 WAF 补充自定义按 UA、路径、ASN、IP 等条件组合控制需要精细化放行和拦截配置复杂规则顺序错误会导致放行失效这里要特别注意“严格”不等于“安全”。如果模式设置为严格GPTBot、ClaudeBot 这类爬虫可能被质询或拦截表面看流量减少了但搜索引擎的抓取、AI 摘要的引用也可能一起减少。对 AI 应用来说AI Agent 访问接口时通常带有服务账号 Token不应该依赖 Bot 模式放行而是通过 WAF 规则按路径和 Token 校验来控制。2.2 把 Bots 模式从严格调整为合适级别避免误伤 AI Agent如果后台显示 Bots Management 模式是“严格”并且线上接口开始出现大量 403尤其是在调用方是合法的 AI Agent 时优先把这个模式调成宽松或自定义。操作路径一般是打开 Cloudflare 控制台选择对应域名。进入 Security - Bots。在 Bots Management 或 Super Bot Fight Mode 配置区域把模式从严格改为宽松。打开“允许验证通过的爬虫”或类似选项确保 Googlebot、Bingbot 等已验证 UA 不受影响。保存后等待 30 秒到 1 分钟再用真实 User-Agent 和模拟 AI 爬虫 UA 分别验证。调整之后不代表所有 Bot 都被放行。Cloudflare 仍然会对明显恶意流量做质询只是不再一刀切拦截。对于 AI 应用自己的接口推荐的做法是不对“是不是 Bot”做唯一判断而是对“是否有有效身份”做判断。也就是在 WAF 层先校验 Token 或签名再决定是否放行。2.3 用 WAF 自定义规则放行或拦截指定 AI 爬虫当预设模式无法满足需求时可以进入 Security - WAF - Custom Rules创建自定义规则。下面是一个示例规则用于拦截伪造 UA 的 /v1/chat/completions 扫描同时放行带有效服务 Token 的请求{ name: Protect AI Completion Endpoint, expression: (http.request.uri.path eq \/v1/chat/completions\ and not http.request.headers[\authorization\][0] matches \^Bearer sk-live-\), action: managed_challenge }这个规则的思路是对访问/v1/chat/completions的请求如果没有以Bearer sk-live-开头的授权头就进入托管质询。质询通过后可以继续访问质询失败则拦截。相比直接 Block这种方式能减少对正常调用的误伤。如果要按 User-Agent 精确放行某个 AI 爬虫可以使用类似这样的表达式{ expression: (http.user_agent contains \GPTBot\ and http.request.uri.path starts \/robots.txt\), action: allow }实际配置时路径、Token 前缀、UA 名称都要按自己的业务调整。这里的关键是不要在 WAF 层把所有 AI 爬虫都当成攻击者也不要完全信任 User-Agent。UA 很容易伪造真正可靠的还是 Token 和签名。注意自定义规则有顺序优先级第一条命中的规则会决定最终动作。放行规则要放在拦截规则之前否则即使写了放行也可能先被拦截规则处理。3. 在 Cloudflare 上接入 AI 应用Workers AI 与本地模型网关对比3.1 Workers AI 适合快速原型但生产环境需要考虑成本Workers AI 是 Cloudflare 提供的模型推理服务最大的优点是省去 GPU 运维。一个 Worker 可以调用env.AI.run直接跑模型适合做原型验证和低频场景。下面是一个最小 Worker 示例用于处理对话请求export default { async fetch(request, env, ctx) { if (request.method ! POST) { return new Response(Method Not Allowed, { status: 405 }); } try { const payload await request.json(); const messages Array.isArray(payload.messages) ? payload.messages : [{ role: user, content: String(payload.message || ) }]; const result await env.AI.run( cf/meta/llama-3.1-8b-instruct, { messages, temperature: 0.2 } ); return Response.json({ result }); } catch (error) { return Response.json({ error: error.message }, { status: 500 }); } } }对应的wrangler.toml配置如下name ai-demo main src/index.js compatibility_date 2024-12-01 [ai] binding AI实际运行时模型名称要以 Cloudflare Workers AI 文档中当前支持的模型列表为准。不同模型对上下文长度的限制不同温度参数也可能影响输出质量。这个例子的重点不是具体模型而是把“调用模型”和“暴露 HTTP 接口”串起来让 Cloudflare 边缘层成为统一入口。3.2 自建模型网关时Cloudflare 作为反向代理如果团队已经有本地 GPU 推理服务比如 vLLM、Ollama、Triton推荐用 Cloudflare Tunnel 把本地服务安全地暴露到公网而不是直接开放防火墙端口。这样 Cloudflare 负责 DDoS 防护、WAF、Bots 管理本地推理服务只接受来自 Tunnel 的请求。假设本地推理服务监听127.0.0.1:8000可以使用cloudflared tunnel将llm.example.com转发到该端口。在cloudflared的配置文件中核心是一段 ingress 规则tunnel: your-tunnel-name credentials-file: /home/user/.cloudflared/your-tunnel-name.json ingress: - hostname: llm.example.com service: http://127.0.0.1:8000 - service: http_status:404启动 Tunnel 前需要在 Cloudflare 后台添加对应的 DNS CNAME 记录指向 Tunnel。之后访问llm.example.com的流量会经过 Cloudflare 边缘再通过 Tunnel 进入本地服务。这种架构的好处是本地网络不用暴露公网 IP出站连接由 cloudflared 主动建立攻击面小很多。3.3 推荐架构边缘层、网关层、推理层分离综合上面两种方式推荐的生产架构可以分成三层边缘层Cloudflare负责 DNS、CDN、WAF、Bots Management、速率限制。网关层业务 API 或 AI Gateway负责身份校验、模型路由、缓存、限流、日志。推理层Workers AI、本地 vLLM、第三方模型 API负责真正的模型推理。Gateway 层是这套架构的关键。它把“谁来调用”“调用哪个模型”“返回什么内容”变成可配置的规则。比如可以在网关层判断某个请求是否来自已登录用户再决定使用快模型还是慢模型也可以在网关层记录每个 Prompt 和输出方便后续做幻觉回归分析。这样即使底层模型服务出现异常也只需要调整网关路由不需要改动边缘层。4. 用 AI Gateway 实现请求缓存、限流和日志减少幻觉放大4.1 AI Gateway 重点解决哪三类问题Cloudflare AI Gateway 是一个面向 AI 请求的代理层。它并不是模型提供方而是统一入口。重点解决三类问题统一协议多个模型服务有不同的 API 格式Gateway 可以把请求转成统一格式也可以把不同模型的响应转成统一结构。缓存与成本控制相同 Prompt 在相同参数下可能得到相同结果缓存后可以减少重复推理降低成本和延迟。可观测与回放每次请求和响应都记录日志线上出现幻觉时可以定位到具体 Prompt、模型版本、温度参数和响应内容。4.2 配置一个统一的 /ai/completions 入口在 Cloudflare AI Gateway 中创建 Gateway 后会得到一个专属 Endpoint。业务 Worker 可以把请求转发给这个 Endpoint而不是直接调用某个模型 API。下面是一个用 Worker 转发请求的示例const GATEWAY_URL https://gateway.ai.cloudflare.com/v1/your-account-id/your-gateway/; export default { async fetch(request, env, ctx) { const body await request.json(); const response await fetch(${GATEWAY_URL}openai/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: request.headers.get(Authorization) || }, body: JSON.stringify({ model: body.model || cf/meta/llama-3.1-8b-instruct, messages: body.messages || [], temperature: body.temperature ?? 0.3 }) }); const data await response.json(); return Response.json(data, { status: response.status }); } };实际使用中your-account-id和your-gateway需要替换成自己的账号和网关名称。Gateway 地址也可能因区域或套餐不同而变化落地前要以官方文档为准。可以在本地先用 curl 验证curl -X POST \ https://gateway.ai.cloudflare.com/v1/your-account-id/your-gateway/openai/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-test \ -d {model:cf/meta/llama-3.1-8b-instruct,messages:[{role:user,content:Hello}],temperature:0.3}重点不是 Endpoint 的精确路径而是请求链路的可观测性每一条请求经过 Gateway 后都应该能看到耗时、Token 消耗、返回状态和响应体。4.3 缓存命中与动态开关避免错误响应扩散AI Gateway 的缓存能力在降本的同时也带来一个隐患如果某个包含幻觉的响应被缓存了后续相同 Prompt 会一直返回错误内容。配置缓存时需要注意以下几点缓存键要包含模型名、上下文版本、temperature 和 messages 的哈希不能只用 Prompt 文本。对 4xx、5xx 响应不要缓存否则错误状态会被当作正常结果。模型版本升级后要主动刷新缓存避免旧版本输出继续被命中。在网关层加一个动态开关发生幻觉或模型异常时可以临时关闭缓存让流量直接回源。这样可以做到“错误可以被快速放大也能被快速停止”。如果没有网关层一旦缓存了错误响应只能等缓存过期或者直接清空整张缓存表影响面会更大。5. AI 幻觉治理从提示词到输出校验的完整链路5.1 幻觉不是模型单独的问题而是链路问题治理幻觉的第一步是要承认它不是一个可以通过调一个参数解决掉的问题。同一个模型提示词里缺少限定条件时会编造上下文过长时会遗忘温度过高时会发散。所以完整的治理链路至少包括四层提示词层明确要求模型标注不确定性禁止编造引用。输入层限制上下文长度只给模型相关内容。输出层对返回内容做格式校验、引用校验、相似度校验。反馈层把用户反馈和线上日志回流到测试集。5.2 在应用层加入输出校验和事实核查在拿到模型输出后不要直接返回给用户先做一次校验。下面是一个 Python 示例演示了“长度校验 引用来源校验 向量相似度校验”的组合import re def validate_model_output(prompt: str, output: str, min_length: int 20): errors [] if len(output.strip()) min_length: errors.append(output_too_short) # 检查是否包含虚构的 http 链接 urls re.findall(rhttps?://\S, output) for url in urls: if not is_url_in_allowlist(url): errors.append(funverified_url:{url}) # 检查是否包含与 Prompt 无关的高置信断言 if 一定 in output or 绝对 in output: errors.append(over_confident) if errors: return { passed: False, output: output, errors: errors, fallback: 我不确定这个问题的答案建议您查阅官方资料。 } return {passed: True, output: output, errors: []} def is_url_in_allowlist(url: str) - bool: allowlist_domains [example.com, docs.example.org] return any(domain in url for domain in allowlist_domains)这个示例的核心是“先校验再返回”。如果校验不通过返回一个固定的兜底文案而不是把模型输出直接发给用户。校验规则可以根据业务扩展比如对包含 JSON 的响应做字段完整性校验对包含温度的响应做数值范围校验。5.3 基于日志和评价数据建立幻觉回归集比单次校验更重要的是建立长期回归机制。每次线上请求和响应都可以通过 AI Gateway 记录下来运维或算法同学定期抽取典型样本标注哪些输出是幻觉放入回归集。发布新模型或修改提示词时用回归集批量跑一遍观察通过率。实践中可以用一个非常简单的评分脚本cases [ {prompt: 介绍一下项目截止日期, expected: 2025-06-30, pos_keywords: [2025-06-30]}, {prompt: 列出官方支持的模型, expected: , neg_keywords: [不存在的模型X]}, ] def run_regression(model_fn): passed 0 for case in cases: output model_fn(case[prompt]) ok True for kw in case.get(pos_keywords, []): if kw not in output: ok False for kw in case.get(neg_keywords, []): if kw in output: ok False if ok: passed 1 return passed / len(cases)回归集的价值是让幻觉治理从“感觉模型不太稳定”变成“本次变更后通过率下降了 8 个百分点”。只有能度量的状态才能进入迭代流程。注意不要把回归集做成静态数据。线上新的幻觉样本要定期补充否则回归集只能覆盖旧问题无法防止新问题。6. 典型故障排查流量异常、403、超时和胡说八道6.1 AI 爬虫导致并发激增接口超时现象Cloudflare 后台 Security Events 里出现大量 AI 爬虫请求模型接口响应时间变长偶发 504。可能原因Bots Management 模式过松或者 WAF 规则没有覆盖 AI 接口路径。AI 爬虫在抓取页面时可能顺带请求了公开的 API 路径。检查方式进入 Security - Events按 Host 和 Path 筛选查看请求 Top User-Agent对比请求量和模型服务 CPU/GPU 使用率。处理建议在 WAF 层对/v1/chat/completions等接口加上身份校验非白名单 UA 或没有 Token 的请求直接 Managed Challenge。同时在 AI Gateway 配置速率限制控制单 IP 或单账号的请求频率。6.2 Cloudflare 返回 403 或 Managed Challenge影响正常调用现象调用方是合法的服务却收到 Cloudflare 的 403 或 JS 质询页面。可能原因Bots Management 设置为严格或者 WAF 自定义规则把服务 UA 误判为攻击者也可能是 IP 被集中标记。检查方式用相同的 UA 和路径在本地 curl 测试对比加不加 Cloudflare 的差异查看 Security Events 中该请求命中了哪条规则确认请求是否缺少必要的 Header。处理建议把 Bots 模式调整为宽松或自定义并在 WAF 规则中放行白名单 UA 和 Token。如果服务端调用方使用固定 IP还可以在 WAF 中按 IP 加白。要注意IP 加白只适合可信的内部服务不适合开放给外部用户。6.3 模型返回内容前后矛盾线上反馈变差现象同一类问题在不同时间返回不同答案其中一部分明显是编造。可能原因模型版本变更、缓存命中了旧版本、温度过高、上下文被截断、提示词没有约束知识边界。检查方式在 AI Gateway 日志中对比相同 Prompt 的多次请求检查模型名称、temperature、请求时间和响应内容确认是否命中缓存查看上下文是否被截断。处理建议为模型配置固定版本不要使用“默认最新版本”把 temperature 控制到 0.2 以下在提示词中明确“超出知识范围时回答不知道”对输出做引用校验。6.4 排查链路与常用命令从问题现象到根因可以按照这个顺序排查确认请求是否到达 Cloudflare查看 Security Events 或curl -I响应头中的cf-ray。确认是否被 WAF 拦截查看 Security Events 中匹配的规则名称。确认是否被 Bots 拦截查看cf-mitigated响应头。确认是否到达模型服务查看 Gateway 日志、推理服务日志。确认是输入问题还是模型问题用相同 Prompt 在测试环境复现。常用命令示例# 查看响应头和 cf-ray curl -I https://llm.example.com/v1/chat/completions # 查看 cloudflared tunnel 日志 cloudflared tunnel info your-tunnel-name # 查看 Worker 实时日志 npx wrangler tail ai-demo这里最关键的是不要跳层。很多 403 问题直接被归因为“模型挂了”但实际上请求在 Cloudflare 边缘层就被拦截了。先看响应头和 Edge 日志能省掉大量无效排查时间。7. 生产环境最佳实践与发布前检查清单7.1 学习环境和生产环境要分开学习环境可以追求快速跑通生产环境必须有稳定性和安全兜底。两者差异如下维度学习环境测试环境生产环境Bots 模式可以随便切换使用宽松模式使用自定义模式 白名单模型版本使用默认最新固定版本固定版本发版前灰度缓存可开启可关闭开启但短过期按版本隔离支持手动刷新日志看控制台结构化日志接入日志平台和告警错误处理直接返回异常校验输出校验 兜底 降级成本控制不关心简单限流账号级配额 实时告警在测试环境验证通过不代表生产环境可以直接复用同一套配置。尤其是 WAF 规则、缓存策略、模型版本都要在发布前重新审视一遍。7.2 发布前检查清单发布 AI 应用前建议逐项确认以下清单[ ] Cloudflare Bots Management 模式不是“严格”且已放行已验证爬虫。[ ] WAF 自定义规则中放行规则位于拦截规则之前。[ ] AI 接口路径已经通过 WAF 或应用层校验身份不裸奔在公网。[ ] AI Gateway 缓存键包含模型名、版本、参数和消息哈希。[ ] 4xx 和 5xx 响应不在缓存范围内。[ ] 模型版本已固定不使用“latest”。[ ] 输出校验逻辑已覆盖至少一个业务核心场景并有兜底文案。[ ] 幻觉回归集已建立且包含最近一周的线上失败样本。[ ] cloudflared Tunnel 日志已接入日志平台。[ ] 已配置速率限制单 IP 或单账号的限额符合业务预期。[ ] 发生模型故障时可以快速切换网关路由到备用模型。这份清单可以在每次发版前跑一遍。不要等到线上出现“AI Psychosis”才开始检查。7.3 下一步可以扩展的方向如果在 Cloudflare 上完成了流量治理和幻觉校验下一步可以从三个方向继续深入接入 RAG把幻觉治理从“事后校验”升级为“事前进制”让模型只基于检索到的资料回答减少编造空间。建立模型评测平台把线上日志、回归集、人工标注统一起来形成模型选型和质量看板。完善降级策略当模型服务超时或输出校验失败时自动切换模型、返回缓存答案或引入人工客服避免用户得到错误结果。“The Cloudflare AI Psychosis”看起来是标题党但它指向的问题非常真实AI 应用不是能调通模型接口就结束了流量混乱、幻觉扩散、错误被缓存放大这些才是线上稳定性的真正敌人。先把 Cloudflare 边缘层管好再在应用层建立校验和回归体系AI 应用才能真正从“能跑”变成“能用”。
用Cloudflare治理AI应用流量与幻觉问题
“The Cloudflare AI Psychosis”并不是一个官方术语我把它用来描述 AI 应用部署到 Cloudflare 之后最常见的两类“疯癫”现象流量层的 Bot 混乱以及模型层的幻觉输出。很多团队把模型接口接入 Cloudflare 后先遇到的是后台 Security - Bots 面板里 AI 爬虫数量忽高忽低再遇到接口出现 403、超时、返回内容前后矛盾最后才发现问题并不是模型选型而是整条链路缺少可控的入口和可回滚的策略。这篇文章会以 Cloudflare 作为入口围绕“AI 流量治理”和“AI 幻觉治理”两条主线讲清楚怎么配置 Bots 管理、接入 Workers AI 或自建模型网关、用 AI Gateway 统一请求以及如何把幻觉问题变成可观测、可验证、可回归的工程问题。全文会从概念解释、环境准备、配置步骤、代码实现、故障排查到生产检查清单展开。读者无论是正在做 AI 应用开发还是负责 AI 服务的稳定性都可以按照这篇文章的顺序先在测试环境跑通最小链路再逐步补充生产需要的限流、缓存、日志和回滚机制。1. 先理解 “AI Psychosis” 在实际项目中指什么1.1 流量层的“疯癫”AI 爬虫和 Bot 请求难以分辨AI 应用对外提供服务后外部流量并不只有真实用户。GPTBot、ClaudeBot、Google-Extended、CCBot 等 AI 爬虫会按自己的策略访问站点有的用于训练数据采集有的用于检索增强有的只是扫描公开接口。Cloudflare 后台的 Security - Bots 页面会把这类流量单独归类但如果 Bots Management 模式设置不当就会出现两种相反的问题设置过严时正常搜索引擎和 AI 摘要服务也被拦截设置过松时恶意扫描器又混在 AI Agent 流量里打满接口。这种“乱了”的状态就是流量层的 AI Psychosis。它并不是模型本身的问题而是入口策略没有匹配当前流量特征。正常 AI Agent 调用接口时一般在请求头中带有明确的 User-Agent 或 Bearer Token恶意爬虫则经常伪造 UA或者直接扫描/v1/chat/completions、/api/generate这类路径。如果不在 Cloudflare 边缘层做区分所有请求都会进入模型服务最后表现为并发飙升、账单异常、接口超时。1.2 模型层的“疯癫”AI 幻觉如何变成线上故障模型层的“疯癫”就是大家熟悉的 AI 幻觉。模型为了生成连贯文本可能编造不存在的 API、错误的日期、虚假的引用来源。在对话演示中幻觉只是看起来不够聪明在线上故障中幻觉可能被用户截图、被客服系统直接发送、被下游流程当成事实写入数据库问题就会放大。幻觉并不是模型单独造成的。同一个 Prompt 在不同温度、不同上下文长度、不同模型版本下输出差异可能很大。如果应用层没有输出校验也没有把用户反馈返回给评估链路那么每次模型更新都可能带来新的“疯癫”内容。更麻烦的是一旦 AI Gateway 或 CDN 把包含幻觉的响应缓存下来错误内容会被反复返回排查时很难判断是模型问题还是缓存问题。1.3 为什么用 Cloudflare 治理这两类问题Cloudflare 在 AI 应用链路中的价值是提供一个统一的边缘入口。Bots Management 可以区分 AI 爬虫和普通用户WAF 可以按路径、UA、ASN 做访问控制AI Gateway 可以统一模型调用、缓存、限流和日志Workers AI 可以直接运行模型而不用管理 GPU。这些能力解决的是“入口可控、请求可审计、错误可回滚”并不会直接消除幻觉但幻觉治理需要的请求日志、响应记录、回放能力和灰度能力Cloudflare 这一层都能提供。所以治理 AI Psychosis 的正确思路是先用 Cloudflare 把外部流量管住再在应用层建立模型输出的校验和回归机制。这样即使模型产生幻觉也只是单个请求的局部问题不会扩散成全站故障。2. 从 Cloudflare 后台 Bots 管理开始确认流量入口是否可控2.1 先理解 Bots Management 的三种常见模式进入 Cloudflare 后台后在 Security - Bots 页面可以配置 Bots Management。不同套餐显示的选项会稍有差异但核心逻辑可以归纳为三种模式严格、宽松、自定义。理解这三种模式比直接点按钮更重要。模式默认行为适用场景主要风险严格高置信度 Bot 直接拦截验证过的搜索引擎也可能被判为可疑核心 API、登录接口、支付回调误伤正常 AI Agent 和搜索引擎爬虫宽松只对明显恶意 Bot 做质询验证过的爬虫和 AI Agent 可以放行内容站点、AI 应用入口恶意流量可能混入需要依赖 WAF 补充自定义按 UA、路径、ASN、IP 等条件组合控制需要精细化放行和拦截配置复杂规则顺序错误会导致放行失效这里要特别注意“严格”不等于“安全”。如果模式设置为严格GPTBot、ClaudeBot 这类爬虫可能被质询或拦截表面看流量减少了但搜索引擎的抓取、AI 摘要的引用也可能一起减少。对 AI 应用来说AI Agent 访问接口时通常带有服务账号 Token不应该依赖 Bot 模式放行而是通过 WAF 规则按路径和 Token 校验来控制。2.2 把 Bots 模式从严格调整为合适级别避免误伤 AI Agent如果后台显示 Bots Management 模式是“严格”并且线上接口开始出现大量 403尤其是在调用方是合法的 AI Agent 时优先把这个模式调成宽松或自定义。操作路径一般是打开 Cloudflare 控制台选择对应域名。进入 Security - Bots。在 Bots Management 或 Super Bot Fight Mode 配置区域把模式从严格改为宽松。打开“允许验证通过的爬虫”或类似选项确保 Googlebot、Bingbot 等已验证 UA 不受影响。保存后等待 30 秒到 1 分钟再用真实 User-Agent 和模拟 AI 爬虫 UA 分别验证。调整之后不代表所有 Bot 都被放行。Cloudflare 仍然会对明显恶意流量做质询只是不再一刀切拦截。对于 AI 应用自己的接口推荐的做法是不对“是不是 Bot”做唯一判断而是对“是否有有效身份”做判断。也就是在 WAF 层先校验 Token 或签名再决定是否放行。2.3 用 WAF 自定义规则放行或拦截指定 AI 爬虫当预设模式无法满足需求时可以进入 Security - WAF - Custom Rules创建自定义规则。下面是一个示例规则用于拦截伪造 UA 的 /v1/chat/completions 扫描同时放行带有效服务 Token 的请求{ name: Protect AI Completion Endpoint, expression: (http.request.uri.path eq \/v1/chat/completions\ and not http.request.headers[\authorization\][0] matches \^Bearer sk-live-\), action: managed_challenge }这个规则的思路是对访问/v1/chat/completions的请求如果没有以Bearer sk-live-开头的授权头就进入托管质询。质询通过后可以继续访问质询失败则拦截。相比直接 Block这种方式能减少对正常调用的误伤。如果要按 User-Agent 精确放行某个 AI 爬虫可以使用类似这样的表达式{ expression: (http.user_agent contains \GPTBot\ and http.request.uri.path starts \/robots.txt\), action: allow }实际配置时路径、Token 前缀、UA 名称都要按自己的业务调整。这里的关键是不要在 WAF 层把所有 AI 爬虫都当成攻击者也不要完全信任 User-Agent。UA 很容易伪造真正可靠的还是 Token 和签名。注意自定义规则有顺序优先级第一条命中的规则会决定最终动作。放行规则要放在拦截规则之前否则即使写了放行也可能先被拦截规则处理。3. 在 Cloudflare 上接入 AI 应用Workers AI 与本地模型网关对比3.1 Workers AI 适合快速原型但生产环境需要考虑成本Workers AI 是 Cloudflare 提供的模型推理服务最大的优点是省去 GPU 运维。一个 Worker 可以调用env.AI.run直接跑模型适合做原型验证和低频场景。下面是一个最小 Worker 示例用于处理对话请求export default { async fetch(request, env, ctx) { if (request.method ! POST) { return new Response(Method Not Allowed, { status: 405 }); } try { const payload await request.json(); const messages Array.isArray(payload.messages) ? payload.messages : [{ role: user, content: String(payload.message || ) }]; const result await env.AI.run( cf/meta/llama-3.1-8b-instruct, { messages, temperature: 0.2 } ); return Response.json({ result }); } catch (error) { return Response.json({ error: error.message }, { status: 500 }); } } }对应的wrangler.toml配置如下name ai-demo main src/index.js compatibility_date 2024-12-01 [ai] binding AI实际运行时模型名称要以 Cloudflare Workers AI 文档中当前支持的模型列表为准。不同模型对上下文长度的限制不同温度参数也可能影响输出质量。这个例子的重点不是具体模型而是把“调用模型”和“暴露 HTTP 接口”串起来让 Cloudflare 边缘层成为统一入口。3.2 自建模型网关时Cloudflare 作为反向代理如果团队已经有本地 GPU 推理服务比如 vLLM、Ollama、Triton推荐用 Cloudflare Tunnel 把本地服务安全地暴露到公网而不是直接开放防火墙端口。这样 Cloudflare 负责 DDoS 防护、WAF、Bots 管理本地推理服务只接受来自 Tunnel 的请求。假设本地推理服务监听127.0.0.1:8000可以使用cloudflared tunnel将llm.example.com转发到该端口。在cloudflared的配置文件中核心是一段 ingress 规则tunnel: your-tunnel-name credentials-file: /home/user/.cloudflared/your-tunnel-name.json ingress: - hostname: llm.example.com service: http://127.0.0.1:8000 - service: http_status:404启动 Tunnel 前需要在 Cloudflare 后台添加对应的 DNS CNAME 记录指向 Tunnel。之后访问llm.example.com的流量会经过 Cloudflare 边缘再通过 Tunnel 进入本地服务。这种架构的好处是本地网络不用暴露公网 IP出站连接由 cloudflared 主动建立攻击面小很多。3.3 推荐架构边缘层、网关层、推理层分离综合上面两种方式推荐的生产架构可以分成三层边缘层Cloudflare负责 DNS、CDN、WAF、Bots Management、速率限制。网关层业务 API 或 AI Gateway负责身份校验、模型路由、缓存、限流、日志。推理层Workers AI、本地 vLLM、第三方模型 API负责真正的模型推理。Gateway 层是这套架构的关键。它把“谁来调用”“调用哪个模型”“返回什么内容”变成可配置的规则。比如可以在网关层判断某个请求是否来自已登录用户再决定使用快模型还是慢模型也可以在网关层记录每个 Prompt 和输出方便后续做幻觉回归分析。这样即使底层模型服务出现异常也只需要调整网关路由不需要改动边缘层。4. 用 AI Gateway 实现请求缓存、限流和日志减少幻觉放大4.1 AI Gateway 重点解决哪三类问题Cloudflare AI Gateway 是一个面向 AI 请求的代理层。它并不是模型提供方而是统一入口。重点解决三类问题统一协议多个模型服务有不同的 API 格式Gateway 可以把请求转成统一格式也可以把不同模型的响应转成统一结构。缓存与成本控制相同 Prompt 在相同参数下可能得到相同结果缓存后可以减少重复推理降低成本和延迟。可观测与回放每次请求和响应都记录日志线上出现幻觉时可以定位到具体 Prompt、模型版本、温度参数和响应内容。4.2 配置一个统一的 /ai/completions 入口在 Cloudflare AI Gateway 中创建 Gateway 后会得到一个专属 Endpoint。业务 Worker 可以把请求转发给这个 Endpoint而不是直接调用某个模型 API。下面是一个用 Worker 转发请求的示例const GATEWAY_URL https://gateway.ai.cloudflare.com/v1/your-account-id/your-gateway/; export default { async fetch(request, env, ctx) { const body await request.json(); const response await fetch(${GATEWAY_URL}openai/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: request.headers.get(Authorization) || }, body: JSON.stringify({ model: body.model || cf/meta/llama-3.1-8b-instruct, messages: body.messages || [], temperature: body.temperature ?? 0.3 }) }); const data await response.json(); return Response.json(data, { status: response.status }); } };实际使用中your-account-id和your-gateway需要替换成自己的账号和网关名称。Gateway 地址也可能因区域或套餐不同而变化落地前要以官方文档为准。可以在本地先用 curl 验证curl -X POST \ https://gateway.ai.cloudflare.com/v1/your-account-id/your-gateway/openai/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-test \ -d {model:cf/meta/llama-3.1-8b-instruct,messages:[{role:user,content:Hello}],temperature:0.3}重点不是 Endpoint 的精确路径而是请求链路的可观测性每一条请求经过 Gateway 后都应该能看到耗时、Token 消耗、返回状态和响应体。4.3 缓存命中与动态开关避免错误响应扩散AI Gateway 的缓存能力在降本的同时也带来一个隐患如果某个包含幻觉的响应被缓存了后续相同 Prompt 会一直返回错误内容。配置缓存时需要注意以下几点缓存键要包含模型名、上下文版本、temperature 和 messages 的哈希不能只用 Prompt 文本。对 4xx、5xx 响应不要缓存否则错误状态会被当作正常结果。模型版本升级后要主动刷新缓存避免旧版本输出继续被命中。在网关层加一个动态开关发生幻觉或模型异常时可以临时关闭缓存让流量直接回源。这样可以做到“错误可以被快速放大也能被快速停止”。如果没有网关层一旦缓存了错误响应只能等缓存过期或者直接清空整张缓存表影响面会更大。5. AI 幻觉治理从提示词到输出校验的完整链路5.1 幻觉不是模型单独的问题而是链路问题治理幻觉的第一步是要承认它不是一个可以通过调一个参数解决掉的问题。同一个模型提示词里缺少限定条件时会编造上下文过长时会遗忘温度过高时会发散。所以完整的治理链路至少包括四层提示词层明确要求模型标注不确定性禁止编造引用。输入层限制上下文长度只给模型相关内容。输出层对返回内容做格式校验、引用校验、相似度校验。反馈层把用户反馈和线上日志回流到测试集。5.2 在应用层加入输出校验和事实核查在拿到模型输出后不要直接返回给用户先做一次校验。下面是一个 Python 示例演示了“长度校验 引用来源校验 向量相似度校验”的组合import re def validate_model_output(prompt: str, output: str, min_length: int 20): errors [] if len(output.strip()) min_length: errors.append(output_too_short) # 检查是否包含虚构的 http 链接 urls re.findall(rhttps?://\S, output) for url in urls: if not is_url_in_allowlist(url): errors.append(funverified_url:{url}) # 检查是否包含与 Prompt 无关的高置信断言 if 一定 in output or 绝对 in output: errors.append(over_confident) if errors: return { passed: False, output: output, errors: errors, fallback: 我不确定这个问题的答案建议您查阅官方资料。 } return {passed: True, output: output, errors: []} def is_url_in_allowlist(url: str) - bool: allowlist_domains [example.com, docs.example.org] return any(domain in url for domain in allowlist_domains)这个示例的核心是“先校验再返回”。如果校验不通过返回一个固定的兜底文案而不是把模型输出直接发给用户。校验规则可以根据业务扩展比如对包含 JSON 的响应做字段完整性校验对包含温度的响应做数值范围校验。5.3 基于日志和评价数据建立幻觉回归集比单次校验更重要的是建立长期回归机制。每次线上请求和响应都可以通过 AI Gateway 记录下来运维或算法同学定期抽取典型样本标注哪些输出是幻觉放入回归集。发布新模型或修改提示词时用回归集批量跑一遍观察通过率。实践中可以用一个非常简单的评分脚本cases [ {prompt: 介绍一下项目截止日期, expected: 2025-06-30, pos_keywords: [2025-06-30]}, {prompt: 列出官方支持的模型, expected: , neg_keywords: [不存在的模型X]}, ] def run_regression(model_fn): passed 0 for case in cases: output model_fn(case[prompt]) ok True for kw in case.get(pos_keywords, []): if kw not in output: ok False for kw in case.get(neg_keywords, []): if kw in output: ok False if ok: passed 1 return passed / len(cases)回归集的价值是让幻觉治理从“感觉模型不太稳定”变成“本次变更后通过率下降了 8 个百分点”。只有能度量的状态才能进入迭代流程。注意不要把回归集做成静态数据。线上新的幻觉样本要定期补充否则回归集只能覆盖旧问题无法防止新问题。6. 典型故障排查流量异常、403、超时和胡说八道6.1 AI 爬虫导致并发激增接口超时现象Cloudflare 后台 Security Events 里出现大量 AI 爬虫请求模型接口响应时间变长偶发 504。可能原因Bots Management 模式过松或者 WAF 规则没有覆盖 AI 接口路径。AI 爬虫在抓取页面时可能顺带请求了公开的 API 路径。检查方式进入 Security - Events按 Host 和 Path 筛选查看请求 Top User-Agent对比请求量和模型服务 CPU/GPU 使用率。处理建议在 WAF 层对/v1/chat/completions等接口加上身份校验非白名单 UA 或没有 Token 的请求直接 Managed Challenge。同时在 AI Gateway 配置速率限制控制单 IP 或单账号的请求频率。6.2 Cloudflare 返回 403 或 Managed Challenge影响正常调用现象调用方是合法的服务却收到 Cloudflare 的 403 或 JS 质询页面。可能原因Bots Management 设置为严格或者 WAF 自定义规则把服务 UA 误判为攻击者也可能是 IP 被集中标记。检查方式用相同的 UA 和路径在本地 curl 测试对比加不加 Cloudflare 的差异查看 Security Events 中该请求命中了哪条规则确认请求是否缺少必要的 Header。处理建议把 Bots 模式调整为宽松或自定义并在 WAF 规则中放行白名单 UA 和 Token。如果服务端调用方使用固定 IP还可以在 WAF 中按 IP 加白。要注意IP 加白只适合可信的内部服务不适合开放给外部用户。6.3 模型返回内容前后矛盾线上反馈变差现象同一类问题在不同时间返回不同答案其中一部分明显是编造。可能原因模型版本变更、缓存命中了旧版本、温度过高、上下文被截断、提示词没有约束知识边界。检查方式在 AI Gateway 日志中对比相同 Prompt 的多次请求检查模型名称、temperature、请求时间和响应内容确认是否命中缓存查看上下文是否被截断。处理建议为模型配置固定版本不要使用“默认最新版本”把 temperature 控制到 0.2 以下在提示词中明确“超出知识范围时回答不知道”对输出做引用校验。6.4 排查链路与常用命令从问题现象到根因可以按照这个顺序排查确认请求是否到达 Cloudflare查看 Security Events 或curl -I响应头中的cf-ray。确认是否被 WAF 拦截查看 Security Events 中匹配的规则名称。确认是否被 Bots 拦截查看cf-mitigated响应头。确认是否到达模型服务查看 Gateway 日志、推理服务日志。确认是输入问题还是模型问题用相同 Prompt 在测试环境复现。常用命令示例# 查看响应头和 cf-ray curl -I https://llm.example.com/v1/chat/completions # 查看 cloudflared tunnel 日志 cloudflared tunnel info your-tunnel-name # 查看 Worker 实时日志 npx wrangler tail ai-demo这里最关键的是不要跳层。很多 403 问题直接被归因为“模型挂了”但实际上请求在 Cloudflare 边缘层就被拦截了。先看响应头和 Edge 日志能省掉大量无效排查时间。7. 生产环境最佳实践与发布前检查清单7.1 学习环境和生产环境要分开学习环境可以追求快速跑通生产环境必须有稳定性和安全兜底。两者差异如下维度学习环境测试环境生产环境Bots 模式可以随便切换使用宽松模式使用自定义模式 白名单模型版本使用默认最新固定版本固定版本发版前灰度缓存可开启可关闭开启但短过期按版本隔离支持手动刷新日志看控制台结构化日志接入日志平台和告警错误处理直接返回异常校验输出校验 兜底 降级成本控制不关心简单限流账号级配额 实时告警在测试环境验证通过不代表生产环境可以直接复用同一套配置。尤其是 WAF 规则、缓存策略、模型版本都要在发布前重新审视一遍。7.2 发布前检查清单发布 AI 应用前建议逐项确认以下清单[ ] Cloudflare Bots Management 模式不是“严格”且已放行已验证爬虫。[ ] WAF 自定义规则中放行规则位于拦截规则之前。[ ] AI 接口路径已经通过 WAF 或应用层校验身份不裸奔在公网。[ ] AI Gateway 缓存键包含模型名、版本、参数和消息哈希。[ ] 4xx 和 5xx 响应不在缓存范围内。[ ] 模型版本已固定不使用“latest”。[ ] 输出校验逻辑已覆盖至少一个业务核心场景并有兜底文案。[ ] 幻觉回归集已建立且包含最近一周的线上失败样本。[ ] cloudflared Tunnel 日志已接入日志平台。[ ] 已配置速率限制单 IP 或单账号的限额符合业务预期。[ ] 发生模型故障时可以快速切换网关路由到备用模型。这份清单可以在每次发版前跑一遍。不要等到线上出现“AI Psychosis”才开始检查。7.3 下一步可以扩展的方向如果在 Cloudflare 上完成了流量治理和幻觉校验下一步可以从三个方向继续深入接入 RAG把幻觉治理从“事后校验”升级为“事前进制”让模型只基于检索到的资料回答减少编造空间。建立模型评测平台把线上日志、回归集、人工标注统一起来形成模型选型和质量看板。完善降级策略当模型服务超时或输出校验失败时自动切换模型、返回缓存答案或引入人工客服避免用户得到错误结果。“The Cloudflare AI Psychosis”看起来是标题党但它指向的问题非常真实AI 应用不是能调通模型接口就结束了流量混乱、幻觉扩散、错误被缓存放大这些才是线上稳定性的真正敌人。先把 Cloudflare 边缘层管好再在应用层建立校验和回归体系AI 应用才能真正从“能跑”变成“能用”。