Звичайно, ось стаття, створена на основі наданої транскрипції відео, написана у стилі Ліли Гарт:
AGUI: Новий Міст до Майбутнього Агентів Штучного Інтелекту
Рік 2025 вже став роком агентів ШІ. Але, як я бачу, він також став роком протоколів агентів – таких, як MCP від Anthropic, що значно спрощує підключення інструментів до наших агентів, або A2A від Google, що робить взаємодію між агентами дуже плавною. Проте, якою б потужною не була їхня сила, все ще бракує однієї важливої частини. Бо якщо ми хочемо, щоб наші користувачі могли взаємодіяти з нашими агентами, нам потрібен інтерфейс, спосіб перетворити нашого агента на повноцінну програму. Але дотепер не було стандарту, який би дозволяв дуже легко з’єднувати наших агентів із будь-яким інтерфейсом, як це можна робити з інструментами та іншими агентами.
І ось я представляю вам AGUI. Це протокол для з’єднання ваших агентів з вашим інтерфейсом та вашими користувачами дуже стандартним способом. І, як MCP та A2A, я думаю, що це абсолютно змінить правила гри. Я познайомлю вас з AGUI та покажу, як ним користуватися. Безумовно, варто витратити час на вивчення цього протоколу прямо зараз, тому що це дійсно відсутній пазл, щоб вивести ваших агентів на наступний рівень, перетворивши їх на повноцінні програми. Тож давайте зануримося в це глибше.
Від CopilotKit до Нового Стандарту
Офіційне оголошення про AGUI було розроблено командою CopilotKit. Copilot Kit, як ви можливо знаєте – це бібліотека з відкритим кодом для створення агентних додатків. Тому є сенс, що саме вони розробили цей стандарт для з’єднання наших інтерфейсів з агентами.
Ця графіка дуже наочно показує, як це виглядає. У нас є AGUI – посередник, як MCP – між нашим додатком, побудованим на чомусь типу React, та нашими агентами ШІ, зібраними на основі Langraph, Crew AI або Pyantic AI. І це просто протокол, щоб зробити це з’єднання безперебійним, як у випадку з MCP та A2A. Це неймовірно потужно, тому що це наш спосіб з’єднати наших агентів з користувачами.
Це критично важливо, тому що більшість агентів ШІ, загалом (і мені це подобається, вони говорять про це тут) говорять про автономних агентів та агентів для спілкування. І Copilot Kit та AGUI не будуть корисними, якщо у нас просто є агент, який працює повністю автономно, просто роблячи речі за лаштунками. Але з більшістю агентів ви хочете мати якийсь спосіб, щоб користувачі працювали разом з ними. Особливо для таких речей, як “людина в циклі”, просто переконуючись, що ми все ще є частиною процесу, чим би не займався наш агент.
Тому ми майже завжди хочемо мати інтерфейс для роботи з нашими агентами. Але доти, поки у нас не було AGUI, це було не дуже легко. Існує багато проблем, пов’язаних з розробкою інтерфейсу, що з’єднується з нашим агентом, без певного стандарту.
Наприклад, на даний момент цілком очікується, що ваш агент ШІ буде видавати результат у режимі реального часу. Він має виглядати так, ніби агент друкує відповідь, як-от ви бачили в Claude або GPT. Але це не дуже просто налаштувати. Вам потрібен спосіб, щоб ваша точка доступу API, яка запускає вашого агента, передавала ці токени в режимі реального часу у ваш інтерфейс. І вам також потрібно обробити це у вашому інтерфейсі.
Іншим хорошим прикладом є оркестровка інструментів. Робота з різними інструментами, які використовуватиме ваш агент. Користувальницькому інтерфейсу часто потрібно показувати перебіг та результати використання цих інструментів. Існує багато компонентів, які входять навіть в один єдинй запуск агента, який ви хочете відобразити у своєму інтерфейсі.
Ще одна важлива річ, на якій варто зупинитися, – це те, що вони називають “розростанням фреймворків”. Я думаю, що це дуже добрий спосіб висловитися. Є так багато різних способів, як ми можемо створити наших агентів на бекенді, використовуючи Langchain, Crew AI або Mao. Є так багато різних прикладів, але всі вони працюють трохи по-різному. Нам доводиться підключати наш інтерфейс до агентів, створеним за допомогою цих фреймворків, дещо по-різному. Нам доводиться винаходити адаптери, як вони сказали, обробляти різні граничні випадки, які просто виникають при використанні цих різних фреймворків.
Але коли у нас є щось на зразок AGUI, і у нас тепер є просто один стандарт, який є посередником між інтерфейсами та цими різними фреймворками, нам тепер потрібно менше про це турбуватися у наших інтерфейсах. Все стає набагато простіше, коли ми це розробляємо. І найкраще те, що AGUI є повністю відкритим кодом, і це стандарт, де ми не покладаємось на конкретний фреймворк. Отже, як і у випадку з MCP, Anthropic створили протокол контексту моделі, але це не означає, що ми повинні використовувати Claude для нашої LLM. Те саме з AGUI. Його створив Copilot Kit, але ми можемо створити будь-який інтерфейс з будь-яким фреймворком і підключити його до будь-якого агента.
Як Працює AGUI: Погляд зсередини
Ось як це працює. У нас є наш користувач, який взаємодіє з нашим додатком, створеним на основі React. І тоді у нас є посередник, про якого я говорила. Це AGUI, який потім з’єднає нас з нашими агентами ШІ. І кожного разу, коли ми маємо якусь операцію, яку виконує наш агент, наприклад, він передає деякий текст або здійснює виклик інструменту, ми маємо ці стандартні події, які ми надсилаємо через AGUI назад у наш інтерфейс. І таким чином наш інтерфейс має дуже стандартний спосіб відображення всього, що робить агент. Це те, що вирішує багато проблем, які у нас виникають з потоковою передачею в реальному часі, оркестровкою інструментів та розростанням фреймворків. Нам тепер просто потрібно покластися на ці події, що надходять у наш інтерфейс, та відображати їх, як завгодно, використовуючи щось на зразок Copilot Kit, якщо ми хочемо полегшити розробку фактичного інтерфейсу.
Ось як працює AGUI в цілому. Але тепер я хочу перейти до практики, фактично створити повний приклад, щоб ви могли побачити це в дії.
В офіційній документації для AGUI, посилання на яку я розміщу в описі цього відео, вони розповідають як про створення агента ШІ на бекенді, який працює з цим протоколом, так і про те, як створювати інтерфейсні програми, які працюють з AGUI, щоб ми могли з’єднати наших агентів з нашими користувачами. Я проведу вас через обидва процеси.
Я пройду з вами швидкий старт та покажу вам на дуже фундаментальному рівні, як працює AGUI. І тоді я навіть покажу вам, як будувати агентів на бекенді з AGUI, як ми можемо використовувати будь-який фреймворк, який захочемо. І ця сторінка «з’єднатися з AGUI» буде основною, через яку я пройду, щоб запустити нашу демонстрацію, щоб ви могли побачити на дуже фундаментальному рівні, як працює цей протокол.
Отже, ви можете слідкувати за цим також, якщо хочете погратися з демонстрацією самостійно, зануритися в неї та просто побачити, як ви можете побудувати на основі AGUI. Є деякі передумови, які вам потрібні: Node.js та npm. А потім ми також будемо використовувати OpenAI для нашого LLM. Далі ви можете пройти ці інструкції, щоб клонувати цей репозиторій з прикладом. Ми можемо встановити все та запустити. А тоді вони також проведуть вас через основні компоненти коду.
Демонстрація в Дії: З’єднання з Реальністю
Ось ця демонстрація, яку я зараз запустила. І ви можете зробити те ж саме всього за хвилину. Це надзвичайно швидко. І ми можемо попрацювати з кількома прикладами, які вони мають тут для нас, щоб побачити AGUI в дії. І все це інтегровано з Copilot Kit. Але знову ж таки, нам не потрібно використовувати Copilot Kit з AGUI. Це просто робить речі дуже простими для нас.
Для цього першого прикладу я можу просто отримати базову відповідь від LLM. Ви можете побачити, як вона передається нам. Але це також приклад використання AGUI для інструментів інтерфейсу, оскільки ми отримуємо відповідь від агента, і це буде диктувати щось, що ми змінимо в нашому інтерфейсі. Наприклад, у цьому випадку я можу сказати змінити фон на червоний. І ми отримаємо відповідь від нашого бекенду, який наказує оновити колір фону. Погляньте на це! Ми можемо сказати, тепер змінити його на синій. І ось, швидко і просто.
І це не надто тривіальна реалізація, начебто це базовий приклад, але мати таку взаємодію між нашим бекендом та інструментами в нашому інтерфейсі – це не надто просто. Спробуємо ще один. Зробимо генеративний інтерфейс на основі інструментів. У цьому випадку ми поговоримо з нашим агентом, і результат буде інтерактивним для нас, щоб потім також змінити те, що ми бачимо тут.
Я скажу: “Створити хайку про ШІ”, і ось хайку, а потім я можу взаємодіяти з викликом інструменту в інтерфейсі тут, щоб застосувати його, і allora, він тепер оновитиме інший стан, який я маю в інтерфейсі.
Ось кілька прикладів, які показують на дуже високому рівні, як ми можемо зробити нашого агента ШІ дуже інтерактивним з викликами інструментів та всім іншим прямо в нашому інтерфейсі. І це саме та річ, яка, якщо у вас немає чогось на кшталт AGUI, буде не так просто зробити.
Інтеграція з Lutra: Розширення Можливостей
Спонсором сьогоднішнього відео є Lutra. Це дуже дружній до користувача спосіб створення автоматизації за допомогою природної мови. Ви взаємодієте з ним так само, як з чат-GTP або Claude, за винятком того, що є сотні інтеграцій, які роблять його набагато потужнішим. І воно може в реальному часі створювати інтеграції з власним кодом для роботи з цими різними сервісами. Далі всі ці інтеграції, які ви об’єднуєте для цієї автоматизації, яку ви створюєте, можна зберігати для використання в майбутніх розмовах та налаштовувати як заплановані завдання. Це дуже потужно.
Lutra нещодавно інтегрувався з MCP. Отже, ми тепер можемо додавати сервери MCP до нашої автоматизації. Після входу в Lutra ви можете перейти на сторінку власних інтеграцій та підключити сервери MCP. Ви можете підключитися до будь-якого сервера MCP, який ви створили самостійно, запущений віддалено, або використовувати будь-який з цих рекомендованих. Наприклад, я можу зайти в ASA, використовувати цей сервер, а потім мені просто потрібно авторизувати свій обліковий запис, щоб підключити його, і я можу почати використовувати сервер MCP у всіх своїх автоматизаціях Lutra.
Наприклад, я можу попросити Lutra створити для мене новий проект в АСА та помістити в нього завдання. І я надішлю це, і воно відразу ж використає сервер MCP, і воно напише власний код для використання різних інструментів на цьому сервері. Ось як я можу інтегруватися з іншими речами разом з цим сервером MCP одночасно. Тож воно буде міркувати, а потім почне діяти. Я поставлю на паузу і прийду, як тільки це буде завершено.
І ось, Lutra створив наш проект і завдання. Я навіть можу побачити це в ASA. Ось моє завдання – створити гостру курятину з манго, тепер я можу зберегти цю автоматизацію. Вона згенерувала код для неї. Я можу повторно використовувати це пізніше в майбутніх бесідах. Дуже, дуже потужно.
Тож в описі я залишу посилання на Lutra. Я б однозначно рекомендувала перевірити їх, якщо ви хочете автоматизувати купу задач дуже розмовно, просто з природною мовою.
Ядро AGUI: Ключові Компоненти
Повертаючись до їхнього прикладу в документації тут про підключення до AGUI, давайте розглянемо основні компоненти, які роблять усе це можливим. Це так важливо розуміти. І в мене ця демонстрація запущена прямо зараз, як я вам тільки що показала. Отже, я перейду в свій IDE і покажу вам цей код. Також деякі доповнення, які я зробила, щоб зробити це ще далі.
Отже, як я вже казала, ядром AGUI є всі ці події, які наш бекенд надсилає у наш інтерфейс. І тут у них є приклад.
У цьому випадку ми фактично не використовуємо велику мовну модель. Вони просто імітують те, як буде виглядати виконання агента. Але ми надсилаємо цю подію, кажучи, що запуск почався. І тоді в нас є наш ідентифікатор потоку, щоб ми могли відстежувати конкретну розмову. У нас є ID для цього поточного виконання самого по собі. Отже, ми маємо багато цих метаданих, які також передаються агенту, що дуже важливо. Щоб ми могли, наприклад, отримати історію розмови, якщо нам потрібно.
І тоді ми переходимо до того, що ми запускаємо повідомлення. Ми передаємо цю відповідь. Ось певний контент. А потім ось кінець повідомлення. І в самому кінці виконання агента ми також надішлемо цю остаточну подію, яка говорить, що запущено.
І так це виглядає, коли ми не використовуємо LLM. Але коли ми дійсно хочемо використовувати LLM, у них є приклад, який я застосувала, який веде його далі. У цьому випадку ми фактично використовуємо GPT 4.1 Mini, щоб керувати нашою розмовою. І це саме те, що ми бачили в демонстрації кілька хвилин тому. І так, ми спочатку виводимо цю подію.
Дозвольте мені збільшити масштаб, щоб вам було дуже легко це побачити. Ми виводимо нашу подію, кажучи, що запуск почався. Тоді ми використовуємо клієнт OpenAI, щоб розпочати відповідь на повідомлення від GPT4.1 Minion, і ми також даємо йому деякі інструменти для виконання таких речей, як зміна кольору фону. Тож, якщо ми хочемо змінити колір фону, LLM виведе цей інструмент, і це буде одна з речей, яку ми передамо в інтерфейс. Я детальніше зупинюсь на цьому за хвилину. Але, так, повертаючись до початку, ми вводимо всі наші повідомлення.
Тож ми отримуємо історію розмови, передану з інтерфейсу з AGUI. І тоді ми починаємо отримувати нашу відповідь. І тому ми збираємося проходити по всіх фрагментах, які ми отримуємо, оскільки ми отримуємо результат в реальному часі від GBT4.1 Mini. І ми просто збираємося виводити кожен з цих фрагментів, як тільки вони надходять. Тож тут ми повертаємо дельту, оскільки це найновіші фрагменти, які були створені. Отже, наш інтерфейс може з часом нарощувати цю відповідь, відображаючи її в реальному часі для користувача.
І тоді для будь-яких викликів інструментів, які відбуваються, ми робимо те саме, але замість того, щоб це була подія фрагмента текстового повідомлення, це є подія фрагмента виклику інструмента. Тож ми повідомляємо інтерфейсу, що всі параметри тут пов’язані з викликом інструмента, наприклад, зі зміною кольору нашого фону. І тоді, як тільки все це буде завершено, тож ми просто проходимо через цей цикл отримання всього з відповіді агента, тоді ми просто надішлемо останнє повідомлення, як ми бачили в базовому прикладі без LLM, кажучи, що тепер виконано.
Таким чином, інтерфейс знає, що він може переходити до всього, що йому може знадобитися зробити, щоб обробити речі після завершення виконання agent, наприклад, повідомити користувачу, що він може надіслати своє наступне повідомлення або будь-що інше. Тож цю подію надсилати теж дуже важливо.
І тоді у нас також є вся ідея надсилання подій про помилки, що дуже добре, щоб просто переконатися, що коли у нас є помилка в бекенді, вона не просто зависає програму, а наш інтерфейс не знає, що сталося. Ми можемо надіслати подію, яка конкретно повідомляє нашому інтерфейсу, з якою проблемою зіткнувся агент, щоб ми могли відповідним чином з цим впоратися.
Тож, так, в основному всі різні типи подій, а всього їх 16, які ми можемо надіслати. Це все, що може знадобитися нашому інтерфейсу для всього, що відбувається з нашим агентом ШІ. Це просто так могутньо, і я детальніше зупинюсь на цьому, коли збудую бекенд на Python. Але ви повинні мати змогу почати уявляти собі, що ви не просто обмежені використанням OpenAI. Як-от ви могли б використовувати будь-який LLM, будь-який фреймворк, який ви хочете, доки ви випускаєте ці стандартні події, які показують різні виклики інструментів та вихідні повідомлення тощо. Неважливо, що ви використовуєте, ви зможете це зробити за допомогою AGUI.
І тоді спосіб, яким ми використовуємо цього агента як точку доступу API, залежатиме від фреймворку, який ви використовуєте. Очевидно, що в цих прикладах вони використовують C-Pilot Kit. І тому в нашій основній сторінці React тут ми налаштовуємо цей екземпляр Copilot Kit, де ми надаємо цей URL-адрес виконання, який буде вказувати на цю кінцеву точку API, де працює цей агент з усім кодом, який я щойно показала вам.
Тож я не хочу зараз заглиблюватися в Copilot Kit. Чесно кажучи, це заслуговує на окремий підручник. Я можу зробити посібник спеціально на Copilot в майбутньому. Однозначно повідомте мене в коментарях, якщо вам це буде цікаво. Але copilot kit просто дає нам змогу налаштувати ці компоненти React для взаємодії з нашими агентами через кінцеві точки API, які реалізують такі речі, як AGUI.
І так, це наша основна сторінка. Це наш інструмент, який дає нам змогу змінювати колір фону, як ми бачили в демонстрації. І тоді ми просто розміщуємо чат-ко-пілот тут у нашому JSX, щоб у нас було це місце для спілкування з нашим агентом.
І тоді в межах маршруту для слеш API, а потім що було тут, як слеш/app/copilot kit. Це наш маршрут для цього, де ми просто використовуємо цей екземпляр середовища виконання co-pilot, яке працює для nex.js. Тож у нас є ця кінцева точка nex.js тут, де ми збираємося передавати це середовище виконання, яке визначає нашого власного агента. Ось цей клас власного агента, який відповідає саме тому, що ми налаштували тут. Власний агент, ми просто імпортуємо це в нашу кінцеву точку API, а потім його налаштовуємо.
Це те, що буде викликано, коли ми робимо цей запит на публікацію до /appi/copilot kit. Тож copilot kit виконує тут багато роботи, полегшуючи інтеграцію агента в інтерфейс. Але вам зовсім не потрібно використовувати copilot kit. Ви можете створити щось повністю самостійно, яке просто буде використовувати ці різні події, які ми отримуємо назад з нашої кінцевої точки, сумісної з AGUI, для нашого агента.
Таким чином, ми можемо переглядати текстові повідомлення та передавати їх. Ми можемо спостерігати за викликами інструментів, і ми можемо відображати їх як завгодно. Тут багато гнучкості. Незалежно від того, як ви хочете створювати свій інтерфейс або свого агента, AGUI дає вам це з’єднання. Тож ви можете використовувати все, що хочете.
З Python до Передової: Гнучкість AGUI
Наприклад, я легко змогла адаптувати цей приклад для використання бекенду Python для мого агента замість того, щоб побудувати його також на JavaScript, як інтерфейс. Отже, дозвольте мені показати вам це. Тут у мене інший екземпляр windsurf, відкритий тут, де я пройшла приклад. Якщо я повернуся до документації тут, замість сторінки «з’єднатися з AGI», перейдіть до пункту «створити з AGUI», і тоді ви зможете побачити приклад з використанням Python.
Таким чином, вони проводять вас через те, як це виглядає. Це дуже схоже на те, що ми бачили, де ми просто збираємося видавати ці різні події, як-от запуск, запуск завершено, або ось наступне текстове повідомлення. Це буде виглядати дуже схоже, але цього разу ми в Python. Ми можемо використовувати такі бібліотеки, як crew AI або pyantic AI. І я не використовую їх у цьому випадку, але ви дуже легко могли б.
І отже, у мене є ця кінцева точка fast API, розміщена просто за допомогою слеш AWP. Я отримую тут ID повідомлення. А потім я надсилаю цю подію, кажучи, що добре, я запускаю відповідь від агента, а потім я використовую GPT4.1 mini, так само, як я це робила з JavaScript. І тоді я збираюся проходити по всіх фрагментах, які я отримую назад у потоці, коли я передаю відповідь від LLM.
І я збираюся надіслати купу цих фрагментів, просто видаючи їх. І тип події для кожного з них – це просто вміст текстового повідомлення. І я також надсилаю цю дельту. Тож ми можемо скласти цю відповідь з часом в інтерфейсі. А потім просто надсилаємо кінець текстового повідомлення та завершення запуску в кінці.
Отже, це базовий приклад, який не обробляє виклик інструменту. Тож я не можу змінити фон за допомогою цього агента, як можу з тим, що в JavaScript. Але я просто хотіла показати вам на дуже базовому рівні, як ми можемо використовувати Python. Повернувшись до мого власного агента тут, я фактично заміню код повністю тим, що я створила за допомогою помічника з кодування ШІ, звичайно, щоб використовувати нашу кінцеву точку Python.
Отже, замість того, щоб мати всю логіку тут, щоб взаємодіяти з GBT4.1 Mini, я тепер збираюся викликати цю кінцеву точку, яка працює зараз у моєму терміналі. Я навіть можу показати вам це тут. Отже, якщо я відкрию свій термінал і покажу вам це тут, у мене є кінцева точка API, яка працює зараз.
Ми збираємося це вразити, а потім ми збираємося створити цей зчитувач, де ми просто будемо обробляти потік. Тож ми збираємося все відображати так само, як і тоді, коли ми реалізували все просто в JavaScript. Отже, трохи додаткового коду, щоб подбати про це. Повернення цього потоку процесу до нашого середовища виконання co-pilot kit, щоб воно могло це обробляти відповідно до протоколу AGUI.
Знову ж таки, у нашому інтерфейсі, і в мене також відкритий термінал, бо я покажу вам, що ми зараз використовуємо нашу кінцеву точку API Python з AGUI. Тож я збираюся надіслати повідомлення, наприклад: «Які найкращі фреймворки агентів ШІ», хоча воно не дасть хорошої відповіді, бо навчання перервано. Але так, ми бачимо тут, що ми зараз отримали запит на публікацію до нашої кінцевої точки. Ми отримуємо наш потік відповідей дуже-дуже добре. Це було легко адаптувати, в основному повністю змінивши нашого агента. Але він підключений до нашого інтерфейсу таким же чином.
Отже, це головне, що я хотіла вам показати. Я пройшла шлях від агента JavaScript до агента Python. І таким чином можна перейти від MRA до crew AI, що завгодно, але мені все одно не потрібно нічого змінювати в інтерфейсі. Я все ще можу взаємодіяти з агентом тим самим способом.
І якщо щось із цього здається вам складним, не хвилюйтеся. Ви не самотні. І вони надають спосіб дуже легко використовувати помічників із кодування ШІ, як-от Windsurf і Cursor, щоб допомогти вам створити з AGUI, як будувати ваших агентів і ваші бекенди, і зробити їх сумісними, і будувати ваші інтерфейси за допомогою власного коду або за допомогою такого інструменту, як copilot kit, що завгодно.
І тому ця сторінка в документації, якщо ви просто прокрутите вниз, ви побачите розробку з курсором, у них є це llm’s-fold.ext. І тому ви можете взяти це, і ви можете надати це як документацію своєму помічнику з кодування ШІ. Отже, cursor має свою вбудовану функцію документів. Ви можете просто вставити це у свій запит. Існують також сервери MCP, такі як мій crawl для AI, де ви могли б сканувати це та використовувати це як базу знань rag.
Отже, AGUI робить це дуже доступним для вас, щоб почати створювати з AGUI, підключаючи своїх агентів до своїх користувачів.
Стан AGUI: Погляд у Майбутнє
Залишилась ще одна річ, яку я хочу торкнутися, це поточний стан AGUI. Очевидно, що цей протокол абсолютно новий, і тому на даний момент він не дуже зрілий. Він точно заслуговує на те, щоб ви його досліджували, почали дізнаватися, як він працює, можливо, ще не використовуючи його буквально у всьому. Я б не пішла туди, тому що ще багато чого треба розробити. І ми бачили це з іншими протоколами, як MCP та A2A. Я маю на увазі, що A2A все ще не отримав широкого поширення. І тоді MCP почало рухатися туди, але це зайняло багато часу. У листопаді минулого року Anthropic вперше випустила MCP. Він не отримав широкого розповсюдження приблизно до березня цього року. Отже, 4-5 місяців. І основна причина цього полягала в тому, що їхня документація спочатку була не найкращою. Протокол не був найдосконалішим і ледве обробляв такі речі, як безпека. Я думаю, що ми бачимо багато цього з AGUI, принаймні на початку. Чесно кажучи, і вони роблять набагато кращу роботу, ніж MCP спочатку.
Тож, хвала їм. Я дуже вражена. І так, з ним було дуже легко працювати. І це безсумнівно робить сенс, той спосіб, як вони налаштували всі ці різні події для наших агентів і як це зв’язується з інтерфейсом.
Отже, на цьому завершується наше знайомство з AGUI. Я обов’язково буду слідкувати за цим протоколом, можливо, навіть почну інтегрувати його у свої програми. І якщо це було вам цікаво, і ви хочете заглибитися в створення повноцінних агентних додатків, обов’язково перевірте dynamis.ai. Це моя спільнота для інших ранніх користувачів ШІ, як і ви. І як частина цього я зараз створюю повний курс, де я проходжу від початку до кінця весь мій процес створення агентів, включаючи створення таких інтерфейсів для підключення ваших користувачів до ваших агентів.
І я дійсно хочу освітити AGUI на своєму каналі в майбутньому, створюючи деякі конкретні варіанти використання. Отже, якщо ви з нетерпінням чекаєте цього і оцінили цей контент, я була б дуже вдячна за лайк та підписку. І на цьому я побачусь з вами в наступній серії!
