Identyfikowanie obowiązków, czynników ryzyka, potrzeb związanych z anty-wzorcem i możliwościami śledzenia
Gdy agenci stają się bardziej zdolni, może to być kuszące, aby wyobrazić sobie, że odpowiedzialność przenosi się do systemu. To nie. Systemy agentyczne mogą wykonywać pracę, ale ludzie pozostają odpowiedzialny za wyniki i kontrole, które zarządzają wykonywaniem.
W tej jednostce dowiesz się
Kto jest odpowiedzialny za działania i wyniki agenta
Jakie typowe zagrożenia i antywzorce pojawiają się w systemach agentowych
Jak mechanizmy kontrolne GitHubu łagodzą te ryzyka
Dlaczego śledzenie i możliwość obserwacji są wymagane w przypadku zaufanych systemów
Odpowiedzialność nie przenosi się z wykonaniem
Gdy agent tworzy wniosek ściągnięcia, zmienia kod lub odpowiada na uwagi, uczestniczy w przepływie pracy, ale nie przyjmuje odpowiedzialności za wyniki. Strony odpowiedzialne są nadal ludźmi i zespołami, które
Zdefiniowano zadanie
Ustawianie uprawnień
Wybieranie i konfigurowanie kontrolek
Zatwierdzono zmiany wynikające z tego
Model przeglądu żądania pobrania sprawia, że jest to jawne: system może zaproponować, ale ludzie decydują, co zostaje akceptowane.
Typowe ryzyka i antywzorce
Systemy agentów na wczesnym etapie często kończą się niepowodzeniem w przewidywalny sposób:
Wykonywanie bez planu Agent rozpoczyna zmianę kodu bez wyraźnego, kontrolowanego podejścia.
Agenci z nadmiernymi uprawnieniami Agent (lub jego token przepływu pracy/poświadczenia narzędzi) ma szerszy dostęp niż jest to konieczne.
Ukryte rozumowanie Przepływ pracy uwidacznia tylko dane wyjściowe (różnice) bez artefaktów pośrednich (plan, założenia, punkty decyzyjne, kontekst wykonywania).
Ślepe zaufanie do automatyzacji Przejście przez etapy CI jest ważne, ale testy tylko weryfikują to, co zostały zaprojektowane do wykrycia. Przekazywanie kompilacji nie oznacza automatycznie ukończenia, odpowiedniego lub niskiego ryzyka zmiany.
Mapowanie implementacji: ryzyko → GitHub środki zaradcze
| Ryzyko/antywzór | Jak wygląda w GitHub | Łagodzenie przy użyciu mechanizmów GitHub |
|---|---|---|
| Wykonywanie bez planu | Żądanie ściągnięcia ma różnicę, ale nie ma planu ani uzasadnienia | Wymagać sekcji planu przez szablon pull requesta; wymagać przeglądu przed scaleniem |
| Agenci z nadmiernymi uprawnieniami | Przepływy pracy mogą zapisywać w repozytorium i globalnie uzyskiwać dostęp do sekretów. | GITHUB_TOKEN z minimalnymi uprawnieniami; środowiska z wymaganymi recenzentami; ograniczenie, kto może uruchamiać przepływy pracy |
| Ukryte rozumowanie | Brak założeń/zakresu/ścieżki decyzyjnej | Wymagaj planowania i łączenia przebiegów przepływu pracy oraz rejestruj decyzje w komentarzach żądań ściągnięcia. |
| Ślepe zaufanie do automatyzacji | "Podejście typu 'CI zakończone, wdrażaj' (ang. "CI passed, ship it") mindset" | Łączenie kontroli z CODEOWNERS, wymaganymi recenzjami i zatwierdzeniami opartymi na ryzyku. |
Możliwość śledzenia i obserwowanie
Aby dobrze nadzorować agenta, potrzebujesz więcej niż ostateczną różnicę, potrzebujesz szlaku. W GitHub ten szlak może obejmować:
Żądania ściągnięcia i historia zatwierdzń
Przeglądanie komentarzy i zatwierdzeń
Procesy przepływu pracy i przesłane artefakty (raporty testowe, dzienniki)
Skanowanie kodu: przesyłanie i alerty
Alerty skanowania tajnych danych i zdarzenia ochrony przesyłania
Zdarzenia dziennika inspekcji organizacji (dostępność i dostęp zależą od konfiguracji organizacji/przedsiębiorstwa)
Celem nie jest tylko zgodność. Jest to zrozumienie operacyjne: gdy coś się nie powiedzie, musisz wiedzieć, co się zmieniło, kto je zatwierdził, jakie dowody istniały i co się stało dalej.
Minimalny ślad audytu dla wkładów agentów
Określony cel (link problemu lub opis żądania ściągnięcia)
Plan do inspekcji (sekcja lub plik planu PR)
Ograniczony zestaw zmian (gałąź i zatwierdzenia)
Zautomatyzowane dowody (przebieg przepływu pracy i artefakty)
Ocena człowieka (przegląd i zatwierdzenie)
Wyraźny wynik (scalanie, przywracanie lub eskalacja)
Załóżmy, że poprawka dotycząca podatności w agencie przechodzi testy CI, ale później powoduje regresję. Kluczowym pytaniem nie jest tylko to, czy agent popełnił błąd— czy system popełnił błąd zrozumiały i możliwy do uniknięcia:
Czy był widoczny plan i zakres?
Czy poproszono odpowiednich recenzentów (i czy oni zatwierdzili)?
Czy kontrole są zgodne z ryzykiem zmiany?
Czy szlak inspekcji jest wystarczający do odtworzenia tego, co się stało?
Systemy agentyczne zmieniają, kto wykonuje pracę, ale nie kto jest właścicielem wyników. Zespoły ludzkie ponoszą odpowiedzialność, dlatego muszą projektować z uwzględnieniem typowych anty-wzorców i zapewniać ścisłe śledzenie GitHub-native artefaktów i logów.
Gdy zrozumiesz, jak działa odpowiedzialność, ostatnim krokiem jest podjęcie decyzji o tym, jak należy ocenić pracę agenta. W następnej jednostce zastosujesz model współautora do danych wyjściowych generowanych przez agentów.