Langflow

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 1 von 15. Prototyping einer KI-Anwendung bedeutet meistens, ein schnelles visuelles Mockup zu bauen, zu beweisen, dass die Idee funktioniert, und dann die ganze UI wegzuwerfen, um das eigentliche Production-Backend von Grund auf neu zu schreiben. Du verlierst Tage damit, visuelle Konzepte in Server-Code zu übersetzen. Diese Folge behandelt das Langflow-Paradigma, ein Konzept, das diesen Übersetzungsschritt komplett eliminiert. Langflow ist ein Framework, das dafür gemacht ist, KI-Anwendungen zu bauen. Weil du damit hauptsächlich über einen Canvas interagierst, auf dem du Components per Drag & Drop platzierst, hält man es sehr leicht für nur ein weiteres UI-Tool oder ein Low-Code-Spielzeug. Das ist ein Irrtum. Pass bei diesem Unterschied genau auf: Langflow ist ein vollwertiges Python-Backend-Framework. Das visuelle Interface ist lediglich ein Fenster in die zugrundeliegende Python-Architektur. Jede visuelle Component, die du auf dem Canvas platzierst, mappt direkt auf eine Python-Klasse, und der Graph, den du zeichnest, wird direkt in Backend-API-Logik übersetzt. In Langflow nennt man die Anwendungen, die du baust, Flows. Wenn du den Workspace öffnest, konstruierst du im Grunde einen Directed Acyclic Graph, oder DAG. Du fängst an, indem du Nodes zum Canvas hinzufügst. Jeder Node repräsentiert einen eigenen Funktionsblock, wie einen Text-Parser, einen Data Loader oder ein Processing-Modul. Dann ziehst du Linien, die die Output Handles von einem Node mit den Input Handles eines anderen verbinden. Diese Linien sind nicht nur Show. Sie diktieren die Execution Dependency deiner gesamten Anwendung. Wenn du den Output von einem Document Loader Node mit dem Input von einem Processing Node verbindest, liest die zugrundeliegende Engine das als strikte Dependency-Regel. Sie weiß, dass sie den Document Loader zuerst ausführen, auf das Ergebnis warten und die Daten dann downstream weitergeben muss. Daten fließen strikt in eine Richtung durch den Graphen, was einen vorhersehbaren, nachvollziehbaren Pfad von deinem User Input bis zur finalen Response garantiert. Das Framework übernimmt das Type Checking zwischen diesen verbundenen Handles und stellt sicher, dass der Output von einem Node mit dem Input des nächsten kompatibel ist, bevor die Execution überhaupt beginnt. Stell dir vor, du baust einen Prototyping-Flow für ein einfaches Question-Answering-Tool. Im Workspace verbindest du einen Text Input Node mit einem Processing Node und routest das dann zu einem Output Node. Du testest es direkt dort im Browser und passt Parameter an, bis die Antworten richtig aussehen. In einem traditionellen Workflow wäre der nächste Schritt, einem Backend Engineer ein Spezifikationsdokument zu übergeben, damit er diese Logik in Python neu schreibt. Im Langflow-Paradigma überspringst du das komplett. In dem Moment, in dem dein visueller Flow funktioniert, ist er bereits eine funktionierende API. Du sendest einfach einen Request an den integrierten Run Endpoint mit deinem Flow Identifier und den Input Variables. Das Framework durchläuft den Graphen exakt so, wie du ihn designt hast, führt jede Python-Klasse in der richtigen Reihenfolge aus und gibt die Antwort zurück. Du wechselst von einem visuellen Prototype zu einem served Python-Backend, ohne eine einzige Zeile Server-Konfigurationscode zu schreiben. Die Core Identity von Langflow ist, dass die visuelle Map, die du zeichnest, um deine Anwendung zu verstehen, exakt dieselbe Struktur ist, die der Server benutzt, um sie auszuführen. Wenn du diese Episoden hilfreich findest und die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 2 von 15. Du verbindest zwei Nodes miteinander, startest deine Pipeline, und absolut nichts passiert. Die Verbindung sieht gut aus, aber die Execution schlägt fehl oder wirft einen kryptischen Error. Das Problem liegt meist daran, wie sich Daten zwischen den Blöcken bewegen, was uns zur Component-Architektur und zu Data Types führt. Oft wird angenommen, dass Langflow-Components lose JSON-Payloads hin und her schieben wie eine Standard-Web-API. Tun sie aber nicht. Jede Component in Langflow ist eine eigenständige, strictly typed Python Class Execution. Eine Component enthält einen internen State, Input-Ports und Output-Ports. Daten fließen ausschließlich über diese definierten Ports, und diese Ports verlangen spezifische Langflow-Objects. Du kannst diese Data Types anhand der Port-Farben tracken. Jeder Port an einer Component hat eine bestimmte Farbe, die dem Data Type entspricht, den er akzeptiert oder zurückgibt. Wenn du einen Output-Port mit einem Input-Port verbindest und die Farben matchen, fließen die Daten reibungslos. Wenn die Farben nicht matchen, versuchst du, inkompatible Daten zu übergeben. Die Downstream-Component wird das eingehende Object nicht parsen können, und der Flow wird fehlschlagen. Um zuverlässige Pipelines zu bauen, musst du die drei Core Data Objects verstehen, die über diese Connections wandern. Das erste ist der Message Type. Ein Message Object wird für Conversational Data verwendet. Es enthält den eigentlichen Text-Content zusammen mit Routing-Informationen, genauer gesagt der Role. Diese teilt dem System mit, ob der Text von einem User, einem System Prompt oder einem AI Model stammt. Der zweite Core Type ist das Data Object. Ein Data Object funktioniert als Wrapper für unstrukturierte Informationen. Es enthält Text-Content zusammen mit einem Dictionary aus Metadaten. Wenn du Documents aus einer Vector Database abrufst, eine Web Page scrapest oder eine Textdatei liest, wandern diese Informationen als strukturiertes Data Object durch deinen Flow, und nicht als Raw String. Das Metadata Dictionary erlaubt es dir, Source-URLs oder Timestamps zusammen mit dem Text zu übergeben, ohne die Downstream Processing Logic zu zerschießen. Der dritte Type ist das DataFrame Object. Das wird für zweidimensionale Tabellendaten verwendet. Es verhält sich sehr ähnlich wie ein Pandas DataFrame. Das macht es zum erforderlichen Type, wenn du geparste CSV-Files oder strukturierte Rows und Columns zwischen Analytical Components übergibst. Weil Ports strictly typed sind, wirst du oft in Situationen kommen, in denen du einen Data Type hast, die nächste Component aber einen anderen verlangt. Nimm mal das Szenario, dass du einen Raw Text String aus einem simplen Python Execution Block holst und ihn an eine Text Processing Component übergeben musst, die explizit ein strukturiertes Data Object verlangt. Die Port-Farben werden nicht matchen. Du kannst einen Raw String nicht in einen Data Port zwingen. Um diese Lücke zu überbrücken, nutzt du eine Type Convert Component. Du platzierst den Type Convert Block zwischen den beiden nicht matchenden Components. Zuerst verbindest du den String Output mit dem Input vom Type Convert Block. Dann verbindest du dessen Output mit dem Data Port deiner Downstream Processing Component. Der Type Convert Block nimmt den Raw String, wrappt ihn in ein sauberes Data Object mit einem leeren Metadata Dictionary und übergibt ihn sicher an den nächsten Node. Das Strict Typing dieser Ports zu verstehen, ist der Unterschied zwischen einem Flow, der funktioniert, und einem Flow, der ständig crasht. Wenn eine Pipeline silently fehlschlägt, debugge nicht zuerst deine Logic. Checke deine Port-Farben, um sicherzustellen, dass deine Components tatsächlich exakt dieselbe Data Language sprechen. Danke fürs Zuhören. Macht's gut zusammen.

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 3 von 15. Eine einfache Chat-Nachricht wirkt vielleicht wie ein simpler String aus Text, aber wenn das so wäre, würde deine Application sofort den Überblick darüber verlieren, wer was gesagt hat, sobald sich ein zweiter User verbindet. Genau dieses Routing-Problem lösen wir heute: das Interfacing mit dem Graph über Chat Input und Chat Output. Wenn du einen Flow baust, ist der Entry Point typischerweise eine Chat Input Komponente. Developer verwechseln das oft mit einer simplen Text Box, die einfach nur blind einen String an die nächste Node weiterleitet. Das ist ein falsches Mental Model. Die Chat Input Komponente fungiert als strukturierte Data Factory. Ihre Hauptfunktion ist es, Raw Text aus dem User Interface abzufangen und in einen speziellen Data Type namens Message Object zu kapseln. Das Message Object ist die grundlegende Währung für Text, der durch einen Langflow Graph fließt. Anstatt nackte Strings zu übergeben, routet der Graph dieses standardisierte Package. Innerhalb des Objects sitzen die vom User getippten Wörter in einem Core Text Field. Um diesen Text herum liegt ein Layer aus Metadaten. Das Object enthält ein Sender Field, das die Source entweder als User oder als Machine kategorisiert. Es beinhaltet einen Sender Name, der das visuelle Display Label im Front End steuert. Außerdem stempelt es die genaue Creation Time in ein Timestamp Field. Diese Metadaten werden extrem wichtig, wenn es um Concurrent Users geht. Stell dir ein Szenario vor, in dem ein User eine Frage in einer deployten Application stellt. Die Chat Input Komponente fängt den Text ab, verpackt ihn in ein Message Object, setzt den Sender auf User und hängt eine eindeutige Session ID an. Diese Session ID ist der Mechanismus, der einen bestimmten Conversation Thread trackt. Während die Message den Graph durchläuft und dabei Retrievers oder Processing Nodes passiert, bleibt diese Session ID angehängt. State Management Tools und Memory Components verlassen sich komplett auf diese ID, um Interaktionen zu gruppieren. Ohne sie hätte der Graph keine Möglichkeit, den Context eines Users von dem eines anderen zu isolieren. Du hast außerdem die Kontrolle über die Sichtbarkeit dieses Inputs. Die Chat Input Komponente kann so konfiguriert werden, dass sie ihre Inhalte vor dem Main Chat Interface verbirgt. Das ist nützlich, wenn man Default System Parameters oder Background Instructions übergibt, die der User nie sehen muss, während man trotzdem ein gültiges Message Object in den Graph injectet. Auf der anderen Seite des Flows sitzt die Chat Output Komponente. Das ist die Terminal Node, die Daten zurück an das User Interface präsentiert. Sie fängt das finale Message Object ab, das von deiner Logik produziert wurde. Weil sie ein vollständig geformtes Object erhält, liest die Chat Output Komponente die Sender und Sender Name Fields, um das Interface akkurat zu rendern, und zeigt die Response typischerweise so an, als käme sie von der Machine. Falls eine vorherige Node zufällig Raw Text anstelle eines Message Objects an den Chat Output übergibt, korrigiert die Komponente das automatisch. Sie wrappt den Raw String in ein frisches Message Object, bevor sie ihn anzeigt, und erzwingt so eine strikte Datenkonsistenz an den Grenzen deines Graphs. Die Chat Input und Output Komponenten sind keine kosmetischen Interface-Elemente, sie sind die Border Controller deiner Application, die garantieren, dass jeder Text sauber in ein getracktes Message Object gewrappt wird, bevor er sich weiterbewegen darf. Danke, dass du dabei warst. Ich hoffe, du hast etwas Neues mitgenommen.

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 4 von 15. Du entscheidest dich mitten im Projekt, deine Anwendung von einem Model Provider zu einem anderen zu wechseln. Normalerweise bedeutet das, jeden API Call zu suchen, Configuration Objects neu zu schreiben und zu hoffen, dass du nicht die gesamte Prompt Chain kaputt gemacht hast. Eine saubere Architektur macht daraus einen nahtlosen Übergang. Die Language Model Component in Langflow bietet die Abstraktion, die das möglich macht. Wenn Entwickler anfangen, Flows zu bauen, erwarten sie oft, einfach eine Model Node auf den Canvas zu ziehen und ihren API Key direkt in die Component Settings einzufügen. Mach das nicht. Langflow ist so konzipiert, dass die Authentication global über die Model Providers Pane abgewickelt wird. Du konfigurierst deine Credentials, wie zum Beispiel deine OpenAI- oder Anthropic-Keys, genau einmal in den Global Settings. Die einzelnen Model Components auf deinem Canvas dienen als Referenzen auf diese globalen Configurations. Die Node selbst steuert das lokale Verhalten, wie den System Prompt, das maximale Token Limit oder die Temperature Setting. Der Global Provider kümmert sich um die sichere Verbindung. Diese Trennung von Authentication und Execution Logic wird entscheidend, wenn du experimentieren willst. Stell dir vor, du hast eine komplexe Prompt Chain, die aktuell in eine OpenAI Model Component eingespeist wird. Du willst sehen, ob ein Anthropic Model bessere Ergebnisse liefert. Dank der globalen Abstraktion ziehst du die neue Anthropic Component einfach auf den Canvas. Du verbindest deine bestehende Prompt Sequence mit ihrem Input. Du stellst deine gewünschte Temperature an der neuen Node ein. Der Global Provider übernimmt die Authorization automatisch im Hintergrund basierend auf deinen gespeicherten Keys. Du löschst die alte Node, und dein Flow ist sofort bereit zum Testen. Nichts in deiner Prompt Chain geht kaputt. Damit ist abgedeckt, wie die Component konfiguriert wird. Schauen wir uns nun an, wie sie Daten weitergibt. Die Language Model Component bietet zwei Output-Möglichkeiten, je nachdem, was der Rest deines Flows tatsächlich benötigt. Standardmäßig gibt die Component eine Model Response aus. Du sendest ihr einen Prompt, das Model verarbeitet ihn, und die Component gibt einen Text String aus. Das ist das Standardverhalten, das du nutzt, wenn du einen einfachen Chatbot oder ein Summarization Tool baust. Die Node empfängt einen Request, generiert die Antwort und gibt diese finale Antwort weiter. Manchmal braucht eine Downstream Component jedoch nicht die Antwort. Sie braucht die Engine. Du kannst das Verhalten des Output Ports ändern und ihn von der Ausgabe einer Message Response auf die Ausgabe einer LanguageModel Instance umstellen. Wenn du das tust, wertet die Component den Prompt nicht mehr aus und sendet keinen Text. Stattdessen verpackt sie das konfigurierte Model selbst, zusammen mit seinen Provider Credentials und Temperature Settings, und übergibt dieses Object an die nächste Node. Das ist für komplexere Architekturen unerlässlich. Wenn du dein Setup mit einer komplexen Retrieval Chain verbindest, muss diese Chain eigene interne Queries ausführen, um eine Datenbank basierend auf der Conversation History zu durchsuchen. Das kann sie nicht, wenn du ihr nur eine statische Text Response übergibst. Sie braucht eine Live Engine, um ihre eigenen Text Generation Tasks auszuführen. Durch die Übergabe der LanguageModel Instance gibst du der Downstream Node ein vollständig konfiguriertes Tool an die Hand, das sie wiederholt nutzen kann, um die spezifischen Prompts zu generieren, die sie braucht. Die Component ist nicht nur ein hardcoded API Call. Sie ist ein flexibler Container, der deine Credentials von deiner Logic trennt und dir die Wahl lässt, ob deine Anwendung eine finale Antwort oder eine Execution Engine braucht. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 5 von 15. Was unterscheidet einen statischen Chatbot von einer echten Reasoning Engine? Die Fähigkeit, die nächsten Schritte selbstständig zu bestimmen. Wenn dein Flow ausschließlich auf hardcoded Prompt Chains basiert, scheitert er in dem Moment, in dem ein User eine unerwartete Folgefrage stellt. Hier kommen Intelligent Execution Engines ins Spiel, genauer gesagt die Agent-Komponente. Viele Entwickler platzieren einen regulären Language Model Node auf dem Canvas und erwarten, dass er sich wie ein smarter, kontextsensitiver Assistent verhält. Das tut er nicht. Ein Standard Language Model Node ist im Grunde ein Text-in, Text-out-Taschenrechner. Du übergibst ihm einen String, und er gibt einen String zurück, der ausschließlich auf diesem einen Input basiert. Eine Agent-Komponente ist grundlegend anders. Sie ist eine autonome Reasoning Engine. Anstatt lediglich einen einzelnen Prompt auszuführen, wertet ein Agent den aktuellen Kontext aus, entscheidet über eine Abfolge von Aktionen und bestimmt seine eigenen Ausführungsschritte, um ein Ziel zu erreichen. Wenn ein User eine Nachricht an einen Agenten sendet, generiert die Komponente nicht sofort die endgültige Antwort. Er geht in einen internen Reasoning Loop. Er analysiert den Input, prüft seinen internen State und formuliert einen Plan. Diese Planungsphase ermöglicht es dem Agenten, komplexe Antworten zu strukturieren oder zu erkennen, dass er vergangene Interaktionen auswerten muss, bevor er fortfährt. Das bringt uns zu den integrierten Memory-Fähigkeiten der Agent-Komponente. Ein Standard Language Model Node leidet unter Amnesie. Jeder Request ist ein unbeschriebenes Blatt. Wenn ein User nach der Hauptstadt von Frankreich fragt und in einer Folgefrage wissen will, wie hoch dort die Einwohnerzahl ist, weiß ein Standard Node nicht, was das Wort dort bedeutet. Du müsstest manuell ein System bauen, um die bisherige Chat History zu erfassen, zu speichern, zu formatieren und in jeden neuen Prompt einzufügen. Die Agent-Komponente löst das nativ. Sie verwaltet automatisch ein fortlaufendes Context Window mit den bisherigen Fragen des Users und den bisherigen Antworten des Systems. Wenn diese zweite Frage nach der Einwohnerzahl reinkommt, fängt der Agent den Request ab. Bevor er eine Response generiert, fragt er sein integriertes Memory ab. Er ruft den Kontext der ersten Frage ab, setzt die Chat History zusammen und schlussfolgert, dass der gesuchte Ort Paris ist. Er führt diese kontextbezogene Auswertung völlig selbstständig durch. Du musst keine separaten Memory Nodes verkabeln, History Strings parsen oder komplexe History Injection Loops auf deinem Canvas bauen. Der Agent verarbeitet die stateful Natur der Konversation intern. Er entscheidet, wann er sich die History ansieht, wie viel davon für die aktuelle Query relevant ist und wie er diesen historischen Kontext nutzt, um seinen nächsten Output zu formen. Dieser Shift verändert, wie du Flows designst. Du musst nicht mehr jeden möglichen Branch einer Konversation abbilden. Du stellst einer intelligenten Engine die Parameter zur Verfügung, die sie braucht, um die Konversation selbst zu managen. Die Komponente übernimmt die Last des State Managements und der Context Resolution. Die wahre Stärke der Agent-Komponente liegt in dieser Autonomie. Durch den Wechsel von statischen Language Models zu einem Agenten delegierst du den Control Flow an die Engine selbst. Das System ist keine starre Pipeline mehr, sondern eine dynamische Entität, die in der Lage ist, State zu halten, sich an vergangene Interaktionen zu erinnern und ihr Reasoning on the fly an die Absicht des Users anzupassen. Ich möchte mir kurz die Zeit nehmen, dir fürs Zuhören zu danken – das hilft uns sehr. Hab einen schönen Tag!

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 6 von 15. Du denkst vielleicht, dass du für die Entwicklung eines Agent Tools eigene Python Wrapper schreiben oder in einer Library nach speziellen Tool Nodes suchen musst. Musst du aber nicht. Fast jede Component, die schon auf deinem Canvas liegt, lässt sich mit einem einzigen Klick in eine aktive Fähigkeit umwandeln. Heute schauen wir uns an, wie man Agents mit dem Tool Mode ausstattet. Ein weit verbreiteter Irrtum ist, dass du dedizierte, hardcoded Tool Components brauchst, um einen Agent zu füttern. In Langflow ist der Tool Mode ein Feature, das direkt in die Standard Nodes eingebaut ist. Egal, ob du mit einem API Caller, einem Database Retriever oder einer Text Processing Node arbeitest, du kannst sie einfach in den Tool Mode schalten. Wenn du dieses Toggle bei einer Component aktivierst, ändert sich ihr Interface. Die Standard Output Ports, die du normalerweise in den nächsten Schritt einer linearen Chain routen würdest, verschwinden. Stattdessen zeigt die Component einen einzigen Tool Output Port. Du nimmst diesen neuen Tool Output und verbindest ihn direkt mit dem Tools Input Port einer Agent Component. Ein inaktiver Verarbeitungsschritt ist jetzt eine ausführbare Utility, die der Agent bei Bedarf triggern kann. Die Component in ein Tool zu verwandeln, ist nur der mechanische Schritt. Der Agent muss immer noch wissen, wie er es benutzt. Wenn du den Tool Mode aktivierst, erscheint auf der Node ein Button mit der Aufschrift Edit Action. Ein Klick darauf öffnet drei Konfigurationsfelder. Das erste Feld ist der Slug. Das ist ein maschinenlesbarer Identifier, der normalerweise mit Unterstrichen statt Leerzeichen formatiert wird. Das zweite ist der Name, ein ganz normaler, menschenlesbarer Titel. Das dritte Feld ist die Description. Das ist der Teil, auf den es ankommt. Das Description Feld ist keine Dokumentation für den Developer. Es ist der buchstäbliche Text Prompt, den das Large Language Model liest, um zu entscheiden, ob es dieses spezifische Tool triggern soll. Wenn deine Description vage ist, wird der Agent raten, wann er das Tool benutzen soll, was zu unvorhersehbarem Verhalten und verschwendeten Tokens führt. Nehmen wir eine Web Search Component als Beispiel. Normalerweise nimmt sie einfach einen String und gibt Suchergebnisse zurück. Wenn du den Tool Mode für diese Node aktivierst, wird sie zu einem Agent Tool. Jetzt öffnest du das Edit Action Menü. Wenn du eine generische Description wie searches the web schreibst, triggert der Agent vielleicht eine Suche für einfache Faktenfragen, die er schon in seinen Trainingsdaten hat. Stattdessen schreibst du eine sehr restriktive Description. Du definierst exakte Bedingungen. Du schreibst, nutze dieses Tool ausschließlich, um Breaking News, aktuelle Ereignisse oder Echtzeit-Wetter abzufragen. Der Agent parst genau diesen Satz während seines Reasoning Cycles. Er evaluiert den Prompt gegen deine Description und stellt so sicher, dass die Web Search Node nur feuert, wenn der User nach aktuellen Nachrichten fragt. Du kannst das skalieren, indem du den Tool Mode für mehrere verschiedene Components aktivierst. Du verbindest einfach alle ihre Tool Output Ports mit dem einzigen Tools Input an der Agent Node. Der Agent prüft die Descriptions für jedes verbundene Tool, wählt das richtige aus, führt es aus und synthetisiert die zurückgegebenen Daten, um seine finale Antwort zu formulieren. Die zugrundeliegende Logik der Node ist für den Agent komplett unsichtbar. Das Einzige, was die Entscheidungsfindung deines Agents steuert, ist die Präzision deiner Tool Descriptions. Danke fürs Einschalten. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 7 von 15. Ein einzelnes Sprachmodell dazu zu zwingen, gleichzeitig grundlegendes Routing und aufwendige Datenanalysen zu übernehmen, führt meistens zu langsamen Antworten und hohen API-Kosten. Die Lösung ist, die kognitive Last aufzuteilen, und genau da kommen Multi-Agent Compositions ins Spiel. Viele Leute betrachten Langflow-Flows streng als isolierte Endpoints. Du rufst eine API auf, bekommst eine Antwort, und die Ausführung endet. Das ist ein Irrtum. Flows sind nicht nur Top-Level-Anwendungen; sie können hierarchisch eingebettet werden. Stell dir ein System zum Parsen von User Requests vor. Du konfigurierst einen primären Routing-Agenten mit einem schnellen, günstigen Modell. Seine einzige Aufgabe ist es, herauszufinden, was der User will. Wenn ein User darum bittet, einen riesigen Finanzbericht zu analysieren, verarbeitet der primäre Agent das Dokument nicht selbst. Stattdessen verbindest du einen sekundären Agenten direkt mit dem Tool Input des primären Agenten. Dieser sekundäre Agent führt ein komplett anderes Modell mit einem viel größeren Context Window aus, das speziell für Data Extraction optimiert ist. Das Routing verlässt sich komplett auf die Tool Description. Wenn du den sekundären Agenten verbindest, musst du eine klare Textbeschreibung davon liefern, was er tut. Der primäre Agent liest diese Beschreibung zusammen mit dem User Prompt. Sobald ein Request mit der Beschreibung übereinstimmt, stoppt der primäre Agent seine eigene Generierung, verpackt den relevanten Context und ruft den sekundären Agenten auf. Für den primären Agenten sieht dieses komplexe sekundäre Setup wie eine einzige Funktion aus. Der sekundäre Agent führt seinen eigenen Reasoning Loop aus, verarbeitet das große Dokument und gibt den finalen Text wieder nach oben an den primären Agenten zurück, der dann dem User antwortet. Du kannst diese Abstraktion sogar noch weiter treiben, indem du einen kompletten Flow als Tool verwendest. Du baust vielleicht einen anspruchsvollen Flow, der eine Website scraped, Text extrahiert, ihn formatiert und den Output evaluiert. Sobald er fertig ist, speicherst du ihn. In einem komplett anderen Projekt ziehst du eine Flow-Tool-Komponente auf den Canvas und wählst deinen gespeicherten Flow aus. Wenn du einen Flow in einen anderen Workspace holst, definierst du spezifische Input- und Output-Komponenten innerhalb dieses Child Flows. Der Parent Agent mappt seine Tool Arguments direkt auf diese definierten Inputs. Er führt den Child Flow aus, wartet darauf, dass die finale Output-Komponente triggert, und zieht den resultierenden Text die Chain wieder nach oben. Langflow basiert auf einer Node-basierten Graph-Architektur. Dank dieser Struktur erlaubt die Engine rekursive Komposition. Ein kompletter Graph kann gekapselt und als einzelner Node innerhalb eines größeren Graphen behandelt werden. Der primäre Agent weiß nichts von der verschachtelten Komplexität. Er sieht einfach nur ein Tool namens scrape_and_evaluate, das eine URL entgegennimmt und eine Zusammenfassung zurückgibt. Die Stärke der Multi-Agent Composition ist die Abstraktion. Sie erlaubt es dir, komplexe, mehrstufige Reasoning Loops hinter einem einzigen Tool Call zu verbergen und so deine primäre Routing-Logik sauber und vorhersehbar zu halten. Wenn du die Show unterstützen möchtest, findest du uns, indem du auf Patreon nach DevStoriesEU suchst. Danke fürs Zuhören. Macht's gut, Leute.

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 8 von 15. Die Zeiten, in denen man für jede neue Datenquelle eigene API-Wrapper schreiben musste, sind vorbei. Du musst nicht länger Endpoints manuell mappen, Header formatieren und raw JSON parsen, nur damit ein Agent eine Webseite lesen oder eine lokale Datenbank abfragen kann. Diese Hürde wird durch den Model Context Protocol Client beseitigt. Das wird oft mit Standard-REST-API-Integrationen verwechselt. Es ist kein generischer HTTP Request Node, bei dem du den Payload selbst zusammenbaust. Das Model Context Protocol, oder MCP, ist ein offener Standard, der speziell dafür entwickelt wurde, Kontext und ausführbare Funktionen an AI-Modelle zu liefern. Es ist eine universelle Sprache für Tool Use. In dieser Architektur fungiert Langflow als MCP Client. Es kontaktiert einen externen MCP Server, fragt nach dessen Capabilities und stellt diese bereit. Das erreichst du mit der MCP Tools Component. Du ziehst diese Component auf deinen Canvas und verbindest ihren Output direkt mit dem Tools-Input einer Agent Component. Sobald die Verbindung hergestellt ist, empfängt Langflow ein striktes Schema, das die Tools, ihre Beschreibungen und die erforderlichen Parameter definiert. Es übersetzt diese automatisch in native Tools. Der Agent weiß von sich aus genau, wie er die Daten formatieren und die externen Funktionen triggern muss. Um diese Verbindung herzustellen, wählst du eine Transportmethode. Die MCP Tools Component unterstützt zwei Optionen: HTTP über Server-Sent Events und STDIO. HTTP ist die richtige Wahl für Remote-Server, die sicher auf einem anderen Rechner ausgeführt werden. Du gibst einfach die Endpoint-URL an. STDIO wird verwendet, wenn Langflow einen lokalen Prozess ausführen und über Standard Input und Output Streams kommunizieren soll. Schauen wir uns ein konkretes Szenario mit STDIO an. Angenommen, dein Agent soll Tech-News direkt von externen URLs zusammenfassen. Dafür kannst du ein vorgefertigtes Tool namens fetch MCP server verwenden. Stelle in deiner MCP Tools Component den Transport auf STDIO. Setze deinen Command auf uvx, ein Python-Tool, das Packages in isolierten Environments herunterlädt und ausführt. Gib im Arguments-Feld mcp dash server dash fetch ein. Verbinde den Component-Output mit deinem Agenten. Wenn du den Agenten promptest, einen bestimmten Artikel zusammenzufassen, ruft der Agent das Fetch-Tool nativ auf. Er streamt die Target-URL über STDIO an den isolierten Hintergrundprozess, liest den zurückgegebenen Text von der Webseite und generiert deine Zusammenfassung. Du hast absolut keinen Code geschrieben, um diese Integration umzusetzen. Viele Tools erfordern eine Authentifizierung, wie ein Datenbankpasswort oder einen privaten API Key. Die MCP Tools Component enthält ein Environment Variables Feld, das ein Dictionary aus Key-Value-Paaren akzeptiert. Wenn du programmatisch über die API mit deinem Langflow-Graphen interagierst, kannst du diese Credentials dynamisch über das Tweaks-Dictionary injecten. Du sprichst einfach die MCP Tools Component ID an und übergibst die Environment Variables sicher in deinem Request Payload. Der entscheidende Vorteil des MCP Clients ist die vollständige Entkopplung. Du deployest eine externe Capability einmalig in einer beliebigen Programmiersprache und gibst jedem Langflow-Agenten sofort nativen Zugriff darauf, ohne jemals die Graph-Logik zu verändern. Danke fürs Zuhören – bis zum nächsten Mal.

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 9 von 15. Du schreibst eine custom AI Pipeline und möchtest, dass dein Code-Editor sie nativ als integriertes Tool ausführt. Du stellst deiner IDE eine Frage, und sie triggert nahtlos das komplexe Retrieval System, das du gestern gebaut hast. Flows als MCP Server bereitzustellen, macht genau das möglich. Zuerst müssen wir klären, was ein MCP Server eigentlich ist. Zuhörer verwechseln das manchmal mit einem Standard Deployment Endpoint, der als Backend für eine Web Application dient. Aber genau das ist es nicht. Das Model Context Protocol, oder MCP, ist ein standardisierter Weg, um anderen AI Agents Capabilities direkt bereitzustellen. Ein Standard Endpoint liefert Daten an ein User Interface. Ein MCP Server stellt einer Reasoning Engine Tools zur Verfügung. Mit Langflow kannst du jedes Projekt automatisch in einen MCP Server verwandeln. Wenn du das machst, wird dein gesamter Flow als ausführbares Tool verpackt. Um mit externen Clients zu kommunizieren, nutzt Langflow einen streamfähigen HTTP Transport Mechanismus, der speziell auf Server-Sent Events basiert. Das bedeutet, dass sich dein externer Client über Standard Web Protokolle verbindet und Streaming Responses direkt von deinem Flow empfangen kann, ohne dass komplexe lokale Networking Setups nötig sind. Die technische Konfiguration ist straightforward, aber es gibt eine absolute Voraussetzung, die du richtig machen musst. Du musst den Tool-Namen und die Description definieren. Wenn sich ein externer Agent mit deinem Langflow MCP Server verbindet, fragt er nach einer Liste der verfügbaren Tools. Der Agent nutzt die bereitgestellten Descriptions, um zu entscheiden, welches Tool er aufruft und wann er es aufruft. Wenn du die Default Description stehen lässt oder etwas Vages schreibst, wird der externe Agent sie ignorieren. Du musst die Description als präzise Anweisung für den AI Agent schreiben. Du promptest das externe System quasi, wie es deinen Flow nutzen soll. Schauen wir uns ein konkretes Szenario an. Du baust einen Document QA Flow in Langflow, der ein internes Company Architecture Document durchsucht. Du möchtest, dass dein lokaler Cursor Editor Agent dieses Dokument nativ abfragt. Du stellst den Flow als MCP Server bereit. Du nennst das Tool query company architecture und legst in der Description fest, dass es das interne Company Architecture Document durchsucht, um technische Fragen zu Backend Services zu beantworten. Dann konfigurierst du Cursor so, dass er sich mit deiner Langflow MCP URL verbindet. Jetzt schreibst du Code in Cursor und fragst den Agent, wie das Authentication System funktioniert. Cursor checkt seine verbundenen MCP Server, liest deine spezifische Description und erkennt, dass dein Langflow Tool genau das ist, was er braucht. Cursor übergibt deine Frage als Argument an das Tool. Langflow empfängt den Request über den HTTP Transport, führt den gesamten Document QA Flow aus und streamt die Antwort zurück in deinen Editor. Deine IDE hat gerade ein komplexes Langflow Projekt als native Funktion genutzt. Der Erfolg einer MCP Integration hängt komplett von der Qualität des Prompts ab, den du in der Tool Description versteckst. Wenn der externe Agent die Description nicht versteht, existiert dein Tool praktisch nicht. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 10 von 15. Wenn zwei User gleichzeitig mit deiner AI-Applikation kommunizieren, wie verhindert das System, dass die Antworten des einen Users an den anderen weitergeleitet werden? Die Antwort liegt darin, wie du Threads isolierst, und genau das macht State und Session Management. Lass uns zuerst ein sehr häufiges Missverständnis klären. Wir müssen eine klare Linie zwischen Chat Memory und semantischem Vector Memory ziehen. Beim Vector Memory werden Dokumente als Embeddings gespeichert und basierend auf ihrer Bedeutung abgerufen. Das behandeln wir hier nicht. Chat Memory ist einfach das lineare, chronologische Log einer Konversation. Es ist der Mechanismus, der es dem Language Model erlaubt, sich daran zu erinnern, was der User vor drei Messages gesagt hat. Standardmäßig speichert Langflow diese lineare Message History lokal in einer SQLite-Datenbank. Jedes Mal, wenn eine Message durch das System geht, wird sie aufgezeichnet. Aber eine Datenbank voller Messages ist nutzlos, wenn das System nicht weiß, welche Message zu wem gehört. Hier kommt die Session ID ins Spiel. Die Session ID ist ein eindeutiger String, der eine Sequenz von Interaktionen miteinander verknüpft. Wenn du das Langflow-Interface nutzt, generiert das System im Hintergrund automatisch eine Session ID für dich. In Production wirst du wahrscheinlich über die API mit Langflow interagieren. Wenn zwei verschiedene User gleichzeitig mit deinem Server interagieren, musst du für jeden eine spezifische Session ID in deinem API Request übergeben. Eine Standardpraxis ist es, die eindeutige User ID aus deiner eigenen Datenbank als Langflow Session ID zu verwenden. Wenn dein erster User eine Message sendet, übergibst du seine spezifische ID. Langflow fragt die SQLite-Datenbank nach genau diesem String ab, zieht nur seine History, hängt sie an den Prompt an und generiert eine Response. Wenn dein zweiter User eine Millisekunde später mit seiner eigenen ID interagiert, führt Langflow genau denselben Prozess in kompletter Isolation aus. Wenn du in deinem API Call keine Session ID übergibst, behandelt Langflow die Interaktion als ein brandneues Event. Der Context geht komplett verloren. Um den Thread aufrechtzuerhalten, muss deine externe Application diesen Identifier mit jedem einzelnen Request mitsenden. Wie du diese History dem Language Model zugänglich machst, hängt komplett von den Components ab, die du wählst. Langflow bietet zwei verschiedene Ansätze. Wenn du eine Standard-Agent-Component nutzt, ist das Memory Management direkt eingebaut. Der Agent übernimmt automatisch das Lesen und Schreiben in die SQLite-Datenbank unter Verwendung der aktiven Session ID. Du musst nichts extra verbinden, damit er sich an die Konversation erinnert. Agents sind stark abstrahiert. Wenn du also eine Custom Chain von Grund auf mit Base Components und Raw Prompts baust, existiert dieses eingebaute Memory nicht. Hier nutzt du die dedizierte Message History Component. Du platzierst diese Component in deinem Flow und verbindest ihren Output mit einer Variable in deiner Prompt Component. Wenn der Flow läuft, schnappt sich die Message History Component die aktive Session ID, holt das relevante chronologische Log aus der Datenbank und formatiert es als Text. Dadurch wird der gespeicherte Hin-und-Her-Dialog physisch in das Context Window übergeben, bevor das Language Model ihn überhaupt zu sehen bekommt. Die Kontrolle der Session ID auf API-Ebene ist die absolut wichtigste Voraussetzung für das Skalieren eines Conversational Interfaces, denn den State strikt an einen übergebenen Identifier zu binden, garantiert komplette Isolation über beliebig viele gleichzeitige User hinweg. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 11 von 15. Der größte Fehler, den Entwickler beim Aufbau von Retrieval Augmented Generation machen, ist die Kombination von langsamem Data Indexing und Real-time Chat Retrieval in einer einzigen Pipeline. Jedes Mal, wenn der User eine Frage stellt, versucht das System, ein hundertseitiges PDF erneut einzulesen. Die Lösung ist das Grounding des LLMs mit Vector Stores über eine entkoppelte Architektur. Es ist unglaublich verbreitet, alle deine Komponenten auf einem einzigen Canvas miteinander zu verknüpfen. Du verbindest einen File Loader mit einem Text Splitter, übergibst das an ein Embedding Model, packst es in einen Vector Store und verkabelst es direkt mit einem Chat Interface. Das erzeugt einen massiven Bottleneck. Data Ingestion und Chat Retrieval sind völlig unterschiedliche Lifecycle Events. Sie sollten nicht im selben Execution Path liegen. Die Standard-RAG-Architektur in Langflow trennt diesen Prozess in zwei separate Flows. Zuerst hast du den Ingestion Subflow. Hier passieren die rechenintensiven Operationen. Du nimmst deine Source Documents, wie zum Beispiel große PDF-Dateien, und übergibst sie an einen Document Loader. Ein Text Splitter zerlegt die Dokumente anschließend in kleinere Chunks. Wenn du deinen Text Splitter konfigurierst, musst du deine Chunk Sizes an die maximalen Token Limits deines gewählten Embedding Models anpassen. Wenn deine Chunk Size dieses Limit überschreitet, wird das Embedding Model den Text stillschweigend abschneiden. Die hinteren Sätze werden ignoriert, und diese fehlenden Daten werden es niemals in deine Vector Database schaffen. Sobald der Text richtig gechunked ist, übergibst du ihn an eine Embedding Component, um die Vektoren zu generieren. Schließlich werden diese Vektoren in einer bestimmten Collection innerhalb deiner Vector Store Component gespeichert. Dieser gesamte Ingestion Flow wird ausgeführt, wenn sich Daten ändern, völlig unabhängig vom User Interface. Der zweite Teil dieser Architektur ist nun der Retrieval Flow. Das ist der User-facing Conversational Part. Weil das aufwendige Indexing bereits woanders erledigt wurde, bleibt dieser Flow schnell und responsive. Er beginnt mit einem Chat Input, der die Frage des Users erfasst. Diese Frage wird an eine Embedding Component weitergeleitet. Du musst diese Komponente so konfigurieren, dass sie exakt dasselbe Embedding Model verwendet, das du während der Ingestion-Phase genutzt hast. Wenn du Daten mit einem Modell indexierst und mit einem anderen abfragst, wird der Vector Store keine relevanten Matches finden. Die Vector Store Component in diesem Flow ist so konfiguriert, dass sie exakt dieselbe Database Collection durchsucht, die du zuvor befüllt hast. Sie nimmt die embedded User-Frage, führt eine Similarity Search in den vorab geladenen Daten durch und gibt die relevantesten Text Chunks zurück. Du routest diese abgerufenen Chunks dann zusammen mit der ursprünglichen User-Frage in eine Prompt Template Component. Dieser angereicherte Prompt wird schließlich an das Language Model gesendet, welches die Antwort formuliert. Indem du deine RAG-Implementierung in einen asynchronen Write Flow für Dokumente und einen schnellen Read Flow für den Chat aufteilst, schützt du dein Chat Interface vor Verzögerungen beim Backend Processing. Die goldene Regel der RAG-Architektur lautet: Eine User Query sollte immer nur eine Suche auslösen, niemals einen Indexing Job. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 12 von 15. Visuelle Programmierung bringt dich zu 90 Prozent ans Ziel, aber unweigerlich stößt du an eine Grenze. Du musst proprietäre Business Logic ausführen oder dich mit einer custom internen API verbinden, und die vorgefertigten Nodes decken das einfach nicht ab. Die Engine über Python zu erweitern, schaltet diese letzten 10 Prozent an absoluter Kontrolle frei. Man denkt schnell, eine Custom Component ist einfach ein Standard-Python-Skript, das du in ein Verzeichnis packst. Ist sie aber nicht. Eine Custom Component erfordert eine strikte Konfiguration auf Class-Level. Ohne diese spezifische Struktur hat die Langflow-Engine keine Ahnung, wie sie deinen Node im visuellen Editor rendern oder seine Daten in den Execution Graph einbinden soll. Der visuelle Node und die Backend-Logik sind eng miteinander verknüpft. Um eine Custom Component zu bauen, startest du immer damit, eine Subclass der von Langflow bereitgestellten Base Component Class zu erstellen. In dieser neuen Klasse schreibst du keine Standard-Initialisierungsmethode, um Variablen zu sammeln. Stattdessen definierst du zwei strikte Arrays: Inputs und Outputs. Schauen wir uns ein praktisches Szenario an. Angenommen, du baust eine custom Text Analyzer Component, die Wörter zählt und ein strukturiertes Data-Objekt an den Graphen zurückgibt. Zuerst konfigurierst du das Inputs-Array. Du befüllst dieses Array mit speziellen Input-Klassen, die von Langflow bereitgestellt werden. Für den Text Analyzer brauchst du einen String, also packst du ein Text-Input-Objekt in das Array und gibst ihm einen Namen. Das ist der entscheidende Teil. Indem du eine spezifische Input-Klasse in deinem Python-Code deklarierst, diktierst du das visuelle Interface. Langflow liest dieses Array und generiert automatisch ein Textfeld an deinem Node im Drag-and-Drop-Editor. Wenn du demselben Array ein Integer-Input-Objekt hinzufügen würdest, würde die UI sofort einen Number Spinner rendern. Du definierst die Datenanforderung im Code, und die Engine baut das User Interface für dich. Sobald die Inputs definiert sind, konfigurierst du das Outputs-Array. Das teilt dem umgebenden Graphen explizit mit, welchen Datentyp dein Node produzieren wird. Beim Text Analyzer wollen wir unser Ergebnis die Chain hinunterreichen, also fügst du dem Array ein Data-Output-Objekt hinzu. Die Output-Konfiguration macht noch eine weitere entscheidende Sache. Sie mappt das visuelle Output Handle auf eine primäre Execution-Methode innerhalb deiner Klasse. Du teilst der Engine explizit mit, welche Python-Funktion ausgeführt werden soll, wenn der nächste Node Daten anfragt. Der letzte Schritt ist, diese gemappte Execution-Methode zu schreiben. Hier lebt deine Standard-Python-Logik. Die Methode empfängt automatisch die Werte, die deine Inputs aus der UI gesammelt haben. Du nimmst den eingehenden String, splittest ihn und zählst die Wörter. Dann, weil der Graph ein standardisiertes Format erwartet, verpackst du deinen finalen Integer in ein Langflow Data-Objekt und gibst es zurück. Die Struktur erzwingt eine saubere Trennung. Das Inputs-Array baut das Interface und sammelt die Daten, die Execution-Methode verarbeitet sie, und das Outputs-Array gibt sie an den visuellen Graphen zurück. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 13 von 15. Vielleicht stellst du dir einen Node als einfache Blackbox vor, wo Daten reingehen, eine Funktion ausgeführt wird, Daten rauskommen und der Node danach sofort alles wieder vergisst. Aber was passiert, wenn deine Pipeline erfordert, dass ein Node eine komplexe Datenbankverbindung initialisiert oder trackt, wie viele Items er gerade verarbeitet hat, bevor er ein Ergebnis liefert? Dafür musst du aus einfachen Funktionen ausbrechen und fortgeschrittene Component Hooks und Execution nutzen. Oft wird angenommen, dass Components strikt stateless Operations sind, die einfach nur Inputs auswerten. Das sind sie aber nicht. Eine Component ist eine Instanz einer Python-Klasse und durchläuft einen spezifischen Lifecycle, der von der internen Execution Engine gemanagt wird. Während dieses Lifecycles kann die Component ihren internen State beibehalten, komplexe Setups orchestrieren und Daten über ihre eigenen internen Methoden hinweg teilen. Wenn Langflow eine Component triggert, initiiert die Engine eine strikte Sequenz. Zuerst, bevor überhaupt eine Output-Generierung beginnt, sucht die Engine nach einem internen Hook namens pre run setup. Du überschreibst diese Methode, wenn deine Component Heavy Lifting betreiben muss, bevor die Hauptlogik feuert. Wenn deine Component sich bei einer externen API authentifizieren, ein großes Machine-Learning-Modell in den Memory laden oder lokale Variablen aufsetzen muss, packst du diese Logik in den Setup Hook. Sobald das Setup komplett ist, wechselt die Engine in die Execution-Phase, indem sie den Run Hook aufruft. Hier lebt dein Main Payload und hier passiert die eigentliche Datenverarbeitung. Die Setup-Logik von der Execution-Logik zu trennen, hält deinen Code organisiert und verhindert redundante Operations. Aber das wirft sofort eine mechanische Frage auf: Wie übergibst du einen authentifizierten API-Client oder eine lokale Variable vom Setup Hook runter in den Run Hook? Dafür nutzt du das Context Dictionary. Jede Custom Component hat ein Attribut namens self dot ctx. Das ist ein Dictionary, das direkt an die Component-Instanz angehängt ist. Es fungiert als dedizierte Memory Bank für die Dauer dieses spezifischen Component Runs. Alles, was du diesem Context Dictionary während der Setup-Phase anhängst, ist sofort verfügbar, wenn die Engine in die Run-Phase übergeht. Lass uns ein praktisches Szenario durchgehen, in dem dieses State Sharing nötig ist. Stell dir eine Custom Component vor, die einen Stream von eingehenden Dokumenten verarbeitet und sowohl den bereinigten Text als auch einen finalen Count ausgeben muss, wie viele Dokumente erfolgreich modifiziert wurden. Zuerst überschreibst du den pre run setup hook. Innerhalb dieser Methode greifst du auf das Context Dictionary zu und erstellst eine Counter-Variable, deren initialen Wert du auf null setzt. Du könntest hier auch deine Text-Cleaning Library initialisieren und sie an den Context anhängen. Als Nächstes triggert die Engine den Run Hook. Deine Methode loopt durch die eingehenden Dokumente. Für jedes Dokument, das erfolgreich durch die Cleaning Library geht, greifst du auf das Context Dictionary zu, holst dir den aktuellen Counter-Wert und erhöhst ihn um eins. Weil das Context Dictionary über diese verschiedenen Aufrufe der Lifecycle-Methoden hinweg bestehen bleibt, behält deine Component ihren internen State sicher bei. Wenn der Run Hook seinen Loop schließlich beendet hat, kann er die verarbeiteten Dokumente zurückgeben und den finalen, genauen Count direkt aus dem Context Dictionary ziehen, um ihn an den nächsten Node weiterzugeben. Die Execution Engine und Component Hooks zu meistern, shiftet dein Mindset: Du schreibst nicht mehr nur einfache Pass-through Scripts, sondern baust robuste, in sich geschlossene Applications, die ihre eigenen Data Lifecycles komplett selbst managen. Wenn du helfen möchtest, die Show am Laufen zu halten, kannst du auf Patreon nach DevStoriesEU suchen. Wie immer, danke fürs Zuhören. Wir sehen uns in der nächsten Folge.

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 14 von 15. Du hast fünfzig Kunden, und alle brauchen eine leicht abgewandelte Version deines AI Support Agents. Der erste Gedanke ist, deinen Graphen fünfzig Mal zu duplizieren und jeweils den System Prompt oder den API Key auszutauschen. Das ist ein absoluter Wartungs-Albtraum. Du brauchst nur einen Graphen und kannst die Variationen on the fly über die Langflow API und dynamische Tweaks handhaben. Wenn du einen Graphen im visuellen Interface baust, sind die Parameter in deinen Components fest. Man denkt schnell, dass man für die Änderung einer kleinen Variable, wie einer Temperature-Einstellung oder einer System Instruction, den gesamten Flow klonen muss. Das stimmt aber nicht. Tweaks lösen das dynamisch zur Runtime, indem sie es dir erlauben, Component-Parameter zu überschreiben, ohne den zugrunde liegenden Graphen zu bearbeiten. Das machst du, indem du komplett headless über die REST API mit Langflow interagierst. Um einen Flow programmatisch auszuführen, sendest du einen HTTP POST Request an den Run Endpoint, genauer gesagt an slash v one slash run, gefolgt von deiner eindeutigen Flow ID. Der Body dieses Requests enthält deine Standard-Inputs, wie zum Beispiel die Textnachricht vom User. Zusätzlich zu diesen Input-Daten kannst du ein Tweaks-Objekt mitgeben. Dieses Objekt ist ein Dictionary, das bestimmte Components in deinem Graphen auf die neuen Werte mappt, die du für diese einzelne Execution injecten willst. Um eine Component zu targeten, brauchst du ihre Node ID. In Langflow besteht eine Node ID typischerweise aus dem Component-Namen und einem zufälligen String, wie Prompt Bindestrich a b c d e. Wenn du deine Tweaks Payload baust, nutzt du genau diese Node ID als Key. Der Value ist ein weiteres Dictionary, das die spezifischen Felder enthält, die du überschreiben willst. Stell dir einen grundlegenden Customer Support Flow vor, der auf mehreren Websites genutzt wird. Der Graph enthält eine Prompt Component, die definiert, wie sich der Agent verhält. Für deinen Banking-Kunden muss der Prompt sehr formell sein. Für deinen Gaming-Kunden muss er locker sein. Anstatt zwei identische Graphen zu pflegen, macht dein Backend-Server einen API Call an exakt dieselbe Flow ID. In der Request Payload gibst du die Node ID dieser Prompt Component an. Darin targetest du das Template-Feld und übergibst die formellen Instructions für die Bank. Wenn die Gaming-Website später einen Call triggert, sendet dein Backend exakt denselben Request, tauscht aber den String im Tweaks Dictionary gegen die lockeren Instructions aus. Die Execution-Logik ist komplett sequenziell. Zuerst bereitest du deine Payload mit der User Query und deinem spezifischen Tweaks Dictionary vor. Dann sendest du den POST Request an den Run Endpoint. Langflow empfängt den Call, wendet deine Overrides temporär auf die getargeteten Nodes an und führt den Graphen aus. Es gibt den finalen Output an deine Application zurück, während der original gespeicherte Flow auf dem Server unangetastet bleibt. Du bist nicht auf Text Prompts beschränkt. Du kannst fast alles tweaken, was in einem Component Input Schema exposed ist. Du kannst dynamisch den Model-Namen austauschen, die Temperature anpassen oder pro Request andere Database Credentials injecten. Das macht aus einem statischen visuellen Graphen eine wiederverwendbare, hochflexible Backend-Funktion. Die Möglichkeit, deine Anwendungslogik von deinen Konfigurationsdaten zu trennen, ist genau das, was Headless Execution in Production wirklich skalieren lässt. Danke fürs Einschalten. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Langflow, Folge 15 von 15. Der visuelle Editor ist genial, um deine Application zu bauen. Aber wenn du genau dieses Drag-and-Drop-Interface auf deinen Live-Servern deployest, frisst das unnötig Memory und legt deine Application Logic offen. Wenn es Zeit für Production Traffic ist, willst du einen schlanken, headless Backend-Container. Genau das schauen wir uns heute an mit Production Containerization. Man sieht es unglaublich oft, dass Teams einen Flow fertig bauen und dann einfach die komplette Langflow-Application samt User Interface auf einem Cloud-Server deployen. Das Interface ist aber strikt für Development gedacht. In einer Production-Umgebung willst du nicht, dass irgendjemand Nodes per Drag-and-Drop verschiebt. Du willst eine immutable, sichere API, die einfach nur Requests verarbeitet. Langflow bietet einen speziellen Modus, um diese Transition zu handhaben. Wenn du den Service startest, nutzt du ein Command Flag namens backend-only. Das weist Langflow an, das React-Frontend komplett zu deaktivieren. Der Server fährt trotzdem hoch, aber er exposed nur die API-Endpoints, die nötig sind, um deine Flows auszuführen. Das reduziert den Memory-Verbrauch drastisch. Es erhöht auch die Security, indem es die Attack Surface verkleinert, und stellt sicher, dass niemand visuell auf die Application-Struktur zugreifen oder sie verändern kann. Um das Ganze für das Deployment zu packen, schreibst du ein Dockerfile. Du startest mit einem Standard-Python Base Image. Da Langflow auf modernes Python-Tooling setzt, managst du deine Packages, indem du deine Dependencies mit UV lockst. Bevor du das Image buildest, exportierst du deinen exakten Dependency Tree in ein Lockfile. Innerhalb des Dockerfiles nutzt du dieses Lockfile, um deine Packages zu installieren. Das garantiert, dass dein Production-Container exakt dieselben Package-Versionen ausführt, die du im Development getestet hast. Als Nächstes bringst du deine Application Logic in das Image. In Langflow ist deine Application im Grunde einfach nur Daten. Wenn du mit dem Bauen im visuellen Editor fertig bist, exportierst du deinen Flow als JSON-File. In deinem Dockerfile kopierst du dieses JSON-File direkt in die Image-Struktur. Das ist der Teil, auf den es bei Custom Logic ankommt. Viele komplexe Flows verlassen sich auf Custom Components. Das sind kleine Python-Scripts, die du geschrieben hast, um spezifische Tasks zu übernehmen. Das Flow-JSON referenziert diese Components, aber es enthält nicht den eigentlichen Python-Code. Du musst das Directory, das deine Custom Component Files enthält, explizit in das Docker Image kopieren. Dann setzt du eine Environment Variable, die dem Container genau sagt, wo er nach diesem Component Path suchen soll, wenn der Server startet. Das letzte Puzzleteil des Dockerfiles ist der Execution Command. Dieser Command triggert das Langflow-Modul, übergibt den File Path zu deinem baked-in Flow-JSON, zeigt auf deine Custom Components und enthält das backend-only Flag. Wenn dieser Container hochfährt, ist er komplett locked down. Der visuelle Editor ist weg, die Flow-Configuration ist static und die Dependencies sind fixed. Was dir bleibt, ist eine schnelle, headless API, die bereit ist, Prompts zu empfangen und Responses zurückzugeben. Das wichtigste Takeaway ist, dass deine Development Environment und deine Production Runtime grundlegend unterschiedliche Formen haben. Baue visuell, aber deploye headless. Da das die letzte Folge ist, ermutige ich dich, in die offizielle Documentation einzutauchen und selbst mal zu versuchen, einen simplen Flow zu containerisieren. Wenn du Ideen hast, was wir in unserer nächsten Serie behandeln sollen, schau auf dev stories dot eu vorbei und lass es uns wissen. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.