Agents Week 启动
原文:Welcome to Agents Week / 2026-04-12 Source: https://blog.cloudflare.com/welcome-to-agents-week/
Cloudflare 的使命一直是帮助构建一个更好的互联网。有时这意味着面向当下的互联网构建,有时意味着面向即将到来的互联网构建。
今天,我们正式启动 Agents Week,致力于为下一代互联网构建。
互联网不是为 AI 时代而生,云也不是
我们今天所知的云,是上一次大型技术范式迁移——智能手机时代——的产物。
智能手机把互联网装进了每个人的口袋,它们不只是增加了用户,而是改变了“在线“这件事的本质。永远在线,永远期待即时响应。应用必须能处理数量级更多的用户,支撑它们的基础设施也必须随之演化。
业界最终收敛到一种简单直接的方案:用户更多,就部署更多份应用副本。随着应用复杂度上升,团队把它们拆分为更小的部分——微服务——这样每个团队都能掌握自己的命运。但核心原则没变:数量有限的应用,每个服务大量用户。规模化等于更多副本。
Kubernetes 和容器成了默认选项。它们让起实例、做负载均衡、按需销毁变得简单。在这种“一对多“模型下,单个实例可以服务大量用户;即使用户数增长到几十亿,你需要管理的对象数量仍然是有限的。
智能体(Agent)打破了这一切。
一个用户、一个 agent、一个任务
不像之前的所有应用,agent 是一对一的。每个 agent 都是一个独特的实例,服务一个用户,运行一个任务。传统应用无论谁在使用都遵循相同的执行路径,而 agent 需要它自己的执行环境:在这个环境里,LLM 决定代码路径,动态调用工具,调整策略,并坚持到任务完成。
把它想成餐厅和私人厨师的区别。餐厅有菜单——固定的选项集——以及为大批量出菜优化过的厨房。今天大多数应用都是这样。而 agent 更像一位私人厨师,他会问:你想吃什么?他每次可能需要完全不同的食材、器具或技法。你不可能用经营一家餐厅的厨房布置来开私厨服务。
过去一年里,我们看到 agent 起飞,coding agent 走在最前面——这并不意外,因为开发者往往是早期采用者。今天大多数 coding agent 的工作方式,是开一个容器,给 LLM 提供它需要的东西:文件系统、git、bash,以及运行任意二进制的能力。
但 coding agent 只是开始。像 Claude Cowork 这样的工具,已经把 agent 带给了非技术用户。一旦 agent 走出开发者圈,进入每个人的手中——行政助理、研究分析师、客服代表、生活规划师——规模化的算式很快就让人清醒。
把 agent 推向大众的算式
如果美国超过 1 亿知识工作者每人都使用一个 agent 助手,即便并发率只有 ~15%,你也需要支撑约 2400 万个并发会话的容量。按 25–50 用户/CPU 计,这意味着 50 万到 100 万个服务器 CPU——而且只是美国,每人只有一个 agent。
现在再设想每个人并发跑好几个 agent。再想想全世界其他地方还有超过 10 亿知识工作者。我们不是缺一点点算力,是差了好几个数量级。
那要怎么补上这个缺口?
为 agent 而生的基础设施
八年前,我们发布了 Workers——这是我们开发者平台的开端,也是对无容器、无服务器(serverless)计算的押注。当时的动机很现实:我们需要一种没有冷启动的轻量计算,服务那些依赖 Cloudflare 提速的客户。基于 V8 isolates 而非容器构建的 Workers,被证明高出一个数量级的效率——启动更快、运行更便宜,而且天生适合“启动、执行、销毁“的模式。
我们当时没有预料到的是,这个模型会和 agent 时代如此契合。
容器给每个 agent 一整间商业厨房:固定的电器、步入式冷库,无论 agent 是否需要;而 isolates 则给私人厨师恰好够用的台面、灶头和这一道菜需要的那把刀。毫秒级启动,菜上桌的瞬间清理完毕。
在一个不需要支撑成千上万个长期运行应用、而是需要支撑数十亿个短暂、单一目的执行环境的世界里,isolates 就是正确的原语。
每个都在毫秒内启动。每个都在安全沙箱中。在同样的硬件上,你能跑的数量比容器多出几个数量级。
就在几周前,我们用 Dynamic Workers 公测 把这个理念又推进了一步:在运行时按需拉起的执行环境。一个 isolate 几毫秒启动,占用几兆内存。这大约比一个容器快 100 倍,内存效率高出 100 倍。
你可以为每一个请求都新起一个 isolate,跑一段代码片段,然后扔掉——规模可达每秒数百万次。
要让 agent 走出早期采用者、进入每个人的手中,它们也必须负担得起。今天每个 agent 都跑在自己的容器里,这种成本之高,使得 agent 工具基本只面向工程师的编码助手——只有他们才能为这个成本买单。Isolates 通过高出几个数量级的运行效率,让 agent 在所需规模下的单位经济性变得可行。
无马马车阶段
虽然为未来打好正确的地基至关重要,但我们还没到那一步。每一次范式迁移,都有一段我们试图把新东西塞进旧模型的时期。最早的汽车被叫做“无马马车“。最早的网站是数字版的宣传册。最早的手机应用是缩小版的桌面 UI。今天我们在 agent 上正处于这个阶段。
到处都看得到。
我们给 agent 配上无头浏览器,让它们去浏览为人眼设计的网站,而它们真正需要的是 MCP 这类结构化协议,可以直接发现并调用服务。
很多早期的 MCP server 不过是在已有 REST API 外面包了层薄壳——一样的 CRUD 操作,新的协议——而 LLM 实际上更擅长写代码,而不是做一连串顺序工具调用。
我们用 CAPTCHA 和行为指纹去验证请求另一端的对象,而那个对象越来越多地是一个代表某人行事的 agent——正确的问题不是“你是人吗?“,而是“你是哪个 agent、谁授权了你、你被允许做什么?”
我们为只需要发几个 API 调用并返回结果的 agent 拉起整套容器。
这只是一些例子,但都不令人意外。这就是过渡期的样子。
双线并进
互联网总是处在两个时代之间。IPv6 客观上比 IPv4 更好,但放弃 IPv4 支持会搞挂半个互联网。HTTP/2 和 HTTP/3 共存。TLS 1.2 还没完全让位给 1.3。更好的技术存在,旧的技术持续,基础设施的工作就是连接两者。
Cloudflare 一直在做衔接这些过渡的生意。向 agent 的迁移也不例外。
Coding agent 真的需要容器——文件系统、git、bash、任意二进制执行。这不会消失。这一周,我们的容器化沙箱环境正式 GA,因为我们承诺把它们做到最好。我们也在浏览器渲染上为 agent 走得更深,因为有大量服务还不会说 MCP,agent 仍然需要和它们交互。这些不是权宜之计——它们是完整平台的一部分。
但我们也在构建下一阶段:agent 真正需要的 isolates、协议和身份模型。我们的工作是确保你不必在“今天能用“和“明天对的“之间做选择。
安全在模型之内,而非围在外面
如果 agent 要处理我们的工作和个人事务——读邮件、操作代码、和金融服务交互——那安全性必须内建在执行模型里,而不是事后加一层。
CISO 是最早面对这件事的群体。把 agent 交到每个人手里带来的生产力红利是真实的,但今天大多数 agent 部署都充满风险:prompt 注入、数据外泄、未授权 API 访问、不透明的工具使用。
开发者的 vibe-coding agent 需要访问代码仓库和部署流水线。企业的客服 agent 需要访问内部 API 和用户数据。这两种情形下,今天保护这些环境意味着拼凑一堆从来不是为自治软件设计的凭据、网络策略和访问控制。
Cloudflare 一直在并行构建两个平台:面向开发者的 developer platform,和面向需要保护访问的组织的 zero trust platform。一段时间里,它们服务不同的受众。
但“我怎么构建这个 agent?“和“我怎么确保它安全?“越来越是同一个问题。我们正在把这两个平台合到一起,使所有这些都成为 agent 运行时的原生能力,而不是另一层附加物。
守规矩的 agent
agent 时代还有一个超越计算和安全的维度:经济与治理。
当 agent 代表我们与互联网交互——读文章、消费 API、访问服务——必须有一种方式让创造内容、运营服务的人和组织设定条款、获得报酬。今天,网络的经济模型构建在人的注意力之上:广告、付费墙、订阅。
agent 没有注意力(嗯,不是那种 attention)。它们看不到广告。它们不点击 cookie 横幅。
如果我们想要一个让 agent 自由运转 并且 让出版商、内容创作者、服务提供方得到公平回报的互联网,我们就需要为它新建基础设施。我们正在打造工具,让出版商和内容所有者能够轻松设定并执行 agent 与他们内容交互的策略。
构建更好的互联网,一直意味着确保它对所有人都管用——不只对构建技术的人,也对其工作和创意让互联网值得使用的人。在 agent 时代,这一点不变,反而更重要。
面向开发者和 agent 的平台
我们对 developer platform 的愿景一直是:提供一个一站式、好用的平台——从实验、到 MVP、再到扩展到数百万用户。但提供原语只是其中一部分。一个伟大的平台还要思考所有部件如何配合,以及它如何融入你的开发流程。
这件事正在演化。它过去纯粹关乎开发者体验,让人类能轻松构建、测试、发布。如今它越来越多地也关乎让 agent 帮助人类,让平台不仅服务于构建 agent 的人,也服务于 agent 自己。agent 能找到最新最好的实践吗?能多容易地发现并调用所需的工具和 CLI?能多无缝地从写代码过渡到部署?
这一周,我们在两个维度都发布改进——让 Cloudflare 对在它上面构建的人类更好,也对在它上面运行的 agent 更好。
为未来构建是一项团队运动
为未来构建,我们没法独自完成。每一次重大的互联网过渡——从 HTTP/1.1 到 HTTP/2、HTTP/3,从 TLS 1.2 到 1.3——都需要业界在共享标准上达成一致。向 agent 的迁移也不会例外。
Cloudflare 长期致力于推动让互联网运转的标准。我们 深度参与 IETF 已超过十年,帮助开发和部署了 QUIC、TLS 1.3、Encrypted Client Hello 等协议。我们是 WinterTC——ECMA 下属的 JavaScript 运行时互操作技术委员会——的创始成员。我们开源了 Workers runtime 本身,因为我们相信底座应该是开放的。
我们在 agentic 时代沿用同样的方式。我们很高兴成为 Linux Foundation 和 AAIF 的一员,并支持和推动像 MCP 这样将成为 agentic 未来基石的标准。自 Anthropic 推出 MCP 以来,我们与他们密切合作构建远程 MCP server 的基础设施,开源了我们的实现,并投入精力让协议在规模下切实可用。
去年,我们与 Coinbase 一起 共同创办了 x402 Foundation,这是一个开放、中立的标准,复活了长期闲置的 HTTP 402 状态码,让 agent 有一种原生的方式为消费的服务和内容付费。
Agent 身份、授权、支付、安全:这些都需要开放标准,任何一家公司都无法独自定义。
敬请关注
这一周,我们将在 agent 栈的每一个维度发布:计算、连接、安全、身份、经济和开发者体验。
互联网不是为 AI 而生,云也不是为 agent 而生。但 Cloudflare 一直致力于帮助构建更好的互联网——而“更好“的含义在每个时代都在变化。这是 agent 的时代。这一周,请追随我们,我们会展示我们在为它构建什么。
– 原文译于 2026-04-30