OpenCode / OpenHands (раніше OpenDevin)(Відкрита платформа автономної інженерії OpenHands)

1. Огляд концепції та системна проблема

Поява комерційних автономних «AI Software Engineers» (на зразок Devin) продемонструвала майбутнє розробки, де моделі самостійно закривають беклог задач. Проте пропрієтарні сервіси несуть серйозні ризики: висока вартість (підписки від $500/місяць), закритість внутрішніх алгоритмів, повна неможливість налаштувати поведінку під специфічний внутрішній стек компанії та ризик витоку комерційної таємниці у закриті хмари вендора.

OpenHands (раніше OpenDevin) створено як вільну, модульну та безпечну альтернативу. Це повноцінний агентний фреймворк, який здатний автономно клонувати репозиторій, аналізувати документацію, відтворювати баги через написання тестів, змінювати кодову базу та пушити Pull Request. Безпека досягається за рахунок суворої ізоляції: кожна сесія агента запускається у власному ефемерному Docker-середовищі (Sandboxing).

2. Архітектурна таксономія та ментальна модель

Архітектурна модель OpenHands базується на шині подій (Event Stream) та ізольованому виконанні:

┌─────────────────────────────────────────────────────────────┐
│                   OPENHANDS ARCHITECTURE                    │
├─────────────────────────────────────────────────────────────┤
│ 1. EventStream Core (EventController & AgentController)     │
│    Центральна шина комунікації подій Action ➔ Observation   │
├─────────────────────────────────────────────────────────────┤
│ 2. Agent Reasoning Layer (ReAct / CodeAct / Planner)       │
│    Підтримка Claude 3.7 Sonnet, DeepSeek R1, OpenAI o1/o3   │
├─────────────────────────────────────────────────────────────┤
│ 3. Isolated Sandbox Runtime (Docker / MicroVM / gVisor)     │
│    • Execution: Bash shell з відстеженням фонових процесів  │
│    • File System: AST-based editors & workspace mounting    │
│    • Headless Browser: Chromium для UI-тестів та документації│
│    • Jupyter / IPython: інтерактивний REPL для аналізу даних │
├─────────────────────────────────────────────────────────────┤
│ 4. Git & CI/CD Integrations: GitHub App, PR Automation      │
└─────────────────────────────────────────────────────────────┘

1. Шина подій (EventStream Architecture):
   • Усі комунікації в системі типізовані як ланцюжок «Дія ➔ Спостереження» (Action ➔ Observation).
   • Будь-який крок агента (виконання bash-команди, зміна файлу, відкриття URL у браузері) записується як дія, а відповідь системи (вихідні дані, помилка, скріншот) — як спостереження.
2. Агентні стратегії міркування (Agent Framework):
   • Підтримує парадигму CodeAct — підхід, де агент генерує безпосередній виконуваний Python- або Bash-код замість складних JSON-структур, що суттєво підвищує точність складних багатокрокових операцій.
3. Ізольоване середовище (Docker Sandboxing):
   • Забезпечує фізичну ізоляцію коду. Репозиторій користувача монтується як робочий том (Volume), а всі системні бінарники, залежності та сервери запускаються всередині контейнера.

3. Технічний пайплайн та внутрішня механіка

Життєвий цикл вирішення інженерного завдання в OpenHands:

1. Ініціалізація та розгортання оточення: Платформа отримує завдання (наприклад, посилання на GitHub Issue). OpenHands створює новий Docker-контейнер із попередньо налаштованим середовищем проекту (Node.js, Python, Rust) та клонує цільову гілку репозиторію.
2. Дослідження та відтворення дефекту (Repro Test Phase):
   • Агент здійснює семантичний пошук файлів за допомогою ripgrep.
   • Перш ніж вносити виправлення, агент створює окремий тестовий файл (Reproduction Script), який падає на існуючому багу.
3. Цикл автономної модифікації (CodeAct Loop):
   • Агент вносить зміни до бізнес-логіки.
   • Запускає тести в терміналі контейнера.
   • Отримує результат: якщо тест знову падає, аналізує стек виклику і формує нову дію.
4. Браузерна перевірка (Optional UI Inspection): Якщо задача стосується веб-інтерфейсу, агент піднімає локальний dev-сервер, відкриває сторінку через headless Chromium і перевіряє візуальне відображення.
5. Генерація PR та очищення ресурсів: Після проходження всіх тестів агент робить git commit, пушить нову гілку на GitHub, відкриває Pull Request із детальним описом виконаної роботи і зупиняє контейнер.

4. Практичні інженерні сценарії в продакшені

01. Автоматизований нічний беклог-воркер (Automated Bug Triaging)

Підключення OpenHands до репозиторію через GitHub Actions / Webhooks:

• При призначенні на тікет мітки needs-ai-fix платформа розгортає контейнер і призначає агенту вирішення задачі.
• До ранку команда отримує 5 готових Pull Requests із пройденими тестами, готових до фінального рев'ю людьми.

02. Повністю безпечне тестування ненадійного зовнішнього коду

Аудит безпеки сторонніх open-source бібліотек або підозрілих скриптів:

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

03. Пакетне оновлення мікросервісів компанії

Необхідність оновити конфігурацію Dockerfiles або Helm-чартів у 40 мікросервісах:

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

5. Підводні камені, типові помилки та безпека

• Небезпека монтування хостового Docker-сокета: При розгортанні OpenHands вкрай небезпечно прокидати сокет /var/run/docker.sock усередину контейнера без додаткового захисту (Docker-out-of-Docker). Це дає агенту root-доступ до хостової машини і нівелює пісочницю.
• Вимоги до обчислювальних ресурсів: Паралельний запуск кількох агентів у Docker вимагає великого обсягу оперативної пам'яті (від 16–32 ГБ RAM) та потужного процесора, інакше система може зазнати аварійного завершення через OOM (Out Of Memory).
• Нескінченне споживання токенів при збої середовища: Якщо в контейнері відсутній системний компілятор або зламана мережа, агент може витратити сотні тисяч токенів у марних спробах встановити відсутній пакет. Завжди налаштовуйте таймаути сесій.
• Залишені «осиротілі» контейнери: У разі аварійної зупинки головного процесу платформи тимчасові контейнери та створені томи можуть залишатися в системі, поступово забиваючи дисковий простір сервера.