Langflow

Olá, daqui é o Alex da DEV STORIES DOT EU. Langflow, episódio 1 de 15. Prototipar uma aplicação de IA geralmente significa construir um mockup visual rápido, provar que a ideia funciona e, de seguida, descartar toda essa UI para escrever o backend de produção do zero. Perdes dias a traduzir conceitos visuais em código de servidor. Este episódio aborda o Paradigma Langflow, um conceito que elimina completamente essa etapa de tradução. O Langflow é um framework desenhado para construir aplicações de IA. Como interages com ele principalmente através de um canvas onde arrastas e largas componentes, é muito fácil confundi-lo com apenas mais uma ferramenta de UI ou um brinquedo low-code. Isso é um equívoco. Presta atenção a esta distinção. O Langflow é um framework de backend Python completo. A interface visual é meramente uma janela para a arquitetura Python subjacente. Cada componente visual que colocas no canvas corresponde diretamente a uma classe Python, e o graph que desenhas traduz-se diretamente em lógica de API de backend. No Langflow, as aplicações que constróis chamam-se flows. Quando abres o workspace, estás essencialmente a construir um Directed Acyclic Graph, ou DAG. Começas por adicionar nodes ao canvas. Cada node representa um bloco distinto de funcionalidade, como um text parser, um data loader ou um módulo de processamento. De seguida, desenhas linhas a ligar os output handles de um node aos input handles de outro. Estas linhas não são apenas decorativas. Elas ditam a dependência de execução de toda a tua aplicação. Se ligares o output de um node de document loader ao input de um node de processamento, o engine subjacente lê isso como uma regra de dependência estrita. Ele sabe que tem de executar o document loader primeiro, esperar pelo resultado e, de seguida, passar esses dados downstream. Os dados fluem estritamente numa direção através do graph, garantindo um caminho previsível e rastreável desde o user input até à resposta final. O framework trata do type checking entre estes handles ligados, garantindo que o output de um node é compatível com o input do seguinte antes mesmo da execução começar. Imagina que estás a construir um flow de prototipagem para uma ferramenta básica de question-answering. No workspace, ligas um node de text input a um node de processamento e, de seguida, encaminhas isso para um node de output. Testas tudo ali mesmo no browser, a ajustar parâmetros até as respostas parecerem corretas. Num workflow tradicional, o passo seguinte é entregar um documento de especificação a um engenheiro de backend para reescrever essa lógica em Python. No paradigma do Langflow, saltas isso completamente. No momento em que o teu flow visual funciona, já é uma API funcional. Basta enviares um request para o run endpoint integrado com o identificador do teu flow e as input variables. O framework percorre o graph exatamente como o desenhaste, executa cada classe Python na ordem correta e retorna a resposta. Fazes a transição de um protótipo visual para um backend Python servido sem escreveres uma única linha de código de configuração de servidor. A identidade central do Langflow é que o mapa visual que desenhas para entender a tua aplicação é exatamente a mesma estrutura que o servidor usa para a executar. Se achas estes episódios úteis e queres apoiar o programa, podes procurar por DevStoriesEU no Patreon. Obrigado por ouvirem, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Langflow, episódio 2 de 15. Ligas dois nodes, corres o teu pipeline, e não acontece absolutamente nada. A ligação parece estar bem, mas a execução falha ou lança um erro enigmático. O problema normalmente tem a ver com a forma como os dados se movem entre os blocos, o que nos leva à arquitetura de componentes e aos data types. É comum assumir-se que os componentes do Langflow passam payloads JSON soltos de um lado para o outro como numa web API standard. Mas não. Cada componente no Langflow é a execução de uma classe Python discreta e estritamente tipada. Um componente contém um internal state, input ports e output ports. Os dados fluem estritamente através destas portas definidas, e essas portas exigem objetos Langflow específicos. Podes seguir estes data types através das cores das portas. Cada porta num componente tem uma cor específica que corresponde ao tipo de dados que aceita ou devolve. Se ligares uma output port a uma input port e as cores coincidirem, os dados fluem sem problemas. Se as cores não coincidirem, estás a tentar passar dados incompatíveis. O componente downstream não vai conseguir fazer o parse do objeto recebido, e o flow vai falhar. Para construíres pipelines fiáveis, precisas de perceber os três data objects principais que viajam através destas ligações. O primeiro é o tipo Message. Um objeto Message é usado para dados conversacionais. Ele carrega o próprio conteúdo de texto juntamente com informação de routing, especificamente o role, que diz ao sistema se o texto teve origem num utilizador, num system prompt ou num modelo de IA. O segundo tipo principal é o objeto Data. Um objeto Data funciona como um wrapper para informação não estruturada. Ele guarda o conteúdo de texto juntamente com um dicionário de metadata. Quando vais buscar documentos a uma vector database, fazes scrape a uma página web, ou lês um ficheiro de texto, essa informação viaja pelo teu flow como um objeto Data estruturado, e não como uma raw string. O dicionário de metadata permite-te passar URLs de origem ou timestamps juntamente com o texto sem quebrar a lógica de processamento downstream. O terceiro tipo é o objeto DataFrame. Este é usado para dados tabulares bidimensionais. Comporta-se de forma muito semelhante a um DataFrame do Pandas, o que faz dele o tipo necessário quando estás a passar ficheiros CSV que sofreram parse, ou linhas e colunas estruturadas, entre componentes analíticos. Como as portas são estritamente tipadas, vais encontrar frequentemente situações em que tens um data type, mas o componente seguinte exige outro. Imagina o cenário de pegares numa raw text string de um bloco básico de execução Python e precisares de a passar para um componente de processamento de texto que exige explicitamente um objeto Data estruturado. As cores das portas não vão coincidir. Não podes forçar uma raw string numa porta Data. Para colmatar esta falha, usas um componente Type Convert. Colocas o bloco Type Convert entre os dois componentes incompatíveis. Primeiro, ligas o output da string ao input do bloco Type Convert. A seguir, ligas o seu output à porta Data do teu componente de processamento downstream. O bloco Type Convert pega na raw string, faz o wrap para um objeto Data adequado com um dicionário de metadata vazio, e passa-o em segurança para o node seguinte. Perceber a tipagem estrita destas portas é a diferença entre um flow que funciona e um flow que está constantemente a falhar. Se um pipeline falhar silenciosamente, não faças debug à tua lógica primeiro; verifica as cores das portas para garantires que os teus componentes estão realmente a falar a mesma linguagem de dados. Obrigado por ouvirem. Fiquem bem, pessoal.

Olá, daqui fala o Alex da DEV STORIES DOT EU. Langflow, episódio 3 de 15. Uma simples mensagem de chat parece apenas uma string de texto, mas se isso fosse verdade, a tua aplicação perderia o rasto de quem disse o quê no momento em que um segundo utilizador se ligasse. Resolver esse problema de routing é exatamente o que vamos abordar hoje: a interação com o graph usando o Chat Input e o Chat Output. Quando constróis um flow, o ponto de entrada é tipicamente um componente Chat Input. Os developers frequentemente confundem isto com uma caixa de texto básica que reencaminha cegamente uma string para o node seguinte. Esse é um modelo mental incorreto. O componente Chat Input atua como uma fábrica de dados estruturados. A sua função principal é intercetar o texto bruto da interface de utilizador e encapsulá-lo num tipo de dados específico chamado objeto Message. O objeto Message é a moeda fundamental para o texto que se move através de um graph do Langflow. Em vez de passar strings nuas, o graph encaminha este pacote padronizado. Dentro do objeto, as palavras exatas digitadas pelo utilizador ficam num campo de texto central. A envolver esse texto, há uma camada de metadados. O objeto contém um campo sender, que categoriza a origem como User ou Machine. Inclui um sender name, que controla a etiqueta visual apresentada no frontend. Também regista a hora exata de criação num campo timestamp. Estes metadados tornam-se cruciais ao lidar com utilizadores simultâneos. Considera um cenário em que um utilizador faz uma pergunta numa aplicação em deploy. O componente Chat Input captura o texto, empacota-o num objeto Message, define o sender como User e anexa um session ID único. Este session ID é o mecanismo que segue uma thread de conversa específica. À medida que o objeto Message percorre o graph, passando por retrievers ou nodes de processamento, esse session ID permanece anexado. As ferramentas de state management e os componentes de memory dependem inteiramente deste ID para agrupar interações. Sem ele, o graph não teria como isolar o contexto de um utilizador do de outro. Também tens controlo sobre a visibilidade deste input. O componente Chat Input pode ser configurado para ocultar o seu conteúdo da interface principal de chat. Isto é útil ao passar parâmetros de sistema default ou instruções de background que o utilizador nunca precisa de ver, enquanto continuas a injetar um objeto Message válido no graph. No lado oposto do flow, encontra-se o componente Chat Output. Este é o node terminal que apresenta os dados de volta à interface de utilizador. Ele captura o objeto Message final produzido pela tua lógica. Como recebe um objeto totalmente formado, o componente Chat Output lê os campos sender e sender name para renderizar a interface com precisão, tipicamente exibindo a resposta como vinda da Machine. Se, por acaso, um node anterior passar texto bruto para o Chat Output em vez de um objeto Message, o componente corrige isso automaticamente. Ele encapsula a string bruta num novo objeto Message antes de a exibir, garantindo uma consistência rigorosa dos dados nas fronteiras do teu graph. Os componentes Chat Input e Chat Output não são elementos cosméticos da interface; eles são os controladores de fronteira da tua aplicação, garantindo que cada pedaço de texto seja devidamente encapsulado num objeto Message com tracking antes de poder avançar. Obrigado por estares aí. Espero que tenhas aprendido algo novo.

Olá, daqui fala o Alex da DEV STORIES DOT EU. Langflow, episódio 4 de 15. Decides mudar a tua aplicação de um model provider para outro a meio do projeto. Normalmente, isto significa andar à caça de cada API call, reescrever configuration objects e esperar que não tenhas partido a prompt chain inteira. Uma arquitetura adequada transforma isto numa transição perfeita. O componente Language Model no Langflow fornece a abstração que torna isto possível. Quando os developers começam a construir flows, muitas vezes esperam simplesmente largar um model node no canvas e colar imediatamente a sua API key diretamente nas component settings. Não faças isso. O Langflow foi concebido para lidar com a autenticação globalmente através do painel Model Providers. Configuras as tuas credenciais, como as tuas keys da OpenAI ou da Anthropic, exatamente uma vez nas global settings. Os model components individuais no teu canvas atuam como referências a essas global settings. O próprio node lida com o comportamento local, controlando coisas como o system prompt, o limite máximo de tokens ou a definição de temperature. O global provider lida com a ligação segura. Esta separação entre autenticação e lógica de execução torna-se crucial quando queres experimentar. Imagina que tens uma prompt chain complexa a alimentar um model component da OpenAI. Queres ver se um modelo da Anthropic produz melhores resultados. Graças à abstração global, basta arrastares o novo componente da Anthropic para o canvas. Ligas a tua prompt sequence existente ao seu input. Defines a temperature desejada no novo node. O global provider lida automaticamente com a autorização em background, com base nas tuas keys guardadas. Apagas o node antigo, e o teu flow fica imediatamente pronto para testar. Nada na tua prompt chain se parte. Isto cobre a forma como o componente é configurado. Agora, repara em como ele passa os dados para a frente. O componente Language Model oferece duas capacidades de output, dependendo do que o resto do teu flow realmente exige. Por defeito, o componente emite uma Model Response. Envias-lhe um prompt, o modelo processa-o, e o componente devolve uma text string. Este é o comportamento standard que usas quando constróis um chatbot básico ou uma ferramenta de resumo. O node recebe um request, gera a resposta, e passa essa resposta finalizada para a frente. No entanto, às vezes, um downstream component não precisa da resposta. Precisa do engine. Podes alterar o comportamento do output port, mudando-o de emitir uma Message response para emitir uma LanguageModel instance. Quando fazes isto, o componente deixa de avaliar o prompt e de enviar texto. Em vez disso, ele empacota o próprio modelo configurado, juntamente com as suas credenciais de provider e definições de temperature, e passa esse objeto para o próximo node. Isto é essencial para arquiteturas mais avançadas. Se ligares o teu setup a uma retrieval chain complexa, essa chain precisa de executar as suas próprias queries internas para pesquisar numa base de dados com base no histórico de conversação. Não consegue fazer isso se lhe entregares apenas uma text response estática. Precisa de um live engine para executar as suas próprias tarefas de geração de texto. Ao passares a LanguageModel instance, entregas ao downstream node uma ferramenta totalmente configurada que ele pode usar repetidamente para gerar os prompts específicos de que precisa. O componente não é apenas uma API call hardcoded. É um container flexível que separa as tuas credenciais da tua lógica, permitindo-te escolher se a tua aplicação precisa de uma resposta finalizada ou de um execution engine. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Langflow, episódio 5 de 15. O que diferencia um chatbot estático de um verdadeiro motor de raciocínio? A capacidade de decidir os seus próprios próximos passos. Se o teu flow depende inteiramente de prompt chains hardcoded, vai falhar no momento em que um utilizador fizer uma pergunta de seguimento inesperada. É aí que entram os Intelligent Execution Engines, especificamente o componente Agent. Muitos developers colocam um node de Language Model normal no canvas e esperam que ele se comporte como um assistente inteligente e context-aware. Mas não funciona assim. Um node de Language Model standard é essencialmente uma calculadora de text-in, text-out. Passas-lhe uma string, e ele devolve uma string baseada puramente nesse único input. Um componente Agent é fundamentalmente diferente. É um motor de raciocínio autónomo. Em vez de simplesmente executar um único prompt, um Agent avalia o contexto atual, decide uma sequência de ações e determina os seus próprios passos de execução para atingir um objetivo. Quando um utilizador envia uma mensagem para um Agent, o componente não gera imediatamente a resposta final. Entra num loop de raciocínio interno. Olha para o input, verifica o seu state interno e formula um plano. Esta fase de planeamento permite que o Agent estruture respostas complexas ou perceba que precisa de avaliar interações passadas antes de prosseguir. Isto leva-nos às capacidades de memória built-in do componente Agent. Um node de Language Model standard sofre de amnésia. Cada request é uma folha em branco. Se um utilizador perguntar qual é a capital de França, e logo a seguir perguntar qual é a população de lá, um node standard não vai saber o que a palavra lá significa. Terias de construir manualmente um sistema para capturar, armazenar, formatar e injetar o histórico de chat anterior em cada novo prompt. O componente Agent resolve isto nativamente. Mantém automaticamente uma context window contínua das perguntas anteriores do utilizador e das respostas anteriores do sistema. Quando essa segunda pergunta sobre a população chega, o Agent interceta o request. Antes de gerar uma resposta, consulta a sua memória built-in. Recupera o contexto da primeira pergunta, junta o histórico da conversa e deduz que o local em questão é Paris. Executa esta avaliação contextual de forma totalmente autónoma. Não precisas de ligar nodes de memória separados, fazer parse de strings de histórico, ou construir loops complexos de injeção de histórico no teu canvas. O Agent lida internamente com a natureza stateful da conversa. Decide quando consultar o histórico, quanto dele é relevante para a query atual, e como usar esse contexto histórico para moldar o seu próximo output. Esta mudança altera a forma como desenhas os flows. Já não estás a mapear cada branch possível de uma conversa. Estás a fornecer a um motor inteligente os parâmetros de que ele precisa para gerir a própria conversa. O componente assume o peso do state management e da resolução de contexto. O verdadeiro poder do componente Agent reside nesta autonomia. Ao passares de language models estáticos para um Agent, delegas o control flow ao próprio motor. O sistema deixa de ser um pipeline rígido, e passa a ser uma entidade dinâmica capaz de manter o state, lembrar-se de interações passadas e adaptar o seu raciocínio para corresponder à intenção do utilizador on the fly. Gostava de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Tem um ótimo dia!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Langflow, episódio 6 de 15. Podes pensar que construir uma tool para um agent exige escrever wrappers Python personalizados ou procurar numa library por tool nodes especializados. Não é o caso. Quase qualquer componente já presente no teu canvas pode ser convertido numa funcionalidade ativa com um único clique. Hoje, vamos ver como equipar agents com o Tool Mode. Um equívoco comum é achares que precisas de tool components dedicados e hard-coded para alimentar um agent. No Langflow, o Tool Mode é uma feature integrada diretamente nos standard nodes. Quer estejas a trabalhar com um API caller, um database retriever ou um text processing node, podes mudá-lo para Tool Mode. Ao ativares este toggle num componente, a sua interface muda. As standard output ports que normalmente encaminharias para o passo seguinte de uma chain linear desaparecem. Em vez disso, o componente expõe uma única Tool output port. Pegas nessa nova Tool output e ligas diretamente à Tools input port de um componente Agent. Um passo de processamento inerte é agora um utilitário funcional que o agent pode invocar a pedido. Transformar o componente numa tool é apenas o passo mecânico. O agent ainda precisa de saber como a usar. Quando ativas o Tool Mode, aparece um botão com o rótulo Edit Action no node. Clicar nele revela três campos de configuração. O primeiro campo é o Slug. Este é um identificador machine-readable, geralmente formatado com underscores em vez de espaços. O segundo é o Name, que é um título human-readable standard. O terceiro campo é a Description. Esta é a parte que interessa. O campo Description não é documentação para o developer. É o text prompt literal que o Large Language Model lê para determinar se deve acionar esta tool específica. Se a tua description for vaga, o agent vai tentar adivinhar quando a usar, levando a um comportamento imprevisível e ao desperdício de tokens. Pega num componente de Web Search como exemplo. Normalmente, ele apenas recebe uma string e devolve resultados de pesquisa. Se ativares o Tool Mode neste node, ele torna-se numa tool do agent. Agora, abres o menu Edit Action. Se escreveres uma description genérica como pesquisa na web, o agent pode acionar uma pesquisa para perguntas factuais básicas que já tem nos seus dados de treino. Em vez disso, escreves uma description altamente restritiva. Defines condições exatas. Escreves, usa esta tool exclusivamente para pesquisar notícias de última hora, eventos atuais ou a meteorologia em tempo real. O agent faz parse a essa frase exata durante o seu ciclo de raciocínio. Ele avalia o prompt em relação à tua description, garantindo que o node de Web Search só dispara quando o user pergunta sobre notícias recentes. Podes escalar isto ao ativar o Tool Mode em vários componentes diferentes. Basta ligares todas as suas Tool output ports à única Tools input no node do agent. O agent revê as descriptions de cada tool ligada, seleciona a correta, executa-a e sintetiza os dados devolvidos para formular a sua resposta final. A lógica subjacente do node é totalmente invisível para o agent. A única coisa que controla a tomada de decisão do teu agent é a precisão das tuas tool descriptions. Obrigado por ouvirem. Até à próxima!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Langflow, episódio 7 de 15. Forçar um único modelo de linguagem a lidar com routing básico e análise de dados pesada ao mesmo tempo, geralmente resulta em respostas lentas e faturas de API elevadas. A solução é dividir a carga cognitiva, e é aí que entram as composições multi-agent. Muitas pessoas veem os flows do Langflow estritamente como endpoints isolados. Chamas uma API, recebes uma resposta e a execução termina. Isso é uma ideia errada. Os flows não são apenas aplicações top-level; podem ser embedded de forma hierárquica. Considera um sistema para fazer o parsing de pedidos dos utilizadores. Configuras um agente de routing primário usando um modelo rápido e barato. A sua única função é descobrir o que o utilizador quer. Quando um utilizador pede para analisar um relatório financeiro enorme, o agente primário não processa o documento em si. Em vez disso, ligas um agente secundário diretamente ao tool input do agente primário. Este agente secundário corre um modelo completamente diferente, com uma context window muito maior, especializado especificamente na extração de dados. O routing depende inteiramente da tool description. Quando ligas o agente secundário, tens de fornecer uma descrição textual clara do que ele faz. O agente primário lê esta descrição juntamente com o prompt do utilizador. Quando um pedido corresponde à descrição, o agente primário interrompe a sua própria geração, empacota o contexto relevante e invoca o agente secundário. Para o agente primário, este setup secundário complexo parece uma única função. O agente secundário executa o seu próprio reasoning loop, processa o documento extenso e devolve o texto final ao agente primário, que depois responde ao utilizador. Podes levar esta abstração ainda mais longe usando um flow inteiro como uma tool. Podes criar um flow sofisticado que faz o scraping de um site, extrai texto, o formata e avalia o output. Depois de construído, guardas-o. Num projeto completamente diferente, arrastas um componente Flow Tool para o canvas e selecionas o teu flow guardado. Ao trazer um flow para outro workspace, defines componentes de input e output específicos dentro desse child flow. O parent agent mapeia os seus tool arguments diretamente para esses inputs definidos. Ele executa o child flow, espera que o componente de output final faça trigger, e puxa o texto resultante de volta pela chain. O Langflow é construído sobre uma arquitetura de graph baseada em nodes. Devido a esta estrutura, o engine permite composição recursiva. Um graph inteiro pode ser encapsulado e tratado como um único node dentro de um graph maior. O agente primário não tem consciência da complexidade nested. Ele apenas vê uma tool chamada scrape_and_evaluate que recebe um URL e devolve um resumo. O poder da composição multi-agent é a abstração. Permite-te esconder reasoning loops complexos e de vários passos atrás de uma única tool call, mantendo a tua lógica de routing primária limpa e previsível. Se quiseres apoiar o programa, podes encontrar-nos pesquisando por DevStoriesEU no Patreon. Obrigado por ouvirem. Fiquem bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. Langflow, episódio 8 de 15. Os dias de escrever API wrappers personalizados para cada nova fonte de dados acabaram. Já não precisas de mapear endpoints manualmente, formatar headers e fazer parse de raw JSON só para permitir que um agent leia uma webpage ou consulte uma base de dados local. Essa fricção é eliminada pelo Model Context Protocol Client. As pessoas costumam confundir isto com integrações standard de REST API. Não é um node genérico de HTTP request onde tu próprio configuras o payload. O Model Context Protocol, ou MCP, é um standard aberto desenhado especificamente para entregar contexto e funções executáveis a modelos de IA. É uma linguagem universal para uso de tools. Nesta arquitetura, o Langflow opera como o MCP Client. Ele liga-se a um MCP Server externo, pergunta que capacidades esse server oferece, e expõe-nas. Consegues isto usando o componente MCP Tools. Largas este componente no teu canvas e ligas o seu output diretamente ao input de tools de um componente Agent. Quando a ligação é estabelecida, o Langflow recebe um schema rigoroso que define as tools, as suas descrições e os seus parâmetros obrigatórios. Ele traduz isto para native tools automaticamente. O agent sabe inerentemente e de forma exata como formatar os dados e fazer trigger das funções externas. Para fazer esta ligação, selecionas um método de transport. O componente MCP Tools suporta duas opções: HTTP via Server-Sent Events, e STDIO. HTTP é a escolha certa para remote servers a correr de forma segura noutra máquina. Basta fornecer o URL do endpoint. STDIO é usado quando queres que o Langflow execute um processo local e comunique através de streams de standard input e output. Vejamos um cenário concreto usando STDIO. Imagina que queres que o teu agent resuma notícias de tecnologia diretamente de URLs externos. Podes usar uma tool pré-construída chamada fetch MCP server. No teu componente MCP Tools, define o transport para STDIO. Define o teu command para uvx, uma tool de Python que faz o download e corre packages em ambientes isolados. Para o campo de arguments, insere mcp dash server dash fetch. Liga o output do componente ao teu agent. Quando fazes um prompt ao agent para resumir um artigo específico, o agent chama nativamente a fetch tool. Ele faz stream do URL de destino através de STDIO para o background process isolado, lê o texto retornado da webpage, e gera o teu resumo. Não escreveste absolutamente nenhum código para fazer esta integração acontecer. Muitas tools exigem autenticação, como uma password de base de dados ou uma API key privada. O componente MCP Tools inclui um campo de Environment Variables que aceita um dictionary de pares key-value. Se interagires com o teu graph do Langflow de forma programática via API, podes injetar estas credenciais dinamicamente usando o dictionary de tweaks. Basta fazeres target ao ID do componente MCP Tools e passar as environment variables de forma segura no payload do teu request. A vantagem definidora do MCP Client é o decoupling total. Fazes o deploy de uma capacidade externa uma vez, em qualquer linguagem de programação, e dás instantaneamente a qualquer agent do Langflow acesso nativo a ela sem nunca alterar a lógica do graph. Obrigado por ouvires — até à próxima.

Olá, daqui é o Alex da DEV STORIES DOT EU. Langflow, episódio 9 de 15. Escreves um pipeline de IA personalizado e queres que o teu editor de código o execute nativamente como uma tool integrada. Fazes uma pergunta ao teu IDE e ele aciona, sem problemas, o sistema complexo de retrieval que construíste ontem. Expor flows como MCP Servers torna isso possível. Primeiro, precisamos de esclarecer o que é realmente um MCP server. Os ouvintes às vezes confundem isto com um endpoint de deploy standard usado para suportar uma aplicação web. Não é nada disso. O Model Context Protocol, ou MCP, é uma forma standard de fornecer capacidades diretamente a outros agentes de IA. Um endpoint standard fornece dados a uma user interface. Um MCP server fornece tools a um reasoning engine. O Langflow permite-te transformar automaticamente qualquer projeto num MCP server. Quando fazes isto, todo o teu flow é empacotado como uma tool executável. Para comunicar com clientes externos, o Langflow usa um mecanismo de transporte HTTP streamable, recorrendo especificamente a Server-Sent Events. Isto significa que o teu cliente externo se liga através de protocolos web standard e pode receber respostas em streaming diretamente do teu flow, sem precisar de configurações complexas de rede local. A configuração técnica é simples, mas há um requisito absoluto que tens de fazer bem. Tens de definir o nome e a descrição da tool. Quando um agente externo se liga ao teu MCP server do Langflow, ele pede uma lista de tools disponíveis. O agente usa as descrições fornecidas para decidir qual tool chamar e quando a chamar. Se deixares a descrição default ou escreveres algo vago, o agente externo vai ignorá-la. Tens de escrever a descrição como uma instrução precisa para o agente de IA. Estás efetivamente a fazer um prompt ao sistema externo sobre como usar o teu flow. Vamos ver um cenário específico. Constróis um flow de Document QA no Langflow que pesquisa um documento interno de arquitetura da empresa. Queres que o teu agente local do editor Cursor faça queries a este documento nativamente. Expões o flow como um MCP server. Dás o nome de query company architecture à tool e defines a descrição para indicar que ela pesquisa o documento interno de arquitetura da empresa para responder a perguntas técnicas sobre serviços de backend. A seguir, configuras o Cursor para se ligar ao teu URL do Langflow MCP. Agora, estás a escrever código no Cursor e perguntas ao agente como funciona o sistema de autenticação. O Cursor verifica os seus MCP servers ligados, lê a tua descrição específica e percebe que a tua tool do Langflow é exatamente o que ele precisa. O Cursor passa a tua pergunta como um argumento para a tool. O Langflow recebe o request através do transporte HTTP, corre todo o flow de Document QA e faz stream da resposta de volta para o teu editor. O teu IDE acabou de utilizar um projeto complexo de Langflow como uma função nativa. O sucesso de uma integração MCP depende inteiramente da qualidade do prompt que escondes dentro da descrição da tool. Se o agente externo não conseguir entender a descrição, a tua tool efetivamente não existe. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Langflow, episódio 10 de 15. Se dois utilizadores falarem com a tua aplicação de IA exatamente ao mesmo tempo, como é que o sistema evita dar as respostas de um utilizador ao outro? A resposta está na forma como isolas as threads, e é exatamente isso que a gestão de state e session faz. Primeiro, vamos esclarecer um ponto de confusão muito comum. Precisamos de traçar uma linha clara entre chat memory e vector memory. A vector memory envolve guardar documentos como embeddings e recuperá-los com base no significado. Não vamos abordar isso aqui. A chat memory é simplesmente o registo linear e cronológico de uma conversa. É o mecanismo que permite ao modelo de linguagem lembrar-se do que o utilizador disse há três mensagens atrás. Por defeito, o Langflow guarda este histórico linear de mensagens localmente usando uma base de dados SQLite. Sempre que uma mensagem passa pelo sistema, é registada. Mas uma base de dados cheia de mensagens é inútil se o sistema não souber a quem pertence cada mensagem. É aqui que entra o session ID. O session ID é uma string única que liga uma sequência de interações. Quando usas a interface do Langflow, o sistema gera automaticamente um session ID para ti nos bastidores. Em produção, provavelmente vais interagir com o Langflow através da sua API. Se tiveres dois utilizadores distintos a interagir com o teu servidor em simultâneo, tens de passar um session ID específico para cada um no teu request à API. Uma prática standard é usar o user ID único da tua própria base de dados como o session ID do Langflow. Quando o teu primeiro utilizador envia uma mensagem, passas o ID específico dele. O Langflow consulta a base de dados SQLite à procura dessa string exata, vai buscar apenas o histórico desse utilizador, anexa-o ao prompt e gera uma resposta. Quando o teu segundo utilizador interage um milissegundo depois com o seu próprio ID, o Langflow executa exatamente o mesmo processo em completo isolamento. Se não passares um session ID na tua API call, o Langflow trata a interação como um evento totalmente novo. O contexto perde-se completamente. Para manter a thread, a tua aplicação externa tem de enviar esse identificador em cada request. A forma como expões este histórico ao modelo de linguagem depende inteiramente dos componentes que escolheres. O Langflow oferece duas abordagens distintas. Se estiveres a usar um componente Agent standard, a gestão de memória já está integrada. O Agent lida automaticamente com a leitura e escrita na base de dados SQLite usando o session ID ativo. Não precisas de configurar nada extra para que ele se lembre da conversa. Os Agents são altamente abstraídos, portanto, se estiveres a construir uma chain personalizada do zero usando componentes base e raw prompts, essa memória integrada não existe. É aqui que usas o componente dedicado Message History. Colocas este componente no teu flow e ligas o seu output a uma variável no teu componente Prompt. Quando o flow corre, o componente Message History agarra no session ID ativo, vai buscar o registo cronológico relevante à base de dados e formata-o como texto. Isto passa fisicamente o diálogo guardado para a context window antes mesmo de o modelo de linguagem o ver. Controlar o session ID ao nível da API é o requisito mais crítico para escalar uma interface conversacional, porque vincular o state estritamente a um identificador passado garante um isolamento completo para qualquer número de utilizadores em simultâneo. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Langflow, episódio 11 de 15. O maior erro que os developers cometem ao construir Retrieval Augmented Generation é combinar a indexação lenta de dados e o chat retrieval em tempo real num único pipeline. Cada vez que o utilizador faz uma pergunta, o sistema tenta reler um PDF de cem páginas. A solução é fazer o grounding do LLM com Vector Stores usando uma arquitetura desacoplada. É incrivelmente comum ligares todos os teus componentes num único canvas. Ligas um file loader a um text splitter, passas isso para um embedding model, colocas num vector store e ligas diretamente a uma interface de chat. Isso cria um bottleneck enorme. A ingestão de dados e o chat retrieval são eventos de lifecycle completamente diferentes. Não devem viver no mesmo execution path. A arquitetura RAG standard no Langflow separa este processo em dois flows distintos. Primeiro, tens o subflow de ingestão. É aqui que as operações pesadas acontecem. Pegas nos teus documentos de origem, como ficheiros PDF grandes, e passas tudo por um document loader. Um text splitter depois divide os documentos em pedaços mais pequenos. Ao configurares o teu text splitter, tens de ajustar o tamanho dos teus chunks aos limites máximos de tokens do embedding model escolhido. Se o tamanho do chunk exceder esse limite, o embedding model vai truncar o texto silenciosamente. As frases finais são ignoradas, e esses dados em falta nunca vão chegar à tua vector database. Assim que o texto estiver devidamente dividido em chunks, passas isso para um componente de embedding para gerar os vetores. Finalmente, esses vetores são guardados numa collection específica dentro do teu componente de vector store. Todo este flow de ingestão é executado quando os dados mudam, de forma completamente independente da user interface. Agora, a segunda parte desta arquitetura é o retrieval flow. Esta é a parte conversacional virada para o utilizador. Como a indexação pesada já foi feita noutro lado, este flow mantém-se rápido e responsivo. Começa com um chat input a capturar a pergunta do utilizador. Essa pergunta é passada para um componente de embedding. Tens de configurar este componente para usar exatamente o mesmo embedding model que usaste durante a fase de ingestão. Se indexares dados com um modelo e fizeres uma query com outro diferente, a vector store não vai conseguir encontrar nenhuma correspondência relevante. O componente de vector store neste flow está configurado para pesquisar exatamente a mesma database collection que preencheste anteriormente. Ele pega na pergunta do utilizador com o embedding, faz uma similarity search contra os dados pré-carregados e devolve os chunks de texto mais relevantes. A seguir, encaminhas esses chunks recuperados, juntamente com a pergunta original do utilizador, para um componente de prompt template. Esse prompt enriquecido é finalmente enviado para o language model, que formula a resposta. Ao dividires a tua implementação RAG num write flow assíncrono para documentos e num read flow rápido para o chat, proteges a tua interface de chat contra atrasos no processamento de backend. A regra de ouro da arquitetura RAG é que uma query do utilizador deve apenas fazer trigger a uma pesquisa, nunca a um indexing job. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Langflow, episódio 12 de 15. A programação visual leva-te a noventa por cento do caminho, mas inevitavelmente, bates numa parede. Precisas de correr business logic proprietária ou de te ligares a uma API interna customizada, e os nodes pré-construídos simplesmente não dão conta do recado. Estender o engine via Python desbloqueia esses dez por cento finais de controlo absoluto. É fácil pensar que um custom component é apenas um script Python standard que largas numa diretoria. Não é. Um custom component requer uma configuração rigorosa ao nível da classe. Sem esta estrutura específica, o engine do Langflow não faz ideia de como renderizar o teu node no editor visual ou como ligar os seus dados ao graph de execução. O node visual e a lógica de backend estão intimamente ligados. Para construíres um custom component, começas sempre por criar uma subclasse da classe base Component fornecida pelo Langflow. Dentro desta nova classe, não escreves um método de inicialização standard para recolher variáveis. Em vez disso, defines dois arrays rigorosos: inputs e outputs. Vamos olhar para um cenário prático. Supõe que estás a construir um custom component Text Analyzer que calcula a contagem de palavras e devolve um objeto Data estruturado ao graph. Primeiro, configuras o array de inputs. Preenches este array usando classes de input especializadas fornecidas pelo Langflow. Para o Text Analyzer, precisas de uma string de texto, então colocas um objeto de text input no array e dás-lhe um nome. Esta é a parte que interessa. Ao declarares uma classe de input específica no teu código Python, estás a ditar a interface visual. O Langflow lê esse array e gera automaticamente um campo de texto no teu node, no editor drag-and-drop. Se adicionasses um objeto de integer input a esse mesmo array, a UI renderizaria instantaneamente um number spinner. Defines os requisitos de dados em código, e o engine constrói a UI para ti. Assim que os inputs estiverem definidos, configuras o array de outputs. Isto diz explicitamente ao graph à sua volta que tipo de dados o teu node vai produzir. Para o Text Analyzer, queremos passar o nosso resultado para a frente na chain, então adicionas um objeto de Data output ao array. A configuração de output faz mais uma coisa crítica. Mapeia o visual output handle para um método de execução principal dentro da tua classe. Estás a dizer explicitamente ao engine qual a função Python a correr quando o próximo node pedir dados. O passo final é escrever esse método de execução mapeado. É aqui que vive a tua lógica Python standard. O método recebe automaticamente os valores que os teus inputs recolheram da UI. Pegas na string de texto recebida, fazes o split e contas as palavras. Depois, como o graph espera um formato standard, encapsulas o teu integer final dentro de um objeto Data do Langflow e devolves. A estrutura força uma separação limpa. O array de inputs constrói a interface e recolhe os dados, o método de execução processa-os, e o array de outputs devolve-os ao graph visual. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. Langflow, episódio 13 de 15. Podes pensar num node como uma simples caixa preta onde os dados entram, uma função é executada, os dados saem e o node esquece instantaneamente tudo. Mas o que acontece quando a tua pipeline exige que um node inicialize uma ligação complexa a uma base de dados ou rastreie quantos itens acabou de processar antes de devolver um resultado? Isso exige ir além de funções simples e usar hooks e execução avançada de componentes. Uma suposição comum é que os componentes são operações estritamente stateless que apenas avaliam inputs. Não são. Um componente é uma instância de uma classe Python e passa por um lifecycle específico gerido pelo engine de execução interno. Durante este lifecycle, o componente pode manter um state interno, orquestrar setups complexos e partilhar dados entre os seus próprios métodos internos. Quando o Langflow aciona um componente, o engine inicia uma sequência rigorosa. Primeiro, antes de começar qualquer geração de output, o engine procura por um hook interno chamado pre run setup. Tu fazes override a este método quando o teu componente precisa de fazer o trabalho pesado antes da lógica principal arrancar. Se o teu componente precisar de se autenticar numa API externa, carregar um modelo de machine learning grande para a memória ou configurar variáveis locais, tu colocas essa lógica dentro do setup hook. Assim que o setup estiver concluído, o engine passa para a fase de execução chamando o run hook. É aqui que reside o teu payload principal e onde o verdadeiro processamento de dados acontece. Separar a lógica de setup da lógica de execução mantém o teu código organizado e evita operações redundantes. Mas isto levanta uma questão mecânica imediata. Como é que passas um cliente de API autenticado ou uma variável local do setup hook para o run hook? Usas o dicionário de context. Todos os componentes customizados têm um atributo chamado self dot ctx. Este é um dicionário anexado diretamente à instância do componente. Atua como um banco de memória dedicado durante a execução desse componente específico. Qualquer coisa que anexes a este dicionário de context durante a fase de setup fica imediatamente disponível quando o engine transita para a fase de run. Vamos analisar um cenário prático onde esta partilha de state é necessária. Considera um componente customizado que processa uma stream de documentos recebidos e precisa de fazer output tanto do texto limpo como da contagem final de quantos documentos foram modificados com sucesso. Primeiro, fazes override ao hook de pre run setup. Dentro deste método, acedes ao dicionário de context e crias uma variável de contador, definindo o seu valor inicial a zero. Também podes inicializar a tua library de limpeza de texto aqui e associá-la ao context. De seguida, o engine aciona o run hook. O teu método faz um loop pelos documentos recebidos. Para cada documento que passa com sucesso pela library de limpeza, acedes ao dicionário de context, recuperas o valor atual do contador e incrementas em um. Como o dicionário de context persiste entre estas chamadas distintas de métodos do lifecycle, o teu componente mantém o seu state interno em segurança. Quando o run hook finalmente completa o seu loop, pode retornar os documentos processados e extrair a contagem final exata diretamente do dicionário de context para passar ao próximo node. Dominar o engine de execução e os hooks de componentes muda a tua mentalidade de escrever simples scripts pass-through para construir aplicações robustas e autocontidas que gerem completamente os seus próprios lifecycles de dados. Se quiseres ajudar a manter o programa no ar, podes procurar por DevStoriesEU no Patreon. Como sempre, obrigado por ouvires. Até ao próximo episódio.

Olá, daqui é o Alex da DEV STORIES DOT EU. Langflow, episódio 14 de 15. Tens cinquenta clientes, e todos eles precisam de uma versão ligeiramente diferente do teu agente de suporte de IA. O instinto é duplicar o teu graph cinquenta vezes, trocando o system prompt ou a API key em cada um. Isso é um pesadelo de manutenção. Só precisas de um graph, e podes lidar com a variação on the fly usando a API do Langflow e Tweaks dinâmicos. Quando constróis um graph na interface visual, os parâmetros dentro dos teus componentes são fixos. É fácil assumir que, para alterar uma variável menor, como uma configuração de temperature ou uma instrução de sistema, tens de clonar o flow inteiro. Isso não é verdade. Os Tweaks resolvem isto dinamicamente em runtime, permitindo-te fazer override dos parâmetros dos componentes sem editar o graph subjacente. Fazes isto interagindo com o Langflow de forma totalmente headless através da sua REST API. Para executar um flow programaticamente, envias um HTTP POST request para o run endpoint, especificamente barra v um barra run, seguido pelo teu flow ID único. O body deste request contém os teus inputs padrão, como a mensagem de texto do utilizador. Juntamente com esses dados de input, podes incluir um objeto tweaks. Este objeto é um dictionary que mapeia componentes específicos no teu graph para os novos valores que queres injetar para essa execução única. Para selecionares um componente, precisas do seu node ID. No Langflow, um node ID normalmente consiste no nome do componente e numa string aleatória, como Prompt hífen a b c d e. Quando constróis o teu tweaks payload, usas este node ID exato como a key. O value é outro dictionary contendo os campos específicos aos quais queres fazer override. Considera um flow básico de suporte ao cliente usado em vários sites. O graph contém um componente Prompt que define como o agente se comporta. Para o teu cliente bancário, o prompt deve ser altamente formal. Para o teu cliente de gaming, precisa de ser casual. Em vez de manter dois graphs idênticos, o teu servidor backend faz uma API call para exatamente o mesmo flow ID. No request payload, especificas o node ID desse componente Prompt. Lá dentro, selecionas o campo template e passas as instruções formais para o banco. Mais tarde, quando o site de gaming faz trigger de uma chamada, o teu backend envia exatamente o mesmo request, mas troca a string no tweaks dictionary para as instruções casuais. A lógica de execução é totalmente sequencial. Primeiro, preparas o teu payload com a user query e o teu tweaks dictionary específico. A seguir, envias o POST request para o run endpoint. O Langflow recebe a chamada, aplica temporariamente os teus overrides aos nodes alvo, e executa o graph. Ele devolve o output final para a tua aplicação, enquanto o flow original guardado no servidor permanece intacto. Não estás limitado a text prompts. Podes fazer tweak de quase tudo o que está exposto num input schema de um componente. Podes trocar dinamicamente o nome do model, ajustar a temperature, ou injetar credenciais de base de dados diferentes por request. Isto transforma um graph visual estático numa função de backend reutilizável e altamente flexível. A capacidade de separar a lógica da tua aplicação dos teus dados de configuração é o que faz com que a execução headless realmente escale em produção. Obrigado por ouvires. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. Langflow, episódio 15 de 15. O editor visual é excelente para construíres a tua aplicação. Mas se fizeres o deploy dessa mesma interface drag-and-drop para os teus servidores live, estás a consumir imensa memória e a deixar a lógica da tua aplicação exposta. Quando chega a hora do tráfego de produção, queres um container de backend leve e headless. É exatamente isso que vamos abordar hoje com a Containerização em Produção. É incrivelmente comum ver equipas terminarem de construir um flow e simplesmente fazerem o deploy de toda a aplicação Langflow, user interface e tudo mais, para um servidor cloud. A interface é estritamente para desenvolvimento. Num ambiente de produção, não queres ninguém a fazer drag-and-drop de nodes. Queres uma API imutável e segura que apenas processe requests. O Langflow oferece um modo específico para lidar com esta transição. Quando inicias o serviço, usas uma flag de comando chamada backend-only. Isto diz ao Langflow para desativar completamente o frontend em React. O servidor arranca na mesma, mas apenas expõe os endpoints da API necessários para correr os teus flows. Isto reduz drasticamente o consumo de memória. Também reforça a segurança ao reduzir a superfície de ataque, garantindo que ninguém consegue aceder visualmente ou alterar a estrutura da aplicação. Para empacotar isto para deploy, escreves um Dockerfile. Começas com uma imagem base standard de Python. Como o Langflow depende de tooling moderno de Python, geres os teus packages fazendo lock das tuas dependências com o UV. Antes de fazeres a build da imagem, exportas a tua árvore de dependências exata para um lockfile. Dentro do Dockerfile, usas este lockfile para instalar os teus packages. Isto garante que o teu container de produção corre exatamente as mesmas versões dos packages que testaste durante o desenvolvimento. A seguir, trazes a lógica da tua aplicação para dentro da imagem. No Langflow, a tua aplicação é fundamentalmente apenas dados. Quando terminas de construir no editor visual, exportas o teu flow como um ficheiro JSON. Dentro do teu Dockerfile, copias este ficheiro JSON diretamente para a estrutura da imagem. Esta é a parte que interessa para a lógica custom. Muitos flows complexos dependem de componentes custom, que são pequenos scripts de Python que escreveste para lidar com tarefas específicas. O JSON do flow referencia estes componentes, mas não contém o código Python em si. Tens de copiar explicitamente a diretoria que contém os ficheiros dos teus componentes custom para a imagem Docker. Depois, defines uma variável de ambiente, instruindo o container exatamente onde procurar por esse path de componentes quando o servidor arrancar. A peça final do Dockerfile é o comando de execução. Este comando aciona o módulo do Langflow, passa o file path para o teu JSON do flow embutido, aponta para os teus componentes custom e inclui a flag backend-only. Quando este container arranca, fica totalmente locked down. O editor visual desaparece, a configuração do flow é estática e as dependências são fixas. Ficas com uma API rápida e headless, pronta para receber prompts e devolver respostas. A conclusão mais crítica é que o teu ambiente de desenvolvimento e o teu runtime de produção têm formas fundamentalmente diferentes. Faz a build visualmente, mas faz o deploy de forma headless. Como este é o episódio final, encorajo-te a mergulhares na documentação oficial e a tentares containerizar um flow simples por ti mesmo. Se tiveres ideias sobre o que devemos abordar na nossa próxima série, passa por dev stories dot eu e diz-nos. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.