Förslag och validering

Översikt

När ElevenAgents Architect slutför en ändring lämnar den över den till dig som ett förslag: en gren som innehåller ändringen, tester som visar att den fungerar och ett sammanslagningsförslag där grenen föreslås slås samman med main. Den här sidan förklarar hur varje del fungerar, var du hittar den och hur ett förslag går från en konversation till live-trafik.

Vad ett förslag är

Ett förslag bygger på den befintliga modellen för versionshantering:

Sammanslagningsförslaget är ett vanligt ElevenAgents-sammanslagningsförslag, av samma typ som en teammedlem öppnar manuellt. Det är inte en separat objekttyp.

Ett sammanslagningsförslag omfattar exakt en källgren och en målgren, så varje förslag innehåller en kandidatlösning. Om du vill jämföra alternativ ber du Architect att lägga varje alternativ på en egen gren. Varje gren får då ett eget förslag, och du kan dela trafiken mellan dem som ett experiment.

Så skapas ett förslag

Architect skapar ett förslag när du ber den att rätta eller förbättra något, eller när du ger den ett misslyckat test, ett resultat från Spotlight eller ett triageärende. Hela processen, med verktygen Architect anropar i varje steg, finns i det genomgångna exemplet. Kort sagt:

1. Architect undersöker, skapar en gren och förbereder ändringen i ditt utkast på den grenen.
2. Architect skriver tester och simuleringar för ändringen och kör dem i konversationen innan resultatet visas för dig.
3. Architect öppnar publiceringsdialogrutan. Du granskar diffen och väljer Publicera, vilket sparar ändringen som en ny version på grenen.
4. Architect öppnar ett sammanslagningsförslag till main och skriver beskrivningen utifrån grenens faktiska commits och testkörningar.
5. Architect erbjuder sig att skicka en liten andel av live-trafiken till grenen medan förslaget granskas. Detta kräver ditt godkännande.

Du kan avbryta vid vilket steg som helst. En gren med en publicerad version men utan sammanslagningsförslag är fortfarande användbar: du kan testa den själv eller öppna ett förslag senare.

Validering i konversationen

Architect skriver och kör tester som en del av att bygga ändringen, inte som ett separat steg som du startar i efterhand. För en rättning är ett användbart mönster att visa att de nya testerna misslyckas utan ändringen och lyckas med den. Architect kan köra samma tester mot originalgrenen och mot utkastet som innehåller ändringen.

Architect kör inte automatiskt den här före- och efterkontrollen för varje ändring. Be om den när det är viktigt, till exempel: “Visa att den nya simuleringen misslyckas på main och lyckas på grenen, och öppna sedan ett förslag.”

Ett test godkänns när alla villkor för att lyckas är uppfyllda. För ett LLM-test uppfyller agentens svar kriterierna för godkänt. För ett verktygsanropstest anropas det förväntade verktyget med de förväntade parametrarna. För en simulering uppfyller den simulerade konversationen sina villkor för godkänt. För att kontrollera opålitliga resultat kan du be Architect att köra tester flera gånger. Den kan upprepa varje test upp till 50 gånger och rapportera godkännandefrekvensen.

Se Tester för hur varje testtyp definieras.

Var du hittar förslag

Öppna agenten och gå sedan till Versionshantering > Förslag. Listan kan filtreras efter status, författare (Skapad av) och granskare (Väntar på granskning från, Granskad av). Ett förslag som Architect öppnade i din konversation visas med dig som författare.

Architect returnerar också en länk till förslaget i konversationen så snart den har skapat det.

Ett förslags delar

Ett förslags sida visar käll- och målgrenarna, dess status, om det kan slås samman och hur långt källgrenen ligger efter eller före målet. Den har följande flikar:

Granskning och sammanslagning

Statusar

Ett sammanslagningsförslag har någon av följande statusar:

Medan ett förslag är öppet är varje granskares senaste granskning antingen Godkänd eller Ändringar begärda. Det finns inga separata statusar för “testad” eller “redo för granskning”. Testresultat visas i stället på fliken Testkörningar.

Granskningar och kommentarer visas på aktivitetstidslinjen på fliken Översikt, tillsammans med varje ny version som sparas på källgrenen.

Vem kan godkänna och slå samman

• Alla med redigeringsåtkomst till agenten kan granska ett förslag, utom dess författare. Eftersom Architect agerar som du kan du inte godkänna ett förslag som Architect öppnade i din konversation. Det måste en teammedlem göra.
• Ett förslag kan slås samman när det har minst ett godkännande från någon annan än författaren och ingen granskares senaste granskning är Ändringar begärda. Workspace-administratörer kan slå samman utan ett godkännande.
• Sammanslagning med en skyddad gren kräver administratörsbehörighet eller ett godkännande från en administratör.

Architect kan inte godkänna, kommentera, slå samman eller stänga ett sammanslagningsförslag. Dessa steg utförs alltid av människor. Se Sammanslagningsförslag för de fullständiga granskningsreglerna.

Vad som händer vid sammanslagning

Det finns inget separat publiceringssteg efter en sammanslagning. Sammanslagning skapar en ny version på målgrenen, och den versionen hanterar live-trafik direkt för den trafikandel som målet tar emot. När målet är main och ingen trafikdelning har angetts innebär det alla uppringare.

Sammanslagning:

• Flyttar den live-trafikandel som källgrenen hade till målet.
• Arkiverar källgrenen som standard.
• Stänger alla andra öppna förslag från samma gren.
• Löser det länkade triageärendet, om det finns något.

Gradvis utrullning

Innan ett förslag har slagits samman kan du skicka en andel av live-trafiken till dess gren så att verkliga uppringare använder ändringen.

Trafikandelar måste alltid bli 100 % totalt, och routningen är deterministisk per konversation. Att ändra andelen för en skyddad gren, inklusive att ta trafik från en skyddad main, kräver en administratör. Se Trafikdistribution.

Proaktiva förslag

Den proaktiva processen i dag är Spotlight följt av en överlämning. Spotlight övervakar kontinuerligt din agents konversationer. Den ger en veckosammanfattning med föreslagna undersökningar, skapar realtidsaviseringar och rekommenderar konfigurationsändringar. Så här gör du ett resultat från Spotlight till ett förslag:

Triageärenden fungerar på samma sätt. Din aktiva agent kan markera problem för granskning under konversationer, och Diskutera med Architect i ett ärende startar en undersökning av det.

Schemalagda automatiseringar, med rapporter som levereras till en Architect-inkorg, är under utveckling. Fliken Inkorg på Architect-sidan är en platshållare för dem.