Terminalowy workflow agentów AI (Herdr, Claude Code, Termux) | Blog Edukey

Mój terminalowy workflow z agentami AI do programowania obejmuje cztery komputery i telefon, obsługuję go z jednego terminala i nie przerywa go ani zamknięcie laptopa, ani restart serwerów, ani to, że idę spać. Graficznego dashboardu nie ma w nim wcale. Poniżej opisuję narzędzia, kilka konfiguracji, koszty, wpadki i to, jak radzę sobie z limitami, w wersji z listopada 2026, na której codziennie wykonuję prawdziwą pracę.

TL;DR

Herdr w WezTerm to mój kokpit do pracy z agentami. Każdy panel pokazuje, czy jego agent pracuje, jest zablokowany czy skończył, a sesje żyją na serwerze, więc zamknięcie laptopa niczego nie zmienia.
Claude Code to mój główny CLI i zarazem orkiestrator: gdy zadanie lepiej pasuje do Codex, Grok, OpenCode albo Antigravity, deleguje je tam przez własny skill.
Aliasy dostawców (ccz = Z.ai, cxaz = Azure) kierują jeden CLI na model innego dostawcy. Zamiast zatrzymywać pracę po wyczerpaniu limitu subskrypcji, kieruję ją do innego dostawcy.
Termux + Tailscale dają mi na telefonie dokładnie te same możliwości co na komputerze. Dużo lepsze niż aplikacje od Claude czy ChatGPT.
Zmiany sprawdzam w Fresh, edytorze działającym w terminalu, a diffy oglądam w lazygit.
Bez strachu powierzam agentom realne zadania, bo Restic robi snapshoty co 2-3 godziny na każdej maszynie.
Limity mam opanowane: ChatGPT Pro nie ma okna 5-godzinnego, a gdy skończy się limit Claude, monitor wznawia sesję po jego odnowieniu.

Poniżej mój faktyczny pulpit, czyli dwa workspace'y Herdr obok siebie. Po lewej Claude Code pracuje nad projektem strony internetowej, a pod nim działa lazygit; po prawej Codex robi review pull requesta. Pasek boczny pokazuje wszystkie nazwane workspace'y i to, czym w tej chwili zajmuje się każdy agent. Jeden z nich nazywa się dosłownie "T3 Herdr Orca Paseo Zed" i jest pamiątką po sesji, w której ten zestaw porównywałem z alternatywami z graficznym interfejsem.

Zdjęcie do artykułu: Mój terminalowy workflow z agentami AI: Herdr + Claude + Termux

Najpierw flota maszyn, bo od niej zależy cała reszta

Zanim przejdę do narzędzi, kilka słów o sprzęcie. Cały układ działa dlatego, że z moich głównych maszyn dostanę się przez SSH do pozostałych, a trzy z nich nigdy nie zasypiają:

Laptop Dell Vostro 7500 z Ubuntu i KDE Plasma. To moja główna maszyna i jedyne miejsce, z którego mam pełen dostęp do narzędzi i CLI (np. gh, az czy gcloud).
Windows 365 Cloud PC (8 vCPU EPYC, 32 GB), na którym część linuksowa w WSL uruchamia agentów 24/7. Tu lądują ciężkie zadania.
Leciwy HP Spectre x2 (tableto-laptop) z procesorem Intel m3, na którym działa Omarchy. Jak na dzisiejsze standardy jest wolny, a mimo to bez problemu działają na nim autonomiczni agenci OpenClaw 24/7.
VPS w Hetznerze, na którym przez Coolify hostuję aplikacje swoje i klientów.
Samsung Galaxy S24 Ultra z Termuxem, czyli pełnym linuksowym środowiskiem użytkownika, a nie tylko podglądem sesji przez aplikacje.

Na tej samej liście hostów SSH jest też flota rodzinna, czyli HP ProBook żony i komputer córki, więc kiedy coś się tam psuje, naprawiam to z terminala, zamiast zabierać im urządzenie. W praktyce opiera się to na osobnych kluczach SSH dla każdego urządzenia, sieci mesh na LAN i Tailscale, dzięki której nic nie przechodzi przez publiczny internet, i dyscyplinie. Więcej o kopiach zapasowych piszę niżej.

SSH celowo nie działa każdy z każdym. Z moich głównych maszyn, także z telefonu, dostanę się do każdej innej, ale w drugą stronę już nie. Na laptopie z Omarchy pracują autonomiczni agenci, więc SSH wyłącza się tam po godzinie: agenci z tej maszyny nie dostaną się do mojego laptopa bez mojej zgody. Agenci działają tam, gdzie ich skieruję, a na komputery rodziny przez SSH loguję się ja, nie flota agentów.

Herdr: tmux, który wie, czym jest agent

Herdr instaluje się jedną linijką (curl -fsSL https://herdr.dev/install.sh | sh; działa też brew i nix) i daje multiplekser terminala, który rozpoznaje agentów do programowania uruchomionych w panelach. Sam projekt przedstawia się raczej jako agent runtime niż multiplekser i to uczciwy opis, bo sesje żyją na serwerze działającym w tle, a nie w oknie terminala. Gdy agentów jest więcej niż dwóch, ma to znaczenie:

Każdy rozpoznany panel agenta zgłasza swój stan: working, blocked, done albo idle (oraz unknown, gdy Herdr nie potrafi go sklasyfikować). Pasek boczny pokazuje ten stan dla każdego agenta i zbiorczo dla całego workspace'u. Przy sześciu agentach koniec z przeskakiwaniem alt-tabem między identycznymi promptami tylko po to, żeby znaleźć tego, który czeka na Ciebie.
Sesje żyją na serwerze, nie w oknie terminala. Zamykasz WezTerm i laptopa, wracasz do domu, a panele pracują dalej; otwierasz nowego klienta na dowolnej maszynie i jesteś z powrotem w tej samej sesji.
Restart samego serwera Herdr zabija procesy, ale nie pracę. Panele z integracją sesji uruchamiają się ponownie i wznawiają rozmowy: Claude Code przez --resume, Codex na podstawie identyfikatora sesji. Zwykłe panele powłoki otwierają się jako nowe powłoki. Restartowałem już serwery, a Claude i Codex kontynuowały wątki dokładnie w miejscu, w którym kończył się transkrypt.
W jednym workspace'ie mieszczą się obok siebie agenci, zwykłe powłoki SSH i inne aplikacje TUI (lazygit, htop). Trzymam jeden workspace na urządzenie, a w nim pasek kart. Jeden widok obejmuje całą maszynę.

Dwóch wygodnych konfiguracji bym nie pominął: nazw oraz opisu bieżącego zadania w pasku bocznym. Agent uruchomiony przez Herdr dostaje unikalną nazwę, którą zachowuje przy zmianie panelu (herdr agent start reviewer --kind codex --pane <pane-id>, wywołane z dostępnego panelu powłoki). Workspace'y można też przemianować, żeby karty przestały być anonimowe. Robi się to z menu kontekstowego pod prawym przyciskiem myszy, a hook w Claude Code potrafi automatycznie nadać workspace'owi nazwę na podstawie zadania:

1herdr workspace rename <workspace-id> my-task-name
Bash / Shell

Opis zadania bierze się z tytułu terminala, który agenci ciągle aktualizują (Claude Code wpisuje tam bieżące zadanie). Dodaj więc ten tytuł jako osobny wiersz paska bocznego w ~/.config/herdr/config.toml:

1[ui.sidebar.agents]
2rows = [["state_icon", "machine", "workspace"], ["terminal_title_stripped"]]
TOML

W drugim wierszu każdej pozycji widać teraz na żywo treść zadania, na przykład "Review PR #210 and verify data migration across repos". Myślałem, że do tego potrzebuję graficznego dashboardu, a w większości wystarczył ten jeden wiersz.

Sam z tmux prawie nie korzystam, Herdr w zupełności wystarcza. Długich zadań nigdy nie uruchamiam bezpośrednio w sesji SSH, bo zerwane połączenie zabija agenta. Gdy agent deleguje pracę do innego CLI, otwiera nazwany workspace w Herdr i uruchamia w nim zadanie z plikiem logu:

1herdr workspace create --label "codex: nightly review" --cwd ~/DEV/Projects/app --no-focus
2herdr pane run <pane-id> "codex exec --sandbox workspace-write 'do the thing' 2>&1 | tee ~/logs/nightly-review.log"
Bash / Shell

Każda delegowana sesja pojawia się w moim pasku bocznym Herdr, więc widzę, co robi każdy agent. Po zapisaniu wyniku agenci sami zamykają swoje workspace'y i zostaje mi tylko to, co jeszcze ważne. Po tmux agenci sięgają sami tylko sporadycznie, przy pojedynczych zadaniach.

Claude Code jako główny CLI (i szef pozostałych)

Claude Code to mój ulubiony CLI i używam go do mniej więcej 80% codziennej pracy. Nie jest jedyny: regularnie korzystam też z Codex i OpenCode, czasem z Antigravity albo Grok, głównie po to, żeby oszczędzać limit, gdy w Claude się skończy. Claude Code pełni też rolę orkiestratora. Moim codziennym narzędziem jest Opus: planuje i deleguje, dużą część wykonania przejmują agenci CLI na Sol 6.1 przez Codex, czasem subagent na haiku 5.5. Własny skill uczy Claude Code, kiedy i jak delegować pracę do innych agentów CLI.

Obecny podział ról to efekt miesięcy dostrajania. W pierwszych wersjach zrzuty ekranu oceniał Antigravity, aż pewnego dnia zgłosił trzy błędy CSS, których nie było. Od tamtej pory obowiązuje zasada: zrzuty ekranu idą do Codexa, research do Antigravity.

Claude Code (Opus) planuje, decyduje, przegląda i weryfikuje. Pisze briefy, rozdziela zadania, czyta diffy i sprawdza poprawność pracy. Kieruje pracą, zamiast stukać w klawiaturę.
Codex (gpt-5.6 Sol przez codex exec) to główny programista: implementacja, refaktoryzacje, seryjne, powtarzalne zmiany. Tylko jemu ufam przy ocenie zrzutów ekranu.
Grok (grok-4.6 przez CLI xAI) to szybki koń pociągowy do mechanicznych serii zadań i masowych edycji. Przejmuje też nadmiar pracy, gdy w połowie sprintu Codex wyczerpie limit.
OpenCode (GLM przez opencode) dostaje zadania, w których liczy się wyczucie: UI, CSS, teksty marketingowe. GLM-5.3 okazał się na tyle dobry w kodzie, że dziś jest pełnoprawnym pierwszym wyborem także do implementacji. Wyłącznie tekst, nigdy obrazy.
Antigravity (agy, Gemini) robi research, bo opiera wyniki na wyszukiwarce Google i jako jedyny lokalny CLI ma do niej prawdziwy dostęp. Przestałem mu powierzać ocenę zrzutów ekranu tego dnia, gdy zgłosił trzy błędy CSS, których nigdy nie było w pliku.
Do naprawdę trudnych problemów mogę też sięgnąć po najmocniejszy model, głównie Fable lub Argon, rzadko Astra 6. Nigdy domyślnie, bo dużo szybciej zjada limit.

Całość jest tania dzięki aliasom dostawców. Alias to tylko parę zmiennych środowiskowych (base URL i klucz) albo profil CLI, który kieruje to samo narzędzie do innego dostawcy:

1# the shape of it - same binary, different backend
2alias ccz='...env vars... claude'      # Claude Code on the Z.ai GLM coding plan
3alias cxaz='codex --profile azure'     # Codex on Azure-hosted models
Bash / Shell

Wybór modelu do zadania to więc kwestia aliasu w powłoce, a nie decyzja zakupowa. Te same aliasy pilnują też prywatności: zadanie, które dotyka danych klientów, trafia do modeli wdrożonych w Azure w UE. Ta zasada jest zapisana w skills, które czytają agenci, a cały wzorzec opisałem w osobnym artykule: AI Agent Data Privacy: How We Let Coding Agents Touch Client Work Safely.

Praktyczny szczegół ze zrzutu ekranu: kiedy pisałem ten artykuł, pasek statusu pokazywał 80% tygodniowego limitu Claude. Nie przeszkadza mi to, a jak radzę sobie z limitami, opisuję niżej.

Ile mnie to kosztuje

Wszyscy o to pytają, więc od razu liczby. Subskrypcje kosztują mnie około $160 miesięcznie:

ChatGPT Pro za $100,
Claude Pro i Google AI Pro, każda po mniej więcej $20,
Grok w ramach X Premium za około $10,
GitHub Copilot za $10,
GLM coding plan od Z.ai w wersji Lite, kupiony na promocji za $25 rocznie. Służy mi od miesięcy i daje więcej tokenów niż niektóre plany za $20 miesięcznie.

Do tego dochodzi mniej więcej $100 miesięcznie za API (modele hostowane w Azure, automatyzacje, mój autonomiczny agent). Pokrywają to kredyty z programu partnerskiego Microsoftu, więc to dotacja, a nie zerowy koszt. Sprzęt, licencja Cloud PC i przestrzeń na dane to kolejne pozycje: ta lista pokazuje rachunek za narzędzia, nie całkowity koszt posiadania.

Skills: uczysz agentów raz, korzystają wszędzie

Skill do delegowania to jeden z około dwudziestu własnych skills. Trzymam je w prywatnym repozytorium git i instaluję na każdym urządzeniu przez skills.sh:

1npx --yes skills@latest add <owner>/<repo> --skill <name> -g
Bash / Shell

To jedno polecenie instaluje skill we wspólnym magazynie na poziomie użytkownika i tworzy dowiązania symboliczne dla każdego agenta CLI, który czyta skills: Claude Code, Codex, OpenCode i pozostałych. Po merge'u robię aktualizację i każdy agent na każdej maszynie ma nową wiedzę. Sam skill to zwykły plik Markdown z instrukcjami (opcjonalnie ze skryptami), więc najtaniej zapisać w nim raz, jak się u nas robi pewne rzeczy, zamiast tłumaczyć to każdemu agentowi w każdej sesji.

Jeśli tej samej zasady potrzebuje agent na VPS i agent na laptopie, zasada trafia do repozytorium, a nie do czyjejś historii promptów. W moim repo są na przykład skills o tym, jak bezpiecznie pracować na Cloud PC, jak rozdzielać pracę między modele, jak pisać artykuły na blog Edukey (szkic tego artykułu powstał z pomocą tego skilla) i jak zrobić audyt telefonu, niczego w nim nie psując. Tak wygląda typowa zasada, prosto z mojego skilla do delegowania:

Zachęć delegata do zgłaszania zastrzeżeń. Poproś agenta w briefie: "jeśli się nie zgadzasz, przedstaw argumenty przeciw tej decyzji". Wtedy pokaże, co zyskujesz i z czego rezygnujesz, zamiast przemilczeć ten kompromis.

Beads i Obsidian: tablica zadań i pamięć

Bez wspólnego stanu praca wielu agentów się rozsypuje, dlatego agenci dostają porządny system zarządzania projektami:

Beads to tracker zadań, coś jak Jira dla agentów. Jedna wspólna baza dostępna przez Tailscale, obsługa przede wszystkim z CLI (bd create, bd update <id> --claim, bd note, bd close), a każdy agent na każdym urządzeniu pracuje na tych samych zgłoszeniach. Priorytety, zależności, notatki o postępach i pytania w rodzaju "sprawdź to przed zamknięciem" siedzą w trackerze, a nie w historii czatu. Moja zasada: jedno zgłoszenie na jeden rezultat, a agent, który skończy bez walidacji, nie może go zamknąć.
Obsidian to baza wiedzy dla ludzi i agentów: cele, plany, briefy, post-mortemy, instrukcje. Dane osobowe klientów nigdy tam nie trafiają. To twarda zasada; te dane leżą w SharePoint, a pracują na nich modele hostowane przez Microsoft.

Synchronizacja jest celowo nudna i wielowarstwowa. Syncthing na bieżąco przenosi treść notatek między urządzeniami, a git co noc robi snapshot vaulta z dokładnie jednego urządzenia, czyli z Della. Wszędzie indziej git działa tylko do odczytu, bo dwa urządzenia commitujące do repozytorium synchronizowanego przez Syncthing to prosta droga do jego uszkodzenia. Co godzinę rclone wysyła kopię na Google Drive, a po stronie Windowsa kopie robi OneDrive. Każda z tych warstw raz mnie zawiodła i właśnie dlatego jest ich kilka.

Telefon to pełnoprawne stanowisko pracy

Kiedy narzędzie z GUI reklamuje się hasłem "steruj agentami z telefonu", wzruszam ramionami. Na przystanku autobusowym mogę naprawić VPS tymi samymi poleceniami, które wpisałbym przy biurku.

Termux i Tailscale na S24 Ultra dają mi te same sesje Herdr co na komputerze. Sam Herdr działa na stale włączonych maszynach, a telefon uruchamia jego klienta połączonego przez SSH z tymi samymi serwerami sesji: te same karty, ci sami agenci, te same stany, pełny dostęp do CLI. Żadna aplikacja towarzysząca ani dashboard tylko do odczytu. Telefon łączy się z każdą maszyną, a z moich głównych maszyn dostanę się przez Tailscale do Termuxa na telefonie.

Oczywisty zarzut dotyczy pisania. Odpowiedzią po obu stronach, na telefonie i na komputerze, jest dyktowanie:

Na telefonie prompty dyktuję przez klawiaturę FUTO z lokalnymi modelami mowy. Wszystko dzieje się na urządzeniu, bez wycieczki do chmury, a techniczne słownictwo rozpoznaje lepiej, niż się spodziewałem.
Na komputerze większość promptów dyktuję lokalnie przez handy.computer z modelami Whisper.

Do długich, precyzyjnych promptów mam jeszcze trzeci sposób, poza dyktowaniem. W prompcie Claude Code skrót ctrl+g przekazuje treść do $EDITOR w terminalu (u mnie to micro) i piszesz prompt jak zwykły plik: układasz, poprawiasz, przepisujesz akapit, a dopiero potem wysyłasz. Kiedy się do tego przyzwyczaisz, promptowanie w jednej linijce przypomina pisanie SMS-ów w grubych rękawicach.

Uczciwie ostrzegam: Termuxa na telefonie utrzymuję ręcznie. W trakcie jednego wyjazdu aktualizacja npm podmieniła ręcznie zainstalowaną binarkę na niezgodny build i zepsuła mi konfigurację. Od tamtej pory menedżery pakietów nie aktualizują tam automatycznie CLI agentów, a ja robię to świadomie, ręcznie.

Kiedy nadal używam GUI (i czemu tak rzadko)

Po aplikacje graficzne sięgam od czasu do czasu, najczęściej po aplikację Codex w ChatGPT. Jest wolna, więc nie pracuję w niej na co dzień, ale przydaje się do trzech rzeczy: rozmowy głosowej na żywo, wbudowanej przeglądarki, gdy agent ma obsłużyć prawdziwą stronę (computer use), i części poprawek UI i UX. Większość pozostałych aplikacji, które testowałem, w tym Zed i Orcę, otwieram dziś rzadko. Zmiany sprawdzam w Fresh, edytorze działającym w terminalu, a diffy oglądam w lazygit.

Powody są praktyczne. Aplikacje graficzne zużywają dużo więcej zasobów, bardziej ograniczają i z mojego doświadczenia mają więcej błędów. Części rzeczy w GUI po prostu nie da się zrobić, a większość łatwiej znaleźć i wykonać w narzędziu CLI.

Narzędziom z interfejsem graficznym dałem jednak uczciwą szansę. Workspace "T3 Herdr Orca Paseo Zed" ze zrzutu ekranu to tygodnie testów, a nie jedno popołudnie:

T3 Code to najbardziej dopracowany panel do sterowania agentami, jaki testowałem, a parowanie z telefonem jest naprawdę udane. Od lipca korzystałem z jego serwera w wersji self-hosted i w tym czasie pokazywał on tylko wątki, które sam rozpoczął, a moje sesje z terminala były dla niego niewidoczne (t3code issue #5346; zgłoszenie jest już zamknięte, więc możliwe, że to naprawiono, a jeśli pracę zaczynasz od GUI, warto sprawdzić ponownie). Nie mierzyłem tego rygorystycznie, ale przy zadaniach prowadzonych przez GUI tygodniowy limit znikał wyraźnie szybciej niż przy tej samej pracy wprost w CLI. To przy tym wciąż wersja alfa, a pierwszego dnia z obecną wersją trafiłem na dwa niedociągnięcia.
Orca ma najwięcej funkcji z całej stawki: fan-out do wielu agentów, wybór zwycięzcy, wbudowane terminale, worktree przez SSH. Problem w tym, że to samo robię ręcznie w trzech kartach Herdr z trzema worktree w git, zużywając tyle samo tokenów i bez narzutu dodatkowego narzędzia. GUI automatyzuje głównie krok, który nic mnie nie kosztuje.
Zed mam nadal zainstalowany na okazjonalne zadania. Jego zdalne sesje przez SSH są najszybsze, z jakich korzystałem, a panel agenta obsługuje ACP (Agent Client Protocol), więc zewnętrzni agenci działają wewnątrz edytora. Dziś otwieram go rzadko, bo to, do czego go używałem, załatwiają Fresh i lazygit.
Zrzuty ekranu z adnotacjami: Flameshot ze strzałkami i tekstem wygrywa z każdą funkcją typu "kliknij element, żeby dodać kontekst", jaką widziałem, bo strzałkę i tak umiem narysować.

Wszystko, co odrzuciłem, ma wspólną cechę: każde GUI chce przejąć kontrolę nad sesją, a u mnie kontrolę ma terminalowy workflow, w którym narzędzia CLI mogę dowolnie wymieniać. Dlatego ograniczenie T3 tak mi przeszkadzało, a komuś, kto każdą sesję zaczyna w GUI, byłoby obojętne.

Siatka asekuracyjna, dzięki której agenci są użyteczni

Jeśli autonomiczni agenci mają pracować na prawdziwych maszynach, trzeba założyć, że prędzej czy później coś zepsują. Moi już to zrobili: usunęli nie ten plik, nadpisali konfigurację, zapchali dysk. Odpowiedzią są snapshoty Restic co 2-3 godziny na każdej maszynie, zaszyfrowane i wysyłane do zewnętrznej lokalizacji.

Gdy agent coś uszkodzi, odzyskiwanie jest czysto mechaniczne: znajduję snapshot, przywracam go do katalogu tymczasowego, robię diff i odkładam plik na miejsce. Nigdy nie przywracaj danych prosto w miejsce oryginałów i nie traktuj lokalnego snapshotu systemu w stylu Timeshift jako ochrony katalogu domowego.

Najdłużej uczyłem się jednej zasady: sprawdź, czy kopia zapasowa obejmuje daną ścieżkę, zanim pozwolisz agentowi ją przepisać, a nie po fakcie. Przywrócenie pliku ze snapshotu sprzed czterech godzin jest lepsze niż odtwarzanie go z pamięci, ale snapshot, którego zapomniałeś skonfigurować, nie przywróci niczego.

Jak radzę sobie z limitami

Kiedyś limit, który kończył się w połowie zadania, zabijał nocne uruchomienia. Dziś to w zasadzie rozwiązany problem. ChatGPT Pro, za który płacę $100, nie ma limitów 5-godzinnych, więc Codex pracuje dalej, gdy Claude staje. W Claude ustawiam monitor na dokładną godzinę odnowienia okna 5-godzinnego i po tym czasie sesja sama się wznawia. Nie muszę wstawać o 3 w nocy, żeby wpisać "continue".

Gateway LiteLLM z uporządkowaną listą zapasowych dostawców dla każdego zadania mógłby niezauważalnie przekierować odpowiedź 429 do kolejnego dostawcy, a każdy CLI w tym zestawie już teraz rozmawia z dowolnymi dostawcami przez aliasy, więc byłaby to kwestia konfiguracji, a nie grzebania w bebechach. Może się przydać, jeśli zechcę automatycznie przełączać dostawców, ale na razie nie jest pilny.

Jak zbudować coś podobnego

Lista startowa bez upiększeń, w tej kolejności:

Najpierw uruchom SSH i Tailscale między maszynami. Cała reszta od tego zależy.
Zainstaluj Herdr, utwórz jeden workspace na urządzenie i pracuj w nim przez tydzień, zanim dodasz cokolwiek innego.
Wybierz jeden CLI na orkiestratora i naucz się go porządnie; u mnie był to Claude Code. Kolejne CLI dodawaj dopiero wtedy, gdy potrafisz wskazać zadanie, z którym pierwszy radzi sobie źle.
Skonfiguruj snapshoty Restic, zanim pozwolisz jakiemukolwiek agentowi działać bez nadzoru, a nie po pierwszym incydencie.
Dodaj tracker zadań wspólny dla agentów (Beads albo coś podobnego), a gdy zauważysz, że powtarzasz agentom te same instrukcje, także repozytorium skills z skills.sh.
Dopiero potem oceniaj graficzne dashboardy, z własnym workflow jako punktem odniesienia.

FAQ

Czy do tego workflow potrzebne są płatne subskrypcje?

Nie. Subskrypcje dają przepustowość i zapas, ale sam wzorzec (multiplekser, jeden CLI jako orkiestrator, flota maszyn połączonych przez SSH, kopie zapasowe) działa też na darmowych planach i lokalnych modelach. Ceny dostawców zmieniają się tak szybko, że cokolwiek tu napiszę, zdezaktualizuje się przed Twoją następną fakturą, czego dowodem jest GLM coding plan za $25 rocznie, który znalazłem na promocji.

Czemu nie użyć po prostu GUI, takiego jak Orca albo T3 Code?

Spróbuj, bo w tym, co robią, są dobre, a jeśli żyjesz w GUI i nigdy nie dotykasz powłoki, u Ciebie GUI może sprawdzić się lepiej. Ja odrzuciłem je z konkretnych powodów: T3 Code w czasie, gdy z niego korzystałem, nie widział sesji uruchomionych w terminalu, a Orca automatyzowała fan-out, który ręcznie nic mnie nie kosztuje. Do tego aplikacje graficzne zużywają więcej zasobów i częściej się psują niż CLI, na których działają.

Czy bezpiecznie jest zostawiać agentów bez nadzoru na własnych maszynach?

Samo w sobie nie jest to bezpieczne i właśnie po to są zabezpieczenia: tryby sandbox w CLI, snapshoty Restic co 2-3 godziny, zasada, że agenci nigdy nie robią commita ani pusha bez wyraźnego polecenia, SSH, które działa tylko z moich głównych maszyn na zewnątrz, oraz dane osobowe klientów dostępne tylko u określonych dostawców i w określonych regionach. Zabezpieczenia zmniejszają skalę szkód, ale nie sprowadzają jej do zera, a kopie zapasowe to nie formalność: zwróciły mi się już więcej niż raz. Jak zbudowane są same zabezpieczenia prywatności (routing według regionu, pliki z zasadami, hooki blokujące dostęp do danych uwierzytelniających), opisuje artykuł o prywatności danych.

Jak to wszystko pisać na telefonie?

Przeważnie nie piszę, tylko dyktuję: na telefonie przez klawiaturę FUTO z lokalnymi modelami, na komputerze przez handy.computer. Przy promptach wymagających starannego sformułowania ctrl+g otwiera prawdziwy edytor. Rozmiar ekranu S24 Ultra pomaga, ale tak naprawdę cały ten workflow opiera się na dyktowaniu.

Która zmiana najbardziej poprawiła ten zestaw?

Sesje po stronie serwera. Gdy agenci wyprowadzili się z okna terminala, a zamknięcie laptopa, zmiana urządzenia, a nawet restart multipleksera przestały zabijać pracę, równoległa praca wielu agentów przestała stresować i zrobiła się nudna, a nuda to tutaj cel.

---

Kilka słów o autorze, skoro zrzut ekranu i tak to zdradza. Panele powyżej to autentyczny wtorek z mojej pracy: praca dla klientów, materiały szkoleniowe i gra 3D o nazwie Stack Underflow, która powstała na hackathonie i mieszka w tych samych repozytoriach co cała reszta.

Budowanie takich automatyzacji to nasz rodzinny biznes. Edukey szkoli zespoły z praktycznych umiejętności związanych z AI i danymi, a w DevPowers wypuszczamy własne projekty zbudowane przez agentów. Wszystko z tego artykułu odtworzysz bez nas. Jeśli jednak chcesz, żeby Twój zespół przeszedł z ChatGPT w karcie przeglądarki na coś takiego, właśnie tym zajmuję się zawodowo.

Mój terminalowy workflow z agentami AI: Herdr + Claude + Termux