Agent-Rollen

Coroid setzt nicht auf einen einzigen allgemeinen Agenten. Jede Phase des Weges von der Beschreibung bis zu pull request wird von einem Agenten mit einem eng begrenzten Aufgabenbereich und bewusst eingeschränkten Werkzeugen bearbeitet.

Die Einschränkungen sind genau der Sinn dahinter: Ein Agent, der kein Code schreiben kann, wird auch nicht versehentlich Code erstellen.

Die Rollen#

Rolle	Phase	Kann Ihren Code ändern
Architekt	Spezifikation und Plan	Nein
Entwickler	Erstellen	Ja
QA	Überprüfen	Nein
Rezensent	Rezension	Nein
Webtester	Überprüfen, Browser-Abläufe	Nein
Explorer	Recherche, jede Phase	Nein
Abhängigkeitsanalyst	Analyse	Nein

Die ersten vier sind die Lieferungs-Agenten, die Sie bei jeder Aufgabe sehen. Im Standard-Modus laufen sie in dieser Reihenfolge:

Architekt → Entwickler → QA → Rezensent

Im Koordinator-Modus entscheidet ein Koordinator über die Reihenfolge während der Ausführung der Aufgabe. Beide Varianten werden unten beschrieben.

Nur eine Rolle – der Entwickler – darf Dateien in Ihrem Repository ändern. Alle anderen Agenten lesen, führen aus, berichten oder erstellen Nachfolgearbeiten.

Zwei Ausführungsweisen einer Aufgabe#

Eine Aufgabe läuft in einem von zwei Modi. Dabei wird AI-Profil sowie Ihre Bereitstellung darüber entscheiden, welcher Modus genutzt wird.

Koordinator-Modus. Der Architekt übergibt seinen Plan nicht einfach und verschwindet anschließend. Er bleibt als Koordinator bei der Aufgabe. Nach der Planung gibt der Koordinator dem Entwickler seine Anweisungen und wartet auf den Bericht. Anschließend beauftragt er das QA-Team, das Ergebnis zu prüfen, und den Rezensenten, die vom QA-Team genehmigte Version zu überprüfen. Nach jedem Bericht entscheidet der Koordinator über die nächsten Schritte: die Ergebnisse an den Entwickler zurücksenden, eine Frage beantworten, den Plan anpassen oder die Aufgabe abschließen. Die Nachbesserung ist für den Koordinator ein zusätzlicher Schritt, kein neuer Durchlauf.

Standard-Modus. Die Plattform leitet die Aufgabe in einer festen Reihenfolge durch die vier Agenten. Bei einem fehlgeschlagenen Check wird die Aufgabe an den Entwickler zurückgesendet. Einige Arbeitsschritte laufen immer so ab, etwa die Lösung eines Merge-Konflikts. Der Standard-Modus dient außerdem als Fallback, wenn der Koordinator-Modus nicht verfügbar ist.

In beiden Modi übernehmen dieselben Agenten die Arbeit unter denselben Einschränkungen und Prüfschritten. Der Unterschied liegt darin, wer den nächsten Schritt bestimmt: die Plattform im Standard-Modus oder der Koordinator im Koordinator-Modus.

Der Koordinator#

Der Koordinator ist der Planungs-Agent, der bei der Aufgabe bleibt. Er liest Ihren Codebestand aus, darf ihn jedoch nicht ändern; alles, was er tut, dient der Steuerung.

Was der Koordinator tut#

• Plant. Der Koordinator durchsucht das Repository und speichert anschließend den Plan samt den Akzeptanzkriterien, anhand derer festgestellt wird, ob die Arbeit erfolgreich war.
• Delegiert. Der Koordinator arbeitet jeweils mit einem Agenten gleichzeitig. Seine Anweisungen enthalten das Ziel, eventuelle Akzeptanzkriterien, die besondere Aufmerksamkeit erfordern, sowie bei der Rücksendung der Arbeit die genauen Korrekturen. Während der Agent arbeitet, wartet der Koordinator und nutzt dabei keine Modellzeit.
• Beantwortet Fragen. Ein Agent, der eine Entscheidung treffen muss, kann den Koordinator um Rat fragen. Der Koordinator gibt die Entscheidung samt Begründung weiter – die Frage bleibt dabei nicht unbeantwortet.
• Reagiert. Fällt die Qualitätssicherung das Ergebnis als nicht ausreichend aus oder verlangt der Rezensent Änderungen, leitet der Koordinator die Korrekturen an den Entwickler weiter und die Qualitätssicherung prüft die neue Version.
• Beendet die Aufgabe. Der Koordinator schließt die Aufgabe ab oder stellt fest, dass sie fehlgeschlagen ist, und nennt den Grund dafür.

Was der Koordinator nicht tun kann#

Der Koordinator steuert den Prozess – er urteilt jedoch nicht. Die Plattform setzt diese Grenzen durch, sodass sie nicht vom Willen des Koordinators abhängen:

1. Urteile obliegen der Qualitätssicherung und dem Rezensenten. Nur die Qualitätssicherung und der Rezensent fällen Urteile – jeweils auf Basis ihres eigenen Ergebnisses. Die Anweisungen des Koordinators beinhalten kein Urteil, und der Koordinator kann einen Prüfschritt nicht als bestanden markieren.
2. Zum Abschluss sind die Prüfschritte erforderlich. Eine Aufgabe ist erst abgeschlossen, wenn die QA die exakte Version, die ausgeliefert werden soll (oder den aktuellen Code, falls sich nichts ändert), erfolgreich geprüft hat und – sofern eine Rezension erforderlich ist – der Rezensent diese Version genehmigt hat. Falls sich die Branch nach der QA-Prüfung geändert hat, wird die Fertigstellung abgelehnt und die neue Version geht zurück an die QA.
3. Nachbesserungen sind begrenzt. Jeder Agent darf pro Aufgabe nur eine begrenzte Anzahl Mal aktiviert werden, und ein Plan darf nur wenige Male überarbeitet werden. Auch die Anzahl der Schritte sowie die Gesamtausführungszeit sind begrenzt. Sobald diese Grenzen erreicht sind, kann der Koordinator die Aufgabe nur noch abschließen oder als fehlgeschlagen kennzeichnen.
4. Wartezeiten sind begrenzt. Jede Wartezeit hat eine Frist.

Eine von einem Koordinator gesteuerte Aufgabe endet somit auf eine von drei Arten: mit einem pull request, den Sie genehmigen müssen; mit der Bestätigung der QA, dass der Code bereits das verlangte Verhalten zeigt und somit nichts geändert werden muss; oder mit einer fehlgeschlagenen Aufgabe, die den Grund dafür angibt. Eine Aufgabe endet nicht einfach dadurch, dass der zuständige Agent sie als fertig markiert.

Mögliche Routen eines Koordinators#

Der Koordinator entscheidet, wie eine Aufgabe die Prüfschritte durchläuft. Die oben genannten Prüfschritte sind auf jeder Route identisch.

• Die vollständige Route. Planen, erstellen, überprüfen, rezensieren, abschließen. So läuft eine Aufgabe ab, es sei denn, der Koordinator hat einen Grund, eine andere Route zu wählen.
• Arbeit zurücksenden. Falls die QA die Arbeit nicht besteht oder der Rezensent Änderungen verlangt, gehen die Korrekturen zurück an den Entwickler. Die neue Version muss anschließend die QA bestehen, bevor die Aufgabe abgeschlossen werden kann. Ein erfolgreicher Test der vorherigen Version gilt für die neue Version nicht.
• Bereits erledigt. Der Code erfüllt möglicherweise bereits die Anforderungen der Aufgabe. Der Koordinator kann dann die QA beauftragen, den unveränderten Code gegen die Annahmekriterien zu prüfen, anstatt etwas neu zu erstellen. Wenn die QA besteht und der Rezensent bei Bedarf die Version genehmigt, ist die Aufgabe abgeschlossen – ohne dass ein pull request benötigt wird, da nichts zusammengeführt werden muss. Die Prüfung durch die QA ist das Ergebnis. Diese Route wird geschlossen, sobald die Ausführung selbst eine Änderung hervorbringt, denn sonst würde die QA Code genehmigen, der nicht ausgeliefert wird.

Zwei kürzere Routen stehen optional zur Verfügung. Coroid nutzt sie standardmäßig nicht. Sie ändern die Route des Koordinators, niemals die Prüfschritte:

• Eine schnelle Änderung. Bei einer kleinen Korrektur an einem bekannten Ort erstellt der Koordinator einen kürzeren Plan und gibt dem Entwickler eine gezielte Anweisung, die die betroffenen Dateien nennt. Der Entwickler arbeitet innerhalb eines kleineren Schrittbudgets, und alle Änderungen außerhalb dieser Dateien werden der QA und dem Rezensenten gemeldet.
• Eine eingeschränkte erneute Prüfung. Nach einer kleinen Korrektur für ein von der QA oder dem Rezensenten festgestelltes Problem startet die QA bei diesem Ergebnis sowie den Projekttests. Dennoch gibt sie ihr Urteil über die gesamte neue Version ab.

Wenn ein Rezensent erforderlich ist#

Standardmäßig durchläuft jede eigenständig ausgeführte Aufgabe immer den Rezensenten. Unabhängig von der gewählten Route des Koordinators – auch wenn keine Änderungen nötig waren – kann die Aufgabe nicht abgeschlossen werden, bis der Rezensent die von der QA geprüfte Version genehmigt hat. Die QA führt die Überprüfung immer durch, egal ob eine Rezension stattfindet oder nicht; eine Rezension ersetzt niemals das Bestehen der QA-Prüfung. Aufgaben, die Teil eines Plans sind, folgen den Regeln ihres jeweiligen Bereichs.

Coroid verfügt außerdem über eine optionale, risikobasierte Richtlinie. Sie ist standardmäßig nicht aktiviert. Unter ihrer Anwendung kann eine eigenständig ausgeführte Aufgabe ohne Rezensenten abgeschlossen werden, sofern die Änderung klein und alltäglich ist. Ein Rezensent bleibt jedoch erforderlich, wenn:

• eine Rezension für die Aufgabe bereits begonnen wurde oder die Revisionsregeln Ihres Projekts bzw. das Qualitätsmodell Ihrer Organisation eine solche verlangen;
• die Änderung Authentifizierung, Sitzungen, Berechtigungen, Geheimnisse oder Kryptografie, Datenbankmigrationen, Build- und Deploy-Konfigurationen, Abhängigkeitsdateien oder Code betrifft, der mit externen Diensten kommuniziert;
• die Änderung groß ist (standardmäßig mehr als 80 geänderte Zeilen) oder Binärdateien, symbolische Links oder Submodule enthält;
• Coroid kann die Richtlinie oder die Änderung selbst nicht einsehen. Im Zweifelsfall ist ein Rezensent erforderlich.

Eine Änderung, die nichts verändert, benötigt niemals einen Rezensenten. Diese Entscheidung trifft der Code, nicht der Koordinator – und der Koordinator kann sie nicht umgehen. Am Ende der pull request-Beschreibung steht angegeben, welcher Weg gewählt wurde und warum. Es beginnt mit „Rezensent erforderlich“ oder „Rezensent nicht erforderlich“.

Architekt#

Wandelt Ihre Beschreibung in eine Spezifikation um und die Spezifikation in einen Plan. Er liest den Codebestand aus, um den Plan auf die tatsächliche Situation abzustimmen – schreibt jedoch keinen Code.

Das Ergebnis dieses Agents ist das Dokument, das Sie vor dem Build-Vorgang genehmigen. Im Coordinator-Modus übernimmt dieser Agent anschließend die Rolle des Koordinators.

Entwickler#

Führt die Arbeit aus: liest den relevanten Code, führt die Änderungen vor, schreibt oder aktualisiert die Tests und führt diese lokal im Arbeitsbereich aus, bis sie erfolgreich sind.

Wenn der Rezensent die Ergebnisse zurücksendet, dann Entwickler ist die Rolle, die darauf reagiert. Im Coordinator-Modus übermittelt der Koordinator die Ergebnisse weiter und gibt die erforderlichen Korrekturen an.

Qualitätssicherung#

Führt die Verifizierung unabhängig vom Agenten durch, der den Code geschrieben hat – Ihr Test-Suite, die für das Projekt konfigurierten Qualitätsprüfungen sowie die aus der Spezifikation abgeleiteten Annahmekriterien.

Die Qualitätssicherung gibt ein Urteil ab. Sie behebt die gefundenen Fehler nicht; diese werden zurück an den Entwickler als Nachbesserungsaufgabe übergeben.

Rezensent#

Liest die fertige Diff-Datei und erstellt Ergebnisse, wobei die von Ihrer Organisation festgelegten Revisionsregeln angewendet werden. Die Ergebnisse werden entweder als Nachbesserungsaufgabe an den Entwickler zurückgesendet oder dem pull request zugeordnet.

Webtester#

Steuert einen echten Browser gegen eine laufende Vorschau Ihrer Anwendung, um Benutzerabläufe end-to-end zu überprüfen. Dies wird dort eingesetzt, wo sich aus dem Code allein keine Aussage über das Verhalten treffen lässt.

Explorer#

Eine lese-only-Forschungsrolle. Andere Agenten nutzen sie, um Fragen zum Codebestand zu beantworten, ohne alles in ihren eigenen Kontext laden zu müssen – „Wo wird die Authentifizierung gehandhabt?“, „Welche Funktion ruft diese auf?“.

Abhängigkeitsanalyst#

Untersucht Abhängigkeiten und wie sich Änderungen im gesamten Codebestand auswirken, einschließlich der Konfiguration von Abhängigkeiten zwischen Projekten.

Warum die Trennung wichtig ist#

Durch diese Aufteilung der Arbeit ergeben sich vier wesentliche Eigenschaften:

1. Die Überprüfung erfolgt unabhängig. Der Agent, der die Arbeit prüft, ist nicht derselbe, der sie erstellt hat – somit hat er kein Interesse am Ergebnis.
2. Der potenzielle Schaden ist begrenzt. Nur die Rolle des Entwicklers verfügt über Werkzeuge zum Code-Schreiben; ein Fehler bei der Rezension oder Analyse kann Ihr Repository daher nicht beschädigen.
3. Jede Rolle nutzt ein ihr entsprechendes Modell. Bei der Planung zählt ein breites Weltwissen; beim Schreiben von compilierbarem Code kommt etwas anderes ins Spiel. AI-Profil Es enthält aus genau diesem Grund für jede Rolle ein eigenes Modell.
4. Über die Abgeschlossenheit entscheiden die Prüfungen – nicht der zuständige Agent. Im Modus „Koordinator“ kann der Agent, der die Aufgabe steuert, diese nicht abschließen, ohne die Stellungnahmen des QA-Teams und des Rezensenten einzuholen.

Weiter#

Zurück zu Wie eine Aufgabe zu einem pull request wird für die Zuordnung dieser Rollen zu den jeweiligen Phasen oder Was ist Coroid? für eine kurze Übersicht.