Распределение инструментов между агентами и настройка tool_choice

Суть

Надёжность выбора падает с ростом числа инструментов: 4–5 сфокусированных дают надёжную маршрутизацию, 18 — перегружают пространство решений. Каждому агенту — только инструменты его роли (синтезатору не нужен веб-поиск).

Три режима tool_choice

auto — модель сама решает, звать ли инструмент (может вернуть и текст). any — обязана вызвать какой-то инструмент (текст запрещён). {"type":"tool","name":"X"} — обязана вызвать именно этот инструмент. any гарантирует вызов, но не какой именно и не порядок — для этого нужен форсированный выбор.

Узкие кросс-ролевые инструменты

Узкий инструмент (например verify_fact) закрывает 85% частых нужд прямо в роли; оставшиеся 15% сложных случаев маршрутизируются через координатора. Это принцип наименьших привилегий против злоупотреблений вне специализации.

Матрица режимов tool_choice

auto                          -> модель может вызвать инструмент ИЛИ вернуть текст
                                 (обычный диалоговый агент)
any                           -> обязан вызвать какой-то инструмент, текст запрещён
                                 (гарантированный структурированный вывод)
{"type":"tool","name":"X"}    -> обязан вызвать именно инструмент X
                                 (форсировать предусловие; следующий шаг — отдельным ходом)

Anti-patterns

Ловушка	Почему не работает	Верный паттерн
Дать синтезатору все веб-поисковые инструменты «для гибкости»	Переснаряжённый агент злоупотребляет вне специализации	Узкий `verify_fact` на 85%; сложное — через координатора
`tool_choice: "auto"`, когда нужен структурированный вывод	`auto` разрешает вернуть текст вместо вызова	`tool_choice: "any"` гарантирует вызов; либо форсировать инструмент
Дать всем агентам одинаковый полный набор «для единообразия»	Раздувает пространство решений; кросс-ролевые ошибки множатся	Каждому — только инструменты роли; маршрутизация через координатора

Exam traps

Ловушка	Почему не работает	Верный паттерн
Считать «больше инструментов = больше гибкости»	Растёт сложность решений и злоупотребления вне роли	Оптимум — 4–5 ролевых инструментов на агента
Путать `any` с форсированием конкретного инструмента	`any` гарантирует какой-то вызов, не какой и не порядок	`{"type":"tool","name":"X"}` форсирует конкретный и порядок

Практическое задание (T3)

Перечислить инструменты для системы из 3 агентов и проверить: ни у кого >5, никто не вне специализации.
Найти частую кросс-ролевую нужду синтезатора и спроектировать для неё узкий инструмент.
Описать сценарий, где верен tool_choice: "any", и объяснить, почему auto провалится.
Описать сценарий с форсированным выбором — реализовать цепочку предусловий через два хода.
Заменить generic-инструмент (fetch_url) ограниченным аналогом и объяснить, какое злоупотребление это предотвращает.

Проверка знаний

Многоагентная исследовательская система

Синтезатор часто проверяет факты при объединении находок. Сейчас каждая проверка — 2–3 round-trip через координатора (+40% задержки). 85% — простые факт-чеки, 15% — глубокое веб-исследование. Лучший подход?

A Дать синтезатору узкий verify_fact для простых проверок; сложное по-прежнему через координатора к веб-поисковику
B Синтезатор копит все проверки и в конце прохода отдаёт пачкой координатору
C Дать синтезатору все веб-поисковые инструменты, чтобы закрывать любые проверки без round-trip
D Веб-поисковик заранее кэширует лишний контекст, предугадывая будущие проверки

Извлечение структурированных данных

Агент извлечения настроен с tool_choice: "auto" и одним инструментом extract_invoice_data. В 15% случаев возвращается текст «Сейчас проанализирую счёт» вместо вызова инструмента. Что исправить?

A Добавить в system prompt: «всегда вызывай extract_invoice_data»
B Сменить tool_choice на "any" — гарантированный вызов инструмента при каждом обращении
C Сменить tool_choice на "none", чтобы не уходить в диалоговый текст
D Добавить инструментов, чтобы у модели был выбор и меньше тяги к тексту

Многоагентная исследовательская система

У координатора 8 инструментов. Он иногда зовёт format_output посреди анализа (по частичным данным) и calculate_statistics до готовности всех данных. Самое архитектурно верное решение?

A В system prompt: «порядок вызова: сначала исследование, потом анализ, в конце format_output»
B Убрать format_output и calculate_statistics у координатора и вызывать постобработкой после него
C tool_choice: "auto" плюс подробная документация каждого инструмента о моменте вызова
D Распределить инструменты по стадиям: координатору — только исследование/валидация; отдельный аналитический агент — calculate_statistics и cross_reference; презентационный — format_output, вызываемый лишь после анализа