Zot: buduj agenty AI, nie nudne plumbling

Przyznajmy to sobie szczerze: tworzenie agenta programistycznego AI od zera to w większości przypadków lessons in frustration. Między parsowaniem streaming responses, walczeniem z autentykacją providerów, definiowaniem schematów narzędzi i implementowaniem sandboxy dla plików — nie masz nawet chwili, żeby pomyśleć o tym, co twój agent powinien właściwie robić. Cała interesująca część — logika, która wyróżnia twojego agenta — ginie pod stosem kodu plumbing, który każdy projekt musi zaimplementować.

Zot podchodzi do tego problemu bezpośrednio. Zamiast dawać ci kolejne black-boxowe rozwiązanie do konfiguracji, zot udostępnia swoje wewnętrzne komponenty jako importowalne pakiety Go. Bierzesz to, czego potrzebujesz, ignorujesz resztę i piszesz działający harness w około stu liniach kodu.

Problem 90/10 w developmentzie AI

Jeśli kiedykolwiek próbowałeś zbudować choćby podstawowego agenta kodującego, pewnie zauważyłeś tę dysproporcję. Prawdziwa wartość twojego agenta — jak analizuje kod, jaki workflow implementuje, jaką personę przyjmuje — to może 10% kodu, który ostatecznie piszesz. Reszta 90%? Parsowanie protokołów streaming, autentykacja providerów, definicje narzędzi, sandboxing, system prompts. Infrastruktura, której każdy projekt AI potrzebuje, ale nikt nie chce budować dwa razy.

Podejście zot całkowicie to odwraca. Projekt dostarcza sprawdzone w boju pakiety Go na cały ten plumbing, zorganizowane pod czystymi interfejsami. Importujesz provider client, pętlę agenta, rejestr narzędzi — cokolwiek twój harness potrzebuje — i od razu zaczynasz budować logikę swojego agenta.

Cztery bloki, nieskończone możliwości

Architektura, która to umożliwia, jest elegancko prosta. Każdy agent oparty na zot składa się z czterech głównych komponentów:

Provider Client — Łącz się z Anthropic, OpenAI, Gemini lub innym wspieranym modelem przez ujednolicony interfejs. Przełączanie między providerami to literally jedna linia kodu, bo zot normalizuje wszystko: streaming responses, wywołania narzędzi, metryki użycia. Twój kod agenta wygląda tak samo niezależnie od tego, czy używasz Claude czy GPT-4.

Tool Registry — Tutaj wyłania się osobowość twojego agenta. Zot ma gotowe narzędzia do odczytu plików, pisania treści, wykonywania poleceń bash i edycji kodu. Ale dodawanie własnych to tylko implementacja interfejsu i rejestracja. Model widzi czysty JSON schema i może wywołać twoje custom tool jak każde wbudowane.

System Prompt — Persona. Kontekst. Instrukcje mówiące modelowi, jakiego typu agentem powinien być. Zot dostarcza helpery do budowania sensownych defaults, ale masz pełną swobodę w tworzeniu dokładnie takiego system promptu, jakiego wymaga twój use case.

Agent Loop — Warstwa orkiestracji spinająca wszystko do kupy. Obsługuje cykl request/response, parsuje wywołania narzędzi, wykonuje zarejestrowane narzędzia, zwraca wyniki do modelu i zapętla się aż do zakończenia lub limitu kroków.

I tyle. Cztery bloki, twój agent działa.

Po co budować własny harness?

Zot zawiera pełny interaktywny TUI out of the box, więc możesz się zastanawiać — po co w ogóle pisać custom harness? Słuszne pytanie. Oto kiedy custom ma sens:

Zadania wsadowe i przyjazne CI — Interaktywne TUI świetnie nadają się do eksploracji, ale co z automatycznymi zadaniami? Custom harness może przyjąć prompt, wykonać się do końca i zakończyć działanie. Idealne dla CI pipelines, które potrzebują code review, generowania testów czy aktualizacji dokumentacji przy każdym pull requeście.

Osadzony behavior agenta — Chcesz możliwości agenta wewnątrz większego programu Go? Custom harness daje ci programistyczną kontrolę. Twoja główna aplikacja wywołuje agenta, otrzymuje ustrukturyzowane wyniki i kontynuuje swoją logikę.

Zamknięte narzędzia — Interaktywne TUI udostępnia elastyczny zestaw narzędzi. Wyspecjalizowany harness może ograniczyć zestaw narzędzi i sandbox dokładnie do tego, czego konkretne zadanie wymaga — ani mniej, ani więcej.

Zamrożone persony — Czasem nie chcesz konfiguracji. Custom harness może na sztywno ustawić system prompt i zestaw narzędzi pod konkretny cel, zamieniając agenta w niezawodne, powtarzalne narzędzie zamiast general-purpose chatbota.

Zrób to swoim

Prawdziwa siła tutaj to nie tylko oszczędność czasu na boilerplate. To pełna kontrola nad zachowaniem agenta. Kiedy budujesz na zot, masz dostęp do tej samej battle-tested infrastruktury, która napędza interaktywne TUI, ale kontrolujesz każdy aspekt interfejsu użytkownika. Możesz zbudować CLI z określonymi formatami output, webhook przyjmujący requesty i zwracający wyniki, usługę działającą w tle monitorującą repozytoria albo całkowicie custom TUI z własnym językiem wizualnym.

Każda linia kodu, którą piszesz, dotyczy twojego produktu, twojego workflow, twojej unikalności. Nie reimplementacji streaming parsers.

Jak zacząć

Jeśli jesteś Go developerem ciekawym agentów AI, zot reprezentuje najniższy próg wejścia do budowania czegoś realnego. Czteroblockowy szkielet, który opisałem wyżej, to wszystko, czego potrzebujesz, żeby zacząć eksperymentować. Zarejestruj potrzebne narzędzia, napisz system prompt, uruchom pętlę agenta.

Możesz mieć działający prototype zanim kawa ci ostygnie. A od tego momentu każde dodatki dotyczą tego, co czyni twojego agenta twoim.

Przestrzeń agentów kodujących AI jest wciąż na tyle młoda, że większość projektów niezależnie rozwiązuje te same podstawowe problemy. Zot pozwala pominąć tę fazę i od razu przejść do interesującej pracy: wymyślania, co twój agent powinien robić, nie jak streamingować odpowiedzi.

To jest trade worth making.

Gotowy do budowania? Sprawdź projekt zot i poeksperymentuj, jak możesz złożyć jego komponenty w coś, co odpowiada twojej wizji. Plumbing jest obsłużony — teraz idź i zrób to interesujące.