Um agente escolhe a próxima ramificação: o Dify 1.18 facilita mover e inspecionar fluxos

Uma demonstração de agente pode parecer convincente após uma única solicitação bem-sucedida. As perguntas difíceis chegam quando outra equipe quer reutilizá-la: qual ramificação ele escolherá, quais arquivos acompanharão a aplicação e onde alguém verá o que aconteceu dentro de um fluxo aninhado?

O Dify 1.18.0, lançado em 23 de outubro de 2026, aproxima essas perguntas. A versão apresenta Output Routes para agentes, pacotes portáteis de aplicações .ifpkg e maior visibilidade dos fluxos. Essas mudanças têm menos a ver com obter uma resposta mais impressionante e mais com tornar o lugar do agente na aplicação compreensível o suficiente para reutilização. Lançamento oficial.

O Dify é uma plataforma para construir aplicações de IA com fluxos visuais, modelos, conhecimento e ferramentas. As equipes podem conectar o julgamento de um modelo às etapas da aplicação, em vez de copiar repetidamente o mesmo prompt em um chat. O interessante nesta versão é a união de três preocupações práticas: decidir a próxima etapa, mover a aplicação e examinar sua execução.

Interface de fluxo por LangGenius / colaboradores da documentação do Dify, CC BY 4.0. Redimensionada e convertida para WebP sem cortes. A tela ilustra o construtor visual, não todos os controles recém-lançados.

Uma ramificação é uma decisão com um destino

Em um fluxo tradicional, as condições costumam inspecionar um valor conhecido: um status foi aprovado, um campo está vazio ou uma pontuação ultrapassou um limite. Solicitações em linguagem natural são menos organizadas. Um cliente pode misturar uma pergunta, uma reclamação e um pedido de exceção em uma única mensagem.

As novas Output Routes do Dify permitem ao agente escolher entre rotas configuradas para o fluxo seguir pela ramificação correspondente. A interpretação do agente vira uma escolha dentro de um processo, com a próxima etapa representada no fluxo em vez de ficar inteiramente no texto gerado.

Isso pode facilitar projetar e examinar a aplicação. O construtor decide quais destinos existem. O agente escolhe entre eles para uma solicitação. O fluxo então executa as etapas conectadas. Uma rota pode ser útil mesmo quando a explicação em linguagem natural do agente não é o produto final.

A fronteira importa. Escolher uma rota de “escalonamento” não é provar que um caso exige escalonamento jurídico ou financeiro. Escolher “redigir resposta” não é permissão para enviá-la. O fluxo ainda precisa definir quais operações são permitidas após cada escolha e quem responde pelas exceções.

Primeiro exemplo: uma mensagem de cliente, três caminhos possíveis

Considere uma equipe de suporte que recebe uma mistura de perguntas sobre o produto e pedidos de exceção. Ela quer uma aplicação capaz de distinguir três caminhos amplos: responder com material de ajuda aprovado, preparar um rascunho para uma pessoa ou escalonar um caso incomum.

Com rotas explícitas, esses destinos ficam visíveis no fluxo. Uma pergunta simples de configuração pode entrar no caminho de resposta com base no conhecimento. Uma solicitação com incerteza específica da conta pode entrar em revisão. Um pedido para abrir exceção a uma condição comercial pode ir para a equipe responsável pela decisão.

São escolhas ilustrativas de aplicação, não uma política pronta de suporte fornecida pelo Dify. A equipe precisa definir o que pertence a cada rota, fornecer exemplos apropriados e decidir o que acontece quando a entrada é ambígua. Uma explicação persuasiva não deve apagar uma fronteira de autoridade.

O benefício não é tornar toda mensagem fácil de classificar. É permitir que o construtor avalie uma decisão específica. Se o agente manda uma mensagem difícil para a ramificação comum de resposta, o teste tem uma falha clara. Se manda toda solicitação para uma pessoa, o fluxo pode ser seguro, mas oferece pouca automação útil.

Mantenha um conjunto de mensagens problemáticas e destinos esperados. Inclua pedidos mistos, informações ausentes e variações linguísticas parecidas com o tráfego real dos clientes. Um fluxo que só funciona nos exemplos mais limpos continua sendo uma demonstração, mesmo que o diagrama pareça pronto.

Uma rota configurada transforma um julgamento de linguagem em um destino visível do fluxo. Cada destino ainda precisa de suas próprias ações permitidas e regras de revisão.

Portátil significa mais do que copiar um prompt

Uma aplicação de IA pode depender de instruções, definições de agentes, Skills, arquivos e referências a recursos de um espaço de trabalho. Copiar o prompt mais visível deixa grande parte da aplicação para trás.

O Dify 1.18 apresenta um pacote .ifpkg que pode incluir Agents incorporados, Skills e seus arquivos. Na importação, a versão descreve recriar os recursos e remapear as referências. Importações por arquivo e URL aceitam YAML e o formato de pacote, enquanto a exportação explícita em YAML continua disponível. Mudanças de pacotes e importação.

É uma mudança importante para reutilização. A equipe tem mais chance de mover juntas as partes que explicam como o agente funciona, em vez de deixar um colega reconstruí-las a partir de uma lista de instruções manuais.

Isso não comprova que toda dependência externa se move automaticamente. Acesso a modelos, credenciais, disponibilidade de plugins, permissões de rede e recursos de conhecimento podem depender do ambiente de destino. Uma aplicação importada pode estar estruturalmente intacta e ainda precisar de configuração para funcionar corretamente.

Trate o pacote como um artefato útil de aplicação que exige inspeção. Um arquivo pode carregar instruções e conteúdo de apoio que a outra equipe não escreveu. Antes de importá-lo em um espaço com acessos valiosos, entenda sua origem e o que se espera de seus agentes e ferramentas.

Segundo exemplo: um fluxo de propostas vai para outra equipe

Imagine uma empresa de serviços que construiu um fluxo para preparar a primeira versão de uma proposta. Ele reúne uma solicitação, aplica uma Skill de redação, confere se as seções obrigatórias estão presentes e encaminha termos comerciais incertos a uma pessoa.

Uma segunda equipe quer usar a mesma abordagem com outro catálogo de serviços. Entregar apenas o prompt seria incompleto: as instruções reutilizáveis, os modelos anexados e as referências de agentes fazem parte do comportamento. O formato de pacote foi projetado para ajudar a mover mais dessas peças conectadas juntas.

A equipe que recebe ainda tem trabalho. Precisa substituir ou confirmar informações dos serviços, configurar modelos e ferramentas permitidos e verificar quem pode aprovar uma proposta. Se o fluxo importado se refere a um recurso que não pertence ao novo espaço, a importação ter funcionado não é motivo para deixar a referência sem questionamento.

Execute um pequeno conjunto das mesmas solicitações antes e depois da mudança. Compare rotas escolhidas, seções obrigatórias, acesso às ferramentas e comportamento de revisão. Uma aplicação portátil deve preservar o processo desejado e permitir mudanças deliberadas nas informações específicas do destino.

É aqui que o empacotamento se torna um recurso operacional. Ele pode reduzir a reconstrução, mas o resultado útil é uma passagem de trabalho repetível que outra equipe consegue entender e testar. A quantidade de cliques economizados na importação é apenas uma parte do resultado.

Enxergar dentro do fluxo muda a forma de depurar

A versão também destaca maior visibilidade dos fluxos, incluindo execução aninhada. Isso importa porque a aplicação pode falhar várias etapas antes do ponto em que o usuário percebe o problema.

Um rascunho final ruim pode vir de um erro de rota, uma fonte de conhecimento ausente, um resultado incompleto de ferramenta ou instruções em um fluxo aninhado. Se a equipe só consegue inspecionar a resposta final, pode continuar reescrevendo um prompt que não é responsável pela falha.

Uma execução mais visível ajuda a fazer uma pergunta mais restrita: qual entrada chegou a esta etapa, qual resultado ela produziu e qual etapa utilizou o resultado depois? A resposta apoia uma correção mais precisa do que alterar várias partes da aplicação de uma vez.

Visibilidade não é uma explicação completa do raciocínio interno do modelo. Informações de execução podem mostrar eventos da aplicação e fluxo de dados sem estabelecer por que cada token ou rota foi escolhido. Também não decidem automaticamente qual conteúdo do rastreamento é apropriado para cada pessoa.

Use a visibilidade disponível para entender o comportamento observável do fluxo. Decida separadamente por quanto tempo guardar rastreamentos, qual material sensível pode aparecer neles e quem deve ter acesso. Uma aplicação com solicitações confidenciais não deve transformar a conveniência da depuração em acesso irrestrito a seu conteúdo.

Disponibilidade da versão e atualização são questões separadas

O lançamento oficial no GitHub é uma versão de software datada. Ele não prova, sozinho, que todo espaço hospedado do Dify tem os mesmos recursos ativados no mesmo instante. Quem usa um serviço gerenciado deve verificar seu espaço real e a documentação antes de planejar em torno de um controle específico.

Instalações próprias têm outra responsabilidade. As notas do Dify 1.18 descrevem mudanças coordenadas entre API, workers, Agent Backend e imagens de execução, incluindo um protocolo alterado de execução de agentes. Atualizar um único componente visível não é uma forma confiável de adotar uma versão que muda a comunicação entre vários componentes.

As notas também destacam detalhes de configuração e migração de sandboxes locais de agentes e ferramentas. Esses detalhes pertencem a um plano de atualização baseado na instalação real. Não devem ser reduzidos a uma instrução universal copiada de uma visão geral do produto.

Antes de atualizar, preserve a configuração e os artefatos atuais da aplicação, identifique as versões compatíveis dos componentes e teste a migração em um ambiente apropriado. Não substitua configurações persistentes de autenticação ou criptografia apenas porque um exemplo contém um valor com aparência nova. Siga as orientações exatas de migração da versão.

Para uma equipe cujo objetivo imediato é avaliar rotas ou pacotes, pode fazer sentido começar por uma aplicação de teste separada. Assim, aprende o novo comportamento sem transformar o primeiro experimento na migração de seu fluxo mais importante.

Uma avaliação útil cabe em uma página

Você não precisa de dezenas de agentes para descobrir se os recursos ajudam. Uma aplicação com uma decisão real e um segundo ambiente para testar importação já revelam várias propriedades importantes.

1. Escolha uma tarefa delimitada. Selecione um processo com entradas e resultados reconhecíveis, como preparar uma resposta de suporte para revisão. Nomeie quem responde por uma exceção.
2. Defina um conjunto pequeno de rotas. Dê a cada uma um significado operacional e especifique as ações seguintes. Inclua um caminho para solicitações que não se encaixam com segurança.
3. Reúna casos representativos. Use pedidos comuns, mensagens com intenções misturadas e casos de informação ausente. Escreva a rota esperada antes de executar.
4. Inspecione a execução, não apenas a resposta final. Siga as etapas aninhadas relevantes e identifique onde surge o primeiro valor ou escolha inesperados.
5. Exporte e importe a aplicação. Revise os recursos incluídos e verifique referências, ferramentas, modelos e segredos no destino. Não suponha que um acesso ausente deva ser concedido automaticamente.
6. Repita os mesmos casos após a mudança. Compare rotas e saídas e registre diferenças intencionais na configuração da equipe que recebe.

As medidas úteis são concretas: com que frequência a solicitação chega ao destino esperado, quanta configuração a passagem exige e se o revisor localiza a falha sem reconstruir toda a execução. Nenhuma delas exige tratar o texto gerado como evidência da própria correção.

Um pacote pode mover a estrutura da aplicação. O destino ainda precisa de suas próprias verificações de acesso e da repetição dos casos que definem um comportamento bem-sucedido.

O que fica mais promissor e o que merece cuidado

A direção animadora é uma unidade de aplicação mais reutilizável. Um fluxo pode conter destinos explícitos, carregar mais recursos de apoio dos agentes e expor mais da execução quando algo dá errado. Essa combinação é útil para equipes que já passaram do prompt isolado, mas não querem que toda aplicação vire um projeto de integração sob medida.

A preocupação correspondente é que a portabilidade espalha erros com a mesma eficiência que boas práticas. Uma definição vaga de rota ou uma ferramenta poderosa demais não se torna adequada por chegar em um pacote organizado. Revise o comportamento importado, não apenas se o arquivo abre corretamente.

Para o Dify, o próximo teste importante é se as equipes conseguem manter essas aplicações diante de mudanças: outro modelo, uma nova Skill, uma política empresarial revisada ou a transferência para outro espaço. Uma primeira importação bem-sucedida anima. Uma atualização controlada que preserva o comportamento pretendido é um sinal mais forte de maturidade.

O Dify 1.18 torna o experimento mais interessante ao conectar decisões de agentes à estrutura visível do fluxo. Comece com um processo pequeno, mantenha as rotas compreensíveis e torne a passagem de trabalho repetível. É assim que uma demonstração promissora começa a se tornar algo que outra equipe pode usar com responsabilidade.

Fontes

• Notas da versão Dify 1.18.0, publicadas em 23 de outubro de 2026, às 06:33 UTC.
• Documentação oficial do Dify, contexto do produto; a disponibilidade da versão deve ser verificada no espaço real.

Quer um lugar pesquisável para notas de fluxos, exemplos de solicitações e decisões por trás de uma revisão? Reúna suas referências no Telli.sh e mantenha a passagem de trabalho compreensível.