Propozycje i walidacja

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żdy element, gdzie go znaleźć i jak propozycja przechodzi od rozmowy do ruchu produkcyjnego.

Czym jest propozycja

Propozycja opiera się na obecnym modelu wersjonowania:

Propozycja scalenia to standardowa propozycja scalenia ElevenAgents — taki sam typ, jaki członek zespołu otwiera ręcznie. Nie jest osobnym typem obiektu.

Propozycja scalenia obejmuje dokładnie jedną gałąź źródłową i jedną docelową, więc zawiera jedno kandydackie rozwiązanie. Aby porównać alternatywy, poproś Architect, aby umieścił każdą na osobnej gałęzi. Każda gałąź otrzyma wtedy własną propozycję, a ruch możesz między nimi podzielić w ramach eksperymentu.

Jak powstaje propozycja

Architect tworzy propozycję, gdy prosisz go o naprawę lub ulepszenie czegoś albo przekazujesz mu nieudany test, ustalenie Spotlight lub zgłoszenie do triage. Pełną sekwencję wraz z narzędziami wywoływanymi przez Architect na każdym etapie znajdziesz w przykładzie krok po kroku. W skrócie:

1. Architect analizuje problem, tworzy gałąź i przygotowuje zmianę w twoim szkicu na tej gałęzi.
2. Architect pisze testy i symulacje dla zmiany oraz uruchamia je w rozmowie, zanim pokaże ci wynik.
3. Architect otwiera okno publikacji. Sprawdzasz różnice i wybierasz Opublikuj, co zapisuje zmianę jako nową wersję na gałęzi.
4. Architect otwiera propozycję scalenia z main, tworząc opis na podstawie rzeczywistych commitów i uruchomień testów z gałęzi.
5. Architect proponuje wysłanie niewielkiej części ruchu produkcyjnego do gałęzi podczas przeglądu propozycji. 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 później otworzyć propozycję.

Walidacja w rozmowie

Architect pisze i uruchamia testy podczas tworzenia zmiany, a nie jako osobny krok uruchamiany później. W przypadku poprawki warto pokazać, że nowe testy nie przechodzą bez zmiany, a przechodzą z nią. Architect może uruchomić te same testy na oryginalnej gałęzi oraz na szkicu zawierającym zmianę.

Architect nie uruchamia automatycznie tego porównania przed i po dla każdej zmiany. Poproś o nie, gdy ma to znaczenie, na przykład: „Pokaż mi nową symulację, która 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ś Architect o kilkukrotne uruchomienie testów. Może powtórzyć każdy test do 50 razy i podać współczynnik 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żesz filtrować według statusu, autora (Utworzone przez) i recenzenta (Oczekuje na recenzję od, Zrecenzowane przez). Propozycja otwarta przez Architect w twojej rozmowie jest na liście z tobą jako autorem.

Architect zwraca też link do propozycji w rozmowie, gdy tylko ją utworzy.

Elementy propozycji

Strona propozycji pokazuje gałęzie źródłową i docelową, jej status, możliwość scalenia oraz to, o ile gałąź źródłowa jest za lub przed docelową. Ma te karty:

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 uprawnieniami edytora agenta może zrecenzować propozycję, z wyjątkiem jej autora. Ponieważ Architect działa w twoim imieniu, nie możesz zatwierdzić propozycji, którą Architect otworzył 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.

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 dla udziału ruchu, który otrzymuje gałąź docelowa. Gdy celem jest main i nie ustawiono podziału ruchu, oznacza to wszystkich rozmówców.

Scalenie także:

• Przenosi na gałąź docelową udział ruchu produkcyjnego, który miała gałąź źródłowa.
• Domyślnie archiwizuje gałąź źródłową.
• Zamyka wszystkie inne otwarte propozycje z tej samej gałęzi.
• Rozwiązuje powiązane zgłoszenie do triage, jeśli istnieje.

Stopniowe wdrażanie

Zanim propozycja zostanie scalona, możesz wysłać część ruchu produkcyjnego do jej gałęzi, aby rzeczywiści rozmówcy przetestowali zmianę.

Suma udziałów ruchu musi zawsze wynosić 100%, a routing jest deterministyczny dla każdej rozmowy. Zmiana udziału chronionej gałęzi, w tym odebranie ruchu chronionemu main, wymaga administratora. Zobacz Wdrażanie ruchu.

Proaktywne propozycje

Obecna proaktywna ścieżka to Spotlight, a następnie przekazanie sprawy. Spotlight stale obserwuje rozmowy twojego agenta. Tworzy cotygodniowe podsumowanie z sugerowanymi analizami, wysyła alerty w czasie rzeczywistym i rekomenduje zmiany konfiguracji. Aby zamienić ustalenie Spotlight w propozycję:

Zgłoszenia do triage działają tak samo. Twój agent produkcyjny może oznaczać problemy do sprawdzenia podczas rozmów, a Omów z Architect przy zgłoszeniu rozpoczyna jego analizę.

Zaplanowane automatyzacje z raportami dostarczanymi do skrzynki Architect są w przygotowaniu. Karta Skrzynka odbiorcza na stronie Architect jest dla nich miejscem zastępczym.