Wyjaśnienia funkcji 01: Silnik orkiestracji Agent Argo

Od pierwszego zlecenia do zweryfikowanego patcha

Agent Argo nie składa się z pojedynczego modelu, który najdłużej pracuje nad zadaniem. To system, który tłumaczy pracę programistyczną na śledzone kroki: planowanie, dzielenie, wykonywanie, sprawdzanie, korygowanie i dopiero wtedy przedstawianie do przejęcia.

Z tym wpisem zaczyna się seria „Wyjaśnienia funkcji”. Ujawnia ona kluczowe mechanizmy Agent Argo – nie jako obietnice marketingowe, ale w oparciu o ich rzeczywiste zastosowanie. Pierwszym jest silnik orkiestracji: przebieg, który zamienia wymóg w kontrolowany proces pracy.

flowchart LR
    A[Zlecenie] --> B[Ustawienia przed uruchomieniem]
    B --> C[CEO tworzy plan]
    C --> D[Graf zadań i kolejność]
    D --> E[Kontekst, wybór modelu i wykonywanie]
    E --> F[Obsługa błędów i korekta]
    F --> G[Przegląd i weryfikacja]
    G --> H[CEO podsumowuje]
    H --> I[Sprawdź lub zastosuj patch]

1. Przed startem: ustal jakość, koszty i autonomię

Zanim Argo przystąpi do zadania, ważne są dwie decyzje. Są one celowo odseparowane:

1. Jak Argo ma bilansować koszty i jakość wyniku?
2. Jak samoistnie Argo może działać w projekcie?

To zapobiega typowemu konfliktowi celów: dokładne uruchomienie nie musi automatycznie oznaczać większych uprawnień do zapisu. A autonomiczne uruchomienie nie musi automatycznie wybierać drogich modeli.

Trzy poziomy kosztów i jakości

Router modeli zna trzy zrozumiałe tryby. Zmieniają one, jak silnie cena i poziom modelu wpływają na wybór; wymagana umiejętność zawsze pozostaje centralna.

Poziom	Tryb routera	Odpowiedni dla
Oszczędny	economy	Zadania rutynowe, ekstrakcja, jasno ograniczone zmiany. Koszt waży mocno.
Zrównoważony	balanced	Standard dla większości uruchomień: dopasowanie umiejętności, koszty i poziom jakości w równowadze.
Wymagający	expert	Architektura, research, złożone analizy i wymagające recenzje. Poziom modelu waży znacznie mocniej, koszt mniej.

Profile operacyjne Szybko i tanio, Zrównoważony i Gruntownie pakują ten tryb routera z dalszymi decyzjami: np. czy wspólne myślenie jest tylko obserwowane czy aktywnie wykonywane, czy weryfikacja jest wiążąca i czy Argo przy niepowodzeniu może mocniej eskalować.

Trzy poziomy autonomii

Autonomia nie reguluje, co Argo uważa za dobre, ale kiedy do tego potrzebuje człowieka.

Poziom	Zachowanie
Bezpieczny	Argo analizuje i planuje. Zmiany pozostają do przeglądu; przed akcjami zapisu lub ryzykownymi pyta.
Zrównoważony	Normalne zmiany mogą powstać w izolowanym stanie roboczym. Przy usuwaniu, poleceniach, pobieraniu, dostępie do sieci lub chronionych ścieżkach Argo dalej pyta.
Pełnie autonomiczny	Uruchomienie działa bez zwykłych pytań. Twarde granice bezpieczeństwa, polityki i budżetu wciąż obowiązują.

W kodzie te zasady są precyzyjniej zaimplementowane jako readonly, confirm_write, auto_write i bypass. Trzy poziomy je ułatwiają; polityka projektu pozostaje jednak ostateczną instancją. Może np. wykluczać dostawców chmury, pozwalać tylko na modele lokalne, blokować dostęp do sieci, ograniczać komendy, chronić sekrety lub ustawiać limit kosztów.

2. Poziom CEO zamienia zlecenie w plan

Użytkownik najpierw opisuje cel w zwykłym języku. Poziom CEO Argo otrzymuje do tego ograniczony przegląd projektu, dostępny katalog modeli i istotne informacje o projekcie. Może przy otwartych pytaniach najpierw zapytać lub wygenerować plan.

Plan nie zawiera tylko listy zadań. Każde zadanie otrzymuje rolę, opis, zależności i potrzebne umiejętności – np. coding, planning, qa_review lub context_comprehension. Dla trudnych zadań można też zaznaczyć wyższą trudność. Poziom CEO nie narzuca sztywno modelu: opisuje pracę, a router decyduje później dla każdego zadania o odpowiednim modelu.

Plan pozostaje tak czytelną dla ludzi umową o przedsięwzięciu, podczas gdy wykonanie może pozostać adaptacyjne.

3. Z planu powstaje graf zadań

Po zatwierdzeniu planu Argo zamienia zadania w graf zadań. Węzeł może się uruchomić, gdy jego zależności zakończyły się sukcesem. Niezależne zadania mogą działać równolegle.

Harmonogram sortuje gotowe węzły według przejrzystej heurystyki użyteczności: oczekiwana jakość minus kara za koszty, czas i ryzyko. Jeśli węzeń leży na ścieżce krytycznej, przy remisie otrzymuje priorytet, bo decyduje o całkowitym czasie trwania uruchomienia.

Przy dużej niepewności lub ryzyku Argo może przed wykonaniem wybrać tryb wspólnego myślenia: kilka perspektyw rozwija podejścia, nawzajem je krytykuje i dostarcza uzasadnione podejście robocze dla Workera. Czy to jest tylko protokolowane czy faktycznie wykonywane, decyduje wybrany przed uruchomieniem profil operacyjny.

4. Przed każdym zadaniem: odpowiedni kontekst, odpowiednie umiejętności, odpowiedni model

Zanim Worker się uruchomi, Argo buduje kontekst dopasowany do roli i zadania. Do tego należą odpowiednie pliki, wyniki zależności oraz – jeśli aktywne – kompaktowy pakiet pamięci i odpowiednie przewodniki umiejętności. Argo nie bierze ślepo całej wiedzy projektu do promptu. Pamięć i umiejętności są wybierane według istotności, pochodzenia, aktualności, kosztów i statusu bezpieczeństwa.

Następnie router modeli wybiera model. Najpierw wyklucza kandydatów, którzy nie są osiągalni, nie mają wystarczającego okna kontekstu, których kontyngent się wyczerpał lub którzy naruszają aktywną politykę. Z pozostałych modeli Argo ocenia cztery czynniki:

• Dopasowanie umiejętności: Jak dobrze model jest oceniany pod kątem potrzebnych umiejętności? Przy wielu umiejętnościach bierze się średnią.
• Koszt: Jak drogie jest zapytanie – lub przy aktywnym routingu kosztów przewidywany udany wynik?
• Poziom modelu: Trudne, krytyczne dla bezpieczeństwa, architektoniczne i recenzyjne zadania mogą preferować flagowy poziom.
• Doświadczenia: Po wystarczającej liczbie rzeczywistych wyników wpływają najnowsze wskaźniki sukcesu i powtarzalności kombinacji model/umiejętność.

Do obliczeń kosztów Argo może wykorzystać Oczekiwany koszt sukcesu: cenę bezpośrednią, oczekiwane ponowne próby, nakład na weryfikację, ewentualną dopracowanie i małą karę za opóźnienie. Tani pojedynczy wywołanie nie jest więc automatycznie najtańszym rozwiązaniem, jeśli często kończy się niepowodzeniem lub wywołuje dopracowanie.

Wysłana rekomendacja modelu jest akceptowana tylko, jeśli jest dostępna, dozwolona przez politykę i wystarczająco duża dla kontekstu. Planowanie, delegacja i zrozumienie kontekstu poziomu CEO znowu używają silnego modelu, wybranego specjalnie dla tych trzech umiejętności.

5. Worker wykonuje zadanie w małych, weryfikowalnych krokach

Worker nie pracuje z jedną odpowiedzią. Przechodzi ograniczoną pętlę ReAct:

1. Model proponuje strukturalne akcje – np. czytanie plików, wyszukiwanie, uruchamianie testów lub zapisywanie zmian.
2. Executor sprawdza uprawnienia, ścieżkę, ryzyko komendy i aktywną politykę.
3. Argo wykonuje tylko dozwolone akcje.
4. Wyniki, diffy i komunikaty błędów wracają jako obserwacja do modelu.
5. Na tej podstawie Worker koryguje swój następny krok lub kończy zadanie.

Dzięki temu Agent może np. najpierw przeczytać dotknięty kod, potem wprowadzić zmianę, uruchomić test i wpleść wynik testu w następną decyzję. Pełny przebieg pozostaje widoczny w dzienniku uruchomienia.

Sama wyjście też jest sprawdzane. Jeśli model dostarcza nieprawidłowy JSON akcji, Argo może zażądać ograniczonej pętli naprawczej. W trybie ścisłym trwale błędne wyjście jest kontrolowanie odrzucane, zamiast niejasnego tekstu interpretować jako akcję.

6. Przy błędach: celowo korygować zamiast ślepo powtarzać

Nie każde nieudane zadanie oznacza, że całe uruchomienie się nie powiodło. Silnik orkiestracji rozróżnia przyczyny błędów i reaguje kontrolowanie:

• Błąd tymczasowy może zostać ponowiony w ustalonych granicach.
• Twarde stwierdzenie weryfikacji dostarcza swoją konkretną zastrzeżenie jako zlecenie na następną próbę.
• Przy aktywnej kaskadowości następna próba przejmuje wnioski poprzedniej, zamiast zaczynać od zera.
• Po niepowodzeniu Argo może preferować silniejszy model.
• Jeśli budżet się wyczerpał, nie startuje drogiej ślepej próby: węzeń kończy się udokumentowanym wynikiem częściowym lub jest widocznie eskalowany.

Strategia węzła ostatecznie decyduje, czy zadanie można pominąć, kontrolowanie nie powieść czy potrzebna jest decyzja użytkownika. Zależne zadania otrzymują wyłącznie potwierdzone wyniki częściowe. Dzięki temu z lokalnego błędu nie staje się cichy błąd, który kontynuuje się przez resztę planu.

7. Po realizacji: recenzja, weryfikacja i ewentualny kolejny cykl

Gdy zaplanowane zadania są wykonane, Argo sprawdza zintegrowany stan z kilku perspektyw:

• Agent QA może czytać pliki i uruchamiać komendy testowe.
• Agent architektury sprawdza strukturę tylko do odczytu i celowo bez uprawnień zapisu.
• Deterministyczne weryfikatory mogą uruchamiać testy, sprawdzanie typów lub linting jako obiektywne orakla.
• Stwierdzenia oparte na modelach i deterministyczne są łączone w ogólne oceny.

Jeśli QA, architektura lub wiążący weryfikator znajdą problemy, Argo przypisuje stwierdzenia do dotkniętych zadań. Tylko te zadania są ponownie wykonywane z konkretnym feedbackiem. Potem znowu następuje recenzja i weryfikacja. Bez trybu konsensusu ta pętla jest ograniczona; w wyraźnie wybranym trybie konsensusu trwa, dopóki użytkownik nie zatrzyma lub recenzenci nie zgodzą się.

Weryfikator w trybie obserwacji dokumentuje stwierdzenia, ale nie blokuje. W trybie wiązającym twarde stwierdzenie może zapobiec uznaniu wyniku za udany. Tak da się dobrać ścisłość na profil operacyjny, nie rezygnując z przejrzystości.

8. Dopiero gdy stan jest sprawdzony: dokumentacja i podsumowanie CEO

Po zakończonym cyklu pracy i sprawdzania agent dokumentacji może utrwalić zmiany. Następnie poziom CEO tworzy podsumowanie dla użytkownika: Co zrobiono? Co zostało otwarte? Jakie sprawdzenia przebiegły? Jakie pliki lub decyzje są dotknięte?

Wynik to więcej niż tekst czatu. Uruchomienie prowadzi wspólny identyfikator dla planu, wyboru modelu, kosztów, akcji, orzeczeń weryfikacji, przerwań użytkownika i późniejszych decyzji o patchu. Dzięki temu da się śledzić, jak Argo doszedł do wyniku.

9. Na końcu człowiek decyduje o prawdziwym workspace

Domyślnie Argo pracuje w izolowanym worktree. Zmiany leżą tam jako patch, nie cicho w prawdziwym projekcie. Zależnie od poziomu autonomii dzieje się następnie jedno z trzech:

• Patch czeka na przyjęcie, częściowe przejęcie, edycję lub odrzucenie.
• Udany patch jest automatycznie przejmowany.
• Przy konfliktach z międzyczasowo zmienionymi plikami Argo widocznie zatrzymuje się; nie nadpisuje obcych zmian.

Nieudane uruchomienie nie jest automatycznie stosowane. Nawet bardzo autonomiczna konfiguracja nie unieważnia polityki: ochrona sekretów, reguły komend, granice dostawców, limity budżetu i konieczne Human Gates pozostają skuteczne.

Co realizuje silnik orkiestracji

Silnik orkiestracji nie decyduje tylko, który model odpowie jako następny. Łączy intencję użytkownika, ustawienia, planowanie, równoległość, wybór modelu, użycie narzędzi, korektę błędów, zapewnienie jakości i bezpieczne przejęcie w spójny przebieg.

Kryterium nie jest „jak najwięcej agentów”. Dodatkowa praca powstaje tylko tam, gdzie jest uzasadniona: silniejszy model dla trudnej decyzji architektonicznej, drugie podejście myślenia przy niepewności, celowy retry po zastrzeżeniu weryfikatora lub ludzka zgoda przed ryzykownym skutkiem.

Kurs jest tym samym wyznaczony.