ШІ експеримент

Я запросив свого агента зі штучного інтелекту в Romergo, і я не знаю, що це таке і як це назвати.

Більшість інтеграцій штучного інтелекту в програми розроблено передбачуваним чином. Продукт додає кнопку іскри, надсилає запит власній моделі та відображає відповідь на бічній панелі.

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

Мені набридло перемикатися між чатом і редактором, і мені спало на думку: а що, якби я міг цього повністю уникнути?

Я додав панель штучного інтелекту безпосередньо в редактор, але не підключив її до моделі, розміщеної на Romergo. Натомість користувач запрошує свого персонального агента ШІ до відкритого сеансу.

Агент залишається там, де він уже живе: у ChatGPT, Claude, Codex або іншому MCP-сумісному клієнті. Він зберігає свою модель, підписку, пам’ять, налаштування та доступні інструменти. Romergo надає лише робочу область, поточний контекст і спеціалізовані інструменти для редагування проекту.

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

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

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

Це починалося як експеримент

У мене не було наміру винаходити новий протокол або створювати нову категорію продуктів. Я хотів перевірити одну просту ідею: чи може особистий агент користувача не просто керувати Romergo ззовні через MCP, а й тимчасово приєднатися до живого сеансу всередині редактора?

Перша версія була експериментальною. На мій подив, це спрацювало досить добре, щоб я почав використовувати його сам.

Найкоротшу схему можна намалювати так:

Personal AI agent  <->  MCP  <->  Romergo Builder

Але важливий знак в обидва боки.

Типовий виклик MCP починається в агента: агент вирішує зв’язатися з додатком і викликає його інструмент. У моєму експерименті Ромерго також може ініціювати роботу. Користувач пише команду в Builder, Romergo розміщує її в захищеному каналі, а вже підключений агент отримує команду через MCP.

Потім агент використовує звичайні інструменти Romergo для читання або зміни проекту та повертає результат до Builder через той самий канал.

Це створює замкнутий цикл:

1. User -> Builder panel: "Replace the music in this chapter"
2. Builder -> authenticated channel: command + current page + selection
3. Personal agent -> MCP: wait for the next Builder command
4. Agent -> Romergo MCP tools: inspect and edit the project
5. Agent -> MCP channel: status, question, result, or error
6. Builder panel -> User: live response from the personal agent

Ромерго не запускає модель на жодному з цих кроків.

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

Двонаправлена ​​поведінка з’являється на рівні сеансу програми, а не через новий транспорт MCP. Ця відмінність має значення: поточну реалізацію найкраще розуміти як невеликий сеансовий контракт, побудований на основі стандартних викликів MCP.

Як агент вступає в сеанс

Builder створює тимчасовий код каналу. Користувач копіює коротку початкову підказку у свій чат AI приблизно так:

Приєднуйтесь до мого каналу Romergo Builder. Виконуйте кожну нову команду один раз, надсилайте результат або запитання назад до Builder і чекайте, поки я прямо не попрошу вас зупинитися.

Потім агент викликає інструмент MCP romergo_join_builder_channel і передає код. Це рукостискання: Romergo перевіряє сеанс OAuth, власника каналу та термін його дії, а потім повертає стан розмови та курсор останньої команди.

Далі агент викликає romergo_wait_for_builder_command. Це довге опитування, яке очікує наступної команди від редактора. Якщо нічого не надходить, агент зберігає курсор і знову починає очікувати. Якщо команда існує, вона містить:

• текст інструкції;
• ID команди;
• монотонна послідовність;
• поточний шлях у Builder;
• Ідентифікатори відкритого проекту, розділу та сцени, якщо вони є в URL-адресі;
• тип поверхні редактора та час захоплення контексту;
• вибраний користувачем текст, якщо такий є.

Весь вкладений контекст позначено як ненадійний вміст програми. Це дані для роботи, а не продовження контрольної інструкції агента.

Агент виконує завдання за допомогою наявних інструментів Romergo MCP. Наприклад, він може прочитати проект і розділ, знайти ресурси, змінити сцену, а потім перевірити збережений результат.

Під час роботи агент може викликати romergo_report_builder_event і відправити панель:

• status - короткий проміжний статус;
• question - питання, без відповіді на яке небезпечно продовжувати;
• reply — готовий результат;
• error - чіткий опис помилки.

Відповідь прив’язується до commandId, а наступна команда зчитується з останньої обробленої послідовності. Під час першого запуску API атомарно призначає команду клієнту OAuth client_id. Інший підключений агент не зможе виконати те саме завдання одночасно. Курсор допомагає продовжити роботу після тайм-ауту або повторного підключення, а одноразові підтвердження викликів певних інструментів захищені відбитком аргументу та не можуть повторно використовуватися для іншої дії.

Права належать кімнаті, а не підказці

Перед підключенням користувач бачить налаштування каналу та вибирає, що дозволено робити агенту: читати проект, редагувати контент, працювати з медіа та аудіо, публікувати чи видаляти дані. Ці налаштування можна будь-коли відкрити за допомогою шестерінки в заголовку панелі.

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

Це не просто текст у початковій підказці. Загальна серверна оболонка перевіряє область перед викликом модифікуючого інструменту MCP. Якщо ввімкнено додаткове підтвердження, Builder показує точну дію за допомогою кнопок «дозволити один раз» і «відхилити», тоді як вихідний виклик продовжує чекати рішення. Дозвіл прив’язаний до відбитка команди, інструменту та аргументу, і після виконання він більше не дійсний.

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

Що в Romergo, а що залишається у користувача

Мені подобається думати про цю архітектуру як про поділ проблем.

Ромерго забезпечує:

• редактор і візуальне робоче середовище;
• поточний проект, сторінка та вибір;
• тимчасове приміщення для двостороннього зв'язку;
• предметно-спеціальні інструменти для читання, модифікації та перевірки проекту;
• OAuth, права доступу та історія подій сесії;
• інтерфейс, у якому користувач бачить питання, прогрес і результати.

Агент користувача приносить:

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

Інтелект не належить до програми. Додаток створює місце, де цей інтелект може працювати безпечно.

Чому б не зробити звичайний вбудований копілот

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

Але тоді Ромерго також мав би стати оператором інфраструктури ШІ:

• платити за висновок або передати його вартість через план;
• підбирати моделі для користувача;
• створити власну пам'ять і персоналізацію;
• повторно підключити зовнішні служби;
• зберігати додатковий чутливий контекст;
• постійно наздоганяти можливості продуктів горизонтального ШІ.

При використанні персонального агента все це вже є на стороні користувача. Ромерго не намагається створити інший ChatGPT. Це надає ChatGPT, Claude або іншому агенту спеціалізований робочий простір і зрозумілі інструменти.

Це особливо цікаво для творчого редактора. Той самий агент може знати, як користувач пише діалог, який тон він віддає перевагу, які посилання вже обговорювалися та які зовнішні інструменти він використовує. Romergo не потрібно копіювати всю цю систему лише для того, щоб допомогти замінити один фон або переставити сцену.

Найдивніше: агент і зовні, і всередині

Агент фізично не переїжджає до Ромерго. Його модель і цикл агента продовжують працювати в оригінальному клієнті ШІ.

Але з точки зору користувача, агент присутній всередині редактора:

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

Тому вирази «ШІ всередині програми» та «ШІ поза межами MCP» тут не зовсім точні. Це скоріше тимчасова присутність зовнішнього агента в сеансі програми.

Я не перший, хто рухається в цьому напрямку

Після того, як експеримент спрацював, я почав шукати схожі підходи.

[Протокол клієнта агента] (https://agentclientprotocol.com/) дозволяє таким редакторам, як Zed і JetBrains, підключати зовнішні агенти кодування. Tidewave розміщує Claude Code, Codex та інші агенти ACP поруч із запущеною веб-програмою та передає їм контекст браузера та середовища виконання. [Клієнт агента Obsidian] (https://community.obsidian.md/plugins/agent-client) показує Claude Code, Codex і Gemini безпосередньо поряд із нотатками й автоматично додає активний документ і виділення. marimo надає зовнішньому агенту живий блокнот як спільний робочий простір.

Існують і більш загальні експерименти. AG-UI стандартизує двосторонній зв’язок між інтерфейсом користувача та серверною частиною агента. WebMCP пропонує, щоб веб-сторінки реєстрували інструменти, доступні для підключеного браузера або агента робочого столу. [Протокол програми агента] (https://agentapplicationprotocol.com/overview) описує модель, у якій програма володіє інтерфейсом користувача та інструментами домену, а зовнішній агент володіє міркуваннями, історією та інструментами загального призначення.

Тобто основна ідея вже існує в кількох формах. Але більшість реалізацій зосереджено на IDE, локальних агентах кодування або агентах, які розгортає сама компанія.

Експеримент Romergo цікавий для мене дещо іншим питанням: що станеться, якщо персональний агент користувача зможе увійти в звичайну творчу програму?

Не нова модель. Не є ключем API для моделі. Не є вбудованою програмою другого пілота. Агент, яким людина вже користується щодня.

Зручність – це лише половина проблеми

Коли зовнішній агент може слухати команди програми та змінювати проект, безпека більше не є додатковою функцією.

Виникають запитання, на які неможливо відповісти за допомогою одного екрана OAuth:

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

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

Як це назвати

Я ще не маю остаточної назви.

Принесіть свій власний ШІ зазвичай означає ваш власний ключ API або вибір моделі. Bring Your Own Agent ближче, тому що користувач приносить не лише модель, але й пам’ять, інструменти та агентський цикл. Однак BYOA не описує важливу частину експерименту: програма також може зв’язуватися з агентом і підтримувати з ним живий сеанс.

Можливо, це:

• канал живого агента;
• сеанс програми-агента;
• рівень присутності агента;
• персональний агентський міст;
• двонаправлений МКП;
• або просто успішний експеримент над існуючими ідеями.

Я не хочу придумувати новий стандарт лише для назви. По-перше, для мене важливіше зрозуміти, чи корисна така модель поза Romergo і які межі потрібні, щоб їй можна було довіряти.

Додаткам може не знадобитися власний AI

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

Можлива ще одна модель.

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

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

Але я знаю, що експериментувати – це дуже весело.

Назад до dev-блогу