OpenAI + Cloudflare AI Gateway 教程（2026）：让生产环境 AI Agent 更可控

快速答案

如果你想在 2026 年让一个基于 OpenAI 的 agent 更接近生产可用，最短路径不是"先搭一个庞大的 agent 平台"，而是：

保留现有的 OpenAI 应用逻辑。
在 OpenAI 请求前面加一层 Cloudflare AI Gateway。
先加上日志、分析、限流、重试和回退，再扩展工作流。
等 gateway 层跑通之后，再把对延迟敏感或需要边缘部署的部分迁到 Cloudflare Workers 或 Workers AI。

OpenAI 在 2026 年 4 月 13 日宣布将 GPT-5.4 等模型扩展到 Cloudflare Agent Cloud 之后，这条路径更有底气了。对大多数团队来说，重点不在合作本身——而是 Cloudflare 文档中已经公开了一条可复现的接入路径：把 OpenAI 流量路由到 Cloudflare 的 gateway 层，然后只在确实有帮助的地方才加入 Cloudflare 的运行时组件。

截至 2026-04-14，这是在不重写整个 agent 架构的前提下获得更好可观测性和控制力的最直接方案。

这份教程适合谁

本文面向已经在用 OpenAI API 或准备上线一个单一场景 agent 的团队，比如：

客户工单自动分类
内部报告自动生成
表单或工单归类
有明确边界的编码或内容工作流
需要日志、限流和回滚能力的 agent 后端

如果你还在 ChatGPT 里手动调试 prompt、不确定 agent 具体该做什么，这篇教程还不是最佳起点。想先了解 agent 的整体图景，可以看 AI Agents 实用指南（2026）。

为什么现在关注这个话题

新闻触发点很具体。

2026 年 4 月 13 日，OpenAI 宣布企业可以在 Cloudflare Agent Cloud 中部署由 OpenAI 模型驱动的 agent，同时 Codex harness 在 Cloudflare Sandboxes 中正式可用（GA），Workers AI 支持在下一步计划中。这个组合把边缘部署和 agent 运维放到了一条路径上。

如果你已经有 OpenAI 应用，最该先看的不是含糊的“agent cloud”概念，而是一条今天就能照抄的接入路径。

Cloudflare 的公开文档已经通过两个组件暴露了这条路径：

组件	做什么	为什么先用它
AI Gateway	在 AI 请求前添加分析、日志、缓存、限流、重试和模型回退	不需要重写应用就能提升控制力
Workers / Workers AI	在 Cloudflare 网络上运行应用逻辑和模型推理	等你确定哪些部分需要更靠近用户时再考虑

所以本教程从 AI Gateway 开始，不从全平台迁移开始。

什么场景适合 OpenAI + Cloudflare

如果你至少需要以下两项，就适合用这个方案：

一个集中查看请求量、token 和错误的地方
在用户和模型调用之间加限流
生产流量的重试或回退行为
以更低成本统一管理多个 OpenAI 端点
之后可能迁移到边缘执行

如果你的工作流还在天天改，agent 没有稳定的成功标准，或者你还不知道哪些 prompt 和工具值得运维化，就先不用这套方案。

Cloudflare 这一层到底给你什么

Cloudflare AI Gateway 的文档把能力写得很具体。截至 2026-04-14，产品文档中直接列出的控制能力包括：

请求、token 和成本分析
请求和错误日志
缓存
限流
请求重试和模型回退
支持包括 OpenAI 在内的多家 provider

Cloudflare 文档明确写了 AI Gateway 适用于所有 Cloudflare 套餐（包括免费套餐），不需要付费就能开始给 AI 流量加日志和控制。Workers AI 作为独立产品，文档标注为 Free 和 Paid 两个套餐均可用，提供在 Cloudflare 网络上的无服务器模型推理。

对大多数团队来说，AI Gateway 是第一层运维层。Workers AI 是第二阶段的部署决策。

最快的安全接入路径

第一步：从一个有边界的 agent 任务开始

不要一上来就做通用自主 agent。

选一个输入、输出和失败条件都清楚的任务。好的例子：

把客户工单摘要成固定 JSON schema
把销售线索分成三个路由类别
从结构化笔记生成内部周报
从会议记录中提取行动项

如果你没法用一段话描述预期输出，还不到加运维控制的时候。

第二步：在现有 OpenAI 调用前面加 AI Gateway

Cloudflare 的 OpenAI provider 文档展示了核心改动：用 Cloudflare gateway URL 替换 OpenAI 的默认 base URL。

原来的调用地址：

https://api.openai.com/v1

改为：

https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_id}/openai

一行改动，请求就经过 Cloudflare 的控制层了。

第三步：保持应用逻辑简单

一个使用 key-in-request 模式（你的 OpenAI API key 直接通过 gateway 转发）的最小 Node 示例：

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  baseURL: "https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_id}/openai",
});

// 使用 OpenAI 较新的 Responses API (client.responses.create)
// 而不是旧版的 Chat Completions API (client.chat.completions.create)
const response = await client.responses.create({
  model: "gpt-5.1",
  input: [
    {
      role: "user",
      content: "Summarize this ticket and return priority, owner, and next action.",
    },
  ],
});

如果你更倾向于使用 Cloudflare 的 stored-key（BYOK）或统一计费路径（由 Cloudflare 保管密钥，你用 Cloudflare API token 认证），Cloudflare 文档在 "Stored Keys" 标签页下有详细说明。核心思路不变：用现有的 OpenAI SDK，只换路由层。

第四步：一次启用一个控制能力

不要一口气打开所有平台功能。

最安全的启用顺序：

日志
分析
限流
重试
回退
缓存——只在响应可以安全复用的场景下

这个顺序降低了你用过多基础设施掩盖 prompt 质量问题的风险。

第五步：边缘部署放到后面

OpenAI 的公告把 Agent Cloud 和 Cloudflare 的边缘技术栈绑在了一起，Cloudflare 文档也把 Workers AI 定位为网络上的模型运行时层。

但这不意味着每个 agent 都该在第一天全面迁到边缘。

更好的规则：

如果现有后端已经稳定，编排逻辑就留在原地
先把请求路由和控制迁到 AI Gateway
只把对延迟敏感或需要全球分布的部分迁到 Workers 或 Workers AI

调试更容易，回滚也更容易。

实用起始案例：工单分类 Agent

如果你想找一个值得快速运维化的工作流，工单分类是很好的候选。

为什么适合

输入容易标准化
输出可以约束为固定 schema
失败容易检查
限流和日志立刻有用
流量高峰时重试和回退很实用

可直接复制的 prompt

You are a support triage assistant.
Return valid JSON with exactly these fields:
- issue_type
- urgency
- customer_impact
- next_action
- escalation_needed

Classify conservatively.
If the ticket is ambiguous, say so in next_action instead of guessing.

示例输出格式

{
  "issue_type": "billing",
  "urgency": "medium",
  "customer_impact": "single account blocked from invoice download",
  "next_action": "send billing support response template and verify account status",
  "escalation_needed": false
}