tryAGI/LangChain: LangChain-Abstraktionen für .NET, mit SQLite-Vektordatenbank
C# implementation of LangChain. We try to be as close to the original as possible in terms of abstractions, but are open to new entities.
Auf einen Blick
- Was ist das?
- Der C#-Port von LangChain bildet Prompt-Templates, Retrieval und Chains nach und liefert eigene Provider für OpenAI und SQLite. Die Abstraktionen sind vertraut, die Reife des Projekts ist es nicht.
- Für wen ist es gedacht?
- Wer bereits in C# arbeitet und die LangChain-Abstraktionen kennt, findet hier eine MIT-lizenzierte Umsetzung mit eigenen Providern und einer SQLite-Vektordatenbank, die sich ohne externen Dienst betreiben lässt. Wer Produktionslast plant, sollte zuerst prüfen, ob die sechs Monate zwischen v0.13.0 und v0.15.0 zum eigenen Release-Zyklus passen, und ob die Dokumentation zu den von ihm benötigten Providern im Wiki oder in den Tests aktuell ist.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 4 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C#, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welche Lücke der Port in der .NET-Welt füllt
LangChain ist als Python-Bibliothek entstanden, und seine Abstraktionen (Prompts, Retriever, Chains, Document Loader) sind in dieser Form in .NET nicht vorhanden. Das Projekt tryAGI/LangChain beschreibt sich selbst als C#-Implementierung von LangChain, die sich laut README so nah wie möglich am Original orientiert, aber offen für neue Entitäten ist. Der Adressat sind damit .NET-Entwickler, die bereits mit den LangChain-Konzepten vertraut sind und diese in einer bestehenden C#-Codebasis weiterverwenden wollen, statt sie neu zu erfinden.
Bemerkenswert ist die ausdrückliche Abgrenzung zu Semantic Kernel. Das README nennt Semantic Kernel nützlich und sagt, das Projekt nutze es, wo immer möglich. Der eigentliche Anspruch lautet aber, dass Semantic Kernel nicht jedes Szenario abdeckt und eng an das Microsoft-Ökosystem gebunden ist. Der Port positioniert sich also nicht als Ersatz, sondern als Ergänzung für Fälle, in denen die Microsoft-Abstraktionen nicht passen. Diese Begründung stammt vom Projekt selbst und ist eine Selbsteinschätzung, keine unabhängig belegte Aussage.
Wie die Chain-Pipeline Daten durchreicht
Der Kern des Beispiels im README ist eine Pipeline aus Operatoren, die über den Pipe-Operator verbunden werden. Die Kette beginnt mit Set, das den Fragetext unter einem Schlüssel ablegt, standardmäßig text. Danach folgt RetrieveSimilarDocuments, das aus einer Vektorsammlung die fünf ähnlichsten Dokumente holt. CombineDocuments führt diese Dokumente zusammen und schreibt sie unter den Schlüssel context. Template füllt eine Prompt-Vorlage mit den Werten context und text. Am Ende steht LLM, das den fertigen Prompt an das Sprachmodell schickt. Ausgeführt wird das Ganze mit chain.RunAsync("text"), also über den Schlüssel, unter dem das Ergebnis erwartet wird.
Parallel dazu zeigt das README denselben Ablauf in imperativer Form: erst GetSimilarDocuments auf der Sammlung, dann ein selbst zusammengebauter Prompt-String an llm.GenerateAsync. Beide Wege greifen auf dieselben Bausteine zu. Wer die Kette nicht braucht, kann sie weglassen, ohne die darunterliegenden Objekte zu wechseln. Das ist der eigentliche Nutzen der Abstraktion: die Pipeline ist optional, nicht erzwungen.
Dokumente, Chunks und Vektoren in SQLite
Das README-Beispiel erzeugt die Vektordatenbank direkt aus einer PDF-Datei. AddDocumentsFromAsync bekommt einen PDF-Loader als Typparameter, dazu das Embedding-Modell, die Dimensionenzahl, eine Datenquelle und einen Sammlungsnamen. Die Dimensionen müssen zum Embedding-Modell passen; für TextEmbeddingV3SmallModel nennt das Beispiel 1536. Wird kein TextSplitter übergeben, greift laut README ein CharacterTextSplitter mit ChunkSize = 4000 und ChunkOverlap = 200. Die Datenquelle kann eine URL sein, im Beispiel ein PDF, das direkt von einer Schulwebsite geladen wird.
Als Speicher dient SqLiteVectorDatabase mit einem Dateipfad wie vectors.db. Damit läuft die Vektorsuche ohne externen Dienst, was für lokale Entwicklung und kleine Anwendungen praktisch ist. Der Preis dafür steht im gleichen Codeblock: Das Beispiel beziffert die Kosten für einen Durchlauf von null auf 0,015 US-Dollar, für einen erneuten Lauf bei vorhandener Datenbank auf 0,0004 US-Dollar. Diese Zahlen stammen aus einem Kommentar im README und beziehen sich auf das dortige Szenario. Sie sind keine Messung dieses Artikels und lassen sich nicht ohne Weiteres auf andere Dokumente oder Modelle übertragen.
Installation und die erste lauffähige Kette
Der Einstieg läuft über NuGet. Das README verlinkt das Paket LangChain in der Vorabversion, erkennbar am Pfad nuget.org/packages/LangChain und am Badge vpre. Für das gezeigte Beispiel sind laut Kommentar im Code drei Pakete nötig: LangChain, LangChain.Databases.Sqlite und LangChain.DocumentLoaders.Pdf. Der OpenAI-Schlüssel kommt aus der Umgebungsvariable OPENAI_API_KEY; das Beispiel wirft eine InconclusiveException, wenn sie nicht gesetzt ist.
Die Modelle werden über einen OpenAiProvider erzeugt, konkret OpenAiLatestFastChatModel und TextEmbeddingV3SmallModel. Für die Ausführung gibt es zwei Anlaufstellen: das Wiki unter tryagi.github.io/LangChain und, falls dessen Code veraltet ist, die WikiTests.cs im Verzeichnis src/Meta/test. Weitere Beispiele liegen unter examples, ein Readme-Test unter src/tests/LangChain.IntegrationTests/ReadmeTests.cs. Dass das Projekt selbst auf Tests als aktuelle Referenz verweist, ist ein ehrlicher Hinweis darauf, dass die Dokumentation nicht immer mit dem Code Schritt hält.
Was das Beispiel offen lässt
Das README zeigt einen einzigen Provider und einen einzigen Vektorspeicher. Ob und wie weitere Anbieter unterstützt werden, geht aus dem Material nicht hervor; die Aussage, man sei offen für Drittanbieter-Bibliotheken, bleibt eine Absichtserklärung. Wer einen anderen LLM-Anbieter oder eine andere Vektordatenbank braucht, muss das im Wiki oder im Quelltext selbst prüfen.
Auch die Release-Historie gibt Anlass zur Vorsicht. Die letzten drei im Material genannten Versionen sind v0.13.0 vom 6. März 2024, v0.14.0 vom 3. Mai 2024 und v0.15.0 vom 27. Juni 2024. Zwischen v0.13.0 und v0.15.0 liegen also rund dreieinhalb Monate, und alle drei tragen eine 0 vor dem Punkt. Das ist kein Urteil über die Qualität, aber ein Hinweis darauf, dass sich die öffentliche API zwischen Versionen ändern kann. Wer das Paket einsetzt, sollte die Version festnageln und Upgrades bewusst einplanen.
Schließlich sagt das README nichts über Fehlerbehandlung, Wiederholungsversuche bei Rate Limits oder das Verhalten bei fehlgeschlagenen Embedding-Aufrufen. Diese Themen tauchen im gezeigten Code nicht auf. Wer sie braucht, findet sie möglicherweise in den Tests, aber nicht in der Projektdokumentation.
Wann Semantic Kernel die bessere Wahl bleibt
Der wichtigste Unterschied zu Semantic Kernel liegt nicht im Funktionsumfang, sondern in der Bindung. Semantic Kernel kommt von Microsoft, ist auf das .NET-Ökosystem zugeschnitten und wird laut README von diesem Projekt selbst dort eingesetzt, wo es passt. Wer bereits Azure-Dienste, Dependency Injection nach Microsoft-Muster und die zugehörigen Konventionen nutzt, bekommt dort eine integrierte Lösung statt einer nachgebauten.
Der Unterschied im Ansatz zeigt sich am deutlichsten in der Chain-Syntax. Das README-Beispiel von tryAGI/LangChain baut eine Pipeline aus Set, RetrieveSimilarDocuments, CombineDocuments, Template und LLM, verbunden mit dem Pipe-Operator. Das ist eine eigene Kompositionsschicht, die es in Semantic Kernel in dieser Form nicht gibt. Wer diese Schreibweise aus Python kennt und schätzt, findet sie hier wieder. Wer sie nie gebraucht hat, zahlt mit einer zusätzlichen Abstraktion, die er nicht nutzt. Die Entscheidung hängt also weniger davon ab, welches Projekt mehr kann, sondern davon, ob die LangChain-Denkweise zum eigenen Code passt.
Lizenz, Wartung und der offene Punkt bei den Providern
Das Projekt steht unter der MIT-Lizenz. Das README hält ausdrücklich fest, dass keine Lizenzänderung für dieses Projekt geplant ist, weist aber darauf hin, dass Projekte innerhalb derselben Organisation andere Lizenzen haben können. Wer das Paket einbettet, sollte also nicht nur die LICENSE-Datei dieses Repositorys prüfen, sondern auch die der mitgelieferten Abhängigkeiten. Das ist keine Rechtsberatung, sondern ein Hinweis auf die Stelle, an der man nachsehen muss.
Zur Wartung äußert sich das README ungewöhnlich offen. Der Maintainer schreibt, er werde allein kaum ernsthaft vorankommen, und nennt als Ziel, C#-Entwickler zu bündeln und die Qualität des Ergebnisses zu kontrollieren. Er will Pull Requests möglichst innerhalb von 24 Stunden annehmen und sucht Entwickler für das Kernteam, die er nach Möglichkeit unterstützen und an Einnahmen beteiligen will. Diese Sätze sind eine Selbstdarstellung des Projekts, keine Zusage. Sie sagen aber etwas darüber, wie die Wartung organisiert ist: als offene Einladung, nicht als bezahltes Team.
Das erklärt auch, warum das README bei den Tests auf die aktuelle Referenz verweist, statt sich auf das Wiki zu verlassen. Für die Upgrade-Kosten bedeutet das: Wer das Paket über mehrere Versionen hinweg aktualisiert, sollte den Diff der öffentlichen Typen prüfen und die Integrationstests des Projekts als Orientierung nehmen, nicht die Wiki-Seiten. Der genaue Aufwand lässt sich aus dem Material nicht ableiten, weil keine Änderungsprotokolle oder Migrationshinweise enthalten sind.
Redaktionelles Fazit
Wer bereits in C# arbeitet und die LangChain-Abstraktionen kennt, findet hier eine MIT-lizenzierte Umsetzung mit eigenen Providern und einer SQLite-Vektordatenbank, die sich ohne externen Dienst betreiben lässt. Wer Produktionslast plant, sollte zuerst prüfen, ob die sechs Monate zwischen v0.13.0 und v0.15.0 zum eigenen Release-Zyklus passen, und ob die Dokumentation zu den von ihm benötigten Providern im Wiki oder in den Tests aktuell ist. Für Teams, die ausschließlich im Microsoft-Ökosystem bleiben, ist Semantic Kernel die passendere Wahl.
Community-Notizen