Voorstellen en validatie
Overzicht
Wanneer ElevenAgents Architect een wijziging voltooit, geeft het die aan je door als een voorstel: een branch met de wijziging, tests die aantonen dat deze werkt, en een mergevoorstel met het verzoek om die branch samen te voegen met main. Op deze pagina lees je hoe elk onderdeel werkt, waar je het vindt en hoe een voorstel van een gesprek naar live traffic gaat.
Wat een voorstel is
Een voorstel is gebaseerd op het bestaande model voor versiebeheer:
Het mergevoorstel is een standaardmergevoorstel van ElevenAgents, hetzelfde type dat een teamgenoot handmatig opent. Het is geen afzonderlijk objecttype.
Een mergevoorstel omvat precies één bronbranch en één doelbranch, dus één voorstel bevat één mogelijke oplossing. Vraag Architect om elk alternatief op een eigen branch te plaatsen als je alternatieven wilt vergelijken. Elke branch krijgt dan een eigen voorstel en je kunt traffic tussen de branches verdelen als experiment.
Architect handelt namens jou, dus een mergevoorstel dat het opent, wordt onder jouw naam als auteur geregistreerd. Geen enkel veld geeft aan dat Architect het heeft gemaakt. Vermeld het in de beschrijving van het voorstel als je team dat wil weten.
Hoe een voorstel wordt gemaakt
Architect maakt een voorstel wanneer je het vraagt iets te herstellen of te verbeteren, of wanneer je het een falende test, een Spotlight-bevinding of een triageticket geeft. De volledige reeks, met de tools die Architect bij elke stap aanroept, staat in het uitgewerkte voorbeeld. Kort samengevat:
- Architect onderzoekt het probleem, maakt een branch en bereidt de wijziging voor in je concept op die branch.
- Architect schrijft tests en simulaties voor de wijziging en voert deze uit in het gesprek voordat het je het resultaat laat zien.
- Architect opent het publicatievenster. Je controleert de diff en selecteert Publiceren, waarmee de wijziging wordt vastgelegd als een nieuwe versie op de branch.
- Architect opent een mergevoorstel naar
mainen schrijft de beschrijving op basis van de daadwerkelijke commits en testruns van de branch. - Architect biedt aan om tijdens de beoordeling van het voorstel een klein deel van live traffic naar de branch te sturen. Hiervoor is je goedkeuring nodig.
Je kunt bij elke stap stoppen. Een branch met een gepubliceerde versie maar zonder mergevoorstel is nog steeds nuttig: je kunt deze zelf testen of later een voorstel openen.
Validatie in het gesprek
Architect schrijft en voert tests uit als onderdeel van het maken van de wijziging, niet als afzonderlijke stap die je daarna start. Voor een oplossing is het een nuttig patroon om te laten zien dat de nieuwe tests zonder de wijziging falen en ermee slagen. Architect kan dezelfde tests uitvoeren op de oorspronkelijke branch en op het concept dat de wijziging bevat.
Architect voert deze voor-en-na-controle niet automatisch uit bij elke wijziging. Vraag erom wanneer het belangrijk is, bijvoorbeeld: “Laat me zien dat de nieuwe simulatie faalt op main en slaagt op de branch, en open daarna een voorstel.”
Een test slaagt wanneer aan alle succesvoorwaarden is voldaan. Bij een LLM-test voldoet het antwoord van de agent aan de succescriteria. Bij een tool-calltest wordt de verwachte tool aangeroepen met de verwachte parameters. Bij een simulatie voldoet het gesimuleerde gesprek aan de succesvoorwaarden. Vraag Architect om tests meerdere keren uit te voeren om te controleren op wisselende resultaten. Het kan elke test maximaal 50 keer herhalen en het slagingspercentage rapporteren.
Zie Testen voor de definitie van elk testtype.
Waar je voorstellen vindt
Open de agent en ga vervolgens naar Versiebeheer > Voorstellen. Je kunt de lijst filteren op status, auteur (Gemaakt door) en reviewer (Wacht op beoordeling van, Beoordeeld door). Een voorstel dat Architect in je gesprek heeft geopend, staat met jou als auteur in de lijst.
Architect stuurt ook een link naar het voorstel in het gesprek zodra het dit maakt.
Anatomie van een voorstel
De pagina van een voorstel toont de bron- en doelbranch, de status, of het kan worden samengevoegd en hoe ver de bronbranch achter of voorloopt op de doelbranch. Deze bevat de volgende tabbladen:
Overzicht
Wijzigingen
Testruns
Gesprekken
De beschrijving, een activiteitentijdlijn met commits op de bronbranch, beoordelingen en opmerkingen, en een opmerkingenveld. De zijbalk toont reviewers, aanbevolen reviewers en eventuele gekoppelde triagetickets.
Een beschrijving die Architect schrijft, heeft altijd drie secties: Samenvatting (elke betekenisvolle wijziging en waarom), Testen (welke tests zijn uitgevoerd en de resultaten daarvan, of de vermelding dat er geen zijn uitgevoerd) en Hoe te beoordelen (waar je op moet letten en een uit te voeren test of te proberen gesprek).
Beoordelen en samenvoegen
Statussen
Een mergevoorstel heeft een van deze statussen:
Zolang een voorstel open is, is de meest recente beoordeling van elke reviewer Goedgekeurd of Wijzigingen aangevraagd. Er zijn geen afzonderlijke statussen voor “getest” of “klaar voor beoordeling”. Testresultaten staan in plaats daarvan op het tabblad Testruns.
Beoordelingen en opmerkingen verschijnen in de activiteitentijdlijn op het tabblad Overzicht, naast elke nieuwe versie die is vastgelegd op de bronbranch.
Wie kan goedkeuren en samenvoegen
- Iedereen met editorrechten voor de agent kan een voorstel beoordelen, behalve de auteur. Omdat Architect namens jou handelt, kun je een voorstel dat Architect in jouw gesprek heeft geopend niet goedkeuren. Dat moet een teamgenoot doen.
- Een voorstel kan worden samengevoegd zodra het ten minste één goedkeuring heeft van iemand anders dan de auteur en de meest recente beoordeling van geen enkele reviewer Wijzigingen aangevraagd is. Workspacebeheerders kunnen zonder goedkeuring samenvoegen.
- Samenvoegen met een beschermde branch vereist beheerdersrechten of goedkeuring van een beheerder.
Architect kan een mergevoorstel niet goedkeuren, erop reageren, samenvoegen of sluiten. Die stappen worden altijd door mensen uitgevoerd. Zie Mergevoorstellen voor de volledige beoordelingsregels.
Architect kan een branch rechtstreeks samenvoegen, zonder voorstel, wanneer je dat vraagt en je rol de
merge toestaat. In de modus Goedkeuring vereist vraagt het dit eerst. In de modus Automatisch goedkeuren doet het dat niet. Gebruik
branchbescherming op main als elke wijziging via een beoordeeld voorstel moet gaan.
Wat er gebeurt bij een merge
Na een merge is er geen afzonderlijke publicatiestap. Door samenvoegen wordt een nieuwe versie op de doelbranch vastgelegd, en die versie verwerkt meteen live traffic voor het deel van de traffic dat het doel ontvangt. Als het doel main is en er geen trafficverdeling is ingesteld, betekent dat alle bellers.
Samenvoegen doet ook het volgende:
- Verplaatst elk deel van live traffic dat de bronbranch had naar het doel.
- Archiveert de bronbranch standaard.
- Sluit alle andere open voorstellen van dezelfde branch.
- Lost het gekoppelde triageticket op, als dat er is.
Gefaseerde uitrol
Voordat een voorstel wordt samengevoegd, kun je een deel van live traffic naar de bijbehorende branch sturen, zodat echte bellers de wijziging gebruiken.
Start de verdeling
Vraag Architect bijvoorbeeld: “Stuur 5% van de traffic naar deze branch.” Architect toont je de volledige
resulterende verdeling, inclusief het aandeel van main, en vraagt om goedkeuring voordat deze wordt toegepast. Je kunt
dit ook zelf instellen: selecteer in Versiebeheer > Branches de optie Deployen op de branch.
Traffic-aandelen moeten altijd samen 100% zijn en routing is deterministisch per gesprek. Het wijzigen van het aandeel van een beschermde branch, waaronder het weghalen van traffic bij een beschermde main, vereist een beheerder. Zie Trafficdeployment.
Proactieve voorstellen
Architect maakt voorstellen wanneer je erom vraagt, of wanneer je het een falende test, een Spotlight- bevinding, een waarschuwing of een triageticket geeft. Het scant je agents nog niet volgens een schema en opent niet zelfstandig voorstellen.
De proactieve route is nu Spotlight, gevolgd door overdracht. Spotlight volgt de gesprekken van je agent continu. Het maakt een wekelijkse samenvatting met voorgestelde onderzoeken, geeft realtime waarschuwingen en beveelt configuratiewijzigingen aan. Zo maak je van een Spotlight-bevinding een voorstel:
Kies een bevinding
Open de wekelijkse samenvatting en bekijk Voorgestelde volgende stappen, of open een realtime waarschuwing.
Draag het over aan ElevenAgents Architect
Selecteer Openen in Architect bij een suggestie, Analyseren met Architect bij de samenvatting of Onderzoeken met Architect bij een waarschuwing. Architect ontvangt de bevinding en krijgt de instructie om deze te verifiëren aan de hand van echte gesprekken en vast te stellen welke branch wordt beïnvloed, voordat het een wijziging voorstelt.
Triagetickets werken op dezelfde manier. Je live agent kan tijdens gesprekken problemen markeren voor beoordeling, en Bespreken met Architect op een ticket start een onderzoek ernaar.
Geplande automatiseringen, met rapporten die worden geleverd aan een Architect-inbox, zijn in ontwikkeling. Het tabblad Inbox op de Architect-pagina is hiervoor een tijdelijke aanduiding.