Przejdź do treści

Szczegółowe poziomy autonomii

Autonomia to nie jedna liczba

NORBI nie ma globalnego przełącznika „autonomiczny”. Poziom określa się dla kombinacji: agent + workflow + narzędzie + projekt + klasa danych + skutek + odbiorca + próg wartości. Ten sam agent może samodzielnie tworzyć streszczenia, wymagać review dla raportu i mieć zakaz wysyłania wiadomości.

Autonomia wykonania jest niezależna od władzy. Nawet najwyższy poziom nie obejmuje samonadania capability, aktywacji agenta/narzędzia, zmiany twardej polityki, utworzenia konta, instalacji niezatwierdzonego kodu ani przejęcia Approval Center.

Sześć poziomów

Poziom Nazwa Co Norbi może zrobić Typowy rezultat
A0 obserwator analizować po udostępnieniu danych, bez tworzenia efektu wyjaśnienie, diagnoza, lista opcji
A1 asystent przygotować draft/plan/candidate, człowiek uruchamia dalszy krok dokument, harmonogram, patch, propozycja
A2 wykonawca zatwierdzany wykonać dokładny plan po approvalu związanym z payloadem render, zapis rekordu, wysyłka, zmiana kandydata
A3 autonomia warunkowa wykonywać pre-approved klasy działań w limitach i eskalować wyjątki triage, rutyna domowa, proste odpowiedzi, QC
A4 operator domenowy prowadzić całe workflow i optymalizować kolejność w zadanym celu/SLA obsługa kolejki, nocna produkcja, monitoring
A5 nadzorowany ekosystem koordynować wiele domen i workerów w długim horyzoncie, z budżetami i ciągłym audytem złożona operacja firmy lub domu

A0 — obserwator

Brak skutków poza odpowiedzią. Dozwolony jest read-only dostęp do jawnie udostępnionych danych. Norbi może wskazać ryzyka i testy. Nie tworzy rekordów, plików ani pamięci długoterminowej bez osobnej operacji. Stosowane przy audycie, pierwszym wdrożeniu i danych wrażliwych.

A1 — asystent

Norbi tworzy candidate artifact lub workflow draft. Może iterować technicznie w izolacji, ale użytkownik decyduje o akceptacji. Przykłady: draft e-maila, trzy grafiki, candidate patch, plan podróży. To domyślny poziom dla nowych agentów i integracji.

A2 — wykonawca zatwierdzany

Po zobaczeniu pełnego kontekstu człowiek zatwierdza exact action. Grant jest jednorazowy i krótki. Zmiana odbiorcy, ceny, pliku, ścieżki, wersji narzędzia lub skutku wymaga nowej decyzji. Przykład: wysłanie konkretnej oferty lub promocja konkretnego candidate commit.

A3 — autonomia warunkowa

Właściciel z góry zatwierdza klasę niskiego/średniego ryzyka z limitami, np. automatyczne tworzenie draftów, odpowiedź na FAQ z zatwierdzonej bazy, włączenie światła w godzinach 18–23, przypomnienie o grafiku. Polityka określa próg, dane, odbiorców, budżet, okno czasu, maksymalną liczbę skutków i circuit breaker. Agent nie zmienia tych limitów.

A4 — operator domenowy

Norbi prowadzi pełny proces bez zatwierdzania każdego kroku: planuje, rezerwuje zasoby, wykonuje, waliduje, ponawia bezpieczne operacje i eskaluje wyjątki. Warunkiem są dojrzałe adaptery, testy, SLO, checkpointy, observability, odcięcie i udowodniony rollback. Skutki wysokie nadal mogą mieć approval, nawet gdy reszta workflow jest autonomiczna.

A5 — nadzorowany ekosystem

System zarządza wieloma workflow, agentami i workerami w ramach ustalonych celów, polityk, budżetów i priorytetów. Może dynamicznie przesuwać zasoby, wybierać modele i uruchamiać zatwierdzone plany awaryjne. Nie jest „suwerennym AI”: governance, capabilities, aktywacje, granice danych, budżety strategiczne i odpowiedzialność pozostają ludzkie.

Macierz wpływu

Poziom autonomii łączy się z klasą skutku:

Skutek A1 A2 A3–A5
lokalny candidate artifact tak tak tak, z quota/retencją
read public web propozycja wykonanie po policy automatyczne w allowliście
wysłanie rutynowego komunikatu draft exact approval tylko zatwierdzone klasy/odbiorcy/limity
publikacja publiczna draft exact approval zasadniczo approval kampanii; wyjątkowo kontrolowany kanał
zakup/płatność porównanie exact approval ceny/odbiorcy/warunków limity mikrotransakcji tylko po jawnej polityce i zabezpieczeniach
zmiana main / aktywacja narzędzia candidate oddzielny approval nie staje się autonomiczna przez A5
instalacja/firmware plan maintenance approval tylko w pre-approved oknie, nadal bez samodzielnego rozszerzenia źródeł
skutek fizyczny symulacja exact approval + interlock ograniczone rutyny z hardware safety; krytyczne nadal eskalowane

Warunki podniesienia poziomu

Podniesienie A1→A3 nie jest decyzją agenta. Wymaga:

  • stabilnego, wersjonowanego workflow i toolchain;
  • danych z shadow i reprezentatywnych testów;
  • określonych SLO oraz progów circuit breaker;
  • analizy false positive/negative i najgorszego skutku;
  • idempotency/reconciliation, backupu i rollbacku;
  • ograniczenia projektów, danych, kont, odbiorców, wartości i czasu;
  • właściciela biznesowego i technicznego;
  • jawnego approvala zmiany polityki oraz daty ponownego review.

Obniżenie może być automatyczne: błąd twardy, drift, wzrost wyjątków lub incydent przełącza na A1/read-only. Ponowne podniesienie wymaga człowieka.

Przykładowe profile

Coding agent: A4 w analizie i candidate worktree; A0 wobec sekretów; A2 dla instalacji test dependency; zawsze oddzielny promotion approval.

Recepcja hotelu: A3 dla FAQ i dostępności; A3 dla standardowych rezerwacji bez wyjątków; A2 dla rabatu; A0 dla danych karty; transfer do człowieka przy sporze.

Dom: A3 dla świateł i temperatury w granicach; A2 dla bramy poza rutyną; A0/A1 dla zakupów; A4 dla monitorowania energii, ale bez samodzielnego zwiększenia limitu mocy.

Walidacja i scenariusz awaryjny

Każdy profil ma testy „powinien wykonać”, „powinien odmówić”, „powinien eskalować” i „powinien zatrzymać się po limicie”. Audit mierzy nie tylko sukces, ale nadmiarowe działanie. UI pokazuje aktualny poziom i powód dla konkretnego joba.

Przy braku Policy Engine albo rozbieżności profilu system spada do najniższego bezpiecznego poziomu. Nie przyjmuje poziomu zadeklarowanego w prompcie, pamięci czy pluginie. Emergency stop unieważnia grants i zatrzymuje dispatch; nie wymaga współpracy agentów.