Агент будує агента: методологія перевірюваної автоматизації

Професія як прихована мова

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

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

Від запису до змісту

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

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

Фабрика агентів, а не модель, що самовдосконалюється

«Агент будує агента» не означає модель, яка сама пише код, сама себе екзаменує й оголошує готовою. Це поділ праці та повноважень. Агент-розробник створює безпечні probes, recorder, схеми даних, валідатори й тести, але спостерігає за оператором, а не керує діагностичним застосунком. Мультимодальний агент-спостерігач описує тип екрана, активний шар, текст, контролери, модальні вікна та невизначеність. Куратор перевіряє архіви, пов’язує події та знаходить пропуски; аналітик виділяє граф станів і рішень, а не макрос.

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

Перенести правило, а не маршрут

Цінністю є перевірювана траєкторія: стан, дозволена ціль, крок, результат, підтвердження та межа застосовності. Замість правила «натиснути координату X» виникає умовне правило: якщо вибрано цей блок, у ньому є ця помилка, екран стабільний, а попередню гілку закрито, можна запропонувати дію з обмеженого набору. Інакше система питає людину або безпечно зупиняється. Модель може запропонувати намір, але він не стає дією, доки не зіставлений із доступним станом і дозволеною навичкою.^saycan

Модель передбачає, система дозволяє

Модель розпізнає ситуацію, пропонує варіанти й позначає невизначеність. Дію з наслідками має дозволити код і поточний стан. Шар повноважень перевіряє свіжість спостереження, відповідність наміру одній дії, дозволену операцію, відсутність суперечних умов і підтвердження після виконання. Якщо доказів недостатньо, правильний результат — ask human або safe stop, а не здогад.

Агент перевіряє агента

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

Межі автоматизації та права

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

Запис досвіду є також обробкою даних. Потрібно визначити мету, обсяг, зберігання, доступ, анонімізацію й розділення первинних доказів та дослідницьких посилань. Принципи GDPR, зокрема мінімізація даних і privacy by design, впливають на архітектуру від початку.^gdpr AI Act додає вимоги прозорості та оцінювання ризику; кваліфікація залежить від intended purpose, функції й контексту.^ai-act Роз’яснення Data Act щодо даних транспортних засобів є галузевими та не переносяться автоматично на інші сфери.^data-act

Обмеження та статус

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

Інструменти AI допомагали зі структурою та редакцією. Автор перевіряє факти, висновки й опубліковану редакцію та несе за неї редакційну відповідальність.

Джерела

1. Brown, T. B. et al. Language Models are Few-Shot Learners, 2020.^few-shot
2. Ahn, M. et al. Do As I Can, Not As I Say: Grounding Language in Robotic Affordances, 2022.^saycan
3. Brohan, A. et al. RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control, 2023.^rt2
4. Regulation (EU) 2016/679 (GDPR), статті 5 і 25.^gdpr
5. Regulation (EU) 2024/1689 (AI Act), статті 4 і 50.^ai-act
6. European Commission, Guidelines on transparency obligations under Article 50 of the AI Act, 2026.^{ai-transparency}
7. European Commission, Guidance on vehicle data, accompanying the Data Act, 2025.^data-act