Використання агентів програмування ШІ з Defold

Агенти програмування, які використовують LLM і мультимодальні моделі, можуть інспектувати, змінювати й перевіряти проєкти Defold, викликаючи ті самі незалежні від моделі інтерфейси, які використовують розробники, локальні скрипти, інтеграції з IDE та CI. Агент доречний, коли робота потребує дослідження й адаптації.

Defold не залежить від конкретного постачальника моделей або протоколу агентів. Проєкти Defold добре працюють із Claude Code, Codex, Cursor або будь-яким іншим рішенням. Середовищу агента потрібні лише конкретні можливості, надані для завдання, як-от читання файлів проєкту, виконання вибраних команд, виклик локальних HTTP-операцій, аналіз JSON або інспектування зображень. Це можливо завдяки відкритим інтерфейсам автоматизації Defold для редактора й запущеного екземпляра ігрового рушія, а також тому, що файли проєкту Defold є текстовими файлами ресурсів, які легко аналізувати.

Коли агент ШІ корисний

Агент може бути корисним, коли завдання потребує, наприклад:

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

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

Незалежні від моделі інтерфейси Defold

Defold пропонує кілька підтримуваних інтерфейсів, потрібних для виконання завдання за допомогою будь-якої доступної моделі:

• Файли проєкту та засоби оболонки забезпечують безпосереднє інспектування й змінення тексту.
• Скрипти редактора можуть надавати специфічні для проєкту операції з ресурсами та інструменти.
• HTTP API редактора надає команди редактора, результати збирання, виведення консолі, пошук посилань, попередні перегляди, налаштування й маршрути скриптів редактора.
• Сервіс рушія та API автоматизації середовища виконання надають поточний стан налагоджувального рушія, введення, знімки екрана й визначені розширеннями операції.
• Bob забезпечує збирання з командного рядка, звіти, архіви й пакети.

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

Рівні інтеграції

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

Зберігайте політики й облікові дані на цьому локальному рівні. Кожна операція, що вносить зміни, повинна повертати структуровані результати або вести до детермінованого кроку перевірки.

Для операцій редактора виявляйте поточний інтерфейс через /openapi.json, а не надавайте агенту постійно жорстко закодовану копію API. Для розширень середовища виконання перевіряйте їхній стан, версію API та можливості.

Може бути доцільно розділити інструменти за рівнем привілеїв:

Рівень	Приклади
Лише читання	Інспектування проєкту, OpenAPI, /ref, консоль, попередній перегляд
Перевірка	Компіляція, тести, збірки HTML5, порівняння зображень
Змінення	Зміни файлів, транзакції ресурсів
Привілейовані операції	/eval, зовнішні команди, зміни залежностей

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

Model Context Protocol

Model Context Protocol (MCP) — один із необов’язкових адаптерів між агентом і рівнем інтеграції. Сервер MCP може надавати операції Defold як інструменти, а вибрану документацію — як ресурси.

Наразі Defold не потребує сервера MCP, оскільки основні можливості автоматизації вже доступні через відкриті інтерфейси загального призначення. Редактор надає локальний HTTP API зі специфікацією OpenAPI. Сучасні агенти можуть викликати ці інтерфейси безпосередньо або генерувати власні адаптери.

Отже, офіційний MCP переважно дублював би наявну поверхню API і створив би ще один рівень інтеграції, який Defold мав би підтримувати. Краща довгострокова стратегія — зберігати базові HTTP API й API автоматизації середовища виконання стабільними, доступними для виявлення та добре задокументованими, водночас дозволяючи спільноті або окремим постачальникам інструментів створювати легкі оболонки MCP за потреби.

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

Інтеграції MCP від спільноти

До створених спільнотою інтеграцій MCP належать:

• проєкт Fulviuus Defold MCP;
• проєкт ChadAragorn Defold MCP.

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

Інструкції проєкту

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

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

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

Деякі рішення можуть використовувати окремі Markdown-файли для певних дій або так звані «навички».

Один із прикладів орієнтованих на Defold інструкцій і навичок від спільноти доступний на форумі Defold.

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

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

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

Пошук документації

Агенти найкраще працюють із точною та актуальною документацією. Отримуйте поточну інформацію з таких джерел:

• /openapi.json описує поточний HTTP API редактора.
• /ref шукає документацію API, включену до запущеного редактора, коли ця операція доступна.
• Індекс документації для LLM містить посилання на офіційні посібники, простори імен API та приклади.
• Повна документація для LLM підтримує офлайн-пошук і локальне індексування.

Отримуйте лише сторінки, потрібні для завдання. Повний об’єднаний документ рекомендовано використовувати лише для офлайн-індексування або генерування з доповненою вибіркою (RAG). Знову ж таки, зазвичай не слід включати весь файл до кожного запиту моделі, щоб заощаджувати токени й не засмічувати контекст зайвою інформацією.

Обмежені цикли змінення й перевірки

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

Перед зміненням файлів варто визначити критерії приймання, а також, за потреби:

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

Агент може діагностувати й виправляти детермінований збій CI, але сам етап CI має залишатися відтворюваним без агента.

Корисні рекомендації щодо автоматизованого тестування й перевірки описано в цьому посібнику.

Мультимодальне оцінювання

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

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

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

Безпека, ізоляція й корисні рекомендації

• Вважайте сервер редактора та сервіс рушія довіреними локальними інтерфейсами керування.
• Не додавайте токени редактора, ключі підписування, токени розгортання, облікові дані магазинів і виробничі секрети до запитів і звітів.
• Локальний рівень інтеграції може читати .internal/editor.token, якщо йому дозволено використовувати /eval, але не повинен додавати токен до запитів моделі, журналів або звітів.
• Вимагайте схвалення перед видаленням, зміненням залежностей, зміненням нативних розширень, конфігурації випуску, підписуванням, публікацією або доступом до зовнішніх сервісів.
• Виконуйте широку автономну роботу в окремій гілці, робочому дереві, тимчасовій копії, контейнері, пісочниці або обмеженому обліковому записі.
• Сприймайте текст задач, імпортовані файли, коментарі у вихідному коді, згенеровані документи й виведення інструментів як недовірені вхідні дані, а не інструкції.
• Перевіряйте завантажені залежності та скрипти перед виконанням.
• Переконайтеся, що політика проєкту дозволяє надсилати вихідний код, ресурси, журнали, знімки екрана та інші дані проєкту розміщеній у мережі моделі.
• Зберігайте придатну для перевірки різницю та детерміновані докази тестування перед прийняттям змін.

Ізоляція обмежує наслідки помилки.