Агенты и tool-use

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 11, остальные разбираются в тренажёре.

1. #agents_tooluse1 / 5
   Когда агент с инструментами оправдан, а когда лучше один вызов LLM?

   A)Агент с инструментами лучше одиночного вызова: чем больше в нём шагов, тем выше итоговое качество

   B)Агент — для многошаговых задач с внешними данными/действиями; для простого ответа один вызов дешевле и надёжнее

   C)Один вызов подходит для перевода текста

   D)Разницы нет, выбор чисто стилистический

   показать ответ и разбор

   +B)Агент — для многошаговых задач с внешними данными/действиями; для простого ответа один вызов дешевле и надёжнее

   // разбор: Агент оправдан, когда задача требует внешних данных, действий или ветвления на несколько шагов (найти → посчитать → записать). За это платят латентностью, стоимостью (много вызовов) и хрупкостью (ошибка на шаге ломает цепочку). Если задача решается одним ответом — один вызов дешевле, быстрее и предсказуемее. Дисциплина: минимально достаточная агентность, а не «агент ради агента».

2. #agents_tooluse2 / 5
   Частый провал tool-use агента в проде — это...

   A)Модель физически не способна вернуть корректно структурированный JSON-вызов в этом случае

   B)Инструменты исполняются мгновенно и без ошибок

   C)Агент не умеет прочитать текст ответа инструмента

   D)модель зовёт не тот инструмент или с кривыми аргументами, либо зацикливается на повторных вызовах

   показать ответ и разбор

   +D)модель зовёт не тот инструмент или с кривыми аргументами, либо зацикливается на повторных вызовах

   // разбор: Реальные провалы: неверный выбор инструмента, галлюцинированные/невалидные аргументы (не по схеме), зацикливание (повторяет вызов, игнорируя результат), плохая обработка ошибки инструмента. Лечат: строгие схемы + валидация аргументов, повтор с сообщением об ошибке модели, лимит шагов/бюджет, few-shot удачных вызовов, узкий набор инструментов. Вернуть JSON модель умеет — проблема в семантике вызова.

3. #agents_tooluse3 / 5
   Когда мульти-агентная схема (несколько специализированных агентов) оправдана против одного агента?

   A)Когда задача делится на роли с раздельными инструментами/контекстом; иначе — лишняя координация без выгоды

   B)Чем больше специализированных агентов вовлечено в задачу, тем выше её итоговое качество

   C)Когда у системы нет доступа к инструментам

   D)Мульти-агент нужен для задач перевода

   показать ответ и разбор

   +A)Когда задача делится на роли с раздельными инструментами/контекстом; иначе — лишняя координация без выгоды

   // разбор: Мульти-агент выигрывает, когда задача естественно распадается на роли с разными инструментами, промптами или контекстами (планировщик/исполнитель/критик), давая изоляцию и специализацию. Но каждый агент — это координация, передача контекста, лишние вызовы и новые точки отказа. Для монолитной задачи один хорошо оснащённый агент проще и дешевле. Правило то же: минимально достаточная сложность.

4. #agents_tooluse4 / 5
   Длинный агентный диалог упирается в переполнение контекста. Что из перечисленного НЕ решение?

   A)Суммаризация ранней истории в компактную сводку

   B)Вынос ключевых фактов во внешнюю память (векторную или структурную) с подтягиванием нужного по запросу

   C)Обрезка истории до скользящего окна последних сообщений

   D)Полагаться на то, что модель сама бесконечно помнит весь диалог в своих весах

   показать ответ и разбор

   +D)Полагаться на то, что модель сама бесконечно помнит весь диалог в своих весах

   // разбор: Контекст конечен, и в весах модель диалог не «помнит» — между вызовами состояние держит приложение, целиком передавая историю в промпт. Управляют бюджетом: суммаризация старого, скользящее окно, вынос фактов во внешнюю память с retrieval по нужде, компрессия. Ошибка — рассчитывать, что модель сама сохранит всё: за пределами окна информация просто не подаётся и «забывается».

5. #agents_tooluse5 / 5
   У агента есть инструменты, меняющие состояние (удалить, оплатить, отправить). Главная предосторожность?

   A)Дать полный автономный доступ ко всем действиям — так быстрее и удобнее пользователю

   B)Запретить агенту инструменты

   C)Ограничить права, валидировать аргументы и требовать подтверждения человека для необратимых действий (least privilege, human-in-the-loop)

   D)Просто попросить модель в промпте быть аккуратной

   показать ответ и разбор

   +C)Ограничить права, валидировать аргументы и требовать подтверждения человека для необратимых действий (least privilege, human-in-the-loop)

   // разбор: Модель вероятностна и уязвима к prompt injection, поэтому давать ей необратимые действия без страховки опасно. Принципы: least privilege (узкие права инструментов), валидация и санитайзинг аргументов, идемпотентность/лимиты, подтверждение человеком (human-in-the-loop) или dry-run для разрушительных операций, аудит-лог. Просьба «будь осторожен» — не контроль: инъекция её перебьёт. Тотальный запрет убивает пользу — нужен баланс.