我是 Cloudflare 的首席信息官 Sam Rhea。大约六个月前，当销售团队的一位成员向我索要 API 密钥时，我就知道我们遇到了问题——而且是多个密钥。他们用 AI 构建了一个他们称之为“超级应用”的东西，旨在改造我们的市场推广团队。他们所需要的只是 Cloudflare 内部十几个记录系统的生产访问权限，以及一个部署管道的管理员权限。2025 年，我们在 Cloudflare 推广 AI 时采取了相当谨慎的态度。我们部署了信息类聊天应用，并尝试用 AI 编写一些样板代码，但我们认为这项技术还没有准备好改变我们的工作方式。然而，在去年年底的几天里，更好的模型和更强大的工具框架改变了这一局面。AI 代理能够做事了，而且能做得很好。Cloudflare 的数百名员工，无论技术岗位还是非技术岗位，都在新年假期前后那段相对清闲的几周里，尝试了那些让构建变得前所未有的简单的新工具。那位销售团队成员构建他们的“超级应用”只是冰山一角，随后大量的人纷纷举手，希望使用这些工具来改变他们完成工作的方式。我们有义务为他们提供装备和支持。但同时，我们也有义务保护我们的系统、内部数据和客户数据的安全。过去几个月，我们一直在 Cloudflare 内部构建一个平台来实现这一目标。我们称之为 Cloudflare OS。我们首先将 Developer 和 Zero Trust 平台（如 Cloudflare Workers 和 Access）中的现成组件拼接在一起。随着我们对挑战的了解加深，我们还创建了针对这种新工作方式定制的服务。与 Cloudflare 的许多产品一样，我们最初是为了解决内部问题。事实证明，你们中的许多人也遇到了同样的问题。这就是为什么今天我们很高兴地分享 Cloudflare OS，这是我们内部推出的所有功能的集合，旨在让我们的团队成员能够安全、高效地使用 AI 并部署代理。你可以在 Phillip 的这篇文章中了解更多关于当前可用功能的信息。在这篇文章中，我想回顾一下我们内部促成此次发布的历程，包括哪些进展顺利，哪些地方我们栽了跟头。文章分为五个部分：我们最初制定的原则；我们如何试点以明确需要完成的工作；我们为工程师和非工程师分别构建了什么；以及我们如何在组织内培养变革推动者。在过去的几个月里，我感觉自己是世界上最幸运的首席信息官，因为我所支持的团队能够接触到这些新兴技术。今天的目标是与每个团队分享这个平台及其经验教训。
**制定基本规则** 我们首先围绕这项工作应该如何开展制定了一套原则。我和 Cloudflare 的首席技术官在德克萨斯州奥斯汀的办公室里坐下来，开始勾勒我们在采用 AI 时需要满足的条件。我们邀请了来自组织各方的领导者对草案提出反馈。最终形成了以下指导方针。
1) 我们使用 AI 是为了花更多时间与客户在一起，并构建技术来解决他们更多的问题。我们不想为了使用 AI 而使用 AI。我们推动团队首先定义他们的“待完成工作”，即那些可以改善我们服务客户方式的痛点、瓶颈或错失的机会。然后我们找到合适的工具。
2) 每个人都应该拥有超能力。AI 非常非常擅长编写代码。因此，第一波能够采取行动的 AI 工具由开发者已经使用的界面组成：命令行、代码编辑器、终端、Git 仓库。这些格式可能会让我们的很大一部分团队成员掉队。虽然我们拥有一支技术能力很强且充满好奇心的员工队伍，但并非每个团队成员都在开发者工具中度过他们的一天。而且我们认为他们也不需要这样！我们希望员工发挥他们的领域专长，我们会为他们提供一个直观的平台，让他们可以重新思考我们的工作方式。
3) 人类对输出负责。我们将 AI 视为工具和工具制造者，而不是团队成员。我们期望人类对依赖 AI 输出的质量、测试和工作流程的定义负责。这条规则也适用于部署代理。发布代理的用户和团队要对其输出负责。如果有人离开？他们的经理会像接管其他工作流程一样，接管他们的代理责任。
4) 组织的上下文比模型更重要。我们在 Cloudflare 部署的工作流程和代理需要了解 Cloudflare。我们在技术上花费的时间必须与投资于一个精心策划的、规范的上下文层的时间相匹配。
5) 使用 AI 时，你对记录系统的权限绝不应超过平时。Cloudflare 的每个人对底层数据都有基于范围的视图，这是有充分理由的。我们使用自己的产品，根据设备、角色、地区等因素来细分数据访问权限。我们还在第三方应用程序内部配置和监控控制措施。当我管理一个与相同数据交互的 AI 代理时，这些控制措施需要适用。我绝不应该因为使用 AI 工具而获得“更多”的数据访问权限，我的 AI 代理只应拥有它们确切需要的访问权限，仅此而已。如果我部署了一个代理并与他人分享，该代理为他们提供的访问权限应反映他们的权限，而不是我的。
**在用户所在之处与他们相遇** 有了这些规则，我们就开始工作了。我们并行运行了两个项目：一个针对我们的工程团队，另一个针对所有其他类型的工作。
**为工程师提供护栏** AI 工具让工程师们已有的工作变得更快——快到我们的审查流程都跟不上。现在，得益于 AI，Cloudflare 的任何人都能更快地写出糟糕的代码。我们需要更好的护栏。因此，我们为工程构建了一个上下文层。我们称之为 Cloudflare 工程准则（Codex）。准则是一份权威指南。我们的准则阐述了我们的工作原则和实践。政策告诉你不能做什么，而准则告诉你应该做什么。它天生带有主观性。我们代码库的每个部分都有一个领域负责人，负责定义该部分“好”的标准。我们在整个软件开发生命周期中展示了这个上下文层。代理使用准则来帮助工程师规划工作。一个代理根据准则要求审查每个合并请求。另一个代理在实现开始前审查技术设计。第三个代理审查事件报告。在过去的四个月里，这些代理标记了近 25 万个潜在问题，并阻止了 16,000 次合并。在编写一行代码之前，它们就在近 600 个设计中发现了架构问题。你可以在 Timo 关于 AI 代码审查的博客文章中阅读更多关于我们如何构建这个代码审查工作流的细节。我们现在正将重点转向为工程师提供工具，以定义评估其代理产出的循环。
**为所有人提供魔法邮箱别名** 我们早期犯的一个错误是，给工程部门以外的所有人提供了相同的工具，只是用户界面稍微友好一些。工程师可以将代码仓库克隆到笔记本电脑上，添加一个像 AGENTS.md 这样的上下文文件，然后将他们的工具框架指向工作。然而，市场上的工具框架并不能很好地映射到其他类型的知识工作，在这些工作中，用户创建一次性的输出，并处理涉及数十个记录系统的项目。如果你给每个人一个非常擅长编写代码的工具框架工作区，你最终会得到比你需要的多得多的代码。结果就是大量“氛围编码”应用泛滥，它们到处寻找要解决的问题。所以我们倒推。我们告诉 Cloudflare 的每个人，他们可以把不想做的工作发送给一个“魔法 AI 邮件机器人”，它会回复他们需要的输出。在这个背后……