Przejdź do głównej treści
Gdy reguła firewalla zwraca werdykt pending_approval, wywołanie narzędzia agenta jest wstrzymane zamiast dyspozytowane — teraz czeka na człowieka. Ta strona jest dla recenzenta: jak zatwierdzać wstrzymane wywołania narzędzi agenta (lub je odrzucać) z konsoli, co pokazuje ci kolejka oraz jak OrcaRouter powstrzymuje dwóch recenzentów przed kolizją na tej samej decyzji. To rozstrzygająca połowa człowieka w pętli. Dla dlaczego wywołanie zostaje wstrzymane i jak wstrzymany agent ponownie wysyła potem, zobacz werdykty i głębszą referencję zatwierdzeń. Aby rozstrzygać z własnego systemu zamiast konsoli, zobacz webhooki zatwierdzeń.

​
1. Cykl życia wstrzymanego wywołania, z fotela recenzenta

Wstrzymane wywołanie to krótka pętla poza pasmem. Twoje zadanie to środkowy krok:
1

Wywołanie jest wstrzymane

Reguła rozwiązuje się do pending_approval. Relay zwraca HTTP 400 z kodem firewall_approval_pending i id zatwierdzenia; wywołanie nigdy nie dociera do narzędzia. Agent zaczyna odpytywać na tym id.
2

Ty je rozstrzygasz

Otwierasz kolejkę Approvals, odczytujesz, dlaczego wywołanie zostało wstrzymane, i zatwierdzasz lub odrzucasz je — przedmiot tej strony.
3

Agent przechodzi dalej (lub zatrzymuje się)

Na zatwierdzenie agent ponownie wysyła oryginalne wywołanie z jednorazowym nagłówkiem X-OrcaRouter-Firewall-Approval, a brama przepuszcza je ten jeden raz. Na odrzucenie wywołanie pozostaje zablokowane.
Rozstrzyganie wstrzymania jest bramkowane na Developer+ — ta sama brama co strumień Events firewalla. Niższe role mogą czytać politykę firewalla, ustawienia i wykryte narzędzia, ale tylko role Developer-i-wyżej mogą wymienić kolejkę zatwierdzeń lub zatwierdzić/odrzucić wstrzymane wywołanie narzędzia. Zobacz role i zakres.

​
2. Wymień kolejkę oczekujących

Zakładka Approvals odczytuje GET /api/workspace/firewall/approvals. Bez filtra zwraca kolejkę pending, od najstarszych — więc najdłużej-czekające wywołanie siedzi na górze, a ty obrabiasz zaległości w kolejności. 
GET /api/workspace/firewall/approvals?state=pending
state to jeden filtr, który ma znaczenie. Wartości mapują się na cykl życia zatwierdzenia:
stateZwrócone zatwierdzenia
pending (domyślny)Wstrzymane, oczekuje na decyzję — twoja kolejka pracy.
approvedJuż przepuszczone.
rejectedJuż zablokowane.
To trasa konsoli na twojej sesji — konfiguruj ją i przeglądaj z dashboardu, nie kluczem relay sk-orca-…. Klucze relay służą do wywołań modelu /v1/*; zarządzanie firewallem działa pod twoim loginem konsoli.

​
3. Odczytaj, dlaczego wywołanie zostało wstrzymane

Każdy wiersz niesie wejścia decyzji, których recenzent potrzebuje — nazwę narzędzia (tool_name), odcisk argumentów (args_hash, SHA-256 skanonizowanych argumentów wywołania — surowe wartości argumentów nie są przechowywane w zatwierdzeniu), id żądania oraz linię proweniencji w prostym języku, która nazywa politykę, regułę i klauzulę, która odpaliła:
Nazwana polityka, do której należy dopasowana reguła, rozwiązana w zakresie przestrzeni roboczej, więc nieaktualne id nigdy nie może ujawnić nazwy polityki innego najemcy.
Etykieta reguły i jednolinijkowy deskryptor „dlaczego” — np. command contains rm -rf lub tool matches "http_fetch" dla reguły tylko-globowej. To renderuje linię „Wstrzymane, ponieważ…” w kolejce.
true, gdy dopasowana reguła została edytowana w momencie lub po utworzeniu tego zatwierdzenia. Aktualna etykieta i klauzula są wtedy tłumione (mogą już nie odzwierciedlać tego, co faktycznie wstrzymało wywołanie), a kolejka pokazuje notatkę „reguła od tego czasu zmieniona” zamiast nieaktualnej proweniencji. Nazwa narzędzia i argumenty — prawdziwe wejścia decyzji — są zawsze pokazywane.
rule_changed to celowy sygnał uczciwości, nie błąd. Jeśli ktoś edytuje regułę firewalla, gdy wywołanie siedzi w kolejce, OrcaRouter woli ukryć prawdopodobnie-zły powód niż pokazać ci proweniencję, która już nie pasuje. Zdecyduj na podstawie nazwy narzędzia i nazwy polityki (wciąż pokazywanych) w tym przypadku.

​
4. Zatwierdź lub odrzuć

Rozstrzyganie wysyła PATCH /api/workspace/firewall/approvals/:id z decision approved lub rejected i opcjonalnym reason. Konsola robi to za ciebie, gdy klikniesz przycisk; kształt to: 
PATCH /api/workspace/firewall/approvals/507f1f77bcf86cd799439011
Content-Type: application/json

{ "decision": "approved", "reason": "verified target host with the on-call" }
  • approved → wstrzymane wywołanie może przejść dalej. Następne ponowne wysłanie agenta, niosące jednorazowy nagłówek zatwierdzenia, jest przepuszczane raz.
  • rejected → wywołanie pozostaje zablokowane. Agent widzi odrzucenie i może wybrać inną ścieżkę, zapytać użytkownika lub zatrzymać się.
decision jest walidowane wobec zamkniętego zestawu {approved, rejected} — cokolwiek innego jest odrzucane. reason jest rejestrowane z decyzją i zapisywane do logu audytu firewalla obok aktora, nazwy narzędzia i id żądania.
Każde rozstrzygnięcie zapisuje wiersz audytu przestrzeni roboczej nazywający, kto zdecydował, decyzję i powód. Rozstrzygnięcia konsoli rejestrują aktora-człowieka; rozstrzygnięcia webhooka rejestrują aktora-system. Proweniencja rozstrzygnięcia nigdy nie jest po cichu pomijana.

​
5. Wygrywa-pierwszy-piszący: brak podwójnego rozstrzygnięcia

Oczekujące zatwierdzenie może być wyścigowane — dwóch recenzentów w konsoli albo kliknięcie w konsoli i webhook callback przybywający razem. OrcaRouter rozwiązuje to pojedynczą regułą wygrywa-pierwszy-piszący:
  • Decyzja to atomowa warunkowa aktualizacja, która odpala tylko, gdy zatwierdzenie wciąż jest pending. Pierwszy piszący wygrywa i stosuje decyzję.
  • Każdy późniejszy piszący obserwuje „już rozstrzygnięte” i jest traktowany jako idempotentny no-op — dostaje HTTP 200 z już-rozstrzygniętym dokumentem, nie błąd.
Odpowiedź mówi ci, po której stronie byłeś: 
{
  "resolved": false,
  "already_resolved": true,
  "approval": { "state": "approved", "decision": "approved", "...": "..." }
}
resolved: true oznacza, że twoje wywołanie zastosowało decyzję; already_resolved: true oznacza, że ktoś (lub jakiś webhook) dotarł tam pierwszy i widzisz jego wynik. Tak czy inaczej kolejka uzgadnia się do jednego spójnego stanu.
Ponieważ rozstrzyganie jest idempotentne, niestabilna sieć lub podwójne kliknięcie nie może uszkodzić wstrzymania ani odwrócić decyzji. Pierwsze zatwierdzenie/odrzucenie to jedyne, które się liczy; wszystko po nim po prostu odczytuje wynik z powrotem.

​
6. Konkretne przejście przez kolejkę

Przestrzeń robocza o zrównoważonej autonomii wstrzymuje wywołanie shell.exec agenta, ponieważ reguła dopasowała command contains rm -rf. Jako recenzent:
  1. Otwierasz Approvals — wstrzymane shell.exec siedzi na górze listy pending od najstarszych.
  2. Odczytujesz wiersz: narzędzie shell.exec, odcisk args_hash, id żądania oraz linię „Wstrzymane, ponieważ… command contains rm -rf” (renderowaną z klauzuli dopasowanej reguły). Brak flagi rule_changed, więc proweniencja jest aktualna.
  3. Cel to katalog roboczy, więc zatwierdzasz z powodem.
  4. Twój PATCH zwraca resolved: true; następne odpytanie agenta widzi approved, ponownie wysyła z jednorazowym nagłówkiem, a polecenie uruchamia się dokładnie raz.
Gdyby kolega z zespołu zatwierdził je sekundę wcześniej, twoje kliknięcie zwróciłoby already_resolved: true z jego decyzją — bez szkody, bez podwójnego uruchomienia.

​
Dokąd dalej

Referencja zatwierdzeń

Pełna pętla HITL: wstrzymaj, odpytaj, wyślij ponownie i jednorazowy nagłówek.

Webhooki zatwierdzeń

Rozstrzygaj wstrzymania z własnego systemu podpisanym HMAC callbackiem.

Werdykty

Gdzie pending_approval siedzi wśród sześciu werdyktów firewalla.

Log zdarzeń

Potwierdź wynik downstream rozstrzygniętego wywołania w strumieniu.
Dla ryzyk, które te wstrzymania mają wychwytywać, zobacz niebezpieczne wywołania narzędzi i nadmierną sprawczość.