AI Tools7 min czytania

Poranny raport z testów może być gotowy przed otwarciem Open WebUI

Open WebUI 0.13.3 daje zaplanowanym agentom programistycznym terminal i katalog projektu. Sprawdź, jak przygotować poranny raport z ograniczonymi uprawnieniami.

K
Ken Jo

W poniedziałek o 8:30 programista otwiera wyniki nocnych testów. Trzy zadania świecą na czerwono. Pierwsze straciło połączenie z testową bazą danych, drugie natrafiło na sporadyczne przekroczenie czasu, trzecie nie przeszło asercji w kodzie zmienionym w piątek. Uporządkowanie wyników trwa dłużej niż odczytanie czerwonych znaczników. Cyklicznie uruchamiany agent mógłby zostawić na czacie krótki raport z nieudaną asercją i fragmentem logu na początku.

Open WebUI, interfejs czatu dla modeli i narzędzi AI, który można hostować samodzielnie, od wersji 0.13.3 obsługuje agentów programistycznych w zaplanowanych automatyzacjach. GitHub podaje czas wydania 8 listopada 2026 roku o 23:48 UTC. Automatyzacja może zapisać terminal, katalog roboczy i dostępnego w nim agenta, a wynik dostarczyć na czat. Harmonogram uruchamia zadanie w określonym środowisku, dzięki czemu poranny raport jest praktyczny. Informacje o wydaniu Open WebUI v0.13.3

Pierwsze zadanie warto ograniczyć do raportu, który człowiek zweryfikuje w kilka minut. Automatyzacja zbiera dowody, a następna decyzja należy do osoby odpowiedzialnej za projekt. Powtarzalny, użyteczny raport daje punkt odniesienia do decyzji o kolejnym uprawnieniu.

Automatyzacja pamięta, gdzie pracuje agent

Automatyzacje Open WebUI już obsługują powtarzane polecenia. Uruchomienie otwiera czat przez zwykły mechanizm generowania odpowiedzi, więc znaczenie mają ustawienia modelu, narzędzia, filtry i właściwe ustawienia pamięci. Wersja 0.13.3 dodaje wybór agenta wykrytego w terminalu. Po wybraniu terminala lista modeli pokazuje dostępne pary w formacie agent/model. Zmiana terminala lub katalogu może zmienić listę. Przed startem Open WebUI sprawdza zapisany terminal i agenta. Jeśli któregoś brakuje, zadanie kończy się błędem, a właściciel może zajrzeć do dziennika. Dokumentacja automatyzacji Open WebUI

Harmonogram, terminal, katalog projektu i agent prowadzą do raportu na czacie

Harmonogram uruchamia czat z zapisanymi ustawieniami. Oryginalna ilustracja Telli.sh oparta na informacjach o wersji 0.13.3.

Katalog roboczy rozstrzyga proste pytanie z kosztownymi skutkami. Którą kopię ma czytać agent, kiedy dwa projekty mają podobne nazwy plików albo na dysku są gałęzie funkcji i wydania? Jawna ścieżka wyznacza punkt startu i daje sprawdzającemu odniesienie. To nadal katalog początkowy. Prawa odczytu i zapisu, dostępne pliki, zmienne środowiskowe, sieć i zachowanie agenta decydują, dokąd może jeszcze sięgnąć zadanie.

Wynik również ma określone miejsce. Automatyzacje z agentami przekazują go na czat. Informacje o wersji odróżniają je od zwykłych automatyzacji modeli, które mogą kierować wyniki do kanałów. Historia i czat wystarczą jednej osobie do przeglądu raportu. Jeśli zespół chce wspólnego powiadomienia, osobno ustala zakres, miejsce i dostęp do logu źródłowego. Nieudane zadanie też potrzebuje właściciela, który wie, gdzie szukać. Informacje o wydaniu Open WebUI v0.13.3

Daj pierwszemu zadaniu małe dane, które da się sprawdzić

W przypadku raportu poniedziałkowego weź kopię ostatniego nocnego podsumowania, automatyczny identyfikator commita i kilka fragmentów logów z błędami. Eksport artefaktów CI albo ręczna kopia w tymczasowym katalogu daje stabilne wejście. Każdy plik powinien zawierać dane pozwalające przypisać błąd do zadania i commita. Usuń oczywiste sekrety i zbędne logi przed przeniesieniem. Ustal standardową nazwę pliku i sprawdzalny znacznik czasu, żeby agent nie musiał zgadywać, co jest najnowsze.

Poproś o trzy części w jednej odpowiedzi. Pierwsza to krótka lista błędów wymagających uwagi. Druga obejmuje problemy środowiska i przypadki bez wyjaśnienia. Trzecia podaje łącze lub ścieżkę do dowodu przy każdym punkcie. Zwięzły format ułatwia porównanie z oryginalnym widokiem CI. Sześć identycznych zgłoszeń za ten sam test w sześciu konfiguracjach powiększa problem, który raport miał uprościć.

Polecenie powinno określać, jakie informacje muszą zostać zachowane. Poniższy przykład zakłada dane próbne z zapisem commita i wyeksportowanym podsumowaniem. Katalog i pliki są przykładowe.

Przeczytaj wyeksportowane podsumowanie testów i fragmenty błędów w przydzielonym katalogu projektu. Zacznij od identyfikatora uruchomienia, commita i czasu z wejścia. Grupuj powtarzające się awarie w macierzy. Dla każdego odrębnego błędu podaj nazwę testu, najkrótszy przydatny fragment i ścieżkę źródła. Oddziel jawne błędy od możliwych przyczyn. Jeśli podsumowanie jest niedostępne, nieaktualne lub niepełne, wymień braki i przerwij. Zostaw pliki bez zmian.

Takie instrukcje ograniczają niejasność. Terminal potrzebuje pasujących uprawnień. Jeśli zadanie tylko czyta pliki, udostępnij widok do odczytu lub tymczasową kopię bez danych dostępowych do repozytorium. Nieudany test może wydrukować dowolny tekst z kodu, zależności lub danych próbnych. To materiał dowodowy bez prawa wydawania poleceń agentowi. Różnica jest ważniejsza, gdy zadanie rusza, zanim jego właściciel wstanie.

Ten sam układ przyda się w innym cyklicznym zadaniu. Kierownik może dać agentowi datowany spis zależności i osobno pobraną listę ostrzeżeń, a następnie poprosić o potencjalne dopasowania wersji i cytaty z zapisów. Przydatny wynik zawiera pakiet, wersję i źródło. Zaufany skaner może dopasowywać wersje deterministycznie, a człowiek oceni, czy zależność jest osiągalna w działającym kodzie. Stabilne pliki pomagają odtworzyć raport, jeśli wyjaśnienie zmienia się między próbami.

Krótka konfiguracja ujawnia większość pracy

Dokumentacja Open WebUI opisuje globalny przełącznik automatyzacji i osobne uprawnienie dla użytkowników bez roli administratora. Sprawdź, czy instancja działa na 0.13.3 lub zgodnym nowszym wydaniu, czy funkcja jest włączona i czy konto ma dostęp. Terminal musi być połączony i dozwolony w kontekście automatyzacji. Może być widoczny w edytorze modeli, a ustawienia kontekstu mogą wykluczać go z zaplanowanych zadań. To wyjaśnia, dlaczego zwykły czat działa, a zadanie z harmonogramu zawodzi. Automatyzacje Open WebUI · Dokumentacja połączenia Open Terminal

  1. Przygotuj dane próbne. W tymczasowym katalogu umieść udane uruchomienie, reprezentatywny błąd i manifest z commitem i czasem. Ogranicz rozmiar plików. Poza katalogiem zostaw klucze produkcji, konfigurację chmury i pliki osobiste.
  2. Otwórz automatyzacje i utwórz zadanie. Uzupełnij nazwę, polecenie, model i harmonogram. W edytorze wybierz terminal, wpisz katalog roboczy i wybierz agenta z listy. Zaczekaj, aż środowisko wyświetli dostępnych agentów.
  3. Uruchom raz z edytora. Otwórz czat i dziennik. Sprawdź commit, pliki źródłowe, usunięcie powtórzeń i uprawnienia. Porównaj wynik z oryginalnym artefaktem i sprawdź czystość drzewa roboczego.
  4. Sprawdź przypadek negatywny. Usuń manifest z osobnego zestawu albo wskaż celowo stare wejście. Raport powinien pokazać braki. Sprawdź, czy terminal niedostępny automatyzacjom daje błąd w historii.
  5. Ustaw harmonogram i przejrzyj pierwsze wyniki. Porównaj start z końcem eksportu CI. Raport, który startuje za wcześnie i czyta wczorajsze dane, ma problem z harmonogramem nawet przy przekonującym opisie. Wstrzymaj go, jeśli format wejścia się zmieni lub odpowiedzi zaczną odbiegać od oczekiwań.

Traktuj dane próbne i polecenie jako parę. Przy zmianie katalogu, zasad gałęzi albo zestawu testów zaktualizuj próbkę razem z zadaniem. Wtedy raport nie straci po cichu dowodów potrzebnych do grupowania. Po zmianie polecenia zachowaj dawny przykład i porównaj obie odpowiedzi na tych samych danych. Najtańszą poprawką często jest lepszy manifest, zwłaszcza gdy dwa zadania muszą się zgadzać co do najnowszego uruchomienia.

Wybór terminala wyznacza granicę uprawnień

Samodzielnie hostowany czat może łączyć się z modelem lub agentem innego dostawcy. Sprawdź dostawcę, otrzymywane dane i dostępne poświadczenia. Kopia robocza w kontenerze lub katalogu tymczasowym pozwala ograniczyć działanie zadania. Sam katalog startowy niewiele chroni, gdy ten sam użytkownik ma dostęp do całego hosta lub agent dysponuje prawem zapisu do repozytorium. Dokumentacja opisuje konteksty terminala, w tym automatyzację, żeby administrator ograniczył dostęp przed startem. Dokumentacja połączeń terminala Open WebUI

Dane tylko do odczytu i ograniczony terminal prowadzą do sprawdzenia dowodów przed osobnym zapisem

Raport tylko do odczytu rozdziela dowody, prawa wykonania i decyzję sprawdzającego. Oryginalna ilustracja Telli.sh.

ZadanieMinimalne przydatne daneWynik do przegląduCo początkowo wyłączyć
Podsumowanie nocnych testówWyeksportowany raport, commit, wybrane fragmenty loguBłędy według pilności wraz z dowodamiZapisy do repozytorium i wdrożenia
Przegląd zależnościSpis wersji i zaufana kopia ostrzeżeńMożliwe dopasowania z pakietem i wersjąAktualizacje pakietów i pull requesty
Przekazanie wydaniaManifest, podsumowanie testów, zatwierdzona lista zgłoszeńBraki dowodów i otwarte kwestieTagi wydania i powiadomienia klientów

Oszczędność to czas od otwarcia wyników do ustalenia, gdzie patrzeć. Niezawodne polecenie może wykonać znaczną część tej pracy. Niech zwraca ID i stan, a agent niech wyjaśnia błędy z różnych rodzajów wyjścia. Gdy zadanie zachowuje się dziwnie, porównaj ID z manifestem i sprawdź wejście przed zmianą agenta.

W tej samej kontroli uwzględnij koszty. Zadania mogą zużywać płatny limit, jeśli agent wywołuje rozliczany model. Długie logi zwiększają wejście, a powtarzające się awarie mogą powodować kolejne analizy. Najpierw oceń pożytek z krótkich fragmentów przy ograniczonym harmonogramie. Jeśli każde zadanie czyta te same duże pliki, dodaj tani deterministyczny krok wykrywający zmianę. Codzienne zadanie łatwiej ująć w budżecie, jeśli ma znany maksymalny rozmiar wejścia.

W małym zespole właściciel zadania jest równie ważny jak terminal. Według dokumentacji automatyzacja należy do osoby, która ją utworzyła, i jest dla niej prywatna. Raport osobisty może zostać tam. Zatwierdzanie wydania przez kilka osób wymaga oddzielnej widocznej procedury dzielenia się materiałami i przekazywania odpowiedzialności. Historia automatyzacji pomaga jednej osobie prześledzić awarię. Wspólna kontrola CI pozostawia decyzję widoczną dla zespołu. Kontrola dostępu do automatyzacji Open WebUI

Wartość raportu widać podczas przeglądu

Po pierwszym tygodniu zobacz, które raporty ktoś naprawdę otworzył. Sprawdź łącze lub fragment przy każdym pilnym elemencie i policz pominięte błędy, powtórzenia oraz odwołania do złego commita. Zapytaj sprawdzającego, czy raport pomógł znaleźć następny test do obejrzenia. Te obserwacje mówią o wartości harmonogramu więcej niż liczba odpowiedzi.

Jeśli wyniki pozostają użyteczne, dodawaj po jednym rodzaju dowodu. Ustal stałe miejsce pracy terminala, ogranicz poświadczenia, a zmiany kodu i infrastruktury prowadź zwykłą ścieżką przeglądu. Najlepszy znak postępu to raport, na podstawie którego można działać i który łatwo sprawdzić, gdy coś się nie zgadza.

Źródła


Aby przechowywać rozmowy i decyzje w miejscu, które można przeszukiwać, załóż konto Telli.sh.


← Wróć do bloga