Zuordnen der Verantwortlichkeiten des Agenten zu SDLC
In dieser Lektion lernen Sie:
- Warum die Zuordnung von Agent-Verantwortlichkeiten zu SDLC-Phasen verbessert die Zuverlässigkeit
- Zuordnung von SDLC-Stufen zu GitHub Artefakten und Steuerelementoberflächen
- Definieren von Architekturgrenzen für das Agentverhalten, um Risiken zu reduzieren und die Auditierbarkeit zu verbessern
Warum die Verantwortungszuordnung wichtig ist
Agentensysteme sollten nicht ohne Einschränkung über die gesamte SDLC hinweg funktionieren. Wenn ein Agent wie ein allgemeiner Entwickler behandelt wird, wird es schwierig, über sein Verhalten zu entscheiden, seine Auswirkungen zu begrenzen oder Überwachungsergebnisse zu überwachen.
Ein zuverlässigerer Ansatz besteht darin, den Agent bestimmten Lebenszyklusphasen zuzuordnen, in denen GitHub Grenzen erzwingen können. Die meisten Teams beginnen mit der Festlegung des Aufgabenbereichs der Agents für die Implementierungs- und Validierungsphasen, in denen Pull Requests und Workflows natürliche Kontrollpunkte bereitstellen.
Zuordnen von SDLC-Phasen zu GitHub Artefakten
Der SDLC lässt sich in die Phasen Planung, Implementierung, Validierung und Bereitstellung unterteilen. Jede Stufe ist einem anderen GitHub-Bereich zugeordnet, in denen Arbeiten und Beweise aufgezeichnet werden können.
| SDLC-Phase | Typische Agentenverantwortung in GitHub | Primäres Artefakt |
|---|---|---|
| Planung | Entwurfsbereich, Planschritte, Definieren von Erfolgskriterien | GitHub Probleme, Beschreibungen/Kommentare der Pull-Anforderung, Registerkarte "Agents" |
| Implementation | Verzweigung erstellen, Änderungen vornehmen, PR öffnen/aktualisieren | Branch, Commits, Pull-Anforderung |
| Überprüfen | Prüfungen durchführen, Artefakte anhängen, Fehler beheben | Workflows, Prüfungen, Artefakte |
| Einsatz | In der Regel eingeschränkt; Genehmigungen für vertrauliche Aktionen erfordern | Umgebungen und Bereitstellungsgenehmigungen |
Definieren von Architekturgrenzen für das Agentverhalten, um Risiken zu reduzieren und die Auditierbarkeit zu verbessern
- Legen Sie frühzeitig den Rahmen fest, um den Auswirkungsbereich zu reduzieren: Beschränken Sie, welche Verzeichnisse ein Agent gemäß Richtlinien und Eigentumsverhältnissen ändern kann.
- Behandeln Sie Workflow- und Infrastrukturänderungen als höheres Risiko als Anwendungscodeänderungen.
- Bevorzugen Sie PR-basierte Arbeit auch für die Automatisierung. Vermeiden Sie Direct-to-Default-Branch-Änderungen.
Eine gemeinsame Entwurfsgrenze ist: Agenten vorschlagen; Menschen und Politik akzeptieren. Der Agent kann Arbeiten vorbereiten und über einen Pull-Request übermitteln, aber Repository-Richtlinien und menschliche Prüfer entscheiden, ob diese Arbeiten zusammengeführt oder ausgerollt werden.
Praktisches Beispiel in GitHub
Ein Abhängigkeitskorrektur-Agent ist auf Implementierung ausgelegt:
- Der Agent erkennt eine anfällige Abhängigkeit (z. B. aus einer Sicherheitswarnung oder einem Problem).
- Der Agent erstellt einen Branch.
- Der Agent aktualisiert die Abhängigkeit und die Sperrdatei.
- Der Agent öffnet eine Pull-Anforderung, die einen strukturierten Plan und erwartete Erfolgssignale enthält.
Zu diesem Zeitpunkt kann die umfangsbezogene Verantwortung des Agenten als vollständig betrachtet werden. Validierung und Akzeptanz erfolgen durch Prüfungen, Überprüfungen und Richtlinienkontrollen.