Identifizieren von Verantwortlichkeiten, Risiken, Antimustern und Rückverfolgbarkeitsanforderungen
Da Agenten fähiger werden, kann es verlockend sein, sich verantwortungsverlagerungen in das System vorzustellen. Das ist nicht der Fall. Agentische Systeme können Arbeiten ausführen, aber Menschen bleiben für Ergebnisse und für die Steuerelemente verantwortlich, die die Ausführung steuern.
In dieser Lektion lernen Sie
Wer für Agentaktionen und -ergebnisse verantwortlich ist
Welche allgemeinen Risiken und Antimuster in Agentsystemen auftreten
Wie GitHub Kontrollen diese Risiken mindern
Warum Rückverfolgbarkeit und Observierbarkeit für vertrauenswürdige Systeme erforderlich sind
Verantwortung bewegt sich nicht mit Ausführung
Wenn ein Agent eine Pull-Anforderung erstellt, Code überprüft oder auf Feedback antwortet, nimmt er am Workflow teil, übernimmt aber nicht den Besitz von Ergebnissen. Die verantwortlichen Parteien sind immer noch die Personen und Teams, die:
Die Aufgabe definieren.
Berechtigungen festlegen
Auswählen und Konfigurieren von Steuerelementen
Die resultierende Änderung wurde genehmigt.
Ein Pull-Anforderungsüberprüfungsmodell macht dies explizit: Das System kann vorschlagen, aber der Mensch entscheidet, was akzeptiert wird.
Häufige Risiken und Antimuster
Frühphasen-Agentsysteme schlagen in der Regel auf vorhersehbare Weise fehl:
Planlose Ausführung Der Agent beginnt mit dem Ändern von Code ohne einen klaren, prüfbaren Ansatz.
Übermäßige Berechtigungen von Agenten Der Agent (oder sein Workflow-Token/Tooling-Zugangsberechtigungen) hat breiteren Zugriff als notwendig.
Verborgene Begründungen Der Workflow zeigt nur die Ausgaben (den Diff), ohne die Zwischenartefakte wie Plan, Annahmen, Entscheidungspunkte und Ausführungskontext darzustellen.
Das Vertrauen in und Bestehen von CI-Tests ist wichtig. Aber die Prüfungen validieren nur das, wofür sie konzipiert sind. Ein erfolgreicher Build bedeutet nicht automatisch, dass die Änderung abgeschlossen, angemessen oder ein geringes Risiko darstellt.
Implementierungszuordnung: Risiko → GitHub Risikominderung
| Risiko/ Antimuster | Wie es in GitHub aussieht | Mitigation mit GitHub-Kontrollen |
|---|---|---|
| Planlose Ausführung | PR hat einen Unterschied, aber keinen Plan oder Begründung | Einen Planabschnitt über die PR-Vorlage anfordern; Überprüfung vor dem Zusammenführen erforderlich |
| Überberechtigte Agenten | Workflows können in ein Repository schreiben und allgemein auf Geheimnisse zugreifen. | GITHUB_TOKEN mit geringsten Rechten; Umgebungen mit erforderlichen Prüfern; Einschränken, wer Workflows auslösen kann |
| Verborgene Begründung | Keine Annahmen/Umfang/Entscheidungspfad | Das Planen und Verknüpfen von Workflow-Durchläufen und das Dokumentieren von Entscheidungen in PR-Kommentaren erfordern. |
| Blindes Vertrauen in automatisierung | Die Denkweise „CI ist bestanden, liefer es aus“ | Kombinieren von Überprüfungen mit CODEOWNERS, obligatorischen Überprüfungen und risikobasierten Genehmigungen |
Rückverfolgbarkeit und Beobachtbarkeit
Um einen Agenten gut zu überwachen, benötigen Sie mehr als einen abschließenden Unterschied – Sie brauchen einen Verlauf. In GitHub kann dieser Pfad Folgendes umfassen:
Verlauf von Pull-Anforderungen und Commits
Überprüfen von Kommentaren und Genehmigungen
Workflowausführungen und hochgeladene Artefakte (Testberichte, Protokolle)
Uploads von Code-Scans und Warnungen
Geheime Scanbenachrichtigungen und Pushschutzereignisse
Überwachungsprotokollereignisse der Organisation (Verfügbarkeit und Zugriff hängen von der Organisations-/Unternehmenskonfiguration ab)
Das Ziel ist nicht nur Compliance. Es ist operatives Verständnis: Wenn etwas fehlschlägt, müssen Sie wissen, was sich geändert hat, wer es genehmigt hat, welche Beweise vorhanden sind und was als Nächstes passiert ist.
Mindestüberwachungspfad für Agentenbeiträge
Ein angegebenes Ziel (Problemlink oder PR-Beschreibung)
Ein prüfbarer Plan (PR-Planabschnitt oder Datei)
Ein abgegrenztes Changeset (Verzweigung und Commits)
Automatisierte Nachweise (Workflowausführung und Artefakte)
Menschliches Urteil (Überprüfung und Genehmigung)
Ein klarer Ausgang (Zusammenführen, Rückgängig machen oder Eskalation)
Angenommen, die Behebung einer Schwachstelle des Agents besteht die CI-Prüfung, führt aber später zu einer Regression. Die Schlüsselfrage ist nicht nur, ob der Agent einen Fehler gemacht hat– ob das System den Fehler verständlich und verhinderbar gemacht hat:
Gab es einen sichtbaren Plan und Umfang?
Wurden die richtigen Prüfer angefordert (und genehmigten sie)?
Stimmen die Prüfungen mit dem Risiko der Änderung überein?
Reicht der Überwachungspfad aus, um zu rekonstruieren, was passiert ist?
Agentische Systeme ändern, wer Arbeit ausführt, aber nicht, wer die Ergebnisse besitzt. Menschliche Teams bleiben verantwortlich, weshalb sie gegen allgemeine Antimuster entwerfen müssen und eine starke Rückverfolgbarkeit durch GitHub native Artefakte und Protokolle erfordern.
Sobald Sie verstehen, wie die Verantwortung funktioniert, besteht der letzte Schritt darin, zu entscheiden, wie die Agentenarbeit beurteilt werden soll. In der nächsten Einheit wenden Sie das Mitwirkende-Modell auf die vom Agenten generierte Ausgabe an.