Eine Aufgabe ausführen und das Ergebnis prüfen

Eine Aufgabe anlegen

Öffne die Seite Aufgaben eines Projekts, oder den Tab Aufgaben in der Konsole einer Instanz, und lege eine an. Du gibst ihr mit:

• Ein Titel und eine Beschreibung. Was sich ändern soll, in normaler Sprache. Details helfen: dieselbe Anfrage mit zwei Sätzen Kontext ergibt einen deutlich besseren Plan als die Anfrage allein.
• Die Instanz, in der gearbeitet wird. Sie entscheidet, welche Codebasis der Agent liest und auf welchen Branch das Ergebnis gepusht wird.
• Optional Skills und Anhänge. Skills sind deine Hauskonventionen; Anhänge sind Dateien, die der Agent als Kontext haben soll, etwa eine Spezifikation oder ein Screenshot des Problems.

Das Anlegen von Aufgaben braucht die Berechtigung für Agent-Aufgaben. Ist das Abonnement des Projekts unbezahlt und das Projekt auf nur lesen gegangen, wird das Anlegen von Aufgaben zusammen mit jeder anderen Aktion abgelehnt.

Die Produktionsinstanz als Ziel verlangt, dass du beim Anlegen der Aufgabe confirm tippst, und die Aufgabe gilt von da an als Produktionsaufgabe.

Den Plan lesen

Der Agent nimmt die Aufgabe auf, liest die Codebasis und schreibt einen Plan zurück. Zu diesem Zeitpunkt ist noch nichts geändert.

Lies den Plan selbst, nicht nur seine erste Zeile. Das ist deine einzige Gelegenheit, ein Missverständnis abzufangen, bevor Code geschrieben wird, und der Aufwand, ihn zu lesen, ist weit geringer als der Aufwand, eine schlechte Änderung hinterher wieder aufzudröseln.

Dann wählst du:

• Freigeben und ausführen: der Agent setzt den Plan um.
• Änderungen anfordern: beschreibe, was falsch ist, und er plant erneut, mit deinem Feedback im Gepäck.
• Erneut planen: lässt die Planung unverändert noch einmal laufen, nützlich, wenn der erste Versuch fehlgeschlagen ist statt danebengegangen. Mit Hinweisen erneut planen macht dasselbe mit einer Notiz von dir.
• Aufgabe abbrechen: stoppt sie.

Das Freigeben braucht die Berechtigung zur Planfreigabe.

Manchmal meldet der Agent den Plan als gesperrt: er hat entschieden, dass er die Arbeit nicht sicher erledigen kann oder dass die Anfrage nicht klar genug ist. Ein gesperrter Plan wartet immer auf einen Menschen, auch in einem Projekt mit eingeschalteter automatischer Ausführung.

Was in git landet

Sobald du freigibst, nimmt der Agent die Änderung im Container der Instanz vor, committet sie und pusht auf den Branch dieser Instanz. Dieser Push deployt die Instanz neu, das Ergebnis läuft also dort, wo du es dir ansehen kannst.

Es gibt keinen Pull Request. Der Commit geht direkt auf den Branch, aus dem die Instanz deployt ist, deshalb ist die Instanz, die du wählst, wichtig, und deshalb ist die Produktion hinter zwei Bestätigungen abgeschirmt.

Wenn der Lauf endet, ohne dass etwas geändert werden musste, sagt er das, statt einen Commit zu erfinden.

Wenn das Ergebnis nicht stimmt

Nutze Weitere Runde starten auf der Aufgabe. Beschreibe, was falsch ist, und der Agent plant eine Korrektur, aufbauend auf dem Code, den er bereits gepusht hat, statt neu anzufangen. Du gibst den neuen Plan frei, bevor etwas läuft, und der bestehende Commit bleibt auf dem Branch.

Runden werden auf der Aufgabe gezählt, du siehst also, wie viele Durchgänge ein Stück Arbeit gebraucht hat und was jeder davon geändert hat.

Wenn etwas schiefgeht

• Die Instanz startet nicht mit dem, was der Lauf committet hat. CICDoo verschiebt diese Commits auf einen Rescue-Branch, setzt den Branch der Instanz zurück und bringt Odoo wieder hoch. Nichts wird gepusht und nichts geht verloren: die Arbeit liegt auf dem Rescue-Branch, falls du sie willst.
• Der Push schlägt fehl. Die Arbeit bleibt im Arbeitsverzeichnis des Containers, statt zu verschwinden.
• Der Lauf trifft auf das Nutzungslimit deines Anbieters. Die Aufgabe pausiert und sagt dir, wann das Limit zurückgesetzt wird. Fortsetzen macht mit dem freigegebenen Plan an dieser Stelle weiter; es ist dieselbe Runde, unterbrochen, keine neue.
• Der Lauf meldet sich nicht mehr. Stirbt ein Container mitten in der Arbeit, wird die Aufgabe als fehlgeschlagen markiert, statt ewig zu hängen. Meldet sich der Agent danach doch noch verspätet, wird das Ergebnis trotzdem übernommen.

Den Verbrauch im Blick behalten

Der Tab Verbrauch der Aufgabe listet jeden Lauf dahinter: welche Runde und Phase, wer ihn ausgelöst hat, das Ergebnis, Tokens rein und raus und die gebrauchte Zeit. Die Seite /agent fasst das über Projekte hinweg zusammen, mit Diagrammen über die letzten 30 Tage, 90 Tage oder 12 Monate.

Wiederholungen und Fehlschläge werden mitgezählt. Das ist Absicht: sie kosten echte Agent-Zeit, und eine Aufgabe, die vier Anläufe gebraucht hat, soll auch danach aussehen.

Nächste Schritte

Wie diese Zeit gemessen und bezahlt wird, steht unter Agent-Zeit und Aufstockungen. Zum Aktivieren der Funktion und zum Verbinden einer CLI siehe Agent-Aufgaben einrichten.

Wenn du nicht weiterkommst, öffne ein Support-Ticket über die Seite Tickets oder das Chat-Widget.