Cloudflare AI 能力选型：从模型接口到检索、Agent 与安全治理
一个聊天接口可以只调用模型；让它回答公司文档、记住会话、打开网页或执行代码，则是四种不同的系统责任。Cloudflare 为这些需求提供多种产品，但不必一次接入全部。先画出数据从用户到模型的路径，再决定哪一段需要托管能力。本篇面向正在规划 AI 应用的开发者；它不替代逐产品的配置文档，也不把账户计划、Beta 资格和价格当作永久承诺。
从一个请求开始
最小路径是客户端请求自己的 Worker，Worker 通过 Workers AI binding 调用模型并返回结果。绑定由运行时注入，Cloudflare API Token 不需要发给浏览器。官方入门提供 C3、ai binding、env.AI.run()、本地测试与部署步骤。本地 wrangler dev 中的推理仍访问 Cloudflare 账户并产生用量；健康检查和拒绝未授权的分支可以先单独测试。
用户 -> 应用鉴权 -> Worker -> Workers AI -> 响应
|
+-> 后续按需要接 Gateway、检索或工具先完成一个有鉴权、输入限制和错误处理的模型调用，再扩展架构。Workers AI 不负责你的用户身份、业务授权和预算策略。模型支持的输入、输出、可用计划和单价应以当前模型目录为准，Worker 请求与模型用量也是两套不同的计量边界。
按问题选择能力
| 实际问题 | 首选能力 | 不应误认成 |
|---|---|---|
| 在 Worker 中调用托管模型 | Workers AI | 业务鉴权或用户配额 |
| 统一多个模型提供商的流量、日志、缓存与限流 | AI Gateway | 对公网应用入口的 WAF |
| 让站点、R2 或上传文档可检索 | AI Search | 通用 SQL 数据库 |
| 自己控制切块、embedding、索引和检索算法 | Vectorize + 自建管线 | 自动完成文档解析的 RAG 产品 |
| 跨请求会话、长连接和调度 | Agents SDK | 每次请求独立的普通 Worker |
| 网页截图、提取或浏览器交互 | Browser Run | 任意 Linux 程序执行 |
| 动态加载短时 JavaScript | Dynamic Workers | 带文件与进程的容器 |
| 运行依赖、文件和进程的隔离任务 | Sandbox SDK | 免费且无需权限审查的工具调用 |
选型先看应用要处理的数据，再看执行边界。下面三条增量路径可以分别验证；任何一条都不要求同时购买其他产品。
例如团队先要让内部文档可问答：单模型接口跑通后，把一组无敏感信息的测试文档交给 AI Search，先确认一个已知问题能命中正确来源、一个无答案问题不会编造来源。此时还不需要 Agents，因为每个请求可以独立完成；也不必先建 Vectorize，除非团队必须控制切块、embedding 或索引重建。后来接入第二家模型，再将测试流量经过 AI Gateway，观察请求是否到达指定 gateway、日志是否按预期只留元数据，并验证超额或上游失败的处理。只有用户真的需要 Agent 打开网页、跨会话记住状态时，才分别评估 Browser Run 和 Agents；每次增加能力都留下一个可观察的验收点。
模型流量需要治理时
应用开始有多个模型、提供商或调用方后，再把请求经过 AI Gateway。官方入门要求 Account ID 和相应权限的 API Token，Workers AI 请求用 cf-aig-gateway-id 指向 gateway；默认 gateway 可在首个已认证请求时创建。创建远程 gateway、发起请求和模型调用均可能改变账户状态或产生用量，先在非生产账户完成。
接入前先决定日志策略。官方日志文档说明 gateway 默认记录请求与响应数据。cf-aig-collect-log-payload: false 可以只保留模型、状态、用量等元数据而不保存原始 prompt/response；cf-aig-collect-log: false 则跳过整个日志条目。对于敏感内容，要在首个真实请求之前检查 gateway 设置和每请求覆盖规则，不要等到日志生成后才补救。
验证顺序是：确认请求确实到达指定 gateway；查看一次脱敏测试请求的日志与费用元数据；测试限流和失败处理；最后才评估缓存、动态路由和内容检查。网关看的是应用到模型的链路，不能代替用户到应用的鉴权。DLP检查流式响应时会等待完整响应，首 Token 延迟随之增加；缓存命中不会重新扫描，策略变更时要考虑旧缓存。Guardrails负责内容类别检查，不等于事实校验或业务授权。
文档检索需要多大控制权
AI Search适合先把站点、R2 或上传文档变成可查询的数据源。官方提供 Dashboard、Workers、CLI 和 REST 等入口。先建测试 instance，选一个没有隐私数据的小数据集，配置数据源与索引，再检查同步状态；用已知能命中与不能命中的问题测试检索结果、来源和删除传播。让模型回答之前，先确认检索到的内容正确且调用方有权看到。
已有 AutoRAG 集成不要直接照搬旧示例。迁移文档指出 env.AI.autorag() 是仍可工作的 legacy API，新功能进入 ai_search 或 ai_search_namespaces binding。实例绑定适合固定单个索引，namespace 绑定适合动态管理多个实例；迁移时同时检查返回结构、过滤器和流式响应。只有具体项目确定实例名、权限、同步和恢复方案后，才应将资源写进该 Worker 项目的绑定配置。
若必须自己决定解析、切块、embedding 模型、过滤和索引生命周期，改选 Vectorize 并自己实现完整管线。索引维度要匹配模型输出；更换模型或维度前规划重建索引和重新生成向量。Vectorize 保存向量，不会自动保留可引用的原文、执行权限过滤或为答案做事实校验。
什么时候引入 Agent 和执行环境
只有需要跨请求状态、WebSocket、调度或恢复执行时，才考虑 Agents SDK；普通的单次 prompt-response 继续用 Worker 即可。Agent 的状态、工具和模型调用仍需分别设计权限与成本。读取文档和发送消息、删除数据、付款或部署属于不同风险等级；后几类动作要在服务端重新授权，并要求可追踪的审批和幂等控制。
工具选择取决于实际需要的执行环境：Browser Run用于网页截图、提取和浏览器会话；Dynamic Workers用于动态 JavaScript；Sandbox SDK用于需要文件、进程或依赖的 Linux 任务。这些不是互换的隔离承诺。第三方网页、仓库和用户上传代码都应按不可信输入处理，限制可访问的凭据、网络、运行时间和数据。
Agent Memory可按 namespace 和 profile 组织长期记忆，但目前仍为 private beta；没有资格的账户应将关键状态留在自己能审计的数据系统中。Agent Lee是 Dashboard 中的账户助手，目前是面向 Free 计划账户的 beta，不是应用内 Agents SDK；它的账户写操作必须由用户逐次批准，也不能代替变更审计。
三种安全流量不能混管
| 流量方向 | 对应边界 | 上线前检查 |
|---|---|---|
| 公网用户进入自己的 AI API | 应用鉴权、限流；按条件评估 AI Security for Apps | 测试正常请求和误报，观察后再拦截 |
| 自己的应用调用模型 | AI Gateway 的日志、缓存、限流和内容策略 | 检查 prompt/response 是否留存，以及失败回退 |
| 员工使用外部 AI 应用 | Cloudflare One 的组织 AI 安全 | 身份、设备、数据外发规则和例外流程 |
内容站还要单独考虑 AI Crawl Control 的 crawler 规则。robots.txt 是声明，不是访问控制；crawler 的识别、WAF 执行顺序和计划能力要在目标站点检查。不要把站点爬虫策略与应用模型调用的 Gateway 策略混成一条规则。
上线顺序与验收
- 在非生产环境完成单模型、单请求测试，给自己的接口加鉴权、输入上限和错误映射；核对模型目录、账户资格、价格与用量。
- 若需要 Gateway，先确定日志载荷与保留策略，再验证测试请求的路由、限流、故障和预算告警。
- 若需要检索，先用受控文档测试命中、来源、权限过滤和删除传播，再把检索结果交给模型。
- 只有存在持久会话或高风险工具时才引入 Agents、Browser Run 或 Sandbox，并测试越权、重试和人工审批。
- 在预览环境观察入口规则的误报，记录版本回退、资源删除和费用停止的操作责任人，再切到生产流量。
本篇是官方文档核对，未做账户实测。实际计划、Beta 资格、可用地区、额度、日志默认值和模型价格会变化；每次实施前按对应产品的官方限制及账单页重新检查。Cloudflare 账户与 Pages/Workers 的基础使用见平台总览，这里不重复安装和域名接入步骤。