Jeden agent, wielu specjalistów: dlaczego osobisty AI powinien kierować pracą, a nie robić jej sam.
Osobisty asystent AI funkcjonuje lepiej jako orkiestrator: kieruje zadania do agentów programistycznych, modeli oraz zwykłych skryptów, przy czym uprawnienia są stopniowane.
Źródła: I Stopped Trying to Build One AI Agent That Does Everything
Qwen, Nemotron, Gemma, DeepSeek. Inferencja lokalna, AWS Bedrock, Azure. Różne środowiska działania, różne rozmiary, różne ceny, różne stopnie rozczarowania. Długa seria eksperymentów z Hermesem, Codexem, OpenCode, modelami lokalnymi oraz API chmurowymi zwykle zaczyna się od przekonania, że istnieje jeden prawidłowy model do znalezienia. Prędzej czy później okazuje się to błędnym założeniem. Za nim kryje się drugie założenie, o wiele ciekawsze: dlaczego sam agent osobisty miałby robić wszystko?
Marzenie o Jarvisie
Pierwsza architektura jest niemal żenująco prosta: człowiek, potem jeden agent, a potem wszystko inne.
Wiadomości skierowane do tego agenta mogą brzmieć: sprawdzenie postępów w projektach, naprawa problemu w jednym z repozytoriów, przygotowanie listy wydarzeń na jutro, zgłoszenie informacji o stanie zdrowia serwera Linux, zbadanie określonego tematu i przekazanie najważniejszych informacji. Agent ma za zadanie zajmować się tym wszystkim.
Brzmi to wspaniale, ale właśnie w tym miejscu zaczynają się problemy, ponieważ wszystko to stanowi ogromną powierzchnię API.
Dla niektórych zadań istnieją już lepsze narzędzia
Najwyraźniejszym przykładem jest programowanie. Codex i OpenCode to nie tylko okna czatu przypisane do modelu – działają one w środowisku programistycznym. Rozumieją strukturę repozytoriów, czytają i wyszukują pliki, edytują kilka plików jednocześnie, uruchamiają polecenia, analizują błędy, przeprowadzają testy, sprawdzają różnice między wersjami plików i iterują. To naprawdę zaawansowane narzędzia specjalistyczne.
A teraz załóżmy, że osobistemu agentowi polecono wdrożyć nową funkcję w projekcie. Istnieją dwa możliwe podejścia.
Podejście A. Daj agencie bardzo potężny model, dostęp do systemu plików oraz dostęp do wiersza poleceń. Naucz go operacji w repozytorium. Stwórz mechanizmy zarządzania kontekstem, obsługi różnic, wykonywania poleceń, pętli testowych oraz przywracania po błędach. Ciągle doskonal proces programowania. Gratulacje: agent programistyczny jest budowany od zera.
Podejście B. Agent rozpoznaje zadanie programistyczne i przekazuje je Codexowi lub OpenCode’owi. To oczywiście rozsądniejsze rozwiązanie.
Asystent nie musi być najlepszy we wszystkim
To prawdziwa zmiana sposobu myślenia. Asystent osobisty nie musi być najlepszym programistą, badaczem, inżynierem DevOps, planistą ani systemem wiedzy na świecie. Musi wiedzieć, kto powinien wykonać pracę. To inna odpowiedzialność, a być może nawet ważniejsza.
Organizacje ludzkie funkcjonują w ten sam sposób. Dyrektor generalny nie pisze każdej funkcji backendowej, nie konfiguruje każdego klastra Kubernetes, nie bada każdego rynku, nie tworzy każdej tabeli kalkulacyjnej, nie umawia każdego spotkania ani nie odpowiada na każdą prośbę o wsparcie. Ich wartość wynika częściowo z rozumienia tego, co musi się wydarzyć, kto powinien to zrobić oraz czy rezultat jest akceptowalny. Orkiestrator AI osobisty można postrzegać w tych kategoriach. Nie wykonywa on każdego zadania – rozumie intencję na tyle dobrze, by prawidłowo kierować pracą.
Inny kształt systemu
Zastąp łańcuch składający się z osoby, agenta, jednego ogromnego modelu i wszystkiego innego czymś w rodzaju tego:
┌──────────────┐
│ Me │
└──────┬───────┘
│
▼
┌─────────────────┐
│ Google Chat │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Hermes │
│ Orchestrator │
└────────┬────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Coding Agents AI Models Tools
Codex/OpenCode Local / Cloud APIs / Servers
│ │ │
└─────────────────┼──────────────────┘
│
▼
Final Result
Zadanie agenta staje się znacznie jaśniejsze. Rozumie on osobę, zna dostępne możliwości, wybiera odpowiednią opcję, dostarcza niezbędnego kontekstu, obserwuje wynik i składa raport. To właśnie jest asystent, który naprawdę warto mieć.
Chat jako jedyny punkt wejścia
Aplikacja do czatowania, takia jak Google Chat, nabiera sensu w takim podejściu. Nie powinna ujawniać leżącej u jej podstaw złożoności. Z perspektywy użytkownika istnieje jedna rozmowa. Wiadomość typu „sprawdź, czy dziś z projektem X nie wydarzyło się nic ważnego” może skłonić agenta do sprawdzenia systemu zadań, przejrzenia GitHuba, sprawdzenia stanu serwera, przeczytania odpowiednich materiałów, być może poproszenia innego modelu o analizę czegoś, a następnie stworzenia podsumowania. Użytkownik nie powinien musieć o tym wiedzieć ani otwierać pięciu aplikacji. Interfejs reprezentuje intencję, a wszystko poniżej to implementacja.
Kodowanie jako przykład modelu
Zdjęcie przedstawiające osobę z dala od komputera. Wiadomość w telefonie informuje o problemie w procesie autoryzacji projektu X i prosi o naprawę, jeśli jest to możliwe. W zasadzie proces przebiega w następujący sposób: agent określa, o który projekt chodzi, zbiera wystarczająco dużo informacji, by znaleźć repozytorium, stwierdza, że kod musi zostać zmodyfikowany, i przekazuje zadanie agentowi zajmującemu się programowaniem. Codex lub OpenCode otwiera repozytorium, bada jego zawartość, edytuje odpowiednie pliki, uruchamia testy, sprawdza różnice i zwraca wynik. Orkiestrator otrzymuje ten wynik i raportuje coś w rodzaju: walidacja tokena odświeżania użyła niewłaściwej warunku wygaśnięcia, agent programistyczny to naprawił, odpowiednie testy przeszły pomyślnie, a oto co zostało zmienione.
Nie ma większego znaczenia, który model wygenerował dany token w danym momencie. Ważne jest to, że zadanie zostało wykonane prawidłowo.
Modele stają się infrastrukturą
Gdy agent staje się warstwą orkiestracji, pytania takie jak to, czy użyć Qwen, DeepSeek, lokalnego modelu, Bedrock czy Azure, przestają się wykluczać. Odpowiedź może być prosta – tak, przy czym różne zadania wymagają różnego poziomu inteligencji. Mały lokalny model zajmuje się prostym routowaniem. Tani model chmurowy tworzy streszczenia. Silniejszy model analityczny podejmuje trudne decyzje. Agent do programowania zarządza repozytoriami. Inny specjalista zajmuje się innymi zadaniami. Modele stają się infrastrukturą, a infrastruktura powinna być wymienna.
Unikanie zależności od jednego dostawcy
Modele zmieniają się z absurdalną szybkością. To, co dziś wydaje się oczywistym wyborem, po sześciu miesiącach może wyglądać przeciętnie. Ceny się zmieniają, dostawcy się zmieniają, modele otwarte się udoskonalają, okna kontekstowe się powiększają, funkcje wywoływania narzędzi stają się lepsze, a pojawiają się nowe architektury inferencji. Jeśli cała osobista konfiguracja zakłada, że Model X robi wszystko, zmiana jest uciążliwa. Lepszym rozwiązaniem jest:
Task
↓
Router
↓
Best available capability
Dziś ostatnim krokiem może być jeden dostawca, a jutro inny, a proces powinien być od tego niezależny.
Router może być ważniejszy niż model
Sporo czasu poświęca się porównywaniu modeli: model A ma ocenę 74, model B – 78, model C obsługuje milion tokenów kontekstu, model D jest o 60 procent tańszy. Te informacje są przydatne. Teraz wyobraźmy sobie system, który wie, że model A jest najlepszy do określonych zadań analitycznych związanych z programowaniem, model B jest szybki i tani do klasyfikacji, model C jest niepotrzebny, ponieważ zapytanie można odpowiedzieć lokalnie, inne zapytanie w ogóle nie wymaga LLM, wystarczy wywołanie API, jedno zapytanie powinno trafić bezpośrednio do Codex, a inne wymaga pytania do użytkownika przed podjęciem jakichkolwiek działań.
Tutaj część inteligencji tkwi w systemie, który decyduje o sposobie jej wykorzystania, co jest o wiele ciekawsze niż kolejna lista liderów.
Nie każdy krok wymaga LLM
Agenci sprawiają, że łatwo o to zapomnieć. Gdy zostanie zadaane pytanie, czy serwer jest online, agent nie potrzebuje modelu rozumowania z 200 miliardów parametrów, aby zastanowić się nad tym, czy serwer istnieje. Wykonuje sprawdzenie stanu, interpretuje wynik i odpowiada. Gdy zostanie zapytane, ile miejsca na dysku pozostało, wykonywane są następujące czynności:
df -h
Następnie analizuje wynik i odpowiada. Drogi model rozumowania na każdym kroku to nie inteligencja – czasami to po prostu kiepska projektowa decyzja.
Prawa dostępu
Gdy agent może delegować zadania, pojawia się trudniejszy problem: co może robić? Czytanie kalendarza różni się od wysyłania e-maila. Czytanie repozytorium różni się od łączenia pull requesta. Sprawdzanie serwera znacznie różni się od usuwania plików. Dlatego przydatny agent osobisty potrzebuje modelu uprawnień wraz ze swoimi narzędziami, mniej więcej w takim wydaniu:
- Czytanie odbywa się bez pytania.
- Przygotowywanie projektów i planów odbywa się bez pytania.
- Działania o niskim ryzyku mogą być wykonywane samodzielnie.
- Wszystko, co ma istotne konsekwencje, wymaga zatwierdzenia człowieka.
Gdy pracownik zostanie poproszony o ustalenie przyczyny awarii usługi, może od razu zająć się tym zadaniem. Jeśli stwierdzi, że baza danych jest uszkodzona i planuje ją usunąć oraz odtworzyć, najpierw powinna nadejść potwierdzenie. Autonomia nie powinna być binarna – powinna być dostosowywana w zależności od poziomu ryzyka.
Pamięć i kontekst
Kolejnym powodem przeciwko przekształcaniu każdego specjalistycznego narzędzia w osobistego asystenta jest kontekst. Codex powinien rozumieć strukturę repozytorium, ale nie całe życie użytkownika. Narzędzie infrastrukturalne powinno znać serwery, a nie każdą kiedykolwiek odbytą rozmowę. Kalendarz informuje o spotkaniach, a menedżer zadań o zadaniach. Orchestrator może stać się warstwą, która rozumie, jak te systemy ze sobą współpracują.
Rozważmy kwestię tego, co dzieje się w konkretnym projekcie. Żadne pojedyncze zapytanie do bazy danych nie może na nią odpowiedzieć. Dobra odpowiedź opiera się na najnowszych pracach nad rozwojem, aktywności na GitHubie, zadaniami, wcześniejszych decyzjach, stanie wdrożenia oraz tym, co użytkownik planował zrobić dalej. To właśnie w tym kontekście międzysystemowym warstwa osobistej orkiestracji staje się naprawdę cenna.
Pułapka nadprojektowania
Zagrożenie jest oczywiste. Taki sposób myślenia ułatwia narysowanie czegoś takiego jak ten diagram:
User
↓
Intent Classifier
↓
Planning Agent
↓
Model Router
↓
Memory Agent
↓
Permission Agent
↓
Coding Agent
↓
Validation Agent
↓
Reflection Agent
↓
Supervisor Agent
↓
Another Agent Watching the Other Agents
A potem spędzenie trzech miesięcy na budowie organizacji opartej na sztucznej inteligencji tylko po to, by móc zapytać, co jest dziś zaplanowane. To nikomu nie pomaga. Lekcją z całego tego eksperymentu jest to, że złożoność musi zasłużyć na swoje miejsce. Dwanaście agentów tylko dlatego, że diagram architektury wygląda fajnie, to zły powód. Zdolności, które wielokrotnie oszczędzają czas, to dobry powód.
Delegowanie przed autonomią
Całkowicie autonomiczne agenty przyciągają dużo uwagi: daj im cel, pozostaw je w działaniu na godziny, pozwól im rozmawiać i decydować między sobą, a potem wróć, gdy wszystko będzie skończone. To ciekawe, ale to nie jest odpowiednie miejsce na rozpoczęcie pracy z osobistym systemem. Bardzo niezawodne delegowanie powinno poprzedzać maksymalną autonomię. Celem jest polecenie wykonania zadania X i sprawienie, by system niezawodnie wybrał odpowiedni narzędzie lub agenta oraz poinformował o tym, co się stało. Gdy to będzie działać doskonale, autonomia może być stopniowo zwiększana.
Więcej specjalistycznych narzędzi, a nie mniej
Na początku cel wydaje się być konsolidacją: zbyt wiele narzędzi AI, więc należy stworzyć jedno AI, które je zastąpi. Okazuje się to błędem. Ostateczny stan może obejmować więcej specjalistycznych systemów AI, przy czym różnica polega na tym, że nie wymagają one już indywidualnego zarządzania, co właśnie rozwiązuje warstwa orkiestracji. Przyszłość może przynieść nie tyle jedno AI rządzące nimi wszystkimi, ile jedną interfejs do ich koordynacji. Różnica jest subtelna, ale znacząca.
Do czego służy agent
Po uruchomieniu takiego systemu, uszkodzeniu niektórych elementów, podłączeniu interfejsu do czatu, przetestowaniu różnych modeli oraz głębokim zastanowieniu się nad specjalistycznymi agentami programistycznymi, na pierwszy plan wysuwa się rola agenta osobistego. Nie musi to być najsprytniejszy AI w całym zestawieniu – musi to być ten, który zna daną osobę oraz jej systemy. Powinien rozumieć, o co jest proszony, jaki kontekst ma znaczenie, która funkcja jest odpowiednia, co może zrobić, kiedy potrzebuje potwierdzenia oraz jak przekazać wynik. To wystarczy, a wszystko inne można delegować.
Architektura, której warto pragnąć
Przyszły kształt systemu wygląda mniej więcej tak:
ME
│
▼
GOOGLE CHAT
│
▼
┌─────────────────┐
│ HERMES │
│ │
│ Intent │
│ Context │
│ Memory │
│ Permissions │
│ Orchestration │
└────────┬────────┘
│
┌──────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
AI MODELS CODING AGENTS TOOLS
│ │ │
Local / Cloud Codex/OpenCode GitHub/APIs
Fast / Strong Servers/Tasks
│ │ │
└──────────────────┼───────────────────┘
│
▼
HERMES
│
▼
ME
Kluczowe nie jest posiadanie oddzielnej skrzynki. Wszystko, co znajduje się poniżej systemu koordynującego, powinno w końcu być wymienialne. Pojawia się lepszy agent kodujący – wystarczy go zastąpić. Pojawia się lepszy lokalny model – również go zastąpić. Inferencja w chmurze staje się tańsza – należy kierować tam więcej zadań. Dostawca okazuje się niewiarygodny – trzeba go ominąć. Przeprojektowywanie sposobu używania asystenta za każdym razem, gdy zmienia się branża AI, nie powinno być konieczne.
Osobisty AI, być może w odwrotnym kierunku
Większość produktów AI konkuje o to, jak inteligentny jest model, co jest zrozumiałe. Jednak w miarę dalszego doskonalenia się modeli rośnie znaczenie kolejnego aspektu: koordynacji. Oznacza to umiejętność zrozumienia intencji osoby, kontekstu, których systemów jest ważnych, jakie narzędzia istnieją, który model się nadaje, jakie działania są bezpieczne, kiedy należy zadać pytanie oraz kiedy w ogóle nie należy korzystać z AI. Asystent, który warto mieć, to niekoniecznie ten z najwyższą oceną w testach. To ten, który sprawia, że cała inteligencja i oprogramowanie wokół osoby funkcjonują jak jeden spójny system.
Krótkie podsumowanie
Punktem wyjścia jest pragnienie posiadania osobistego agenta AI. Wdrożenie takiego agenta pokazuje, że trwały asystent to w rzeczywistości problem infrastrukturalny. Poszukiwanie idealnego modelu ujawnia, że wybór modelu to w istocie problem routingu. Decydowanie o tym, co powinien robić agent, pokazuje, że osobisty asystent może w gruncie rzeczy stanowić problem orkiestracji. Architektura przechodzi od poszukiwania najmądrzejszego modelu i dostarczania mu wszelkich narzędzi do systemu, który rozumie intencję i kieruje zadania we właściwe miejsce. To znacznie mniej „magiczny” opis Jarvisa, ale o wiele bliższy temu, co faktycznie można zbudować i używać na co dzień.
Literatura pokrewna
- Stwórz agenta planistycznego w LangGraph: planuj, wykonywaj, planuj ponownie, raportuj — Czterowęzłowy agent planistyczny LangGraph do badań finansowych: ustrukturyzowane plany, rejestr narzędzi świadomy przestrzeni nazw, ograniczenia planowania ponownego oraz zapisany przykład wykonywania.
- MiniCPM5-2B kontra konkurencja 4B: dlaczego podejście oparte na agentach pokazuje inne wyniki — Model o pojemności 2,5 miliarda parametrów, który przewyższa konkurencję 4B w testach jednorazowych, jest dwa do trzech razy wolniejszy w zastosowaniach opartych na agentach. Problemy z wersją indeksu, lokalna wydajność i sytuacje, w których to podejście jest odpowiednie.