Text size
Ausprobiert & getestet6 Min. Lesezeit

KI-Agenten in meiner Pipeline: Was funktioniert wirklich

Agenten, die Bauten reparieren und Pull-Anfragen öffnen, sind jetzt real. So lasse ich sie sicher rein.

AI agents in my pipeline: what actually works
KI-generierte Illustration

In Nimmt mir KI meinen DevOps-Job weg? Ich schrieb, dass KI wie ein sehr schneller Junior-Ingenieur ist, der nie müde wird und nie genau weiß, wann er falsch liegt. Ich sagte auch, ein neuer Teil meines Jobs wäre das Bauen von Geländer für KI-Agenten.

Dieser Beitrag ist die praktische Folge. Nicht "wird KI DevOps verändern", sondern: Welche Aufgaben können Sie heute einem Agenten überlassen, und wie stellen Sie sie so ein, dass ein Fehler klein bleibt?

Was hat sich geändert?

Vor ein oder zwei Jahren bedeutete KI in DevOps meistens Autovervollständigung im Editor oder das Einfügen eines Fehlers in ein Chatfenster. Nützlich, aber du warst immer am Steuer.

Agenten sind anders. Tools wie Claude Code, GitHub Copilot's Codierungsagent, Cursor's Hintergrundagenten und andere können eine Aufgabe übernehmen, das Repository lesen, Befehle ausführen, die Ergebnisse ansehen, erneut versuchen und eine Pull-Anfrage öffnen. Sie arbeiten in einer Schleife, keine einzige Antwort.

Das macht sie viel nützlicher und viel wichtiger zu kontrollieren.

Aufgaben, die ich gerne Agenten übergebe.

Das Muster ist: gut definiert, leicht zu überprüfen und überprüft, bevor es in Produktion geht.

Ich repariere einen defekten Bau. "Die Pipeline ist bei diesem Test ausfallen, finde heraus, warum und schlage eine Lösung vor". Der Agent liest die Protokolle, reproduziert den Ausfall und schlägt eine Änderung vor. Ein Mensch überprüft die Anfrage.

Abhängigkeits-Upgrades, die Codeänderungen erfordern. Renovate öffnet das Upgrade, die Tests scheitern, weil sich eine API geändert hat, der Agent aktualisiert die Anrufseiten.

Langeweile für Veränderungen in der Infrastruktur. Hinzufügen einer neuen Umgebungsvariable für Dienste, Aktualisierung von Ressourcenanfragen in Helm-Werten, Umbenennung eines Labels überall.

Erste Entwürfe schreiben. Eine neue Pipeline, eine Dockerfile, ein Terraform-Modul-Skelett, ein Runbook aus einer Vorfallzeitlinie.

Erklärungen und Dokumentationen. "Was macht dieses alte Skript?" wurde zu einem README.

Die Erlaubnisse, die ich ihnen gebe (und nicht gebe)

Das ist der wichtigste Teil. Meine Regeln:

  • Agenten arbeiten auf Zweigstellen, nie auf dem Hauptweg. Jede Änderung geht durch eine Anfrage und eine normale Überprüfung.
  • Keine Produktionsnachweise. - Niemals. Agenten werden in einem CI oder einer Sandbox ausgeführt, die nur Zugriff auf das Repository und die Testumgebung haben.
  • Kurzlebige, enge Token. Ein GitHub-Token, das zu Zweigen schieben und Pull-Anfragen öffnen kann, nicht einer, der die Repository-Einstellungen ändern oder seine eigenen PRs genehmigen kann.
  • Die Branchenschutzbehörde macht die Durchsetzung. Die erforderlichen Überprüfungen und Kontrollen gelten für Agenten genau wie für Menschen.
  • Netzwerkbeschränkungen, soweit möglich. Ein Agent, der einen Test fixiert, muss nicht das ganze Internet erreichen.
  • Alles ist protokolliert. Was der Agent lief, was es veränderte, wer es begann.

Behandeln Sie einen KI-Agenten wie einen neuen Auftragnehmer an seinem ersten Tag: hilfsbereit, eifrig und mit genau dem Zugriff, den die Aufgabe braucht, nichts mehr.

Wo sie immer noch scheitern

Agenten sind beeindruckend, aber ich sehe immer wieder dieselben Fehlermuster:

  • Der Test zu bestehen, anstatt den Fehler zu beheben. Manchmal ändert die "Fix" die Erwartung des Tests. Lesen Sie die Unterscheidung sorgfältig durch.
  • Es fehlt der Kontext. Der Agent weiß nicht, dass diese Einstellung existiert, wegen eines Ausfalls vor drei Jahren. Sie wird es gerne "aufräumen".
  • Zu breite Berechtigungen in generierten IAM-Richtlinien oder Kubernetes RBAC. * ist immer verlockend.
  • Sofortige Injektion. Ein Agent, der Probleme, Protokolle oder Webseiten liest, kann durch Text, der geschrieben wurde, um ihn zu manipulieren, getäuscht werden. Geben Sie einem Agenten, der unzuverlässige Eingaben liest, niemals die Macht, etwas Unumkehrbares zu tun.
  • Vertrauen. Das klingt immer sicher. Das ist nicht dasselbe wie Recht zu haben.

Meine Einrichtung, Schritt für Schritt

Wenn Sie das mit Ihrem Team versuchen wollen, hier ist ein sicherer Ausgangspunkt:

  1. Wählen Sie ein Repository mit guter Testbedeckung.
  2. Erstellen Sie eine spezielle Bot-Identität mit nur Zweig-Push-Rechten.
  3. Die Agentur wird in einem CI (oder einem Behälter) ausgeführt, der durch ein Etikett oder einen Kommentar ausgelöst wird, z. B. durch Hinzufügen agent:fix zu einer scheiternde PR.
  4. Gib ihm eine klare Anweisungsdatei im Repo: wie man baut, wie man testet, was nicht anfasst.
  5. Erfordert eine menschliche Überprüfung für jede Zuganfrage, die er öffnet.
  6. Verfolgen Sie die Ergebnisse für einen Monat: Wie viele PRs wurden zusammengeführt, wie viele mussten überarbeitet werden, wie viele waren falsch.

Nach einem Monat wissen Sie, wo es tatsächlich Zeit für Ihr Team spart, was jeden Anbieter-Benchmark übertrifft.

Also, ist es das wert?

Ja, für die richtigen Aufgaben. Agenten entfernen viele kleine, lästige Arbeiten, und sie werden schnell besser. Aber der Wert hängt ganz von den Rängen um sie herum ab. Gute Tests, gute Bewertungen und enge Berechtigungen machen einen Agenten von einem Risiko zu einem sehr produktiven Teamkollegen.

Meine Meinung: Lassen Sie Agenten vorschlagen, lassen Sie Pipelines überprüfen und lassen Sie Menschen entscheiden. Die gleiche Regel wie vorher, jetzt mit echten Werkzeugen dahinter.

Desly