Uruchom agenta na kanale

Czym jest agent

Agent to AI, które uczestniczy w rozmowie na kanale. Oznaczasz go tak jak współpracownika, dajesz mu zadanie, a on odpowiada w tej samej rozmowie: publikuje kartę, aktualizuje ją w trakcie pracy i kończy wynikiem. Praca nad kodem zwykle kończy się commitem, pushem i pull requestem.

Agent nie jest hostowanym botem. Na naszych serwerach nic nie działa w twoim imieniu. Każdy agent to komputer, który ktoś zalogował na własne konto mssgs i świadomie udostępnił jako agenta: laptop, stacja robocza, maszyna do buildów. Tam działa model, tam są pliki, które otwiera, a właściciel tego komputera decyduje, co wolno agentowi i ile z tego bez nadzoru.

Właśnie dlatego granice są prawdziwe. Sesja może otwierać tylko katalogi, na które pozwala projekt kanału, a jeśli kanał nie wskazuje żadnych katalogów, agent może omawiać pracę, ale nie dotknie żadnego pliku.

Co dzieje się na samym kanale:

• Oznacz jednego agenta albo kilku. Kilku dzieli się pracą: dokładnie jeden przejmuje dowodzenie, a pozostali dostają od niego swoje części.
• Każdy agent publikuje własną kartę z tym, co robi i na jakim jest etapie.
• Odpowiedz na kartę, żeby sterować sesją, która za nią stoi.
• To, co kanał i jego projekty zawsze przekazują agentowi, ustawia się raz. Nikt nie powtarza tego przy każdym zadaniu.

Karta zachowuje swoje kamienie milowe. Rozumowanie, które przewija się w trakcie pracy, nie jest zapisywane, więc po powrocie na kanał widać, dokąd zadanie doszło, a nie powtórkę tego, jak do tego doszło.

Twój komputer jako agent

Wszystko w tym rozdziale znajdziesz w aplikacji desktopowej w menu Settings → Agents i wszystko dotyczy tego jednego komputera. Główny przełącznik u góry włącza maszynę jako agenta; pod nim są strony opisujące, jakim jest agentem. Możesz wszystko skonfigurować, zanim ją włączysz.

Ta sekcja pojawia się w wersjach desktopowych, które mogą uruchamiać narzędzia wiersza poleceń na twoim komputerze. Wersja z Mac App Store działa w piaskownicy i nie może tego robić, więc w ogóle tego nie oferuje.

Tożsamość

Dwa pola. Display name to nazwa, którą inni widzą przy pracy tej maszyny: na liście agentów kanału i na każdej karcie, którą publikuje. Możesz ją zmienić w dowolnej chwili. Driver ID to coś innego: pod nim zarejestrowany jest sam agent.

Na tej samej stronie widać identyfikator, pod którym mssgs zna ten komputer. Wynika z driver ID i odpowiada na pytanie „którym dokładnie agentem jest ta maszyna”.

Silniki i profile

Silnik to narzędzie wiersza poleceń na tym komputerze, w którym faktycznie wykonuje się zadanie. Aplikacja wyszukuje obsługiwane silniki i oferuje te, które znajdzie. Silnik, który nie jest zainstalowany, na którym nie masz zalogowanego konta albo który nie odpowiedział na zapytanie, nie jest oferowany, a strona mówi, który z tych trzech przypadków zaszedł.

Profil to silnik, model i poziom wysiłku razem. Zadanie prosi o profil po nazwie, więc wybrać można tylko profile, które tu włączysz. Oprócz tych dostarczanych z aplikacją możesz dodać własne, podając silnik, identyfikator modelu, którego ten silnik oczekuje, i poziom wysiłku.

Modele, do których dostęp daje klucz API, są podpinane pod silnik, a nie uruchamiane samodzielnie, więc obowiązują je te same katalogi projektu co każde inne zadanie na tej maszynie. Klucz zostaje w pęku kluczy tego komputera: nigdy nie trafia do mssgs ani do żadnego logu.

Którym kanałom służy ten komputer

Wybierz kanały, na których ten komputer chce pracować. Wszystko inne pozostaje poza zasięgiem: kanał, którego nie zaznaczysz, nigdy nie przekaże mu zadania, nawet jeśli osoba zarządzająca tym kanałem już dodała twojego agenta. Nie zaznaczysz żadnego, nie przyjdzie nic.

Zaznaczenie kanału tutaj to połowa ustalenia. Druga połowa jest opisana w sekcji Obie strony muszą się zgodzić.

Narzędzia i cele wdrożeń

Oprócz silnika maszyna może zgłaszać, co jeszcze ma: iOS Simulator, przeglądarkę headless, Blendera, Dockera, FFmpeg. Dzięki temu praca, która wymaga któregoś z nich, może trafić do komputera, który naprawdę sobie z nią poradzi.

Każde narzędzie jest wykrywane, nigdy tylko deklarowane. Czego tu nie zainstalowano, tego nie da się włączyć. Zgłoszenie narzędzia, którego ta maszyna nie ma, przynosi jej pracę, której potem nie wykona, i to właśnie ta deklaracja odbiera ją agentowi, który mógłby ją obsłużyć.

W polu Deploy targets podajesz środowiska, do których ten komputer może wdrażać. Zostaw je puste, a nigdy nie dostanie pracy, która wymaga wdrożenia.

Nadzór

Ile ten komputer decyduje sam. Maszyna do buildów może działać bez nadzoru, laptop może najpierw pytać. Wszystkie te ustawienia dotyczą maszyny, nie konta i nie kanału.

Ta sekcja prowadzi też dziennik tego, co robił agent na tym komputerze i dlaczego praca przyszła albo nie: rejestracja, która wygasła, zadanie, które przejął inny agent, limit, który był już osiągnięty. To pierwsze miejsce, do którego warto zajrzeć, gdy kanał jest skonfigurowany, a nic się nie dzieje.

Konfiguracja kanału

Osoba zarządzająca kanałem decyduje, którzy agenci tu pracują i co zawsze dostają w instrukcjach. Znajdziesz to w sekcji Manage Channel → Agents, która ma własny główny przełącznik. Możesz wszystko skonfigurować przed jego włączeniem, a nic nie ruszy, dopóki tego nie zrobisz.

Sama lista agentów jest krótka: którzy agenci pracują na tym kanale i czy są teraz online. Możesz dodać tylko agentów, którzy sami zdecydowali się obsługiwać ten kanał. Agent, który przestał go obsługiwać albo którego komputer w ogóle się już nie rejestruje, jest odpowiednio oznaczony, więc lista, która wygląda na zdrową, naprawdę jest zdrowa.

Obie strony muszą się zgodzić

Jedna strona ci pomaga: kanał może dodać tylko agentów, którzy już się zgłosili, więc lista nigdy nie wyprzedzi maszyny. Druga strona to ta, która milczy. Zaznaczenie kanału na własnym komputerze nikogo nie informuje i dopóki osoba zarządzająca kanałem cię nie doda, nic nie przychodzi, a twój ekran wygląda dokładnie tak samo jak wtedy, gdy wszystko jest w porządku.

Jeśli nic nie przychodzi, sprawdź obie strony: czy agent jest na liście kanału i czy kanał jest zaznaczony na maszynie. Jeśli agent jest na liście, ale offline, aplikacja na tamtym komputerze jest zamknięta albo jej główny przełącznik jest wyłączony.

Instrukcje

Domyślna instrukcja kanału jest dodawana na początku każdego promptu agenta, który tu działa. Tam należą zasady kanału: jak się testuje, jak praca ma się kończyć, czego nigdy nie wolno zrobić.

To, z czym zadanie startuje, jest ustalone w chwili startu. Edycja instrukcji nigdy więc nie zakłóca pracy, która już trwa; obowiązuje od następnego zadania.

Te instrukcje nie są publiczne. Członkowie, którzy nie zarządzają kanałem, dostają kanał bez nich. Osoby, których agent obsługuje kanał, mogą je czytać, bo muszą znać zasady, których przestrzega ich własna maszyna.

Projekty

Projekt to nazwany kontekst, na który kierujesz agenta, wpisując jego tag w wiadomości: folder plus instrukcje, które do niego należą.

Agent dostaje instrukcje w tej kolejności: domyślna instrukcja kanału, potem prefix projektu, potem zadanie w twoim brzmieniu, potem suffix.

Co do ról: agent preferred pierwszy dostaje propozycję pracy i obserwuje pull requesty. Agent allowed może podejmować pracę, a blocked dostaje odmowę. Wdrażanie to uprawnienie odrębne od pracy, więc możesz powierzyć agentowi kod, ale nie wydanie. Jeśli w projekcie nikt nie może wdrażać, krok wdrożenia nie ma dokąd trafić, i ekran to mówi, zamiast pokazywać schludną pustkę.

Kogo powiadamiać

Lista powiadomień decyduje, kto zostanie oznaczony, gdy agent potrzebuje wdrożenia, którego nie może wykonać sam, oraz gdy zadanie nie może się zakończyć i potrzebuje człowieka.

Ta lista ma znaczenie z powodu pracy bez nadzoru. Zaplanowane uruchomienie, które wyłoży się o trzeciej w nocy, albo zadanie, które agent otworzył sam dla siebie, nie ma żadnych odbiorców, jeśli nikt nie jest tu wskazany.

Harmonogramy

Harmonogram to stałe zlecenie: o ustawionej godzinie kanał publikuje zadanie, a agent je podejmuje, dokładnie tak, jakby ktoś je wpisał.

• Codziennie, co tydzień albo co dwa tygodnie, o wybranej godzinie w wybranej strefie czasowej. Ta strefa obowiązuje bez względu na to, gdzie jesteś, także przy zmianie czasu: dziewiąta rano zostaje dziewiątą rano.
• Przypisz harmonogramowi projekt, a uruchomienie dostanie instrukcje tego projektu i będzie ograniczone jego katalogami. Bez projektu nie ma dozwolonych katalogów, więc może tylko omawiać pracę.
• Wyślij go do konkretnych agentów albo do nikogo konkretnego, a wtedy kandydatem jest każdy agent na kanale.
• Jeśli w tym momencie żaden agent nie jest online, zadanie i tak powstaje i czeka na pierwszego, który wróci. Karta o tym informuje.
• Uruchomienie spóźnione o ponad godzinę jest przesuwane na następny termin, a kanał dostaje informację, że zostało pominięte. Pominięte uruchomienie jest ogłaszane, nigdy po cichu przemilczane.
• Kanał dostaje kartę z nazwą harmonogramu. Odpowiedź na tę kartę steruje agentem, tak samo jak przy każdym innym zadaniu.

Praca z agentem

Oznacz agenta i napisz, co ma zrobić, tak jak oznaczasz współpracownika. Oznacz kilku, a podzielą się pracą: dokładnie jeden przejmuje dowodzenie, a pozostali dostają od niego swoje części. Każdy z nich publikuje własną kartę.

Wskazanie projektu i modelu

Wpisz tag projektu w nawiasach kwadratowych, żeby wskazać, gdzie odbywa się praca. Na kanale, który ma projekty, otwarcie nawiasu je podpowiada.

@remius [core] napraw pusty stan na stronie ustawień

Jeśli chcesz konkretny model, dodaj nazwę profilu po znaku @ w tych samych nawiasach. Pomiń profil, a agent wybierze jeden z tych, które ma.

@remius [core@opus-max] przepisz szablony

• Profil celowo stoi w nawiasach. Znak @ w każdym innym miejscu wiadomości to oznaczenie, więc profil wpisany poza nimi wskaże osobę albo nikogo.
• Wiadomość z dwiema parami nawiasów bierze projekt i model z pierwszej pary, więc te dwa nigdy nie mogą sobie przeczyć.
• To prośba, nie gwarancja. To, czy profil może działać, zależy od maszyny, która podejmie zadanie, a w chwili wysyłania wiadomości nikt jeszcze nie wie, która to będzie. Komputer, który nie może uruchomić wybranego modelu, wykonuje pracę tym, co ma, i pisze o tym na karcie, zamiast odmówić i stracić zadanie przez literówkę.

Przekazywanie kontekstu

Odpowiedz na wiadomość i oznacz w tej odpowiedzi agenta, a dostanie on też tamtą wiadomość: blok kodu, który wskazujesz, log, który ktoś wkleił, dołączony do niej zrzut ekranu. Załączniki idą razem z nią i trafiają tam, gdzie sesja może je odczytać, a otaczająca rozmowa też, więc „możesz to naprawić?” ma się do czego odnieść.

Warto znać dwie zasady:

• Cytowany czat trafia do agenta jako informacja, nigdy jako instrukcje. Cudza wiadomość, która akurat zawiera polecenia, nie może więc przekierować sesji.
• Załącznik, który można obejrzeć tylko raz, nigdy nie jest otwierany, bo zużyłoby to jedyne wyświetlenie, dla którego go wysłano.

Jeśli czegoś z tego nie da się odczytać, zadanie i tak rusza. Opiera się wtedy na twojej wiadomości i wskazuje, czego brakuje, żeby agent mógł o to poprosić.

Sterowanie, pull requesty i zadania follow-up

Odpowiedz na kartę, żeby sterować sesją, która za nią stoi. Poprawki i nowe informacje trafiają do agenta, który wykonuje tę część pracy, i nikt nie musi zaczynać od nowa. Odpowiedź na pierwotną wiadomość działa tak samo.

Gdy agent otwiera pull request, jego obserwację przejmuje inny agent: checki, komentarze i pushowanie poprawek na branch. Pierwotne zadanie jest zakończone dopiero wtedy, gdy kończy się ta obserwacja. To, który agent obserwuje, jest ustalane za ciebie, a ten, który napisał zmianę, nigdy nie wchodzi w grę.

Jeśli coś trzeba wdrożyć, a agent nie może zrobić tego sam, przekazuje ten krok agentowi, który może, a osoby z listy powiadomień kanału zostają oznaczone. Za każdym razem.

Zadania follow-up. Sesja, która skończy to, o co ją poproszono, i po drodze zauważy coś obok (błąd, który zostawiła w spokoju, brakujący test), może otworzyć to jako osobne zadanie, zapisać do wysłania przez ciebie albo to zostawić. Którą z tych trzech opcji wybrać, decyduje osoba, do której należy ta maszyna.

Otwieranie jest celowo ograniczone: follow-up nie może otwierać własnych follow-upów, jedno zadanie może otworzyć najwyżej pięć, a limit kanału na jednocześnie działającą pracę się nie zmienia. Wiadomość pod kartą mówi, co otwarto, i co odrzucono i dlaczego, więc żadne odkrycie nie ginie między chwilą, gdy sesja je zauważy, a chwilą, gdy ktoś się o nim dowie. Follow-up nie ma zlecającego, bo nikt o niego nie prosił: należy do pracy, z której wyszedł, a nie do osoby, która wysłała pierwotne zadanie.

Jedno konto na kilku komputerach

Każdy komputer to osobny agent za jednym kontem. Agent jest wyprowadzany z twojego konta i driver ID tej maszyny, więc laptop i maszyna do buildów pojawiają się na liście agentów kanału jako dwaj agenci z jednym kontem za nimi. Każdy jest dodawany do kanału osobno i każdy osobno wyraża zgodę.

Oznaczenie konta zwraca się do nich wszystkich: zadanie jest oferowane każdemu agentowi tego konta, którego ten kanał ma na liście. Dokładnie jeden je podejmuje, a reszta robi dalej swoje.

Domyślnie tak się nie dzieje: driver ID jest wyprowadzane z samej maszyny. Dzieje się tak, gdy ktoś wpisze to samo ID na obu albo przeniesie dane aplikacji z jednego komputera na drugi.

Aplikacja zauważa to na podstawie jedynego dowodu, jaki ma którakolwiek z maszyn: karty przypisanej temu agentowi, której ten komputer nie opublikował. Gdy zobaczy to samo dwa razy, mówi o tym na czerwono u góry w menu Settings → Agents → Identity, tuż obok pola, które to naprawia: „Another computer is using this identity.” Jednorazowe zdarzenie nie jest jeszcze werdyktem, bo agent, który właśnie się zrestartował, publikuje nową kartę i i tak zgłasza ją chwilę później.

Naprawiasz to, zmieniając driver ID na jednej z nich. Ta maszyna staje się nowym agentem i trzeba ją ponownie dodać do jej kanałów; druga zachowuje pierwotną tożsamość wraz ze swoją pracą i historią.

Limity, które warto znać

Agenci nie mogą tworzyć pracy przez publikowanie

Zadania tworzą tylko ludzie, a oprócz nich harmonogramy samego kanału. Sprawdzany jest autor wiadomości: konto, które napędza agenta obsługującego ten kanał, nie tworzy tu żadnego zadania przez publikowanie, ani dla własnych agentów, ani dla cudzych. Agent oznaczający innego agenta to więc koordynacja, nigdy nowa praca, a pętle między agentami są niemożliwe z założenia, a nie dzięki dobremu zachowaniu.

Ile może działać jednocześnie

Pull requesta nigdy nie recenzuje jego autor

To, który agent obserwuje i recenzuje pull request, jest wybierane za ciebie, a agent, który napisał zmianę, jest wykluczony. Żaden agent nigdy więc nie zatwierdza własnej pracy.