So funktioniert ElevenAgents Architect
Was ElevenAgents Architect beim Start einer Unterhaltung weiß, wie es untersucht und wie es eine Frage in eine validierte Änderung umwandelt.
Überblick
Eine Unterhaltung mit ElevenAgents Architect läuft als Echtzeit-Unterhaltung mit ElevenAgents – auf derselben Engine, die auch Ihre erstellten Agents betreibt. Die Tools von Architect laufen in Ihrem Browser innerhalb Ihrer angemeldeten Sitzung. Jedes Tool ruft dieselben ElevenAgents-APIs auf wie das Dashboard. Daher wird jeder Lese- und Schreibzugriff anhand Ihrer eigenen Berechtigungen geprüft. Siehe Berechtigungen, Genehmigungen und Entwürfe.
Was ElevenAgents Architect standardmäßig weiß
Zu Beginn jeder Unterhaltung erhält Architect:
- Ihr Konto und Ihren Workspace: Ihren Plan, Workspace und Ihre Nutzung.
- Ihren aktuellen Ort: die Seite und, wenn Sie sich in einem Agent befinden, diesen Agent sowie den geöffneten Branch. In der Seitenleiste erhält Architect außerdem eine Momentaufnahme der Seite und vor jeder Nachricht ein Update, falls sich die Seite geändert hat.
- Eine Agent-Zusammenfassung: Sie wird von ElevenLabs erstellt, wenn Sie sich in einem Agent befinden. Sie umfasst Name und Eigentümer des Agents, seine Branches und deren Traffic-Aufteilung, das Anrufvolumen der letzten 7 Tage, den Entwurfsstatus, verbundene Agents, Verfahren, die Testkonfiguration und die Branches, die Sie bearbeiten können.
- Agent-Kontext: das
agents.md-Dokument des Agents, das alle Personen teilen, die den Agent erstellen. Siehe Architect anpassen. - Ihre Präferenzen: Ihr persönliches
user.md-Dokument, das für jeden von Ihnen erstellten Agent gilt. - Die Informationen des Einstiegspunkts: zum Beispiel fehlgeschlagene Tests, ein Spotlight-Ergebnis oder ein Issue. Siehe Unterhaltung starten.
- Frühere Nachrichten in diesem Chat.
Architect startet nicht mit der vollständigen Konfiguration des Agents, seinen Transkripten, Testergebnissen, Spotlight-Daten oder Ihren anderen Architect-Chats. Bei Bedarf liest es diese über Tools. So bleibt jede Unterhaltung fokussiert, und Architect arbeitet stets mit aktuellen Daten statt mit einer veralteten Kopie.
Untersuchungen und direkte Anweisungen
Architect behandelt zwei Arten von Anfragen unterschiedlich.
Direkte Anweisungen benennen die Änderung, etwa „Fügen Sie eine Guardrail hinzu, die Gespräche über Preise von Wettbewerbern blockiert“ oder „Machen Sie die erste Nachricht kürzer.“ Architect liest die relevante Konfiguration, nimmt die Änderung vor und meldet, was es vorgemerkt hat. Im Standardmodus für Genehmigungen werden Änderungen an der Agent-Konfiguration ohne Rückfrage in einem Entwurf vorgemerkt. Maßnahmen, die Live-Traffic oder gemeinsame Ressourcen betreffen, warten auf Ihre Genehmigung.
Untersuchungen stellen eine Frage, ohne eine Lösung zu benennen, etwa „Warum werden Erstattungsanrufe eskaliert?“ oder „Wie verbessere ich Erstattungsabschlüsse?“ Architect recherchiert, bevor es etwas ändert:
- Es schreibt eine Aufgabenliste für die Untersuchung, die beim Abschluss von Punkten über dem Composer sichtbar bleibt.
- Es beginnt mit kostengünstigen Signalen wie Gesprächszahlen, Themen und Bewertungsergebnissen, bevor es einzelne Transkripte liest.
- Es analysiert Gespräche parallel und gruppiert die Ergebnisse nach Grundursachen.
- Seine Überlegungen sind sichtbar. Jeder Schritt lässt sich zu Gedanke für Ns einklappen und erweitern.
- Es berichtet, was es gefunden hat, einschließlich der Anzahl tatsächlich gelesener Gespräche. Eine Stichprobe wird nicht als vollständig dargestellt.
Planmodus
Wechseln Sie bei größeren Änderungen im Composer zu Plan (drücken Sie Shift+Tab, um durch die Modi zu wechseln). Im Planmodus recherchiert Architect mit schreibgeschützten Tools, erstellt einen Plan, dessen Entwurf Sie verfolgen können, und fordert Sie dann auf, den Plan zu Genehmigen oder Abzulehnen. Es nimmt erst Änderungen vor, nachdem Sie zugestimmt haben. Wenn Sie den Plan mit einer Anmerkung ablehnen, überarbeitet Architect ihn und fragt erneut.
Im Architect-Tab im Vollbild erscheint der Plan in einem Bereich über dem Composer. In der Seitenleiste erscheint er als Karte im Chat.
Praxisbeispiel: Erstattungsabschlüsse verbessern
Dieses Beispiel verfolgt eine einzelne Unterhaltung von einer allgemeinen Frage bis zu einer zur Überprüfung bereiten Änderung. Die Toolnamen werden angezeigt, damit Sie jeden Schritt mit dem vergleichen können, was in der Unterhaltung erscheint. Architect wählt seine Schritte selbst, daher kann sich eine echte Unterhaltung in Reihenfolge und Detail unterscheiden.
Die Anfrage wurde über den Architect-Tab des Agents gesendet:
Wie verbessere ich Erstattungsabschlüsse?
Untersuchung planen
Architect erstellt eine Aufgabenliste (write_todos): Problem messen, fehlgeschlagene
Erstattungsgespräche finden, Grundursachen identifizieren, Lösung vorschlagen und testen.
Problem messen
Architect liest die Themen des Agents (get_agent_topics, get_topics_summary), um das Erstattungs-
Thema und seine Erfolgsrate zu finden, und zählt und listet dann aktuelle Erstattungsgespräche auf,
deren Bewertung fehlgeschlagen ist (count_conversations, list_conversations).
Gespräche lesen
Architect durchsucht Transkripte nach Erstattungsanfragen (search_conversation_messages,
semantic_search_conversations) und analysiert dann parallel eine Gruppe fehlgeschlagener Gespräche
(analyze_conversation_subagent). Jede Analyse berichtet, was der Nutzer wollte, wo der Agent
falsch lag und in welchem Turn dies geschah.
Grundursache finden
Architect vergleicht die Fehler mit der aktuellen Konfiguration (get_agent_config,
list_procedures, get_procedure). Es meldet beispielsweise: „In 31 von 40 fehlgeschlagenen
Erstattungsanrufen rief der Agent lookup_order auf, bevor er nach der Bestellnummer fragte,
erhielt einen Fehler und eskalierte.“
Änderung in einem Branch vornehmen
Architect erstellt einen Branch (create_branch), damit die Änderung vom Live-Agent getrennt ist. Dann
bearbeitet es das Erstattungsverfahren (update_procedure), um vor der Abfrage nach der Bestellnummer
zu fragen. Die Änderung wird in Ihrem Entwurf in diesem Branch vorgemerkt. Für Live-Anrufer hat sich nichts geändert.
Tests für die Änderung schreiben
Architect schreibt Tests, die den Fehler abbilden: eine Simulation eines Anrufers, der eine Erstattung
verlangt, ohne eine Bestellnummer anzugeben (create_simulation_test), einen Tool-Call-Test, der prüft,
dass lookup_order nicht zuerst aufgerufen wird (create_tool_test), sowie einen Test, der aus einem der
tatsächlich fehlgeschlagenen Gespräche generiert wird (generate_test_from_conversation). Architect mockt
Tools mit Nebenwirkungen in Simulationen, damit keine echten Erstattungen ausgelöst werden.
Tests vorher und nachher ausführen
Architect führt die Tests gegen den Agent ohne Änderung aus (run_tests im ursprünglichen
Branch oder run_agent_tests mit include_draft: false), dann gegen den Entwurf mit der
Änderung (run_agent_tests) und liest die Ergebnisse (get_test_suite_summary,
get_test_suite_failures). Das erwartete Ergebnis ist, dass die neuen Tests ohne Änderung fehlschlagen
und damit bestehen. Falls Tests weiterhin fehlschlagen, liest Architect die Fehler, passt die Änderung an
und führt sie erneut aus.
Änderung präsentieren
Architect fasst Grundursache, Änderung und Testergebnisse zusammen und öffnet den
Veröffentlichungsdialog (request_draft_publish). Sie prüfen den Diff und wählen Veröffentlichen,
wodurch die Änderung als neue Version im Branch festgeschrieben wird. Architect kann nicht für Sie veröffentlichen.
Vorschlag öffnen
Architect liest die Historie und Merge-Vorschau des Branches (get_branch_history,
merge_branch_preview) und öffnet einen Merge-Vorschlag in main (create_merge_proposal). Die
Beschreibung enthält drei Abschnitte – Zusammenfassung, Tests und So prüfen Sie – und wird
aus den tatsächlichen Commits und Testläufen erstellt. Architect kann Reviewer vorschlagen
(suggest_merge_proposal_reviewers), aber Sie wählen sie aus.
Die Validierung erfolgt innerhalb der Unterhaltung, bevor Sie gebeten werden, etwas zu veröffentlichen oder zu prüfen. Wenn der Vorschlag einen Reviewer erreicht, sind die Tests, die die Änderung veranlasst haben, bereits am Agent angehängt und im Branch ausgeführt worden. Unter Vorschläge und Validierung erfahren Sie, was der Reviewer sieht.
Der Testlauf vorher und nachher ist empfehlenswert, wird von Architect aber nicht bei jeder Änderung automatisch ausgeführt. Um sicherzustellen, dass dies geschieht, bitten Sie direkt darum, etwa: „Zeigen Sie mir, wie die neuen Tests auf main fehlschlagen und im Branch bestehen.“
Slash-Befehle
Geben Sie im Composer / ein, um die auf der aktuellen Seite verfügbaren Befehle anzuzeigen.
Die meisten Befehle gelten nur, wenn Sie sich in einem Agent befinden. /clear und /feedback sind auf der Startseite des Architect-Tabs nicht verfügbar.
Dashboards im Chat
Architect kann in der Unterhaltung ein Dashboard erstellen, um eine Frage mit Daten zu beantworten, etwa „Schlüsseln Sie die Eskalationen dieser Woche nach Grund auf und zeigen Sie mir den Trend.“ Verwenden Sie /dashboard oder bitten Sie direkt um eines.
Architect sammelt die Daten mit seinen Tools, verarbeitet sie mit Code und rendert ein Dashboard aus denselben Kennzahlen-Kacheln, Diagrammen, Listen und Textkarten wie Spotlight. Ein Dashboard kann Folgendes enthalten:
- Kennzahlen-Kacheln mit einem Hauptwert, einer Veränderung und einem Sparkline-Diagramm.
- Diagramme: Flächen-, Linien-, Balken-, gestapelte Flächen- und Donut-Diagramme sowie sortierte Balkenlisten für Top-N-Aufschlüsselungen.
- Listen mit Statuslabels, Daten und Links zu Seiten in ElevenAgents, etwa zu einzelnen Gesprächen.
- Textkarten für Erkenntnisse und Empfehlungen.
Im Architect-Tab im Vollbild werden Dashboards inline in der Unterhaltung gerendert. In der Seitenleiste öffnen sie sich in einem Bereich neben dem Chat.
Dashboard-Daten werden nur im Speicher des Browser-Tabs aufbewahrt, in dem sie erstellt wurden, und nie mit dem Chat gespeichert. Nach dem Neuladen der Seite, dem Öffnen des Chats in einem anderen Tab oder dem Erstellen mehrerer großer Dashboards zeigt ein älteres Dashboard statt seiner Daten eine Nachricht an. Bitten Sie Architect, es neu zu erstellen. Dashboards sind schreibgeschützte Momentaufnahmen. Sie haben keine Filter und werden nicht live aktualisiert.
Code ausführen
Architect kann kurze Python-Programme ausführen, um Daten aus seinen Tools zu zählen, gruppieren und vergleichen, etwa um Abschlussraten pro Woche über einige Hundert Gespräche hinweg zu berechnen. Der Code läuft in einer Sandbox in Ihrem Browser und kann nur die Python-Standardbibliothek verwenden. Er hat keinen Netzwerkzugriff, keinen Zugriff auf Ihr ElevenLabs-Konto und ein Zeitlimit von 20 Sekunden. Die Codeausführung wird schrittweise eingeführt und ist möglicherweise nicht in jedem Workspace verfügbar.
Große Antworten
Wenn ein Tool mehr Daten zurückgibt, als in die Unterhaltung passen, etwa eine lange Gesprächsliste, behält Architect die vollständige Antwort im Speicher Ihres Browser-Tabs und arbeitet mit einer Zusammenfassung. Bei Bedarf kann es den Rest durchsuchen und lesen. Ein Hinweis im Tool-Aufruf zeigt an, wenn dies geschehen ist. Diese Antworten werden niemals gespeichert oder hochgeladen.