Vorschläge und Validierung

Überblick

Wenn ElevenAgents Architect eine Änderung abschließt, übergibt es sie Ihnen als Vorschlag: einen Branch mit der Änderung, Tests, die zeigen, dass sie funktioniert, und einem Merge-Vorschlag, der beantragt, diesen Branch in main zu mergen. Diese Seite erklärt, wie die einzelnen Teile funktionieren, wo Sie sie finden und wie ein Vorschlag vom Gespräch bis zum Live-Traffic gelangt.

Was ein Vorschlag ist

Ein Vorschlag basiert auf dem bestehenden Versionierungsmodell:

Der Merge-Vorschlag ist ein standardmäßiger ElevenAgents-Merge-Vorschlag, derselbe Typ, den Teammitglieder manuell öffnen. Er ist kein separater Objekttyp.

Ein Merge-Vorschlag umfasst genau einen Quell- und einen Ziel-Branch. Ein Vorschlag enthält also eine Kandidatenlösung. Um Alternativen zu vergleichen, bitten Sie Architect, jede auf einem eigenen Branch abzulegen. Jeder Branch erhält dann einen eigenen Vorschlag, und Sie können den Traffic als Experiment zwischen ihnen aufteilen.

So wird ein Vorschlag erstellt

Architect erstellt einen Vorschlag, wenn Sie es bitten, etwas zu beheben oder zu verbessern, oder wenn Sie ihm einen fehlgeschlagenen Test, ein Spotlight-Ergebnis oder ein Triage-Ticket übergeben. Die vollständige Abfolge mit den Tools, die Architect bei jedem Schritt aufruft, finden Sie im Praxisbeispiel. Kurz gesagt:

1. Architect untersucht das Problem, erstellt einen Branch und legt die Änderung in Ihrem Entwurf auf diesem Branch ab.
2. Architect schreibt Tests und Simulationen für die Änderung und führt sie im Gespräch aus, bevor es Ihnen das Ergebnis zeigt.
3. 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.
4. Architect öffnet einen Merge-Vorschlag nach main und schreibt die Beschreibung auf Basis der tatsächlichen Commits und Testausführungen des Branches.
5. 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 stoppen. 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 öffnen.

Validierung im Gespräch

Architect schreibt und führt Tests beim Erstellen der Änderung aus, nicht als separaten Schritt, den Sie anschließend starten. Bei einer Fehlerbehebung 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 bei jeder Änderung automatisch aus. Bitten Sie darum, wenn es wichtig ist, zum Beispiel: „Zeig mir, dass die neue Simulation auf main fehlschlägt und auf dem Branch besteht, und öffne dann einen Vorschlag.“

Ein Test besteht, wenn jede Erfolgsbedingung erfüllt ist. 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 das simulierte Gespräch die Erfolgsbedingungen. Um auf instabile Ergebnisse zu prüfen, bitten Sie Architect, Tests mehrmals auszuführen. Es kann jeden Test bis zu 50-mal wiederholen und die Bestehensrate melden.

Unter Tests erfahren Sie, wie die einzelnen Testtypen definiert sind.

Wo Sie Vorschläge finden

Öffnen Sie den Agenten und gehen Sie dann zu Versionskontrolle > Vorschläge. Die Liste lässt sich nach Status, Autor (Erstellt von) und Reviewer (Wartet auf Prüfung durch, Geprüft von) filtern. Ein Vorschlag, den Architect in Ihrem Gespräch geöffnet hat, wird mit Ihnen als Autor aufgeführt.

Architect gibt außerdem einen Link zum Vorschlag im Gespräch zurück, sobald es ihn erstellt.

Aufbau eines Vorschlags

Die Seite eines Vorschlags zeigt Quell- und Ziel-Branch, Status, ob er gemergt werden kann und wie weit der Quell-Branch hinter oder vor dem Ziel-Branch liegt. Sie hat folgende Tabs:

Prüfen und mergen

Status

Ein Merge-Vorschlag hat einen dieser Status:

Solange ein Vorschlag offen ist, lautet das aktuellste Review jedes Reviewers entweder Genehmigt oder Änderungen angefordert. Es gibt keine separaten Status wie „getestet“ oder „bereit für Review“. 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 Editor-Zugriff auf den Agenten können einen Vorschlag prüfen, außer dessen Autor. Da Architect in Ihrem Namen handelt, können Sie einen Vorschlag, den Architect in Ihrem Gespräch geöffnet hat, nicht genehmigen. Das muss ein Teammitglied tun.
• Ein Vorschlag kann gemergt werden, sobald er mindestens eine Genehmigung von jemandem anderen als dem Autor hat und das aktuellste Review keines Reviewers Änderungen angefordert lautet. Workspace-Administratoren können ohne Genehmigung mergen.
• Das Mergen in einen geschützten Branch erfordert Administratorberechtigungen oder eine Genehmigung durch einen Administrator.

Architect kann keinen Merge-Vorschlag genehmigen, kommentieren, mergen oder schließen. Diese Schritte werden immer von Menschen ausgeführt. Die vollständigen Review-Regeln finden Sie unter Merge-Vorschläge.

Was beim Merge passiert

Nach einem Merge gibt es keinen separaten Veröffentlichungsschritt. Das Mergen erstellt eine neue Version auf dem Ziel-Branch, und diese Version bedient sofort Live-Traffic entsprechend dem Traffic-Anteil, den das Ziel erhält. Wenn das Ziel main ist und keine Traffic-Aufteilung festgelegt ist, bedeutet das alle Anrufer.

Beim Mergen geschieht außerdem Folgendes:

• Jeder Live-Traffic-Anteil des Quell-Branches wird auf das Ziel verschoben.
• Der Quell-Branch wird standardmäßig archiviert.
• Alle anderen offenen Vorschläge desselben Branches werden geschlossen.
• Das verknüpfte Triage-Ticket wird gelöst, falls es eines gibt.

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.

Die Traffic-Anteile müssen immer insgesamt 100 % ergeben, und das Routing ist pro Gespräch deterministisch. Das Ändern des Anteils eines geschützten Branches, auch durch Abziehen von Traffic von einem geschützten main, erfordert einen Administrator. Siehe Traffic-Bereitstellung.

Proaktive Vorschläge

Der proaktive Weg führt heute über Spotlight und anschließende Übergabe. Spotlight überwacht die Gespräche Ihres Agenten fortlaufend. Es erstellt eine wöchentliche Zusammenfassung mit vorgeschlagenen Untersuchungen, löst Echtzeit-Alerts aus und empfiehlt Konfigurationsänderungen. So machen Sie aus einem Spotlight-Ergebnis einen Vorschlag:

Triage-Tickets funktionieren genauso. Ihr Live-Agent kann während Gesprächen 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.