Разборы · Статья: · Видео: · 28:27
Агент со 100 инструментами — это ловушка: почему точность падает и как её вернуть роутингом
Разбор доклада Prosodica с AI Engineer: почему «жадный агент», которому загрузили сразу все инструменты, становится медленнее, дороже и глупее по мере роста каталога — и как семантический роутинг (RAG для инструментов) с just-in-time контекстом возвращает точность выше 83%.
Смотреть на YouTube The 100-Tool Agent Is a Trap - Sohail Shaikh and Ankush Rastogi, Prosodica
AI Engineer · 28:27
Главы видео — нажми, чтобы перейти к моменту 9
- 0:00 Ловушка «жадного агента» Дать агенту сразу все инструменты кажется безобидным и отлично работает в демо, но ломается в продакшне.
- 2:34 Что такое fat agent Каждый вызов тащит в промпт все имена функций, описания и JSON-схемы, нужны они или нет.
- 4:11 Как рушится точность 78% на 10 инструментах, ~40% на 100, 13,6% на 741 — примерно один верный инструмент из восьми.
- 5:46 Латентность и стоимость 741 инструмент = 127k токенов на каждый запрос; на 500 инструментах TTFT переваливает за 5 секунд.
- 9:19 Семантический роутинг — RAG для инструментов Эмбеддишь описания инструментов офлайн, на запросе достаёшь top-K релевантных и инжектишь только их.
- 10:55 Just-in-time инъекция контекста Не грузить всё заранее, а дождаться запроса и подать только нужное; Anthropic через MCP срезал 150k токенов до 2k.
- 12:51 Как это честно замерили Четыре метрики, датасеты BFCL и синтетические пулы, свип K=3/5/10; K=5 как сильный дефолт.
- 15:58 Как внедрить Три шага (офлайн-индекс, ретрив на запросе, инъекция схем) и продакшн-чек-лист из шести пунктов.
- 24:24 Риски и когда роутер НЕ нужен Промах роутера, слабые описания, редкие инструменты; до 20 инструментов роутер не нужен.
Коротко
Если сваливать в промпт все определения инструментов сразу, агент тонет в контексте: на 741 инструменте точность выбора падает до 13,6%, а промпт раздувается до 127 000 токенов ещё до вопроса пользователя. Лечится это семантическим роутингом — ретривом 3–5 релевантных инструментов под конкретный запрос, который держит точность выше 83% и режет токены на инструменты почти на 99%.
Выжимка голосом
Самое ценное из разбора — за пару минут
Показать текст выжимки Скрыть текст выжимки
Озвучено синтезом речи · голос alena
Объясни проще
Суть без жаргона
Простыми словами
Когда строят ИИ-агента, ему обычно дают список всех инструментов, которыми он может пользоваться: искать рейсы, отправлять письма, смотреть календарь, дёргать API. Пока инструментов десяток, модель нормально выбирает нужный. Но чем длиннее список, тем чаще она путается, зовёт не тот инструмент или выдумывает несуществующий — и при этом отвечает медленнее и дороже, потому что весь список каждый раз тащится в запрос. Решение простое: не показывать модели весь каталог, а под каждый вопрос сначала находить 3–5 подходящих инструментов и подсовывать только их.
Как ребёнку
Представь мастера, у которого есть огромный ящик с сотнями инструментов. Если вывалить их все на стол разом, он будет долго рыться и может схватить не ту отвёртку. А если помощник заранее послушает задачу и положит перед ним только молоток и пару гвоздей — мастер сделает всё быстро и без ошибок.
Аналогия — «это как…»
Это как официант, который вместо того чтобы приносить тебе меню на триста страниц, спрашивает «что вы хотите?» и приносит одну страницу с тремя блюдами, которые точно подходят. Меню в ресторане не уменьшилось — просто перед тобой всегда лежит короткий релевантный список.
Зачем это мне
Почти любой продакшн-агент рано или поздно обрастает десятками и сотнями инструментов (особенно через MCP-серверы), и команды винят в сбоях «плохие промпты». Доклад показывает, что проблема архитектурная: раздутый каталог одновременно бьёт по точности, латентности и счёту за токены — а чинится это не переписыванием на полгода, а спринтом поверх уже имеющейся RAG-инфраструктуры.
Для тех, кто в теме
Semantic routing = RAG над определениями инструментов: офлайн эмбеддишь описания в vector index, на запросе эмбеддишь query, достаёшь top-K (дефолт K=5) и инжектишь в вызов модели только эти схемы. Ключевые числа из бенчмарка (Berkeley Function Calling Leaderboard + синтетические пулы до 1041 инструмента): fat agent 78%→13,6% точности на 10→1041 инструментах против стабильных >83% у роутера; 127k токенов на инструменты у fat agent против ~1k у JIT (≈99% сокращение tool-context); TTFT у fat agent >5 c на 500 инструментах против почти плоского у роутера. Причина деградации — lost-in-the-middle. Риски: router miss (fallback: шире K / второй проход / broader tool group), слабые описания, редкие инструменты.
Оценка видео
Чем выше — тем больше пользы на минуту
средняя из 5
Управление контекстом агентов и рост каталогов инструментов через MCP — одна из горячих инженерных тем 2026 года.
Конкретные цифры, чёткий паттерн, код, продакшн-чек-лист и разбор рисков — плотно и по делу.
Авторы честно говорят: это не новая идея, а lazy loading и RAG, применённые к выбору инструментов.
Готовый рецепт: K=5 как дефолт, шесть шагов внедрения, переиспользование имеющейся vector DB.
Есть ссылки на Anthropic MCP и MCP Zero, но своя методология бенчмарка и цифры даны без модели и деталей.
Кому будет полезно
Чем выше оценка — тем больше пользы для профессии. Разверни — почему.
Для разработчиков ИИ-агентов 5 /5
Прямое попадание: доклад про то, как строить agent loop, чтобы он не разваливался по мере роста каталога инструментов.
Для ML-инженеров 4.3 /5
Эмбеддинги, vector search, top-K ретрив и оценка точности выбора инструмента — всё в их зоне ответственности.
Для техлидов и архитекторов 4.2 /5
Помогает решить, когда монолитного агента пора резать на роутер, и как оценить trade-off латентности, цены и точности.
Для бэкенд-разработчиков 4 /5
Латентность first token, стоимость на 100k запросов в день и интеграция роутера в вызов модели — их повседневные заботы.
Для продакт-менеджеров AI-продуктов 3.4 /5
Объясняет, почему агент кажется медленным, дорогим и «тупит» — и что это лечится архитектурой, а не новой моделью.
Инсайты
Нажми, чтобы раскрыть — то, что меняет взгляд на тему
01 Агент ломается не из-за плохого инструмента, а из-за архитектуры 3:13
Инстинкт — чинить промпты или переписывать инструмент, который «зовётся не вовремя». Но сбой возникает потому, что каждый запрос вынужден нести весь каталог. Это меняет диагноз: проблема не в качестве отдельных кусков, а в том, что модель заставляют решать не ту задачу.
02 Больше возможностей — глупее агент 4:11
Мы привыкли, что добавить фичу = сделать продукт мощнее. С инструментами всё наоборот: каждый новый инструмент в общем промпте снижает точность выбора для всех остальных. Способности агента и его надёжность начинают тянуть в разные стороны.
03 Роутер ценен не тем, что добавляет, а тем, что убирает 20:06
Обычно про ретрив думают как про «достать нужное». Но половина силы — в том, что неправильные инструменты просто не попадают в набор вариантов модели. Убрать соблазн ошибиться бывает важнее, чем подсказать правильный ответ.
04 Это не новая проблема, а lazy loading для контекста LLM 10:55
Индустрия десятилетиями грузит ресурсы по требованию: lazy loading, JIT-компиляция, ленивая подгрузка. Раздутый промпт — та же болезнь «загрузили всё заранее», только в новой обёртке. Значит, и лечение уже известно.
05 Токены — это одновременно деньги, задержка и точность 5:46
Легко считать токены только строкой в счёте. Но те же лишние токены на описания инструментов удлиняют time to first token и топят нужные схемы в «середине» контекста. Один раздутый промпт бьёт сразу по трём метрикам.
Ключевые цитаты
Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале
«Дизайн ломается не потому, что какой-то один инструмент плохо написан. Он ломается потому, что каждый запрос вынужден тащить весь каталог.»
«741 инструмент занимает до 127 000 токенов только на описания — ещё до того, как вообще учтён вопрос пользователя.»
«Роутер не просто добавляет нужный инструмент — он ещё и убирает неправильные из набора вариантов модели.»
«Каталог может расти, но рабочий набор модели должен оставаться маленьким.»
«Семантический роутинг — это, по сути, RAG для инструментов.»
«Это не переписывание платформы на полгода. Для большинства команд это сфокусированный спринт.»
«Если агент начинает сбоить по мере добавления инструментов, это не обязательно значит, что плохи ваши промпты. Возможно, архитектура заставляет модель решать не ту задачу.»
«Цель не в том, чтобы усложнять агентов, а в том, чтобы перестать заставлять модель рассуждать над нерелевантными инструментами.»
Полезные советы
Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать
1 Посчитай, сколько токенов съедают твои инструменты
15 минут увидишь скрытый налог, который платится на каждом запросе ещё до вопроса пользователя
Посчитай, сколько токенов съедают твои инструменты
Сложи токены всех определений инструментов, которые уходят в промпт по умолчанию, и умножь на дневное число запросов. На большом каталоге это легко превращается в миллиарды токенов в день только на описания.
Что делать
- 1 Выгрузи полный список схем инструментов, которые сейчас идут в каждый вызов.
- 2 Посчитай их суммарный размер в токенах (tokenizer модели).
- 3 Умножь на реальный дневной трафик — получишь цену и задержку «за воздух».
2 Не ставь роутер, пока инструментов меньше 20
5 минут не переусложнишь систему там, где статическая загрузка ещё работает нормально
Не ставь роутер, пока инструментов меньше 20
Авторы прямо предупреждают: до ~20 инструментов роутер избыточен, грузи их напрямую. Смысл появляется, когда в продакшне переваливаешь за 50 и промпт/латентность/путаница становятся реальной болью.
3 Начни с K=5 и подметай логи
1 час получишь рабочий дефолт без долгого подбора и данные для будущего тюнинга
Начни с K=5 и подметай логи
K=5 — сильная стартовая точка: меньше K дешевле и быстрее, больше K вылавливает пограничные случаи. Прогони тест-сет на K=3/5/10 и возьми наименьший K, который бьёт твою цель по точности.
Что делать
- 1 Собери тестовый набор реальных запросов с известными «правильными» инструментами.
- 2 Прогони роутер на K=3, 5 и 10, замерь точность выбора.
- 3 Зафиксируй минимальный K, который проходит порог, — он же самый дешёвый.
4 Переиспользуй существующую RAG-инфраструктуру
полдня внедришь роутинг спринтом, а не проектом на полгода
Переиспользуй существующую RAG-инфраструктуру
Если у тебя уже есть embedding-модель и vector DB под документы, роутинг инструментов — тот же паттерн ретрива, только достаёшь инструменты, а не тексты. Никакой новой инфраструктуры городить не нужно.
5 Перепиши описания инструментов словами пользователей
вечер поднимешь качество ретрива без смены модели и кода
Перепиши описания инструментов словами пользователей
Слабые описания дают слабые эмбеддинги, и роутер промахивается. Пиши описания теми словами, которыми формулируют запрос сами пользователи, и явно включай намерение, действие и ключевые сущности.
Что делать
- 1 Собери реальные формулировки запросов из логов.
- 2 Перепиши описание каждого инструмента под эти слова: intent + action + entities.
- 3 Переэмбеддь инструменты после правок описаний.
6 Заведи fallback на промах роутера
1 час агент не будет падать на редких или необычных запросах
Заведи fallback на промах роутера
Роутер иногда не достаёт нужный инструмент. Заранее пропиши запасной путь: расширить K, сделать второй проход ретрива или отправить запрос в более широкую группу инструментов.
7 Логируй каждое решение роутера
1 час сможешь чинить промахи и тюнить K на реальных данных
Логируй каждое решение роутера
Пиши, какие инструменты выбрал роутер, какой в итоге вызвала модель, где были сбои и fallback. Без логов ты не поймёшь, надо ли переписать описание редкого инструмента или поднять K.
8 Собери каталог инструментов в одном месте
2 часа получишь управляемый источник правды вместо хардкода в agent loop
Собери каталог инструментов в одном месте
Заведи единый реестр: имя, описание, схема, владелец, версия. Список инструментов для модели должен приходить из роутера по этому реестру, а не из захардкоженного полного каталога.
Сценарии применения
Как разные люди применяют это на практике
Я как AI-инженер стартапа
Проблема: после 60 инструментов агент стал звать не те функции и иногда выдумывать имена
Хочу: вернуть точность, не выкидывая половину возможностей
Поможет: разбор показывает, что дело в раздутом каталоге, и даёт паттерн ретрива top-K вместо загрузки всего
Я как ML-инженер
Проблема: уже есть vector DB под RAG, но непонятно, как приткнуть к ней выбор инструментов
Хочу: переиспользовать инфраструктуру эмбеддингов для роутинга
Поможет: статья объясняет, что роутинг — тот же ретрив, только над описаниями инструментов
Я как Бэкенд-разработчик real-time продукта
Проблема: time to first token уплывает за секунды, SLA по отклику трещит
Хочу: сделать латентность агента стабильной и предсказуемой
Поможет: видно, что маленький постоянный промпт держит TTFT почти плоским независимо от размера каталога
Я как Техлид
Проблема: один монолитный агент со всеми инструментами стало страшно тестировать и обновлять
Хочу: понять, когда и как резать его на роутер
Поможет: есть порог (>50 инструментов), чек-лист внедрения и оценка рисков
Я как Основатель, следящий за расходами
Проблема: счёт за токены растёт быстрее трафика, непонятно за что платим
Хочу: срезать издержки без потери качества
Поможет: показан источник — описания инструментов в каждом запросе — и ~99% сокращение этих токенов через JIT
Я как Продакт-менеджер AI-продукта
Проблема: пользователи жалуются, что ассистент «тупит» и делает не то
Хочу: объяснить команде, почему и что чинить
Поможет: аргумент: это архитектура подачи инструментов, а не «плохая модель» или «плохие промпты»
Я как Платформенный инженер с MCP-серверами
Проблема: десятки MCP-серверов дают тысячи инструментов на агента
Хочу: масштабировать выбор инструментов без взрыва контекста
Поможет: упомянуты MCP Zero и роутинг на тысячах инструментов через много серверов
Логика повествования
Как устроена аргументация видео — пройди по шагам
-
Предпосылка Дать агенту сразу все инструменты — удобно 0:00
Простейший дизайн: каждое имя функции, описание и JSON-схема идут в промпт на каждый запрос.
-
Аргумент На 10 инструментах это работает, но каталог растёт 2:34
10 → 30 → сотни. В какой-то момент модель начинает звать не те функции, путать похожие и выдумывать имена.
-
Пример 741 инструмент = 127k токенов и 13,6% точности 4:11
Точность падает 78% → ~40% → 13,6%; это примерно один верный инструмент из восьми.
-
Аргумент Причина — «потерян в середине» и раздутый промпт 5:11
Модель сильнее смотрит на начало и конец контекста; сотни схем в середине она использует ненадёжно.
-
Аргумент Решение — семантический роутинг: RAG для инструментов 9:19
Достаём под запрос только 3–5 релевантных инструментов и инжектим в модель лишь их схемы.
-
Пример На запрос про рейс подаются только нужные схемы 19:11
«Найди рейс в Нью-Йорк» → search flights, book flight, calendar check; отели и погода даже не в наборе.
-
Аргумент Роутер держит точность >83% и латентность стабильной 14:26
С точки зрения модели она всегда выбирает из горстки инструментов, даже если каталог огромен.
-
Вывод Каталог растёт, а рабочий набор модели остаётся маленьким 15:39
Главный урок: масштабируй каталог, но не рабочее окно, в котором модель принимает решение.
Подробный разбор
Полный разбор — разверни, если нужно глубже
Развернуть подробный разбор Свернуть подробный разбор
Стоит ли смотреть целиком
Да, если вы строите или проектируете ИИ-агента, который уже вышел из стадии демо. Доклад плотный и практичный: за полчаса — понятная механика проблемы, конкретные числа, код, шесть шагов внедрения и честный разбор рисков. Особенно ценно, что авторы делят роли: Sohaib отвечает за поведение модели и роутинга, Ankush — за системный дизайн и продакшн-компромиссы, поэтому разговор не скатывается ни в чистую теорию, ни в голый инженерный рецепт.
Главная польза — не в самих цифрах, а в смене диагноза. Когда агент начинает «тупить» по мере роста, первая реакция — крутить промпты и модель. Доклад аргументированно показывает, что чаще виновата архитектура подачи инструментов, и предлагает лечение, которое почти наверняка уже наполовину лежит у вас в стеке в виде embedding-модели и vector DB.
Чего в докладе не хватает
Бенчмарк — собственный, и авторы не называют модель, эмбеддер и полную методологию, поэтому конкретные проценты стоит воспринимать как иллюстрацию тренда, а не как обещание. Отдельно почти не обсуждаются нативные альтернативы от провайдеров (серверный tool-search, prompt caching, параллельные вызовы) и композитные запросы, где нужны инструменты из разных кластеров сразу. Но как отправная точка и чёткий mental model «каталог может расти, рабочий набор — нет» доклад работает отлично.
План внедрения
С чего начать — отмечай шаги, прогресс сохранится
Выполнено 0 из 6
Проверь себя
Ответь на вопросы, чтобы материал закрепился
-
1. Почему «жадный агент» (fat agent) теряет точность с ростом каталога инструментов?
-
2. Какая точность выбора инструмента у fat agent на 741 инструменте по бенчмарку?
-
3. Что по сути делает семантический роутер?
-
4. С какого значения K авторы рекомендуют начинать?
-
5. Когда роутер, по словам авторов, НЕ нужен?
-
6. В чём «недооценённая» польза роутера помимо подсказки правильного инструмента?
-
7. На сколько Anthropic через on-demand загрузку инструментов в MCP срезала токены (по докладу)?
Словарь терминов
Понять незнакомое простым языком
Показать 10 терминов Свернуть словарь
- Fat agent (жадный агент)
- Агент, которому в каждый запрос загружают определения всех инструментов сразу, независимо от того, нужны они или нет.
- Семантический роутинг
- Приём, где под каждый запрос сначала находят несколько релевантных инструментов по смыслу и подают модели только их. По сути RAG, но над инструментами, а не документами.
- Just-in-time инъекция контекста
- Стратегия «не грузить заранее»: дождаться, пока запрос понятен, и добавить в промпт только тот контекст, который нужен именно сейчас.
- Lost in the middle (потерян в середине)
- Свойство LLM надёжнее использовать информацию в начале и конце длинного контекста и хуже — в середине. Из-за него сотни схем в середине промпта работают плохо.
- Top-K (K)
- Сколько инструментов роутер достаёт под один запрос. Меньше K — дешевле и быстрее, больше K — лучше ловит редкие случаи. Дефолт K=5.
- Time to first token (TTFT)
- Задержка до первого токена ответа. Растёт с размером промпта: модель должна прочитать весь каталог, прежде чем начать отвечать.
- Эмбеддинг
- Числовой вектор, кодирующий смысл текста. Похожие по смыслу тексты дают близкие векторы — на этом строится поиск релевантных инструментов.
- Vector database
- База, хранящая эмбеддинги и умеющая быстро искать ближайшие по смыслу (Chroma, Pinecone, Qdrant).
- MCP
- Model Context Protocol — стандарт подключения инструментов к агентам. Один агент легко набирает тысячи инструментов через много MCP-серверов.
- Berkeley Function Calling Leaderboard
- Публичный бенчмарк качества выбора и вызова функций моделью; использован для замеров в докладе.
Критический взгляд
Объективно: с какими тезисами можно поспорить и что преувеличено
Цифры точности (78% → 13,6%, >83% у роутера) даны без модели и деталей
Итог сильно зависит от конкретной модели, эмбеддера, качества описаний и состава синтетических пулов. Как иллюстрация тренда числа убедительны, но переносить их на свой стек как гарантию нельзя — нужен собственный замер.
Сравнение «fat agent против роутера» немного одностороннее
Роутер добавляет собственную точку отказа (router miss), и реальная точность = точность ретрива × точность выбора. Авторы честно упоминают fallback, но график сравнивает идеальный ретрив с раздутым каталогом, а не с промежуточными вариантами.
Игнорируются нативные механизмы провайдеров
Провайдеры уже дают tool-search на своей стороне, prompt caching описаний и параллельные вызовы, которые тоже смягчают проблему больших каталогов. Свой семантический роутер — не единственный путь и не всегда самый дешёвый в поддержке.
«RAG для инструментов» — упрощение для многошаговых задач
Эмбеддинг-ретрив хорошо ловит запросы вокруг одного намерения, но композитные задачи требуют инструментов из разных семантических кластеров сразу. Тут одного прохода top-K может не хватить, и нужен агрегирующий или многоступенчатый роутинг.
«99% сокращение токенов» легко прочитать шире, чем есть
Речь про токены на описания инструментов, а не про весь промпт. Системный промпт, история и сам вход пользователя никуда не деваются, так что общий выигрыш по стоимости запроса обычно скромнее заявленных 99%.
Взгляни иначе
Новый угол, смежные области и потенциал на стыке — пища для размышлений
Проблема не в инструментах, а во внимании модели
Тот же механизм бьёт по раздутым системным промптам, длинной истории чата и куче few-shot примеров. Стоит думать не «сколько инструментов дать», а «что вообще должно лежать в рабочем окне внимания под этот конкретный ход».
Ретрив под запрос — не только для инструментов
Тот же приём просится на подсказки, примеры, документацию и куски системного промпта: собирать контекст под задачу динамически, а не держать одну гигантскую статичную «шапку» на все случаи.
Роутер инструментов = скрытый слой безопасности
Если ретрив уже решает, какие инструменты видит модель, тот же шаг может фильтровать их по роли, правам и политике доступа. Управление контекстом и управление доступом (cross-domain со security) естественно сливаются в одну точку.
Инструменты как микросервисы для агентов
Вместо одного монолитного агента со всем каталогом — кластеры инструментов как отдельные суб-агенты с узким набором, а роутер играет роль сервис-меша. Это перенос организационного принципа декомпозиции (cross-domain с архитектурой ПО) на агентов.
Роутер может уехать внутрь самого API
По мере того как провайдеры встраивают tool-search и серверную фильтрацию, ручной семантический роутер рискует стать временным решением — как когда-то самописные пулы соединений уступили встроенным. Стоит закладывать это в архитектуру.
Похожие разборы
Domain-specific агенты: почему будущее за роем узких ИИ, а не за одним всемогущим
Компании пытаются интегрировать ИИ, навешивая на один большой агент всё больше MCP и skills — и упираются в раздувание контекста и хрупкость. Автор доказывает, что будущее за композицией: рой узких доменных агентов, каждый со своей моделью, инструментами и памятью, координируемых на обычном языке — это дешевле, безопаснее и масштабируется.
Читать → РазборМодель предлагает — платформа решает: инфраструктура надёжности для автономных ИИ-агентов
При переходе от чатботов к автономным агентам узкое место смещается с интеллекта модели на надёжность инфраструктуры вокруг неё. Модель должна лишь предлагать действия, а проверять, одобрять и исполнять их обязана детерминированная платформа — и именно она, а не лучший промпт, становится конкурентным преимуществом.
Читать → РазборTurboQuant: как ужать память агентного поиска в 5 раз без потери качества
Эмбеддинги в поиске хранятся в полной 32-битной точности, хотя ранжированию хватает 3–4 бит, — отсюда пятикратный перерасход памяти. TurboQuant сжимает векторы до этих 3–4 бит без падения качества, и подключается он заменой одного слоя ретривера, не трогая ни агента, ни векторную базу.
Читать → РазборHeadroom: как перестать переплачивать за токены ИИ-агентов — слой сжатия контекста простыми словами
Большая часть токенов в Claude Code и Codex уходит не на ваши промпты, а на «мусор» — целиком вычитанные логи, JSON и страницы, из которых нужно 10–20%. Headroom — это локальный прокси, который умно сжимает этот мусор разными компрессорами и при этом обратим: если модель захочет оригинал, она вернёт его одним tool-call.
Читать →