Propozycje i walidacja
Jak zmiany ElevenAgents Architect są testowane, sprawdzane i wdrażane w ruchu na żywo.
Omówienie
Gdy ElevenAgents Architect kończy zmianę, przekazuje ci ją jako propozycję: gałąź zawierającą zmianę, testy potwierdzające, że działa, oraz propozycję scalenia z prośbą o scalenie tej gałęzi z main. Ta strona wyjaśnia, jak działa każda część, gdzie ją znaleźć i jak propozycja przechodzi od rozmowy do ruchu produkcyjnego.
Czym jest propozycja
Propozycja bazuje na istniejącym modelu wersjonowania:
Propozycja scalenia to standardowa propozycja scalenia ElevenAgents — taki sam typ, jaki członek zespołu otwiera ręcznie. Nie jest to osobny typ obiektu.
Propozycja scalenia obejmuje dokładnie jedną gałąź źródłową i jedną docelową, więc jedna propozycja zawiera jedno potencjalne rozwiązanie. Aby porównać alternatywy, poproś Architecta o umieszczenie każdej na osobnej gałęzi. Każda gałąź otrzyma wtedy własną propozycję, a ruch możesz podzielić między nimi jako eksperyment.
Architect działa w twoim imieniu, więc otwarta przez niego propozycja scalenia jest zapisana na twoje nazwisko jako autora. Nie ma pola wskazującego, że utworzył ją Architect. Wspomnij o tym w opisie propozycji, jeśli zespół chce o tym wiedzieć.
Jak powstaje propozycja
Architect tworzy propozycję, gdy prosisz go o naprawę lub ulepszenie czegoś albo przekazujesz mu nieudany test, ustalenie Spotlight lub zgłoszenie. Pełną sekwencję wraz z narzędziami wywoływanymi przez Architecta na każdym etapie znajdziesz w przykładzie krok po kroku. W skrócie:
- Architect analizuje problem, tworzy gałąź i przygotowuje zmianę w twojej wersji roboczej na tej gałęzi.
- Architect pisze testy i symulacje dla zmiany oraz uruchamia je w rozmowie, zanim pokaże ci wynik.
- Architect otwiera okno publikacji. Sprawdzasz różnice i wybierasz Opublikuj, co zapisuje zmianę jako nową wersję na gałęzi.
- Architect otwiera propozycję scalenia do
main, tworząc jej opis na podstawie faktycznych commitów i uruchomień testów z gałęzi. - Architect proponuje wysłanie niewielkiej części ruchu produkcyjnego do gałęzi, gdy propozycja jest sprawdzana. Wymaga to twojej zgody.
Możesz zatrzymać się na dowolnym etapie. Gałąź z opublikowaną wersją, ale bez propozycji scalenia, nadal jest przydatna: możesz przetestować ją samodzielnie lub otworzyć propozycję później.
Walidacja w rozmowie
Architect pisze i uruchamia testy podczas tworzenia zmiany, a nie jako osobny krok uruchamiany później. Przy poprawce dobrym wzorcem jest pokazanie, że nowe testy nie przechodzą bez zmiany, a przechodzą z nią. Architect może uruchomić te same testy na oryginalnej gałęzi oraz na wersji roboczej zawierającej zmianę.
Architect nie uruchamia automatycznie takiego porównania przed i po dla każdej zmiany. Poproś o nie, gdy ma to znaczenie, na przykład: „Pokaż, że nowa symulacja nie przechodzi na main, a przechodzi na gałęzi, a potem otwórz propozycję”.
Test przechodzi, gdy spełnione są wszystkie warunki sukcesu. W teście LLM odpowiedź agenta spełnia kryteria sukcesu. W teście wywołania narzędzia oczekiwane narzędzie jest wywoływane z oczekiwanymi parametrami. W symulacji symulowana rozmowa spełnia warunki sukcesu. Aby sprawdzić niestabilne wyniki, poproś Architecta o kilkukrotne uruchomienie testów. Może powtórzyć każdy test do 50 razy i podać wskaźnik powodzenia.
Zobacz Testowanie, aby dowiedzieć się, jak definiowany jest każdy typ testu.
Gdzie znaleźć propozycje
Otwórz agenta, a następnie przejdź do Kontrola wersji > Propozycje. Listę można filtrować według statusu, autora (Utworzone przez) i recenzenta (Oczekuje na recenzję od, Zrecenzowane przez). Propozycja otwarta przez Architecta w twojej rozmowie będzie widoczna z tobą jako autorem.
Architect zwraca też link do propozycji w rozmowie zaraz po jej utworzeniu.
Elementy propozycji
Strona propozycji pokazuje gałęzie źródłową i docelową, jej status, możliwość scalenia oraz to, jak bardzo gałąź źródłowa jest opóźniona lub wyprzedza docelową. Zawiera te karty:
Omówienie
Zmiany
Uruchomienia testów
Rozmowy
Opis, oś aktywności z commitami na gałęzi źródłowej, recenzjami i komentarzami oraz pole komentarza. Pasek boczny pokazuje recenzentów, polecanych recenzentów i powiązane zgłoszenie.
Opis tworzony przez Architecta zawsze zawiera trzy sekcje: Podsumowanie (każda istotna zmiana i jej powód), Testowanie (uruchomione testy i ich wyniki albo informacja, że nie uruchomiono żadnych) oraz Jak zrecenzować (na czym się skupić oraz test do uruchomienia lub rozmowa do wypróbowania).
Recenzowanie i scalanie
Statusy
Propozycja scalenia ma jeden z tych statusów:
Gdy propozycja jest otwarta, najnowsza recenzja każdego recenzenta ma status Zatwierdzono albo Poproszono o zmiany. Nie ma osobnych statusów „przetestowano” ani „gotowe do recenzji”. Wyniki testów są widoczne na karcie Uruchomienia testów.
Recenzje i komentarze pojawiają się na osi aktywności na karcie Omówienie, obok każdej nowej wersji zapisanej na gałęzi źródłowej.
Kto może zatwierdzać i scalać
- Każdy z dostępem edytora do agenta może zrecenzować propozycję, z wyjątkiem jej autora. Ponieważ Architect działa w twoim imieniu, nie możesz zatwierdzić propozycji otwartej przez niego w twojej rozmowie. Musi to zrobić członek zespołu.
- Propozycję można scalić, gdy ma co najmniej jedno zatwierdzenie od osoby innej niż autor, a najnowsza recenzja żadnego recenzenta nie ma statusu Poproszono o zmiany. Administratorzy workspace mogą scalać bez zatwierdzenia.
- Scalenie z chronioną gałęzią wymaga uprawnień administratora lub zatwierdzenia przez administratora.
Architect nie może zatwierdzać, komentować, scalać ani zamykać propozycji scalenia. Te kroki zawsze wykonują ludzie. Pełne zasady recenzji znajdziesz w Propozycjach scalenia.
Architect może scalić gałąź bezpośrednio, bez propozycji, gdy go o to poprosisz i twoja rola pozwala
na scalenie. W trybie Wymagane zatwierdzenie najpierw pyta o zgodę. W trybie Automatyczne zatwierdzanie nie pyta. Użyj
ochrony gałęzi na main, jeśli każda zmiana ma przechodzić przez zrecenzowaną propozycję.
Co dzieje się po scaleniu
Po scaleniu nie ma osobnego kroku publikacji. Scalenie zapisuje nową wersję na gałęzi docelowej, a ta wersja od razu obsługuje ruch produkcyjny w zakresie udziału ruchu przypisanego do gałęzi docelowej. Gdy celem jest main i nie ustawiono podziału ruchu, oznacza to wszystkich rozmówców.
Scalenie także:
- Przenosi na gałąź docelową cały udział ruchu produkcyjnego gałęzi źródłowej.
- Domyślnie archiwizuje gałąź źródłową.
- Zamyka wszystkie inne otwarte propozycje z tej samej gałęzi.
- Rozwiązuje powiązane zgłoszenie, jeśli istnieje.
Stopniowe wdrożenie
Zanim propozycja zostanie scalona, możesz wysłać część ruchu produkcyjnego do jej gałęzi, aby prawdziwi rozmówcy sprawdzili zmianę.
Rozpocznij podział
Poproś Architecta, na przykład: „Wyślij 5% ruchu do tej gałęzi”. Architect poda pełny
wynikowy podział, w tym udział main, i poprosi o zgodę przed jego zastosowaniem. Możesz też
ustawić go samodzielnie: w Kontrola wersji > Gałęzie wybierz Wdróż na gałęzi.
Udziały ruchu muszą zawsze sumować się do 100%, a routing jest deterministyczny dla każdej rozmowy. Zmiana udziału chronionej gałęzi, w tym odebranie ruchu chronionej gałęzi main, wymaga administratora. Zobacz Wdrażanie ruchu.
Proaktywne propozycje
Architect tworzy propozycje, gdy go o to poprosisz albo gdy przekażesz mu nieudany test, ustalenie Spotlight, alert lub zgłoszenie. Nie skanuje jeszcze twoich agentów według harmonogramu ani nie otwiera propozycji samodzielnie.
Obecna ścieżka proaktywna to Spotlight, a następnie przekazanie sprawy. Spotlight stale monitoruje rozmowy twojego agenta. Tworzy cotygodniowe podsumowanie z proponowanymi analizami, zgłasza alerty w czasie rzeczywistym i rekomenduje zmiany konfiguracji. Aby zamienić ustalenie Spotlight w propozycję:
Wybierz ustalenie
Otwórz cotygodniowe podsumowanie i sprawdź Sugerowane kolejne kroki albo otwórz alert w czasie rzeczywistym.
Przekaż sprawę ElevenAgents Architect
Wybierz Otwórz w Architect przy sugestii, Analizuj z Architect w podsumowaniu lub Zbadaj z Architect przy alercie. Architect otrzyma ustalenie i instrukcję, aby zweryfikować je na podstawie prawdziwych rozmów oraz ustalić, której gałęzi dotyczy, zanim zaproponuje zmianę.
Zgłoszenia działają tak samo. Twój agent produkcyjny może oznaczać zgłoszenia do sprawdzenia podczas rozmów, a Omów z Architect przy zgłoszeniu rozpoczyna jego analizę.
Zaplanowane automatyzacje, z raportami dostarczanymi do skrzynki Architecta, są w trakcie tworzenia. Karta Skrzynka odbiorcza na stronie Architecta jest na razie miejscem na nie.