Umowy delegacji dla zespołów agentów AI: zakres, akceptacja i radzenie sobie z błędami
Dlaczego tytuły stanowisk agentów nie zapobiegają błędnym przekazom, oraz jak można testować umowy delegacji z narzuconą polityką, niezależnymi zasadami akceptacji i radzenia sobie z błędami.
Załóżmy, że zmiana produktu jest realizowana przez trzech agentów: w API, u klienta, który je wywołuje, oraz w testach. Wszyscy trzej zgłaszają sukces, a mimo to klient nie potrafi zinterpretować danych zwracanych przez API. Agent API wysyła wartość next_cursor, agent klienta oczekuje wartości nextCursor, a agent testowy sprawdza mocki stworzone na podstawie założeń klienta. Każde z tych zadań wydaje się ukończone, ale połączona zmiana zawodzi już przy pierwszym rzeczywistym żądaniu.
Określenie agentów jako Inżynierów, Specjalistów od Klientów i Recenzentów nie wskazuje, która interfejs wygrywa ani kto zatwierdza wynik. Takie decyzje powinny znajdować się w umowie delegacji, czyli konkretnym zleceniu, które określa dane wejściowe, dozwolony zakres, wymagany wynik, warunki akceptacji oraz to, co się dzieje w przypadku awarii. Jej wartość wynika z tego, w jaki sposób system wykorzystuje tę umowę, a nie z stworzenia kolejnego dokumentu.
Pomyśl o tym warstwowo: rola określa, w jaki sposób agent podchodzi do pracy, natomiast umowa precyzyjnie określa, jakie wkłady są dozwolone. Zasady działania w czasie rzeczywistym decydują o tym, co agent faktycznie może zrobić, a akceptacja określa, czy dany wkład przekształca się w gotowy produkt.
Specjalizacja pozostawia proces przekazywania otwarty
Rola opisuje określony punkt widzenia, np. poszukiwanie problemów z bezpieczeństwem, budowanie klienta lub krytykowanie projektu. Umowa zadań opisuje konkretną instrukcję: użyj tej wersji interfejsu, zmień te pliki, przygotuj te dowody. Uprawnienia w czasie wykonywania zadania określają, co pracownik może faktycznie odczytać, zmienić lub uruchomić.
Rozdzielenie tych elementów pozwala, by przydatna rola pozostała użyteczna, nie biorąc na siebie odpowiedzialności za wszystko. Osoba sprawdzająca może zauważyć zmianę, która może powodować problemy, ale nie ma prawa jej zatwierdzić, a inżynier może zaproponować zmodyfikowany interfejs, lecz nie ma uprawnień, by uczynić go wersją ostateczną.
Badania nad wieloagentowymi systemami przeprowadzone przez Anthropic w sierpniu 2026 roku uwydatniają problem zależności. W eksperymentach z tworzeniem gier role określone regułami oraz hierarchia w stylu CEO niewiele zmieniły, a gry pozostały słabe, mimo że niektóre modele osiągały lepsze wyniki w pomiarach koordynacji. W tym samym raporcie odnotowano powiązany wzorzec zachowań oraz powiązane błędy. Wyniki te pochodzą z konkretnych eksperymentów i nie stanowią ostatecznych ustaleń dotyczących każdej grupy agentów, a porównania dotyczące wrażliwości różnią się zakresem i wykorzystaniem zasobów, dlatego surowe sumy wyników nie pozwalają określić, co dokładnie przyczyniło się do koordynacji.
Istnieje przypadek kontrprzykładowy. Raport inżynieryjny Anthropic na temat jego systemu badawczego opisuje korzyści wynikające z równoległych badań oraz zadania, które zawierają cele, formaty wyjściowe, wskazówki dotyczące narzędzi oraz ograniczenia. Podaje również wyższe zużycie zasobów i ostrzega przed pracą z wieloma zależnościami. To argument za poważnym potraktowaniem dekompozycji, ale nie pokazuje, że architektura badawcza przenosi się bez zmian do inżynierii w wspólnej bazie kodu.
Proponowana tu koncepcja dotyczy granicy pomiędzy zadaniami delegowanymi a zadaniami przyjętymi. To, czy wyraźne wyznaczenie tej granicy jest opłacalne pod względem dodatkowych kosztów, wymaga sprawdzenia.
Napisz zadanie wokół zależności
Aby zmienić mechanizm stronicowania, najpierw właściciel produktu musi skorygować zamierzony sposób działania, a właściciel API zatwierdzić interfejs. Załóżmy, że interfejs używa next_cursor, przy czym null oznacza ostatnią stronę. Wtedy programy API i klienta mogą być budowane w oparciu o jedną wersję, podczas gdy testy akceptacyjne sprawdzają połączony wynik.
Poniższy YAML jest przykładem umowy dla programu klienta. Jego ścieżki, nazwy wersji oraz identyfikatory kontrolne służą jedynie jako przykład i nie stanowią standardu ani części żadnego API frameworku.
task_id: pagination-client-17
objective: Fetch successive pages using next_cursor; stop at null.
inputs:
repository:
ref: product-repo
revision: base-42
requirement:
ref: pagination-behavior
revision: r3
interface:
ref: api/pagination.yaml
revision: r7
scope:
writable:
- client/pagination.ts
- tests/client/pagination.test.ts
non_goals:
- interface_changes
- api_changes
- deployment
deliverable:
- patch_against_base-42
- check_results_bound_to_patch_and_input_revisions
acceptance:
checks:
- client-pagination-unit
- pagination-api-client-e2e
owner: product-maintainer
policy_ref: client-worker-v2
failure:
stale_or_conflicting_input: stop_and_report_to_owner
missing_evidence: return_incomplete
authority_required: request_owner_decision
max_attempts: 2
exhausted: return_unaccepted_to_owner
Nazwy kontrolnych muszą odnosić się do rzeczywistych poleceń i założeń w rejestrze kontrolowanym przez uruchamiający. W tym przykładzie odnoszą się one do kontrol jednostkowych dotyczących obsługi kursora oraz do kontroli end-to-end, która sprawdza kilka stron w oparciu o rzeczywistą kandydującą API, włączając zamknięcie za pomocą null. Procesor klienta może wykonywać własne kontrole jednostkowe, podczas gdy uruchamiający integrację generuje połączone dowody, gdy oba pliki z poprawkami już istnieją.
Podobnie policy_ref jedynie określa nazwę polityki. Dysponent musi powiązać zatwierdzone zadanie z uwierzytelnionym procesorem i wyszukać tę politykę w konfiguracji, której procesor nie może edytować. Nieznana referencja lub żądanie silniejszej polityki musi spowodować niepowodzenie weryfikacji, a edycja pliku YAML nigdy nie powinna przyznawać dodatkowych uprawnień.
Ograniczenie pracy do dwóch prób to lokalna decyzja, która zapobiega nieskończonym pętlom naprawczym, ale nic nie mówi o niezawodności. Określony przez właściciela skończony budżet wykonywania gwarantuje, że żadna z prób nie będzie trwać wiecznie.
Zastrukturyzowane zadanie nie stanowi granicy uprawnień. YAML może opisać zamierzony zakres, ale wciąż konieczne jest jego egzekwowanie przez system.
Ścieżka kroków, która urzeczywistnia umowę
wokół pracowników znajduje się ścieżka kroków. Narzędzie to jest po prostu oprogramowaniem, które uruchamia pracowników, zarządza ich narzędziami i rejestruje to, co się dzieje.
- Zatwierdzenie zależności: właściciele produktu i API podpisują potwierdzenie dotyczące wymagań oraz interfejsu.
- Walidacja przydziału: jego autor dostarcza umowę oraz ustalone wersje.
- Rozsyłka zgodnie z obowiązującą polityką: system rozsyłający uruchamia izolowane pracowniki API i klienta.
Zadanie może być przygotowane przez człowieka lub innego agenta. Następują dwa etapy sprawdzania. Deterministyczny walidator potwierdza poprawność struktury oraz to, że wszystkie odniesienia są poprawne, natomiast odpowiedzialna osoba sprawdza, czy tekst rzeczywiście odzwierciedla wymagania produktu. Dopiero potem dysponent czeka na zatwierdzone zależności, ładuje niezbędne dane wejściowe i uruchamia każdego pracownika w jego określonych granicach.
Cztery pytania muszą pozostać oddzielone. Walidacja schematu sprawdza, czy istnieją wymagane pola i czy są poprawnie sformatowane. Adekwatność semantyczna sprawdza, czy przypisanie opisuje właściwą pracę. Egzekwowanie uprawnień sprawdza, czy pracownik może przekroczyć swoje uprawnienia. Dowody wyników sprawdzają, czy łączny produkt spełnia wymagania. Dokument, który jest strukturalnie ważny, odpowiada tylko na pierwsze z tych pytań.
Dla celów egzekwowania lista ścieżek do zapisu musi stać się rzeczywistym ograniczeniem w czasie wykonywania, wspieranym kontrolą zmienionych plików podczas integracji. Dostęp do środowiska shell nie może oferować alternatywnego sposobu obejścia kontroli plików lub sieci. Odrębny proces weryfikacji utrzymuje propozycje oddzielnie, ale sam w sobie nie stanowi granicy uprawnień.
Ogłoszenie GitHuba z 9 września na temat zarządzanych uprawnień opisuje operacje, które są centralnie blokowane, wymagają zatwierdzenia lub są dozwolone, przy czym istnieją ograniczenia, których nie można złagodzić za pomocą ustawień przestrzeni roboczej. Opis architektury dotyczący agentywnych przepływów pracy przedstawia izolowaną eksploatację oraz etapowe, sprawdzone zapisy. Oba te przypadki są przykładami mechanizmów egzekwowania zasad, a żaden z nich nie dowodzi, że taka architektura delegacji poprawia efektywność dostaw lub gwarantuje prawidłowe zmiany.
Właściciel połączonego wyniku
W przykładzie z paginacją narzędzie integracyjne łączy propozycje API i klienta w tymczasowej przestrzeni roboczej. Sprawdza zakres, weryfikuje rewizje danych wejściowych i uruchamia zarejestrowane procedury weryfikacyjne dokładnie w tej tymczasowej przestrzeni. Następnie właściciel akceptacji analizuje uzyskane dowody i ocenia kwestie produktowe, których nie da się rozstrzygnąć za pomocą tych procedur.
Niezależna akceptacja oznacza, że osoba wykonała prace nie kontroluje sama kryteriów ani dowodów. Twierdzenia i narzędzia używane w całym procesie pozostają poza zasięgiem dostępu do zapisu przez osobę wykonującą prace, a wyniki są powiązane z podsumowaniem kandydata. Akceptacja może łączyć sprawdzenia deterministyczne z udziałem człowieka odpowiedzialnego za konserwację, a dodatkowy model LLM jest opcjonalny. Nadanie modelowi nazwy „Supervisor” nie nadaje mu uprawnień ani nie czyni jego oceny wiarygodną.
Tylko upoważniony właściciel może zmienić kryteria akceptacji, robiąc to z zapisanym powodem oraz nową wersją zadań. Agent wykonujący może poprosić o zmianę, ale nie może pominąć nieudanego testu z zestawu ani przedefiniować struktury paginacji tak, by jedna strona była uznawana za zakończoną.
W końcu upoważniony integrator wprowadza zaakceptowany kandydat drogą już istniejącej, zabezpieczonej ścieżki łączenia. Rekord akceptacji wskazuje dokładny kandydat oraz rewizje danych, które obejmuje. Jeśli gałąź docelowa rozwinie się przed integracją, kandydat jest ponownie budowany i najpierw sprawdzany pod kątem nowej bazy.
Wyniki, które się sprzeczają, są zwracane osobie odpowiedzialnej za sporny obszar. Dwie prawdopodobne interfejsy pozostają dwoma niekompatybilnymi interfejsami, więc dopóki ta osoba nie podejmie decyzji, żadna z propozycji nie staje się wspólną definicją tylko dlatego, że pojawiła się pierwsza.
Rozwiązywanie problemów powinno należeć do tego samego procesu pracy
Każdy z tych przypadków powinien być przetestowany oddzielnie w ramach procesu paginacji, z określoną odpowiedzią oczekiwaną oraz osobą odpowiedzialną za jej egzekwowanie.
Gdy obaj pracownicy próbują zmienić interfejs, dyspozytor odrzuca jego jednoczesną własność, a ograniczenia czasowe uniemożliwiają nieuprawnione edytowanie. Integracja odrzuca każdą poprawkę wykraczającą poza przydzielony jej zakres, a właściciel API decyduje o żądanej zmianie.
Jeśli w trakcie pracy następuje aktualizacja interfejsu, sprawdzenie zależności oznacza propozycję jako przestarzałą. Właściciel decyduje, czy ponownie ją wysłać zgodnie z nową wersją interfejsu, a integracja nie może po prostu przyjąć dowodów zebranych dla starej wersji.
Gdy pojawia się prawdopodobny kod bez żadnych dowodów, brama akceptacji rejestruje go jako niekompletny. Zaufany uruchamiający wykonywa niezbędne sprawdzenia, a wiarygodna informacja o ukończeniu nie może zastąpić rzeczywistych wyników.
Gdy pracownik przerywa działanie w połowie, uprząż rejestruje tę przerwę i zachowuje częściową propozycję oddzielnie. Przed rozpoczęciem prac zastępczych stara próba jest usunięta, aby później nie mogła złożyć przyjętego wyniku.
Jeśli ponowna próba może utworzyć dwa razy to samo środowisko wstępne, adapter działań zewnętrznych najpierw synchronizuje wcześniejszą prośbę. Tam, gdzie dostawca obsługuje usuwanie duplikatów, używana jest stabilna klucz operacyjna, a efekty, które pozostają niepewne, trafiają do właściciela w celu przejrzenia.
Jeśli integracja wymaga uprawnień, których pracownik nie posiada, polityka narzędzia blokuje operację i wysyła prośbę do odpowiedniego właściciela. Propozycja pozostaje niesprawdzona, dopóki nie nadejdzie decyzja.
Scenariusz środowiska wstępnego jest opcjonalnym dodatkiem do przykładu, należącym do usługi integracyjnej, przy czym implementacja pozostaje poza zakresem obowiązków klienta. Jedna klucz operacji określa jeden zamierzony efekt we wszystkich próbach ponownych wykonania, identyfikator próby oddziela poszczególne wykonywania, a ponowne próby nie mogą tworzyć nowej operacji tylko po to, by obejść niejednoznaczną odpowiedź.
Konto Agent Harness w Temporal opisuje trwałe wykonywanie z punktami kontrolnymi w ramach wewnętrznego pętla agenta, wraz z czekaniem na odzyskanie stanu i zatwierdzenie. Jest to rozwijany projekt dostawcy i nie stanowi niezależnego dowodu porównawczego. Dla działań zewnętrznych nadal potrzebna jest deduplikacja lub rozrachunek specyficzny dla dostawcy, ponieważ sama trwała orkiestracja nie gwarantuje efektu dokładnie jeden raz w dowolnej usłudze, a dokumentacja Temporal dotycząca ponownych prób wymaga wykrywania duplikatów w kolejnych etapach.
Każda naprawa zużywa część deklarowanego budżetu prób oraz zasobów. Gdy któryś z nich się wyczerpie, proces przechodzi do stanu niesprawdzonego wyniku wraz z dowodami i określonym właścicielem. Procedury eskalacji wymagają również terminu wygaśnięcia lub sposobu anulowania, aby odpowiedzialność nie zaginęła w porzuconej rozmowie.
Umowy mogą sformalizować błędne prace
Największą przeszkodą są dodatkowe koszty. Gdy jeden agent edytuje pojedynczą funkcję, problem wraz z istniejącymi testami może już zapewnić wystarczającą kontrolę zakresu i akceptacji. Prototypy jednorazowe oraz niezależne zadania badawcze o niskim ryzyku prawdopodobnie wymagają jedynie jasnych instrukcji. Tworzenie specjalnej usługi umownej tylko po to, by ponownie nazwać takie ustalenia, byłoby bezsensowne.
Umowy również nie mogą stworzyć zamierzonej funkcjonalności produktu ani zapewnić możliwości, które w rzeczywistości nie istnieją. Niewłaściwa dekompozycja pozostaje niewłaściwa, błędy korelacyjne trwają, a błędny mechanizm weryfikacji, czyli test lub ocena decydująca o tym, czy wynik jest poprawny, pozostaje błędny. Załóżmy, że test end-to-end ponownie wykorzystuje błędny model klienta – w takim przypadku pozytywny wynik całkowicie pomija pierwotny błąd.
Z tego powodu projekt zasługuje na porównanie z prostszymi alternatywami, w tym z pojedynczym agentem lub deterministycznym przepływem pracy. Pytanie brzmi, czy dodatkowa koordynacja poprawia jakość wykonywanych zadań, czy też kontroluje rzeczywiste ryzyko dla danego obciążenia pracy.
Jak to przetestować
Dla tego rozwiązania nie przeprowadzono żadnych nowych eksperymentów. Warto porównać trzy konfiguracje: pojedynczego agenta (A), kilku agentów z przydziałem ról (B) oraz kilku agentów wykorzystujących wyraźne umowy delegacji oraz powyższy schemat (C).
Sprawiedliwość wymaga, aby A, B i C otrzymały identyczne informacje dotyczące zadań oraz kryteria akceptacji, porównywalne narzędzia i limity bezpieczeństwa, odpowiednie środowiska startowe oraz jeden ogłoszony budżet zasobów. B i C dzielą się modelami oraz liczbą pracowników, a A korzysta z odpowiedniego modelu, o ile to możliwe. Zmienną badaną jest mechanizm delegacji i koordynacji, bez żadnych dodatkowych możliwości czy ukrytych wymagań po stronie.
B powinno zachować zwykłe środki bezpieczeństwa oraz przydatne opisy zadań. Jeśli naturalnie powstaną wyraźne umowy przekazywania obowiązków, należy to odnotować i nie zabraniać takiego zachowania. Należy opublikować rzeczywiste konfiguracje, aby porównanie nie przerodziło się w zestawienie udoskonalonej implementacji z celowo słabym punktem odniesienia.
Wybieraj zadania, które odzwierciedlają rzeczywisty układ: niektóre z elementami niezależnymi, inne z zależnościami sekwencyjnymi, a jeszcze inne z interfejsami lub zasobami współdzielonymi między procesorami. Próby są powtarzane w losowej kolejności w środowiskach odświeżonych, a zwykłe zadania pozostają oddzielone od celowo wprowadzanych błędów. Po fazie pilotażowej konfiguracje zostają zamrożone, zadania rezerwowane służą do rzeczywistego porównania, a niepewność jest podawana dla każdej struktury zależności.
Metodologia oceny firmy Anthropic odróżnia transkrypcję od stanu środowiska, jaki pozostawia, i ocenia model wraz z jego otoczeniem. To właśnie tutaj należy dokonać pomiaru: czy paginacja działa w połączonym środowisku? Fakt, że trzy agenty zgłaszają ukończenie pracy, nic nie dowodzi.
Stosuje się trzy główne wskaźniki: akceptowane wyniki od początku do końca, całkowity koszt każdego akceptowanego wyniku oraz czas upływający od rozpoczęcia do jego akceptacji. Koszty obejmują nieudane próby, koordynację, ponowne próby, przeglądanie, konfigurację oraz sporządzanie umów. Początkowa konfiguracja jest raportowana oddzielnie od kosztów powtarzalnych, podano również założenia dotyczące amortyzacji, a czas poświęcony przez ludzi jest jasno rejestrowany. Jeśli nic nie zostanie zaakceptowane, należy podać wydatki i liczbę zerowych sukcesów zamiast pokazywać koszt jednostkowy, który wydaje się skończony, ale wprowadza w błąd.
Oprócz nich należy śledzić niepowodzenia integracji, powtarzane prace, błędy spowodowane przestarzałymi danymi, interwencje ludzkie, naruszenia zakresu oraz wyniki odrzucone po zgłoszeniu ich jako ukończonych. Próby naruszeń oraz te udane są raportowane oddzielnie, a niezakończone próby i przekroczenia czasowe pozostają uwzględnione, aby szybkie sukcesy nie maskowały długotrwałych niepowodzeń.
Odrzucenie przestarzałego patcha w odpowiedni sposób potwierdza poprawne funkcjonowanie mechanizmów kontroli, ale zadanie związane z produktem nadal się nie powiodło, chyba że przyjęto ważny wynik w ramach ustalonego budżetu. Wczesne wyniki pilotażowe wskazują jedynie kierunek dalszych działań. Jeśli umowy powodują dodatkowe obciążenia bez lepszych rezultatów lub znacząco niższego ryzyka, rozsądnym radą jest pominęcie ich przy takim obciążeniu pracy.
Zacznij od jednego procesu, który można przeanalizować
Rozsądny początek to pojedynczy istniejący proces pracy z dwoma pracownikami oraz osobą odpowiedzialną za akceptację. Sprawdzenie integracji pozostaje poza kontrolą pracowników, a każdy przypadek awarii jest testowany osobno, zanim zakres zostanie rozszerzony. Krótki opis w tym stylu może zostać przesłany do agenta zajmującego się kodowaniem:
Add the minimum delegation contract to [WORKFLOW].
Acceptance owner: [OWNER].
Preserve existing safety boundaries.
1. Inspect current delegation, inputs, permissions, and acceptance.
Exit: map who assigns, executes, checks, accepts, and commits.
2. Identify missing boundaries; reuse existing issues and checks.
Exit: owner-approved scope, revisions, deliverable, and criteria.
3. Wire the minimum contract into dispatch and result handling.
Exit: references resolve; proposals cannot accept themselves; unauthorized operations are blocked by the actual runtime.
4. Exercise valid and invalid handoffs in isolated fixtures.
Exit: demonstrate acceptance, conflict rejection, stale-input detection, missing-evidence rejection, interruption recovery, bounded retries, and authority escalation. Mock external effects.
5. Report changed files, commands run, outcomes, and remaining gaps.
Exit: distinguish implemented controls from unverified behavior.
Nie zastępuj platformy orkiestracji ani nie modyfikuj niespokrewnionych z nią elementów, a także nie publikuj, wdrażaj ani nie rozszerzaj uprawnień.
API, klient oraz testy nadal wymagają sprawnych pracowników. Zmiana dotyczy zasad działania obowiązujących w ich otoczeniu. Zanim łączna praca zostanie uznana za zakończoną, należy dokładnie określić, jakie elementy musi zawierać każdy wkład, kto może go przyjąć oraz co się stanie, jeśli nie będzie mógł zostać zaakceptowany. Tytuły stanowisk nigdy nie wyznaczają takich granic.