Vorschläge und Validierung
Vorschläge und Validierung
Wie die Änderungen von Architect getestet, überprüft und für Live-Traffic eingeführt werden.
Überblick
Wenn Architect eine Änderung abgeschlossen hat, übergibt es sie Ihnen als Vorschlag: einen Branch mit der Änderung, Tests, die ihre Funktion bestätigen, und einem Merge-Vorschlag, der darum bittet, diesen Branch in main zu mergen. Diese Seite erklärt, wie die einzelnen Teile funktionieren, wo Sie sie finden und wie ein Vorschlag von einer Unterhaltung in den Live-Traffic gelangt.
Was ein Vorschlag ist
Ein Vorschlag basiert auf dem bestehenden Versionierungsmodell:
Der Merge-Vorschlag ist ein standardmäßiger ElevenAgents-Merge-Vorschlag, also derselbe Typ, den ein Teammitglied manuell erstellt. Er ist kein eigener Objekttyp.
Ein Merge-Vorschlag umfasst genau einen Quell- und einen Ziel-Branch. Ein Vorschlag enthält also genau eine mögliche Lösung. Um Alternativen zu vergleichen, bitten Sie Architect, jede auf einem eigenen Branch bereitzustellen. Jeder Branch erhält dann einen eigenen Vorschlag, und Sie können den Traffic zwischen ihnen als Experiment aufteilen.
Architect handelt in Ihrem Namen. Ein von ihm eröffneter Merge-Vorschlag wird daher unter Ihrem Namen als Autor erfasst. Es gibt kein Feld, das festhält, dass Architect ihn erstellt hat. Erwähnen Sie dies in der Beschreibung des Vorschlags, wenn Ihr Team es wissen soll.
Wie ein Vorschlag erstellt wird
Architect erstellt einen Vorschlag, wenn Sie es bitten, etwas zu beheben oder zu verbessern, oder wenn Sie ihm einen fehlschlagenden Test, einen Spotlight-Befund oder ein Triage-Ticket übergeben. Die vollständige Abfolge mit den Tools, die Architect bei jedem Schritt aufruft, finden Sie im durchgearbeiteten Beispiel. Kurz gesagt:
- Architect untersucht das Problem, erstellt einen Branch und stellt die Änderung in Ihrem Entwurf auf diesem Branch bereit.
- Architect schreibt Tests und Simulationen für die Änderung und führt sie in der Unterhaltung aus, bevor es Ihnen das Ergebnis zeigt.
- Architect öffnet den Veröffentlichungsdialog. Sie prüfen den Diff und wählen Veröffentlichen. Dadurch wird die Änderung als neue Version auf dem Branch gespeichert.
- Architect erstellt einen Merge-Vorschlag für
mainund schreibt dessen Beschreibung anhand der tatsächlichen Commits und Testausführungen des Branches. - Architect bietet an, während der Prüfung des Vorschlags einen kleinen Anteil des Live-Traffics an den Branch zu senden. Dafür ist Ihre Zustimmung erforderlich.
Sie können bei jedem Schritt anhalten. Ein Branch mit einer veröffentlichten Version, aber ohne Merge-Vorschlag, ist weiterhin nützlich: Sie können ihn selbst testen oder später einen Vorschlag erstellen.
Validierung in der Unterhaltung
Architect schreibt und führt Tests beim Erstellen der Änderung aus, nicht als separaten Schritt, den Sie später starten. Bei einem Fix ist es sinnvoll zu zeigen, dass die neuen Tests ohne die Änderung fehlschlagen und mit ihr bestehen. Architect kann dieselben Tests gegen den ursprünglichen Branch und gegen den Entwurf mit der Änderung ausführen.
Architect führt diese Vorher-Nachher-Prüfung nicht automatisch bei jeder Änderung aus. Bitten Sie darum, wenn sie wichtig ist, zum Beispiel: „Zeig mir, dass die neue Simulation auf main fehlschlägt und auf dem Branch besteht, und erstelle dann einen Vorschlag.“
Ein Test besteht, wenn alle Erfolgsbedingungen erfüllt sind. Bei einem LLM-Test erfüllt die Antwort des Agenten die Erfolgskriterien. Bei einem Tool-Call-Test wird das erwartete Tool mit den erwarteten Parametern aufgerufen. Bei einer Simulation erfüllt die simulierte Unterhaltung ihre Erfolgsbedingungen. Um auf schwankende Ergebnisse zu prüfen, bitten Sie Architect, Tests mehrmals auszuführen. Es kann jeden Test bis zu 50-mal wiederholen und die Erfolgsrate berichten.
Unter Tests erfahren Sie, wie jeder Testtyp definiert ist.
Wo Sie Vorschläge finden
Öffnen Sie den Agenten und gehen Sie dann zu Versionskontrolle > Vorschläge. Die Liste kann nach Status, Autor (Erstellt von) und Reviewer (Wartet auf Prüfung durch, Geprüft von) gefiltert werden. Ein von Architect in Ihrer Unterhaltung erstellter Vorschlag wird mit Ihnen als Autor aufgeführt.
Sobald Architect einen Vorschlag erstellt, sendet es Ihnen auch einen Link dazu in der Unterhaltung.
Aufbau eines Vorschlags
Auf der Seite eines Vorschlags sehen Sie Quell- und Ziel-Branch, Status, Merge-Möglichkeit sowie den Rückstand oder Vorsprung des Quell-Branches gegenüber dem Ziel. Sie enthält diese Tabs:
Übersicht
Änderungen
Testausführungen
Unterhaltungen
Die Beschreibung, eine Aktivitätszeitleiste der Commits auf dem Quell-Branch, Reviews und Kommentare sowie ein Kommentarfeld. Die Seitenleiste zeigt Reviewer, empfohlene Reviewer und verknüpfte Triage-Tickets.
Eine von Architect verfasste Beschreibung hat immer drei Abschnitte: Zusammenfassung (jede wichtige Änderung und ihr Grund), Tests (welche Tests ausgeführt wurden und ihre Ergebnisse oder der Hinweis, dass keine ausgeführt wurden) und So prüfen Sie (worauf Sie achten sollten und einen auszuführenden Test oder eine auszuprobierende Unterhaltung).
Prüfen und mergen
Status
Ein Merge-Vorschlag hat einen dieser Status:
Solange ein Vorschlag offen ist, lautet das letzte Review jedes Reviewers entweder Genehmigt oder Änderungen angefordert. Es gibt keine separaten Status wie „getestet“ oder „bereit zur Prüfung“. Testergebnisse werden stattdessen im Tab Testausführungen angezeigt.
Reviews und Kommentare erscheinen in der Aktivitätszeitleiste im Tab Übersicht, zusammen mit jeder neuen Version, die auf dem Quell-Branch gespeichert wurde.
Wer genehmigen und mergen kann
- Alle Personen mit Editorzugriff auf den Agenten können einen Vorschlag prüfen, außer dem Autor. Da Architect in Ihrem Namen handelt, können Sie keinen Vorschlag genehmigen, den Architect in Ihrer Unterhaltung erstellt hat. Das muss ein Teammitglied übernehmen.
- Ein Vorschlag kann gemergt werden, sobald er mindestens eine Genehmigung von einer anderen Person als dem Autor hat und das letzte Review keines Reviewers Änderungen angefordert lautet. Workspace-Admins können ohne Genehmigung mergen.
- Das Mergen in einen geschützten Branch erfordert Admin-Berechtigungen oder die Genehmigung eines Admins.
Architect kann einen Merge-Vorschlag nicht genehmigen, kommentieren, mergen oder schließen. Diese Schritte werden immer von Menschen ausgeführt. Unter Merge-Vorschläge finden Sie die vollständigen Review-Regeln.
Architect kann einen Branch auf Ihre Anweisung direkt und ohne Vorschlag mergen, wenn Ihre Rolle das
Mergen erlaubt. Im Modus Genehmigung erforderlich fragt es zuerst. Im Modus Automatisch genehmigen nicht. Verwenden Sie
Branch-Schutz für main, wenn jede Änderung über einen geprüften Vorschlag erfolgen muss.
Was beim Merge passiert
Nach einem Merge gibt es keinen separaten Veröffentlichungsschritt. Beim Mergen wird eine neue Version auf dem Ziel-Branch erstellt. Diese Version bedient sofort Live-Traffic entsprechend dem Traffic-Anteil des Ziels. Wenn das Ziel main ist und keine Traffic-Aufteilung festgelegt ist, betrifft das alle Anrufer.
Ein Merge bewirkt außerdem Folgendes:
- Der Live-Traffic-Anteil des Quell-Branches wird auf das Ziel übertragen.
- Der Quell-Branch wird standardmäßig archiviert.
- Alle anderen offenen Vorschläge vom selben Branch werden geschlossen.
- Das verknüpfte Triage-Ticket wird gelöst, falls vorhanden.
Schrittweiser Rollout
Bevor ein Vorschlag gemergt wird, können Sie einen Anteil des Live-Traffics an seinen Branch senden, damit echte Anrufer die Änderung nutzen.
Aufteilung starten
Bitten Sie Architect beispielsweise: „Sende 5 % des Traffics an diesen Branch.“ Architect nennt Ihnen die vollständige
resultierende Aufteilung einschließlich des Anteils von main und bittet vor der Anwendung um Ihre Genehmigung. Sie können
sie auch selbst festlegen: Wählen Sie unter Versionskontrolle > Branches beim Branch Bereitstellen.
Ergebnisse beobachten
Öffnen Sie den Tab Unterhaltungen des Vorschlags, um Unterhaltungen auf dem Branch zu lesen, oder bitten Sie Architect,
die Ergebnisse des Branches mit denen von main zu vergleichen.
Übernehmen oder zurücksetzen
Um die Änderung zu übernehmen, mergen Sie den Vorschlag. Der Traffic-Anteil des Branches wechselt dabei zu main. Zum
Zurücksetzen bitten Sie Architect, den Anteil des Branches auf 0 % zu setzen, oder bearbeiten Sie die Bereitstellung selbst.
Der Live-Traffic kehrt sofort zu main zurück.
Die Traffic-Anteile müssen immer zusammen 100 % ergeben. Das Routing ist pro Unterhaltung deterministisch. Das Ändern des Anteils eines geschützten Branches, einschließlich des Abziehens von Traffic von einem geschützten main, erfordert einen Admin. Siehe Traffic-Bereitstellung.
Proaktive Vorschläge
Architect erstellt Vorschläge, wenn Sie es darum bitten oder wenn Sie ihm einen fehlschlagenden Test, einen Spotlight- Befund, einen Alert oder ein Triage-Ticket übergeben. Es überprüft Ihre Agenten noch nicht nach Zeitplan und erstellt auch nicht eigenständig Vorschläge.
Der proaktive Ablauf besteht heute aus Spotlight und einer anschließenden Übergabe. Spotlight überwacht die Unterhaltungen Ihres Agenten kontinuierlich. Es erstellt eine wöchentliche Zusammenfassung mit vorgeschlagenen Untersuchungen, löst Echtzeit-Alerts aus und empfiehlt Konfigurationsänderungen. So machen Sie aus einem Spotlight-Befund einen Vorschlag:
Befund auswählen
Öffnen Sie die wöchentliche Zusammenfassung und prüfen Sie Vorgeschlagene nächste Schritte, oder öffnen Sie einen Echtzeit-Alert.
An Architect übergeben
Wählen Sie bei einem Vorschlag In Architect öffnen, in der Zusammenfassung Mit Architect analysieren oder bei einem Alert Mit Architect untersuchen. Architect erhält den Befund und die Anweisung, ihn anhand echter Unterhaltungen zu überprüfen und den betroffenen Branch zu bestimmen, bevor es eine Änderung vorschlägt.
Triage-Tickets funktionieren genauso. Ihr Live-Agent kann während Unterhaltungen Probleme zur Prüfung markieren, und Mit Architect besprechen auf einem Ticket startet dessen Untersuchung.
Geplante Automatisierungen mit Berichten, die an einen Architect-Posteingang gesendet werden, befinden sich in Entwicklung. Der Tab Posteingang auf der Architect-Seite ist ein Platzhalter dafür.