訂閱以接收新文章的通知:

歡迎來到 Agents Week

2026-04-12

閱讀時間:8 分鐘
本貼文還提供以下語言版本:EnglishFrançaisDeutschItaliano日本語한국어Español (Latinoamérica)Español简体中文

Cloudflare 的使命始終是協助建立更美好的網際網路。有時這意味著為現有的網際網路進行建置,有時則意味著為即將問世的網際網路進行預先佈局。

今天,我們正式展開 Agents Week,致力於為接下來的時代建構網際網路。

網際網路並非為 AI 時代而生,雲端運算也是如此。

眾所周知,雲端運算是上一個重大技術典範轉移下的產物:智慧型手機。

當智慧型手機將網際網路放進每個人的口袋時,它們不僅增加了使用者數量,更改變了「上線」的本質。人們隨時保持連線,隨時期待即時回應。應用程式必須處理數量級增長的使用者,而支撐它們的基礎架構也必須隨之演進。

業界最終得出的解決方案直截了當:更多使用者,那就製作更多應用程式副本。隨著應用程式變得越發複雜,團隊將其拆分為更小的部分——微服務,以便每個團隊都能掌控自己的命運。但核心原則保持不變:有限數量的應用程式,各自服務大量使用者。擴展意味著更多副本。

Kubernetes 和容器因此成為預設選項。它們讓啟動執行個體、負載平衡和銷毀變得容易。在這種「一對多」的模式下,單一執行個體可以服務許多使用者,即使使用者數量成長到數十億,需要管理的物件數量仍然是有限的。

智慧體打破了這一切。

一位使用者,一個智慧體,一項工作

與過去所有應用程式不同,智慧體是「一對一」的。每個智慧體都是一個獨特的執行個體,服務一位使用者,執行一項任務。傳統應用程式始終遵循相同的執行路徑,無論使用者是誰;而智慧體則需要自己的執行環境:一個由 LLM 決定程式路徑、動態呼叫工具、調整方法並持續運作直到任務完成的環境。

可以將其視為餐廳與私人主廚的差別。餐廳有一份菜單(提供一套固定的選項),以及一個經過最佳化、可大量產出餐點的廚房。如今大多數應用程式都是如此。智慧體則更像是一位私人主廚,他會問:您想吃什麼?他們每次可能需要完全不同的食材、器具或技術。您無法用經營餐廳的廚房配置來提供私人主廚服務。

過去一年,我們見證了智慧體的起飛,其中編碼代理領先群雄——這並不令人意外,因為開發人員往往是早期採用者。目前大多數編碼智慧體的運作方式,是透過啟動一個容器來提供 LLM 所需的一切:檔案系統、git、bash 以及執行任意二進位檔的能力。

但編碼智慧體只是個開始。像 Claude Cowork 這樣的工具已經讓技術水準較低的使用者也能使用智慧體。一旦智慧體不再局限於開發人員,而是普及到所有人——行政助理、研究分析師、客服代表、私人規劃師——那麼規模化的數學計算很快就會變得嚇人。

將智慧體推向大眾的規模化數學計算

如果美國超過 1 億的知識工作者,每人以大約 15% 的並發率使用一個自主式助理,您需要的容量大約是 2400 萬個同時連線工作階段。以每個 CPU 服務 25 到 50 個使用者來算,這大約需要 50 萬到 100 萬顆伺服器 CPU——這還只是美國、而且每人只使用一個智慧體的情況。

現在想像一下,每個人同時執行好幾個智慧體。再想像一下,全世界有超過 10 億的知識工作者。我們不是稍微欠缺運算資源,而是差了數個數量級。

那麼,我們如何彌補那個差距呢?

為智慧體建置的基礎架構

八年前,我們推出了 Workers,這是我們開發人員平台的起點,也是一場對「無容器、無伺服器運算」的押注。當時的動機很實際:我們需要沒有冷啟動問題的輕量級運算,來服務那些依賴 Cloudflare 來取得速度的客戶。Workers 建立在 V8 隔離區 (isolate) 而非容器之上,結果證明效率高出一個數量級——啟動更快、執行更便宜,並且原生支援「啟動、執行、銷毀」模式。

我們當時沒有預料到的是,這個模型竟然如此契合 AI 智慧體的時代。

容器為每個智慧體提供了一整間商業廚房:無論智慧體是否需要,都有固定式的大型電器、步入式冰箱等全套設備;反之,隔離區只給私人主廚這道特定料理所需的檯面、爐頭和刀具。幾毫秒內完成部署。菜上桌的同時就清理完畢。

BLOG-3238 2

在我們需要支援數十億個短暫的、單一用途的執行環境,而非數千個長時間執行的應用程式的時代,隔離區才是正确的基元。

每個隔離區都能在毫秒內啟動。每個隔離區都擁有安全的沙箱環境。而且,與容器相比,在相同的硬體上可以執行數量級更高的隔離區。

就在幾週前,我們更進一步推出了 Dynamic Workers 公開測試版:執行環境在執行階段按需啟動。一個隔離區啟動只需幾毫秒,僅使用幾 MB 記憶體。這比容器快了約 100 倍,記憶體效率也高出 100 倍。

您可以為每一個請求啟動一個新的隔離區,執行一小段程式碼,然後將其丟棄——每秒達數百萬次規模。

要讓智慧體走出早期採用者的圈子、進入每個人的手中,它們還必須負擔得起。在各自容器中執行每個智慧體的成本極高,導致當今的自主式工具大多僅限於工程師使用的編碼助理,因為只有他們能證明成本的合理性。隔離區的運作效率高出幾個數量級,使得在智慧體所需的規模下,單位成本變得可以接受。

BLOG-3238 3

無馬馬車階段

雖然為未來建立正確的基礎至關重要,但我們尚未達到目標。每一次典範轉移都會有一段時期,我們試圖讓新事物在舊模型中運作。第一輛汽車被稱為「無馬馬車」。第一批網站是數位宣傳手冊。第一批行動應用程式是縮小版的桌面 UI。我們現在正處於智慧體的這個階段。

這種現象隨處可見。

我們為智慧體提供無頭瀏覽器來瀏覽為人類設計的網站,而它們真正需要的是像 MCP 這樣的結構化通訊協定,以便直接發現和叫用服務。

許多早期的 MCP 伺服器只是對現有 REST API 的簡單封裝:同樣的 CRUD 操作,只是換了新通訊協定。而 LLM 實際上更擅長編寫程式碼,而不是進行順序工具呼叫。

我們使用 CAPTCHA 和行為指紋來驗證請求另一端的是什麼,但現在越來越多情況下那是一個代表某人行事的智慧體——正確的問題不該是「你是人類嗎?」,而是「你是哪個智慧體?誰授權了你?你被允許做什麼?」

我們為那些只需要進行幾次 API 呼叫並傳回結果的智慧體啟動了完整的容器。

這些只是幾個範例,但這些都不令人意外。這就是過渡期的樣貌。

為兩者而建

網際網路總是處於兩個時代之間。客觀來說 IPv6 比 IPv4 好,但放棄 IPv4 支援會讓一半的網際網路無法運作。HTTP/2 和 HTTP/3 共存。TLS 1.2 仍未完全讓位給 1.3。更好的技術已經存在,舊的技術依然持續,基礎架構的工作就是扮演兩者之間的橋樑。

Cloudflare 一直以來都在做銜接這些過渡期的工作。轉向智慧體的時代也不例外。

編碼智慧體確實需要容器——檔案系統、git、bash、執行任意二進位檔的能力。這不會消失。本週,我們基於容器的沙箱環境將正式推出,因為我們致力於將其做到最好。我們正在深入研究面向智慧體的瀏覽器渲染,因為未來仍會有大量服務不支援 MCP,而智慧體仍需要與這些服務進行互動。這些並非權宜之計,而是完整平台的一部分。

但我們同時也在打造未來真正需要的東西:隔離區、通訊協定以及智慧體真正需要的身分識別模型。我們的職責是確保您不必在「當下適用的方案」和「面向未來的方案」之間做出選擇。

內建於模型中的安全,而非外掛的安全

如果智慧體要處理我們的職業和個人任務,如閱讀電子郵件、操作程式碼、與金融服務互動,那麼安全性必須內建於執行模型中,而不是事後才疊加上去。

CISO 是第一批直面這個問題的人。讓每個人都擁有智慧體所能帶來的生產力提升是真實存在的,但如今,大多數智慧體的部署充滿風險:提示詞插入攻擊、資料外流、未經授權的 API 存取、不透明的工具使用。

開發人員的 Vibe 編碼智慧體需要存取存放庫和部署管線。企業的客服智慧體需要存取內部 API 和使用者資料。在這兩種情況下,如今保護環境意味著要將認證、網路政策和存取控制整合在一起,而這些原本並非為自主軟體而設計。

Cloudflare 一直在平行建置兩個平台:一個是給建置應用程式的開發人員使用的開發人員平台,另一個是需要保護存取的組織使用的 Zero Trust 平台。有一段時間,這兩者服務於不同的受眾。

但「我該如何建置這個智慧體?」和「我該如何確保它是安全的?」這兩個問題正日益變成同一個問題。我們將這些平台結合起來,讓所有這些都成為智慧體執行的原生功能,而不是事後才加裝的獨立層。

遵守規則的智慧體

除了運算和安全性之外,智慧體時代還有另一個維度:經濟學和治理。

當智慧體代表我們與網際網路互動時(閱讀文章、使用 API、存取服務),必須有一種方式,讓創造那些內容與營運那些服務的個人和組織能夠制定條款並獲得報酬。現今網路的經濟模式是圍繞人類注意力建立的:廣告、付費牆、訂閱。

智慧體沒有注意力(好吧,沒有那種注意力)。它們不看廣告。它們不會點擊 cookie 橫幅。

如果我們想要一個智慧體可以自由運作,發布者、內容創作者和服務提供者能獲得公平補償的網際網路,我們需要為此建立新的基礎架構。我們正在建置工具,讓發布者和內容擁有者能輕鬆設定並強制執行智慧體與其內容互動的政策。

建立更好的網際網路始終意味著確保它對所有人都有利——不僅僅是那些打造技術的人,還有那些透過工作和創意讓網際網路值得使用的普通人。這在智慧體時代並未改變,反而變得更加重要。

為開發人員與智慧體而生的平台

我們對開發人員平台的願景始終是提供一個開箱即用的全面平台:從實驗、MVP 到擴展至數百萬使用者。但提供基元只是等式的一部分。一個好的平台還必須考慮一切如何協同工作,以及如何整合到您的開發流程中。

這項工作正在演進。過去它純粹關乎開發人員體驗,讓人類易於建置、測試和發布。現在,它越來越多地關乎幫助智慧體協助人類,並讓平台不僅對建立智慧體的人有效,對智慧體本身也有效。智慧體能找到最新、最正確的最佳做法嗎?它能多輕鬆地發現並叫用所需的工具和 CLI?它能多順暢地從寫程式碼轉移到部署?

本週,我們將發佈這兩個層面上的改進——讓 Cloudflare 對在其上建置的人類更好,也對在其上執行的智慧體更好。

為未來而建置時一項團隊活動

為未來而建置不是我們單打獨鬥就能完成的事。網際網路每一次重大轉變,從 HTTP/1.1 到 HTTP/2 和 HTTP/3,從 TLS 1.2 到 1.3,都需要業界匯聚於共同的標準。向智慧體的轉變也不例外。

Cloudflare 一直以來都積極參與並推動網際網路標準的製定和發展。十多年來,我們深入參與了 IETF 的工作,幫助開發和部署了 QUIC、TLS 1.3 和 Encrypted Client Hello 等通訊協定。我們也是 WinterTC(ECMA JavaScript 執行時期互通性技術委員會)的創始成員。我們開源了 Workers 執行時期本身,因為我們相信基礎架構應該開放。

我們將同樣的理念帶入智慧體時代。我們很高興能成為 Linux Foundation 和 AAIF 的一份子,並協助支援和推進 MCP 等標準的發展,這些標準將成為智慧體未來發展的基礎。自從 Anthropic 推出 MCP 以來,我們一直與他們緊密合作,建立遠端 MCP 伺服器的基礎架構,開源我們自己的實作,並致力於使該通訊協定能夠大規模地實際應用。

去年,我們與 Coinbase 共同創立了 x402 Foundation,這是一個開放、中立的標準,它復興了長期閒置的 HTTP 402 狀態碼,為智慧體提供了一種原生方式來為其所使用的服務和內容付費。

智慧體身分、授權、支付、安全性:這些都需要開放標準,沒有任何單一公司可以獨自定義。

敬請期待

本週,我們將發布一系列涵蓋智慧體技術堆疊各個方面的公告:運算、連線性、安全性、身分、經濟效益和開發人員體驗。

網際網路並非為 AI 而生。雲端運算也並非為智慧體而生。但 Cloudflare 的宗旨始終是協助建立一個更美好的網際網路——而「更美好」的定義會隨著每個時代而改變。這是智慧體的時代。本週,請持續關注,我們將展示我們為此建構的成果。

我們保護整個企業網路,協助客戶有效地建置網際網路規模的應用程式,加速任何網站或網際網路應用程式抵禦 DDoS 攻擊,阻止駭客入侵,並且可以協助您實現 Zero Trust

從任何裝置造訪 1.1.1.1,即可開始使用我們的免費應用程式,讓您的網際網路更快速、更安全。

若要進一步瞭解我們協助打造更好的網際網路的使命,請從這裡開始。如果您正在尋找新的職業方向,請查看我們的職缺
Agents Week代理程式Cloudflare WorkersWorkers AIAI開發人員平台開發人員無伺服器

在 X 上進行關注

Rita Kozlov|@ritakozlov_
Dane Knecht|@dok2001
Cloudflare|@cloudflare

相關貼文

2026年4月30日

Agents can now create Cloudflare accounts, buy domains, and deploy

Starting today, agents can now be Cloudflare customers. They can create a Cloudflare account, start a paid subscription, register a domain, and get back an API token to deploy code right away. Humans can be in the loop to grant permission, but there’s no need to go to the dashboard, copy and paste API tokens, or enter credit card details. ...

2026年4月22日

Making Rust Workers reliable: panic and abort recovery in wasm‑bindgen

Panics in Rust Workers were historically fatal, poisoning the entire instance. By collaborating upstream on the wasm‑bindgen project, Rust Workers now support resilient critical error recovery, including panic unwinding using WebAssembly Exception Handling....