Agent wybiera następną gałąź: Dify 1.18 ułatwia przenoszenie i kontrolę procesów

Demo agenta może przekonywać już po jednej udanej prośbie. Trudniejsze pytania pojawiają się, gdy drugi zespół chce użyć go ponownie: którą gałąź wybierze, jakie pliki pojadą z aplikacją i gdzie zobaczyć przebieg zagnieżdżonego procesu?

Dify 1.18.0, wydane 23 października 2026 r., łączy te pytania. Wprowadza agentowe Output Routes, przenośne pakiety aplikacji .ifpkg i głębszy wgląd w procesy. Mniej chodzi tu o bardziej efektowną odpowiedź, a bardziej o zrozumiałe miejsce agenta w aplikacji, którą da się wykorzystać ponownie. Oficjalne wydanie.

Dify to platforma budowania aplikacji AI z wizualnych procesów, modeli, wiedzy i narzędzi. Pozwala łączyć ocenę modelu z krokami aplikacji zamiast wielokrotnie kopiować prompt do czatu. Interesująca jest tu więź trzech praktycznych spraw: wyboru następnego kroku, przeniesienia aplikacji i badania wykonania.

Interfejs procesu autorstwa LangGenius / współtwórców dokumentacji Dify, CC BY 4.0. Zmniejszono i przekonwertowano do WebP bez przycinania. Ekran ilustruje edytor wizualny, nie wszystkie nowo wydane kontrolki.

Gałąź jest decyzją prowadzącą do konkretnego celu

W tradycyjnym procesie warunki często badają znaną wartość: zatwierdzony status, puste pole lub wynik ponad progiem. Prośby językowe są mniej uporządkowane. Klient może połączyć pytanie, skargę i wniosek o wyjątek w jednej wiadomości.

Nowe Output Routes pozwalają agentowi wybierać ze skonfigurowanych tras, by proces kontynuował odpowiednią gałęzią. Interpretacja staje się wyborem wewnątrz procesu, którego następny krok jest widoczny w strukturze, a nie pozostawiony całkowicie generowanej prozie.

Może to ułatwić projektowanie i sprawdzanie aplikacji. Twórca ustala możliwe cele. Agent wybiera jeden dla danej prośby. Proces wykonuje połączone kroki. Trasa bywa użyteczna, nawet gdy językowe wyjaśnienie agenta nie jest produktem końcowym.

Granica ma znaczenie. Wybór „eskaluj” nie dowodzi prawnej lub finansowej konieczności eskalacji. Wybór „szkic odpowiedzi” nie jest zgodą na wysłanie. Proces musi nadal kodować operacje dozwolone po każdej decyzji i właścicieli wyjątków.

Przykład pierwszy: jedna wiadomość klienta, trzy drogi

Rozważmy zespół obsługi klienta otrzymujący pytania o produkt i prośby o wyjątki. Chce odróżniać trzy szerokie ścieżki: odpowiedź z zatwierdzonej pomocy, przygotowanie szkicu dla człowieka lub eskalację nietypowej sprawy.

Jawne trasy mogą pokazywać te cele w procesie. Proste pytanie konfiguracyjne trafi do odpowiedzi opartej na wiedzy. Prośba z niepewnością dotyczącą konta do przeglądu. Żądanie odstępstwa od warunków handlowych do zespołu odpowiedzialnego za decyzję.

To przykładowe wybory aplikacji, nie gotowa polityka wsparcia dostarczana przez Dify. Zespół definiuje przynależność tras, dostarcza przykłady i wybiera zachowanie wobec niejednoznaczności. Przekonujące wyjaśnienie nie powinno wymazywać granicy uprawnień.

Korzyść nie polega na łatwej klasyfikacji każdej wiadomości. Twórca może ocenić konkretną decyzję. Trudna wiadomość skierowana do zwykłej odpowiedzi daje jasny błąd testu. Każda prośba skierowana do człowieka może być bezpieczna, lecz zapewniać niewiele automatyzacji.

Zachowaj zestaw kłopotliwych wiadomości i oczekiwanych celów. Dodaj mieszane prośby, braki danych i warianty językowe podobne do rzeczywistego ruchu. Proces działający tylko na najczystszych przykładach nadal jest demonstracją, choć jego diagram wygląda na gotowy.

Skonfigurowana trasa zmienia ocenę językową w widoczny cel procesu. Każdy cel nadal potrzebuje własnych dozwolonych działań i zasad kontroli.

Przenośność to więcej niż kopiowanie promptu

Aplikacja AI może zależeć od instrukcji, definicji agentów, Skills, plików i odniesień do zasobów przestrzeni pracy. Skopiowanie najbardziej widocznego promptu zostawia sporą część aplikacji.

Dify 1.18 wprowadza pakiet .ifpkg mogący zawierać osadzone Agents, Skills i ich pliki. Opis wydania mówi o odtwarzaniu zasobów i mapowaniu referencji przy imporcie. Import z pliku i URL obsługuje YAML oraz pakiet, a jawny eksport YAML pozostaje dostępny. Zmiany pakietów i importu.

To istotna zmiana dla ponownego użycia. Zespół ma większą szansę przenieść razem elementy wyjaśniające działanie agenta, zamiast kazać koledze odtwarzać je z ręcznej instrukcji.

Nie dowodzi to automatycznego przeniesienia wszystkich zależności. Dostęp do modeli, dane uwierzytelniające, wtyczki, uprawnienia sieci i zasoby wiedzy mogą zależeć od środowiska docelowego. Strukturalnie kompletna importowana aplikacja nadal może potrzebować konfiguracji.

Traktuj pakiet jako użyteczny artefakt aplikacji wymagający przeglądu. Plik przenosi instrukcje i treści, których drugi zespół nie napisał. Przed importem do środowiska z wartościowymi dostępami zrozum jego pochodzenie i oczekiwane działania agentów oraz narzędzi.

Przykład drugi: proces ofertowy przechodzi do innego zespołu

Wyobraźmy sobie firmę usługową z procesem przygotowania pierwszej oferty. Zbiera prośbę, stosuje Skill pisania, sprawdza wymagane sekcje i kieruje niepewne warunki handlowe do człowieka.

Drugi zespół chce zastosować to samo do innego katalogu usług. Sam prompt nie wystarczy: powtarzalne instrukcje pisarskie, dołączone wzory i referencje agentów są częścią zachowania. Format pakietu ma pomagać w przenoszeniu większej liczby powiązanych części razem.

Odbiorca nadal ma pracę do wykonania. Musi podmienić lub potwierdzić dane usług, skonfigurować dozwolone modele i narzędzia oraz zweryfikować uprawnienia akceptacji oferty. Jeśli import odsyła do zasobu niepasującego do nowej przestrzeni, powodzenie importu nie usprawiedliwia pozostawienia go bez pytań.

Uruchom mały zestaw tych samych próśb przed przeniesieniem i po nim. Porównaj trasy, obowiązkowe sekcje, dostęp narzędzi i przegląd. Przenośna aplikacja powinna zachowywać zamierzony proces przy świadomych zmianach danych specyficznych dla celu.

Tu pakowanie staje się funkcją operacyjną. Zmniejsza odbudowę, ale użytecznym rezultatem jest powtarzalne przekazanie, które drugi zespół rozumie i testuje. Liczba oszczędzonych kliknięć importu stanowi tylko część wyniku.

Wgląd do wnętrza procesu zmienia diagnozowanie

Wydanie podkreśla również głębszą widoczność procesów, w tym zagnieżdżonego wykonania. To ważne, bo aplikacja może zawieść kilka kroków od miejsca, w którym użytkownik zauważa problem.

Słaby szkic końcowy może wynikać z błędnej trasy, brakującej wiedzy, niepełnego wyniku narzędzia lub instrukcji wewnątrz procesu. Widząc tylko końcową odpowiedź, zespół może ciągle przepisywać prompt nieodpowiadający za awarię.

Widoczne wykonanie pomaga pytać wężej: jakie wejście dotarło do kroku, jaki dał wynik i kto go następnie użył? Odpowiedź umożliwia precyzyjniejszą poprawkę niż jednoczesna zmiana wielu części aplikacji.

Widoczność nie jest pełnym wyjaśnieniem wewnętrznego rozumowania modelu. Informacje pokazują zdarzenia i przepływ danych bez dowodu przyczyny każdego tokenu lub trasy. Nie rozstrzygają też automatycznie, które fragmenty śladu należą się każdemu odbiorcy.

Używaj wglądu do rozumienia obserwowalnego zachowania. Osobno określ retencję śladów, dopuszczalne wrażliwe treści i dostęp. Aplikacja obsługująca poufne prośby nie powinna zmieniać wygody debugowania w nieograniczony wgląd w zawartość.

Dostępność wydania i aktualizacja to różne sprawy

Oficjalny release GitHub jest datowanym wydaniem oprogramowania. Sam nie potwierdza jednoczesnego włączenia tych samych funkcji w każdej hostowanej przestrzeni Dify. Użytkownicy usługi zarządzanej powinni sprawdzić własny interfejs i dokumentację przed planowaniem na podstawie konkretnej kontrolki.

Własne instalacje mają inną odpowiedzialność. Informacje Dify 1.18 opisują skoordynowane zmiany API, workerów, Agent Backend i obrazów środowiska, w tym nowy protokół runtime agenta. Aktualizacja pojedynczego widocznego komponentu nie jest niezawodnym przyjęciem wersji zmieniającej komunikację wielu części.

Notatki wskazują też konfigurację i migrację lokalnych piaskownic agentów oraz narzędzi. To elementy planu aktualizacji konkretnej instalacji. Nie należy sprowadzać ich do uniwersalnego polecenia skopiowanego z przeglądu produktu.

Przed aktualizacją zachowaj obecną konfigurację i artefakty, ustal wspierane wersje komponentów i przetestuj migrację we właściwym środowisku. Nie podmieniaj trwałych ustawień uwierzytelniania lub szyfrowania tylko dlatego, że przykład zawiera nowo wyglądającą wartość. Przestrzegaj dokładnych instrukcji migracji.

Jeśli natychmiastowym celem jest ocena tras lub pakietów, warto zacząć od osobnej aplikacji testowej. Pozwala poznać zachowanie bez przekształcania pierwszego eksperymentu w migrację najważniejszego procesu.

Przydatna ocena mieści się na jednej stronie

Nie potrzeba dziesiątek agentów do oceny tych funkcji. Jedna aplikacja z realną decyzją i drugie środowisko importu wystarczą do ujawnienia kilku istotnych cech.

1. Wybierz ograniczone zadanie. Ustal proces z rozpoznawalnym wejściem i wynikiem, na przykład przygotowanie sprawdzanej odpowiedzi wsparcia. Wskaż właściciela wyjątku.
2. Zdefiniuj mały zestaw tras. Nadaj każdej znaczenie operacyjne i określ dalsze czynności. Uwzględnij prośby niepasujące bezpiecznie do pozostałych.
3. Zbierz reprezentatywne przypadki. Użyj zwykłych próśb, mieszanych intencji i braków informacji. Zapisz oczekiwaną trasę przed uruchomieniem.
4. Sprawdzaj wykonanie, nie tylko wynik. Śledź właściwe zagnieżdżone kroki i znajdź pierwsze pojawienie się nieoczekiwanej wartości lub wyboru.
5. Eksportuj i importuj aplikację. Oceń zasoby pakietu, referencje, narzędzia, modele i sekrety w miejscu docelowym. Nie zakładaj automatycznej zgody na brakujący dostęp.
6. Powtórz przypadki po przeniesieniu. Porównaj trasy i wyniki oraz zapisz celowe różnice konfiguracji zespołu odbierającego.

Użyteczne pomiary są konkretne: częstość trafiania do właściwego celu, wysiłek konfiguracji i możliwość znalezienia błędu bez odbudowy całego przebiegu. Żaden nie wymaga traktowania generowanego tekstu jako dowodu własnej poprawności.

Pakiet przenosi strukturę aplikacji. Miejsce docelowe nadal potrzebuje własnych kontroli dostępu i powtórzenia przypadków definiujących sukces.

Co staje się bardziej obiecujące, a co wymaga uwagi

Nadzieję daje bardziej wielokrotnego użytku jednostka aplikacji. Proces może zawierać jawne cele, więcej wspierających zasobów agentowych i więcej informacji o wykonaniu po problemie. To pomaga zespołom wychodzącym poza pojedynczy prompt, które nie chcą budować osobnego projektu integracyjnego dla każdej aplikacji.

Obawa odpowiada tej zalecie: przenośność rozpowszechnia błędy równie skutecznie jak dobre wzorce. Niejasna definicja trasy lub nadmiernie uprawnione narzędzie nie staje się właściwe po schludnym zapakowaniu. Oceniaj importowane zachowanie, nie tylko udane otwarcie pliku.

Dla Dify kolejnym ważnym sprawdzianem będzie utrzymanie aplikacji podczas zmian modelu, Skill, polityki biznesowej lub przestrzeni pracy. Udany pierwszy import zachęca. Kontrolowana aktualizacja zachowująca zamierzone zachowanie jest mocniejszym sygnałem dojrzałości.

Dify 1.18 czyni eksperyment ciekawszym, łącząc decyzje agentów z widoczną strukturą procesu. Zacznij od małej pracy, zrozumiałych tras i powtarzalnego przekazania. Tak obiecujące demo staje się czymś, czego inny zespół może odpowiedzialnie użyć.

Źródła

• Informacje o wydaniu Dify 1.18.0, opublikowane 23 października 2026 r. o 06:33 UTC.
• Oficjalna dokumentacja Dify, tło produktu; dostępność wydania należy sprawdzić we własnej przestrzeni.

Chcesz przeszukiwalne miejsce na notatki o procesach, przykładowe prośby i decyzje za zmianami? Zbierz materiały odniesienia w Telli.sh i zachowaj zrozumiałość przekazania.