Sam Rhea 是 Cloudflare 的首席信息官。
大约半年前，我意识到我们遇到了问题：销售团队的一位成员找到我，向我要 API 密钥，而且是复数的密钥。他们用 AI 构建了一个自称为 SuperApp 的东西，说它将改变我们的市场拓展团队。要让它跑起来，他们只需要 Cloudflare 大约十几个记录系统（system of record）的生产访问权限，以及一条部署流水线的管理员权限。
2025 年，我们在 Cloudflare 推广 AI 的态度相当谨慎。我们部署了信息类的聊天应用，也尝试用 AI 帮忙写一些样板代码，但我们觉得这项技术还不足以改变我们的工作方式。
然后，在去年年底的短短几天里，更好的模型和更强大的套件（harness）改变了这笔账。AI 智能体能够做事了，而且做得很好。Cloudflare 各个技术和非技术岗位的数百名团队成员，在新年前后较为清闲的几周里，试验了让构建变得前所未有地容易的新工具。
那位构建 SuperApp 的销售同事只是第一个，随后涌来的是一大批举手要求使用这些工具来改变工作方式的人。我们有义务为他们配备条件、提供支持。但我们同样有义务保护我们的系统、内部数据和客户数据的安全。
过去几个月里，我们一直在 Cloudflare 内部构建一个平台来做到这一点，我们称之为 Cloudflare OS。我们起初把开发者平台和 Zero Trust 平台中的现成组件拼接在一起，比如 Cloudflare Workers 和 Access。随着我们对这一挑战了解得更多，我们也创建了为这种新工作方式量身定制的自有服务。
与 Cloudflare 的许多产品一样，我们着手解决的是自己内部遇到的问题。事实证明，你们中的许多人也有同样的问题。因此，今天我们很高兴地发布 Cloudflare OS，它汇集了我们在内部推出的一切，让我们自己的团队成员能够安全且高效地使用 AI 并部署智能体。关于目前已可使用的内容，你可以在 Phillip 的文章中了解更多。
在这篇文章中，我想带你回顾我们自己内部的历程，它最终促成了这次发布，既包括进展顺利的地方，也包括我们栽跟头的地方。共分五个部分：我们一开始确立的原则；我们如何通过试点弄清楚要完成的任务（jobs to be done）是什么；我们为工程师和非工程师分别构建了什么；以及我们如何在整个组织中培养推动变革的倡导者。
过去几个月里，我觉得自己是世界上最幸运的 CIO，因为我所支持的团队能够使用这些新兴技术。今天的目标，是把这个平台和它带来的经验分享给每一个团队。
确立基本规则
我们首先制定了一套关于这件事应当如何运作的原则。Cloudflare 的 CTO 和我坐在德克萨斯州奥斯汀的办公室里，开始勾勒我们采用 AI 时必须成立的条件。我们邀请了整个组织的领导者对草案提出反馈。最终的结果就成了下面这些准则。
1）我们用 AI 来花更多时间陪伴客户，并构建技术来解决他们更多的问题。
我们不想为了用 AI 而用 AI。我们推动团队先定义他们的“待完成任务”（jobs to be done），也就是那些能够改善我们服务客户方式的痛点、瓶颈或错失的机会，然后再去寻找合适的工具。
2）每个人都应该拥有超能力。
AI 非常非常擅长写代码。由此推及，第一波能够采取行动的 AI 工具，采用的都是开发者本来就在使用的界面：命令行、代码编辑器、终端、Git 仓库。
这些形式可能会让我们团队中的很大一部分人掉队。虽然我们的员工技术能力很强、充满好奇心，但并不是每位成员都整天泡在开发者工具里。而且我们并不认为他们需要这样！我们希望员工带来他们的专业知识，而我们则为他们提供一个直观的平台，让他们用来重新思考我们的工作方式。
3）人对产出负责。
我们把 AI 视为工具和造物者，而不是团队成员。我们期望人类对依赖 AI 产出的质量、测试和工作流程的定义承担责任。
这条规则同样适用于部署智能体。发布智能体的用户和团队要对这些智能体的产出负责。有人离职了？他们的经理会像继承其他工作流程一样，继承其智能体的责任。
4）来自组织的上下文比模型更重要。
我们在 Cloudflare 部署的工作流和智能体需要了解 Cloudflare。我们在技术上投入的时间，必须与投入到一个经过精心整理的、权威的上下文层上的时间相匹配。
5）使用 AI 时，你对记录系统的权限永远不应该更多。
Cloudflare 的每个人对底层数据都只有限定范围的视图，这是有充分理由的。我们用自己的产品，按设备、角色、地区等因素来划分数据访问。我们还会在第三方应用内部配置并监控各项控制。
当我管理一个与同样的数据交互的 AI 智能体时，这些控制同样必须适用。使用 AI 工具时，我绝不应该拥有“更多”的数据访问权限，而我的 AI 智能体应当只能访问其所需的确切内容，不多一分。而且，如果我部署了一个智能体并分享给别人，那么该智能体向对方提供的访问权限应当反映对方的权限，而不是我的。
走到用户身边
规则确定之后，我们就动手了。我们并行开展了两个项目：第一个面向工程团队，第二个面向所有其他类型的工作。
为工程师提供护栏
AI 工具让工程师原本就在做的工作变得更快——快到我们的评审流程跟不上。如今 Cloudflare 的任何人都可以借助 AI 更快地写出糟糕的代码。我们需要更好的护栏。
于是我们为工程构建了一个上下文层，称之为 Cloudflare Engineering Codex。Codex 是一份权威指南。我们的这份阐明了我们所遵循的原则和实践。策略（Policy）告诉你不能做什么，而 Codex 告诉你应该做什么。它在设计上是有鲜明立场的。我们代码库的每个部分都有一位领域负责人，对那里什么是好的标准负责。
我们把这个上下文层贯穿整个软件开发生命周期。智能体借助 Codex 帮助工程师规划工作。一个智能体依据 Codex 的要求评审每一个合并请求（Merge Request）。另一个在实施开始之前评审技术设计。第三个评审事故报告。在过去四个月里，这些智能体标记了近 25 万个潜在问题，拦截了 16,000 次合并。它们在近 600 份设计中、在写下一行代码之前就发现了架构问题。
关于我们如何构建这套代码评审工作流，你可以在 Timo 关于 AI 代码评审的博文中读到更详细的介绍。我们现在把重点转向为工程师提供工具，让他们定义用来评估其智能体产出的循环。
给每个人一个神奇的邮件别名
我们早期犯的一个错误，是给工程之外的所有人提供与工程师相同的工具，只是用户界面稍微友好一些。工程师可以把代码仓库克隆到笔记本电脑上，添加一个像 AGENTS.md 这样的上下文文件，然后让他们的套件去处理工作。然而，市面上的套件与其他类型的知识工作匹配得很差：在这些工作中，用户创建的是一次性的产出，所做的项目涉及几十个记录系统。
如果你给每个人一个擅长写代码的套件工作区，最后得到的代码会远远超出你的需要。结果就是涌现出一大堆靠感觉编程（vibe coding）做出来、却在到处找问题可解的应用。于是我们倒推回去。
我们告诉 Cloudflare 的每个人，他们可以把不想做的工作发给一个“神奇的 AI 邮件机器人”，它会回复他们所需的产出。在幕后，是一个小团队用 AI 工具来处理这个邮件别名并完成工作。
不知为何，人们不太愿意把他们的 vibe coding 想法发给自己以为是自动化的系统，却非常乐意把自己不想做的工作发过去。在管理这个邮件别名的数百次、继而数千次会话中，我们识别出了团队成员希望自动化的那些琐碎工作。
我们手动对这些进行分流，并随着时间推移观察到了一些模式。我们创建了技能和上下文文件，梳理出数据连接，并定义了用户所需的产出类型。有了这些，我们就能自动化回复这个邮件别名收到的部分请求。
我们非常想摆脱给这个服务配人值守的状态，因为那实在太痛苦了。长远目标是把我们整理好的这些材料做成技能（skill），让用户自己解决问题。这个邮件别名背后的人工工作一直持续到我们觉得已经梳理出足够多 Cloudflare 内部常见的“待办任务（jobs to be done）”，可以让各团队在自动化上先行一步为止。现在，我们需要给他们一个平台，让他们能轻松、安全地运行这些工作流。
为团队成员提供解决问题的平台
这个平台的第一个版本，我们称之为 Cloudflare OS，是一个运行在 Cloudflare 基础设施容器里的简易 harness。用户通过网页浏览器访问，经 Cloudflare Zero Trust 认证后，就可以运行我们在“神奇邮箱”阶段开始积累的技能文件和工作流。
这一切都在浏览器内完成，无需任何本地配置。用户打开笔记本就能立刻开始高效工作。我们听到销售团队的新成员说，入职几天之内，他们就觉得自己可以把在上一家公司需要数周才能完成的工作自动化。
用户还可以合上电脑，去喝杯咖啡或上趟洗手间，任务照样在后台进行。再也不用抱着半开的笔记本在办公室里走来走去了。
我们认为，基于云的工作空间受益的不只是用户。一个临时性的云端环境只能访问用户在会话中主动引入的数据，而使用本地 harness 时，面前这台笔记本上的几乎所有内容都可能被触及。我们的安全团队对该环境拥有审计可见性和网络控制权，包括过滤它能连接互联网上哪些地方的能力。
用户需要完成工作时，首先运行由我们在各部门识别出的常见工作流所定义的技能文件。公司在“神奇邮箱”阶段积累的上下文和技能，只需一次点击就能变成可执行的内容。
右侧面板会渲染指定技能文件的输出，比如技术架构文档或幻灯片。用户可以把输出分享给队友。
我们通过 Model Context Protocol（MCP）Portal 把各个系统记录（systems of record）连接起来，让 Cloudflare OS 能够访问数据。MCP 标准是一个框架，它定义了如何把 AI 工具连接到系统记录，并告诉 AI 工具有哪些数据和操作可用。遵循我们的权限规则，用户会话在 Cloudflare OS 中的访问范围，限定为其在相应系统记录中已有的权限集。
在大多数情况下，即使系统记录本身提供了原生的 MCP 服务器，我们也会为每个系统记录自行构建并部署一套 MCP 服务器实现。自己构建，就能增加额外的控制层，比如按角色或区域设置速率限制。Cloudflare Workers 为我们提供了一个简单的构建场所，而且作为无服务器平台，后续的维护负担几乎为零。
Cloudflare OS 使用 AI 推理时，我们会把请求通过 AI Gateway 路由。这样我们就能过滤、记录并审计用户与这些 AI 系统之间的所有交互。例如，我们可以复用 Secure Web Gateway 中的数据防泄漏（Data Loss Prevention，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 智能体编写驱动这些图表的代码，并通过我们称为 gatekeeper 的服务建立到数据集的安全连接。这个 gatekeeper 负责处理我的智能体对数据集发出的各类固定查询，为应用缩小上下文范围，而且无需管理任何 API 密钥。
真正需要 AI 推理时，我可以把它嵌入应用中。我做了一些选项，用 AI 为新到的工单起草回复，我审阅后再发送。这一切都在一个受保护的工作空间内完成，我不需要创建和管理任何集成或部署流水线。
当我把自己构建的智能体分享给其他人时，他们通过同样的 gatekeeper，用自己的权限对该智能体进行认证，因此不会跨越数据边界。而且每次加载初始报告时，我消耗的 token 恰好为零。
派出“冠军”，分享你的成果
Cloudflare OS 为我们提供了所需的平台，但我们仍然需要赋能团队。为此，我们没有招聘专门的 AI 团队，而是在各种岗位上找到早期采用者，把他们培养成能帮助同事使用这个新平台的“冠军”。我们请到了伦敦的一位销售负责人、德克萨斯的一位解决方案工程师、葡萄牙的一位投资者关系负责人、日本的一位业务拓展成员、美国的一位销售运营负责人等等，请他们与各自的团队合作，重新思考工作方式。
我们还成功地把实习生嵌入到现有团队中。我们宣布今年的目标是招收 1,111 名实习生，其中许多已经加入的实习生在各部门工作，目标很简单：“用我们的 AI 工具武装团队，把这个团队变成全明星。”
结果持续让我们惊叹。每周有数千名 Cloudflare 团队成员使用这个平台，日活跃用户数在每一个工作日都在增长。仅在上个月，我们估计销售团队成员在区域规划和方案创建等原本需要手工完成的任务上，就节省了超过 10,000 小时。在这 30 天里，用户创建了 4,000 多个应用和工具来解决具体问题。
下一步是什么？
我们还远没有结束，但每一天，当我们执着地思考如何重新设计解决问题所需的工作时，都能看到一点新的进展。昨晚有人给我发来 Cloudflare OS 中的一份报告链接，它帮助我们诊断出一个采购瓶颈，而这在过去需要花几天时间手动翻查电子表格。今天早上，IT 团队的一位成员把基于该平台构建的、用于跟踪笔记本电脑更换的工作流智能体，分享给了里斯本办公室里坐在他附近的一位财务团队同事。这些小小的自动化和知识分享，正在不断累积。
正如我们致力于让 Cloudflare 的每个人都拥有超能力一样，我们认为 Cloudflare 之外的每个团队也都应该拥有。我们很高兴今天与大家分享 Cloudflare OS，并期待随着我们一起学习得更多，它能继续快速演进。如果有人想坐下来交流内部 AI 落地中哪些有效、哪些无效，欢迎告诉我们。我很乐意聊聊，人与人之间的交流。