Open WebUI v0.13.3 umożliwia zaplanowanie uruchomienia agenta kodującego w wybranym terminalu i katalogu roboczym. Zacznij od zadania, które tylko generuje raport, w tymczasowej kopii repozytorium: uruchom znane polecenie testowe, podsumuj błędy i prześlij wynik na czat. Taki test sprawdza harmonogram, uprawnienia i sposób dostarczania wyników, zanim przyznasz cyklicznemu zadaniu dostęp do ważnych plików.
Potrzebujesz zgodnej instalacji Open WebUI, dostępnej integracji terminala oferującej wybranego agenta oraz dostępnego obszaru roboczego. Informacje o wydaniu v0.13.3 mówią, że zaplanowane uruchomienia sprawdzają, czy zapisany terminal i agent są nadal dostępne. Traktuj terminal, system plików i połączenie z bazowym modelem jako osobne elementy konfiguracji.
Co zmieniło listopadowe wydanie?
W edytorze automatyzacji można wybrać terminal i katalog, a następnie agenta oferowanego przez ten terminal. Skonfigurowany terminal i folder są używane podczas zaplanowanego uruchomienia. Wyniki automatyzacji z agentem trafiają do czatu, natomiast inne typy automatyzacji mogą mieć inne opcje miejsca docelowego. Wcześniejsze wydanie v0.13.1 wprowadziło agentów kodujących do selektora modeli, gdy oferuje ich podłączony terminal.
Wybrany terminal może działać na tym samym hoście co Open WebUI lub być osobną, dostępną usługą. W przypadku zadania liczy się system plików terminala. Katalog widoczny na laptopie może być niedostępny w kontenerze. Plik dostępny w jednym terminalu może nie istnieć w innym. Sprawdź ścieżkę w dokładnie tym terminalu, który wybrano do automatyzacji.

Jak przygotować obszar roboczy?
Utwórz dedykowaną testową kopię repozytorium, najlepiej małego i niezawierającego żadnych tajemnic produkcyjnych. Ustaw znaną wersję i dodaj do konfiguracji nieszkodliwy test, który przechodzi, oraz znany test, który kończy się niepowodzeniem. Na potrzeby pierwszego raportu udostępnij wejściową kopię repozytorium tylko do odczytu, jeśli runner testów to obsługuje. Zapewnij zapisywalny katalog roboczy na pamięć podręczną testów i logi. Niektóre narzędzia do budowania wymagają zapisu w drzewie, więc skonfiguruj je tak, by zapisywały gdzie indziej, lub użyj tymczasowej zapisywalnej kopii.
| Granica | Praktyczne ustawienie domyślne | Weryfikacja |
|---|---|---|
| Repozytorium | Dedykowana kopia repozytorium lub drzewo robocze | Agent widzi tylko wskazaną wersję i katalog. |
| Zapisy w systemie plików | Katalog roboczy lub tymczasowa kopia repozytorium | Katalogi nadrzędne i wrażliwe punkty montowania są niedostępne. |
| Dane logowania | Bez kluczy wdrożeniowych ani tokenów produkcyjnych dla pierwszego zadania | Środowisko i zamontowane ścieżki zawierają wyłącznie zatwierdzone dane wejściowe. |
| Model agenta | Wybierz rzeczywistego dostawcę i go udokumentuj | Sprawdź, które instrukcje lub wyniki narzędzi mogą opuścić hosta. |
| Wyniki | Raport czatu ze statusem i krótkim fragmentem dziennika | Zadanie dostarcza przydatnych dowodów, nawet jeśli testy się nie powiodą. |
Jeśli kilka zadań korzysta z jednego repozytorium, utwórz osobne drzewo robocze dla każdego agenta lub zadania. Kopie zapasowe i katalog roboczy przechowuj osobno. Zanim przyznasz zadaniu szerokie uprawnienia do zapisu na serwerze plików, przeczytaj dlaczego przy współdzielonym dostępie kopie zapasowe mogą zawodzić.
Jak skonfigurować pierwsze zaplanowane zadanie?
Otwórz edytor automatyzacji w wersji obsługującej automatyzację agentów. Wybierz terminal, katalog widoczny z poziomu tego terminala, a następnie agenta. Przy pierwszym teście zaplanuj jednorazowe uruchomienie w najbliższym czasie, jeśli Twoja instalacja oferuje taką opcję. Odczytaj harmonogram w skonfigurowanej strefie czasowej. Ustaw niewielki limit czasu działania lub kroków za pomocą ustawień dostępnych dla Twojego agenta i wdrożenia.
Podaj zadaniu konkretne dane wejściowe, polecenie i format wyniku. Na przykład:
Sprawdź kopię roboczą w wybranym katalogu roboczym.
Raz uruchom istniejące lokalne polecenie testu dymnego.
Podaj polecenie, kod wyjścia i nazwę pierwszego nieudanego testu.
Jeśli polecenie lub folder są niedostępne, zgłoś ten błąd.
Nie instaluj zależności, nie zmieniaj repozytorium ani nie kontaktuj się z usługami zewnętrznymi.
Instrukcje naprowadzają agenta. Granice dostępu do systemu plików i sieci egzekwuj osobno, za pomocą konfiguracji terminala i kontenera. Sprawdź, czy brak zależności powoduje czytelny komunikat o błędzie, a nie nieoczekiwaną instalację. Dokumentacja Open WebUI to punkt wyjścia do poznania ustawień terminala i administratora.
Co należy sprawdzić po pierwszym uruchomieniu?
Otwórz utworzony czat i sprawdź tożsamość agenta, ścieżkę roboczą, polecenie testowe, kod wyjścia oraz rewizję, która była testowana. Porównaj wynik z ręcznym uruchomieniem tego samego polecenia w tym terminalu. Zakończona automatyzacja pokazuje tylko, że przepływ pracy dobiegł końca. Raport nadal musi zawierać dowody, że rzeczywiście wykonano zamierzony test.
Celowo przetestuj ścieżkę błędu. Skieruj zadanie testowe do niegroźnego, brakującego pliku wejściowego albo na krótko zatrzymaj tymczasowy terminal i sprawdź stan po tej operacji. Po teście przywróć poprzedni stan. Operator powinien móc odróżnić niedostępnego agenta, brakujący katalog, nieudany test i przekroczenie limitu czasu modelu bez czytania całej historii czatu. Sprawdź, czy następne prawidłowe uruchomienie nie wykorzystuje po cichu nieaktualnych wyników.
Czy self-hosting Open WebUI zapewnia lokalne przechowywanie kodu?
Open WebUI i jego terminal mogą być hostowane samodzielnie, podczas gdy wybrany agent programistyczny korzysta ze zdalnego modelu. Ustal, dokąd agent wysyła prompty systemowe, fragmenty plików i logi testów. Sprawdź konfigurację dostawcy, zanim podłączysz prywatne repozytorium. Dane uwierzytelniające dostawcy przechowuj w przeznaczonej do tego konfiguracji sekretów usługi i nie udostępniaj ich w promptach ani logach.
Jeśli Twoje wymagania wykluczają przetwarzanie zewnętrzne, zacznij od lokalnego punktu końcowego modelu. Sprawdź punkt końcowy i konfigurację awaryjną agenta, a następnie zweryfikuj wszelkie ograniczenia sieciowe dotyczące terminala. Więcej informacji o ograniczaniu ryzyka ujawnienia znajdziesz w tym przewodniku po analizie luk w zabezpieczeniach za pomocą AI i ochronie sekretów.
Jak zmienić zadanie generujące wyłącznie raport w cykliczny przepływ pracy?
Gdy wyniki pierwszych uruchomień, zarówno udanych, jak i nieudanych, będą zrozumiałe, dodaj cykliczny harmonogram, który nie będzie nakładać się na inne zadanie korzystające z tego samego katalogu. Dodawaj do raportów znacznik czasu i rewizję repozytorium. Uprość alerty: sygnalizuj awarie wymagające działania i zachowuj wystarczający kontekst, aby można je było odtworzyć. Okresowo sprawdzaj, czy dane uwierzytelniające agenta, łączność z terminalem i zaplanowany katalog nadal działają po aktualizacjach.
Jeśli później zezwolisz na wprowadzanie poprawek, trzymaj je w odizolowanej gałęzi i wymagaj weryfikacji przed scaleniem. W przeciwnym razie ponowienie zadania przez harmonogram może powielić skutki uboczne. Zadanie generujące wyłącznie raport łatwiej ponowić, bo zapisuje tylko wynik, podczas gdy aktualizacje zależności i polecenia wdrożeniowe zmieniają stan. Potraktuj tę zmianę jako odrębną decyzję dotyczącą uprawnień.
FAQ
W której wersji dodano automatyzacje agentów?
Odpowiednia funkcja została wymieniona w Open WebUI v0.13.3. Funkcja selektora agentów w v0.13.1 jest powiązana, ale odrębna.
Dlaczego agent nie pojawia się w selektorze?
Sprawdź, czy wybrany terminal jest osiągalny i udostępnia tego agenta oraz czy Twoja zainstalowana wersja i uprawnienia konta umożliwiają korzystanie z tej funkcji.
Czy mogę wybrać folder z laptopa?
Wybierz ścieżkę dostępną w terminalu, który rzeczywiście uruchomi zadanie. W razie potrzeby najpierw zamontuj tam lub skopiuj repozytorium.
Czy wynik automatyzacji trafia na kanał?
W informacjach o wersji v0.13.3 wskazano, że automatyzacje agenta dostarczają wyniki przez czat. Zanim skorzystasz z innego miejsca docelowego, sprawdź dostępne opcje w bieżącej wersji.
Co zrobić, jeśli dwa przebiegi nakładają się na siebie?
Użyj osobnych drzew roboczych albo wybierz harmonogram i limit czasu działania, które zapobiegną nakładaniu się zadań. Zanim zaufasz raportowi, sprawdź każdy przebieg, który korzystał z niewłaściwej rewizji.
Wnioski
Użyj jednego terminala, jednego odizolowanego katalogu roboczego i jednego niewielkiego zadania generującego wyłącznie raport, aby sprawdzić cały przebieg. Zweryfikuj dostawcę modelu, przetestuj zarówno powodzenie, jak i niepowodzenie, a dane uwierzytelniające do środowiska produkcyjnego trzymaj poza terminalem. Gdy wyniki będą powtarzalne, ta sama konfiguracja może obsługiwać cykliczne kontrole repozytorium.
Wsparcie i porady
Więcej do przeczytania

Co sprawdzić przed załadowaniem modelu społecznościowego w Transformers
Użyj aktualizacji piaskownicy Jinja dla Transformers, aby sprawdzić pochodzenie modelu, szablony czatu, zdalny kod, serializowane wagi i pierwsze uruchomienia w izolowanym środowisku.

Uruchom Mirage lokalnie: OCR i wykrywanie obiektów na podstawie jednego obrazu
Przetestuj niewielki lokalny model wizyjny Cactus Compute, zweryfikuj OCR i ekstrakcję obiektów na rzeczywistych danych wejściowych oraz poznaj ograniczenia związane z pamięcią, językiem i...

Jak bezpiecznie skonfigurować DeepSeek Super Agent: konta, uprawnienia i izolacja
Nie rozpoczynaj eksperymentu z dsh-superagent na swoim codziennym koncie ani w cennym repozytorium produkcyjnym. Z dokumentacji wdrożenia wynika, że zarówno presety routera, jak i...




