Уявіть собі.
Ви даєте агенту п'ять інструментів та одну інструкцію.
Ваш процес повернення коштів може працювати бездоганно.
Але потім лист із підтвердженням дає збій.
Агент починає послідовність спочатку, повторюючи дію, яка вже була успішною.
Результат? Подвійне повернення коштів.
Прототип працював чудово. Продакшн-система — ні.
Проблема не в промпті.
Проблема в тому, що модель просять виконувати процес, який вона взагалі не повинна виконувати!
LLM постійно змушують займатися маршрутизацією, плануванням і обробкою помилок.
Це завдання, з якими стандартне програмне забезпечення вже справляється з ідеальною передбачуваністю.
Проте ми просимо ШІ виконувати два суперечливі завдання:
- Розуміти світ: осмислювати непередбачувані, неструктуровані дані
- Виконувати процес: оркеструвати жорстку, заздалегідь визначену послідовність подій
У першому сяє ШІ, а друге належить традиційному коду.
Коли наступний крок відомий, модель не повинна вгадувати його.
Уявіть одного автономного агента з п'ятьма інструментами та однією великою інструкцією:
→ отримати історію покупок
→ перевірити політику повернення
→ оформити повернення коштів, якщо це можливо
→ надіслати листа
→ закрити тикет
Щоб усе це спрацювало, агент має пам'ятати послідовність, перевіряти кожен результат роботи інструмента та визначати, що робити далі.
Якщо лист із підтвердженням не надійде після переказу коштів, модель намагатиметься відтворити робочий процес зі свого контекстного вікна, замість того щоб продовжити з безпечного стану виконання.
Результат — те саме подвійне повернення коштів, про яке ми згадували раніше.
Як ADK 2.0 наводить лад у хаосі
ADK 2.0 від Google вирішує цю проблему завдяки цілком новому підходу.
Він перетворює передбачувані дії на конкретні кроки робочого процесу, вбудовуючи ШІ лише там, де справді потрібна інтерпретація:
[Графік процесу повернення коштів — джерело: «Чому ми створили ADK 2.0»]
У прикладі вище отримання історії покупок, оформлення повернення коштів і закриття тикета — це звичайні програмні дії.
Аналіз скарги та підготовка персоналізованого повідомлення з підтвердженням передаються ШІ.
Результат — чудовий гібрид: фіксоване виконання в поєднанні зі сфокусованим міркуванням.
Але ви можете подумати: хіба це не просто повернення до жорсткої автоматизації?
Чи не зашиваємо ми в код власне ті робочі процеси, які мали замінити агенти?
Не зовсім.
Робочий процес визначає межі, які вже відомі.
Агенти, як і раніше, виконують частини, що потребують інтерпретації, мови чи судження.
Мета — не прибрати гнучкість, а перестати змушувати модель щоразу заново прокладати той самий шлях виконання.
Завдяки усуненню цих зайвих рішень моделі ця архітектура повністю змінює правила гри.
Той самий процес повернення коштів. Та сама модель.
Але з ADK 2.0 кількість токенів зменшилася з 5 152 до 2 265, а затримка впала з 7,2 с до 5,7 с 🔥
[джерело: «Чому ми створили ADK 2.0»]
Ця структура діє як природний фільтр, що вдвічі скорочує використання токенів.
Замість того щоб передавати всю історію, агенти бачать лише те, що їм потрібно (наприклад, агент політики бачить лише скаргу).
Переваги видно одразу:
- Менше шуму в промпті та вищий рівень конфіденційності
- Суворо обмежене виконання
- Запобіжники: модель може ухвалити хибне рішення, але ніколи не зможе вигадати власний маршрут
Фронтенд теж потребує меж: як A2UI тримає ваші інтерфейси під контролем
Це чудово. Процес повернення коштів тепер під контролем.
ADK 2.0 визначив шлях і не дозволив агенту вигадувати власну послідовність.
Але користувачеві все ще потрібен безпечний спосіб бачити результати роботи агента та взаємодіяти з ними.
Іншими словами, фронтенд теж потребує меж!
Уявіть, що кожне схвалене повернення коштів тепер потребує підпису керівника.
Агент не повинен просто генерувати текст на кшталт:
«Це повернення коштів схвалено.»
Він має показати структуровану картку, яка містить:
- суму
- транзакцію
- причину згідно з політикою
- чіткі кнопки «Схвалити/Відхилити»
Саме тут у гру вступає A2UI від Google!
Завдяки A2UI агент повертає декларативний JSON-пейлоад, а не виконуваний фронтенд-код.
Хост перевіряє цей пейлоад і рендерить лише ті компоненти, які підтримує його каталог.
Агент вирішує, яка інформація з'являється, а застосунок контролює, як вона рендериться.
👇 Нижче наведено приклади карток, відрендерених за допомогою A2UI, які демонструють, наскільки різноманітними можуть бути UI-композиції:
Демо Recipe Studio від Google на основі A2UI-over-MCP показує цю архітектуру в дії:
Джерело: блог Google Developers.
👆 Ви можете бачити, що статична форма вибору передається через MCP Resource, а динамічно згенерована картка рецепта повертається через MCP Tool.
A2UI рендерить обидва елементи нативно всередині хост-застосунку.
Помічаєте симетрію?
- ADK 2.0 обмежує те, що агент може робити на бекенді
- A2UI обмежує те, що він може створювати на фронтенді
В обох випадках модель має простір для міркувань, але лише в межах, визначених застосунком.
Повертаючись до прикладу з поверненням коштів, який ми обговорювали вище, стандартне повернення може потребувати лише простої картки схвалення.
Але спірний випадок з винятками, вкладеннями чи частковим поверненням коштів може потребувати багатшого досвіду взаємодії.
Саме тут на допомогу приходить MCP App, який забезпечує ізольований робочий простір для складних взаємодій:
→ ADK контролює, що може статися
→ A2UI робить результат видимим та інтерактивним
→ MCP Apps керують складними робочими просторами
Хочете дізнатися більше?
Ось усе, що вам потрібно, щоб дослідити ADK 2.0, A2UI та ширшу агентну платформу Google Cloud:
- ADK 2.0: https://fandf.co/4yJhcyh
- A2UI: https://fandf.co/3S1O9pe
- A2UI over MCP: https://fandf.co/45vomJ3
- Gemini Enterprise Agent Platform: https://fandf.co/4x59VY7
Для нас було честю співпрацювати з @googlecloud над цим проєктом! 🤝
Якщо ви хочете бути в курсі останніх новин про LLM, ШІ-агентів і робочі процеси, підписуйтесь на мене @datachaz, щоб отримувати щоденні інсайти.
