Apify zpřístupnilo Server Actors, které odpovídají bez nového spuštění

Apify podle oznámení z 10. listopadu 2026 zpřístupnilo Server Actors ve všeobecné dostupnosti. Aplikace nebo AI agent mohou poslat další požadavek připravenému běhu a dostat odpověď bez zakládání nové úlohy pro každou interakci. Jde o nový způsob používání Actors vedle dosavadního zpracování samostatných úloh.

Techstrong AI popisuje novinku představenou na konferenci Run jako službu pro interaktivní pracovní postupy; uvádí také více než 267 milionů spuštění Actors týdně v říjnu a přes 100 tisíc nástrojů v katalogu Apify. Pro vývojáře je podstatné, kdy další krok agenta čeká na okamžitou odpověď a kdy může sběr dat doběhnout samostatně.

Jak se serverové rozhraní liší od běžného běhu

Běžný Actor přijme vstup, spustí úlohu, provede práci a skončí. Hodí se tak pro rozsáhlejší procházení webu nebo zpracování dat, jehož výsledek aplikace převezme po dokončení. Server Actor má navíc serverové rozhraní: přijímá HTTP požadavky na své adrese a vrací na ně odpovědi podobně jako webové API.

Dokumentace Apify vysvětluje, že platforma směruje požadavky na běžící HTTP server a podle příchozí zátěže jeho běhy spouští nebo zastavuje. Když běh po nastavené době nečinnosti skončí, další požadavek může čekat na nový start. Odpověď bez nového spuštění tedy platí pro opakované volání již připraveného běhu, nikoli pro každé volání za všech okolností.

Obě rozhraní mohou patřit stejnému Actoru. Vývojář tak nemusí převádět dlouhý sběr dat na sérii krátkých dotazů jen proto, aby mohl nabídnout rychlé odpovědi agentovi. Serverové rozhraní řeší způsob doručení požadavku a odpovědi; samo nezkracuje čas, který nástroj potřebuje k načtení zdrojové stránky nebo ke zpracování získaných dat.

Kdy rozhoduje rychlá odpověď

Server Actor dává smysl tam, kde další krok aplikace závisí na výsledku právě odeslaného dotazu. Může jít o vyhledání údaje k jedné stránce během práce agenta nebo o opakované dotazy v interaktivní aplikaci. Pokud by každý takový krok zakládal samostatný běh, čekání na start by se v celém postupu sčítalo.

U pravidelného monitoringu záleží na podobě úlohy. Podmíněný příklad: agent při vyhodnocování změny požádá o aktuální údaj z konkrétní veřejné stránky a podle odpovědi pokračuje; zde se serverové rozhraní hodí. Pokud má naproti tomu každou noc projít mnoho stránek a uložit souhrnnou datovou sadu, může práci převzít běžný běh bez čekajícího uživatele.

Podobný rozdíl platí při získávání údajů o firmách. Jednotlivý dotaz, jehož výsledek asistent hned použije v odpovědi, odpovídá serverovému režimu. Sestavení úplného přehledu z velkého počtu zdrojů odpovídá spíše dávkové úloze. Rozhodující není označení nástroje jako AI, ale to, zda volající potřebuje jednotlivou odpověď během probíhající interakce, nebo hotový výstup po dokončení celé práce.

Od vytvoření Actoru k požadavku agenta

Vývojář může vytvořit Server Actor ze šablony nebo zapnout serverové rozhraní u existujícího Actoru. V programu připraví HTTP server a endpointy, které přijmou požadavek a vrátí odpověď. Popis endpointů může zpřístupnit v nastavení Actoru, aby bylo zřejmé, jaké vstupy rozhraní očekává a jaký výsledek poskytne.

Po nasazení má serverové rozhraní adresu, která zůstává stejná i při výměně jednotlivých běhů. Aplikace na ni posílá ověřené požadavky s tokenem Apify. Pokud Actor poskytuje také endpoint pro Model Context Protocol, může touto cestou zpřístupnit své funkce agentovi; samotné zapnutí serverového rozhraní však ještě neurčuje, jaké nástroje bude agent umět volat.

Vývojář nastavuje také počet souběžných požadavků na běh, přidělenou paměť a dobu nečinnosti před zastavením. Delší pohotovost může zkrátit čekání na další dotaz, ale běžící služba dál spotřebovává prostředky. Při vyšší zátěži může platforma založit další běh, takže ani připravená služba neznamená, že všechny požadavky vždy obslouží jediný proces.

Co určuje provoz opakovaných požadavků

Server Actor může obsluhovat více uživatelů ze sdílených běhů v účtu svého tvůrce, nebo mít pro každého uživatele oddělený běh v jeho účtu. První uspořádání odpovídá mnoha krátkým požadavkům se společnou infrastrukturou. Druhé je vhodnější, když práce vyžaduje vlastní přístupové údaje, přihlášenou relaci nebo stav patřící konkrétnímu uživateli.

Rozdíl se promítá i do nákladů a zacházení s daty. U sdíleného běhu musí tvůrce oddělit údaje různých uživatelů ve své aplikaci; u oddělených běhů nese každý uživatel provoz vlastního běhu. Volba proto souvisí s povahou požadavků stejně jako s požadovanou odezvou. Pro dlouhé úlohy zůstává vstupní rozhraní dostupné i u Actoru, který umí současně odpovídat na serverové požadavky.

Pro AI agenta je největší změnou možnost vložit krátké získání webových dat přímo mezi další kroky práce. Výsledek jednoho dotazu může použít hned, zatímco rozsáhlý sběr nechá běžet samostatně. Hranice mezi oběma režimy vede v okamžiku, kdy aplikace potřebuje odpověď: během interakce, nebo až po dokončení celé úlohy.

Přečtěte si také:

• Jak vydělávat na Apify Actors a neprodělat na běhu nástroje
• Zapier, nebo Power Automate: účet mění počet tvůrců, ne jen počet spuštění
• AI gramotnost bez certifikátu: české firmě stačí průkazná evidence