Microsoft запустила Foundry Toolbox та супутню функцію Tool Search — єдину сервісну точку (single-endpoint service), яка дозволяє розробникам підключати ШІ-агентів до сотень інструментів без необхідності налаштовувати кожного агента окремо. Tool Search скоротив використання вхідних токенів на величину до 94%, коли каталог містив понад 600 інструментів.

Чому централізований toolbox має значення

ШІ-агентам потрібні зовнішні можливості — бази даних, CRM, аналітичні платформи — для виконання запитів користувачів. Досі багато організацій підключали кожного агента безпосередньо до потрібних API. Інженери повторно писали код для конфігурації облікових даних, застосування політик та обробки помилок для кожного нового агента. Результатом була заплутана мережа дубльованих налаштувань, яку було важко аудитувати, і яка була вразливою до прогалин у безпеці.

Foundry Toolbox замінює цей «клаптиковий» підхід єдиним сервісним шаром. Замість десятка агентів, кожен з яких звертається до десятка окремих кінцевих точок, усі агенти взаємодіють з єдиною кінцевою точкою «toolbox». Toolbox бере на себе версіонування, рядки підключення та політики безпеки, дозволяючи командам керувати всією екосистемою інструментів з одного місця. Підприємства, які використовують десятки агентів у різних бізнес-підрозділах, одразу помічають зниження операційних витрат.

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

Коли агент вмикає Tool Search, модель спочатку викликає мета-інструмент під назвою tool_search, описуючи звичайною англійською мовою те, що їй потрібно (наприклад, «find the latest sales forecast for region X»). Сервіс повертає короткий ранжований список інструментів-кандидатів, що відповідають наміру. Потім модель викликає call_tool, обираючи найбільш підходящий запис із цього списку. Завдяки наданню лише відповідного підмножини, промпт залишається крихітним, що дозволяє заощадити до 94% вхідних токенів у бенчмарку з 600 інструментами.

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

Як отримати максимум від toolbox

  • Пишіть якісні метадані – Tool Search покладається на назву та опис кожного інструмента. Нечіткі назви, як-от «Get data», дають моделі мало можливостей для роботи. Детальні заголовки, наприклад «Retrieve customer renewal risks and contacts», спрямовують пошукову систему до правильного збігу.
  • Закріплюйте часто використовувані інструменти – Якщо агенту на кожному кроці потрібна певна утиліта, закріпіть цей інструмент у конфігурації агента. Закріплення пропускає етап пошуку, скорочуючи затримку та споживання токенів.
  • Організовуйте за можливостями – Замість монолітного toolbox, що охоплює все підприємство, розділіть інструменти на логічні групи (наприклад, sales-tools, CRM-tools). Менші групи обмежують радіус дії помилок конфігурації та роблять результати пошуку більш цілеспрямованими.
  • Тестуйте перед розгортанням – Версії toolbox є незмінними (immutable); як тільки версія встановлена як стандартна, усі агенти починають її використовувати. Використовуйте ендпоінт для розробників, щоб ізольовано перевірити нову версію перед її впровадженням у масштабах компанії.

Ці практики стають найбільш важливими, коли кількість інструментів сягає сотень. Для одного агента з кількома утилітами прямі підключення все ще можуть бути найпростішим шляхом. Але коли команди множаться, а toolbox розширюється, централізована модель окупає себе завдяки зменшенню дублювання, посиленню безпеки та помітній економії токенів.

Підсумок: Foundry Toolbox та Tool Search дають великим ШІ-системам можливість приборкати розростання інструментів, скоротити витрати токенів до 94% і забезпечити послідовні політики безпеки — і все це шляхом додавання єдиного, добре керованого сервісного шару. Команди, які можуть дозволити собі початкове налаштування та дисципліну в роботі з метаданими, отримають більш гнучку та керовану екосистему агентів.