93% 的研发人员在过去 30 天内使用了 AI 编程工具。这不是一次工具采购，而是一次工程基础设施的整体重建。Cloudflare 用自己正在向客户销售的产品，给自己搭了这套东西。

一、11 个月，从零到 93%

在过去 30 天里，Cloudflare 93% 的研发组织使用了建立在自家平台上的 AI 编程工具。

11 个月前，这个数字接近于零。Cloudflare 专门组建了一个叫做 iMARS（Internal MCP Agent/Server Rollout Squad）的突击队，横跨公司多个部门，将 AI 真正嵌入工程栈的每一个环节。

这篇文章是对这 11 个月工作的完整复盘，它的价值不仅在于 Cloudflare 自己做了什么，更在于它展示了一家技术公司如何系统性地完成这种迁移——包括哪些是真正的难题，哪些做法是可以复用的。

---

二、过去 30 天的真实规模

过去 30 天的数据：3683 名内部用户活跃使用 AI 编程工具（占全公司 60%，研发部门 93%）；4795 万次 AI 请求；295 个团队在使用 Agentic AI 工具；2018 万次 AI Gateway 请求；2413.7 亿个 Token 通过 AI Gateway 路由；518.3 亿个 Token 在 Workers AI 上处理。

对开发者效率的影响清晰可见：四周滚动平均的合并请求数量从每周约 5600 个攀升至超过 8700 个。2026 年 3 月 23 日那一周达到 10952 个，几乎是 Q4 基线的两倍。

这组数字背后是三层架构的协同运作。

---

三、整体架构：平台、知识、执行三层分工

整套系统分为三个层次，每层各司其职：

平台层：解决身份认证、LLM 路由、推理成本和工具接入的基础问题。

知识层：解决 Agent 如何理解系统上下文——不只是代码，还有服务关系、团队归属、架构约定。

执行层：解决如何在大规模变更中保持代码质量和工程标准不退化。

三层之间相互依赖：知识层让平台层的 Agent 能做出有意义的决策，执行层基于知识层的上下文对输出进行评判。

---

四、平台层

AI Gateway：统一路由，安全与成本的控制平面

一切从 Cloudflare Access 开始，负责所有身份验证和零信任策略执行。认证完成后，每一个 LLM 请求都经过 AI Gateway 路由，这给了 Cloudflare 一个统一的地方来管理提供商密钥、成本追踪和数据留存策略。

过去一个月的请求分布：

提供商	请求量/月	占比
Frontier Labs（OpenAI、Anthropic、Google）	1338 万	91.16%
Workers AI	130 万	8.84%

前沿模型目前处理大部分复杂的 Agentic 编程工作，但 Workers AI 已经承担了相当比例，并且在持续增长。

Workers AI：内部推理的低成本底座

Workers AI 的一个关键优势是推理与 Workers、Durable Objects 和存储在同一网络上运行，无需跨云调用，这意味着更低的延迟、更少的网络故障和更简单的网络配置。

Kimi K2.5 是 2026 年 3 月在 Workers AI 上线的前沿规模开源模型，拥有 256K 上下文窗口、工具调用和结构化输出能力。Cloudflare 有一个安全 Agent 每天在 Kimi 上处理超过 70 亿个 Token。如果使用中档专有模型，这每年估计要花费 240 万美元。但在 Workers AI 上，成本降低了 77%。

除了安全场景，Workers AI 还承担着 CI 流水线中的文档审查、跨数千个仓库生成 AGENTS.md 上下文文件，以及对同网络延迟要求高于峰值模型能力的轻量推理任务。

一条命令配置一切

整个设置从一条命令开始：opencode auth login https://opencode.internal.domain。这条命令触发一系列配置：提供商、模型、MCP 服务器、Agent、命令和权限，用户无需触碰任何配置文件。

背后的流程分三步：OpenCode 从发现端点（一个 Worker）拉取配置，配置中包含认证方式和组织共享的默认设置；用户通过 Cloudflare Access 完成 SSO 认证，拿到签名 JWT，此后每个请求自动附带；配置合并进 OpenCode，组织默认值与用户本地覆盖共存，互不干扰。

代理 Worker 的三个核心职责：

一是提供共享配置。配置在部署时从结构化源文件编译，请求时 Worker 动态填充占位符，所有提供商请求通过 Worker 路由而非直连模型提供商。二是代理请求到 AI Gateway，验证 JWT 后改写请求头，真实 API Key 由 Worker 服务端注入，用户设备上不存在任何 API Key。三是保持模型目录新鲜，小时级 cron 触发器拉取最新模型列表，缓存到 Workers KV，并自动为每个模型注入 store: false 实现零数据留存，新模型自动获得这一保护，无需重新部署配置。

匿名用户追踪：

JWT 验证后，Worker 将用户邮箱映射到一个 UUID，使用 D1 做持久存储、KV 做读缓存。AI Gateway 只能在元数据中看到匿名 UUID，永远看不到邮箱。这样实现了逐用户的成本追踪和使用分析，同时不向模型提供商或 Gateway 日志暴露身份。

这个设计选择值得反复强调：从第一天就通过单一代理 Worker 路由，而不是让客户端直接连接 AI Gateway。这个选择让后续所有的逐用户归因、模型目录管理和权限控制都可以在不触碰任何客户端配置的情况下加进来。控制平面的价值正是来自这个单一的节流点。

MCP Server Portal：一次 OAuth，接入 13 个工具服务

内部 MCP Portal 聚合了 13 个生产 MCP 服务器，对外暴露 182 个以上的工具，覆盖 Backstage、GitLab、Jira、Sentry、Elasticsearch、Prometheus、Google Workspace、内部发布管理器等。统一了访问入口，只需一个端点和一套 Cloudflare Access 流程管理所有工具的访问权限。

每个 MCP 服务器都基于相同的基础：来自 Agents SDK 的 McpAgent、用于 OAuth 的 workers-oauth-provider、用于身份的 Cloudflare Access。整套代码在一个单体仓库里，共享认证基础设施、Bazel 构建、CI/CD 流水线。增加一个新服务器基本上就是复制一个现有的，然后改掉它所包装的 API。

Code Mode：解决 MCP 的上下文膨胀问题

MCP 有一个实际问题：每个工具定义在模型开始工作之前就消耗上下文窗口 Token。随着 MCP 服务器和工具数量增长，Token 开销也随之增长，在规模化场景下这会成为真实成本。

GitLab MCP 服务器最初暴露了 34 个独立工具。这 34 个工具 Schema 每次请求消耗约 15000 个上下文 Token。在 200K 上下文窗口里，还没问问题就用掉了 7.5% 的预算。MCP Server Portal 现在支持 Code Mode 代理：不再向客户端暴露所有上游工具定义，而是将它们合并为两个 Portal 级工具：portal_codemode_search 和 portal_codemode_execute。这样做的好处是随着接入更多服务器，客户端始终只看到这两个工具，而不是线性增长的上下文开销。

---

五、知识层

Backstage：16000+ 实体的工程知识图谱

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

Cloudflare 运行开源内部开发者门户 Backstage 作为服务目录，它追踪：2055 个服务、167 个库、122 个包；228 个带 Schema 定义的 API；544 个系统（产品）分布在 45 个域；1302 个数据库、277 个 ClickHouse 表、173 个集群；375 个团队和 6389 个用户及其所有权映射；连接服务与其依赖的数据库、Kafka Topic 和云资源的依赖图。

Backstage MCP 服务器（13 个工具）通过 MCP Portal 对外提供，Agent 可以查找服务归属、检查依赖关系、找到相关 API 规范、拉取技术洞察分数，所有这些都无需离开编程会话。没有这些结构化数据，Agent 是在盲目工作。目录将独立仓库变成了工程组织的连通地图。

AGENTS.md：让 3900 个仓库对 AI 可读

推广早期，Cloudflare 反复看到同一种失败模式：编程 Agent 产出的变更看起来合理，但对这个仓库来说是错误的。通常问题是本地上下文：模型不知道正确的测试命令、团队当前的约定，或者代码库里哪些地方不能碰。这推动了 AGENTS.md 的出现——每个仓库里一个简短的结构化文件，告知编程 Agent 这个代码库实际上是如何工作的，并迫使团队将这些上下文显式化。

一个典型的 AGENTS.md 包含：运行时环境和命令（测试、Lint）、代码库导航说明（目录结构约定）、需要遵循的规范（对应 Engineering Codex 规则 ID）、明确的边界（哪些文件不能动）、依赖关系声明（依赖谁、谁依赖我）。

大规模生成管道：

生成器从 Backstage 服务目录拉取实体元数据（所有权、依赖关系、系统关系），分析仓库结构以检测语言、构建系统、测试框架和目录布局，然后将检测到的技术栈映射到相关的 Engineering Codex 标准，由一个有能力的模型生成结构化文档，系统打开一个合并请求让所属团队审查和完善。

Cloudflare 以这种方式处理了大约 3900 个仓库。第一轮并不总是完美的，特别是对于多语言仓库或不寻常的构建设置，但即使是这个基线也比让 Agent 从头推断要好得多。

保持 AGENTS.md 不腐化：

过时的 AGENTS.md 可能比没有文件更糟糕。Cloudflare 通过 AI 代码审查器来关闭这个循环——当仓库变更表明 AGENTS.md 应该更新时，审查器会发出提示。

---

六、执行层

AI 代码审查器：所有 MR，100% 覆盖

Cloudflare 的每个合并请求都会得到 AI 代码审查。集成很简单：团队在流水线中添加一个 CI 组件，此后每个 MR 都会被自动审查。

审查器以多 Agent 审查协调器运行 OpenCode。协调器按风险层级（Trivial、Lite 或 Full）对 MR 进行分类，并委托给专项审查 Agent：代码质量、安全、Codex 合规、文档、性能和发布影响。每个 Agent 通过 AI Gateway 访问模型，从中央仓库拉取 Engineering Codex 规则，读取仓库的 AGENTS.md 获取代码库上下文，并将结果以结构化 MR 评论的形式发回。

审查器在多轮迭代中保持上下文。如果它在上一轮审查中标记了某个问题，而该问题已经被修复，它会予以确认而非重新提出。当一条发现映射到 Engineering Codex 规则时，它会引用具体的规则 ID，将一个 AI 建议变成对组织标准的引用。

过去 30 天的数据：所有标准 CI 流水线上的仓库实现 100% AI 代码审查覆盖；547 万次 AI Gateway 请求；247.7 亿个 Token 处理。

Workers AI 处理了约 15% 的审查流量，主要用于文档审查任务（Kimi K2.5 在这类任务上表现出色且成本远低于前沿模型）。涉及安全敏感和架构复杂的审查则使用 Opus 4.6 和 GPT 5.4 处理。

Engineering Codex：把工程标准变成 Agent 技能

Engineering Codex 是 Cloudflare 新的内部标准系统，核心工程标准在此集中。通过多阶段 AI 提炼流程，输出一套 Codex 规则（“如果需要 X，使用 Y；如果在做 Y 或 Z，必须做 X”），以及一个使用渐进式披露和嵌套层级信息目录的 Agent 技能。

这个技能对工程师开放，可以用"我的 Rust 服务应该如何处理错误？"或"审查这段 TypeScript 代码是否符合规范"这样的 Prompt 本地使用。在代码审查时，AI 代码审查器在反馈中引用具体的 Codex 规则，将 AI 建议与组织标准直接挂钩。

---

七、成绩单

从启动这项工作到研发部门 93% 的采用率，用了不到一年。

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

指标	数值
活跃用户	3683（占全公司 60%）
研发团队采用率	93%
AI 消息数	4795 万
有 AI 活动的团队数	295

AI Gateway（过去 30 天）： 2018 万次请求，2413.7 亿个 Token。

Workers AI（过去 30 天）： 514.7 亿个输入 Token，3.61 亿个输出 Token。

---

八、下一步：后台 Agent

内部工程栈的下一个演进方向是后台 Agent：按需启动、拥有与本地相同工具集（MCP Portal、git、测试运行器），但完全运行在云端的 Agent。架构使用 Durable Objects 和 Agents SDK 进行编排，当任务需要完整开发环境（克隆仓库、安装依赖、运行测试）时委托给 Sandbox 容器。Agents Week 期间正式 GA 的 Sandbox SDK 使这成为可能。

长时运行的 Agent（在 Agents Week 期间原生集成进 Agents SDK）解决了以前需要各种变通的持久会话问题。SDK 现在支持运行时间足够长的会话，可以在一次会话内克隆大型仓库、运行完整测试套件、迭代修复失败，并打开一个合并请求。

---

九、总结：不是工具叠加，而是系统重新布线

这篇文章最值得深读的部分，不是任何单个功能，而是三层之间的连接方式。

这些单独的部件本身并不新颖。很多公司都在运行服务目录、发布审查机器人或发布工程标准。不同之处在于布线。当一个 Agent 能从 Backstage 拉取上下文、读取它正在编辑的仓库的 AGENTS.md、并被同一套工具链依照 Codex 规则审查时，第一稿通常已经足够接近可以发布的状态。六个月前这还不是真的。

这套架构的另一个核心价值在于：所有东西都建立在向客户出售的同一套产品上。这不是"我们内部有一套特殊基础设施"，而是一个完整的参考实现。对于正在考虑如何在组织内推进 AI 工程化的团队，这份复盘提供的不只是结论，还有可以直接对照的架构蓝图。

---

原文链接：https://blog.cloudflare.com/internal-ai-engineering-stack/