Hoppa till navigering

Så fungerar ElevenAgents Architect

Vad ElevenAgents Architect vet när en konversation börjar, hur den undersöker och hur den omvandlar en fråga till en validerad ändring.

Översikt

En konversation med ElevenAgents Architect körs som en ElevenAgents-konversation i realtid, på samma motor som driver agenterna du bygger. Architects verktyg körs i din webbläsare under din inloggade session. Varje verktyg anropar samma ElevenAgents-API:er som instrumentpanelen använder, så varje läs- och skrivåtgärd kontrolleras mot dina egna behörigheter. Se Behörigheter, godkännanden och utkast.

Vad ElevenAgents Architect känner till som standard

I början av varje konversation får Architect:

  • Ditt konto och din arbetsyta: din plan, arbetsyta och användning.
  • Var du är: sidan och, när du är inne i en agent, den agenten och den gren du har öppen. I sidofältet får Architect även en ögonblicksbild av sidan samt en uppdatering före varje meddelande om sidan har ändrats.
  • En agentsammanfattning: skapad av ElevenLabs när du är inne i en agent. Den omfattar agentens namn och ägare, dess grenar och deras trafikfördelning, samtalsvolym de senaste 7 dagarna, utkaststatus, anslutna agenter, procedurer, om tester är konfigurerade och vilka grenar du kan redigera.
  • Agentkontext: agentens agents.md-dokument, som delas med alla som bygger agenten. Se Anpassa Architect.
  • Dina inställningar: ditt personliga user.md-dokument, som gäller för varje agent du bygger.
  • Vad startpunkten skickade med: till exempel misslyckade tester, en Spotlight-insikt eller ett triageärende. Se Starta en konversation.
  • Tidigare meddelanden i den här chatten.

Architect startar inte med agentens fullständiga konfiguration, dess transkript, testresultat, Spotlight-data eller dina andra Architect-chattar. Den läser in detta med verktyg när uppgiften kräver det. Det håller varje konversation fokuserad och innebär att Architect alltid arbetar med aktuell data i stället för en inaktuell kopia.

Undersökningar och direkta instruktioner

Architect hanterar två typer av förfrågningar olika.

Direkta instruktioner anger ändringen, till exempel ”Lägg till en skyddsräcke som blockerar diskussion om konkurrenters prissättning” eller ”Gör det första meddelandet kortare.” Architect läser relevant konfiguration, gör ändringen och rapporterar vad den har lagt i staging. I standardläget för godkännanden läggs ändringar av agentkonfigurationen i staging i ett utkast utan att fråga. Åtgärder som påverkar live-trafik eller delade resurser väntar på ditt godkännande.

Undersökningar ställer en fråga utan att ange en lösning, till exempel ”Varför eskaleras återbetalningssamtal?” eller ”Hur förbättrar jag återbetalningslösningar?” Architect undersöker innan något ändras:

  • Den skriver en att göra-lista för undersökningen, som förblir synlig ovanför skrivfältet när uppgifter slutförs.
  • Den börjar med billiga signaler, som antal konversationer, ämnen och utvärderingsresultat, innan den läser enskilda transkript.
  • Den analyserar konversationer parallellt och grupperar det den hittar efter grundorsak.
  • Dess resonemang är synligt. Varje resonemangssteg fälls ihop till Tanke i Ns och kan expanderas.
  • Den rapporterar vad den hittade, inklusive hur många konversationer den faktiskt läste. Den framställer inte ett urval som fullständigt.

Planläge

För större ändringar växlar du skrivfältet till Plan (tryck på Shift+Tab för att växla mellan lägen). I planläget undersöker Architect med skrivskyddade verktyg, skriver en plan som du kan se den utforma och ber dig sedan att Godkänn plan eller Avvisa. Den gör inga ändringar förrän du godkänner. Om du avvisar planen med en kommentar reviderar Architect den och frågar igen.

På Architect-fliken i helskärm visas planen i en panel ovanför skrivfältet. I sidofältet visas den som ett kort i chatten.

Exempel: förbättra återbetalningslösningar

Det här exemplet följer en enda konversation från en bred fråga till en ändring som är redo för granskning. Verktygsnamn visas så att du kan koppla varje steg till det som visas i konversationen. Architect väljer sina egna steg, så en verklig konversation kan skilja sig åt i ordning och detaljnivå.

Förfrågan, skickad från agentens Architect-flik:

Hur förbättrar jag återbetalningslösningar?

1

Planera undersökningen

Architect skriver en att göra-lista (write_todos): mät problemet, hitta misslyckade återbetalningskonversationer, identifiera grundorsaker och föreslå samt testa en lösning.

2

Mät problemet

Architect läser agentens ämnen (get_agent_topics, get_topics_summary) för att hitta återbetalnings- ämnet och dess lösningsgrad, räknar sedan och listar nyliga återbetalningskonversationer som misslyckades i utvärderingen (count_conversations, list_conversations).

3

Läs konversationerna

Architect söker i transkript efter återbetalningsförfrågningar (search_conversation_messages, semantic_search_conversations) och analyserar sedan ett urval av misslyckade konversationer parallellt (analyze_conversation_subagent). Varje analys rapporterar vad användaren ville, var agenten gjorde fel och vid vilken tur det hände.

4

Hitta grundorsaken

Architect jämför misslyckandena med den aktuella konfigurationen (get_agent_config, list_procedures, get_procedure). Den rapporterar till exempel följande: ”I 31 av 40 misslyckade återbetalningssamtal anropade agenten lookup_order innan den frågade efter ordernumret, fick ett fel och eskalerade.”

5

Gör ändringen i en gren

Architect skapar en gren (create_branch) så att ändringen isoleras från live-agenten. Den redigerar sedan återbetalningsproceduren (update_procedure) för att fråga efter ordernumret före uppslaget. Ändringen läggs i staging i ditt utkast på den grenen. Inget har ändrats för live-uppringare.

6

Skriv tester för ändringen

Architect skriver tester som fångar felet: en simulering av en uppringare som ber om återbetalning utan att ange ett ordernummer (create_simulation_test), ett verktygsanropstest som kontrollerar att lookup_order inte anropas först (create_tool_test) och ett test som genereras från en av de verkliga misslyckade konversationerna (generate_test_from_conversation). Architect simulerar verktyg som har sidoeffekter i simuleringar, så inga verkliga återbetalningar utfärdas.

7

Kör testerna före och efter

Architect kör testerna mot agenten utan ändringen (run_tests på den ursprungliga grenen, eller run_agent_tests med include_draft: false), sedan mot utkastet med ändringen (run_agent_tests), och läser resultaten (get_test_suite_summary, get_test_suite_failures). Det förväntade resultatet är att de nya testerna misslyckas utan ändringen och godkänns med den. Om tester fortfarande misslyckas läser Architect felen, justerar ändringen och kör dem igen.

8

Presentera ändringen

Architect sammanfattar grundorsaken, ändringen och testresultaten och öppnar publicerings- dialogrutan (request_draft_publish). Du granskar diffen och väljer Publicera, vilket genomför ändringen som en ny version i grenen. Architect kan inte publicera åt dig.

9

Öppna ett förslag

Architect läser grenens historik och sammanslagningsförhandsvisning (get_branch_history, merge_branch_preview) och öppnar ett sammanslagningsförslag till main (create_merge_proposal). Beskrivningen har tre avsnitt, Sammanfattning, Testning och Så granskar du, skrivna utifrån de faktiska ändringarna och testkörningarna. Architect kan föreslå granskare (suggest_merge_proposal_reviewers), men du väljer dem.

10

Erbjud en gradvis utrullning

Architect erbjuder att skicka en liten andel av live-trafiken, vanligtvis 5 %, till grenen medan förslaget granskas (set_traffic_split). Detta ändrar live-trafiken, så det väntar på ditt godkännande.

Validering sker i konversationen innan du ombeds att publicera eller granska något. När förslaget når en granskare är testerna som motiverade ändringen redan kopplade till agenten och har körts på grenen. Se Förslag och validering för vad granskaren ser.

Testkörningen före och efter är en bra praxis, men Architect kör den inte automatiskt vid varje ändring. För att säkerställa att den gör det ber du om det direkt, till exempel ”Visa mig de nya testerna som misslyckas på main och godkänns i grenen.”

Architects arbetsspår

Arbetsspåret för en förfrågan, med varje verktygsanrop Architect gjorde

Snedstreckskommandon

Skriv / i skrivfältet för att se de kommandon som är tillgängliga på den aktuella sidan.

KommandoVad det gör
/startKonfigurera agentens kontext (agents.md) så att Architect känner till dina mål.
/generateGenerera en ny agent från en beskrivning.
/debugFelsök nyliga misslyckade konversationer.
/testKör tester och sammanfatta resultaten.
/explainFörklara vad den här agenten gör på enkel svenska.
/optimizeFöreslå förbättringar av prompt och konfiguration.
/reviewGranska agentens prestanda och hitta förbättringar.
/branchSkapa en ny gren för den här agenten.
/experimentSkapa en gren och driftsätt den som ett A/B-test.
/rollbackGranska nyliga konfigurationsändringar och ångra dem vid behov.
/rememberSpara ett faktum för agenten som ett kunskapsbasdokument.
/dashboardBygg en anpassad analysinstrumentpanel i chatten.
/clearRensa den här konversationen och börja om.
/feedbackSkicka privat feedback om den här sessionen till ElevenLabs.

De flesta kommandon gäller bara när du är inne i en agent. /clear och /feedback är inte tillgängliga på Architect-flikens startsida.

Instrumentpaneler i chatten

Architect kan bygga en instrumentpanel i konversationen för att besvara en fråga med data, till exempel ”Dela upp den här veckans eskaleringar efter orsak och visa trenden.” Använd /dashboard eller be om en direkt.

Architect samlar in data med sina verktyg, formar den med kod och renderar en instrumentpanel med samma metrikkort, diagram, listor och textkort som Spotlight. En instrumentpanel kan innehålla:

  • Metrikkort med ett rubrikvärde, förändring och minidiagram.
  • Diagram: yta, linje, stapel, staplad yta, ringdiagram och rankade stapellistor för topp-N-uppdelningar.
  • Listor med statusetiketter, datum och länkar till sidor i ElevenAgents, till exempel enskilda konversationer.
  • Textkort för insikter och rekommendationer.

På Architect-fliken i helskärm renderas instrumentpaneler direkt i konversationen. I sidofältet öppnas de i en panel bredvid chatten.

Instrumentpanelsdata sparas bara i minnet i den webbläsarflik där den byggdes och sparas aldrig med chatten. När du laddar om sidan, öppnar chatten i en annan flik eller bygger flera stora instrumentpaneler visar en äldre instrumentpanel ett meddelande i stället för sin data. Be Architect att bygga om den. Instrumentpaneler är skrivskyddade ögonblicksbilder. De har inga filter och uppdateras inte live.

Köra kod

Architect kan köra korta Python-program för att räkna, gruppera och jämföra data från sina verktyg, till exempel för att beräkna lösningsgrader per vecka över några hundra konversationer. Koden körs i en sandbox-miljö i din webbläsare med endast Pythons standardbibliotek. Den har ingen nätverksåtkomst, ingen åtkomst till ditt ElevenLabs-konto och en tidsgräns på 20 sekunder. Kodkörning rullas ut gradvis och kanske inte är tillgänglig i alla arbetsytor.

Stora svar

När ett verktyg returnerar mer data än vad som ryms i konversationen, till exempel en lång lista med konversationer, behåller Architect hela svaret i minnet i din webbläsarflik och arbetar med en sammanfattning. Den kan söka i och läsa resten vid behov. Ett meddelande i verktygsanropet visar när detta har hänt. Dessa svar sparas eller laddas aldrig upp.