Подоспел реальный пример для иллюстрации поста<\/p>\n
В позапрошлом посте <\/a> я писал, что агентский поиск должен принимать пачку запросов за раз. Напомню идею: один тулкол, много запросов, один ответ. Иначе получается N+1: агент ищет, ищет, ищет.<\/p>\n И вот поспел живой пример.<\/p>\n У Вкусвилла появился официальный MCP<\/a>. vkusvill_products_search<\/i> принимает один q<\/i>. У меня в приложении Recipe Scaler<\/a> список покупок для рецептов. Пара блюда — штук 20 ингредиентов. Чтобы собрать из них корзину Вкусвилла, мой агент делает примерно так:<\/p>\n Каждый поиск — это полный цикл тулкола, кусок контекста, шанс упереться в рейт-лимит у меня или у мцп Вкусвилла. Да в целом я задумался, когда у меня сработала защита на число тулов в одном вопросе. Да и пользователю тоже неудобно: «ищем, ищем, ищем».<\/p>\n Человеку так и надо: вбил «сметана», посмотрел выдачу. Агенту так не надо, он может посмотреть пять выдач параллельно.<\/p>\n Могло бы быть так:<\/p>\n И ответ:<\/p>\n Батчинг тоже надо делать не в тупую, например limit<\/i> нужно на каждый запрос, не общий на всю выдачу. Для корзины из рецепта не нужны десять сметан. А общий лимит оставить только как защиту от дос-атаки.<\/p>\n",
"summary": "В позапрошлом посте я писал, что агентский поиск должен принимать пачку запросов за раз. Напомню идею",
"date_published": "2026-08-27T15:56:27+05:00",
"date_modified": "2026-08-27T15:56:25+05:00",
"tags": [
"ИИ",
"интерфейс"
],
"_date_published_rfc2822": "Thu, 27 Aug 2026 15:56:27 +0500",
"_rss_guid_is_permalink": "false",
"_rss_guid": "229",
"_e2_data": {
"is_favourite": false,
"links_required": [
"highlight\/highlight.js",
"highlight\/highlight.css"
],
"og_images": []
}
},
{
"id": "227",
"url": "https:\/\/mikeozornin.ru\/blog\/all\/agentic-ui\/",
"title": "Что такое agentic UI \/ agent-friendly сервис",
"content_html": " Нейросети сводят всех с ума, началась эпоха «агентского интерфейса».<\/p>\n Только ленивый не говорит про агентский юикс, выходят посты, статьи как его делать. В целом этот агентский юикс немножко напоминает истерию с чат-ботами лет десять назад. Когда появились чат-боты (те, которые работали на скриптах, не поверх языковых моделей), тоже была истерика, что всё, Галя, отменяем все интерфейсы, всё переводим на чат-боты.<\/p>\n Ну отлично, перевели на чат-ботов.<\/p>\n А потом оказалось, что пропускная способность интерфейса чат-бот (количество бит информации, которое может пропустить чат-бот за одно взаимодействие), очень низкая. И людям неинтересно, смотреть по одному варианту чат-бота для билетов. Они хотят выдать хорошую, понятную, удобную выдачу с сортировкой и фильтрами. Они не хотят формулировать пару кликов мыши в виде сообщения «покажи сейчас варианты до 5 тыс, но если хорошие, то и до 7.5 тыс тоже можно».<\/p>\n Чат-бот — это как ночной режим у меня в блоге (посмотрите, чтобы понять аналогию) — смотреть на маленькую область, а не видеть всю картину целиком.<\/p>\nvkusvill_search_products({ q: "яйца" })\nvkusvill_search_products({ q: "тесто фило" })\nvkusvill_search_products({ q: "апельсин" })\nvkusvill_search_products({ q: "греческий йогурт" })\nvkusvill_search_products({ q: "сахар" })\nvkusvill_search_products({ q: "разрыхлитель" })\nvkusvill_search_products({ q: "ваниль" })\nvkusvill_search_products({ q: "растительное масло" })\nvkusvill_search_products({ q: "апельсиновый сок" })\nvkusvill_search_products({ q: "корица" })\nvkusvill_search_products({ q: "вода" })\nvkusvill_cart_link_create({ products: [...] })<\/code><\/pre>{\n "queries": [\n { "q": "сметана 20%", "limit": 3 },\n { "q": "мука пшеничная", "limit": 3 },\n { "q": "яйца С1", "limit": 3 },\n { "q": "черника свежая", "limit": 3 }\n ],\n "mode": "short",\n "sort": "rating",\n "vvonly": 1\n}<\/code><\/pre>{\n "results": [\n {\n "q": "сметана 20%",\n "items": [\n { "id": 111, "xml_id": 222, "name": "Сметана 20%", "price": 89, "rating": 4.8 }\n ]\n }\n ]\n}<\/code><\/pre>