Веб-поиск как статья расходов агентов
Обновлено September 10, 2026 · впервые опубликовано September 10, 2026
Агенты переходят от статичных знаний к живому веб-исследованию, и модель стоимости меняется. Один запрос пользователя теперь может запустить несколько поисков, вызов модели для разбора каждого результата, повторы при сбоях инструмента и финальный синтез. Слой поиска больше не невидимая инфраструктура: это отдельно тарифицируемая часть задачи.
Например, Amazon Bedrock AgentCore описывает веб-поиск как возможность с оплатой за использование: $7 за 1,000 запросов. Цена зависит от провайдера и продукта, но урок FinOps универсален: вызовы инструментов считаются оплачиваемой работой наравне с входными и выходными токенами. Актуальный пример см. в объявлении AWS.
Один запрос может стать множеством поисков
Усиление поиска идёт от планирования. Агент может переформулировать вопрос, искать по нескольким источникам, пройти по ссылке, повторить запрос после таймаута и искать снова, найдя противоречивые данные. Если приложение фиксирует только исходный запрос пользователя, финансы видят функцию с низкой нагрузкой, а провайдер получает большую нагрузку от вызовов инструментов.
Записывайте ID родительской задачи, провайдера поиска, число запросов, число загруженных результатов, число повторов и то, изменил ли результат итоговый ответ. Затем считайте стоимость поиска на успешную задачу. Поиск, который ни разу не помог полезному ответу, — кандидат на изменение политики, а не просто статья расходов, которую нужно принять.
Контролируйте бюджет поиска
- Задавайте максимальное число поисковых запросов на задачу и на тариф пользователя.
- Для первичного обнаружения используйте более дешёвый проход, а глубокое исследование оставляйте для задач высокой ценности.
- Кэшируйте стабильные запросы и нормализуйте безобидные различия в формулировках.
- Останавливайтесь, когда достигнут порог доказательств, а не давайте планировщику исследовать бесконечно.
- Делайте повторы с экспоненциальной задержкой и ограничивайте их отдельно от повторов модели.
Сверяйте свежесть данных с расходами
Свежесть ценна, только если меняет решение. Сравнивайте качество ответа и успех задач при разной глубине поиска: без поиска, с одним запросом и с ограниченным набором запросов. Некоторым процессам нужна актуальная информация; другие платят за повторное получение фактов, которые меняются медленно.
Показывайте три числа вместе: стоимость модели, стоимость поиска и стоимость на успешную задачу. Так дешёвая модель не будет выглядеть эффективной, если она компенсирует слабость большим числом платных поисков. Продуктовым командам это же даёт обоснование, когда живая веб-опора стоит своей цены.
Связанное
По теме
Хотите применить это к своему стеку? Принесите счета провайдеров, логи шлюза и ключевые рабочие процессы — мы определим драйверы затрат и пути экономии. Заказать бесплатный аудит →