GitAgent: Docker dla agentów AI, który próbuje poskromić chaos frameworków

Świat agentów AI wygląda dziś jak plac budowy bez architekta. LangChain robi swoje, AutoGen idzie w swoją stronę, CrewAI ma własne reguły, OpenAI Assistants jeszcze inne, a Claude Code gra solo. Efekt? Deweloperzy budujący autonomiczne systemy muszą z góry zakładać zakład na jednego dostawcę i jeden ekosystem, a każda zmiana decyzji oznacza przepisanie projektu od zera. Pojawił się projekt, który chce to zmienić.

Problem, który wszyscy znają, ale mało kto adresuje

GitAgent to otwartoźródłowa specyfikacja i narzędzie CLI, które proponuje coś prostego w założeniu, ale trudnego w realizacji: wspólny, niezależny od frameworka format opisu agenta AI. Idea jest analogiczna do Dockera w świecie kontenerów. Docker oddzielił aplikację od środowiska uruchomieniowego, GitAgent chce oddzielić logikę agenta od silnika jego wykonania.

Zamiast pisać kod ściśle powiązany z LangGraph, AutoGenem czy API Anthropica, deweloper definiuje agenta raz, w ustandaryzowanej strukturze katalogów repozytorium Git, a potem eksportuje go do dowolnego z obsługiwanych frameworków za pomocą jednej komendy.

Jak wygląda agent w praktyce

Struktura GitAgenta to zestaw plików i katalogów, gdzie każdy element ma ściśle określoną rolę:

• agent.yaml – centralny plik konfiguracyjny z metadanymi, dostawcą modelu i zależnościami
• SOUL.md – plik definiujący tożsamość, osobowość i ton agenta, zastępujący chaotyczne „system prompty” rozsiane po różnych plikach Pythona
• DUTIES.md – określa zakres obowiązków i ograniczeń agenta, co może robić, a czego nie
• skills/ i tools/ – katalogi z możliwościami funkcjonalnymi, gdzie „skills” to wzorce behawioralne, a „tools” to konkretne funkcje i definicje API
• rules/ – miejsce na zabezpieczenia i ograniczenia compliance
• memory/ – stan agenta przechowywany w czytelnych dla człowieka plikach Markdown, takich jak dailylog.md czy context.md

Ten ostatni punkt warto podkreślić. Zamiast zapisywać historię agenta w nieprzejrzystych bazach wektorowych, GitAgent trzyma ją w zwykłych plikach tekstowych. To nie tylko estetyczna decyzja.

Git jako warstwa nadzoru

Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl:

GitAgent trafia w bardzo realny problem. Dzisiaj większość zespołów budujących agentów AI utknęła w jednym frameworku nie dlatego, że to był najlepszy wybór, ale dlatego, że zmiana kosztuje za dużo. To klasyczna pułapka vendor lock-in, tyle że po stronie oprogramowania open source. Idea wspólnego formatu jest słuszna i potrzebna. Ale mam jedno pytanie, które zadałbym każdemu, kto myśli o wdrożeniu: kto utrzymuje specyfikację? Historia technologii pełna jest „uniwersalnych standardów”, które rozpadły się, gdy zabrakło im governance. GitAgent jest dziś projektem open source bez wyraźnego ciała zarządzającego. To może być jego największa siła, ale też potencjalna słabość. Warto obserwować, czy wokół projektu zbierze się wystarczająco duża społeczność, żeby specyfikacja faktycznie przeżyła zderzenie z produkcyjną rzeczywistością.

GitAgent robi coś, czego nikt wcześniej nie połączył w ten sposób: używa Gita jako warstwy nadzoru nad zachowaniem agenta. Każda zmiana wewnętrznego stanu agenta, aktualizacja pamięci, przyswojenie nowej umiejętności, traktowana jest jak zmiana kodu. System może skonfigurować tworzenie nowej gałęzi i Pull Requesta, gdy agent modyfikuje swój context.md lub SOUL.md.

To oznacza, że deweloper może przeglądać diff zmian w osobowości lub pamięci agenta dokładnie tak, jak przegląda zmiany w kodzie. A jeśli agent zaczyna zachowywać się nieprzewidywalnie lub dryfować od pierwotnych założeń, wystarczy git revert. Czarna skrzynka agenckiej pamięci zamienia się w audytowalny asset pod kontrolą wersji.

Eksport do pięciu frameworków

Główna obietnica GitAgenta to CLI-driven workflow eksportu. Po jednorazowym zdefiniowaniu agenta, komenda gitagent export -f [nazwa_frameworka] przenosi go do wybranego środowiska:

1. OpenAI – mapowanie do schematu Assistants API
2. Claude Code – adaptacja dla środowiska terminalowego Anthropica
3. LangChain/LangGraph – tłumaczenie logiki na grafy węzłów i krawędzi
4. CrewAI – formatowanie agenta jako uczestnika wieloagentowej „drużyny”
5. AutoGen – konwersja do konwersacyjnego agenta asynchronicznego

Compliance w sektorach regulowanych

Dla firm działających w sektorach finansowych i prawnych GitAgent oferuje wbudowane wsparcie dla regulacji FINRA, SEC i Federal Reserve przez mechanizm Segregation of Duties (SOD). W złożonych przepływach pracy często wymaga się, żeby agent inicjujący proces nie był tym samym, który go zatwierdza.

GitAgent pozwala definiować macierze konfliktów, gdzie poszczególnym agentom przypisuje się role maker, checker lub executor. Przed wdrożeniem komenda gitagent validate sprawdza konfigurację pod kątem tych reguł.

Czy to rzeczywiście „Docker dla agentów”?

Analogia do Dockera jest chwytliwa i sensowna, ale nie idealna. Docker rozwiązał problem, który był już dobrze zdefiniowany, a rynek konteneryacji miał wyraźnych liderów gotowych na adopcję standardu. Ekosystem agentów AI jest znacznie młodszy i bardziej fragmentaryczny. LangChain, AutoGen, CrewAI czy OpenAI Assistants mają własne roadmapy, własnych inwestorów i własne powody, żeby nie oddawać kontroli nad formatem opisu agentów zewnętrznemu standardowi.

GitAgent jest wart uwagi. Repozytorium projektu dostępne jest na GitHubie. Pytanie, czy wystarczy mu momentum, żeby stać się rzeczywistym standardem, czy pozostanie jednym z wielu ambitnych, ale niszowych projektów open source.