O czym jest ten film
- Autor (Callum z kanału Wanderloots) pokazuje, jak połączyć dwa niezależnie działające zestawy agentów w jeden system sterowany z jednego komputera.
- Scenografia sprzętowa: Mac Studio jako centrum dowodzenia („Hermes 1”) oraz AMD Ryzen AI Halo z lokalnymi modelami uruchamianymi przez llama.cpp („Hermes 2”).
- Klucz do zrozumienia architektury: aplikacja desktopowa Hermes to tylko klient — właściwy system działa jako „gateway”, dostępny w czterech trybach: lokalnym, Hermes Cloud, zdalnym i przez SSH.
- Profile w Hermesie to samodzielne boty: każdy ma własne umiejętności, narzędzia, pamięć i kontekst; profile nie dzielą się niczym.
- Na drugiej maszynie powstaje bot „badacz”: profil o tej nazwie, skopiowany plik
soul.mdoraz konektor Consensus MCP do przeszukiwania publikacji naukowych. - Backend wystawiany jest przez Tailscale:
tailscale servena porcie 9119, następniehermes config set dashboard.public_urlihermes serve host 9119. - Pierwsze uruchomienie wymusza ustawienie loginu i hasła do panelu — dostęp jest chroniony nawet wewnątrz zaufanej sieci VPN.
- Centrum dowodzenia dodaje zdalne połączenie (nazwa, URL, dane logowania), testuje dostępność i z paska profili przełącza się na boty działające na drugim komputerze.
- Sesje i pamięć są wspólne: tę samą rozmowę można zacząć na jednym komputerze i kontynuować na drugim; na ekranie widać realne zadanie badawcze z Consensus (13 prac naukowych) i wyszukiwaniem w sieci.
- Część „zaawansowana”: utrzymanie backendu przy życiu (odłączenie od terminala, autostart, dostępność 24/7), tryb SSH jako zdalna administracja, komunikacja bot–bot oraz zapowiedź automatycznego przełączania modeli lokalnych.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Aplikacja desktopowa Hermes to tylko klient — backend żyje osobno
Na czym polega: Interfejs na pulpicie jest nakładką na „gateway”, czyli część serwerową, która może działać na zupełnie innym komputerze. To właśnie to rozdzielenie pozwala sterować botami zdalnej maszyny ze swojego głównego komputera.
Jak stosować: Projektując własny układ, zacznij od backendu: gdzie działa, na jakim porcie, kto się z nim łączy. Dopiero potem dobieraj klienty na poszczególnych urządzeniach.
Na co uważać: Łatwo pomylić lokalną instancję aplikacji z działającym w tle procesem serwującym — wtedy sesje zgłaszają „nie znaleziono”, choć boty formalnie działają.
2.Profile to odseparowane boty — nie dzielą się niczym
Na czym polega: Każdy profil w Hermesie ma własne umiejętności, narzędzia, pamięć i kontekst. Test „kim jesteś?” pokazał, że nowy bot nie znał wcześniejszych rozmów autora — profile startują od czystej karty.
Jak stosować: Nowych specjalistów zakładaj jako osobne profile, a ich charakter przenoś przez plik soul.md zamiast liczyć na wspólną pamięć.
Na co uważać: Wiedza o Tobie nie przenosi się między profilami automatycznie — każdą pamięć trzeba zbudować (lub skopiować) od nowa.
3.Zdalny gateway: drugi komputer staje się częścią zespołu
Na czym polega: W ustawieniach bramy dodajesz zapisane połączenie zdalne (nazwa, URL, uwierzytelnienie). Po zalogowaniu w kliencie pojawiają się profile działające na tamtej maszynie.
Jak stosować: Po dodaniu połączenia zawsze użyj przycisku testu dostępności, zanim zaczniesz z nim pracować na serio.
Na co uważać: Na komputerze sterującym nie ustawiaj połączenia zdalnego jako głównego — jego podstawą ma pozostać lokalna brama.
4.Tailscale to najprostszy sposób wystawienia backendu pod prywatny adres
Na czym polega: Urządzenia dołączone do jednej sieci Tailscale (tzw. tailnet) widzą się nawzajem, a polecenie tailscale serve wystawia wskazany port — w tym wypadku 9119 — pod stabilnym adresem URL.
Jak stosować: Zainstaluj Tailscale na obu maszynach, dodaj je do tego samego tailnetu, wystaw port backendu i wklej otrzymany adres jako URL bramy w kliencie.
Na co uważać: Taki adres działa tylko wewnątrz Twojej sieci — nie udostępniaj go publicznie i pilnuj, żeby port w poleceniu zgadzał się z portem, na którym nasłuchuje Hermes.
5.Kolejność konfiguracji: najpierw URL, potem serwer
Na czym polega: Zanim uruchomisz Hermes w trybie serwera, ustaw publiczny adres panelu poleceniem hermes config set dashboard.public_url, a dopiero potem wystartuj backend przez hermes serve host 9119. Pierwsze uruchomienie dodatkowo wymusza ustawienie loginu i hasła.
Jak stosować: Trzymaj się tej kolejności i zanotuj dane logowania od razu — przydadzą się w kliencie na drugim komputerze.
Na co uważać: Pominięcie ustawienia adresu skieruje klienta w próżnię, a utracone hasło do panelu odcina od całej instancji.
6.Dedykowane konektory przydzielaj specjalistom, nie wszystkim botom
Na czym polega: Badacz dostał konektor Consensus MCP (darmowy dostęp do milionów publikacji naukowych, także bez płatnego konta) oraz autorską umiejętność narzucającą sposób jego użycia.
Jak stosować: Podłącz narzędzie bezpośrednio do profilu odpowiedniego specjalisty i opisz w jego „duszy”, kiedy i po co z niego korzystać.
Na co uważać: Każde podpięte narzędzie poszerza możliwości bota — lepsze wąskie, wyspecjalizowane zestawy niż jeden agent z dostępem do wszystkiego.
7.Sesje i pamięć podążają za botem, nie za komputerem
Na czym polega: Rozmowę rozpoczętą na jednej maszynie widać w panelu projektów na drugiej; raz zapisana pamięć agenta jest dostępna z obu urządzeń, bo oba klienty rozmawiają z tym samym backendem.
Jak stosować: Zadania zaczynaj tam, gdzie wygodnie — agent dokończy je z drugiego komputera w tej samej sesji.
Na co uważać: Aplikacja desktopowa na maszynie serwującej nie zawsze podpina się do działającego backendu; obejściem jest dodanie na niej połączenia zdalnego na localhost i ustawienie go jako głównego.
8.Backend musi żyć: odłącz go od terminala
Na czym polega: Zamknięcie terminala zabija proces hermes serve — a wraz z nim dostęp centrum dowodzenia do całej zdalnej drużyny.
Jak stosować: Uruchom serwer jako proces odłączony od sesji (usługa systemowa, harmonogram zadań) i dodaj autostart razem ze startem systemu.
Na co uważać: Bez autostartu każdy restart komputera „zabiera” zespół; warto regularnie sprawdzać przyciskiem testu, czy połączenie wciąż jest osiągalne.
9.SSH jako ramię administracyjne centrum dowodzenia
Na czym polega: Tryb SSH pozwala komputerowi sterującemu uruchamiać skrypty i polecenia w powłoce drugiej maszyny — na przykład ponownie podnieść backend po awarii.
Jak stosować: Połącz maszyny przez SSH, gdy chcesz administrować zdalnym komputerem nie wstając od biurka; centrum staje się wówczas maszyną zarządzającą.
Na co uważać: To pełny dostęp do powłoki — zadbaj o klucze i ogranicz, co dokładnie wolno wykonywać zdalnie.
10.Specjalizacja zamiast monolitu — ale krok po kroku
Na czym polega: Autor stawia na modułowych, wąsko wyspecjalizowanych agentów, które — jak zauważa — zwykle wygrywają z pojedynczym botem-do-wszystkiego; układ wielomaszynowy pozwala trzymać ich przy lokalnych modelach.
Jak stosować: Buduj małych specjalistów na mocniejszej maszynie z lokalnymi modelami i wołaj ich przez orkiestratora z komputera głównego.
Na co uważać: Zanim sięgniesz po komunikację bot–bot i podagentów, doprowadź do stabilności prosty scenariusz z jednym zdalnym zespołem.
Redakcyjne tłumaczenie
Dwa komputery, jedno centrum dowodzenia
Całością steruję z mojego centrum dowodzenia. Na ekranie widać, że dwa zadania właśnie się zakończyły — jedno tutaj, drugie tam. A teraz wyobraźcie sobie, że agentów uruchamiacie na jednym komputerze, a korzystacie z nich zupełnie z innego. Hermes sprawił, że to banalnie proste: botami można zarządzać z wielu urządzeń, co daje znacznie większą swobodę w projektowaniu i uruchamianiu zespołów — zarówno tych zasilanych modelami lokalnymi, jak i chmurowymi.
Nazywam się Callum, w sieci znany jako Wanderloots, i witam w odcinku o łączeniu wielu zespołów agentów w jedno centrum sterowania. Plan na dziś: stawiamy na moim AMD Halo — komputerze dedykowanym lokalnym modelom — specjalistycznego bota zasilanego lokalnie, bezpiecznie podłączamy go do głównego centrum na Macu Studio, wykonujemy nim prawdziwe zadanie badawcze, korzystamy z tego samego badacza z obu maszyn, a na koniec zerkamy na opcje pozwalające zespołowi pracować całą dobę. Zaczynamy.
(Informacja dodatkowa: Hermes w tym materiale oznacza platformę agentową — aplikację desktopową plus działającą w tle część serwerową — konfigurowaną wcześniej przez autora w odrębnych odcinkach.)
To nie to samo, co jeden agent dostępny z wielu urządzeń
Wcześniej pokazywałem, jak sięgać po tego samego agenta z kilku urządzeń. Dziś idziemy krok dalej: mamy niezależnie działające zespoły agentów, koordynowane z jednego miejsca. Dzięki temu mogę postawić mocniejszą maszynę — właśnie to AMD — z lokalnymi modelami, które zasila jej własny system botów, a całość nadal nadzoruję z głównego Studia. Działa to z dowolną liczbą sprzętów: wszystkie podpinamy do tej samej instancji Hermes. To jeden z większych atutów nowego systemu bram — może działać kilka osobnych backendów, a wszystkim sterujemy z jednego klienta desktopowego. Nie mogę się doczekać głębszego grzebania w tym, zwłaszcza że mam nowy, dedykowany komputer do AI, o którym opowiem w osobnym filmie.
Jeśli materiał Ci pomaga, zostaw łapkę i zasubskrybuj — to naprawdę wspiera kanał. Chcesz wsparcia więcej? Zapraszam do grona członków na YouTube lub Patreonie. Wszystkie polecenia i kod z tego odcinka zebrałem ponadto w darmowym artykule na Patreonie — link zostawiam w pierwszym komentarzu, żebyś mógł po prostu iść za mną krok po kroku.
Cztery tryby połączenia z Hermesem
W poprzednim odcinku postawiliśmy na tym komputerze nową instancję Hermes podłączoną do modelu lokalnego: działa silnik llama.cpp obsługujący ten model (u mnie w kwantyzacji 3.6). Krótko mówiąc, model jest spięty z silnikiem na tym urządzeniu. Ale co, gdybym chciał sięgnąć po tego bota z innego komputera?
Wchodzimy w ustawienia, zakładka Gateway. Do wyboru cztery tryby: brama lokalna, Hermes Cloud, brama zdalna oraz połączenie przez SSH. Najważniejsze jest zrozumienie jednej rzeczy: aplikacja, w której teraz siedzę, to wyłącznie klient — interfejs nałożony na coś, co Hermes nazywa gateway. Na razie pulpit łączy się z bramą lokalną, ale mam też inne możliwości: Hermes Cloud, czyli usługę zarządzaną przez Nous Research (Informacja dodatkowa: transkrypt automatyczny zapisuje „News Research” — chodzi o Nous Research, twórców modeli Hermes); bramę zdalną, w której pulpit staje się lekką nakładką na istniejący backend Hermes działający gdzie indziej; wreszcie SSH, pozwalający uruchomić taki backend i przetunelować go do aplikacji.
Cel jest prosty: bieżący Hermes ma zarządzać Hermesem na innym urządzeniu, a brama zdalna daje dostęp do botów i profili tamtego, odległego agenta.
Mac Studio i Halo: podział ról
Mamy więc Maca Studio i AMD Ryzen AI Halo — jeden komputer z macOS, drugi z Windows, na którym królują modele lokalne. Wróćmy na moment do Maca: na dole widać kilka profili. Każdy profil to osobny bot, który można uruchomić w trybie Hermes Bot Mode, i każdy ma własne umiejętności, narzędzia, pamięć, kontekst i połączenia. To w pełni samodzielny agent.
Chodzi o to, żeby główny komputer nie ograniczał się do botów zainstalowanych lokalnie. Chcę też zarządzać bramami i sięgać po modele, które ustawiłem na maszynie AMD — tak, żeby na tamtym urządzeniu mieszkała cała kadra agentów zasilana lokalnie. Nazwijmy ją umownie Hermes 2. A ja z Hermes 1, czyli z komputera głównego, mam do wszystkich tych botów pełny dostęp i kontrolę. Jeden interfejs sterujący, który sięga po agentów żyjących na innej maszynie. Bierzemy się za konfigurację.
Budowa bota badacza na drugiej maszynie
Zaczynam od utworzenia nowego profilu o nazwie researcher — celowo takiej samej jak na drugim urządzeniu. Kopiuję plik soul.md, żeby nowy bot dostał ten sam opis co jego imiennik, wklejam go i klikam „utwórz profil”. Gotowe: obok domyślnego bota z instalacji Hermes pojawia się badacz.
Potem dodaję mu kilka konkretnych umiejętności i połączeń, ale nie będę się w to zagłębiał — w osobnych filmach pokazywałem, jak ustawia się boty w trybie Hermes Bot Mode i jak rozbudowałem mojego badacza o dodatkowe możliwości. Dziś liczy się co innego: żeby ten badacz stał się dostępny dla drugiego komputera. Po wgraniu „duszy” podłączam jeszcze Consensus MCP — sponsora dzisiejszego odcinka, do którego wrócę za chwilę. (Informacja dodatkowa: MCP, Model Context Protocol, to otwarty standard podłączania zewnętrznych narzędzi i źródeł danych do agentów AI.)
Lokalny badacz na Hermes 2 będzie więc prowadził własne sesje, własną pamięć i własne umiejętności — ale dostanie też własne konektory. Mogę podpiąć pod tego agenta dowolne narzędzia i dać specjalistom dostęp do konkretnych zasobów, takich jak Consensus, czyli darmowy sposób na przeszukiwanie artykułów naukowych. Klikam „połącz” i konektor działa. Dorzucam też autorską umiejętność „Consensus academic”, która wymusza określony sposób użycia tego konektora — to przygotowanie pod mój badawczy system LLM Wiki. Bot stoi, czas sprawdzić, czy działa.
Pytam: „Kim jesteś?” — i bot nie wie, kim jestem, choć w poprzednim tutorialu przedstawiałem się już Hermesowi. To skutek rozdzielenia profili: domyślny i „badacz” nie mają wspólnej pamięci, umiejętności ani czegokolwiek innego. To czysta karta — idealna, gdy chcesz zacząć od zera z innym, wyspecjalizowanym botem. I właśnie dlatego chcę go przenieść na Hermes 1: dostanę w pełni lokalnego badacza, dostępnego zawsze, gdy zechcę, sterowanego z głównego komputera — z pełną kontrolą nad każdym szczegółem jego konfiguracji. Skoro bot działa, czas wystawić go drugiemu urządzeniu.
Wystawienie backendu przez Tailscale
Żeby Hermes 2 stał się widoczny dla Hermes 1, konfiguruję bramę zdalną — to właśnie tak ten komputer ma sięgnąć po Hermes działający na drugiej maszynie. W ustawieniach, w sekcji zapisanych połączeń, klikam „dodaj połączenie” i wybieram typ: brama zdalna. Potrzebne są trzy rzeczy: nazwa (u mnie: Halo), adres URL (do niego zaraz dojdziemy) i uwierzytelnienie.
Teraz trzeba „podać” Hermes z komputera numer dwa pod adres dostępny dla Hermes 1. Sposobów jest kilka, ale mój ulubiony to Tailscale. Działa jak serwer koordynujący połączenia między komputerami: Hermes uruchamiam na jednym urządzeniu, a sprawnie dopięcie drugiego komputera zostawiam Tailscale. Konfiguracja jest naprawdę prosta, ale dziś jej nie omawiam, bo nagrałem od zera osobny tutorial — jeśli zaczynasz, obejrzyj najpierw tamten. W skrócie: instalujesz Tailscale i dodajesz urządzenia do swojej sieci, tzw. tailnetu.
Gdy oba komputery siedzą w jednym tailnecie, uruchamiamy Hermes jako backend, przepuszczamy adres przez Tailscale i używamy go jako URL-a bramy spinającego centrum dowodzenia z drugą maszyną.
Konkrety. Poleceniem tailscale serve wystawiam właściwy port — wszystkie komendy z tego odcinka są w darmowym artykule w pierwszym komentarzu, więc niczego nie musisz notować na bieżąco. Mechanika jest taka: backend Hermes w trybie bramy nasłuchuje na porcie 9119. Wystawiam ten port przez Tailscale, dzięki czemu staje się widoczny w sieci. Enter — i dostaję własny adres URL z moim identyfikatorem tailnetu. To właśnie on ma być dostępny dla pozostałych urządzeń, więc kopiuję go i wklejam jako adres bramy.
Zostaje uruchomienie samego Hermes pod tym adresem. Najpierw hermes config set dashboard.public_url z nowym URL-em — polecenie aktualizuje adres panelu w konfiguracji. Następnie hermes serve host 9119, co zamienia Hermes w serwer, z którym może rozmawiać aplikacja desktopowa albo cokolwiek innego.
Ponieważ robimy to pierwszy raz, Hermes domaga się uwierzytelnienia panelu: wymusza ustawienie nazwy użytkownika i hasła, żeby dostęp do instancji mieli tylko uprawnieni. A że ruch idzie przez Tailscale, jest też bezpieczniej — wszystko zostaje wewnątrz zaufanej sieci, rodzaju LAN czy VPN. Wybieram opcję pierwszą, zakładam konto „Halo admin” i ustawiam hasło. Hermes melduje: backend gotowy na porcie 9119. Pod localhost:9119 pojawia się okienko logowania; po zalogowaniu widać, że część serwerowa działa bez interfejsu graficznego — i dobrze, bo grafika jest nam teraz zbędna.
Łączenie z centrum dowodzenia
Wracam na Maca. Podaję nazwę użytkownika i hasło, klikam logowanie — Hermes informuje, że ta brama wymaga zalogowania, aby autoryzować aplikację desktopową. Potwierdzam i połączenie rusza. Mamy bramę zdalną spiętą przez Tailscale: nazwa Halo, adres URL, uwierzytelnienie. Zapisuję połączenie.
Na liście pojawia się konektor „Halo” z adresem; przycisk testu potwierdza: Halo jest osiągalne. Lokalna brama dalej działa jako połączenie główne, a w zapisanych wisi urządzenie Halo. Jest opcja „uczynienia głównym” — celowo z niej nie korzystam: podstawą centrum dowodzenia ma pozostać brama lokalna na tym komputerze, a Halo to druga maszyna, do której tylko sięgam.
Zerkam na pasek profili: doszła sekcja „profile na tym urządzeniu”, a obok — „profile na Halo”. Widać domyślnego bota Halo i badacza Halo. Nowy bot z innego komputera jest już dostępny; klikam i patrzymy. Połączenie przeskakuje z chmurowego modelu (ChatGPT) na model lokalny. To efektywnie ten sam bot, którego mieliśmy przed chwilą na tamtym sprzęcie — tylko steruję nim stąd.
Czas na próbę ogniową. W panelu projektów rozwijam listę i widzę dokładnie tę samą rozmowę, którą zacząłem na drugim komputerze. Mogę ją po prostu kontynuować. Piszę na przykład: „Kilka rzeczy o mnie: jestem prawnikiem specjalizującym się w własności intelektualnej i rzecznikiem patentowym, studiowałem inżynierię materiałową, a dziś nagrywam filmy na kanale Wanderloots, ucząc ludzi, jak technologią ułatwiać sobie życie.” Wiadomość musiałem wysłać dwa razy, ale informacje zostały zapamiętane. Otwieram sekcję pamięci: plik zaktualizowany — bot zapisał, że nazywam się Callum, jaki jest mój zawodowy rodowód i nad czym obecnie pracuję.
To dowód, że sięgamy w tę samą pamięć przypisaną badaczowi na maszynie Halo — pamięć kontekstową i agentową, o której szerzej opowiem w jednym z kolejnych odcinków. Dziś chciałem podkreślić co innego: możemy tworzyć specjalistów działających na różnych urządzeniach — jak na moim Halo, przy lokalnych modelach — którzy wykonują pracę i raportują ją do głównego komputera, a ja śledzę postępy. Sprawdźmy to na trudniejszym zadaniu.
Prawdziwe zadanie badawcze na modelu lokalnym
Wysyłam badacza w teren. Nadal korzysta z modelu lokalnego z Halo i nadal jestem połączony z Halo — ale steruję z Maca Studio, z centrum dowodzenia. Polecenie brzmi: „Przeprowadź rzetelne badanie, ograniczając się do pięciu głównych źródeł, z użyciem Consensus i wyszukiwania w sieci. Temat: jakie typy wyspecjalizowanych agentów AI najlepiej sprawdzają się na modelach lokalnych i co ma sens przy różnych poziomach pamięci RAM.” Mój plan: złożyć zespół agentów-specjalistów działających na Halo, wywoływanych przez agenta orkiestratora z komputera sterującego.
Poprosiłem o dwie rzeczy naraz: sieć oraz Consensus — sponsora odcinka. Consensus pozwala za darmo podłączyć agenta do milionów publikacji i pomaga wyłuskać te najbardziej trafne i wiarygodne. Połączenie MCP umożliwia przeszukiwanie Consensus wprost z agenta, a do prac naukowych da się sięgać nawet bez płatnego konta.
Agent rusza i faktycznie korzysta zarówno z Consensus, jak i ze źródeł sieciowych. Przeszedł przez bazę, znalazł 13 prac naukowych i składa je właśnie w notatkę badawczą. W aplikacji Consensus po niedawnej aktualizacji można nie tylko samemu wyszukiwać i robić to przez agenta z MCP, ale też zakładać wątki. Ten prompt oznaczony jest ikonką agenta — badacz sformułował całkiem obszerne zapytanie o głębokie badanie. System przefiltrował 2,7 mln artykułów i wyłuskał listę najlepszych pod moje pytanie. Efekt: obok własnego raportu badacza powstały dwa osobne briefingi z głębokiego researchu w Consensus. Mogę też kliknąć podgląd wątku na żywo i kontynuować tę rozmowę z poziomu Hermes, przechodząc swobodnie między agentem a własnym badaniem. Naprawdę fajny sposób, żeby podnieść jakość tego, co dają modele lokalne. Dzięki, Consensus, za wsparcie odcinka — a my idziemy dalej.
Pułapka: aplikacja nie zawsze widzi własny backend
Zanim zajmiemy się wynikami, pokażę coś istotnego: to wszystko dzieje się na Halo, nie tylko w moim centrum. Gdy otwieram Hermes wprost na Halo — mimo że badacz tam działał i rozmowa jest widoczna — sesja melduje: „wznawianie nieudane, nie znaleziono”. Powód: aplikacja na Halo niekoniecznie jest podłączona do tej samej bramy, z którą łączył się Mac Studio. Aplikacja desktopowa jest samowystarczalna i teoretycznie przypina się do działającego w tle procesu serwującego, ale w praktyce bywa z tym różnie. Wiem, że twórcy nad tym pracują — docelowo po uruchomieniu hermes serve aplikacja ma się automatycznie łączyć z już działającą bramą. Na razie mam z tym pewne kłopoty.
Obejście — być może wkrótce zbędne: w ustawieniach, w bramach i zapisanych połączeniach, dodaję dokładnie to samo połączenie zdalne, tylko z adresem localhost. Loguję się, dla porządku zmieniam nazwę na Halo, zapisuję i zaznaczam jako główne. Hermes ostrzega, że to ten sam backend, co na tym urządzeniu — świadomie akceptuję. Po restarcie Hermes stare połączenie pokazuje „nieosiągalne”, ale profile na zdalnej bramie Halo — domyślny i badacz — są na miejscu, razem z tą samą sesją, i nic nie zgłasza „nie znaleziono”. W przyszłości ten krok może okazać się niepotrzebny, gdy aplikacja na maszynie serwującej poprawnie podepnie się pod backend. Na dziś to najprostszy sposób, żeby na drugim komputerze domyślnie wchodzić we właściwą instancję.
I teraz sedno. Piszę z Halo: „Daj zwięzłe podsumowanie całego naszego badania.” Model na nowo ładuje się do pamięci; przechodzę na Maca — tam właśnie przetwarzany jest ten sam prompt, w tej samej sesji. Traktując aplikację na Halo jako klienta podpiętego do wspólnego backendu — dokładnie tak jak na Studio — synchronizujemy sesje niemal bezszwowo: obie aplikacje rozmawiają z jednym procesem serwowanym przez Hermes. Zamiast polegać na mechanizmie automatycznego podpinania aplikacji do zdalnego hosta, tym obejściem uzyskuję równoległy dostęp z obu maszyn. Zadanie kończy się tu — i tu. Można zacząć na jednym komputerze i dokończyć na drugim; wszystko jedno, które.
A oto wyniki: raport na podstawie Consensus i sieci o tym, jakie struktury modeli pasują do jakich konfiguracji — uporządkowane zestawienie poziomów RAM i typów modeli, które warto na nich uruchamiać. Szerzej opowiem o tym w następnym odcinku: jak przypisywać różne modele do różnych akcji i specjalistów. Może zechcesz postawić własne LLM Wiki, jak w moim filmie o agencie-bibliotekarzu — agencie, który utrzymuje za nas bazę wiedzy. Najpiękniejsze w tej metodzie: wszystko może dziać się w stu procentach lokalnie.
Praca ciągła: trzy rzeczy do przemyślenia
Skoro połączenia już działają, kilka uwag „zaawansowanych” dla każdego, kto chce taki system utrzymywać.
Pierwsza: harmonogram zadań. Jeśli zamknę ten terminal, serwowany Hermes zniknie — a wraz z nim dostęp centrum dowodzenia do tej maszyny. Zależnie od systemu operacyjnego można odłączyć proces od terminala i ustawić uruchamianie razem ze startem komputera. Wtedy agent jest pod ręką zawsze — całą dobę, każdego dnia.
Druga: tryb SSH (secure shell) w ustawieniach bram. Pozwala komputerowi sterującemu uruchamiać skrypty i akcje w powłoce drugiej maszyny — na przykład ponownie podnieść backend. Nie musi to wcale iść przez samego Hermes: wystarczy spiąć komputery w podobny sposób, a centrum staje się maszyną administracyjną.
Trzecia: komunikacja bot–bot, której dziś nie ruszaliśmy. Mój orkiestrator może wysyłać wiadomości badaczowi na Halo — jak to działa, opisałem w filmach „Czy tryb botów Hermes jest wart uwagi?” oraz o rozbudowie mojego zespołu agentów. Teraz to samo da się robić między urządzeniami, co otwiera drogę do bardziej złożonej orkiestracji: podagentów kontra pełnych zespołów.
Specjalizacja zamiast monolitu — co dalej
Cieszę się na testowanie kolejnych modeli o różnych pojemnościach, uruchamianie ich na Halo i udostępnianie botom z głównego komputera. Mogę albo wchodzić na specjalistów zasilanych lokalnie, albo dawać istniejącym botom dostęp do lokalnych narzędzi. Wchodzimy w specjalizację zamiast uogólniania: modułowi agenci przypisani do wąskich zadań zwykle wygrywają z pojedynczym, monolitycznym botem.
Mamy więc lokalnie zasilony zespół podłączony do centrum dowodzenia. Dwie osobne drużyny — każda z innymi umiejętnościami, narzędziami, kontekstem i pamięcią — a jednak koordynowane z jednego miejsca. Zaczyna to naprawdę wyglądać jak jeden zespół, zwłaszcza że modele lokalne wzmacniają system, nad którym pracuję od dawna. Do zrobienia zostało jeszcze dużo: przełączanie modeli, automatyczna podmiana modeli lokalnych pod konkretne zadania lub boty — i przeniesienie tej koordynacji do centrum, żeby obie ekipy korzystały z lokalnej mocy obliczeniowej. Tym zajmiemy się w następnym odcinku.
Dzięki za obejrzenie — łapka i subskrypcja bardzo pomagają. Do zobaczenia.