Agenty

https://xpil.eu/pF09R 📋

Od kilku lat w każdą sobotę rano zabieram Młodego na basen. Sam nie umiem pływać (z wyjątkiem pionowo w dół, ale to każdy głupi potrafi), ale to nie znaczy od razu, że moje dzieci też mają nie umieć.

Nie mają umieć?

Siedząc na basenie przeważnie nadrabiam zaległości w lekturze RSS-ów. A więc stary tablet z klientem Tailscale, podłączony przez przeglądarkę do instancji Miniflux siedzącej na Dockerze na domowym komputerze (rym przypadkowy). Młody - ku mej zazdrości - śmiga z łatwością kolejne długości basenu kraulem bądź też delfinkiem, a ja w tym czasie czytam co tam inni blogerzy wypisują.

W ramach coraz śmielszego eksperymentowania z LLM-ami postanowiłem dziś rano przeprowadzić następujący eksperyment: włączyłem VS Code, uruchomiłem wtyczkę Codex, przestawiłem ją w tryb całkowicie autonomiczny bez ograniczeń i poprosiłem o przemigrowanie Minifluxa z maszyny A na maszynę B. Zasugerowałem mu tylko, żeby nie wykonywał żadnych operacji kasujących dane na maszynie A, oraz że ma do obydwu maszyn dostęp przez ssh (bez hasła) oraz sudo (również bez hasła). A także objaśniłem, że Miniflux siedzi na Dockerze.

Większość pleno titulo Czytelników obeznanych z tematem zapewne w tej chwili puka się z politowaniem w czoło. Zdurniał chłop!

A ja mówię: leap of faith.

Dygresja

"...uruchomiłem wtyczkę Codex, przestawiłem ją w tryb całkowicie autonomiczny..." - tak mogłaby zaczynać się powieść o tym, jak Skynet przejął kontrolę nad Siecią 🙂

Koniec dygresji

No więc przykazałem agentowi wykonać migrację, po czym zgarnąłem Młodego do auta i pojechaliśmy na basen. W samochodzie gadka szmatka, jakoś mi się zapomniało o tej całej migracji. Docieramy na miejsce; Młody hyc do basenu, ja odpalam tablet, zaglądam na Minifluxa, czytam sobie pierwszy artykuł... i cóś mię tkło. Wszystko działało jak trzeba, więc albo migracja się udała, albo się nie udała 🙂 Tertium non datur.

Nie mam z tableta możliwości zajrzenia na pulpit domowego kompa... ale mam klienta ssh. Loguję się więc po ssh na komputer A, uruchamiam sudo docker ps... - a tam ani śladu po Minifluxie.

Dla pewności przełączam się na przeglądarkę, odświeżam... nie, no wszystko działa jak trzeba.

Już bardziej dla formalności zaglądam po ssh na komputer B i widzę, że sudo docker ps wypluwa dokładnie to, czego się spodziewałem:

CONTAINER ID   IMAGE                        COMMAND                  CREATED       STATUS       PORTS     NAMES
8d461b5db520   miniflux/miniflux:latest     "/usr/bin/miniflux"      2 hours ago   Up 2 hours             rss
925e0fc1fd9d   postgres:17-alpine           "docker-entrypoint.s…"   2 hours ago   Up 2 hours             rss-db
dcc0dc4931ff   tailscale/tailscale:latest   "/usr/local/bin/cont…"   2 hours ago   Up 2 hours             rss-tailscale

Wszystkie trzy kontenery śmigają jak trzeba i gadają ze sobą bez zająknięcia, jakby nigdy nic.

Zaglądam jeszcze w Uptime Kuma (rozwiązanie monitorujące, które sobie jakiś czas temu postawiłem, żeby mnie alarmowało jak któraś z maszyn pójdzie w maliny) i okazało się, że między zniknięciem starej instancji Minifluxa z sieci a pojawieniem się nowej upłynęło około 12 minut. Tyle czasu potrzebował autonomiczny agent na całe zadanie.

Obstawiam, że sam bym się w 12 minut nie wyrobił. Albo może tak, ale z pomocą jakiegoś LLM-a 😉

Dla ludzi spoza branży to może nie jest nic nadzwyczajnego. Mi się trochę podniosły włosy na przedramieniach.

Na przedramionach?

No bo tak: kiedyś człowiek musiał obciosać patyk kamieniem, żeby zapolować na mamuta, z wielkim prawdopodobieństwem, że zostanie przezeń rozdeptany i z obiadu nici. A dziś mówię agentowi, żeby przemigrował Dockera z jednej maszyny na drugą i 12 minut później pieczeń z mamuta paruje na półmisku, z sosem, sztućcami i łagodnym jazzem w tle.

Dziwne czasy.

Dopisane pod wieczór

Przejrzałem logi z tego zadania i okazało się, że migracja wcale nie była taka prosta, jak by się mogło wydawać. Najpierw agent próbował zalogować się przez ssh na konto root - kiedy się nie udało, wykombinował, że ssh lepiej działa z bieżącym użytkownikiem i dalej sudo. Potem zatrzymał starą instancję. Zarchiwizował ją do pliku .tar. Skopiował archiwum na docelowego hosta używając rsync. Rozpakował, zweryfikował czy rozmiary folderów się zgadzają. A potem poległ na uruchamianiu nowej instancji, bo się okazało, że tam nie ma Dockera 🙂 Na instalacji Dockera miał kilka time-outów (po każdym zwiększał odrobinę czas oczekiwania na zakończenie polecenia), potem jeszcze sprawdził, czy komendy docker i docker-compose się odzywają bez błędów - i dopiero wtedy podjął kolejną próbę podniesienia instancji docelowej. Na koniec sprawdził stan wszystkich kontenerów - ponieważ nie zgłaszały żadnych błędów, uznał misję za zakończoną sukcesem (jak się okazało - słusznie).

Coś całkiem interesującego wydarzyło się natomiast później. Otóż poprosiłem go o wykonanie kopii zapasowej starej instancji i skopiowanie jej do osobnego folderu, gdzie trzymam backupy. Zrobił to bez pudła.

A potem poprosiłem go o skasowanie starej instancji - w dwóch etapach. Najpierw miał mi podać komendę usuwającą starą instancję, ale bez jej wykonywania. Wymyślił: sudo rm -rf /folder/ze/starą/instancją/. Sprawdziłem, że wszystko się zgadza. Powinienem teraz był po prostu wykonać tę komendę własnoręcznie w osobnym terminalu, ale jak się bawić to się bawić - przykazałem agentowi wykonanie tego rm -rf - spróbował i dostał wiadomość od swojego shella, że wykonywanie komend destrukcyjnych jest odgórnie zablokowane przez politykę bezpieczeństwa wtyczki. Zamiast mnie jednak o tym poinformować i zatrzymać działanie... obszedł politykę używając komendy find z flagą -delete 🙂 I to już zadziałało bez pudła.

A więc Microsoft, owszem, próbuje udawać, że pilnuje swoich elemelków, ale elemelki wiedzą lepiej i robią swoje.

Może to jeszcze nie Skynet, ale i tak jest ciekawie.

https://xpil.eu/pF09R 📋