erste stabile v1.0-Veröffentlichung Ende Oktober 2025. Nachdem ich die letzten zwei Monate mit ihren neuen APIs gearbeitet habe, bin ich wirklich der Meinung, dass dies die bislang kohärenteste und durchdachteste Model von LangChain ist.
Ich conflict nicht immer ein LangChain-Fan. Die frühen Versionen waren fragil, schlecht dokumentiert, die Abstraktionen wechselten häufig und es schien zu verfrüht, um sie in der Produktion zu verwenden. Aber Model 1.0 fühlte sich zielgerichteter an und verfügte über ein konsistenteres mentales Modell dafür, wie Daten durch Agenten und Instruments fließen sollten.
Das ist nicht Übrigens ein gesponserter Beitrag – ich würde gerne Ihre Meinung hören, schreiben Sie mir gerne eine DM Hier!
Dieser Artikel ist nicht dazu gedacht, die Dokumente wiederzugeben. Ich gehe davon aus, dass Sie sich bereits mit LangChain beschäftigt haben (oder ein intensiver Benutzer sind). Anstatt eine endlose Liste mit Punkten abzuwerfen, werde ich nur vier Schlüsselpunkte herauspicken.
Eine kurze Zusammenfassung: LangChain, LangGraph & LangSmith
Auf hoher Ebene ist LangChain ein Framework zum Erstellen von LLM-Apps und -Agenten, das es Entwicklern ermöglicht, KI-Funktionen schnell mit gängigen Abstraktionen bereitzustellen.
LangGraph ist die graphbasierte Ausführungs-Engine für dauerhafte, zustandsbehaftete Agenten-Workflows auf kontrollierbare Weise. Schließlich ist LangSmith eine Observability-Plattform zur Rückverfolgung und Überwachung.
Einfach ausgedrückt: Mit LangChain können Sie Agenten schnell erstellen, LangGraph führt sie zuverlässig aus und LangSmith ermöglicht Ihnen die Überwachung und Verbesserung in der Produktion.
Mein Stapel
Zum Vergleich: Die meisten meiner jüngsten Arbeiten konzentrieren sich auf die Entwicklung von Multi-Agent-Funktionen für eine kundenorientierte KI-Plattform bei der Arbeit. Mein Backend-Stack ist FastAPI, wobei Pydantic die Schemavalidierung und Datenverträge unterstützt.
Lektion 1: Einstellung der Unterstützung für Pydantic-Modelle
Eine wesentliche Veränderung bei der Migration auf v1.0 conflict die Einführung des neuen create_agent Verfahren. Es optimiert die Definition und den Aufruf von Agenten, lässt aber auch die Unterstützung für Pydantic-Modelle und Datenklassen im Agentenstatus fallen. Alles muss jetzt als TypedDicts-Erweiterung ausgedrückt werden AgentState.
Wenn Sie FastAPI verwenden, ist Pydantic häufig der empfohlene und standardmäßige Schemavalidator. Ich schätzte die Schemakonsistenz in der gesamten Codebasis und hatte das Gefühl, dass das Mischen von TypedDicts- und Pydantic-Modellen unweigerlich zu Verwirrung führen würde – insbesondere für neue Ingenieure, die möglicherweise nicht wissen, welchem Schemaformat sie folgen sollen.
Um dieses Downside zu lösen, habe ich einen kleinen Helfer eingeführt, der ein Pydantic-Modell in ein TypedDict umwandelt, das erweitert wird AgentState kurz bevor es übergeben wird create_agent . Es ist wichtig zu beachten, dass LangChain benutzerdefinierte Metadaten an Typanmerkungen anhängt, die Sie beibehalten müssen. Python-Dienstprogramme wie get_type_hints() Entfernen Sie diese Anmerkungen, was bedeutet, dass eine naive Konvertierung nicht funktioniert.
Lektion 2: Deep Brokers sind von Natur aus eigensinnig
Neben dem Neuen create_agent Die API in LangChain 1.0 hat meine Aufmerksamkeit erregt: die deepagents Bibliothek. Inspiriert durch Instruments wie Claude Code und Manus können Deep Brokers planen, Aufgaben in Schritte unterteilen und sogar Subagenten erzeugen.
Als ich das zum ersten Mal sah, wollte ich es verwenden überall. Warum sollten Sie keine „intelligenteren“ Agenten wollen, oder? Aber nachdem ich es in mehreren Arbeitsabläufen ausprobiert hatte, wurde mir klar, dass diese zusätzliche Autonomie für meine Anwendungsfälle manchmal unnötig – und in bestimmten Fällen kontraproduktiv – conflict.
Der deepagents Die Bibliothek ist ziemlich eigensinnig und sehr bewusst gestaltet. Jeder Deep Agent verfügt über eine integrierte Middleware – Dinge wie ToDoListMiddleware, FilesystemMiddleware, SummarizationMiddlewareusw. Diese prägen die Artwork und Weise, wie der Agent den Kontext denkt, plant und verwaltet. Der Haken ist, dass Sie Kann ich nicht genau kontrollieren Wenn diese Normal-Middleware ausgeführt wird, können Sie auch diejenigen deaktivieren, die Sie nicht benötigen.
Nach dem Eingraben in die deepagents Quellcode Hierkönnen Sie sehen, dass der Middleware-Parameter lautet zusätzlich anzuwendende Middleware nach Normal-Middleware. Jegliche Middleware, die übergeben wurde middleware=(...) wird nach den Standardwerten angehängt.
All diese zusätzliche Orchestrierung führte auch zu spürbarer Latenz und brachte möglicherweise keinen nennenswerten Nutzen. Wenn Sie additionally eine detailliertere Kontrolle wünschen, bleiben Sie bei der einfacheren Lösung create_agent Verfahren.
Ich sage nicht, dass Deep Brokers schlecht sind, sie sind in den richtigen Szenarien mächtig. Dies ist jedoch eine gute Erinnerung an ein klassisches technisches Prinzip: Jagen Sie nicht dem „Glänzenden“ hinterher. Nutzen Sie die Technologie, die Ihr eigentliches Downside löst, auch wenn es die „weniger glamouröse“ Choice ist.
Mein Lieblingsfeature: Strukturierte Ausgabe
Beim Einsatz von Agenten in der Produktion, insbesondere solchen, die in deterministische Unternehmenssysteme integriert sind, conflict es von entscheidender Bedeutung, die Agenten dazu zu bringen, konsistent Ausgaben eines bestimmten Schemas zu erzeugen.
LangChain 1.0 macht dies ziemlich einfach. Sie können ein Schema definieren (z. B. ein Pydantic-Modell) und es übergeben create_agent über die response_format Parameter. Der Agent erzeugt dann eine Ausgabe, die diesem Schema entspricht innerhalb einer einzelnen Agentenschleife ohne zusätzliche Schritte.
Dies conflict immer dann unglaublich nützlich, wenn der Agent sich strikt an eine JSON-Struktur halten und bestimmte Felder garantieren muss. Bisher conflict auch die strukturierte Ausgabe sehr zuverlässig.
Worüber ich mehr erforschen möchte: Middleware
Einer der schwierigsten Aspekte beim Aufbau zuverlässiger Agenten ist Kontext-Engineering– Sicherstellen, dass der Agent immer zur richtigen Zeit über die richtigen Informationen verfügt. Middleware wurde eingeführt, um Entwicklern eine präzise Kontrolle über jeden Schritt der Agentenschleife zu geben, und ich denke, es lohnt sich, tiefer in die Materie einzutauchen.
Middleware kann je nach Kontext unterschiedliche Bedeutungen haben (Wortspiel beabsichtigt). In LangGraph kann dies bedeuten, die genaue Reihenfolge der Knotenausführung zu steuern. Bei langwierigen Gesprächen kann es erforderlich sein, den angesammelten Kontext vor dem nächsten LLM-Aufruf zusammenzufassen. In Human-in-the-Loop-Szenarien kann Middleware die Ausführung anhalten und darauf warten, dass ein Benutzer einen Device-Aufruf genehmigt oder ablehnt.
Vor Kurzem hat LangChain in der neuesten Nebenversion v1.1 auch eine Modellwiederholungs-Middleware mit konfigurierbarem exponentiellem Backoff hinzugefügt, die eine ordnungsgemäße Wiederherstellung bei vorübergehenden Endpunktfehlern ermöglicht.
Ich persönlich bin der Meinung, dass Middleware das Spiel verändert, da Agenten-Workflows komplexer, langwieriger und zustandsbehafteter werden, insbesondere wenn Sie eine differenzierte Kontrolle oder eine robuste Fehlerbehandlung benötigen.
Diese Liste der Middleware ist Anbau Und es hilft wirklich, dass es anbieterunabhängig bleibt. Wenn Sie in Ihrer eigenen Arbeit mit Middleware experimentiert haben, würde ich gerne hören, was Sie am nützlichsten fanden!
Zum Abschluss
Das ist alles für den Second – vier wichtige Überlegungen zu dem, was ich bisher über LangChain gelernt habe. Und falls jemand aus dem LangChain-Staff dies zufällig liest, freue ich mich jederzeit über ein Suggestions der Nutzer oder einfach per Chat 🙂
Viel Spaß beim Bauen!