У Google DeepMind активно перебудовують спосіб, у який розробники взаємодіють з моделями Gemini. На сесії AI Engineer Thor Schaeff та Philipp Schmid показують новий Interactions API — поверхню, яка має замінити generateContent і зробити створення агентів та мультимодальних асистентів значно простішим. У центрі цієї трансформації — уніфікована модель контенту, вбудовані інструменти, підтримка стримінгу та системні інструкції, що визначають поведінку агентів.
Ця стаття розбирає саме ці фундаментальні елементи: як єдиний формат контент-блоків дозволяє однаково працювати з текстом, аудіо, відео, зображеннями й викликами функцій; як Interactions API поєднує Google Search з кастомними тулзами; і як системні інструкції задають «персону» кодувального агента, що вміє працювати з локальною файловою системою.
Єдиний формат контенту: від тексту до function_call в одному полі type
Одна з найпомітніших змін у Interactions API — це уніфікований формат контенту. Замість окремих структур для різних типів даних, API працює з єдиними контент-блоками, у яких головну роль відіграє поле type.
Кожен блок має type, який може представляти текст, аудіо, відео, зображення, function_call або thought_signature. І вхід, і вихід моделі описуються цими ж самими блоками. Для розробника це означає, що не потрібно перемикатися між різними схемами залежно від того, чи це текстова відповідь, зображення, чи виклик інструмента: усе проходить через один і той самий формат.
Така уніфікація вирішує одразу кілька проблем, які накопичилися в попередніх поколіннях API. Старіші інтерфейси Gemini були помітно «гуглівськими»: сильно зав’язаними на protobuf, gRPC і власні специфічні структури. Interactions API навпаки намагається виглядати максимально знайомим для веб-розробників, які вже працювали з OpenAI chat completions чи API Anthropic. Єдині контент-блоки з полем type — це крок у бік більш стандартної, передбачуваної моделі.
З практичної точки зору це спрощує і клієнтський код, і серверну логіку. Наприклад, якщо агент у відповідь повертає спочатку текст, потім виклик функції, а потім зображення, це все — послідовність блоків одного типу даних, де відрізняється лише значення type. Розробник може написати один узгоджений пайплайн обробки, а не підтримувати окремі гілки для кожного виду контенту.
Окремої уваги заслуговують типи function_call і thought_signature. Перший використовується для структурованих викликів інструментів, другий — для внутрішніх «роздумів» моделі, які можуть бути корисними для діагностики або спеціальних агентних сценаріїв. Обидва вписуються в ту саму систему блоків, не вимагаючи окремих протоколів.
Мультимодальність «за замовчуванням»: текст, аудіо, відео й зображення на вході та виході
Уніфікований формат контенту напряму пов’язаний із мультимодальністю Interactions API. Модель не обмежується текстом: API підтримує текст, аудіо, відео та зображення як у запитах, так і у відповідях.
Це означає, що розробник може будувати агента, який, наприклад, приймає відеоінструкцію, витягує з неї релевантні кадри, аналізує аудіодоріжку, а потім повертає текстове пояснення, згенероване зображення або навіть відеофрагмент. З погляду API це все — різні контент-блоки з відповідними type: audio, video, image, text.
Мультимодальність тут не виглядає як «надбудова» над текстовим ядром, а радше як базова властивість. Коли кожен блок має однакову структуру, стає простіше комбінувати модальності в одному запиті. Наприклад, можна надіслати текстову інструкцію, зображення інтерфейсу й короткий аудіокоментар користувача в одному interaction, а модель сама вирішить, як це поєднати.
Для агентів це відкриває очевидні сценарії: від віртуальних асистентів із камерою й мікрофоном до систем підтримки, які аналізують скріншоти, відеозаписи екрану чи голосові звернення. Важливо, що API не змушує розробника переходити на інші ендпоінти чи формати, щойно з’являється щось відмінне від тексту — усе залишається в межах одного інтерфейсу.
У поєднанні з єдиним форматом блоків це робить мультимодальність не стільки «фічою», скільки очікуваною нормою. Якщо модель уміє працювати з відео чи аудіо, Interactions API не створює додаткового бар’єра — розробник просто додає ще один тип контенту в запит.
Стримінг через SSE: токени й події в реальному часі
Ще один ключовий елемент Interactions API — підтримка стримінгу відповідей через Server-Sent Events (SSE). Для веб-розробників це знайомий патерн: замість чекати на повну відповідь, клієнт отримує потік подій, які надходять поступово.
У контексті агентів це має кілька важливих наслідків. По-перше, можна стрімити текст токен за токеном, забезпечуючи відчуття «живої» розмови. Інтерфейси чату, голосові асистенти, будь-які інтерактивні UI — усі вони виграють від того, що користувач бачить (або чує) відповідь одразу, а не через кілька секунд.
По-друге, через SSE можна передавати не лише текст, а й події, пов’язані з інструментами чи іншими типами контенту. Наприклад, агент може спочатку надіслати частину текстової відповіді, потім — подію про виклик функції, далі — результат цього виклику, а вже потім — фінальне формулювання. Усе це вкладається в модель «потоку подій», яку SSE добре підтримує.
Для розробників, які звикли до WebSockets, SSE пропонує простіший варіант для одностороннього стримінгу від сервера до клієнта. У випадку Interactions API це логічний вибір: більшість сценаріїв передбачає, що клієнт надсилає запит і потім лише слухає відповідь. SSE знімає частину інфраструктурних складнощів, пов’язаних із двосторонніми з’єднаннями, але при цьому дає змогу реалізувати майже ті самі UX-патерни.
У поєднанні з мультимодальністю стримінг стає ще цікавішим. Теоретично, модель може спочатку стрімити чорновий текстовий опис, а потім — посилання на згенероване зображення чи інший ресурс. Або ж надсилати статусні оновлення довготривалого завдання, перш ніж повернути фінальний результат. Interactions API закладає для цього технічну основу, не змушуючи розробника вигадувати власні протоколи поверх HTTP.
Інструменти в одному виклику: Google Search, кастомні функції та віддалені MCP
Окрема вісь еволюції Interactions API — робота з інструментами. Новий інтерфейс підтримує як вбудовані тулзи, так і кастомні, включно з віддаленими MCP-інструментами. І головне — тепер їх можна комбінувати в одному виклику.
Серед вбудованих інструментів особливо виділяється Google Search. Модель може напряму викликати пошук, отримувати актуальну інформацію з вебу й використовувати її в своїх відповідях. Раніше розробникам доводилося або покладатися на вбудовані агенти, або будувати власні обгортки навколо API пошуку. Тепер це інтегровано в сам Interactions API.
Паралельно API дозволяє визначати власні інструменти — як локальні функції, так і віддалені MCP-тулзи. MCP (Model Context Protocol) дає змогу підключати зовнішні сервіси як інструменти моделі, не вбудовуючи їх жорстко в код агента. Це особливо корисно для корпоративних сценаріїв, де потрібно інтегрувати внутрішні API, бази знань або бізнес-логіку.
Ключова нова можливість — комбінувати Google Search із кастомними функціями в одному виклику. Це була одна з найчастіших запитів від розробників: модель має вміти одночасно звертатися і до веб-пошуку, і до внутрішніх сервісів, не розбиваючи діалог на кілька окремих раундів. Тепер агент може, наприклад, спочатку уточнити загальну інформацію в Google Search, а потім викликати внутрішній інструмент для перевірки наявності товару чи статусу замовлення.
Технічно Interactions API представляє виклики інструментів як структуровані типи в результаті interaction. Коли модель вирішує скористатися інструментом, у вихідних блоках з’являється function_call із параметрами. Клієнтський код виконує відповідну функцію (локальну чи віддалену), отримує результат і повертає його назад у модель як function_result. Цей цикл може повторюватися доти, доки модель не завершить використання інструментів.
Така схема робить агентів по-справжньому «агентними»: вони не просто генерують текст, а планують дії, викликають інструменти, аналізують результати й коригують свою поведінку. І все це — в межах одного уніфікованого API, де інструменти описуються так само, як інші типи контенту.
Системні інструкції як «характер» агента: приклад кодувального асистента з доступом до файлової системи
Щоб інструменти працювали не хаотично, а в рамках зрозумілої поведінки, Interactions API спирається на системні інструкції. Це окремий шар налаштувань, який визначає «персону» агента, його цілі, стиль і правила використання інструментів.
У воркшопі цей підхід демонструють на прикладі кодувального агента. Мета — створити асистента, який уміє читати файли, записувати файли й виконувати bash-команди, працюючи з локальною файловою системою розробника. Такий агент має бути достатньо «розумним», щоб не пошкодити середовище, але водночас досить автономним, щоб виконувати нетривіальні завдання.
Системна інструкція в цьому випадку описує, ким є агент (наприклад, «досвідчений помічник-розробник»), які в нього повноваження (може читати й змінювати файли в межах проєкту, запускати певні команди), а також коли й як він має використовувати інструменти. Інструкція прямо вказує, що для взаємодії з файловою системою потрібно використовувати відповідні функції, а не вигадувати власні шляхи.
На рівні коду це поєднується з клієнтом GenAI і класом Agent, який зберігає глобальний previousInteractionId для багатокрокових діалогів. Кожен новий запит до агента надсилається разом із цим ідентифікатором, щоб серверна сторона могла відновити контекст. У відповідях модель може повертати function_call для читання файлу, запису чи виконання bash-команди. Клієнтський цикл перевіряє вихідні блоки, виконує відповідні локальні функції, додає результати назад у interaction і повторює процес, доки модель не припинить викликати інструменти.
Системна інструкція тут відіграє роль «конституції» агента. Вона задає рамки, у яких модель приймає рішення про використання інструментів, і визначає, як саме агент має поводитися з кодом, файлами й командним рядком. Без цього шару поведінка була б менш передбачуваною, а ризики — вищими.
Цей підхід добре масштабується й на інші сценарії. Для агента підтримки можна задати інструкцію, яка описує тон спілкування, політику ескалації, правила доступу до внутрішніх систем. Для аналітичного агента — пріоритети точності над швидкістю, вимоги до цитування джерел, обмеження на виконання певних дій. У всіх випадках системні інструкції стають центральним механізмом керування поведінкою.
Висновок: Interactions API як основа для наступного покоління агентів
Новий Interactions API у виконанні Google DeepMind — це не просто ще один ендпоінт для генерації тексту. Це спроба побудувати єдину, послідовну поверхню для моделей і агентів, яка враховує реальні потреби розробників: мультимодальність, інструменти, стримінг, керування станом і поведінкою.
Уніфікований формат контент-блоків із полем type дозволяє однаково працювати з текстом, аудіо, відео, зображеннями, викликами функцій і thought_signature. Мультимодальність стає базовою властивістю, а не окремою опцією. Стримінг через SSE дає змогу будувати живі, інтерактивні інтерфейси, де відповіді надходять поступово, разом із подіями інструментів.
Підтримка вбудованих інструментів, таких як Google Search, у поєднанні з кастомними функціями й віддаленими MCP-тулзами, відкриває шлях до агентів, які одночасно працюють із вебом і внутрішніми системами. А системні інструкції дозволяють формалізувати «характер» і повноваження таких агентів, як-от кодувальний асистент із доступом до локальної файлової системи.
У сукупності ці елементи роблять Interactions API логічним наступником generateContent і наближають екосистему Gemini до того, що вже стало де-факто стандартом у галузі, але з власними акцентами на мультимодальність і глибоку інтеграцію інструментів. Для розробників це означає не лише нові можливості, а й більш передбачувану, узгоджену модель роботи з AI-агентами.
Джерело
Building Conversational Agents — Thor Schaeff and Philipp Schmid, Google DeepMind