Cloudflare hozzáadta a Web Search API bétaverzióját az AI Gateway-hez, így az ügynökök és az AI-alkalmazások lehetőséget adnak arra, hogy élő internetes keresést végezzenek ugyanazon az átjárórétegen keresztül, amelyet a modellforgalomhoz használtak. A funkció új, szűk felületű és még béta állapotban van, de nagyobb elmozdulásra utal: a keresés számlázható mesterségesintelligencia-eszközzé válik, nem csupán alkalmazásoldali integrációvá.
A vállalat 2026. október 2-án jelentette be a béta verziót. Induláskor a Cloudflare a Ceramic.ai-t, az Exa-t és a Linkupot felsorolja a választható keresőszolgáltatók között. A fejlesztők keresési kérelmeket küldhetnek az AI Gateway-en keresztül, megjeleníthetik ezeket az átjárónaplókban, és az AI Gateway-jóváírásokon keresztül fizethetnek értük az egyes szolgáltatók feltüntetett API-os áron. A Cloudflare azt mondja, hogy nem ad hozzá további jelölést. A csapatok használhatják a saját kulcsú szolgáltatói hitelesítési adatokat is, ahol ez támogatott.
Ez a kombináció azért fontos, mert három olyan problémát egyesít, amelyeket gyakran külön kezelnek: az eszközök útválasztását, a megfigyelhetőséget és a számlázást. A visszakereséssel kiegészített ügynököket, kutatási asszisztenseket, támogató robotokat vagy automatizált értékesítési munkafolyamatokat építő fejlesztők számára már nem csak az a kérdés, hogy melyik modell generálta a választ. Azt is, hogy melyik keresési szolgáltatót hívták meg, kinek a hitelesítési adataival, milyen áron, és hogy az ebből eredő ráfordítás köthető-e ügyfélhez, csapathoz, projekthez vagy API kulcshoz.
Mi változott
A közelmúltig sok mesterséges intelligencia-átjáró megbeszélés középpontjában a modellhívások álltak: OpenAI-kompatibilis végpontok, szolgáltatói feladatátvétel, token elszámolás, késleltetés, gyorsítótárazás és kérésnaplók. A Cloudflare Web Search API bétaverziója más típusú tranzakciókat ad ehhez a vezérlősíkhoz. A keresési hívás támogathat egy modellválaszt, de önmagában nem modellkövetkeztetési kérés. Különböző árazásokkal, más szolgáltatói szemantikával és más irányítási kérdésekkel rendelkezik.
A Cloudflare elindítása a keresőszolgáltatót konfigurálható átjáróvá teszi, nem pedig kódolt alkalmazásfüggőséggé. A fejlesztők választhatnak a felsorolt szolgáltatók közül, átirányíthatják a hívást az AI Gateway-en keresztül, és más AI-forgalom mellett láthatják. Ha az ügyfél Cloudflare által felügyelt számlázást használ, a terhelés az AI Gateway jóváírásaira vonatkozik. Ha az ügyfél szolgáltatói kulcsot hoz, az átjáró továbbra is az útválasztás és a naplózás útvonalában maradhat.
Ez egy értelmes termékhatár. A keresés többé nem láthatatlan segítő, amely egy ügynöki keretrendszer mögé rejtőzik. Első osztályú esemény lesz az átjáró nyilvántartásában. A többmodell API csapatok számára készült átjárónál ez a különbség „az ügynök drága volt” és „ez a munkafolyamat pénzt költött modelltokenekre, gyorsítótárazott kontextusra és hat élő keresési hívásra” között.
Miért kell foglalkozniuk az átjárócsapatokkal
A közvetlen közönség a Cloudflare AI Gateway-t már használó fejlesztők, különösen azok az alkalmazások, amelyeknek friss információkra van szükségük. A keresés segítheti az élő adatok válaszait, de egy másik költségegységet és egy másik szolgáltató-függőségi forrást is bevezet. Ha egy ügyfélszolgálati ügynök a dokumentációban keres, a megfelelőségi asszisztens ellenőrzi az aktuális szabályzat oldalait, vagy egy piacfigyelő munkafolyamat ismételten átvizsgálja az internetet, a keresési díjak működési szempontból fontossá válhatnak még akkor is, ha a tokenhasználat szerénynek tűnik.
Ez ugyanaz a minta, amely most az ügynöki infrastruktúrában jelenik meg. A hosztolt shell-eszközök, a böngészőhasználat, a kódellenőrző ügynökök és a visszakereső szolgáltatások mind mérsékelt műveletekké alakulnak a modell körül. A tokenek továbbra is számítanak, de már nem jelentik a teljes főkönyvet. Egy használható átjárónak meg kell magyaráznia a teljes munkafolyamat költését, nem csak a végső befejezést.
Vállalkozások esetében ez a visszaterhelést és az árrést érinti. Előfordulhat, hogy a viszonteladónak vagy a belső platformcsapatnak el kell döntenie, hogy a keresési ráfordítást a szolgáltatói listaáron továbbítják, megjelölik, csomagba foglalják vagy alapértelmezés szerint blokkolják. Egy pénzügyi csapatnak tudnia kell, hogy az ügyfél számlája növekedett-e a nagyobb promptok, több kimeneti token, a gyorsítótár viselkedése vagy a webes keresés mennyisége miatt. Előfordulhat, hogy a termékcsapatok olyan használati jelentéseket szeretnének, amelyek megkülönböztetik a háttérben történő gazdagítást a felhasználó által látható generálástól.
Ez gyakorlati lehetőséget teremt az erősebb egységes AI API számlázáshoz. A számlázási modellnek le kell fednie a tokeneket, a gyorsítótárazott tokeneket és az eszközhívásokat anélkül, hogy azokat egyetlen homályos „AI használat” sorba rendezné. Ellenkező esetben az ügyfelek nem tudják megmondani, hogy az ügynöki rendszer melyik része okozza a költségeket.
A fejlesztői következmények
A fejlesztőknek az internetes keresést az alkalmazás API dizájnjának részeként kell kezelniük, nem csak azonnali fejlesztésként. A keresési szolgáltatónak láthatónak kell lennie a konfigurációban. A hitelesítő adatok hatókörét kell meghatározni. A naplóknak elegendő információt kell megőrizniük a szolgáltatói viselkedés és az ügyfelek költésének hibakereséséhez anélkül, hogy a szükségtelen érzékeny adatokat megőriznék. A hibakezelésnek meg kell különböztetnie a modellhibát a keresőszolgáltató hibájától, mivel a felhasználói élmény és az újrapróbálkozási stratégia eltérő lehet.
Van egy útválasztási kérdés is. A Ceramic.ai, az Exa és a Linkup nem cserélhető fel minden felhasználási esetben. A keresés minősége, a lefedettség, a várakozási idő, az eredmények formátuma és az árak egyaránt befolyásolhatják a modell későbbi viselkedését. A szolgáltatók között irányítani képes átjáró rugalmasságot biztosít a fejlesztőknek, de megköveteli a szabályzatot is: melyik szolgáltató melyik bérlő számára engedélyezett, mely régiók vagy adatosztályok engedélyezettek, és hogy bizonyos ügyfelek esetében szükség van-e BYOK hitelesítési adatokra.
AModel Gate és hasonló termékek esetében a gyakorlati kapcsolat közvetlen. Ha az ügyfelek az ügynöki szolgáltatásokat egy átjáró tetején építik ki, akkor végül kérni fogják, hogy a keresési használat megjelenjen a modellhasználat mellett ugyanazon az elemzési felületen. Előfordulhat, hogy a partner API-knak fel kell tenniük a keresési hívások rekordjait, hogy a downstream platformok pontosan számlázhassák saját ügyfeleiket. A keresés első osztályú számlázható eszközként való kezelése természetesen illeszkedne a APIkulcskezelés, a csapatvezérlés és a használati elemzések mellé.
Ez nem jelenti azt, hogy minden átjárónak át kell másolnia a Cloudflare pontos szolgáltatói listáját. A fontosabb pont strukturális: amint az élő keresés elérhető egy átjárón keresztül, a szerszámmérés az átjárószerződés részévé válik. A team AI API költségkontroll, amely figyelmen kívül hagyja az eszközhívásokat, alábecsüli a valódi ügynöki költségeket.
Ami még bizonytalan
A béta állapot több nyitott kérdést hagy maga után. A Cloudflare megnevezte a kezdeti keresési szolgáltatókat és leírta a számlázási megközelítést, de a termelési csapatoknak továbbra is értékelniük kell a szolgáltató-specifikus teljesítményt, az eredmények minőségét, az adatkezelési kötelezettségvállalásokat és a működési korlátokat. A nyilvános dokumentáció megerősíti a bétaverziót és az alapvető árképzési útvonalat, de nem dönti el, hogy egy szolgáltató jobb-e az összes munkaterheléshez, vagy hogyan fog fejlődni a funkció az általános elérhetőség előtt.
Az sem világos, hogy a fejlesztők milyen gyorsan szabványosítják az átjáró által közvetített keresést a közvetlen szolgáltatói integráció helyett. A meglévő visszakereső veremekkel rendelkező csapatok saját infrastruktúrájukon belül folytathatják a keresést. Mások előnyben részesíthetik az átjáró-útválasztást, mert csökkenti az integrációs munkát és központosítja a naplókat. A döntés valószínűleg az irányítási igényektől és a keresési relevanciától is függ.
Az irány ennek ellenére elég egyértelmű. Az AI-átjárók több ügynök-futási időt vesznek fel a modell körül. A Cloudflare Web Search API bétaverziója nem csupán egy keresési funkció; ez egy újabb jele annak, hogy az AI-alkalmazások vezérlősíkjának most olyan gondosan kell mérnie, irányítania és elmagyaráznia az eszközöket, mint ahogyan a modelleket kezeli.