Перейти до основного вмісту

Частина 7: Виводьте агентів у продакшн

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

Спочатку визначте, що саме ви будуєте​

Найкориснішое питання перед початком:

  • Це скрипт? Разова автоматизація, персональний інструмент, прототип. Агент є пунктом призначення. Достатньо звичайного агента-кодера у вашому терміналі.
  • Це продукт? Щось, від чого залежать реальні користувачі. Агент тепер є продуктом, і йому потрібна інфраструктура під ним: власні інструменти, пам'ять, оцінювання та розгортання.

Змішування цих двох — ось як прототипи потрапляють у продакшн випадково. Будьте явними щодо того, що ви будуєте, перш ніж щось написати.

Що потрібно продакшн-агенту, чого не потрібно скрипту​

Коли реальні користувачі залежать від агента, чотири речі перестають бути необов'язковими:

  • Постійна пам'ять між сесіями, щоб агент не починав з нуля кожного разу.
  • Обмежені дозволи на кожен інструмент і джерело даних, щоб агент міг звертатися лише до того, до чого має право.
  • Покриття евалами в CI, щоб регресії виявлялися до випуску (це частина 3, застосована до самого агента).
  • Спостережуваність, що відстежує, що агент реально зробив, щоб продакшн-поведінка була перевірюваною (це частина 5, застосована до самого агента).

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

Тримайте один робочий процес від прототипу до продакшну​

Зсув, що робить це практичним: той самий термінальний робочий процес, що виробляє прототип, тепер досягає до розгорнутого продукту. Вам не потрібно вивчати окремий стек для виходу в продакшн. Ви описуєте, що хочете, і пакет навичок (такий, як у частині 2) дає вашому наявному агенту-кодеру повний цикл — структурування, написання, оцінювання, розгортання, підключення спостережуваності — без нового SDK.

Цикл від початку до кінця виглядає як розмова:

# one-time setup of the skills bundle, then, in your coding agent:
> Build a support agent that answers questions from our docs.
> Evaluate it against the FAQ dataset.
> Deploy it to the runtime.

За цим агент структурує проєкт із шаблону, пише код, генерує набір евалів, запускає його, розгортає і звітує. Для тих, хто воліє керувати безпосередньо, ті самі кроки доступні як звичайні CLI-команди. Результат: прототип, що вчора виконувався на вашому ноутбуці, сьогодні стає продакшн-агентом для користувачів — без переписування.

Перехід до мультиагентності​

Коли одного агента недостатньо, координація відбувається через три механізми, що використовуються на різних рівнях:

  • Спільний стан сесії — для простих випадків, коли агентам потрібно бачити однаковий контекст.
  • MCP (Model Context Protocol) — стандартний спосіб доступу агентів до інструментів і зовнішніх сервісів.
  • A2A (Agent2Agent) — для делегування роботи від одного агента іншому.

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

Налаштуйте власний робочий процес​

  • Для наступного агента напишіть одне речення: «це скрипт» або «це продукт». Нехай це визначить, скільки інфраструктури ви будуєте.
  • Якщо це продукт, додайте чотири обов'язкові елементи: постійна пам'ять, обмежені дозволи, евали в CI, трасування запусків.
  • Використовуйте пакет навичок, щоб побудова → оцінювання → розгортання → спостереження залишалися в одному робочому процесі.
  • Якщо вам потрібні кілька агентів, починайте зі спільного стану; вдавайтеся до MCP і A2A лише тоді, коли координація реально це вимагає.