Cloudflare добави бета версия на уеб търсене API към AI Gateway, като дава на агентите и AI приложенията начин да търсят в интернет на живо през същия слой на шлюза, който вече се използва за трафик на модели. Функцията е нова, с тясна повърхност и все още в бета версия, но сочи към по-голяма промяна: търсенето се превръща в платен AI инструмент, а не само в интеграция от страна на приложението.
Компанията обяви бета версията на 2 октомври 2026 г. При стартирането Cloudflare изброява Ceramic.ai, Exa и Linkup като избираеми доставчици на търсене. Разработчиците могат да изпращат заявки за търсене през AI Gateway, да показват тези заявки в регистрационните файлове на шлюза и да плащат за тях чрез кредити за AI Gateway на посочената API цена на всеки доставчик. Cloudflare казва, че не добавя допълнителна маркировка. Екипите могат също така да използват идентификационни данни на доставчик на донесете свой собствен ключ, където се поддържат.
Тази комбинация има значение, защото обединява три проблеми, които често се разглеждат отделно: маршрутизиране на инструмента, видимост и таксуване. За разработчиците, изграждащи агенти с разширени извличане, изследователски асистенти, ботове за поддръжка или автоматизирани работни процеси за продажби, въпросът вече не е само кой модел е генерирал отговора. Също така кой доставчик на търсене е извикан, под чии идентификационни данни, на каква цена и дали произтичащите разходи могат да бъдат обвързани с клиент, екип, проект или ключ API.
Какво се промени
Доскоро много дискусии за AI gateway се съсредоточаваха върху извикванията на модела: OpenAI-съвместими крайни точки, преход при срив на доставчика, отчитане на токени, латентност, кеширане и журнали на заявки. Уеб търсене API бета на Cloudflare добавя различен вид транзакция към тази контролна равнина. Повикването за търсене може да поддържа отговор на модела, но само по себе си не е заявка за извод на модел. Има различно ценообразуване, различна семантика на доставчика и различни въпроси относно управлението.
Стартирането на Cloudflare прави доставчика на търсене конфигурируем избор на шлюз, а не твърдо кодирана зависимост от приложение. Разработчиците могат да избират между изброените доставчици, да маршрутизират обаждането през AI Gateway и да го виждат заедно с друг AI трафик. Ако клиентът използва таксуване, управлявано от Cloudflare, таксата се начислява срещу кредити на AI Gateway. Ако клиентът донесе ключ на доставчика, шлюзът все още може да стои на пътя за маршрутизиране и регистриране.
Това е значима продуктова граница. Търсенето вече не е невидим помощник, скрит зад агентска рамка. Това се превръща в първокласно събитие в записите на портала. За мултимоделен API шлюз за екипи, това е разликата между „агентът беше скъп“ и „този работен процес изразходва пари за моделни токени, кеширан контекст и шест обаждания за търсене на живо.“
Защо екипите на портала трябва да се интересуват
Непосредствената аудитория са разработчици, които вече използват Cloudflare AI Gateway, особено тези, които създават приложения, които се нуждаят от свежа информация. Търсенето може да помогне за основаване на отговорите в живи данни, но също така въвежда друга единица цена и друг източник на зависимост от доставчика. Ако агент по поддръжката търси документация, асистент за съответствие проверява текущите страници с правила или работен процес за наблюдение на пазара сканира многократно мрежата, таксите за търсене могат да станат важни от оперативна гледна точка, дори когато използването на токени изглежда скромно.
Това е същият модел, който сега се появява в инфраструктурата на агента. Хостваните инструменти на обвивката, използването на браузъра, агентите за преглед на кода и услугите за извличане се превръщат в измервани операции около модела. Токените все още имат значение, но те вече не са цялата книга. Един използваем шлюз трябва да обяснява разходите за целия работен процес, а не само за крайното завършване.
За фирмите това се отразява на възстановяването на плащането и маржа. Може да се наложи дистрибутор или вътрешен екип на платформа да реши дали разходите за търсене се предават по каталожна цена на доставчика, маркирани, групирани в план или блокирани по подразбиране. Финансовият екип може да иска да знае дали фактурата на клиент се е увеличила поради по-големи подкани, повече изходни токени, поведение на кеша или обем на търсене в мрежата. Продуктовите екипи може да искат отчети за употребата, които разграничават фоновото обогатяване от видимото за потребителя генериране.
Това създава практична възможност за по-мощно унифицирано AI API таксуване. Моделът на таксуване трябва да покрива токени, кеширани токени и извиквания на инструменти, без да ги слива в един неясен ред „използване на AI“. В противен случай клиентите не могат да разберат коя част от агентската система води до разходи.
Последствията за разработчиците
Разработчиците ще трябва да третират търсенето в мрежата като част от API дизайна на приложението, а не само като незабавно подобрение. Доставчикът на търсене трябва да се вижда в конфигурацията. Идентификационните данни трябва да имат обхват. Дневниците трябва да съхраняват достатъчно информация за отстраняване на грешки в поведението на доставчика и разходите на клиентите, без да запазват ненужни чувствителни данни. Обработката на грешки трябва да разграничи грешката на модела от грешката на доставчика на търсене, тъй като потребителското изживяване и стратегията за повторен опит може да са различни.
Има и въпрос за маршрутизиране. Ceramic.ai, Exa и Linkup не са взаимозаменяеми във всеки случай на употреба. Качеството на търсенето, покритието, забавянето, форматът на резултатите и ценообразуването могат да повлияят на поведението на модела надолу по веригата. Шлюзът, който може да маршрутизира между доставчици, дава на разработчиците гъвкавост, но също така изисква политика: кой доставчик е одобрен за кой клиент, кои региони или класове данни са разрешени и дали идентификационните данни BYOK са необходими за някои клиенти.
За Model Gate и подобни продукти практическата връзка е директна. Ако клиентите изграждат агентски услуги върху шлюз, те в крайна сметка ще поискат използването на търсене да се появи до използването на модела в същата повърхност за анализ. Партньорските приложни програмни интерфейси (API) може също да се наложи да изложат записи на обаждания за търсене, така че платформите надолу по веригата да могат да таксуват точно собствените си клиенти. Третирането на търсенето като първокласен платим инструмент би паснало естествено наред с API-управление на ключове, екипни контроли и анализи на използването.
Това не означава, че всеки шлюз трябва да копира точния списък с доставчици на Cloudflare. По-важният момент е структурен: след като търсенето на живо е достъпно през шлюз, измерването на инструмента става част от договора за шлюз. ИИ на екип API контрол на разходите, който игнорира извикванията на инструменти, ще подценява реалните разходи на агента.
Какво остава несигурно
Бета статусът оставя няколко открити въпроса. Cloudflare посочи първоначалните доставчици на търсене и описа подхода за таксуване, но производствените екипи все пак ще трябва да оценят специфичната за доставчика производителност, качеството на резултатите, ангажиментите за обработка на данни и оперативните ограничения. Публичната документация потвърждава бета версията и основния път на ценообразуване, но не решава дали един доставчик е по-добър за всички работни натоварвания или как функцията ще се развие преди общата наличност.
Също така не е ясно колко бързо разработчиците ще стандартизират търсенето, опосредствано от шлюза, вместо директните интеграции на доставчика. Екипите със съществуващи стекове за извличане могат да продължат търсенето в собствената си инфраструктура. Други може да предпочетат маршрутизиране чрез шлюз, защото намалява работата по интеграцията и централизира регистрационните файлове. Решението вероятно ще зависи както от нуждите на управлението, така и от уместността на търсенето.
Все пак посоката е достатъчно ясна. AI шлюзовете поглъщат повече от времето за изпълнение на агента около модела. Уеб търсене API бета на Cloudflare не е просто функция за търсене; това е още един знак, че контролната равнина за AI приложения сега трябва да измерва, маршрутизира и обяснява инструментите толкова внимателно, колкото борави с моделите.