Cloudflare公开企业级AI工作平台实践

Sam Rhea 是 Cloudflare 的首席信息官。

大约六个月前，当销售组织的一名成员联系我索要 API 密钥时，我意识到我们遇到了一个问题。注意，是多个密钥。他们使用 AI 构建了一个据称能够彻底改变市场进入团队工作方式的 SuperApp。为了让它正常运行，他们只需要 Cloudflare 大约十几个记录系统的生产环境访问权限，以及部署流水线的管理员权限。

2025 年期间，Cloudflare 在推广 AI 方面采取了相当谨慎的方式。我们部署了信息查询类聊天应用，也尝试使用 AI 协助编写一些样板代码，但当时我们认为，这项技术还不足以改变我们的工作方式。

然而，就在去年年底短短几天内，更出色的模型和更强大的执行框架改变了这一判断。AI 智能体已经能够执行任务，而且完成得很好。在新年前后工作节奏较为平缓的几周里，Cloudflare 数百名来自技术和非技术岗位的团队成员开始尝试各种新工具，这些工具让构建应用变得前所未有地容易。

那位构建 SuperApp 的销售团队成员，只是随后汹涌而来的第一人。越来越多的人主动提出，希望利用这些工具改变自己的工作方式。我们有责任为他们提供必要的工具和支持，让他们能够做到这一点。但与此同时，我们也有责任确保自身系统、内部数据和客户数据的安全。

过去几个月里，我们一直在 Cloudflare 内部构建一个平台，目的正是同时满足这些要求。我们将其称为 Cloudflare OS。最初，我们把开发者平台和 Zero Trust 平台中的现成组件组合在一起，例如 Cloudflare Workers 和 Access。随着对这一挑战的了解不断深入，我们也创建了专门适配这种全新工作方式的定制服务。

与 Cloudflare 的许多产品一样，我们最初只是为了解决自身面临的问题。结果发现，很多人也遇到了同样的问题。因此，今天我们很高兴与大家分享 Cloudflare OS——它汇集了我们在内部推出的所有能力，让自己的团队成员能够安全、高效地使用 AI 和部署智能体。关于目前已经提供的功能，你可以阅读 Phillip 的文章了解更多信息。

在本文中，我想介绍促成这次发布的 Cloudflare 内部历程，包括哪些方面进展顺利，以及我们在哪些地方走了弯路。全文分为五个部分：我们最初确立的原则；如何通过试点确定需要完成的工作；我们分别为工程师和非工程师构建了什么；以及我们如何在整个组织中培养推动变革的倡导者。

过去几个月里，我感觉自己是全世界最幸运的 CIO，因为我所支持的团队能够接触到这些新兴技术。今天，我们的目标是把这个平台以及从中获得的经验分享给每一个团队。

首先，我们围绕这套工作方式定义了一系列原则。Cloudflare 的 CTO 和我坐在得克萨斯州奥斯汀的办公室里，开始勾勒在采用 AI 的过程中必须满足哪些条件。我们邀请组织内各部门的负责人对草案提出反馈，最终形成了以下准则。

1）我们使用 AI，是为了花更多时间陪伴客户，并构建能够解决客户更多问题的技术。

我们不希望只是为了使用 AI 而使用 AI。我们要求团队首先定义自己的“待完成工作”，也就是那些能够改善客户服务的痛点、瓶颈或被错过的机会，然后再寻找合适的工具。

2）每个人都应该拥有超能力。

AI 非常、非常擅长编写代码。因此，第一批能够实际执行操作的 AI 工具采用的，都是开发者早已习惯使用的界面：命令行、代码编辑器、终端和 Git 仓库。

这些形式可能会让我们团队中的很大一部分人掉队。尽管我们的员工普遍具备很强的技术能力和好奇心，但并非每一位团队成员每天都会使用开发者工具。我们也不认为他们有必要这样做！我们希望员工发挥自己的领域专业知识，而我们则为他们提供一个直观的平台，让他们能够借此重新思考我们的工作方式。

3）人类对输出负责。

我们将 AI 视为工具和工具制造者，而不是团队成员。我们要求人类负责定义质量标准、开展测试，并对依赖 AI 输出的工作流承担责任。

这条规则同样适用于智能体的部署。发布智能体的用户和团队需要对这些智能体的输出负责。如果某人离职，其经理将继承该员工智能体的责任，就像继承其负责的其他工作流一样。

4）来自组织的上下文比模型更重要。

我们在 Cloudflare 部署的工作流和智能体需要了解 Cloudflare。在技术上投入时间的同时，我们也必须投入时间，构建经过精心整理且权威统一的上下文层。

5）使用 AI 时，你对记录系统的权限绝不能比平时更高。

Cloudflare 的每个人只能查看 Cloudflare 底层数据中与其职责相符的范围，这是有充分理由的。我们使用自己的产品，依据设备、角色、地区等因素对数据访问进行分段控制。我们也会配置和监控第三方应用中的控制措施。

当我管理一个与相同数据交互的 AI 智能体时，这些控制措施也必须生效。使用 AI 工具时，我绝不能获得“更多”数据访问权限；我的 AI 智能体也只能访问它确切需要的数据，不能多访问任何内容。如果我部署了一个智能体并将其分享给其他人，该智能体向他们提供的访问权限应当以他们自身的权限为准，而不是以我的权限为准。

在用户熟悉的地方与他们相遇

这些规则确立后，我们便开始行动。我们并行运行了两个项目：第一个面向工程团队，第二个面向其他所有类型的工作。

为工程师提供护栏

AI 工具加快了工程师原本就在做的工作——快到我们的审查流程难以跟上。借助 AI，Cloudflare 的任何人现在都能更快地写出糟糕的代码。我们需要更完善的护栏。

因此，我们为工程工作构建了一个上下文层，称为 Cloudflare Engineering Codex。Codex 是一份权威指南。我们的 Codex 规定了工作中应遵循的原则和实践。策略告诉你哪些事情不能做，而 Codex 则告诉你应该怎么做。它被有意设计成具有明确主张的形式。代码库的每个部分都有一位领域负责人，负责定义该领域的优秀标准。

我们让这个上下文层贯穿软件开发生命周期。智能体使用 Codex 帮助工程师规划工作。一个智能体会依据 Codex 的要求审查每一个 Merge Request；另一个智能体会在实施开始前审查技术设计；第三个智能体则负责审查事故报告。在过去四个月里，这些智能体标记了近 25 万个潜在问题，并阻止了 16,000 次合并。在编写任何一行代码之前，它们就在近 600 份设计中发现了架构问题。

关于我们如何构建这套代码审查工作流，你可以在 Timo 关于 AI Code Review 的博客文章中阅读更详细的介绍。现在，我们正将重点转向为工程师提供工具，让他们能够定义用于评估智能体产出成果的反馈循环。

为所有人提供一个神奇的电子邮件别名

我们早期犯过的一个错误，是向工程团队之外的所有人提供与工程师相同的工具，只是为其配上稍微友好一些的用户界面。工程师可以把代码仓库克隆到笔记本电脑上，添加 AGENTS.md 之类的上下文文件，然后让执行框架处理相关工作。然而，市面上的执行框架并不适合其他类型的知识工作，因为这些工作中的用户通常需要创建一次性交付物，并参与涉及数十个记录系统的项目。

如果给每个人都提供一个非常擅长编写代码的执行框架工作区，最终得到的代码将远远超过实际需要。结果，大量通过凭感觉编程构建的应用蜂拥而至，却找不到需要解决的问题。因此，我们选择从结果倒推。

我们告诉 Cloudflare 的所有人，他们可以把不想做的工作发送给一个“神奇的 AI 邮件机器人”，它会回复他们所需要的结果。实际上，在幕后，一个小团队负责处理这个电子邮件别名，并使用 AI 工具完成这些工作。

不知为何，人们不太愿意把自己的凭感觉编程创意发送给一个他们以为是自动化系统的对象，却非常乐意把自己不想做的工作发给它。在通过这个电子邮件别名处理了数百次、继而数千次会话后，我们识别出了团队成员希望实现自动化的那些繁琐工作。

我们先以人工方式对这些请求进行分流，并随着时间推移观察其中的规律。我们创建了技能文件和上下文文件，梳理了数据连接，并定义了用户所需的输出类型。有了这些基础，我们便可以自动回复发送到这个电子邮件别名的部分请求。

我们非常希望不再安排人员维护这项服务。因为这项工作实在令人痛苦。我们的长期目标是将整理好的这些材料转化为用于解决相关问题的技能，让用户能够自行解决问题。这个电子邮件别名背后的人工工作一直持续到我们认为已经充分涵盖了 Cloudflare 常见的“待完成工作”，足以帮助各团队更快启动自动化。现在，我们只需要为他们提供一个能够轻松、安全地运行这些工作流的平台。

为团队成员提供解决问题的平台

这个平台的第一个版本被称为 Cloudflare OS，由一个运行在 Cloudflare 基础设施容器中的简单执行框架组成。用户可以通过 Web 浏览器访问它，并在通过 Cloudflare Zero Trust 完成身份验证后，运行我们在“神奇电子邮件”阶段开始收集的技能文件和工作流。

Cloudflare OS V1 登录页

所有这些操作都在浏览器中完成，无需进行任何本地配置。用户打开笔记本电脑，立即就能开始高效工作。销售团队的新成员告诉我们，入职仅仅几天后，他们就觉得自己已经能够自动化处理一些在上一家公司需要数周才能完成的工作。

用户还可以在任务执行期间合上电脑，去喝杯咖啡或上个洗手间。再也不用带着半开着的笔记本电脑在办公室里四处走动了。

我们认为，云端工作区带来的好处并不只属于用户。临时云端环境只能访问用户引入当前会话的数据；而使用本地执行框架时，它可能有权访问你面前那台笔记本电脑上的所有内容。我们的安全团队可以审计和控制该环境的网络访问，包括过滤它能够连接到的互联网位置。

当用户需要完成工作时，可以先运行根据我们在各部门中发现的通用工作流定义的技能文件。我们在“神奇电子邮件”阶段收集的公司累积上下文和技能，只需单击一下即可执行。

右侧面板会呈现指定技能文件的输出，例如技术架构文档或幻灯片。用户可以与团队成员共享这些输出结果。

我们通过 Model Context Protocol（MCP）Portal 连接各个记录系统，让 Cloudflare OS 能够访问数据。MCP 标准是一套框架，它定义了如何将 AI 工具连接到记录系统，并向 AI 工具说明有哪些数据和操作可供使用。遵循我们的权限规则，用户会话在 Cloudflare OS 中拥有的访问权限，仅限于该用户在指定记录系统中现有的权限集。

在大多数情况下，即使记录系统提供原生版本，我们也会为每个记录系统自行构建并部署 MCP 服务器实现。自行构建让我们能够增加额外的控制层，例如按角色或地区设置速率限制。Cloudflare Workers 为我们提供了一个构建这些服务器的简单平台；同时，由于它是无服务器平台，持续维护负担实际上几乎为零。

当 Cloudflare OS 使用 AI 推理时，我们会通过 AI Gateway 路由相关请求。这样，我们就能够过滤、记录和审计用户与这些 AI 系统之间的所有交互。例如，我们可以复用 Secure Web Gateway 中的数据丢失防护（DLP）规则，阻止特定数据集被发送给任何提供商。

AI Gateway 还让我们能够控制模型的使用。并非每位用户都需要使用最新前沿实验室模型的最高思考模式。我们也不需要团队成员每小时花费 20 美元来总结自己的电子邮件收件箱。我们可以使用 AI Gateway，根据角色限制模型的使用，或者将具体用例——尤其是定时运行技能文件等自主程度较高的用例——引导至效率更高的模型。

现在，通过人人可用的智能体提高确定性

Cloudflare OS 为我们的团队提供了一个 AI 工作区，用户可以在其中运行技能文件和自己的工作流。然而，用户每次运行技能文件，都会启动一个消耗大量 token 的推理会话。我们的大部分工作在很大程度上都是确定性的：它们是一系列步骤，只需在适当的位置加入一些推理（或人工判断）。与其总让 AI 充当工具，我们更需要 AI 成为工具的创造者。

为了解决这个问题，我们着手更新 Cloudflare OS，也就是今天要与大家分享的版本。这个版本允许用户用自然语言描述工作流，让 AI 智能体创建用于驱动该工作流的代码，然后按需运行智能体、定时运行智能体，或由事件触发智能体。我们不再尝试构建一套通用智能体供整个组织共享，而是让每一位团队成员都能创建默认相互隔离的安全应用程序。

例如，与我合作的一个团队是我们的 IT 服务台。我们为 Cloudflare 的团队成员提供工作所需的硬件和软件支持，覆盖从配置发放、问题调试到离职处理的全过程。我们通过传统的工单队列管理这些工作。

每天早上，我都想查看待处理工单队列，以及与我们服务这些内部客户的能力有关的指标。在使用 Cloudflare OS 之前，我会手动完成这项工作。我们的工单系统内置了仪表板，但功能非常基础。我会下载 CSV 文件并将其导入 Google Sheets，然后在其中创建图表。接着，我会手动逐一打开夜间收到的每张工单。这不仅耗费时间，还会在记录系统之外产生重复数据。

在 Cloudflare OS v1 中，我通过一个连接到工单软件 MCP 服务器的技能文件执行这项工作。虽然这种方式更加安全（人工操作也更少），但这意味着我每天早上都要消耗数千个 token，重新生成一份内容基本相同的报告。我还在分类处理夜间工单并起草回复时白白消耗了大量 token。

Cloudflare OS v2 为我以及其他需要解决类似问题的人处理了这一切。我描述了自己想查看的图表，它便使用 AI 智能体编写驱动这些图表的代码，同时通过我们称为“守门人”的服务建立与数据集的安全连接。守门人负责处理我的智能体向数据集发起的固定查询，在不需要管理任何 API 密钥的情况下，缩小应用程序可访问的上下文范围。

当我确实需要 AI 推理时，可以将其嵌入应用程序中。我构建了使用 AI 为新到工单起草回复的功能。我可以审核这些回复并将其发送出去。所有操作都在安全工作区中完成，无需我创建和管理任何集成或部署流水线。

当我与其他人共享自己构建的智能体时，他们会通过相同的守门人，使用各自的权限向智能体进行身份验证，因此我们不会跨越数据边界。而且，我每次加载初始报告时消耗的 token 数恰好为零。

派出倡导者并分享成果

Cloudflare OS 为我们提供了所需的平台，但我们仍然需要帮助团队掌握它。为此，我们没有组建一支专门的 AI 团队，而是从不同岗位中找到一批早期采用者，将他们培养成推广先锋，帮助同事使用这个新平台。我们邀请了伦敦的一位销售负责人、得克萨斯州的一位解决方案工程师、葡萄牙的一位投资者关系负责人、日本的一位业务拓展团队成员、美国的一位销售运营负责人等，请他们与各自的团队合作，重新思考工作方式。

我们还成功地将实习生安排到成熟团队中。我们宣布了今年招募 1,111 名实习生的目标，许多已经加入我们的实习生正在各个部门工作，他们的目标很简单：“用我们的 AI 工具武装团队，让这支团队人人都成为明星。”

取得的成果仍在不断带给我们惊喜。每周都有数千名 Cloudflare 团队成员使用该平台，日活跃用户数在每一个工作日都保持增长。仅在过去一个月，我们估计销售团队成员就在区域规划和提案制作等过去需要手动完成的任务上节省了超过 10,000 个小时。在这 30 天里，用户创建了 4,000 多个应用和工具，用于解决具体问题。

距离完成目标，我们还差得很远。但当我们全力思考如何重新设计解决问题所需的工作时，我每天都能看到新的进展。昨晚，有人给我发来了一份 Cloudflare OS 报告的链接，它可以帮助我们诊断采购流程中的瓶颈；过去，这项工作需要花上几天逐一检查电子表格。今天早上，在里斯本办公室，一位 IT 团队成员向坐在附近的一位财务团队成员分享了一个基于该平台构建的工作流智能体，用来跟踪笔记本电脑的更换情况。正是这些看似微小的自动化与知识共享行动，最终汇聚成了显著的成效。

正如我们致力于让 Cloudflare 的每个人都拥有超能力一样，我们认为 Cloudflare 之外的每个团队也应该拥有这样的能力。今天，我们非常高兴能与大家分享 Cloudflare OS；随着我们共同积累更多经验，我们预计它将继续快速演进。如果有人想坐下来交流一下内部 AI 推广中哪些做法有效、哪些无效，请随时联系我们。我非常愿意与你聊聊——以人与人之间的方式。