OpenCode / OpenHands (dawniej OpenDevin)

1. Przegląd koncepcji i problem systemowy

Pojawienie się komercyjnych, autonomicznych „AI Software Engineers” (takich jak Devin) zaprezentowało przyszłość rozwoju oprogramowania, w której modele samodzielnie realizują backlog zadań. Jednakże zamknięte serwisy wiążą się z poważnymi ryzykami: wysokimi kosztami (subskrypcje od $500/miesiąc), nieprzejrzystością wewnętrznych algorytmów, całkowitą niemożnością dostosowania zachowania do specyficznego stacku technologicznego firmy oraz ryzykiem wycieku tajemnic handlowych do zamkniętych chmur dostawcy.

OpenHands (dawniej OpenDevin) zostało stworzone jako darmowa, modułowa i bezpieczna alternatywa. Jest to pełnoprawny framework agentowy zdolny do autonomicznego klonowania repozytoriów, analizowania dokumentacji, odtwarzania błędów poprzez pisanie testów, modyfikowania bazy kodowej oraz wysyłania Pull Requestów. Bezpieczeństwo osiągnięto dzięki ścisłej izolacji: każda sesja agenta uruchamiana jest we własnym efemerycznym środowisku Docker (Sandboxing).

2. Taksonomia architektoniczna i model mentalny

Model architektoniczny OpenHands opiera się na szynie zdarzeń (Event Stream) oraz izolowanym wykonaniu:

┌─────────────────────────────────────────────────────────────┐
│                   ARCHITEKTURA OPENHANDS                    │
├─────────────────────────────────────────────────────────────┤
│ 1. Rdzeń EventStream (EventController i AgentController)    │
│    Centralna szyna komunikacji zdarzeń Action ➔ Observation │
├─────────────────────────────────────────────────────────────┤
│ 2. Warstwa rozumowania agenta (ReAct / CodeAct / Planner)   │
│    Obsługa modeli Claude 3.7 Sonnet, DeepSeek R1, OpenAI o1/o3 │
├─────────────────────────────────────────────────────────────┤
│ 3. Izolowane środowisko uruchomieniowe (Docker / MicroVM / gVisor) │
│    • Wykonanie: Powłoka Bash ze śledzeniem procesów w tle   │
│    • System plików: Edytory oparte na AST & montowanie workspace │
│    • Przeglądarka bez interfejsu graficznego: Chromium do testów UI i dokumentacji │
│    • Jupyter / IPython: Interaktywny REPL do analizy danych │
├─────────────────────────────────────────────────────────────┤
│ 4. Integracje Git i CI/CD: Aplikacja GitHub, automatyzacja PR │
└─────────────────────────────────────────────────────────────┘

1. Szyna zdarzeń (EventStream Architecture):
   • Wszystkie komunikacje w systemie są typizowane jako łańcuch «Akcja ➔ Obserwacja» (Action ➔ Observation).
   • Każdy krok agenta (wykonanie polecenia bash, zmiana pliku, otwarcie URL w przeglądarce) rejestrowany jest jako akcja, a odpowiedź systemu (dane wyjściowe, błąd, zrzut ekranu) – jako obserwacja.
2. Strategie rozumowania agentowego (Agent Framework):
   • Obsługuje paradygmat CodeAct – podejście, w którym agent generuje bezpośrednio wykonywalny kod Python lub Bash zamiast złożonych struktur JSON, co znacząco zwiększa precyzję skomplikowanych, wieloetapowych operacji.
3. Izolowane środowisko (Docker Sandboxing):
   • Zapewnia fizyczną izolację kodu. Repozytorium użytkownika montowane jest jako wolumin roboczy (Volume), a wszystkie binaria systemowe, zależności oraz serwery uruchamiane są wewnątrz kontenera.

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia rozwiązywania zadania inżynierskiego w OpenHands:

1. Inicjalizacja i przygotowanie środowiska: Platforma otrzymuje zadanie (np. link do GitHub Issue). OpenHands tworzy nowy kontener Docker z prekonfigurowanym środowiskiem projektu (Node.js, Python, Rust) i klonuje docelową gałąź repozytorium.
2. Eksploracja i odtworzenie defektu (Repro Test Phase):
   • Agent przeprowadza semantyczne wyszukiwanie plików za pomocą ripgrep.
   • Przed wprowadzeniem poprawek agent tworzy osobny plik testowy (Reproduction Script), który failuje na istniejącym bugu.
3. Pętla autonomicznej modyfikacji (CodeAct Loop):
   • Agent wprowadza zmiany w logice biznesowej.
   • Uruchamia testy w terminalu kontenera.
   • Otrzymuje wynik: jeśli test ponownie failuje, analizuje stack trace i formułuje nową akcję.
4. Weryfikacja przez przeglądarkę (Optional UI Inspection): Jeśli zadanie dotyczy interfejsu webowego, agent podnosi lokalny serwer dev, otwiera stronę przez headless Chromium i sprawdza wizualne renderowanie.
5. Generowanie PR i czyszczenie zasobów: Po przejściu wszystkich testów agent wykonuje git commit, pushuje nową gałąź do GitHub, otwiera Pull Request ze szczegółowym opisem wykonanej pracy i zatrzymuje kontener.

4. Praktyczne scenariusze inżynierskie w produkcji

01. Zautomatyzowany nocny worker backlogu (Automated Bug Triaging)

Podłączenie OpenHands do repozytorium przez GitHub Actions / Webhooks:

• Przy przypisaniu etykiety needs-ai-fix do ticketu platforma rozwinia kontener i przypisuje agentowi rozwiązanie zadania.
• Do rana zespół otrzymuje 5 gotowych Pull Requestów z przechodzącymi testami, przygotowanych do finalnego code review przez ludzi.

02. Całkowicie bezpieczne testowanie niepewnego kodu zewnętrznego

Audyt bezpieczeństwa zewnętrznych bibliotek open-source lub podejrzanych skryptów:

• Agent eksploruje repozytorium, uruchamia statyczne analizatory oraz testy obciążeniowe.
• Dzięki piaskownicy Docker próby połączenia się zewnętrznego kodu z systemem hosta lub pobrania złośliwego oprogramowania są całkowicie blokowane.

03. Masowa aktualizacja mikrousług firmowych

Konieczność zaktualizowania konfiguracji Dockerfiles lub Helm-charts w 40 mikrousługach:

• OpenHands kolejno podnosi izolowane środowisko dla każdej mikrousługi, aplikuje zmiany, weryfikuje sukces lokalnego buildu kontenera i publikuje PR w odpowiednim repozytorium.

5. Pułapki, typowe błędy i bezpieczeństwo

• Niebezpieczeństwo montowania socketu Dockera hosta: Przy wdrażaniu OpenHands niezwykle niebezpieczne jest przekazywanie socketu /var/run/docker.sock do wnętrza kontenera bez dodatkowych zabezpieczeń (Docker-out-of-Docker). Daje to agentowi dostęp root do maszyny hosta i niweluje korzyści z piaskownicy.
• Wymagania dotyczące zasobów obliczeniowych: Równoległe uruchamianie kilku agentów w Dockerze wymaga dużej ilości pamięci RAM (od 16–32 GB) oraz wydajnego procesora; w przeciwnym razie system może ulec awaryjnemu zamknięciu z powodu OOM (Out Of Memory).
• Nieskończone zużycie tokenów przy awarii środowiska: Jeśli w kontenerze brakuje systemowego kompilatora lub sieć jest uszkodzona, agent może zużyć setki tysięcy tokenów w daremnych próbach instalacji brakującego pakietu. Zawsze konfiguruj timeouty sesji.
• Pozostawione „sieroce” kontenery: W przypadku awaryjnego zatrzymania głównego procesu platformy tymczasowe kontenery oraz utworzone woluminy mogą pozostać w systemie, stopniowo zapełniając przestrzeń dyskową serwera.