Cloudflare内部AI工程栈推动研发团队93%采用率
Cloudflare AI··作者 Rajesh Bhatia
关键信息
该架构包括Cloudflare Access实现零信任认证、AI Gateway进行路由与成本控制、Workers AI实现平台内推理，以及通过Code Mode实现沙箱执行——全部基于Workers、Durable Objects和Backstage等已上线产品构建。
资讯摘要
Cloudflare构建了一个内部AI工程栈，将代理型AI融入软件开发流程。一个月内，超过3600名员工（占公司总数的60%）和93%的研发人员使用了AI工具，生成了4795万次AI请求。该系统利用Cloudflare自身的产品——包括AI Gateway、Workers AI和Access——实现安全、可扩展的LLM访问。
它还包含Code Mode用于安全执行代理生成的代码，以及Backstage用于知识图谱集成。开发效率显著提升，合并请求量从每周约5600次增长到超过8700次。
资讯正文
在过去30天里，Cloudflare研发部门有93%的团队使用了由我们自建平台支持的AI编程工具。
十一个月前，我们启动了一个重大项目：真正将AI融入工程体系。我们需要构建内部MCP服务器、访问层以及AI工具链，使代理在Cloudflare内部变得有用。我们召集了公司各条线的工程师组成一个特别行动小组，名为iMARS（内部MCP代理/服务器部署小队）。这项持续的工作最终交由开发者生产力团队负责，他们也掌管着我们的CI/CD、构建系统和自动化工具等大部分内部基础设施。
以下数据反映了过去30天我们自身对代理式AI的使用情况：
3,683名内部用户
正在使用AI编程工具（占公司总人数的60%，研发团队占比93%），约6,100名员工中
4795万次
AI请求
295个团队
目前正使用代理式AI工具和编程助手
2018万次
每月通过AI网关的请求
2413.7亿次
通过AI网关路由的token
518.3亿次
在Workers AI上处理的token
内部开发者的开发速度提升效果十分明显：我们从未见过季度间合并请求增长如此显著的情况。
随着AI工具采纳率的上升，四周滚动平均值从大约每周5600次增长到超过8700次。3月23日那一周达到10952次，几乎是第四季度基线的两倍。
MCP服务器是起点，但团队很快意识到我们需要走得更远：重新思考标准如何编码、代码如何审查、工程师如何入职，以及变更如何在数千个代码仓库之间传播。
本文深入探讨了过去十一个月以来我们具体做了什么，以及最终成果如何。我们选择在这个时候发布，是为了在Agent Week结束之际展示：我们内部构建的AI工程栈运行在本周我们正在交付和增强的产品之上。
架构概览
面向工程师的工具层（
OpenCode
、Windsurf以及其他兼容MCP的客户端）包括开源和第三方编程助手工具。
每一层都对应我们使用的Cloudflare产品或工具：
我们构建的内容
使用的技术
零信任认证
Cloudflare Access
集中式LLM路由、成本追踪、BYOK（自带密钥）、零数据保留控制
AI Gateway
平台内推理，使用开放权重模型
Workers AI
MCP服务器门户，单点OAuth认证
Workers + Access
AI代码审查CI集成
Workers + AI Gateway
代理生成代码的沙箱执行（代码模式）
Dynamic Workers
状态持久、长时间运行的代理会话
Agents SDK（McpAgent、Durable Objects）
隔离环境用于克隆、构建和测试
Sandbox SDK —— Agents Week期间正式上线
持久化的多步骤工作流
Workflows —— 在Agents Week期间扩展了10倍
16000+实体知识图谱
Backstage（开源）
—— 以上内容并非仅限内部使用。除Backstage外，上述所有组件都是已发布的商品化产品，其中许多在Agents Week期间获得了重大更新。
我们将分三个部分来介绍：
平台层
—— 认证、路由和推理机制如何运作（AI Gateway、Workers AI、MCP门户、代码模式）
知识层
— 代理如何理解我们的系统（Backstage、AGENTS.md）
执行层
— 如何在大规模下保持高质量（AI代码审查工具、工程编码规范）
第一幕：平台层
AI网关如何帮助我们保障安全并提升开发者体验
当每天有超过3600名内部用户使用AI编程工具时，你需要解决跨多种客户端、使用场景和角色的访问与可见性问题。
一切始于
Cloudflare Access
，它负责所有身份验证和零信任策略执行。认证通过后，每个大语言模型请求都会经过
AI网关
。这使我们能够集中管理提供方密钥、成本追踪和数据保留策略。
OpenCode AI网关概览：每日处理68.846万次请求，每日处理105.7亿个标记，通过一个端点路由到四个提供方。
AI网关分析显示了上个月各模型提供方的使用分布情况。过去一个月，内部请求量如下所示。
提供方
每月请求数
Frontier Labs（OpenAI、Anthropic、Google）
1338万
91.16%
Workers AI
130万
8.84%
目前，前沿模型承担了大部分复杂的代理式编程任务，但Workers AI已经占到了相当比例，并且正在越来越多地承担我们的代理式工程工作负载。
我们如何越来越多地利用Workers AI
Workers AI
是Cloudflare的无服务器AI推理平台，可在我们全球网络中的GPU上运行开源模型。相比前沿模型，它带来了巨大的成本优势，另一个关键优势在于推理过程与你的Workers、Durable Objects和存储位于同一网络中。无需跨云跳转，从而避免了延迟增加、网络不稳定以及额外的网络配置管理工作。
上个月Workers AI的使用情况：输入标记514.7亿，输出标记3.6112亿。
Kimi K2.5
于2026年3月在Workers AI上线，是一款具备256k上下文窗口、工具调用和结构化输出能力的前沿级开源模型。正如我们在
Kimi K2.5发布文章中所述
，我们有一个安全代理每天处理超过70亿个标记的Kimi数据。如果使用中等价位的专有模型，每年成本预计高达240万美元；但在Workers AI上，成本低了77%。
除了安全领域，我们还使用Workers AI进行CI流水线中的文档审查、为数千个代码仓库生成AGENTS.md上下文文件，以及对那些更看重同网络延迟而非极致模型性能的轻量级推理任务。
随着开源模型持续进步，我们预计Workers AI将承担我们内部工作负载的更大份额。
我们早期做对的一件事：从第一天起就通过单一代理 Worker 进行路由。我们本可以让客户端直接连接到 AI 网关，这样初始设置会更简单。但通过 Worker 中心化处理，让我们之后可以轻松添加用户级归属、模型目录管理和权限控制，而无需改动任何客户端配置。下面 Bootstrap 部分描述的每一个功能，都是因为我们有这个唯一的控制节点。代理模式提供了直接连接无法实现的控制平面；如果我们将来接入额外的编码助手工具，同一个 Worker 和发现端点也能处理它们。
工作原理：一个 URL 配置全部内容
整个设置从一条命令开始：
opencode auth login https://opencode.internal.domain
这条命令触发一连串操作，自动配置提供方、模型、MCP 服务器、代理、命令和权限，用户无需手动编辑任何配置文件。
第一步：发现认证要求。
OpenCode 从类似 https://opencode.internal.domain/.well-known/opencode 的 URL 获取 config。这个发现端点由 Worker 提供服务，响应中包含一个 auth 块，说明 OpenCode 如何进行身份验证，还有一个 config 块，其中包含提供方、MCP 服务器、代理、命令以及默认权限信息：
{
"auth": {
"command": ["cloudflared", "access", "login", "..."],
"env": "TOKEN"
},
"config": {
"provider": { "..." },
"mcp": { "..." },
"agent": { "..." },
"command": { "..." },
"permission": { "..." }
}
}
第二步：通过 Cloudflare Access 认证。
OpenCode 执行认证命令，用户使用与 Cloudflare 其他服务相同的 SSO 方式完成认证。
cloudflared 返回一个签名 JWT。OpenCode 将其本地存储，并自动将其附加到后续所有提供方请求中。
第三步：配置合并进 OpenCode。
提供的配置是组织级别的共享默认值，但本地配置始终优先。用户可以覆盖默认模型、添加自己的代理，或调整项目和用户范围的权限，而不会影响其他人。
在代理 Worker 内部。
这个 Worker 是一个简单的 Hono 应用，主要做三件事：
1. 提供共享配置。
配置在部署时从结构化源文件编译而成，包含类似 {baseURL} 这样的占位符，代表 Worker 的源地址。在请求时，Worker 会替换这些占位符，因此所有提供方请求都经过 Worker 路由，而不是直接发给模型提供方。每个提供方都有一个路径前缀（如 /anthropic、/openai、/google-ai-studio/v1beta、/compat 用于 Workers AI），Worker 会将请求转发到对应的 AI Gateway 路由。
2. 代理请求到 AI Gateway。
当 OpenCode 发送类似 POST /anthropic/v1/messages 的请求时，Worker 会验证 Cloudflare Access JWT，然后重写请求头再转发：
- 移除：authorization、cf-access-token、host
- 添加：cf-aig-authorization: Bearer <API_KEY>
- cf-aig-metadata: {"userId": "<anonymous-uuid>"}
请求到达 AI Gateway 后，它会被路由到相应的提供方。响应原封不动返回，不进行缓冲。
apiKey
客户端配置中的字段为空，因为 Worker 会在服务器端注入真正的密钥。用户设备上不存在 API 密钥。
保持模型目录的实时更新。
一个每小时触发的 cron 任务从 models.dev 获取当前 OpenAI 模型列表，将其缓存在 Workers KV 中，并对每个模型注入 store: false，实现零数据保留（ZDR）。新模型会自动获得 ZDR 功能，无需重新部署配置。
匿名用户追踪。
在 JWT 验证后，Worker 使用 D1 将用户的电子邮件映射为 UUID 并以 KV 作为读取缓存。AI 网关始终只看到 cf-aig-metadata 中的匿名 UUID，而不会获取电子邮件。这样我们可以在不向模型提供方或网关日志暴露身份的情况下进行按用户的成本追踪和使用分析。
配置即代码。
代理和命令以带有 YAML 前置元数据的 Markdown 文件形式编写。构建脚本将它们编译成单个 JSON 配置文件，并依据 OpenCode JSON Schema 进行验证。每次新会话都会自动获取最新版本。
整体架构简单易用，任何人都可以通过我们的开发者平台轻松部署：一个代理 Worker、Cloudflare Access、AI 网关，以及一个可被客户端访问的发现端点，自动完成所有配置。用户只需运行一条命令即可完成设置，无需手动配置任何内容，也不需要在笔记本电脑上配置 API 密钥，或手动建立 MCP 服务器连接。对我们超过 3000 名使用者的智能工具进行更改并更新其编码环境中的功能，只需一次 wrangler deploy 即可完成。
MCP 服务器门户：一次 OAuth 认证，接入多个 MCP 工具
我们在另一篇单独的文章中详细描述了企业级管理 MCP 的完整方法，包括如何结合使用 MCP 服务器门户、Cloudflare Access 和 Code Mode。以下是我们在内部构建的简化版本。
我们内部的门户聚合了 13 个生产环境的 MCP 服务器，覆盖 Backstage、GitLab、Jira、Sentry、Elasticsearch、Prometheus、Google Workspace、内部发布管理器等多个平台上的 182+ 个工具。这统一了访问入口，简化了所有流程，让我们仅通过一个端点和一套 Cloudflare Access 流程就能控制对所有工具的访问权限。
每个 MCP 服务器都基于相同基础构建：来自 Agents SDK 的 McpAgent、用于 OAuth 的 workers-oauth-provider，以及用于身份验证的 Cloudflare Access。整个系统托管在一个单一的 monorepo 中，共享认证基础设施、Bazel 构建、CI/CD 流水线，以及用于 Backstage 注册的 catalog-info.yaml 文件。新增一个服务器几乎只需要复制现有服务器并修改它所封装的 API 即可。有关其工作原理及背后安全架构的更多细节，请参阅我们的企业级 MCP 参考架构。
在门户层使用 Code Mode
MCP 是连接 AI 代理与工具的正确协议，但存在一个实际问题：每个工具定义都会在模型开始工作前消耗上下文窗口令牌。随着 MCP 服务器和工具数量的增长，这种令牌开销也随之增加，在大规模场景下成为显著的成本负担。
Code Mode 是正在出现的解决方案：不再预先加载所有工具模式，而是让模型通过代码动态发现并调用工具。
我们的 GitLab MCP 服务器最初暴露了 34 个独立工具（get_merge_request
list_pipelines
get_file_content
，等等）。这些34个工具模式大约每请求消耗15,000个标记的上下文窗口。在一个20万标记的上下文窗口中，这相当于在提问之前就占用了7.5%的预算。如果乘以每个请求、每位工程师每天的使用量，这个数字会迅速累积。
MCP服务器门户现在支持代码模式代理，这让我们可以集中解决这个问题，而不是逐台服务器单独处理。我们不再将每个上游工具定义暴露给客户端，而是将它们合并为两个门户级别的工具：
portal_codemode_search 和 portal_codemode_execute
在门户层面上做这件事的好处在于它能干净地扩展。没有代码模式时，每新增一台MCP服务器都会增加每个请求的模式开销。而有了门户级别的代码模式，即使我们在门户后连接更多服务器，客户端仍然只会看到两个工具。这意味着更少的上下文膨胀、更低的令牌成本，以及整体架构更加清晰。
第二幕：知识层
Backstage：所有系统背后的知识图谱
在iMARS团队能够构建真正有用的MCP服务器之前，我们需要先解决一个更根本的问题：关于我们的服务和基础设施的结构化数据。我们需要让我们的代理理解代码库之外的上下文，比如谁负责什么、服务之间如何依赖、文档存放在哪里，以及某个服务与哪些数据库通信。
我们运行的是 Backstage —— 这是一个最初由Spotify开发的开源内部开发者门户。它是自托管的（不是运行在Cloudflare产品上），并记录了如下信息：
2,055个服务、167个库和122个包
228个带有模式定义的API
跨越45个领域的544个系统（产品）
1,302个数据库、277个ClickHouse表、173个集群
375个团队和6,389名用户及其所有权映射
连接服务与其所依赖的数据库、Kafka主题和云资源的依赖图谱
我们的Backstage MCP服务器（包含13个工具）可通过MCP门户访问，代理可以在不离开编码会话的情况下查找某个服务的所有者、检查其依赖项、查找相关API规范，并获取技术洞察评分。
如果没有这种结构化的数据，代理就只能盲目工作。它们可以读取当前代码，但看不到周围的系统。目录将单个仓库变成一张工程组织的互联地图。
AGENTS.md：让数千个仓库准备好迎接AI
在初期部署过程中，我们不断遇到相同的失败模式：编码代理生成的更改看起来合理，但对仓库来说却是错误的。通常问题出在本地上下文上：模型不知道正确的测试命令、团队当前的惯例，或者代码库中哪些部分是禁用的。这促使我们开发了 AGENTS.md：一种存在于每个仓库中的简短且结构化的文件，告诉编码代理代码库的实际运作方式，并强制团队明确表达这些上下文。
AGENTS.md 长什么样
我们在GitLab实例中建立了一个系统，用于生成AGENTS.md文件。因为这些文件直接位于模型的上下文窗口内，我们希望它们保持简短且信号强。典型的文件如下所示：
## AGENTS.md
### 仓库
- 运行时：Cloudflare Workers
- 测试命令：`pnpm test`
- 格式化命令：`pnpm lint`
### 如何浏览这个代码库
- 所有 Cloudflare Workers 文件位于 `src/workers/` 目录下，每个 Worker 对应一个文件
- MCP 服务器定义在 `src/mcp/` 中，每个工具单独存放于一个文件
- 测试文件与源码一一对应：`src/foo.ts` → `tests/foo.test.ts`
### 规范
- 测试：使用 Vitest 并配合 `@cloudflare/vitest-pool-workers`（Codex：RFC 021，RFC 042）
- API 模式：遵循内部 REST 规范（Codex：API-REST-01）
### 边界
- 不要编辑 `gen/` 中生成的文件
- 引入新的后台任务前，必须更新 `config/`
### 依赖关系
- 依赖项：auth-service、config-service
- 被依赖项：api-gateway、dashboard
当一个代理读取此文件时，它无需从头推断整个仓库结构。它已经知道代码库如何组织、应该遵循哪些规范，以及适用哪些 Engineering Codex 规则。
我们如何大规模生成这些文档
生成器流水线从我们的 Backstage 服务目录中提取实体元数据（所有权、依赖关系、系统关联），分析仓库结构以识别语言、构建系统、测试框架和目录布局，然后将检测到的技术栈映射到相应的 Engineering Codex 标准。一个能力足够的模型会生成结构化文档，系统随后打开一个合并请求（MR），让负责团队进行审查和优化。
我们通过这种方式处理了大约 3,900 个仓库。初次生成并不总是完美，尤其是多语言仓库或特殊构建配置的情况，但即便如此，其基线质量也远胜于要求代理完全从零开始推断。
第一个合并请求解决了启动问题，但保持这些文件的时效性同样重要。一份过时的 AGENTS.md 可能比完全没有还要糟糕。我们通过 AI 代码审查工具闭环解决了这个问题，它可以标记出仓库变更是否意味着需要更新 AGENTS.md。
第三幕：执行层
AI 代码审查工具
Cloudflare 的每个合并请求都会接受 AI 代码审查。集成非常简单：团队只需在 CI/CD 流水线中添加一个组件，此后所有 MR 都会自动被审查。
我们使用 GitLab 自托管解决方案作为 CI/CD 平台。审查工具实现为 GitLab CI 组件，团队将其加入自己的流水线。当 MR 打开或更新时，CI 作业运行 OpenCode，由一个多代理审查协调器接管。该协调器根据风险等级（轻微、轻量或完整）对 MR 分类，并分配给专门的审查代理：代码质量、安全、Codex 合规性、文档、性能和发布影响。每个代理连接至 AI 网关获取模型访问权限，从中央仓库拉取 Engineering Codex 规则，并读取仓库中的 AGENTS.md 获取上下文信息。结果以结构化的 MR 评论形式返回。
一个基于 Workers 的配置服务负责每名审查代理的集中模型选择，这样我们可以在不修改 CI 模板的前提下切换模型。审查过程本身在 CI 运行器中执行，每次运行都是无状态的。
输出格式要求：
- 返回适合新闻详情页直接阅读的中文段落，段落之间用空行分隔。
- 若存在明显网站 UI 残留或提取错误，请移除。
- 删除重复标题、导航栏、作者/署名元数据、时间戳、页脚/关于/法律/联系区块、相关故事模块、推荐卡片及无关编号推荐列表。
- 仅保留文章事实内容。
我们花时间调整了输出格式。评审结果按类别划分（安全、代码质量、性能），让工程师可以快速浏览标题，而无需阅读大段文字。每个发现都有严重程度等级（关键、重要、建议或可选细节），能立即明确哪些需要关注，哪些只是信息性提示。
评审器在迭代过程中保持上下文。如果之前版本中标记的问题已经修复，它会承认这一点，而不是重复提出相同问题。当某个发现对应 Engineering Codex 规则时，它会引用具体的规则编号，将 AI 建议转化为对组织标准的引用。
Workers AI 处理约 15% 的评审流量，主要用于文档审查任务，此时 Kimi K2.5 的表现优异且成本仅为前沿模型的几分之一。像 Opus 4.6 和 GPT 5.4 这样的模型则负责处理涉及安全敏感或架构复杂的评审任务，因为这些场景更依赖推理能力。
过去 30 天内：
100% 的 AI 代码评审覆盖率，覆盖我们标准 CI 流水线中的所有仓库。
547 万次 AI 网关请求
247.7 亿 token 被处理
我们将在本文发布的同时推出一篇详细的技术博客文章，涵盖评审器的内部架构，包括如何在不同模型之间路由、多代理编排机制以及我们开发的成本优化策略。
Engineering Codex：将工程标准转化为代理技能
Engineering Codex 是 Cloudflare 新推出的内部标准系统，我们的核心工程标准都集中在此。我们采用多阶段 AI 提炼流程，输出一套 Codex 规则（例如“如果你需要 X，请使用 Y；如果你正在做 Y 或 Z，则必须执行 X”），并配套一个代理技能，该技能利用渐进披露和嵌套层次化信息目录，在 Markdown 文件间建立链接。
工程师可以在本地使用这项技能，通过提示如“我的 Rust 服务应如何处理错误？”或“检查这段 TypeScript 代码是否合规”来获取帮助。我们的网络防火墙团队曾用多代理共识流程审计了 rampartd，每项要求都被评分合规、部分合规或不合规，并附带具体违规说明和修复步骤，将此前需数周手动完成的工作转变为结构化、可重复的流程。
在评审时，AI 代码评审器会在反馈中引用具体的 Codex 规则。
AI 代码评审：展示分类发现（本例为 Codex 合规性），指出违反的 RFC 条款。
这些组件单独来看并不新颖：很多公司运营服务目录、部署评审机器人或发布工程标准。真正不同的是它们之间的连接方式。当一个代理能够从 Backstage 获取上下文、读取 AGENTS.md 文件了解当前编辑的仓库，并由同一工具链根据 Codex 规则进行评审时，初稿通常已足够接近可发布状态——这在六个月前还做不到。
成绩榜
从启动该项目到研发团队采纳率达到 93%，不到一年时间。
全公司范围采纳情况（2026 年 2 月 5 日至 4 月 15 日）：
指标
数值
活跃用户
3,683
（占公司总人数的 60%）
研发团队采纳率
93%
AI 消息数量
4795 万
团队中的AI活动
295
OpenCode消息
2708万
Windsurf消息
434.9万
AI网关（最近30天，合计）：
指标
数值
请求量
2018万
Token数量
2413.7亿
Workers AI（最近30天）：
指标
数值
输入Token
514.7亿
输出Token
361.12亿
下一步：后台代理
我们内部工程栈的下一个演进将包括后台代理：这些代理可以按需启动，拥有本地可用的所有工具（MCP门户、Git、测试运行器），但完全在云端运行。该架构使用Durable Objects和代理SDK进行编排，在需要完整开发环境（如克隆仓库、安装依赖项或运行测试）时，委托给Sandbox容器执行任务。
Sandbox SDK已在代理周正式发布。
长期运行的代理也已在代理周内原生集成到代理SDK中，解决了此前必须借助变通手段才能处理的持久会话问题。现在SDK支持长时间运行的会话而不会被驱逐，足以让一个代理在一个会话中完成克隆大型仓库、运行完整测试套件、迭代修复错误，并打开合并请求（MR）等操作。
这代表了我们长达十一个月的努力，不仅重新思考代码如何编写，还重新思考代码如何审查、标准如何强制执行，以及变更如何安全地跨数千个仓库部署。每一层都基于客户使用的相同产品构建。
开始构建
代理周刚刚发布了你所需的一切。平台已经就绪。
npx create-cloudflare@latest --template cloudflare/agents-starter
这个代理模板可让你快速上手。下图展示了当你准备扩展时的完整架构：你的工具层位于最上方（聊天机器人、网页界面、CLI、浏览器插件），中间是代理SDK负责会话状态和编排，底层则是你调用的Cloudflare服务。
文档：
代理SDK
Sandbox SDK
AI网关
Workers AI
工作流
代码模式
MCP on Cloudflare
仓库：
cloudflare/agents
cloudflare/sandbox-sdk
cloudflare/mcp-server-cloudflare
cloudflare/skills
要了解我们在Cloudflare如何使用AI，请阅读关于AI代码审查流程的文章。同时查看代理周期间我们发布的全部内容。
我们非常期待听到你构建的内容。在Discord、X平台上找到我们。
Ayush Thakur负责构建AGENTS.md系统及OpenCode基础设施中的AI网关集成；Scott Roemeschke是Cloudflare开发者生产力团队的工程经理；Rajesh Bhatia领导Cloudflare生产力平台功能。本文由Devtools团队协作撰写，并得到了公司内部iMARS（内部MCP代理/服务器推广小组）特遣队志愿者们的帮助。
来源与参考
收录于 2026-04-21