Agenty AI ze stanem na brzegu sieci (edge): Cloudflare Durable Objects i Agents SDK kontra AgentCore, Vertex i Foundry

Jerzy Kopaczewski 12 listopada 2026 11 min czytania
Contents

Agenty AI ze stanem na brzegu sieci (edge): Cloudflare Durable Objects i Agents SDK kontra AgentCore, Vertex i Foundry

Porównania platform agentowych wielkiej trójki pomijają czwartą, inaczej zbudowaną opcję: Cloudflare uruchamia agentów ze stanem na brzegu sieci (ang. edge), czyli w rozproszonych węzłach blisko użytkownika, trzymając obliczenia i dane w jednym miejscu. Działa to na Durable Objects i Agents SDK. Poniżej wyjaśniamy, co ten model daje, a gdzie nie dorównuje AgentCore, Vertex ani Foundry. Bez ogłaszania zwycięzcy: to wybór architektury, nie ranking.

Gdy zestawialiśmy platformy agentowe AWS, Google i Microsoftu, wszystkie trzy okazały się wariacją tego samego pomysłu: zarządzany, izolowany runtime, do którego przynosisz swojego agenta. Cloudflare podchodzi do tego zupełnie inaczej, i właśnie te różnice nas najbardziej interesują. Zamiast hostować agenta w odległym regionie, uruchamia go na brzegu sieci (edge), czyli w węźle położonym blisko użytkownika, w obiekcie, który łączy obliczenia z własnym magazynem danych.

Zastanawiasz się, gdzie zbudować swoje agenty?

Umów bezpłatną rozmowę 30 min

 

Krótka odpowiedź

Cloudflare buduje agentów na Durable Objects: obiektach ze stanem, lokalnych na brzegu sieci, po jednej instancji na rozmowę czy encję. Wielka trójka oferuje zarządzane runtime z głębszymi katalogami modeli i mocniejszym compute. Wybór sprowadza się do tego, co jest dla Ciebie ważniejsze: lokalność stanu i niskie opóźnienia, czy katalog modeli i moc obliczeniowa na dłuższe, cięższe zadania.

 

Czym właściwie są Durable Objects

To sedno całego modelu. Durable Object to szczególny rodzaj funkcji Cloudflare Workers, który łączy obliczenia z własnym magazynem danych: każda instancja ma swoją bazę SQLite, jest jednowątkowa i adresowalna globalnie po unikalnym identyfikatorze. Uruchamia się blisko miejsca, z którego pada pierwsze żądanie, i usypia, gdy nie jest używana. Takich instancji możesz mieć miliony, po jednej na rozmowę, użytkownika czy dokument.

To jest ta różnica, której wielka trójka nie ma w czystej postaci: stan nie leży w osobnej bazie, do której agent sięga po sieci, tylko tuż obok kodu, w tej samej instancji. Stąd zdanie, które wszystko łączy: agent na Cloudflare działa wewnątrz Durable Object. Od niedawna Durable Objects są dostępne w darmowym planie Workers, więc możesz ich używać bez dodatkowych zobowiązań.

 

Stos agentowy Cloudflare w jednym przejściu

  • Agents SDK buduje agentów ze stanem na Durable Objects: wbudowana pamięć, harmonogramowanie zadań, połączenia WebSocket, obsługa poczty, klient i serwer MCP oraz narzędzia. Dostajesz zarządzanie stanem i komunikację w czasie rzeczywistym bez budowania tego od zera.
  • Workers AI to inferencja na brzegu sieci, na kartach GPU, rozliczana w jednostkach zwanych Neuronami (0,011 USD za 1000; każde konto, darmowe i płatne, dostaje 10 000 Neuronów dziennie za darmo). Uruchamia też duże modele, a AI Gateway pozwala ujednolicić rozliczenia między Workers AI a dostawcami zewnętrznymi. Część modeli wymaga planu Workers Paid (od 5 USD miesięcznie).

To wystarcza, by zbudować agenta end-to-end bez wychodzenia poza Cloudflare, choć w praktyce wiele projektów łączy sieć brzegową Cloudflare z modelami hostowanymi gdzie indziej.

 

Kontrast architektoniczny

Najkrótsze ujęcie różnicy: Cloudflare stawia na compute ze stanem, zlokalizowany przy danych na brzegu sieci; wielka trójka na zarządzany runtime z głębokim katalogiem modeli i grawitacją własnego ekosystemu danych.

WymiarCloudflare (Durable Objects + Agents SDK)Wielka trójka (AgentCore / Vertex / Foundry)
Model stanuStan przy obliczeniach, jedna instancja na encjęStan zwykle w osobnej usłudze pamięci
LokalizacjaSieć brzegowa (edge), blisko użytkownikaWybrany region chmury
Czas startuBliski zera, bez rozruchu konteneraZależny od runtime; skalowanie do zera na AWS i Azure
Katalog modeliWęższy (Workers AI + zewnętrzni przez AI Gateway)Szeroki (Bedrock / Vertex Model Garden / Foundry Models)
Długie, ciężkie zadaniaLimity czasu CPU (do 5 min na wywołanie, domyślnie 30 s)Dłuższe przebiegi i GPU do treningu
JęzykiJavaScript/TypeScript/WASMRównież Python i inne stosy natywnie
Ekosystem danychSamodzielna sieć brzegowaGłęboka grawitacja danych w macierzystej chmurze

UWAGA: Stan na listopad 2026; ta dziedzina zmienia się z miesiąca na miesiąc, więc stawki i limity zweryfikuj przed decyzją.

 

Gdzie model Cloudflare wygrywa

  • Agenci w czasie rzeczywistym i współpraca - czat, współedycja, powiadomienia na żywo, gdzie liczy się stan per sesja i niskie opóźnienie.
  • Stan per rozmowa - jedna adresowalna instancja na użytkownika czy wątek, bez budowania własnej warstwy koordynacji.
  • Wywoływanie narzędzi wrażliwe na opóźnienia, gdy agent często sięga po stan i narzędzia.
  • Globalny zasięg z niskim czasem startu, gdy użytkownicy są rozproszeni po świecie.
  • Tani, bezzobowiązaniowy start dzięki darmowym Durable Objects i 10 000 Neuronów dziennie.

 

Gdzie wielka trójka nadal wygrywa

  • Szeroki katalog modeli zarządzanych i dostęp do najnowszych modeli przez Bedrock, Vertex czy Foundry.
  • Ciężkie, długie obliczenia i GPU do treningu, czego sieć brzegowa nie obsłuży.
  • Stosy agentowe w Pythonie i innych językach hostowane natywnie, a nie tylko JavaScript/TypeScript.
  • Głęboka grawitacja danych - gdy dane i obliczenia siedzą w jednej chmurze razem z usługami analitycznymi.
  • Tożsamość, obserwowalność i zgodność klasy korporacyjnej o szerokim zakresie.

 

Czego to porównanie nie rozstrzyga

Tak jak w porównaniu wielkiej trójki, najdroższą pozycją przy realnym ruchu jest zwykle inferencja modelu, a to wybór modelu, nie platformy. Lokalność stanu, opóźnienia i czas startu to realne różnice architektoniczne, ale samego rachunku za agenta nie zdominują one tak jak koszt tokenów. Poza tym koszt przeniesienia między modelami i platformami jest prawdziwy. To wybór architektury pod konkretne obciążenie, a nie tabela z werdyktem.

 

Jak Devopsity podchodzi do tego wyboru

Zaczynamy od Twojego obciążenia, nie od dostawcy. Jeśli agent jest interaktywny, wrażliwy na opóźnienia i mocno zależny od stanu per sesja, model brzegowy Cloudflare bywa naturalnym dopasowaniem. Jeśli potrzebujesz szerokiego katalogu modeli, ciężkiego compute albo jesteś już osadzony głęboko w jednej z wielkich chmur, lepiej pasuje zarządzany runtime wielkiej trójki. Często najlepsze jest połączenie: brzeg Cloudflare jako front, model hostowany w chmurze jako zaplecze. Pomagamy wybrać architekturę i policzyć koszt w obu modelach rozliczeń, w ramach naszej praktyki FinOps i optymalizacji kosztów oraz nadzoru nad agentami AI.

Jerzy Kopaczewski

Wybierasz, gdzie zbudować agenty AI?

Umów bezpłatną 30-minutową rozmowę. Dopasujemy architekturę do Twojego obciążenia i policzymy koszt w sieci brzegowej Cloudflare oraz na platformie wielkiej trójki, bez faworyzowania dostawcy.

Umów rozmowę

 

Najczęściej zadawane pytania

Czy na Cloudflare można budować agentów AI?

Tak. Agents SDK buduje agentów ze stanem na Durable Objects, z wbudowaną pamięcią, harmonogramowaniem zadań, połączeniami WebSocket, obsługą poczty, klientem i serwerem MCP oraz narzędziami. Inferencję zapewnia Workers AI, czyli modele uruchamiane na brzegu sieci (edge). Całego agenta da się zbudować bez wychodzenia poza Cloudflare, choć w praktyce wiele projektów łączy sieć brzegową Cloudflare z modelami hostowanymi u innego dostawcy.

Czym jest Durable Object?

Durable Object to szczególny rodzaj funkcji Cloudflare Workers, który łączy obliczenia z własnym magazynem danych. Każda instancja ma swoją bazę SQLite, jest jednowątkowa i adresowalna globalnie po unikalnym identyfikatorze, uruchamia się blisko pierwszego żądania i usypia w bezczynności. Takich instancji możesz mieć miliony, po jednej na rozmowę czy encję. To właśnie na Durable Objects działają agenci budowani z Agents SDK, a od niedawna są dostępne w darmowym planie Workers.

Czym Cloudflare różni się od AWS Bedrock AgentCore?

Cloudflare uruchamia agentów ze stanem na brzegu sieci, trzymając obliczenia i dane w jednej instancji blisko użytkownika. AWS Bedrock AgentCore to zarządzany, izolowany runtime w wybranym regionie, z szerokim katalogiem modeli i głęboką integracją z danymi w AWS. Wybór sprowadza się do tego, co ważniejsze: lokalność stanu i niskie opóźnienia (Cloudflare) czy katalog modeli i moc obliczeniowa na dłuższe zadania (AgentCore). To różnica architektury, nie prosty ranking.

Jak rozliczane jest Workers AI?

Workers AI rozlicza się w Neuronach, czyli jednostkach pracy GPU: 0,011 USD za 1000 Neuronów, przy czym każde konto, darmowe i płatne, dostaje 10 000 Neuronów dziennie za darmo. Część modeli wymaga planu Workers Paid (od 5 USD miesięcznie). AI Gateway pozwala ujednolicić rozliczenia między Workers AI a modelami zewnętrznych dostawców. Stawki zweryfikuj przed budżetowaniem, bo ta dziedzina zmienia się szybko.

Kiedy NIE używać Cloudflare do agentów?

Gdy potrzebujesz ciężkich lub długich obliczeń albo GPU do treningu, gdy budujesz agenta w Pythonie lub innym stosie hostowanym natywnie na wielkiej trójce, gdy liczy się szeroki katalog modeli zarządzanych, głęboka integracja z danymi w jednej chmurze albo szeroki zakres zgodności klasy korporacyjnej. W tych przypadkach AgentCore, Vertex lub Foundry pasują lepiej. Limity czasu CPU Workers (do 5 minut na wywołanie) też wykluczają najdłuższe kroki agenta.

Czy to zamiennik platform agentowych AWS, Azure i GCP?

Nie. To inny model architektoniczny i często raczej uzupełnienie niż zamiennik. Wiele projektów łączy sieć brzegową Cloudflare jako front (stan per sesja, niskie opóźnienia, komunikacja w czasie rzeczywistym) z modelem hostowanym w wielkiej trójce jako zaplecze (szeroki katalog, ciężkie compute). Wybór nie polega na wskazaniu zwycięzcy, lecz na dopasowaniu modelu do konkretnego obciążenia.

Cloudflare Durable Objects agenci AI Workers AI edge computing platform engineering