L'agente sceglie il prossimo ramo: Dify 1.18 facilita il trasferimento e l'ispezione dei flussi
Dify 1.18 aggiunge percorsi di uscita, pacchetti portabili e maggiore visibilità dei flussi. Che cosa significa trasformare una demo promettente in un processo aziendale riusabile.
Una demo può convincere dopo una sola richiesta riuscita. Le domande difficili arrivano quando un secondo team vuole riusarla: quale ramo sceglierà, quali file viaggiano con l'applicazione e dove si vede cosa è successo in un flusso annidato?
Dify 1.18.0, rilasciato il 23 ottobre 2026, riunisce queste domande. Introduce Output Routes per gli agenti, pacchetti .ifpkg portabili e maggiore visibilità dei flussi. Più che rendere impressionante la risposta, aiuta a capire il ruolo dell'agente nell'applicazione abbastanza da riutilizzarlo. Rilascio ufficiale.
Dify costruisce applicazioni IA con flussi visuali, modelli, conoscenza e strumenti. Collega il giudizio del modello ai passi dell'applicazione invece di copiare continuamente lo stesso prompt nella chat. Il rilascio unisce tre esigenze pratiche: scegliere il prossimo passo, spostare l'applicazione ed esaminarne l'esecuzione.
Interfaccia di LangGenius / collaboratori della documentazione Dify, CC BY 4.0. Ridimensionata e convertita in WebP senza ritagli. Illustra il builder visuale, non tutti i controlli appena rilasciati.
Un ramo è una decisione con una destinazione
In un flusso tradizionale, le condizioni verificano spesso un valore noto: approvazione, campo vuoto o punteggio oltre soglia. Le richieste linguistiche sono meno ordinate. Un cliente può mescolare domanda, lamentela ed eccezione nello stesso messaggio.
Le nuove Output Routes permettono all'agente di scegliere fra percorsi configurati, proseguendo nel ramo corrispondente. L'interpretazione diventa una scelta nel processo. Il passo successivo è rappresentato nel flusso, invece di essere affidato interamente alla prosa generata.
Questo facilita progettazione e ispezione. Il costruttore stabilisce le destinazioni. L'agente sceglie per una richiesta. Il flusso esegue i passi collegati. Il percorso serve anche quando la spiegazione in linguaggio naturale non è il prodotto finale.
Il confine conta. Scegliere «escalation» non prova un obbligo legale o finanziario di escalation. Scegliere «bozza» non autorizza l'invio. Il flusso deve ancora definire operazioni consentite dopo ogni scelta e responsabilità delle eccezioni.
Primo esempio: un messaggio del cliente, tre percorsi
Un team di assistenza riceve domande sui prodotti e richieste di eccezioni. Vuole distinguere risposta da fonti approvate, bozza per una persona ed escalation del caso insolito.
Con percorsi espliciti le destinazioni sono visibili. Una semplice domanda di configurazione va alla risposta basata sulla conoscenza. L'incertezza specifica dell'account va alla revisione. La richiesta di derogare a condizioni commerciali va al team autorizzato.
Sono scelte illustrative, non una policy pronta fornita da Dify. Il team deve definire ogni percorso, fornire esempi e decidere cosa fare nell'ambiguità. Una spiegazione persuasiva non deve cancellare un confine di autorità.
Il beneficio non è classificare facilmente tutto. È poter valutare una decisione precisa. Se un caso difficile finisce nella risposta ordinaria, il test fallisce chiaramente. Se tutto va a una persona, il flusso può essere sicuro ma automatizzare poco.
Conserva messaggi difficili e destinazioni attese. Includi richieste miste, dati mancanti e variazioni linguistiche reali. Un flusso valido solo sugli esempi puliti resta una demo, anche con un diagramma completo.
Un percorso configurato rende visibile il giudizio linguistico. Ogni destinazione necessita ancora di azioni consentite e regole di revisione.
Portabile significa più che copiare il prompt
Un'applicazione IA dipende da istruzioni, definizioni di agenti, Skills, file e riferimenti alle risorse. Copiare il prompt più visibile lascia indietro molto.
Dify 1.18 introduce il pacchetto .ifpkg, con Agents inline, Skills e relativi file. L'importazione ricrea le risorse e rimappa i riferimenti. Importazioni da file e URL supportano YAML e pacchetti, mentre rimane l'esportazione YAML esplicita. Pacchetti e importazione.
È un cambiamento significativo per il riuso. Diventa più probabile spostare insieme le parti che spiegano il funzionamento, invece di farle ricostruire a un collega da istruzioni manuali.
Non dimostra il trasferimento automatico di tutte le dipendenze esterne. Modelli, credenziali, plugin, permessi di rete e conoscenza dipendono dal nuovo ambiente. L'applicazione può essere strutturalmente integra e richiedere configurazione per funzionare.
Tratta il pacchetto come artefatto utile da ispezionare. Può contenere istruzioni e materiali scritti altrove. Prima di importarlo dove ci sono accessi importanti, comprendi origine e comportamento atteso di agenti e strumenti.
Secondo esempio: un processo di proposte passa a un altro team
Immagina un'azienda di servizi che prepara prime bozze di proposte. Il flusso raccoglie la richiesta, applica una Skill di scrittura, verifica le sezioni necessarie e invia condizioni commerciali incerte a una persona.
Un secondo team vuole usarlo con un catalogo diverso. Il solo prompt sarebbe incompleto: istruzioni, modelli allegati e riferimenti agli agenti sono parte del comportamento. Il pacchetto sposta più elementi collegati insieme.
Il destinatario deve ancora sostituire o confermare i servizi, configurare modelli e strumenti e verificare chi approva. Se il flusso fa riferimento a una risorsa estranea al nuovo spazio, l'importazione riuscita non giustifica ignorarla.
Esegui le stesse poche richieste prima e dopo il trasferimento. Confronta percorsi, sezioni, strumenti e revisione. La portabilità deve preservare il processo previsto, consentendo modifiche deliberate ai dati locali.
Qui il pacchetto diventa una funzione operativa. Riduce la ricostruzione, ma l'esito utile è un passaggio ripetibile che il nuovo team comprende e prova. I clic risparmiati sono solo parte del vantaggio.
Vedere dentro il flusso cambia la ricerca degli errori
Il rilascio evidenzia maggiore visibilità dei flussi, comprese esecuzioni annidate. Un'applicazione può fallire parecchi passi prima del punto in cui l'utente nota il problema.
Una bozza scadente può derivare da percorso errato, fonte mancante, risultato incompleto di uno strumento o istruzioni annidate. Guardando solo la fine si rischia di riscrivere il prompt sbagliato.
La visibilità permette domande più precise: quale ingresso è arrivato, quale risultato è uscito e quale passo lo ha usato? La risposta consente correzioni mirate anziché cambiare più parti insieme.
Non equivale a spiegare interamente il ragionamento interno del modello. Gli eventi e i dati non stabiliscono perché sia stato scelto ogni token o percorso. Non decidono neppure quali tracce ogni persona debba vedere.
Usa la visibilità per il comportamento osservabile. Decidi separatamente durata delle tracce, dati sensibili presenti e accessi. La comodità della diagnosi non deve trasformarsi in accesso illimitato alle richieste riservate.
| Capacità di 1.18 | Miglioramento pratico | Confine residuo |
|---|---|---|
| Output Routes degli agenti | La scelta linguistica ha un passo successivo visibile | Servono autorizzazione e gestione degli errori |
Pacchetti .ifpkg | Risorse di agenti e Skills viaggiano insieme | Accessi esterni e configurazione vanno controllati |
| Maggiore visibilità | I fallimenti si esaminano dentro processi ampi | La traccia non prova la correttezza della decisione |
Disponibilità e aggiornamento sono domande separate
Il rilascio GitHub è software pubblicato a una data precisa. Non dimostra che tutti gli spazi ospitati abbiano le stesse funzioni nello stesso momento. Chi usa il servizio gestito deve controllare il proprio spazio e la documentazione prima di pianificare.
Le installazioni autonome hanno responsabilità diverse. Dify 1.18 descrive cambi coordinati di API, worker, Agent Backend e immagini runtime, con protocollo modificato. Aggiornare un solo componente visibile non è affidabile quando cambia la comunicazione tra più parti.
Le note dettagliano anche configurazione e migrazione di sandbox locali e strumenti. Servono in un piano basato sull'installazione reale. Non vanno ridotte a un comando universale copiato da una panoramica.
Prima di aggiornare, conserva configurazione e artefatti, identifica le versioni compatibili e prova la migrazione nell'ambiente adatto. Non sostituire impostazioni persistenti di autenticazione o crittografia perché l'esempio contiene un valore nuovo. Segui esattamente la guida di migrazione.
Per provare percorsi e pacchetti può bastare un'applicazione separata. Così si impara il comportamento senza migrare subito il flusso più importante.
Una valutazione utile sta in una pagina
Non servono decine di agenti per capire il beneficio. Un'applicazione con una decisione reale e un secondo ambiente per l'importazione rivelano già proprietà importanti.
- Scegli un compito circoscritto. Usa ingressi e risultati riconoscibili, come una risposta di assistenza rivista. Nomina il responsabile delle eccezioni.
- Definisci pochi percorsi. Dai significato operativo a ognuno, specifica le azioni e prevedi i casi che non rientrano in sicurezza.
- Raccogli casi rappresentativi. Includi richieste normali, intenzioni miste e dati mancanti. Scrivi il percorso atteso prima della prova.
- Ispeziona l'esecuzione oltre alla risposta. Segui i passi annidati e individua dove nasce il risultato inatteso.
- Esporta e importa. Rivedi risorse, riferimenti, strumenti, modelli e segreti nel nuovo spazio. Non concedere automaticamente accessi mancanti.
- Ripeti gli stessi casi. Confronta percorsi e risultati e registra differenze deliberate nella configurazione del destinatario.
Le misure utili sono frequenza del percorso corretto, configurazione necessaria e possibilità di localizzare il guasto senza ricostruire tutto. Nessuna richiede di usare la prosa generata come prova di se stessa.
Il pacchetto trasferisce la struttura. Il nuovo ambiente necessita ancora di controlli d'accesso e degli stessi casi che definiscono il successo.
Che cosa promette di più e che cosa richiede cura
La direzione promettente è un'unità applicativa più riusabile. Il flusso ha destinazioni esplicite, risorse collegate e maggiore ispezionabilità. Aiuta chi ha superato il prompt isolato ma non vuole ogni applicazione come integrazione personalizzata.
La portabilità può però diffondere errori quanto buone pratiche. Un percorso vago o uno strumento troppo potente non diventano corretti dentro un pacchetto ordinato. Rivedi il comportamento, non soltanto l'apertura del file.
La prossima prova è la manutenzione: modello diverso, Skill nuova, policy aggiornata o nuovo spazio. La prima importazione riuscita incoraggia. Un aggiornamento controllato che preserva il comportamento indica più maturità.
Dify 1.18 rende interessante l'esperimento collegando decisioni e struttura visibile. Parti piccolo, mantieni comprensibili i percorsi e rendi ripetibile il passaggio. È così che una demo diventa qualcosa utilizzabile responsabilmente da un altro team.
Fonti
- Note di Dify 1.18.0, pubblicate il 23 ottobre 2026 alle 06:33 UTC.
- Documentazione ufficiale Dify, contesto del prodotto; verifica la disponibilità nello spazio reale.
Vuoi uno spazio ricercabile per note, richieste di esempio e decisioni delle revisioni? Raccogli i riferimenti in Telli.sh e rendi comprensibile il passaggio.