Анти-патерн Too Many Tools: занадто багато інструментів

Ідея за 30 секунд

Too Many Tools — це анти-патерн, коли агенту дають занадто багато інструментів без чітких меж по задачах.

У результаті зростає шум у виборі дій: агент частіше бере нерелевантний інструмент і витрачає кроки на повторний вибір. Це підвищує latency, вартість і нестабільність відповіді.

Просте правило: для кожного сценарію агент має бачити лише мінімальний набір інструментів, які справді потрібні.

Приклад анти-патерну

Команда будує support-агента для запитів про замовлення, повернення і оплату.

Замість вузького набору команда дає агенту великий список інструментів "на всі випадки".

response = agent.run(
    "User: Чому не проходить оплата за замовлення #8341?"
)

У такій схемі агент має десятки варіантів і може піти в неправильний бік:

tools = ["get_payment_status", "get_invoice", "get_order"]
selected_tool = agent.pick_tool(tools)
result = run_tool(selected_tool, order_id)

# агент може спершу обрати get_invoice,
# не знайти причину збою
# і лише потім перейти до get_payment_status

Для цього кейсу достатньо короткого маршруту з кількома інструментами:

payment_data = get_payment_status(order_id)
return format_payment_answer(payment_data)

У цьому випадку надлишок tools додає:

• шум у виборі дій
• зайві виклики інструментів
• вищий ризик неправильного маршруту

Чому виникає і що йде не так

Цей анти-патерн часто з’являється, коли команда намагається зробити "універсального" агента для всіх запитів одразу.

Типові причини:

• додавання нових tools без видалення старих
• відсутність per-task allowlist для інструментів
• страх "а раптом не вистачить одного інструмента"
• копіювання великих toolset із демо без перевірки продакшн-кейсів

У результаті виникають проблеми:

• нестабільний вибір — агент бере tool, який формально підходить, але не найкращий
• вища latency — цикл вибору і повторні виклики займають більше часу
• більша вартість — зайві tool або LLM кроки на типовий запит
• роздутий контекст — у prompt потрапляє опис багатьох tools і проміжні результати
• складний дебаг — важко відстежити, чому агент обрав саме цей шлях

Типові production-сигнали, що інструментів уже забагато:

• типовий user request запускає 3-5 tool викликів там, де вистачило б 1-2
• одна й та сама задача проходить різними шляхами в різних запусках
• команда не може чітко пояснити, чому tool A обирається замість tool B
• додавання нового tool погіршує quality існуючих сценаріїв

У результаті агент витрачає більше кроків на вибір дії, ніж на розв’язання самої задачі. Важливо, що вибір інструмента — це частина LLM inference. Модель обирає дію серед опцій, які бачить у prompt. Коли інструментів стає багато, зростає кількість можливих шляхів, і вибір стає менш стабільним: модель частіше обирає інструмент, який формально підходить, але не є найкращим.

Коли така схема розростається, без trace і візуалізації виконання стає важко зрозуміти, чому агент обрав саме цей інструментальний шлях. Тому production-системи зазвичай мають окремий шар спостережуваності для запусків агентів.

Правильний підхід

Починайте з найпростішого маршруту, який стабільно закриває більшість запитів сьогодні. Інструменти додавайте лише тоді, коли є вимірюваний збій, ризик або обмеження поточного дизайну.

Практична рамка:

• для кожного типу задачі задайте чіткий tool allowlist
• тримайте малий набір tools у кожному маршруті
• додавайте новий tool тільки тоді, коли є вимірювана причина (наприклад, покращення success rate або зменшення помилок без різкого росту latency і cost per request)

def answer_payment_question(order_id: str, user_message: str) -> str:
    route = classify_intent(user_message)  # simple classifier or rules

    if route == "payment_status":
        allowed_tools = ["get_payment_status"]
        data = run_tool("get_payment_status", order_id)
        return format_payment_answer(data)

    allowed_tools = ["get_payment_status", "get_invoice"]
    return agent.run(
        user_message=user_message,
        allowed_tools=allowed_tools,
    )

У такій схемі агент працює з невеликим і релевантним набором інструментів, тому вибір дії стає стабільнішим.

Швидкий тест

Якщо на ці питання відповідь "так", у вас є ризик too-many-tools:

• Чи типовий запит регулярно потребує 3+ tool викликів там, де мало б вистачити 1-2?
• Чи один і той самий запит проходить різними tool-шляхами в різних запусках?
• Чи нові tools додаються швидше, ніж команда встигає їх обмежувати, прибирати або переглядати?

Чим відрізняється від інших анти-патернів

Tool Calling for Everything vs Too Many Tools

Multi-Agent Overkill vs Too Many Tools

Giant System Prompt vs Too Many Tools

Самоперевірка: чи немає у вас цього анти-патерну

Швидка перевірка на anti-pattern Too Many Tools.
Відмічайте пункти під вашу систему і дивіться статус нижче.

Перевірте свою систему:

FAQ

Q: Чи означає це, що багато tools — завжди погано?
A: Ні. Проблема не в кількості як такій, а в тому, що агент бачить забагато нерелевантних опцій у конкретному сценарії.

Q: Коли додавати новий tool?
A: Коли є конкретний сигнал: прогалини в покритті задач, помилки якості або ліміти поточного маршруту, які не закриваються поточним набором без непропорційного росту latency, cost або складності дебагу.

Q: Як зменшити хаос у виборі tools без великого рефакторингу?
A: Почніть із простого: введіть allowlist по типу задачі, зафіксуйте ліміт кроків і приберіть tools, які майже не використовуються або дають дублюючий результат.

Що далі

Схожі anti-patterns:

• Agent Everywhere Problem — коли агент додається навіть для детермінованих задач.
• Overengineering Agents — коли система обростає зайвими шарами без вимірюваної користі.
• Multi-Agent Overkill — коли в системі надто багато агентів із розмитими ролями.

Що будувати замість цього:

• Allowed Actions — як задавати чіткі межі того, що агенту дозволено робити.
• Routing Agent — як маршрутизувати задачі й давати агенту лише релевантні інструменти.
• Tool Execution Layer — де в архітектурі контролювати виклики tools і політики доступу.