Identifikace odpovědností, rizik, anti-vzorů a potřeb sledovatelnosti
S tím, jak jsou agenti schopní, může být lákavé představit si, že odpovědnost se přesune do systému. Nejde to. Agentické systémy mohou provádět práci, ale lidé zůstávají zodpovědní za výsledky a kontroly, které řídí provádění.
V této jednotce se naučíte
Kdo je zodpovědný za akce agenta a výsledky
Jaká běžná rizika a antivzory se vyskytují v systémech agentů
Jak GitHubová opatření tyto rizika zmírňují?
Proč jsou pro důvěryhodné systémy vyžadována sledovatelnost a pozorovatelnost
Odpovědnost se nepřesune s prováděním
Když agent vytvoří žádost o přijetí změn, reviduje kód nebo odpoví na zpětnou vazbu, účastní se pracovního postupu, ale nepředpokládá vlastnictví výsledků. Odpovědné strany jsou stále lidmi a týmy, kteří:
Definice úkolu
Nastavení oprávnění
Výběr a konfigurace ovládacích prvků
Schválila výslednou změnu.
Model kontroly požadavků na přijetí změn toto jasně vyjadřuje: systém může navrhnout, ale lidé rozhodnou, co bude přijato.
Běžná rizika a antivzory
Systémy agentů v rané fázi obvykle selhávají předvídatelně:
Neplánovatelné spuštění Agent začne měnit kód bez jasného a kontrolovatelného přístupu.
Agenti s nadměrnými oprávněními Agent (nebo jeho token pracovního procesu nebo přihlašovací údaje nástroje) má širší přístup, než je nutné.
Skryté odůvodnění Pracovního postupu zveřejňuje pouze výstupy (rozdíl) bez přechodných artefaktů (plán, předpoklady, rozhodovací body, kontext provádění).
Slepá důvěra v automatizaci Prošlé CI je důležité, ale kontroly pouze ověřují to, co jsou navrženy k detekci. Úspěšné sestavení automaticky neznamená, že je změna dokončena, vhodná nebo nízkoriziková.
Mapování implementace: zmírnění rizik → GitHub
| Riziko / anti-vzor | Jak to vypadá na GitHubu | Zmírnění pomocí ovládacích prvků GitHub |
|---|---|---|
| Provádění bez plánu | Žádost o přijetí změn má rozdíl, ale žádný plán ani odůvodnění | Vyžadovat oddíl plánu prostřednictvím šablony pull requestu; vyžadovat revizi před sloučením |
| Agenti s více oprávněními | Pracovní postupy můžou zapisovat do repositáře, přistupovat obecně k tajným údajům. | GITHUB_TOKEN s nejnižšími oprávněními; prostředí s požadovanými kontrolory; omezení, kdo může aktivovat pracovní postupy |
| Skryté odůvodnění | Žádné předpoklady, rozsah nebo rozhodovací stopa | Vyžadovat plán, propojit průběhy pracovních postupů a zaznamenat rozhodnutí v komentářích k PR |
| Nevidomá důvěra v automatizaci | "Postoje 'CI prošlo, můžeme to nasadit'" | Kombinování kontrol s CODEOWNERS, požadovanými kontrolami a schváleními na základě rizik |
Sledovatelnost a pozorovatelnost
Pokud chcete účinně dohlížet na agenta, potřebujete více než jen konečné porovnání – potřebujete stopu. V GitHub může tato trasa obsahovat:
Žádosti o začlenění a historie commitů
Kontrola komentářů a schválení
Pracovní běhy a nahrané artefakty (testovací zprávy, protokoly)
Nahrané položky a výstrahy kontroly kódu
Upozornění na skenování tajných informací a události ochrany před odesláním
Události protokolu auditu organizace (dostupnost a přístup závisí na konfiguraci organizace nebo podniku)
Cílem není pouze dodržování předpisů. Je to provozní porozumění: když něco selže, potřebujete vědět, co se změnilo, kdo ho schválil, jaké důkazy existovaly a co se stalo dál.
Minimální záznam auditu pro příspěvky agenta
Stanovený cíl (odkaz na problém nebo popis návrhu změny)
Kontrolovatelný plán (oddíl nebo soubor plánu žádosti o přijetí změn)
Ohraničená sada změn (větev a potvrzení)
Automatizované důkazy (běh pracovního postupu a artefakty)
Lidský úsudek (přezkum a schválení)
Jasný výsledek (sloučení, vrácení nebo eskalace)
Předpokládejme, že oprava zranitelnosti agenta projde CI, ale později způsobí regresi. Klíčovou otázkou není jen to, zda agent udělal chybu, ale zda systém učinil chybu pochopitelnou a předcházetelnou.
Byl nějaký viditelný plán a rozsah?
Byli požádáni ti správní recenzenti (a schválili)?
Odpovídaly kontroly riziku změny?
Je záznam auditu dostatečný k rekonstrukci toho, co se stalo?
Agentické systémy mění, kdo provádí práci, ale ne kdo vlastní výsledky. Lidské týmy zůstávají zodpovědné, a proto musí navrhovat proti běžným antivzorům a vyžadovat silnou sledovatelnost prostřednictvím nativních artefaktů a protokolů GitHubu.
Jakmile pochopíte, jak odpovědnost funguje, je posledním krokem rozhodnutí, jak by se měla posoudit práce agenta. V další lekci použijete model přispěvatele na výstup vygenerovaný agentem.