Cloudflare 内部 AI 工程栈：基于自研平台构建，93% 研发团队已采用

在过去30天里，Cloudflare研发部门中有93%的人使用了基于我们自建平台基础设施的AI编码工具。

十一个月前，我们启动了一个重大项目：将AI真正集成到我们的工程栈中。我们需要构建内部MCP服务器、访问层以及AI工具，使代理在Cloudflare中发挥作用。我们从公司各部门抽调工程师，组建了一个名为iMARS（内部MCP代理/服务器推广小组）的突击队。持续的工作最终由开发生产力团队接手，该团队还负责管理我们大部分内部工具，包括CI/CD、构建系统和自动化。

以下是一些反映我们过去30天自主AI使用情况的数据：

3,683名内部用户积极使用AI编码工具（全公司占比60%，研发部门占比93%），员工总数约6,100人

4,795万次AI请求

295个团队目前正在使用自主AI工具和编码助手。

每月2,018万次AI Gateway请求

2,413.7亿个通过AI Gateway路由的token

518.3亿个在Workers AI上处理的token

对内部开发者效率的影响显而易见：我们从未见过合并请求的季度环比增长达到如此程度。

随着AI工具采用率的增长，四周滚动平均值从约5,600次/周攀升至超过8,700次。3月23日当周达到10,952次，几乎是第四季度基线的两倍。

MCP服务器是起点，但团队很快意识到我们需要更进一步：重新思考标准如何编纂、代码如何审查、工程师如何入职，以及变更如何在数千个仓库中传播。

本文将深入探讨过去十一个月的情况以及我们最终取得的成果。我们选择在代理周结束时发布，因为我们在内部构建的AI工程栈正是基于本周我们发布和增强的同一批产品。

架构概览

面向工程师的工具层（OpenCode、Windsurf以及其他兼容MCP的客户端）包括开源和第三方编码助手工具。

每一层都对应我们使用的Cloudflare产品或工具：

以上没有一个是仅限内部使用的基础设施。上面列出的所有内容（除了Backstage）都是已发布的产品，其中许多在代理周期间获得了重大更新。

我们将分三个部分进行介绍：

平台层 — 认证、路由和推理如何工作（AI Gateway、Workers AI、MCP门户、代码模式）

知识层 — 代理如何理解我们的系统（Backstage、AGENTS.md）

执行层 — 我们如何在大规模下保持高质量（AI代码审查、工程规范）

AI Gateway 如何帮助我们保障安全并改善开发者体验

当你有超过 3600 名内部用户每天使用 AI 编码工具时，你需要解决跨多个客户端、用例和角色的访问和可见性问题。

一切始于 Cloudflare Access，它处理所有身份验证和零信任策略执行。一旦通过身份验证，每个 LLM 请求都会通过 AI Gateway 路由。这为我们提供了一个统一的位置来管理提供商密钥、成本跟踪和数据保留策略。

OpenCode AI Gateway 概览：每天 688.46k 次请求，每天 10.57B 个 token，通过一个端点路由到四个提供商。

AI Gateway 分析显示月度使用量在模型提供商之间的分布。上个月，内部请求量细分如下。

目前，前沿模型处理了大部分复杂的代理编码工作，但 Workers AI 已经占据了重要份额，并且在我们代理工程工作负载中的占比正在增加。

我们如何越来越多地利用 Workers AI

Workers AI 是 Cloudflare 的无服务器 AI 推理平台，它在全球网络的 GPU 上运行开源模型。除了相比前沿模型巨大的成本优势外，一个关键优势是推理与你的 Workers、Durable Objects 和存储位于同一网络上。无需处理跨云跳转，这会导致更多延迟、网络不稳定以及额外的网络配置管理。

上个月 Workers AI 使用量：51.47B 输入 token，361.12M 输出 token。

Kimi K2.5 于 2026 年 3 月在 Workers AI 上发布，是一个前沿规模的开源模型，具有 256k 上下文窗口、工具调用和结构化输出。正如我们在 Kimi K2.5 发布文章 中所述，我们有一个安全代理每天在 Kimi 上处理超过 70 亿个 token。在中档专有模型上，这估计每年花费 240 万美元。但在 Workers AI 上，成本降低了 77%。

除了安全领域，我们还在 CI 流水线中使用 Workers AI 进行文档审查，在数千个仓库中生成 AGENTS.md 上下文文件，以及执行轻量级推理任务——在这些任务中，同网络延迟比峰值模型能力更重要。

随着开源模型的不断改进，我们预计 Workers AI 将处理我们内部工作负载中越来越大的份额。

我们早期做对的一件事：从一开始就通过单个代理 Worker 进行路由。我们本可以让客户端直接连接到 AI Gateway，这样初始设置会更简单。但通过 Worker 集中化意味着我们可以在以后添加每个用户的归属、模型目录管理和权限执行，而无需触及任何客户端配置。下面引导部分描述的每个功能之所以存在，是因为我们拥有那个单一控制点。代理模式为你提供了直接连接所不具备的控制平面，如果我们以后接入额外的编码辅助工具，同一个 Worker 和发现端点将处理它们。

整个设置从一个命令开始：

opencode auth login https://opencode.internal.domain

该命令触发一个链式流程，自动配置提供商、模型、MCP服务器、代理、命令和权限，用户无需接触配置文件。

步骤1：发现认证要求。 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": { "..." }
}
}

步骤 2：通过 Cloudflare Access 进行身份验证。 OpenCode 运行 auth 命令，用户通过他们在 Cloudflare 中用于其他所有操作的同一 SSO 进行身份验证。cloudflared

返回一个签名的 JWT。OpenCode 将其存储在本地，并自动附加到每个后续的提供商请求中。

步骤 3：配置合并到 OpenCode 中。 提供的配置是整个组织的共享默认值，但本地配置始终优先。用户可以覆盖默认模型、添加自己的代理，或调整项目和用户范围的权限，而不会影响其他人。

在代理 Worker 内部。 Worker 是一个简单的 Hono 应用，它执行三项操作：

提供共享配置。 配置在部署时从结构化源文件编译而来，并包含占位符值，如 Worker 来源的 {baseURL}。在请求时，Worker 替换这些值，因此所有提供商请求都通过 Worker 路由，而不是直接发送到模型提供商。每个提供商都有一个路径前缀（/anthropic, /openai, /google-ai-studio/v1beta, /compat

用于 Workers AI），Worker 将其转发到相应的 AI Gateway 路由。

将请求代理到 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，无需重新部署配置。

匿名用户跟踪。 JWT 验证后，Worker 使用 D1 进行持久存储，KV 作为读取缓存，将用户的电子邮件映射到 UUID。AI Gateway 在 cf-aig-metadata

中只看到匿名 UUID，永远不会看到电子邮件。这使我们能够进行按用户成本跟踪和使用分析，而不会向模型提供商或 Gateway 日志暴露身份。

配置即代码。 代理和命令被编写为带有 YAML 前置元数据的 Markdown 文件。构建脚本将它们编译成一个 JSON 配置，并根据 OpenCode JSON 模式进行验证。每个新会话都会自动获取最新版本。

整体架构简单，任何人都可以轻松使用我们的开发者平台进行部署：一个代理 Worker、Cloudflare Access、AI Gateway 和一个客户端可访问的发现端点，自动配置所有内容。用户只需运行一个命令即可完成。他们无需手动配置任何东西，笔记本电脑上没有 API 密钥，也不需要手动设置 MCP 服务器连接。更改我们的代理工具并更新 3000 多人在其编码环境中获得的内容，只需执行 wrangler deploy

即可。

我们在 另一篇文章 中描述了在企业规模下管理 MCP 的完整方法，包括我们如何一起使用 MCP Server Portals、Cloudflare Access 和 Code Mode。以下是我们内部构建的简要版本。

我们的内部门户聚合了 13 个生产 MCP 服务器，暴露了 182 多个工具，涵盖 Backstage、GitLab、Jira、Sentry、Elasticsearch、Prometheus、Google Workspace、我们的内部 Release Manager 等。这统一了访问并简化了一切，为我们提供了一个端点和一条 Cloudflare Access 流程来管理对每个工具的访问。

每个 MCP 服务器都建立在相同的基础上：来自 Agents SDK 的 McpAgent、用于 OAuth 的 workers-oauth-provider 以及用于身份的 Cloudflare Access。整个系统位于一个单一仓库中，共享身份验证基础设施、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个token的上下文窗口。在一个200K的上下文窗口中，这意味着在提问之前就已经用掉了7.5%的预算。乘以每个请求、每个工程师、每一天，这个消耗会不断累积。

MCP Server Portals现在支持Code Mode代理，这让我们可以集中解决这个问题，而不是一次只处理一个服务器。Portal不是将每个上游工具定义暴露给客户端，而是将它们合并为两个Portal级别的工具：portal_codemode_search和portal_codemode_execute。

在Portal层做这件事的好处是它可以干净地扩展。没有Code Mode，每个新的MCP服务器都会给每个请求增加更多的模式开销。有了Portal级别的Code Mode，即使我们在Portal后面连接更多的服务器，客户端仍然只看到两个工具。这意味着更少的上下文膨胀、更低的token成本，以及更清晰的整体架构。

第二幕：知识层

Backstage：支撑一切的知识图谱

在iMARS团队能够构建真正有用的MCP服务器之前，我们需要解决一个更基本的问题：关于我们服务和基础设施的结构化数据。我们需要我们的代理理解代码库之外的上下文，比如谁拥有什么、服务之间如何依赖、文档在哪里，以及服务与哪些数据库通信。

我们运行__Backstage__——最初由Spotify构建的开源内部开发者门户——作为我们的服务目录。它是自托管的（记录一下，不是基于Cloudflare产品），并且跟踪以下内容：

2,055个服务、167个库和122个包

228个带有模式定义的API

544个系统（产品）分布在45个领域

1,302个数据库、277个ClickHouse表、173个集群

375个团队和6,389个用户，带有所有权映射

连接服务与其依赖的数据库、Kafka主题和云资源的依赖图

我们的Backstage MCP服务器（13个工具）通过我们的MCP Portal可用，代理可以查找谁拥有某个服务、检查它依赖什么、查找相关的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 标准。然后，一个能力较强的模型生成结构化文档，系统会打开一个合并请求，以便所属团队可以审查和完善它。

我们已通过这种方式处理了大约 3900 个仓库。第一次处理并不总是完美的，尤其是对于多语言仓库或不常见的构建配置，但即使是这个基线也比要求智能体从头推断一切要好得多。

初始的合并请求解决了引导问题，但保持这些文件的最新状态同样重要。过时的 AGENTS.md 可能比没有文件更糟糕。我们通过 AI 代码审查器闭环了这个问题，它可以在仓库变更表明需要更新 AGENTS.md 时发出标记。

第三幕：执行层

Cloudflare 的每个合并请求都会收到 AI 代码审查。集成很简单：团队只需在流水线中添加一个 CI 组件，从那时起每个 MR 都会自动接受审查。

我们使用 GitLab 的自托管解决方案作为 CI/CD 平台。审查器实现为一个 GitLab CI 组件，团队将其包含在流水线中。当 MR 被打开或更新时，CI 作业会运行 OpenCode 并带有一个多智能体审查协调器。协调器根据风险等级（琐碎、轻量或完整）对 MR 进行分类，并委托给专门的审查智能体：代码质量、安全、codex 合规、文档、性能和发布影响。每个智能体连接到 AI 网关以获取模型访问权限，从中央仓库拉取 Engineering Codex 规则，并读取仓库的 AGENTS.md 以获取代码库上下文。结果以结构化的 MR 评论形式发布。

一个独立的基于 Workers 的配置服务负责每个审查智能体的集中模型选择，这样我们可以在不更改 CI 模板的情况下切换模型。审查过程本身在 CI 运行器中执行，并且每次执行都是无状态的。

我们花时间优化了输出格式。审查按类别（安全、代码质量、性能）划分，以便工程师可以扫描标题而不是阅读大段文字。每个发现都有严重级别（严重、重要、建议或可选挑剔），可以立即明确哪些需要关注，哪些只是信息性内容。

审查器在迭代过程中保持上下文。如果它在之前的审查轮次中标记了某个问题，而该问题已被修复，它会确认这一点，而不是再次提出相同的问题。并且当某个发现映射到 Engineering Codex 规则时，它会引用具体的规则 ID，将 AI 建议转化为对组织标准的引用。

Workers AI 处理了审查器大约 15% 的流量，主要用于文档审查任务，在这些任务中 Kimi K2.5 表现良好，而成本仅为前沿模型的一小部分。像 Opus 4.6 和 GPT 5.4 这样的模型处理安全敏感和架构复杂的审查，这些场景中推理能力最为重要。

在过去 30 天里：

我们正在发布一篇__详细的技术博文__，与本文一同介绍审查者的内部架构，包括我们如何在模型之间路由、多智能体编排以及我们开发的成本优化策略。

Engineering Codex：将工程标准作为智能体技能

Engineering Codex 是 Cloudflare 新的内部标准系统，我们的核心工程标准都存放在这里。我们有一个多阶段的 AI 蒸馏过程，输出一组 codex 规则（“如果你需要 X，使用 Y。如果你正在做 Y 或 Z，你必须做 X。”）以及一个智能体技能，该技能使用渐进式披露和嵌套的分层信息目录以及跨 Markdown 文件的链接。

工程师可以在本地使用此技能，通过诸如“我该如何在 Rust 服务中处理错误？”或“审查这段 TypeScript 代码是否符合规范”等提示进行构建。我们的网络防火墙团队使用多智能体共识流程审计了 rampartd，其中每个需求都被评为 COMPLIANT、PARTIAL 或 NON-COMPLIANT，并附有具体的违规细节和修复步骤，将以前需要数周的手动工作减少为一个结构化、可重复的流程。

在审查时，AI 代码审查者会在其反馈中引用特定的 Codex 规则。

AI 代码审查：显示分类结果（此处为 Codex 合规性），并注明 codex RFC 违规。

这些部分单独来看并不特别新颖。许多公司运行服务目录、部署审查机器人或发布工程标准。区别在于连接方式。当一个智能体可以从 Backstage 获取上下文，读取正在编辑的仓库的 AGENTS.md，并通过相同的工具链根据 Codex 规则进行审查时，初稿通常已经足够接近可发布状态。这在六个月前是不可能的。

从启动这项工作到 93% 的研发团队采用，用了不到一年时间。

全公司采用情况（2026 年 2 月 5 日至 4 月 15 日）：

AI 网关（最近 30 天，合计）：

Workers AI（最近 30 天）：

下一步：后台智能体

我们内部工程栈的下一个演进将包括后台智能体：这些智能体可以按需启动，使用与本地相同的工具（MCP 门户、git、测试运行器），但完全在云端运行。该架构使用 Durable Objects 和 Agents SDK 进行编排，当任务需要完整的开发环境（如克隆仓库、安装依赖或运行测试）时，委托给 Sandbox 容器。Sandbox SDK 在 Agents Week 期间正式发布。

长时间运行的智能体，在 Agents Week 期间原生集成到 Agents SDK，解决了之前需要变通方法的持久会话问题。该 SDK 现在支持长时间运行且不会被驱逐的会话，足以让智能体在单个会话中克隆大型仓库、运行完整测试套件、迭代失败并打开 MR。

这代表着长达十一个月的努力，不仅重新思考代码的编写方式，还重新思考代码的审查方式、标准的执行方式，以及如何安全地将变更部署到数千个仓库中。每一层都运行在我们客户使用的相同产品上。

Agent Week 刚刚 交付 了你所需的一切。平台已经就绪。

npx create-cloudflare@latest --template cloudflare/agents-starter

那个智能体入门套件能让你快速上手。下图展示了当你准备扩展时的完整架构：你的工具层（聊天机器人、Web UI、CLI、浏览器扩展）位于顶部，Agents SDK 在中间处理会话状态和编排，底层是你从它调用的 Cloudflare 服务。

文档： Agents SDK · Sandbox SDK · AI Gateway · Workers AI · Workflows · Code Mode · MCP on Cloudflare

仓库： cloudflare/agents · cloudflare/sandbox-sdk · cloudflare/mcp-server-cloudflare · cloudflare/skills

想了解更多关于我们在 Cloudflare 如何使用 AI 的信息，请阅读关于 我们进行 AI 代码审查的流程 的文章。并查看 我们在智能体周期间发布的所有内容。

我们很期待听到你的作品。在 Discord、X 和 Bluesky 上找到我们。

Ayush Thakur 构建了 AGENTS.md 系统和 OpenCode 基础设施的 AI Gateway 集成，Scott Roemeschke 是 Cloudflare 开发者生产力团队的工程经理，Rajesh Bhatia 领导 Cloudflare 的生产力平台职能。本文是 Devtools 团队的协作成果，并得到了公司内部通过 iMARS（内部 MCP 智能体/服务器推广小组）突击队的志愿者的帮助。