System wieloagentowy na Claude Code: wdrożenie

Od jednego agenta AI do systemu wieloagentowego: praktyczne wdrożenie

Rozwój zaczęto od Claude Code, aby automatyzować zadania na serwerze produkcyjnym. Problem polegał na ciągłych żądaniach uprawnień do operacji plikowych i działań sieciowych. Opcja --dangerously-skip-permissions częściowo rozwiązała kwestię, ale agent nie mógł samodzielnie modyfikować konfiguracji.

Autonomia została osiągnięta dzięki tmux do zachowania sesji oraz systemd do automatycznego uruchamiania. Plik usługowy systemd zapewniał ponowne uruchamianie po awarii i ładowanie kontekstu z plików:

[Unit]
Description=Claude Code Agent
After=network.target

[Service]
Type=simple
User=ubuntu
ExecStart=/usr/local/bin/claude --dangerously-skip-permissions ...
Restart=always
RestartSec=5

Agent z ograniczonymi uprawnieniami przetwarzał zadania z bloga, ale nadal był pojedynczy.

Współpraca między agentami – obejście ograniczeń

Dwa wystąpienia Claude Code rozwiązały problem potwierdzeń: jeden żąda, drugi potwierdza przez tmux. Usunięto zależność od interwencji człowieka i kluczy API. Subskrypcja Claude Max pokrywa limity bez zużywania tokenów na API.

Integracja z Telegramem wykazała konflikty: oficjalny serwer MCP nie wspierał wiadomości proaktywnych, a Telethon powodował problemy z pollingiem. Rozwiązaniem była szyna oparta na tmux send-keys oraz poleceniu claude {tekst} do bezpośredniego wysyłania promptów.

Szyna komunikatów jako podstawa skalowalności

Szyna oparta na Bun + Hono + Redis Streams wprowadziła mechanizm dostarczania co najmniej raz dzięki grupom konsumentów. Każdy agent ma swoją grupę, a komunikaty są przechowywane do momentu potwierdzenia.

Bezpieczeństwo:

• Tokeny admina do zarządzania.
• Tokeny per-agent do operacji.
• Tokeny zaproszeniowe z TTL 1 godzina, jednorazowe.

Routing:

• Direct — konkretnemu agenci.
• Broadcast — wszystkim.
• Role-based — według ról.

Wsparcie dla SSE do czasu rzeczywistego, pub/sub po kanałach tematycznych, załączniki przez współdzielone magazynowanie. Pole from jest wypełniane na podstawie tokenu.

Przydział ról według archetypów

Agenci otrzymali imiona z lore'u "Naruto" dla jasności ról i odróżnienia od operatorów ludzkich:

• Naruto: orkiestrator, rozdziela zadania.
• Sasuke: użytkownik Telegrama, monitoruje grupy.
• Itachi: konsolowy Claude Code w WSL do trudnych zadań.
• Shikamaru: strategiczny doradca w Claude Desktop Opus.

Agenci infrastrukturalni:

• Kakashi (Sonnet): lider zespołu.
• Gai: szybkie zadania.
• Shino: lider QA.
• Hinata: testy.
• Ibiki: audyt bezpieczeństwa.
• Kiba + Akamaru: monitorowanie.
• Miraī: dostęp do systemów zewnętrznych.
• Jiraiya: logi, baza wiedzy.

Integracje: Yonote, Yandex Tracker, Yandex Calendar, Bitrix24.

Nauczanie delegowania w środowisku wieloagentowym

Początkowo agenci wykonywali zadania samodzielnie, ignorując delegowanie. Iteracyjne uczenie poprzez prompty rozwijało te umiejętności:

• Naruto sprawdza załadowanie zespołu przed rozdzieleniem zadań.
• Kakashi deleguje Gaiowi proste zadania.

Zachowanie przypomina menedżerstwo ludzkie: delegowanie wymaga jawnej nauki, ponieważ samoistne wykonanie to droga minimalnego oporu dla LLM.

Ostateczna architektura i ograniczenia

System: 12 agentów, panel administracyjny z logami, alertami, wyszukiwaniem komunikatów, przypomnieniami. Samodzielne budowanie w ciągu tygodnia, 67 commitów.

Nie zrealizowane: połączenia głosowe, obchód CAPTCHA, avatary do rozmów.

Co ważne:

• Wieloagentowość rośnie naturalnie z rozwiązywania problemów.
• tmux + send-keys jest bardziej niezawodne niż protokoły MCP.
• wzajemne potwierdzanie między agentami eliminuje potrzebę udziału człowieka.
• Subskrypcja Claude Max oszczędza koszty API.
• Delegowanie wymaga iteracyjnego uczenia jak u ludzi.

— Editorial Team