Neben den beeindruckenden Projekten hat uns die Erfahrung bei Cal Hacks 12.0 auch etwas ebenso Wertvolles gebracht: schnelles, unverfälschtes Feedback von Entwicklern, die zum ersten Mal mit unserem Stack in Berührung kamen. Hackathons sind einzigartige Drucktests mit engen Zeitvorgaben, keinerlei Vorkenntnissen und unvorhersehbaren Hindernissen (wie den berüchtigten WLAN-Ausfällen). Sie zeigen genau, wo die Entwicklererfahrung glänzt und wo noch Verbesserungsbedarf besteht. Dies ist heute umso wichtiger, da Entwickler auf neue Weise mit dem Elastic Stack interagieren, zunehmend über LLM-gesteuerte Workflows. In diesem Blogbeitrag werden wir genauer darauf eingehen, was die Teilnehmer mit Agent Builder erstellt haben und was wir dabei gelernt haben.

Die Gewinnerprojekte

Erster Platz: AgentOverflow

Stack Overflow neu entwickelt für die LLM- und Agentenära.

Lesen Sie hier mehr über AgentOverflow.

AgentOverflow löst ein Problem, mit dem die meisten KI-Entwickler konfrontiert sind: LLMs halluzinieren, Chatverläufe verschwinden, und Entwickler verschwenden Zeit damit, dieselben Probleme immer wieder zu lösen.

AgentOverflow erfasst, validiert und präsentiert reale Problem-Lösungs-Paare, damit Entwickler die Illusionsspirale durchbrechen und schneller Ergebnisse liefern können.

So funktioniert es:

1. JSON teilen – das „Lösungsschema“.

Ein Klick auf eine Claude-Freigabe extrahiert und erstellt eine Share Solution JSON-Datei in einem strukturierten Format, das Folgendes enthält:

• Problem

• Kontext

• Code

• Tags

• Die Lösungsschritte wurden verifiziert.

Ein Validator (LAVA) prüft und erzwingt die Struktur, der Benutzer fügt eine Zeile zusätzlichen Kontexts hinzu, dann wird das Ganze in Elasticsearch gespeichert und indiziert.

2. Lösung finden

Wenn Sie nicht weiterkommen, klicken Sie auf Find Solution AgentOverflow extrahiert dann Ihre aktuelle Konversation, erstellt daraus eine Abfrage und führt eine hybride Elasticsearch-Suche durch, um Folgendes anzuzeigen:

• Rangliste, von der Community validierte Korrekturen

• Die genauen Eingabeaufforderungen, die das Problem ursprünglich gelöst haben

Dies ermöglicht es Entwicklern, ihre aktuelle Sitzung schnell zu kopieren, einzufügen und zu entsperren.

3. MCP – Kontextinjektion für LLMs

Durch die Anbindung an die in Elasticsearch gespeicherten strukturierten Lösungen über MCP (Model Context Protocol) erhalten LLMs zur Laufzeit einen hochsignifikanten Kontext (Code, Protokolle, Konfigurationen, vorherige Korrekturen) ohne zusätzliche Störungen.

AgentOverflow verwendet Agent Builder mit Elasticsearch als strukturierte Speicherschicht, die relevanten Kontext in LLMs einfügt. Dadurch werden sie von passiven Chatbots zu kontextsensitiven Problemlösern.

Zweiter Platz: MarketMind

Eine in Echtzeit interpretierbare Darstellung der Marktenergie, ermöglicht durch sechs elastische Agenten.

Lesen Sie hier mehr über MarketMind.

MarketMind hat sich seinen Platz verdient, indem es unerfahrenen Händlern eine Plattform bietet, die fragmentierte Marktdaten in klare Echtzeitsignale umwandelt. Anstatt Kursentwicklung, Fundamentaldaten, Stimmung und Volatilität über verschiedene Tools hinweg zu jonglieren, konsolidiert MarketMind all diese Informationen auf einer einzigen Plattform und hilft Händlern so, umsetzbare Erkenntnisse zu gewinnen. Dieses Projekt verwendete beim Erstellen seiner Agenten auch einige komplexe ES|QL-Abfragen.

So funktioniert es:

1. Marktdaten in Echtzeit erfassen

MarketMind bezieht Kursdaten, Fundamentaldaten, Stimmungsanalysen, Volatilitäts- und Risikokennzahlen von Yahoo Finance. Diese Daten werden erfasst und in mehreren Elasticsearch-Indizes organisiert.

2. Sechs spezialisierte Agenten analysieren den Markt.

Jeder mit Agent Builder erstellte Agent konzentriert sich auf eine andere Marktebene. Sie lesen Daten aus einem Elasticsearch-Index, berechnen ihre eigenen domänenspezifischen Metriken und generieren eine standardisierte JSON-Ausgabe mit Bewertungen und Begründungen.

3. Signale in einem einheitlichen „Marktenergie“-Modell aggregieren

Die kombinierten Ergebnisse erscheinen als leuchtende Impulse um jede Aktie herum und veranschaulichen, ob sich die Dynamik verstärkt, das Risiko steigt oder sich die Stimmung ändert.

4. Erkenntnisse visualisieren

Das Frontend wurde mit React und Next.js unter Verwendung von TypeScript, SVG-basierten physikbasierten Visualisierungen und Chart.js für Live-Candlestick-Charts erstellt. Dadurch wird die Rohanalyse in direkt umsetzbares Feedback in Echtzeit umgewandelt.

Weitere interessante Projekte:

Hier sind einige weitere starke Konkurrenten, die Elastic in verschiedenen Teilen ihres Technologie-Stacks eingesetzt haben:

Die vollständige Liste der Projekte, die in unserem Wettbewerb eingereicht wurden, finden Sie hier.

Was wir von Entwicklern gelernt haben

• Agent Builder ist benutzerfreundlich:

Die meisten Teams hatten Elastic noch nie zuvor benutzt und waren dennoch in der Lage, mit wenig Unterstützung schnell Agenten zu erstellen. Wir haben einen Workshop für diejenigen veranstaltet, die mehr Unterstützung benötigten, aber die meisten waren in der Lage, ihre Daten zu erfassen und einen Agenten zu erstellen, der Aktionen auf diesen Daten durchführt.

• LLMs sind hervorragend in kNN -Abfragen, benötigen aber dennoch Unterstützung bei der Generierung von ES|QL:

Die Aufforderung an ChatGPT-5, ES|QL-Abfragen zu generieren, lieferte falsche Informationen, wobei häufig ES|QL und SQL vermischt wurden. Die Bereitstellung der Dokumente in einer Markdown-Datei für das LLM schien eine praktikable Lösung zu sein.

• Nur für Snapshots verfügbare ES|QL-Funktionen in die Dokumentation gelangten:

Die kommenden Aggregationsfunktionen FIRST und LAST sind versehentlich in unsere ES|QL-Dokumentation eingeschlichen. Da wir diese Dokumente an ChatGPT übermittelt haben, nutzte das Modell diese Funktionen pflichtgemäß, obwohl sie in Serverless noch nicht verfügbar sind. Dank des Feedbacks der Gruppe hat das Entwicklungsteam schnell einen Fix erstellt und zusammengeführt, um die Funktionen aus der veröffentlichten Dokumentation zu entfernen (PR #137341).

• Fehlende Serverless-spezifische Anleitung:

Ein Team versuchte, LOOKUP JOIN für einen Index zu aktivieren, der nicht im Lookup-Modus erstellt wurde. Die Fehlermeldung veranlasste sie, Befehle zu verfolgen, die auf Serverless nicht existieren. Wir haben dies dem Produktteam mitgeteilt, das umgehend einen Fix für eine Serverless-spezifische, umsetzbare Fehlermeldung erstellt hat. Längerfristig besteht die Vision darin, die Komplexität der Neuindizierung vollständig zu verbergen (Problem #4838).

• Wert von Präsenzveranstaltungen:

Online-Hackathons sind toll, aber nichts kommt an den schnellen Feedback-Loop heran, den man erhält, wenn man Seite an Seite mit Entwicklern Fehler behebt. Wir haben beobachtet, wie Teams Agent Builder in verschiedenen Anwendungsfällen integriert haben, festgestellt, wo die Entwicklererfahrung mit ES|QL verbessert werden konnte, und Probleme viel schneller behoben, als dies über asynchrone Kanäle zu versuchen.

Fazit

Cal Hacks 12.0 bot uns mehr als ein Wochenende voller cooler Demos; es gab uns auch Einblick in die Art und Weise, wie neue Entwickler mit dem Elastic Stack interagieren. Innerhalb von nur 36 Stunden sahen wir, wie Teams Agent Builder einsetzten, Daten in Elasticsearch einspielten, Multiagentensysteme entwarfen und unsere Funktionen auf vielfältige Weise testeten. Die Veranstaltung erinnerte uns auch daran, warum Präsenzveranstaltungen so wichtig sind. Die schnellen Feedbackschleifen, die echten Gespräche und das praktische Debugging halfen uns, die aktuellen Bedürfnisse der Entwickler zu verstehen. Wir freuen uns darauf, das Gelernte an das Ingenieurteam weiterzugeben. Wir sehen uns beim nächsten Hackathon.

In diesem Blogbeitrag verwenden wir Mastra , um einen Wissensagenten zu entwickeln, der sich merkt, was Benutzer sagen, und relevante Informationen später abrufen kann. Als Speicher- und Abruf-Backend nutzen wir Elasticsearch. Dieses Konzept lässt sich problemlos auf reale Anwendungsfälle übertragen. Man denke beispielsweise an Supportmitarbeiter, die sich an frühere Gespräche und Lösungen erinnern können, sodass sie ihre Antworten auf bestimmte Benutzer zuschneiden oder Lösungen schneller auf Basis des vorherigen Kontextes präsentieren können.

Folgen Sie dieser Anleitung, um zu sehen, wie Sie es Schritt für Schritt bauen können. Falls Sie nicht weiterkommen oder einfach nur ein fertiges Beispiel ausführen möchten, schauen Sie sich das Repository hier an.

Was ist Mastra?

Mastra ist ein Open-Source-TypeScript-Framework zum Erstellen von KI-Agenten mit austauschbaren Teilen für Schlussfolgerungen, Speicher und Werkzeuge. Die semantische Abruffunktion ermöglicht es Agenten, vergangene Interaktionen zu erinnern und abzurufen, indem Nachrichten als Einbettungen in einer Vektordatenbank gespeichert werden. Dies ermöglicht es den Agenten, den Gesprächskontext und die Kontinuität langfristig aufrechtzuerhalten. Elasticsearch ist ein hervorragender Vektorspeicher, um diese Funktion zu ermöglichen, da er eine effiziente dichte Vektorsuche unterstützt. Wenn der semantische Abruf ausgelöst wird, ruft der Agent relevante vergangene Nachrichten in das Kontextfenster des Modells ab, sodass das Modell diesen abgerufenen Kontext als Grundlage für seine Schlussfolgerungen und Antworten nutzen kann.

Was Sie für den Einstieg benötigen

• Node v18+

• Elasticsearch (Version 8.15 oder neuer)

• Elasticsearch API-Schlüssel

• OpenAI API-Schlüssel

Hinweis: Sie benötigen dies, da die Demo den OpenAI-Provider verwendet. Mastra unterstützt jedoch auch andere KI-SDKs und Community-Modell-Provider, sodass Sie ihn je nach Ihrer Konfiguration problemlos austauschen können.

Aufbau eines Mastra-Projekts

Wir werden die integrierte CLI von Mastra verwenden, um das Grundgerüst für unser Projekt bereitzustellen. Führen Sie folgenden Befehl aus:

Sie erhalten eine Reihe von Eingabeaufforderungen, beginnend mit:

1. Gib deinem Projekt einen Namen.

2. Wir können diese Standardeinstellung beibehalten; Sie können dieses Feld gerne leer lassen.

3. Für dieses Projekt verwenden wir ein von OpenAI bereitgestelltes Modell.

4. Wählen Sie die Option „Jetzt überspringen“, da wir alle unsere Umgebungsvariablen in einer `.env`-Datei speichern, die wir in einem späteren Schritt konfigurieren werden.

5. Diese Option können wir auch überspringen.

Sobald dieser Initialisierungsprozess abgeschlossen ist, können wir zum nächsten Schritt übergehen.

Abhängigkeiten installieren

Als Nächstes müssen wir einige Abhängigkeiten installieren:

• ai - Core AI SDK-Paket, das Werkzeuge zur Verwaltung von KI-Modellen, Eingabeaufforderungen und Arbeitsabläufen in JavaScript/TypeScript bereitstellt. Mastra basiert auf dem AI SDK von Vercel, daher benötigen wir diese Abhängigkeit, um Modellinteraktionen mit Ihrem Agenten zu ermöglichen.

• @ai-sdk/openai - Plugin, das das AI SDK mit OpenAI-Modellen (wie GPT-4, GPT-4o usw.) verbindet und API-Aufrufe mit Ihrem OpenAI-API-Schlüssel ermöglicht.

• @elastic/elasticsearch - Offizieller Elasticsearch-Client für Node.js, Wird verwendet, um eine Verbindung zu Ihrer Elastic Cloud oder Ihrem lokalen Cluster für Indizierungs-, Such- und Vektoroperationen herzustellen.

• dotenv Lädt Umgebungsvariablen aus einer .env-Datei Datei in process.env, ermöglicht das sichere Einfügen von Anmeldeinformationen wie API-Schlüsseln und Elasticsearch-Endpunkten.

Konfiguration von Umgebungsvariablen

Erstellen Sie eine .env -Datei in Ihrem Projektstammverzeichnis, falls dort noch keine vorhanden ist. Alternativ können Sie das von mir im Repository bereitgestellte Beispiel .env kopieren und umbenennen. In dieser Datei können wir die folgenden Variablen hinzufügen:

Damit ist die grundlegende Einrichtung abgeschlossen. Von hier aus können Sie bereits mit dem Erstellen und Orchestrieren von Agenten beginnen. Wir gehen noch einen Schritt weiter und fügen Elasticsearch als Speicher- und Vektorsuchschicht hinzu.

Elasticsearch als Vektorspeicher hinzufügen

Erstellen Sie einen neuen Ordner namens stores und fügen Sie darin diese Datei ein. Bevor Mastra und Elastic eine offizielle Elasticsearch-Vektorspeicherintegration veröffentlichten, teilte Abhi Aiyer(CTO von Mastra) diese frühe Prototypklasse mit dem Namen ElasticVector. Vereinfacht gesagt verbindet es die Speicherabstraktion von Mastra mit den dichten Vektorfunktionen von Elasticsearch, sodass Entwickler Elasticsearch als Vektordatenbank für ihre Agenten verwenden können.

Werfen wir einen genaueren Blick auf die wichtigen Aspekte der Integration:

Aufnahme des Elasticsearch-Clients

Dieser Abschnitt definiert die Klasse ElasticVector und richtet die Elasticsearch-Clientverbindung mit Unterstützung für Standard- und serverlose Bereitstellungen ein.

• ElasticVectorConfig extends ClientOptionsDadurch wird eine neue Konfigurationsschnittstelle erstellt, die alle Elasticsearch-Clientoptionen (wie node, auth, requestTimeout) erbt und unsere benutzerdefinierten Eigenschaften hinzufügt. Das bedeutet, dass Benutzer jede gültige Elasticsearch-Konfiguration zusammen mit unseren serverlosen Optionen übergeben können.

• extends MastraVectorDies ermöglicht es ElasticVector von Mastras Basisklasse MastraVector zu erben, die eine gemeinsame Schnittstelle darstellt, der alle Vektorspeicherintegrationen entsprechen. Dadurch wird sichergestellt, dass sich Elasticsearch aus Sicht des Agenten wie jedes andere Mastra-Vektor-Backend verhält.

• private client: ClientDies ist eine private Eigenschaft, die eine Instanz des Elasticsearch JavaScript-Clients enthält. Dadurch kann die Klasse direkt mit Ihrem Cluster kommunizieren.

• isServerless und deploymentChecked: Diese Eigenschaften arbeiten zusammen, um zu erkennen und zwischenzuspeichern, ob wir mit einer serverlosen oder einer Standard-Elasticsearch-Bereitstellung verbunden sind. Diese Erkennung erfolgt automatisch bei der ersten Nutzung oder kann explizit konfiguriert werden.

• constructor(config: ClientOptions)Dieser Konstruktor nimmt ein Konfigurationsobjekt entgegen (das Ihre Elasticsearch-Zugangsdaten und optionale Serverless-Einstellungen enthält) und verwendet es, um den Client in der Zeile this.client = new Client(config) zu initialisieren.

• super(): Dadurch wird der Basiskonstruktor von Mastra aufgerufen, sodass Logging, Validierungshilfsmechanismen und andere interne Hooks geerbt werden.

Zu diesem Zeitpunkt weiß Mastra, dass es einen neuen Vektor-Shop namens gibt. ElasticVector

Erkennung des Bereitstellungstyps

Vor dem Erstellen von Indizes erkennt der Adapter automatisch, ob Sie Elasticsearch Standard oder Elasticsearch Serverless verwenden. Dies ist wichtig, da serverlose Bereitstellungen keine manuelle Shard-Konfiguration zulassen.

Was passiert:

• Zuerst wird geprüft, ob Sie isServerless explizit in der Konfiguration festgelegt haben (überspringt die automatische Erkennung).

• Ruft die info() -API von Elasticsearch auf, um Clusterinformationen zu erhalten.

• Prüft den Wert build_flavor field (serverlose Bereitstellungen geben serverless zurück)

• Falls die Build-Variante nicht verfügbar ist, wird auf die Überprüfung des Slogans zurückgegriffen.

• Speichert das Ergebnis im Cache, um wiederholte API-Aufrufe zu vermeiden.

• Wird standardmäßig die Bereitstellung durchgeführt, wenn die Erkennung fehlschlägt.

Anwendungsbeispiel:

Erstellen des „Speichers“ in Elasticsearch

Die folgende Funktion richtet einen Elasticsearch-Index zum Speichern von Einbettungen ein. Es wird geprüft, ob der Index bereits existiert. Andernfalls wird eine solche mit der unten stehenden Zuordnung erstellt, die ein dense_vector -Feld zum Speichern von Einbettungen und benutzerdefinierten Ähnlichkeitsmetriken enthält.

Einige Dinge sind zu beachten:

• Der Parameter dimension gibt die Länge des jeweiligen Einbettungsvektors an und hängt davon ab, welches Einbettungsmodell Sie verwenden. In unserem Fall generieren wir Einbettungen mithilfe des text-embedding-3-small -Modells von OpenAI, das Vektoren der Größe 1536 ausgibt. Dies werden wir als Standardwert verwenden.

• Die in der folgenden Zuordnung verwendete Variable similarity wird durch die Hilfsfunktion const similarity = this.mapMetricToSimilarity(metric) definiert, welche den Wert für den Parameter metric entgegennimmt und ihn in ein Elasticsearch-kompatibles Schlüsselwort für die gewählte Distanzmetrik umwandelt.

  • Zum Beispiel: Mastra verwendet allgemeine Begriffe für Vektorähnlichkeit wie cosine, euclidean, und dotproduct. Würden wir die Metrik euclidean direkt in das Elasticsearch-Mapping einfügen, würde dies einen Fehler auslösen, da Elasticsearch erwartet, dass das Schlüsselwort l2_norm die euklidische Distanz repräsentiert.

• Serverless-Kompatibilität: Der Code lässt Shard- und Replikateinstellungen für serverlose Bereitstellungen automatisch aus, da diese von Elasticsearch Serverless automatisch verwaltet werden.

Speichern einer neuen Erinnerung oder Notiz nach einer Interaktion

Diese Funktion nimmt die nach jeder Interaktion neu generierten Einbettungen zusammen mit den Metadaten entgegen und fügt sie anschließend mithilfe der bulk -API von Elastic in den Index ein oder aktualisiert sie. Die bulk API bündelt mehrere Schreibvorgänge in einer einzigen Anfrage; diese Verbesserung unserer Indexierungsleistung stellt sicher, dass Aktualisierungen effizient bleiben, während der Speicher unseres Agenten immer größer wird.

Abfrage ähnlicher Vektoren für semantische Wiedererkennung

Diese Funktion ist der Kern des semantischen Recall-Features. Der Agent verwendet eine Vektorsuche, um ähnliche gespeicherte Einbettungen in unserem Index zu finden.

Unter der Haube:

• Führt eine kNN- Abfrage (k-nächste Nachbarn) mit Hilfe der knn -API in Elasticsearch aus.

• Gibt die K ähnlichsten Vektoren zum Eingabeabfragevektor zurück.

• Optional können Metadatenfilter angewendet werden, um die Ergebnisse einzugrenzen (z. B. nur innerhalb einer bestimmten Kategorie oder eines bestimmten Zeitraums zu suchen).

• Gibt strukturierte Ergebnisse zurück, einschließlich der Dokument-ID, des Ähnlichkeitswerts und der gespeicherten Metadaten.

Erstellung des Wissensagenten

Nachdem wir nun die Verbindung zwischen Mastra und Elasticsearch durch die ElasticVector -Integration kennengelernt haben, erstellen wir den Knowledge Agent selbst.

Erstellen Sie im Ordner agents eine Datei namens knowledge-agent.ts. Wir können damit beginnen, unsere Umgebungsvariablen zu verbinden und den Elasticsearch-Client zu initialisieren.

Hier, wir:

• Verwenden Sie dotenv um unsere Variablen aus unserer .env -Datei zu laden.

• Prüfen Sie, ob die Elasticsearch-Zugangsdaten korrekt eingefügt werden, dann können wir eine erfolgreiche Verbindung zum Client herstellen.

• Übergeben Sie den Elasticsearch-Endpunkt und den API-Schlüssel an den ElasticVector -Konstruktor, um eine Instanz unseres zuvor definierten Vektorspeichers zu erstellen.

• Optional können Sie isServerless: true angeben, wenn Sie Elasticsearch Serverless verwenden. Dadurch wird der automatische Erkennungsschritt übersprungen und die Startzeit verkürzt. Wird dieser Parameter weggelassen, erkennt der Adapter Ihren Bereitstellungstyp bei der ersten Verwendung automatisch.

Als nächstes können wir den Agenten mithilfe der Klasse Agent von Mastra definieren.

Folgende Felder können wir definieren:

• name und instructions: Gib ihr eine Identität und eine primäre Funktion.

• modelWir verwenden OpenAIs gpt-4o über das @ai-sdk/openai -Paket.

• memory:

  • vector: Verweist auf unseren Elasticsearch-Speicher, sodass Einbettungen dort gespeichert und abgerufen werden.

  • embedderWelches Modell soll zur Generierung von Einbettungen verwendet werden?

  • semanticRecall Die Optionen bestimmen, wie der Rückruf funktioniert:

    • topK: Wie viele semantisch ähnliche Nachrichten sollen abgerufen werden?

    • messageRange: Wie viel vom Gespräch soll bei jedem Spielzug einbezogen werden?

    • scope: Definiert die Speichergrenze.

Fast fertig. Wir müssen diesen neu erstellten Agenten lediglich zu unserer Mastra-Konfiguration hinzufügen. Importieren Sie in der Datei mit dem Namen index.ts den Wissensagenten und fügen Sie ihn in das Feld agents ein.

Zu den weiteren Bereichen gehören:

• storageDies ist Mastras interner Datenspeicher für Laufzeitverlauf, Observability-Metriken, Scores und Caches. Weitere Informationen zu Mastra-Speicherlösungen finden Sie hier.

• loggerMastra verwendet Pino, einen leichtgewichtigen, strukturierten JSON-Logger. Es erfasst Ereignisse wie Agentenstart und -stopp, Toolaufrufe und -ergebnisse, Fehler und LLM-Reaktionszeiten.

• observability: Steuert die KI-Verfolgung und die Sichtbarkeit der Ausführung von Agenten. Es verfolgt:

  • Beginn/Ende jedes Denkschritts.

  • Welches Modell oder Werkzeug wurde verwendet?

  • Ein- und Ausgänge.

  • Bewertungen und Beurteilungen

Testen des Agenten mit Mastra Studio

Glückwunsch! Wenn Sie es bis hierher geschafft haben, sind Sie bereit, diesen Agenten auszuführen und seine semantischen Erinnerungsfähigkeiten zu testen. Zum Glück bietet Mastra eine integrierte Chat-Benutzeroberfläche, sodass wir keine eigene entwickeln müssen.

Um den Mastra-Entwicklungsserver zu starten, öffnen Sie ein Terminal und führen Sie folgenden Befehl aus:

Nach der ersten Bündelung und dem Start des Servers sollte Ihnen eine Adresse für den Playground bereitgestellt werden.

Fügen Sie diese Adresse in Ihren Browser ein, und Sie gelangen zum Mastra Studio.

Wählen Sie die Option für knowledgeAgent und legen Sie los.

Um schnell zu prüfen, ob alles richtig verkabelt ist, geben Sie ihm beispielsweise folgende Information: „Das Team gab bekannt, dass die Umsatzentwicklung im Oktober um 12 % gestiegen ist, hauptsächlich aufgrund von Vertragsverlängerungen im Unternehmensbereich.“ Der nächste Schritt besteht darin, die Kundenansprache auf mittelständische Unternehmen auszuweiten.“ Starten Sie anschließend einen neuen Chat und stellen Sie eine Frage wie: „Auf welches Kundensegment sollten wir uns als Nächstes konzentrieren?“ Der Wissensagent sollte in der Lage sein, die Informationen aus dem ersten Chat abzurufen. Sie sollten eine Antwort wie diese sehen:

Eine solche Antwort bedeutet, dass der Agent unsere vorherige Nachricht erfolgreich als Einbettungen in Elasticsearch gespeichert und später mithilfe der Vektorsuche abgerufen hat.

Überprüfung des Langzeitspeichers des Agenten

Wechseln Sie im Mastra Studio zur Registerkarte memory in der Konfiguration Ihres Agenten. So können Sie sehen, was Ihr Agent im Laufe der Zeit gelernt hat. Jede Nachricht, Antwort und Interaktion, die in Elasticsearch eingebettet und gespeichert wird, wird Teil dieses Langzeitgedächtnisses. Sie können vergangene Interaktionen semantisch durchsuchen, um schnell erinnerte Informationen oder Kontexte wiederzufinden, die der Agent zuvor gelernt hat. Dies ist im Wesentlichen derselbe Mechanismus, den der Agent beim semantischen Abruf verwendet, aber hier können Sie ihn direkt untersuchen. In unserem unten stehenden Beispiel suchen wir nach dem Begriff „Vertrieb“ und erhalten jede Interaktion zurück, die etwas mit Vertrieb zu tun hat.

Fazit

Durch die Verbindung von Mastra und Elasticsearch können wir unseren Agenten Speicher zur Verfügung stellen, was eine wichtige Ebene im Kontext-Engineering darstellt. Mithilfe des semantischen Abrufs können Agenten im Laufe der Zeit Kontext aufbauen und ihre Antworten auf dem basieren, was sie gelernt haben. Das bedeutet genauere, zuverlässigere und natürlichere Interaktionen.

Diese frühe Integration ist nur der Ausgangspunkt. Das gleiche Prinzip kann hier Support-Mitarbeitern ermöglichen, die sich an frühere Tickets erinnern, internen Bots, die relevante Dokumente abrufen, oder KI-Assistenten, die sich mitten im Gespräch an Kundendetails erinnern können. Wir arbeiten außerdem an einer offiziellen Mastra-Integration, wodurch diese Verbindung in naher Zukunft noch nahtloser wird.

Wir sind gespannt, was Sie als Nächstes entwickeln werden. Probieren Sie es aus, erkunden Sie Mastra und seine Speicherfunktionen und teilen Sie Ihre Entdeckungen gerne mit der Community.

1. Verwendung der _mapping -API zum Abrufen von Feldinformationen

2. Verwendung der _search API zum Anzeigen von Feldwerten

3. Unterfelder anzeigen

4. Synthetisches Feld „_source“

5. Laufzeitfelder

1. Verwendung der _mapping-API zum Abrufen von Feldinformationen

Die _mapping API ermöglicht es Ihnen, die Mapping-Definition für einen oder mehrere Indizes abzurufen. Dies umfasst Informationen über die Felder, ihre Datentypen und weitere Eigenschaften. Um die Zuordnung für einen bestimmten Index abzurufen, verwenden Sie die folgende Anfrage:

Wenn Sie beispielsweise einen Index mit dem Namen my_index haben, können Sie dessen Zuordnung mit der folgenden Anfrage abrufen:

Die Antwort enthält die Mapping-Definition für den Index, die Informationen über die Felder und deren Eigenschaften enthält.

Es ist auch möglich, die Zuordnung eines bestimmten Feldes abzurufen. Dies kann nützlich sein, wenn Ihre Kartierung recht umfangreich ist und Sie sich nur auf ein bestimmtes Feld konzentrieren möchten. Um die Zuordnung eines bestimmten Feldes abzurufen, verwenden Sie die folgende Anfrage:

Sie können die Zuordnungen mehrerer Felder auch abrufen, indem Sie deren Namen durch Kommas trennen, wie in der folgenden Anfrage:

2. Verwenden der _search-API zum Anzeigen von Feldwerten

Um die Werte von Feldern in einem Elasticsearch-Index anzuzeigen, können Sie die _search API verwenden. Die _search API bietet Ihnen mehrere Möglichkeiten, die zurückgegebenen Felder zu steuern; die beiden wichtigsten sind:

1. _sourceDas Feld _source enthält den ursprünglichen JSON-Dokumentkörper genau so, wie er indexiert wurde, einschließlich aller Änderungen, die durch Ingestionspipelines oder Vorverarbeitungsschritte vorgenommen wurden. Um bestimmte Felder aus dem Quelldokument anzuzeigen, implementieren Sie eine Quellfilterung, wie wir im Folgenden sehen werden.

2. fieldsMit dem Parameter fields können Sie beim Durchführen einer Suche bestimmte Felder aus Ihren Dokumenten auf Basis der Indexzuordnung abrufen. Im Gegensatz zu _source kann fields auch Werte aus gespeicherten Feldern, Dokumentwerten oder Laufzeitfeldern zurückgeben, ohne auf _source zu verweisen. Für Standardfelder ohne Dokumentwerte oder gespeicherte Einstellungen wird jedoch auf _source zurückgegriffen. Dies kann viele Vorteile mit sich bringen, wie zum Beispiel eine höhere Leistungsfähigkeit und mehr, wie wir im Folgenden sehen werden.

Verwendung des Feldes _source

Standardmäßig gibt die _search -API das Feld _source zurück, welches das ursprüngliche, indizierte JSON-Dokument enthält. Um bestimmte Felder anzuzeigen, können Sie Filter im Parameter _source der Suchanfrage hinzufügen; dies wird als Quellfilterung bezeichnet.

Hier ist ein Beispiel für eine Suchanfrage, die die Werte der Felder title und author für Dokumente im Index my_index zurückgibt:

In diesem Beispiel gibt der Parameter _source die zurückzugebenden Felder an.

Falls Sie noch mehr Kontrolle benötigen, können Sie die Eigenschaften includes und excludes des Objekts _source verwenden. Beispielsweise gibt die folgende Abfrage das Feld der obersten Ebene title und alle Unterfelder von author außer author.description zurück.

In diesem Beispiel verwenden wir das Muster author.* , um jedes direkte Unterfeld des Objekts author abzurufen. Dann schließen wir author.description explizit aus, sodass nur die übrigen Autorenfelder zurückgegeben werden. Beachten Sie, dass dies keine Leistungsverbesserungen mit sich bringt, da das Quell-JSON weiterhin geladen und analysiert werden muss, aber es kann die Größe der über das Netzwerk gesendeten Antwort verringern.

Verwendung des Parameters „fields“

Mit dem Parameter fields können Sie die in der Suchergebnisseinduktion zurückgegebenen Felder filtern. Die Verwendung fields anstelle von _source bietet mehrere Vorteile, darunter:

• Verbesserte Performance: fields kann Werte direkt aus gespeicherten Feldern oder Dokumentwerten zurückgeben, ohne die vollständige _source laden zu müssen, wodurch die Größe der Antwortnutzlast kleiner wird.

• Formatierte Ausgabe: Bei Standardfeldern kann fields auf _source zurückgreifen, um die Werte zu erfassen. Dabei wird jedoch die Indexzuordnung herangezogen, um die Ausgabe korrekt zu formatieren, z. B. formatierte Datumsangaben, sodass sie mit den für Aggregationen und Sortierungen verwendeten Formaten konsistent sind.

• Zugriff auf Laufzeitfelder: fields kann Laufzeitfelder zurückgeben, die im ursprünglichen _source nicht existieren.

• Weitere Vorteile finden Sie hier.

Um beispielsweise nur die Felder title und author im Index my_index zurückzugeben, können Sie die folgende Suchanfrage verwenden:

In der obigen Abfrage setzen wir das Feld _source auf false, damit wir das Quelldokument nicht zurückgeben. Dadurch kann die Nutzlastgröße der Antwort drastisch reduziert werden. Beachten Sie jedoch, dass dies nur funktioniert, weil die Felder title und author vom Feldtyp keyword sind, bei dem standardmäßig doc_values aktiviert ist. Wenn das Feld doc_values nicht aktiviert hat und _source auf false gesetzt ist, hat Elasticsearch keine Möglichkeit, diese abzurufen, und sie werden in der Antwort übersprungen.

Wichtig zu beachten ist, dass die fields -Antwort immer ein Array von Werten für jedes Feld zurückgibt, selbst wenn es nur einen einzigen Wert gibt. Dies liegt daran, dass Elasticsearch keinen dedizierten Array-Typ besitzt und jedes Feld mehrere Werte haben kann. Für weitere Informationen zu Arrays in Elasticsearch klicken Sie hier.

Weitere Möglichkeiten zum Abrufen von Feldern

Obwohl das Abrufen von Feldern mit _source oder fields die empfohlenen Methoden sind, stehen für bestimmte Anwendungsfälle verschiedene Methoden zur Verfügung, wie zum Beispiel:

Doc-Wertfelder: Wenn Sie _source komplett vermeiden möchten, können Sie mit dem Parameter docvalue_fieldssuchen. Doc-Werte speichern die gleichen Feldwerte wie _source , jedoch in einer auf der Festplatte gespeicherten Datenstruktur, die für Sortierung und Aggregation optimiert ist.

Da es sich um separate Werte handelt, die nicht mit _source gespeichert sind, können Sie bestimmte Felder anfordern, ohne das gesamte _source zu laden. Dies ist nützlich, wenn Sie große Dokumente abfragen, aber nur wenige kleine Felder benötigen, die Dokumentwerte unterstützen. Ein weiterer Anwendungsfall für docvalue_fields besteht darin, dass Sie eine benutzerdefinierte Formatierung für die Felder date und numeric verwenden möchten, wie wir im folgenden Beispiel sehen werden.

Beachten Sie, dass dies nur für Felder funktioniert, für die Sie doc_values aktivieren, oder für Feldtypen, bei denen dies standardmäßig aktiviert ist, wie z. B. keyword, date, numerische Typen und boolean, nicht für text oder annotated_text.

In diesem Beispiel verwenden wir den Parameter docvalue_fields , um die Felder title, author und published abzurufen, ohne das vollständige Dokument _source zu laden:

Wenn diese Abfrage ausgeführt wird, greift Elasticsearch direkt auf die Werte in seinem spaltenorientierten Speicher auf der Festplatte zu, anstatt für jedes Dokument auf _source zu verweisen. Das Feld published wird dank des in der Abfrage angegebenen Parameters format im Format epoch_millis anstatt im Standardformat zurückgegeben.

Gespeicherte Felder: Wenn Sie in der Zuordnung explizit bestimmte Felder als gespeichert markiert haben, können Sie mit dem Parameter stored_fields nach diesen Feldern filtern. Dies ist nützlich, wenn Sie kurze Antworten nur mit diesen spezifischen Feldern wünschen oder Felder, die Sie absichtlich zum späteren Abruf gespeichert haben. Es wird separat von _source gespeichert, daher ist diese Methode auch nützlich, um das Laden von _source zu vermeiden.

Wichtig zu beachten ist, dass diese Option standardmäßig deaktiviert und generell nicht empfehlenswert ist. Verwenden Sie stattdessen Quellfilter, um bestimmte Teilmengen des ursprünglichen Quelldokuments zurückzugeben.

In der folgenden Beispielabfrage verwenden wir den Parameter stored_fields , um das Feld summary abzurufen, das die Indexzuordnungskonfiguration ”store”: true hat.

Wenn diese Abfrage ausgeführt wird, prüft Elasticsearch, ob dieses Feld mit ”store”: true markiert wurde. Falls dies nicht der Fall ist, wird das Feld vollständig übersprungen.

3. Unterfelder anzeigen

Wenn Ihr Index Unterfelder enthält, können Sie die Punktnotation verwenden, um den Feldpfad im Parameter fields anzugeben. Beachten Sie, dass Unterfelder sich vom verschachtelten Feldtyp unterscheiden. Wenn Sie beispielsweise ein Unterfeld mit dem Namen address.city haben, können Sie es wie folgt in die Suchergebnisseinlösung einbinden:

In diesem Beispiel enthält die Suchergebnisseinsendung die Werte der Felder title, author und address.city .

4. Synthetische Quelle

Wenn Sie die Funktionalität der Verwendung von _source beibehalten, aber gleichzeitig Speicherplatz sparen möchten, haben Sie die Möglichkeit, in Ihrer Indexzuordnung synthetisches _source zu verwenden. Die Funktion Synthetic _source ermöglicht es Elasticsearch, die _source aus vorhandenen Daten wie gespeicherten Feldern und Dokumentwerten zu rekonstruieren, selbst wenn _source deaktiviert ist. Dadurch lässt sich viel Speicherplatz sparen, allerdings auf Kosten etwas geringerer Abfragegeschwindigkeiten, da die Rekonstruktion in Echtzeit erfolgt. Aktivieren Sie diese Funktion, indem Sie die folgenden Werte in Ihren Indexeinstellungen verwenden:

Zu den Vorteilen der Verwendung von synthetischem _source gehören: vollständige Dokumentanzeige bei Verwendung der _search API, Quellfilterung und Kompatibilität mit anderen Funktionen und Tools wie Kibana, die die Verfügbarkeit _source voraussetzen, und das alles, ohne dass das vollständige _source Dokument gespeichert werden muss.

5. Laufzeitfelder

Mit Laufzeitfeldern können Sie skriptgesteuerte Felder zur Abfragezeit oder in Ihrer Indexzuordnung unter einem Laufzeitblock definieren. Diese Felder werden nie indiziert, daher erhöht das Hinzufügen eines Laufzeitfelds nicht die Indexgröße, es wird aber niemals in _source angezeigt. Die in der Zuordnung definierten Laufzeitfelder sind persistent und für alle Abfragen verfügbar, während die zur Abfragezeit definierten Laufzeitfelder temporär sind und nur in dieser Suchanfrage verfügbar sind.

Der Hauptvorteil der Verwendung von Laufzeitfeldern besteht darin, dass man Felder zu Dokumenten hinzufügen kann, nachdem man sie bereits importiert hat, was die Zuordnungsentscheidungen vereinfacht. Laufzeitfelder eignen sich auch hervorragend, um Ihre Dokumente mit Werten anzureichern, die im Originaldokument nicht vorhanden sind, sondern mithilfe eines Skripts generiert werden, z. B. durch Formatieren einer Zeichenkette oder Berechnen einer Punktzahl.

Es ist außerdem zu beachten, dass Laufzeitfelder die Leistung beeinträchtigen können, da für jedes Dokument im Ergebnissatz ein Skript ausgeführt werden muss. Um ein Laufzeitfeld abzurufen, können Sie auch den Parameter fields der API _search verwenden.

Fazit

Die Anzeige von Feldern eines Elasticsearch-Index kann von der einfachen Abfrage von Werten mithilfe der Indexzuordnung oder _source bis hin zu fortgeschritteneren Methoden mit fields, docvalue_fields oder Laufzeitfeldern für mehr Kontrolle und Effizienz reichen. Das Verständnis der Vor- und Nachteile verschiedener Methoden ist der Schlüssel zur Optimierung Ihrer Sucherfahrung. Egal ob Sie Nutzdaten optimieren, Dokumente anreichern oder synthetische Daten _source verwenden, um Speicherplatz zu sparen, Elasticsearch bietet Ihnen zahlreiche Tools und Funktionen, um die benötigten Daten so zu finden, wie Sie sie benötigen. Mithilfe dieser Techniken können Sie die Struktur Ihrer Daten verstehen, bestimmte Felder identifizieren und Probleme beheben.

In diesem Beitrag zeigen wir Ihnen, wie Sie mit Mastra einen agentenbasierten RAG-Assistenten und eine leichtgewichtige JavaScript-Webanwendung zur Interaktion mit diesem erstellen. Durch die Anbindung dieses Agenten an Elasticsearch erhalten Sie Zugriff auf strukturierte Spielerdaten und die Möglichkeit, statistische Aggregationen in Echtzeit durchzuführen, um Ihnen auf Spielerstatistiken basierende Empfehlungen geben zu können. Besuchen Sie das GitHub- Repository , um die Schritte nachzuvollziehen; die README-Datei enthält Anweisungen zum Klonen und Ausführen der Anwendung.

So sollte es aussehen, wenn alles zusammengebaut ist:

Hinweis: Dieser Blogbeitrag baut auf „ Entwicklung von KI-Agenten mit AI SDK und Elastic“ auf. Wenn Sie sich mit KI-Agenten im Allgemeinen noch nicht auskennen und nicht wissen, wofür sie eingesetzt werden könnten, fangen Sie dort an.

Architekturübersicht

Kernstück des Systems ist ein großes Sprachmodell (LLM), das als Denkmaschine (das Gehirn) des Agenten fungiert. Es interpretiert die Benutzereingaben, entscheidet, welche Tools aufgerufen werden sollen, und koordiniert die notwendigen Schritte, um eine relevante Antwort zu generieren.

Der Agent selbst wird von Mastra, einem Agenten-Framework im JavaScript-Ökosystem, bereitgestellt. Mastra umschließt das LLM mit einer Backend-Infrastruktur, stellt es als API-Endpunkt bereit und bietet eine Schnittstelle zur Definition von Tools, Systemaufforderungen und Agentenverhalten.

Im Frontend verwenden wir Vite , um schnell eine React-Webanwendung zu erstellen, die eine Chat-Oberfläche zum Senden von Anfragen an den Agenten und zum Empfangen seiner Antworten bereitstellt.

Schließlich gibt es noch Elasticsearch, das Spielerstatistiken und Matchup-Daten speichert, die der Agent abfragen und aggregieren kann.

Hintergrund

Lassen Sie uns einige grundlegende Konzepte durchgehen:

Was ist agentic RAG?

KI-Agenten können mit anderen Systemen interagieren, unabhängig agieren und Aktionen auf Basis ihrer definierten Parameter ausführen. Agentic RAG kombiniert die Autonomie eines KI-Agenten mit den Prinzipien der abrufverstärkten Generierung und ermöglicht es einem LLM, auszuwählen, welche Werkzeuge aufgerufen und welche Daten als Kontext verwendet werden sollen, um eine Antwort zu generieren. Lesen Sie hier mehr über RAG.

Warum sollte man bei der Wahl eines Frameworks über das AI-SDK hinausgehen?

Es gibt viele KI-Agenten-Frameworks, und Sie haben wahrscheinlich schon von den bekannteren wie CrewAI, AutoGen und LangGraph gehört. Die meisten dieser Frameworks verfügen über eine gemeinsame Funktionspalette, darunter die Unterstützung verschiedener Modelle, die Verwendung von Werkzeugen und das Speichermanagement.

Hier finden Sie eine Vergleichstabelle der verschiedenen Frameworks von Harrison Chase (CEO von LangChain).

Was mich an Mastra besonders interessiert hat, ist, dass es sich um ein JavaScript-basiertes Framework handelt, das für Full-Stack-Entwickler entwickelt wurde, um Agenten einfach in ihr Ökosystem zu integrieren. Das AI-SDK von Vercel kann das meiste davon auch, aber Mastra glänzt vor allem dann, wenn Ihre Projekte komplexere Agenten-Workflows beinhalten. Mastra erweitert die vom AI-SDK festgelegten Basismuster, und in diesem Projekt werden wir sie gemeinsam verwenden.

Rahmenwerke und Überlegungen zur Modellwahl

Diese Frameworks können zwar dabei helfen, schnell KI-Agenten zu entwickeln, es gibt jedoch einige Nachteile zu beachten. Wenn man beispielsweise andere Frameworks als KI-Agenten oder Abstraktionsschichten im Allgemeinen verwendet, verliert man ein Stück weit die Kontrolle. Wenn das LLM die Werkzeuge nicht korrekt verwendet oder etwas tut, was Sie nicht möchten, erschwert die Abstraktion die Fehlersuche. Dennoch ist dieser Kompromiss meiner Meinung nach den Komfort und die Geschwindigkeit wert, die man beim Erstellen von Projekten erhält, insbesondere weil diese Frameworks immer beliebter werden und ständig weiterentwickelt werden.

Auch diese Frameworks sind modellagnostisch, das heißt, Sie können verschiedene Modelle einsetzen und verwenden. Bedenken Sie jedoch, dass sich die Modelle in den Datensätzen unterscheiden, mit denen sie trainiert wurden, und dass sich dadurch auch die Ergebnisse unterscheiden. Manche Modelle unterstützen nicht einmal den Aufruf von Tools. Es ist also möglich, zwischen verschiedenen Modellen zu wechseln und diese auszuprobieren, um zu sehen, welches die besten Ergebnisse liefert. Bedenken Sie jedoch, dass Sie höchstwahrscheinlich für jedes Modell die Systemabfrage neu schreiben müssen. Zum Beispiel mit Llama3.3 Im Vergleich zu GPT-4o sind deutlich mehr Aufforderungen und spezifische Anweisungen erforderlich, um die gewünschte Antwort zu erhalten.

NBA Fantasy Basketball

Beim Fantasy-Basketball geht es darum, mit einer Gruppe von Freunden eine Liga zu gründen (Achtung: Je nachdem, wie wettbewerbsorientiert eure Gruppe ist, könnte dies den Status eurer Freundschaften beeinträchtigen), wobei in der Regel auch Geld auf dem Spiel steht. Jeder von euch stellt dann ein Team aus 10 Spielern zusammen, die abwechselnd wöchentlich gegen die 10 Spieler eines anderen Freundes antreten. Die Punkte, die zu Ihrer Gesamtpunktzahl beitragen, ergeben sich aus der Leistung jedes Ihrer Spieler gegen seine Gegner in einer bestimmten Woche.

Wenn ein Spieler Ihres Teams verletzt, gesperrt usw. wird, steht Ihnen eine Liste von Free Agents zur Verfügung, die Sie Ihrem Team hinzufügen können. Hier findet ein Großteil des schwierigen Denkens im Fantasy-Sport statt, denn man hat nur eine begrenzte Anzahl an Spielern zur Auswahl und jeder ist ständig auf der Suche nach dem besten Spieler.

Hier wird unser NBA-KI-Assistent seine Stärken ausspielen, insbesondere in Situationen, in denen Sie schnell entscheiden müssen, welchen Spieler Sie auswählen. Anstatt manuell nachschlagen zu müssen, wie ein Spieler gegen einen bestimmten Gegner abschneidet, kann der Assistent diese Daten schnell finden und Durchschnittswerte vergleichen, um Ihnen eine fundierte Empfehlung zu geben.

Nachdem Sie nun einige Grundlagen zu Agentic RAG und NBA Fantasy Basketball kennengelernt haben, sehen wir uns das Ganze mal in der Praxis an.

Aufbau des Projekts

Falls Sie an irgendeiner Stelle nicht weiterkommen oder es nicht von Grund auf neu erstellen möchten, schauen Sie bitte im Repository nach.

Was wir behandeln werden

1. Gerüstbau für das Projekt:

   1. Backend (Mastra): Verwenden Sie npx create mastra@latest, um das Backend zu erstellen und die Agentenlogik zu definieren.

   2. Frontend (Vite + React): Verwenden Sie npm create vite@latest, um die Frontend-Chat-Oberfläche für die Interaktion mit dem Agenten zu erstellen.

2. Einrichten von Umgebungsvariablen

   1. Installieren Sie dotenv, um Umgebungsvariablen zu verwalten.

   2. Erstellen Sie eine .env-Datei Datei und geben Sie die erforderlichen Variablen an.

3. Elasticsearch einrichten

   1. Erstellen Sie einen Elasticsearch-Cluster (entweder lokal oder in der Cloud).

   2. Installieren Sie den offiziellen Elasticsearch-Client.

   3. Stellen Sie sicher, dass Umgebungsvariablen zugänglich sind.

   4. Verbindung zum Client herstellen.

4. Massenhaftes Einlesen von NBA-Daten in Elasticsearch

   1. Erstellen Sie einen Index mit den entsprechenden Zuordnungen, um Aggregationen zu ermöglichen.

   2. Spielerstatistiken aus einer CSV-Datei massenhaft in einen Elasticsearch-Index importieren.

5. Elasticsearch-Aggregationen definieren

   1. Abfrage zur Berechnung historischer Durchschnittswerte gegen einen bestimmten Gegner.

   2. Abfrage zur Berechnung der Saison-Durchschnittswerte gegen einen bestimmten Gegner.

6. Datei zum Spielervergleich

   1. Konsolidiert Hilfsfunktionen und Elasticsearch-Aggregationen.

7. Agentenaufbau

   1. Fügen Sie die Agentendefinition und die Systemeingabeaufforderung hinzu.

   2. Installieren Sie zod und definieren Sie Tools.

   3. Fügen Sie eine Middleware-Konfiguration zur Behandlung von CORS hinzu.

8. Integration des Frontends

   1. Die Interaktion mit dem Agenten erfolgt über die useChat-Funktion des AI-SDK.

   2. Erstellen Sie eine Benutzeroberfläche, die ordnungsgemäß formatierte Konversationen ermöglicht.

9. Die Anwendung ausführen

   1. Starten Sie sowohl das Backend (Mastra-Server) als auch das Frontend (React-App).

   2. Beispielabfragen und Anwendungsbeispiele.

10. Was kommt als Nächstes: Den Agenten intelligenter machen.

    1. Durch die Integration semantischer Suchfunktionen können aussagekräftigere Empfehlungen ermöglicht werden.

    2. Aktivieren Sie dynamische Abfragen, indem Sie die Suchlogik auf den Elasticsearch MCP (Model Context Protocol)-Server verlagern.

Voraussetzungen

• Node.js und npm: Sowohl das Backend als auch das Frontend laufen auf Node.js. Stellen Sie sicher, dass Sie Node 18+ und npm v9+ installiert haben (das in Node 18+ standardmäßig enthalten ist).

• Elasticsearch-Cluster: Ein aktiver Elasticsearch-Cluster, entweder lokal oder in der Cloud.

• OpenAI API-Schlüssel: Generieren Sie einen auf der Seite „API-Schlüssel“ im Entwicklerportal von OpenAI.

Projektstruktur

Schritt 1: Das Projektgerüst erstellen

1. Erstellen Sie zunächst das Verzeichnis nba-ai-assistant-js und navigieren Sie darin mit folgendem Befehl:

Backend:

1. Verwenden Sie das Mastra-Erstellungstool mit folgendem Befehl:

2. Sie sollten nun einige Eingabeaufforderungen in Ihrem Terminal erhalten. Bei der ersten nennen wir das Projekt-Backend:

3. Als nächstes behalten wir die Standardstruktur für die Speicherung der Mastra-Dateien bei, also Eingabe src/.

4. Dann wählen wir OpenAI als unseren Standard-LLM-Anbieter.

5. Abschließend werden Sie nach Ihrem OpenAI-API-Schlüssel gefragt. Fürs Erste wählen wir die Option, dies zu überspringen und es später in einer .env -Datei bereitzustellen.

Frontend:

1. Wechseln Sie zurück in das Stammverzeichnis und führen Sie das Vite-Erstellungstool mit folgendem Befehl aus: npm create vite@latest frontend -- --template react

Dadurch sollte eine leichtgewichtige React-App mit dem Namen frontend und einer spezifischen Vorlage für React erstellt werden.

Wenn alles gut geht, sollten Sie in Ihrem Projektverzeichnis ein Backend-Verzeichnis sehen, das den Mastra-Code enthält, und ein frontend -Verzeichnis mit Ihrer React-App.

Schritt 2: Umgebungsvariablen einrichten

1. Zur Verwaltung sensibler Schlüssel verwenden wir das Paket dotenv , um unsere Umgebungsvariablen aus der .env-Datei zu laden. Datei. Navigieren Sie zum Backend-Verzeichnis und installieren Sie dotenv:

2. Im Backend-Verzeichnis befindet sich eine example.env-Datei mit den entsprechenden Variablen zum Ausfüllen. Wenn Sie Ihre eigene Version erstellen, achten Sie darauf, die folgenden Variablen einzubeziehen:

Hinweis: Stellen Sie sicher, dass diese Datei von Ihrer Versionskontrolle ausgeschlossen wird, indem Sie .env zu .gitignore hinzufügen.

Schritt 3: Elasticsearch einrichten

Als Erstes benötigen Sie einen aktiven Elasticsearch-Cluster. Es gibt zwei Möglichkeiten:

• Option A: Elasticsearch Cloud verwenden

  • Registrieren Sie sich für Elastic Cloud

  • Erstellen Sie eine neue Bereitstellung

  • Rufen Sie Ihre Endpunkt-URL und Ihren API-Schlüssel (kodiert) ab.

• Option B: Elasticsearch lokal ausführen

  • Elasticsearch lokal installieren und ausführen

  • Verwenden Sie http://localhost:9200 als Endpunkt.

  • API-Schlüssel generieren

Installation des Elasticsearch-Clients auf dem Backend:

1. Installieren Sie zunächst den offiziellen Elasticsearch-Client in Ihrem Backend-Verzeichnis:

2. Erstellen Sie anschließend ein Verzeichnis „lib“, um wiederverwendbare Funktionen zu speichern, und wechseln Sie in dieses Verzeichnis:

3. Erstellen Sie darin eine neue Datei namens elasticClient.js. Diese Datei initialisiert den Elasticsearch-Client und stellt ihn für die Verwendung in Ihrem gesamten Projekt zur Verfügung.

4. Da wir ECMAScript-Module (ESM) verwenden, sind __dirname and __-Dateinamen nicht verfügbar. Um sicherzustellen, dass Ihre Umgebungsvariablen korrekt aus der .env-Datei geladen werden Fügen Sie diese Konfiguration am Anfang der Datei im Backend-Ordner hinzu:

5. Initialisieren Sie nun den Elasticsearch-Client mithilfe Ihrer Umgebungsvariablen und überprüfen Sie die Verbindung:

Nun können wir diese Clientinstanz in jede Datei importieren, die mit Ihrem Elasticsearch-Cluster interagieren muss.

Schritt 4: Massenhaftes Einlesen von NBA-Daten in Elasticsearch

Datensatz:

Für dieses Projekt werden wir auf die Datensätze im Verzeichnis backend/data des Repos zurückgreifen. Unser NBA-Assistent wird diese Daten als Wissensbasis für statistische Vergleiche und die Generierung von Empfehlungen nutzen.

• sample_player_game_stats.csv - Beispielhafte Spielstatistiken eines Spielers (z. B. Punkte, Rebounds, Steals usw.) pro Spiel und Spieler während seiner gesamten NBA-Karriere. Wir werden diesen Datensatz für Aggregationen verwenden. (Hinweis: Dies sind Beispieldaten, die zu Demonstrationszwecken generiert wurden und nicht aus offiziellen NBA-Quellen stammen.)

• playerAndTeamInfo.js - Ersetzt die Spieler- und Team-Metadaten, die normalerweise über einen API-Aufruf bereitgestellt werden, damit der Agent Spieler- und Teamnamen IDs zuordnen kann. Da wir Beispieldaten verwenden, möchten wir den Aufwand des Abrufens von einer externen API vermeiden. Daher haben wir einige Werte fest codiert, auf die der Agent zugreifen kann.

Durchführung:

1. Erstellen Sie im Verzeichnis backend/lib eine Datei mit dem Namen playerDataIngestion.js.

2. Importe einrichten, den CSV-Dateipfad auflösen und das Parsen einrichten. Da wir ESM verwenden, müssen wir __dirname rekonstruieren, um den Pfad zur Beispiel-CSV-Datei aufzulösen. Außerdem importieren wir Node.js. eingebaute Module fs und readline, um die gegebene CSV-Datei Zeile für Zeile zu analysieren.

Damit sind Sie bestens gerüstet, um die CSV-Datei effizient zu lesen und zu analysieren, wenn wir zum Schritt der Massenverarbeitung übergehen.

3. Erstellen Sie einen Index mit der entsprechenden Zuordnung. Obwohl Elasticsearch Feldtypen mithilfe von Dynamic Mapping automatisch ableiten kann, möchten wir hier explizit vorgehen, damit jede Statistik als numerisches Feld behandelt wird. Dies ist wichtig, da wir diese Felder später für Aggregationen verwenden werden. Wir möchten außerdem den Typ float für Statistiken wie Punkte, Rebounds usw. verwenden, um sicherzustellen, dass wir Dezimalwerte einbeziehen. Zum Schluss möchten wir die Mapping-Eigenschaft dynamic: 'strict' hinzufügen, damit Elasticsearch nicht dynamisch nicht erkannte Felder zuordnet. 

4. Fügen Sie die Funktion hinzu, um die CSV-Daten in Ihren Elasticsearch-Index zu importieren. Innerhalb des Codeblocks überspringen wir die Kopfzeile. Anschließend werden die einzelnen Zeilen durch Kommas getrennt und in das Dokumentobjekt eingefügt. Dieser Schritt reinigt sie außerdem und stellt sicher, dass es sich um den richtigen Typ handelt. Als nächstes fügen wir die Dokumente zusammen mit den Indexinformationen in das bulkBody-Array ein, welches als Nutzlast für die Massenaufnahme in Elasticsearch dient.

5. Anschließend können wir die Bulk-API von Elasticsearch mit elasticClient.bulk() verwenden, um mehrere Dokumente in einer einzigen Anfrage zu erfassen. Die unten beschriebene Fehlerbehandlung ist so aufgebaut, dass sie Ihnen eine Übersicht darüber gibt, wie viele Dokumente nicht eingelesen werden konnten und wie viele erfolgreich eingelesen wurden.

6. Führen Sie die unten stehende Funktion main() aus, um die Funktionen createIndex() und bulkIngestCsv() nacheinander auszuführen.

Wenn in der Konsole eine Meldung erscheint, dass die Massenaufnahme erfolgreich war, überprüfen Sie kurz Ihren Elasticsearch-Index, um festzustellen, ob die Dokumente tatsächlich erfolgreich aufgenommen wurden.

Schritt 5: Elasticsearch-Aggregationen definieren und konsolidieren

Dies sind die Hauptfunktionen, die wir verwenden werden, wenn wir die Werkzeuge für den KI-Agenten definieren, um die Statistiken der Spieler miteinander zu vergleichen.

1. Navigieren Sie zum Verzeichnis backend/lib und erstellen Sie eine Datei namens elasticAggs.js.

2. Fügen Sie die unten stehende Abfrage hinzu, um historische Durchschnittswerte für einen Spieler gegen einen bestimmten Gegner zu berechnen. Diese Abfrage verwendet einen bool -Filter mit 2 Bedingungen: eine, die player_id entspricht, und eine weitere, die opponent_team_id entspricht, um nur die relevanten Spiele abzurufen. Wir müssen keine Dokumente zurückgeben, uns geht es nur um die Aggregationen, deshalb setzen wir size:0. Im Block aggs führen wir mehrere Metrikaggregationen parallel auf Feldern wie points, rebounds, assists, steals, blocks und fg_percentage durch, um deren Durchschnittswerte zu berechnen. LLMs können bei Berechnungen ungenau sein, und dies lagert diesen Prozess an Elasticsearch aus, um sicherzustellen, dass unser NBA-KI-Assistent Zugriff auf genaue Daten hat.

3. Um die Saisondurchschnittswerte eines Spielers gegen einen bestimmten Gegner zu berechnen, verwenden wir praktisch die gleiche Abfrage wie für die historischen Ergebnisse. Der einzige Unterschied bei dieser Abfrage besteht darin, dass der bool -Filter eine zusätzliche Bedingung für game_date enthält. Das Feld game_date muss innerhalb des Bereichs der aktuellen NBA-Saison liegen. In diesem Fall liegt der Bereich zwischen 2024-10-01 und 2025-06-30. Die unten stehende zusätzliche Bedingung stellt sicher, dass die nachfolgenden Aggregationen nur die Spiele dieser Saison berücksichtigen.

Schritt 6: Spielervergleichstool

Um unseren Code modular und wartbar zu halten, erstellen wir eine Hilfsdatei, die Metadaten-Hilfsfunktionen und Elasticsearch-Aggregationen zusammenfasst. Dies wird das Hauptwerkzeug des Agenten mit Strom versorgen. Mehr dazu später:

1. Erstellen Sie eine neue Datei comparePlayers.js im Verzeichnis backend/lib .

2. Fügen Sie die unten stehende Funktion hinzu, um Metadaten-Helfer und Elasticsearch-Aggregationslogik in einer einzigen Funktion zu konsolidieren, die das Hauptwerkzeug des Agenten antreibt.

Schritt 7: Erstellung des Agenten

Nachdem Sie nun das Frontend- und Backend-Gerüst erstellt, NBA-Spieldaten eingespielt und eine Verbindung zu Elasticsearch hergestellt haben, können wir damit beginnen, alle Teile zusammenzufügen, um den Agenten zu entwickeln.

Definition des Agenten

1. Navigieren Sie zur Datei index.ts im Verzeichnis backend/src/mastra/agents und fügen Sie die Agentendefinition hinzu. Sie können Felder wie die folgenden angeben:

• Name: Geben Sie Ihrem Agenten einen Namen, der als Referenz verwendet wird, wenn er im Frontend aufgerufen wird.

• Anweisungen/Systemaufforderung: Eine Systemaufforderung gibt dem LLM den anfänglichen Kontext und die Regeln vor, die während der Interaktion zu befolgen sind. Es ähnelt der Aufforderung, die Benutzer über das Chatfenster senden, diese wird jedoch vor jeglicher Benutzereingabe angezeigt. Auch dies hängt vom gewählten Modell ab.

• Modell: Welches LLM soll verwendet werden (Mastra unterstützt OpenAI, Anthropic, lokale Modelle usw.)?

• Tools: Eine Liste der Tool-Funktionen, die der Agent aufrufen kann.

• Speicher: (Optional) Wenn der Agent sich den Gesprächsverlauf usw. merken soll. Der Einfachheit halber können wir ohne persistenten Speicher beginnen, obwohl Mastra diesen unterstützt.

Werkzeuge definieren

1. Navigieren Sie zur Datei index.ts im Verzeichnis backend/src/mastra/tools .

2. Installieren Sie Zod mit folgendem Befehl:

3. Werkzeugdefinitionen hinzufügen. Beachten Sie, dass wir die Funktion innerhalb der Datei comparePlayers.js als Hauptfunktion importieren, die der Agent beim Aufruf dieses Tools verwenden wird. Mit der Funktion createTool() von Mastra registrieren wir unser playerComparisonTool. Zu den Feldern gehören:

• idDies ist eine Beschreibung in natürlicher Sprache, die dem Agenten hilft zu verstehen, was das Tool leistet.

• input schemaUm die Form der Eingabe für das Tool zu definieren, verwendet Mastra das Zod -Schema, eine TypeScript-Bibliothek zur Schema-Validierung. Zod hilft dabei, indem es sicherstellt, dass der Agent korrekt strukturierte Eingaben vornimmt und die Ausführung des Tools verhindert, wenn die Eingabestruktur nicht übereinstimmt.

• descriptionDies ist eine Beschreibung in natürlicher Sprache, die dem Agenten helfen soll zu verstehen, wann er anrufen und das Tool verwenden soll.

• executeDie Logik, die beim Aufruf des Tools ausgeführt wird. In unserem Fall verwenden wir eine importierte Hilfsfunktion, um Leistungsstatistiken zurückzugeben.

Hinzufügen von Middleware zur Behandlung von CORS

Fügen Sie Middleware auf dem Mastra-Server hinzu, um CORS zu behandeln. Man sagt, es gäbe drei Dinge im Leben, denen man nicht entkommen kann: den Tod, die Steuern und für Webentwickler zusätzlich CORS. Kurz gesagt, Cross-Origin Resource Sharing ist eine Browser-Sicherheitsfunktion, die verhindert, dass das Frontend Anfragen an ein Backend sendet, das auf einer anderen Domain oder einem anderen Port läuft. Obwohl wir sowohl das Backend als auch das Frontend auf localhost betreiben, verwenden sie unterschiedliche Ports, wodurch die CORS-Richtlinie ausgelöst wird. Wir müssen die in der Mastra-Dokumentation beschriebene Middleware hinzufügen, damit unser Backend diese Anfragen vom Frontend zulässt.

1. Navigieren Sie zur Datei index.ts im Verzeichnis backend/src/mastra und fügen Sie die Konfiguration für CORS hinzu:

• origin: ['http://localhost:5173']

  • Erlaubt Anfragen nur von dieser Adresse (Vite-Standardadresse)

• allowMethods: ["GET", "POST"]

  • Zulässige HTTP-Methoden. In den meisten Fällen wird POST verwendet.

• allowHeaders: ["Content-Type", "Authorization", "x-mastra-client-type, "x-highlight-request", "traceparent"],

  • Diese legen fest, welche benutzerdefinierten Header in Anfragen verwendet werden können.

Schritt 8: Integration des Frontends

Diese React-Komponente stellt eine einfache Chat-Oberfläche bereit, die über den useChat() -Hook aus @ai-sdk/react eine Verbindung zum Mastra AI-Agenten herstellt. Wir werden diesen Hook auch verwenden, um die Tokenverwendung und Toolaufrufe anzuzeigen sowie die Konversation darzustellen. In der obigen Systemabfrage bitten wir den Agenten außerdem, die Antwort im Markdown-Format auszugeben. Daher verwenden wir react-markdown , um die Antwort korrekt zu formatieren.

1. Installieren Sie im Frontend-Verzeichnis das Paket @ai-sdk/react, um den useChat()-Hook verwenden zu können.

2. Installieren Sie im selben Verzeichnis React Markdown, damit wir die vom Agenten generierte Antwort richtig formatieren können.

3. Implementiere useChat(). Dieser Hook steuert die Interaktion zwischen Ihrem Frontend und Ihrem KI-Agenten-Backend. Es verarbeitet Nachrichtenstatus, Benutzereingaben und Statusinformationen und bietet Lebenszyklus-Hooks zur Überwachung. Zu den Optionen, die wir übergeben, gehören:

• api: Dies definiert den Endpunkt Ihres Mastra AI-Agenten. Standardmäßig wird Port 4111 verwendet, und wir möchten außerdem die Route hinzufügen, die Streaming-Antworten unterstützt.

• onToolCallDies wird immer dann ausgeführt, wenn der Agent ein Tool aufruft; wir verwenden es, um zu verfolgen, welche Tools unser Agent aufruft.

• onFinishDies wird ausgeführt, nachdem der Agent eine vollständige Antwort abgegeben hat. Auch wenn wir Streaming aktiviert haben, wird onFinish erst ausgeführt, nachdem die gesamte Nachricht empfangen wurde, und nicht nach jedem einzelnen Datenblock. Hier verwenden wir es, um unsere Token-Nutzung zu verfolgen. Dies kann hilfreich sein, um die LLM-Kosten zu überwachen und zu optimieren.

4. Zum Schluss gehen Sie zur Komponente ChatUI.jsx im Verzeichnis frontend/components , um die Benutzeroberfläche für unsere Konversation zu erstellen. Als Nächstes muss die Antwort in eine ReactMarkdown -Komponente eingeschlossen werden, um die Antwort des Agenten korrekt zu formatieren.

Schritt 9: Ausführen der Anwendung

Glückwunsch! Sie können die Anwendung nun ausführen. Folgen Sie diesen Schritten, um sowohl das Backend als auch das Frontend zu starten.

1. Öffnen Sie ein Terminalfenster, beginnend im Stammverzeichnis, und navigieren Sie zum Backend-Verzeichnis. Starten Sie dort den Mastra-Server:

2. Öffnen Sie ein weiteres Terminalfenster, beginnend mit dem Stammverzeichnis, und navigieren Sie zum Frontend-Verzeichnis. Starten Sie dort die React-App:

3. Öffnen Sie Ihren Browser und navigieren Sie zu:

http://localhost:5173

Sie sollten die Chat-Oberfläche sehen können. Probieren Sie diese Beispielaufforderungen aus:

• „Vergleiche LeBron James und Stephen Curry“

• "Wen soll ich wählen, Jayson Tatum oder Luka Doncic?"

Was kommt als Nächstes: Den Agenten intelligenter machen.

Um den Assistenten handlungsfähiger und die Empfehlungen aussagekräftiger zu gestalten, werde ich in der nächsten Version einige wichtige Verbesserungen vornehmen.

Semantische Suche nach NBA-Nachrichten

Es gibt unzählige Faktoren, die die Leistung eines Spielers beeinflussen können, viele davon spiegeln sich nicht in den reinen Statistiken wider. Dinge wie Verletzungsberichte, Aufstellungsänderungen oder auch eine Spielanalyse nach dem Spiel findet man nur in Nachrichtenartikeln. Um diesen zusätzlichen Kontext zu erfassen, werde ich semantische Suchfunktionen hinzufügen, damit der Agent relevante NBA-Artikel abrufen und diese Erzählung in seine Empfehlungen einbeziehen kann.

Dynamische Suche mit dem Elasticsearch MCP-Server

MCP (Model Context Protocol) entwickelt sich schnell zum Standard für die Art und Weise, wie Agenten Verbindungen zu Datenquellen herstellen. Ich werde die Suchlogik auf den Elasticsearch MCP-Server migrieren, wodurch der Agent Abfragen dynamisch erstellen kann, anstatt sich auf vordefinierte Suchfunktionen zu verlassen, die wir bereitstellen. Dies ermöglicht uns die Nutzung von Workflows in natürlicher Sprache und reduziert den Aufwand, jede einzelne Suchanfrage manuell zu formulieren. Erfahren Sie hier mehr über den Elasticsearch MCP-Server und den aktuellen Stand des Ökosystems.

Diese Änderungen sind bereits im Gange, bleiben Sie gespannt!

Fazit

In diesem Blog haben wir einen agentenbasierten RAG-Assistenten entwickelt, der mithilfe von JavaScript, Mastra und Elasticsearch maßgeschneiderte Empfehlungen für Ihr Fantasy-Basketballteam liefert. Wir behandelten Folgendes:

• Grundlagen von Agentic RAG und wie die Kombination der Autonomie eines KI-Agenten mit den Werkzeugen zur effektiven Nutzung von RAG zu differenzierteren und dynamischeren Agenten führen kann.

• Elasticsearch und wie seine Datenspeicherfunktionen und leistungsstarken nativen Aggregationen es zu einem großartigen Partner als Wissensbasis für ein LLM machen.

• Das Mastra- Framework und wie es die Entwicklung dieser Agenten für Entwickler im JavaScript-Ökosystem vereinfacht.

Egal, ob Sie ein Basketballfanatiker sind, sich damit beschäftigen, wie man KI-Agenten entwickelt, oder beides wie ich, ich hoffe, dieser Blog hat Ihnen einige Bausteine für den Einstieg geliefert. Das vollständige Repository ist auf GitHub verfügbar, Sie können es gerne klonen und damit experimentieren. Jetzt hol dir den Sieg in der Fantasy-Liga!

Was ist das Model Context Protocol (MCP)?

Für diejenigen, die es nicht kennen: Model Context Protocol ist ein offener Standard, der eine strukturierte, bidirektionale Möglichkeit bietet, KI-Modelle mit verschiedenen Datenquellen und Tools zu verbinden, sodass sie relevantere und fundiertere Antworten generieren können. Er wird allgemein als „ USB-C-Anschluss für KI-Anwendungen“ bezeichnet.

Hier ist ein Architekturdiagramm, das seine bidirektionale Natur hervorhebt:

Dies stellt für KI-Praktiker eine bedeutende Veränderung dar, da eine der größten Herausforderungen bei der Skalierung von KI-Anwendungen darin besteht, für jede neue Datenquelle benutzerdefinierte Integrationen erstellen zu müssen. MCP bietet eine nachhaltige, wiederverwendbare Architektur zum Verwalten und Bereitstellen von Kontext für Modelle. Es ist modellunabhängig, serverunabhängig und vollständig Open Source.

MCP ist die neueste Version einer Reihe von API-Spezifikationen, die die Integration zwischen Anwendungen standardisieren sollen. In der Vergangenheit hatten wir OpenAPI für RESTful-Dienste, GraphQL für Datenabfragen und gRPC für die Mikrodienstkommunikation. MCP teilt nicht nur die strukturierte Genauigkeit dieser älteren Spezifikationen, sondern bringt sie auch in eine generative KI-Umgebung ein, wodurch es einfacher wird, Agenten ohne benutzerdefinierte Konnektoren in verschiedene Systeme einzubinden. In vielerlei Hinsicht zielt MCP darauf ab, für KI-Agenten das zu tun, was HTTP für das Web getan hat. So wie HTTP die Kommunikation zwischen Browsern und Websites standardisiert, versucht MCP, die Art und Weise zu standardisieren, wie KI-Agenten mit der sie umgebenden Datenwelt interagieren.

MCP im Vergleich zu anderen Agentenprotokollen

Die Landschaft der Agentenprotokolle wächst rasant, und über ein Dutzend neuer Standards konkurrieren darum, die Interaktion der Agenten zu definieren. Laurie Voss von LlamaIndex beschreibt, dass die meisten in zwei Typen eingeteilt werden können: Inter-Agent-Protokolle, bei denen der Schwerpunkt auf der Kommunikation der Agenten untereinander liegt, und kontextorientierte Protokolle wie MCP, bei denen der Schwerpunkt auf der Bereitstellung eines strukturierten Kontexts für LLMs liegt.

Andere beliebte Protokolle wie A2A (Agent to Agent) von Google, ACP (Agent Communication Protocol) von Cisco und IBM sowie Agora zielen darauf ab, Verhandlungen zwischen Agenten, den Aufbau von Koalitionen und sogar dezentrale Identitätssysteme zu ermöglichen. MCP verfolgt dabei einen etwas pragmatischeren Ansatz, da es sich darauf konzentriert, wie Agenten auf Tools und Daten zugreifen und nicht unbedingt darauf, wie sie miteinander kommunizieren (obwohl MCP dies in Zukunft auch auf andere Weise ermöglichen könnte).

Was MCP derzeit auszeichnet, ist seine Zugkraft und Dynamik. Wie React in den Anfängen der Frontend-Frameworks begann MCP mit einem Nischenproblem und ist heute in der Praxis eines der am häufigsten verwendeten und erweiterbarsten Agentenprotokolle.

Gipfel-Rückblick: Neue Prioritäten für MCP

Auf dem Gipfel sprachen Redner von Mitwirkenden bei Anthropic, Okta, OpenAI, AWS, GitHub und vielen anderen. Die Gespräche reichten von Verbesserungen des Kernprotokolls bis hin zu Implementierungen in der realen Welt und skizzierten sowohl unmittelbare als auch langfristige Prioritäten. Diese Gespräche spiegelten eine Abkehr von frühen Experimenten und einfachen Tool-Aufrufen hin zum Aufbau vertrauenswürdiger, skalierbarer und modularer KI-Systeme auf der Grundlage von MCP wider.

Mehrere Redner deuteten eine Zukunft an, in der MCP mehr als nur eine Protokoll-Infrastruktur ist und die Grundlage eines KI-nativen Webs werden kann. So wie JavaScript es Benutzern ermöglicht, auf Webseiten zu klicken und mit ihnen zu interagieren, könnte MCP es Agenten ermöglichen, dieselben Aktionen in unserem Namen auszuführen. Im E-Commerce beispielsweise könnten Benutzer, anstatt manuell zu einer Website zu navigieren, um einzukaufen, einfach einen Agenten anweisen, sich anzumelden, ein bestimmtes Produkt zu suchen, es in den Einkaufswagen zu legen und zur Kasse zu gehen.

Und das ist nicht bloß reine Spekulation und Hype; PayPal hat auf dem Gipfel sein neues Agenten-Toolkit und seinen MCP-Server vorgestellt, die genau dieses Agenten-Commerce-Erlebnis ermöglichen. Da MCP einen sicheren und zuverlässigen Zugriff auf Tools und Datenquellen bietet, können Agenten das Web nicht nur lesen, sondern auch darauf reagieren. MCP ist heute bereits ein leistungsstarker Standard mit großer Dynamik und könnte sich in Zukunft zum Standard für KI-gestützte Benutzerinteraktionen im gesamten Web entwickeln.

MCP-Projekt-Updates: Transport, Erhebung und strukturierte Werkzeuge

Jerome Swannack, ein Hauptbeitragender zu MCP, hat einige Aktualisierungen der Protokollspezifikation der letzten 6 Monate mitgeteilt. Die Hauptziele dieser Änderungen sind:

1. So aktivieren Sie Remote-MCP durch Hinzufügen von Streamable HTTP

2. Um umfangreichere Agenteninteraktionsmodelle durch die Ergänzung von Elicitation- und Tool-Output-Schemata zu ermöglichen

Da MCP Open Source ist, stehen Änderungen wie Streamable HTTP den Entwicklern bereits zur Implementierung zur Verfügung. Die Schemata zur Ermittlung und Tool-Ausgabe sind derzeit noch nicht veröffentlicht. Sie befinden sich im Entwurfsstadium und können sich weiterentwickeln.

Streamable HTTP (veröffentlicht am 26.03.2025): Ein wirkungsvolles technisches Update war die Einführung von Streamable HTTP als neuer Transportmechanismus. Dadurch werden serverseitig gesendete Ereignisse (SSE) durch ein skalierbareres, bidirektionales Modell ersetzt, das Chunked-Transfer-Encoding und progressive Nachrichtenübermittlung über eine einzelne HTTP-Verbindung unterstützt. Dadurch können Sie MCP-Server auf Cloud-Infrastrukturen wie AWS Lambda bereitstellen und Unternehmensnetzwerkbeschränkungen ohne langlebige Verbindungen oder die Notwendigkeit von Polling unterstützen.

Elicitation (veröffentlicht am 18.06.2025): Elicitation ermöglicht es Servern, ein Schema für die gewünschte Kontextstruktur eines Clients zu definieren. Im Wesentlichen kann der Server beschreiben, was er benötigt und welche Art von Eingabe er erwartet. Dies hat einige Auswirkungen: Server-Builder können komplexere Agenteninteraktionen erstellen. Client-Builder können dynamische Benutzeroberflächen implementieren, die sich an diese Schemata anpassen. Die Erhebung von Daten sollte jedoch nicht dazu verwendet werden, vertrauliche oder persönlich identifizierbare Informationen von Benutzern zu erhalten. Entwickler sollten bewährte Methoden befolgen, um sicherzustellen, dass die Abfrageaufforderungen sicher und angemessen bleiben, insbesondere wenn MCP weiterentwickelt wird. Dies hängt mit allgemeineren Sicherheitsbedenken zusammen, die wir später in diesem Beitrag erörtern werden.

Tool-Ausgabeschemata (veröffentlicht am 18.06.2025): Dieses Konzept ermöglicht es dem Client und dem LLM, die Formen der Tool-Ausgabe im Voraus zu kennen. Mithilfe von Tool-Ausgabeschemata können Entwickler beschreiben, was ein Tool voraussichtlich zurückgeben wird. Diese Schemata beheben eine der Haupteinschränkungen des direkten Toolaufrufs, nämlich die ineffiziente Verwendung des Kontextfensters. Das Kontextfenster gilt als eine der wichtigsten Ressourcen bei der Arbeit mit LLMs. Wenn Sie ein Tool direkt aufrufen, gibt es Rohinhalte zurück, die vollständig in den Kontext des LLMs verschoben werden. Mithilfe von Tool-Ausgabeschemata können Sie Ihre Token und das Kontextfenster besser nutzen, indem Sie dem MCP-Server die Bereitstellung strukturierter Daten ermöglichen. Hier sind einige Best Practices zu Tools im Allgemeinen.

Zusammen werden diese neuen Updates und zukünftigen Ergänzungen dazu beitragen, dass MCP zu einem modulareren, typisierteren und produktionsbereiteren Agentenprotokoll wird.

Untergenutzte Power-Funktionen: Sampling und Wurzeln

Obwohl die MCP-Spezifikation nichts Neues ist, wurden in der Keynote sowohl Sampling als auch Roots hervorgehoben. Diese beiden Grundelemente werden derzeit übersehen und sind noch nicht ausreichend erforscht, können jedoch erheblich zu umfassenderen und sichereren Interaktionen zwischen Agenten beitragen.

Sampling – Server können Vervollständigungen vom Client anfordern: Durch Sampling können MCP-Server Vervollständigungen vom clientseitigen LLM anfordern. Dies trägt zur bidirektionalen Natur des Protokolls bei, bei dem der Server nicht nur auf Anfragen antwortet, sondern das Modell des Clients auffordern und bitten kann, eine Antwort zu generieren. Dadurch behält der Kunde die volle Kontrolle über die Kosten, die Sicherheit und das vom MCP-Server verwendete Modell. Wenn Sie also einen externen MCP-Server mit einem vorkonfigurierten Modell verwenden, müssen Sie weder Ihre eigenen API-Schlüssel angeben noch Ihr eigenes Abonnement für dieses Modell konfigurieren, da der Server einfach das bereits mit dem Client verbundene Modell aufrufen kann. Dies ermöglicht komplexere und interaktivere Agentenverhalten.

Roots – eingeschränkter Zugriff auf Ressourcen: Roots wurden entwickelt, um Clients die Möglichkeit zu bieten, Server über relevante Ressourcen und Arbeitsbereiche zu informieren, auf die sie sich konzentrieren sollen. Dies ist leistungsstark, um den Umfang festzulegen, in dem Server arbeiten. Es ist wichtig zu beachten, dass Roots „ informativ und nicht strikt erzwingend“ sind, d. h., sie definieren keine Berechtigungen oder Berechtigungen für MCP-Server oder -Agenten. Mit anderen Worten: Sie können sich nicht allein auf Roots verlassen, um einen Server oder Agenten daran zu hindern, bestimmte Tools auszuführen oder Schreibaktionen durchzuführen. Bei Roots sollten Berechtigungen weiterhin clientseitig mit Mechanismen für Benutzergenehmigungen gehandhabt werden. Darüber hinaus sollten Entwickler weiterhin darauf achten, Server zu verwenden, die so konzipiert sind, dass sie die von den Roots gesetzten Grenzen respektieren und bewährte Methoden verwenden.

Authentifizierung für Agenten: OAuth 2.1 und geschützte Metadaten

Dieser Abschnitt konzentriert sich auf OAuth 2.1, die neueste Version von OAuth 2.0, die unsichere Abläufe beseitigt und bewährte Methoden konsolidiert.

Die OAuth-Unterstützung war ein mit Spannung erwartetes Thema, insbesondere da Sicherheit und Skalierbarkeit als die größten Hindernisse gelten, die verhindern, dass MCP zum Standard für die Verbindung von Agenten mit Tools wird. Aaron Parecki (OAuth 2.1-Redakteur und Experte für Identitätsstandards bei Okta) erläuterte, wie MCP einen sauberen, skalierbaren OAuth-Flow übernehmen kann, der den Serverentwicklern den Großteil der Komplexität abnimmt. Die offizielle Autorisierungsspezifikation OAuth 2.1 wurde kürzlich am 18.06.2025 in der neuesten Protokollrevision veröffentlicht.

In dieser Implementierung können die OAuth-Verantwortlichkeiten zwischen dem MCP-Client und dem Server aufgeteilt werden. Der Großteil des Authentifizierungsflusses wird vom MCP-Client initiiert und verarbeitet. Der Server ist nur am Ende beteiligt, um das sichere Token zu empfangen und zu überprüfen. Diese Aufteilung hilft bei der Lösung eines kritischen Skalierungsproblems bei der Authentifizierung über viele Tools hinweg, ohne dass Entwickler jede einzelne Verbindung konfigurieren müssen, und stellt sicher, dass MCP-Serverentwickler keine OAuth-Experten werden müssen.

Zwei wichtige Highlights aus dem Vortrag:

1. Metadaten geschützter Ressourcen: MCP-Server können eine JSON-Datei veröffentlichen, die ihren Zweck, ihre Endpunkte und ihre Authentifizierungsmethoden beschreibt. Dadurch können Clients OAuth-Flows nur mit der Server-URL starten, was den Verbindungsprozess vereinfacht. Mehr erfahren: OAuth in MCP reparieren

2. Unterstützung für IDPs und SSO: Unternehmen können Identitätsanbieter integrieren, um den Zugriff zentral zu verwalten. Dies ist sowohl für das Benutzererlebnis als auch für die Sicherheit ein Gewinn. Benutzer müssten nicht durch zehn verschiedene Zustimmungsbildschirme klicken und Sicherheitsteams könnten jede Verbindung beobachten.

Indem die OAuth-Logik an den Client übertragen wird und auf Metadaten von Servern zurückgegriffen wird, vermeidet das MCP-Ökosystem einen großen Engpass. Dadurch wird MCP besser an die Art und Weise angepasst, wie moderne APIs in heutigen Produktionsumgebungen gesichert werden.

Zusätzliche Lektüre: OAuth 2 Simplified.

Sicherheitsherausforderungen in einem zusammensetzbaren Ökosystem

Neue Entwicklungen bringen auch neue Angriffsflächen mit sich. Arjun Sambamoorthy von Cisco listet mehrere wichtige Bedrohungen in der MCP-Landschaft auf, darunter:

Bedrohung

Beschreibung

Abhilfemaßnahmen und bewährte Methoden

Sofortige Injektion & Werkzeugvergiftung

Eine Möglichkeit, eine bösartige Eingabeaufforderung in den LLM-Systemkontext oder die Toolbeschreibung einzufügen, wodurch das LLM unbeabsichtigte Aktionen wie das Lesen von Dateien oder das Durchsickern von Daten ausführt.

Verwenden Sie Tools wie MCP Scan, um Überprüfungen der Tool-Metadaten durchzuführen. Überprüfen Sie Beschreibungen und Parameter, bevor Sie sie in Eingabeaufforderungen aufnehmen. Erwägen Sie abschließend die Implementierung von Benutzergenehmigungen für Hochrisikotools. Weitere Einzelheiten finden Sie im OWASP Prompt Injection-Handbuch in der zusätzlichen Leseliste unter der Tabelle.

Sampling-Angriffe

Im Kontext von MCP öffnet das Sampling dem MCP-Server die Tür für sofortige Injektionsangriffe auf das LLM.

Deaktivieren Sie die Stichprobenentnahme für nicht vertrauenswürdige Server und ziehen Sie in Erwägung, menschliche Genehmigungen für Stichprobenanfragen hinzuzufügen.

Bösartige MCP-Server

Bei den aktuellen Sammlungen von MCP-Servern ist es schwierig, jeden einzelnen zu überprüfen, um die Sicherheit zu gewährleisten. Betrügerische Server können Ihre Daten unbemerkt sammeln und böswilligen Akteuren preisgeben.

Stellen Sie nur Verbindungen zu MCP-Servern aus vertrauenswürdigen Registern oder internen Listen her. Führen Sie Server von Drittanbietern in Containern mit Sandboxing aus.

Schädliche MCP-Installationstools

Befehlszeileninstallationsprogramme und -skripte sind praktisch, um MCP-Server oder -Tools schnell zu implementieren, aber Sie könnten am Ende ungeprüften, kompromittierten Code installieren.

Installieren Sie es in Sandbox-Umgebungen und validieren Sie Paketsignaturen. Führen Sie niemals automatische Updates aus nicht verifizierten Quellen durch.

Um dem noch weiter entgegenzuwirken, schlägt Arjun ein vertrauenswürdiges MCP-Register vor, das alle Überprüfungen übernimmt (ein Thema, das im Mittelpunkt stand – weitere Einzelheiten finden Sie in den ersten beiden Punkten der Leseliste unten) und außerdem die Verwendung dieser Sicherheitscheckliste.

Weiterführende Literatur:

• Offizielle Best Practices für MCP-Sicherheit

• OWASP LLM-Bewerbung Top 10

• HiddenLayer-Bedrohungsforschung

• MCP-Scan

• OWASP Prompt Injection-Leitfaden

Was kommt als Nächstes: Register, Governance und Ökosystem

Ein zentrales MCP-Register ist in der Entwicklung und war eines der am häufigsten diskutierten Themen auf dem Gipfel. Das aktuelle Server-Ökosystem leidet unter Fragmentierung, geringem Vertrauen und mangelnder Auffindbarkeit. Für Entwickler ist es schwierig, MCP-Server zu finden, ihre Funktion zu überprüfen und sie sicher zu installieren, insbesondere in einem dezentralen Ökosystem, in dem Metadaten unvollständig oder gefälscht sein können.

Ein zentrales Register behebt diese Schwachstellen direkt, indem es als vertrauenswürdige Quelle der Wahrheit fungiert, die Auffindbarkeit verbessert, die Integrität der Servermetadaten sicherstellt und das Risiko der Installation bösartiger Tools verringert.

Die Ziele des MCP-Registers sind:

• Bereitstellung einer einzigen zuverlässigen Quelle für Servermetadaten (was ein Server tut, wie er authentifiziert, installiert und aufgerufen wird)

• Beseitigung unvollständiger Registrierungen von Drittanbietern und Fragmentierung, sodass ein Server bei der Registrierung nicht jede einzelne andere Registrierung im Internet aktualisieren muss.

• Bereitstellung eines Serverregistrierungsflusses, der ein CLI-Tool und eine server.json-Datei umfasst, die die zuvor erwähnten Metadaten enthält.

Die allgemeinere Hoffnung besteht darin, dass ein vertrauenswürdiges Register dabei hilft, das Ökosystem sicher zu skalieren und es Entwicklern ermöglicht, neue Tools selbstbewusst zu erstellen und zu teilen.

Ein weiteres wichtiges Thema für Anthropic war die Regierungsführung. Sie machten deutlich, dass MCP offen und von der Community gesteuert bleiben sollte, die Skalierung dieses Governance-Modells jedoch noch in Arbeit ist. Sie suchen derzeit in diesem Bereich nach Unterstützung und bitten jeden, der Erfahrung mit der Governance in Open-Source-Protokollen hat, sich zu melden. Dies führt zu dem anderen Thema, das ich erwähnen wollte. Während der gesamten Veranstaltung betonten die Redner, dass das Ökosystem nur durch die Beiträge der Entwickler wachsen kann. Es bedarf konzentrierter Anstrengungen, um MCP zum neuen Webstandard zu machen und es von den anderen gängigen Agentenprotokollen abzuheben.

MCP in der Praxis: Fallstudien und Demos

Mehrere Organisationen berichteten, wie MCP bereits in praktischen Anwendungen eingesetzt wird:

• PayPal – MCP-Server für Agentic Commerce: PayPal stellte sein neues Agent-Toolkit und seinen MCP-Server vor, die das Einkaufserlebnis eines Benutzers grundlegend verändern können. Anstatt soziale Medien nach Artikeln zu durchsuchen, Preise zu vergleichen und zur Kasse zu gehen, können Benutzer mit einem Agenten chatten, der eine Verbindung zum PayPal-MCP-Server herstellt und alle diese Aktionen abwickelt.

• EpicAI.pro – Jarvis: Die Entwicklungen in MCP bringen uns einem echten Assistenten vom Typ Jarvis immer näher. Für diejenigen, die die Iron Man-Filme nicht kennen: Jarvis ist ein KI-Assistent, der natürliche Sprache verwendet, auf multimodale Eingaben reagiert, beim Antworten keine Latenz aufweist, die Bedürfnisse des Benutzers proaktiv antizipiert, Integrationen automatisch verwaltet und zwischen Geräten und Standorten im Kontext wechseln kann. Wenn wir uns Jarvis als physischen Roboterassistenten vorstellen, verleiht MCP Jarvis „Hände“ oder die Fähigkeit, komplexe Aufgaben zu bewältigen.

• Postman – MCP-Server-Generator: Bietet eine Warenkorb-Erfahrung für API-Anfragen, bei der Sie verschiedene API-Anfragen auswählen, in einen Korb legen und den gesamten Korb als MCP-Server herunterladen können.

• Bloomberg – Bloomberg hat einen wichtigen Engpass bei der GenAI-Entwicklung für Unternehmen gelöst. Mit fast 10.000 Ingenieuren benötigten sie eine standardisierte Möglichkeit, Tools und Agenten teamübergreifend zu integrieren. Mit MCP haben sie ihre internen Tools in modulare Remote-First-Komponenten umgewandelt, die Agenten problemlos über eine einheitliche Schnittstelle aufrufen können. Dadurch konnten ihre Ingenieure Tools für die gesamte Organisation bereitstellen, während sich die KI-Teams auf die Erstellung von Agenten statt auf benutzerdefinierte Integrationen konzentrierten. Bloomberg unterstützt jetzt skalierbare, sichere Agenten-Workflows, die die vollständige Interoperabilität mit dem MCP-Ökosystem ermöglichen. Bloomberg hat keine öffentlichen Quellen verlinkt, aber dies ist, was sie auf dem Gipfel öffentlich präsentiert haben.

• Block – Block verwendet MCP, um Goose zu betreiben, einen internen KI-Agenten, der es Mitarbeitern ermöglicht, Aufgaben in den Bereichen Technik, Vertrieb, Marketing und mehr zu automatisieren. Sie haben über 60 MCP-Server für Tools wie Git, Snowflake, Jira und Google Workspace erstellt, um die Interaktion in natürlicher Sprache mit den Systemen zu ermöglichen, die sie täglich verwenden. Die Mitarbeiter von Block verwenden Goose jetzt, um Daten abzufragen, Betrug zu erkennen, Vorfälle zu verwalten, interne Prozesse zu steuern und vieles mehr – und das alles, ohne Code schreiben zu müssen. MCP hat Block dabei geholfen, die Einführung von KI in vielen Berufsfunktionen in nur zwei Monaten zu skalieren.

• AWS – AWS MCP-Server: AWS hat einen unterhaltsamen MCP-Server mit Dungeons-and-Dragons-Thema vorgestellt, der das Würfeln simuliert, vergangene Würfe verfolgt und Ergebnisse über Streamable HTTP zurückgibt. Dieses einfache Beispiel verdeutlicht, wie einfach es ist, MCP-Server mit AWS-Tools und -Infrastrukturen wie Lambda und Fargate zu erstellen und bereitzustellen. Sie stellten außerdem Strands SDK vor, ein Open-Source-Toolkit zum Erstellen multimodaler Agenten, die mit MCP-Servern interagieren.

MCP-Unterstützung im Elastic Agent Builder

Sie können noch heute mit MCP experimentieren und dabei den Elastic Agent Builder verwenden. Dies ist die einfachste Möglichkeit, Agenten direkt auf Basis Ihrer Daten zu erstellen. Mit Agent Builder können Sie Elasticsearch-basierte Tools für MCP-kompatible Agenten bereitstellen. Es enthält bereits einige leistungsstarke integrierte Tools, darunter:

• platform.core.search - Führt Suchvorgänge unter Verwendung der vollständigen Elasticsearch Query DSL aus.

• platform.core.list_indices - Listet alle verfügbaren Indizes in Elasticsearch auf (hilft Agenten, die vorhandenen Daten zu ermitteln)

• platform.core.get_index_mapping - Ruft Feldzuordnungen für einen bestimmten Index ab (hilft Agenten, die Struktur und die Typen Ihrer Daten zu verstehen)

• platform.core.get_document_by_id - Ruft ein bestimmtes Dokument anhand seiner ID ab (für präzisen Abruf)

Mit diesen Tools allein können Sie Ihren Agenten mit Such- und Relevanzfunktionen auf Unternehmensebene ausstatten, was für die Entwicklung zuverlässiger KI-Agenten unerlässlich ist.

Was Agent Builder noch leistungsfähiger macht, ist die Möglichkeit, eigene, auf die Bedürfnisse Ihrer Anwendung zugeschnittene Tools zu definieren und bereitzustellen. Dies ist besonders nützlich für vordefinierte oder wiederholbare Arbeitsabläufe, bei denen der Agent eine bestimmte Art von Suche in einem bestimmten Index durchführen soll, ohne dass diese Logik jedes Mal neu ermittelt werden muss. Anstatt Tokens für Planung und Schlussfolgerung auszugeben, um zum selben Ergebnis zu gelangen, können Sie diese Absicht direkt in ein Tool einprogrammieren, wodurch Ihre Agenten schneller, zuverlässiger und kosteneffizienter werden.

Innerhalb der Agent Builder-Benutzeroberfläche finden Sie hier ein Beispiel für eine benutzerdefinierte Tool-Definition, die ES|QL verwendet:

Sobald Sie Ihre benutzerdefinierten Tools definiert haben, können Sie diese (sowie die integrierten nativen Tools) mithilfe von MCP verfügbar machen, indem Sie auf das Dropdown-Menü für Manage MCP klicken und die MCP-Server-URL kopieren.

Sie können diesen MCP-Endpunkt nun in jeden Client importieren, der MCP verwendet, um ihn mit Agent Builder zu verbinden und ihm Zugriff auf alle verfügbaren Tools zu gewähren. Weitere Informationen finden Sie in dieser Einführung zu Agent Builder.

Fazit

Der MCP Dev Summit machte deutlich, dass MCP die Art und Weise prägt, wie diese KI-Agenten miteinander und mit der sie umgebenden Datenwelt interagieren. Unabhängig davon, ob Sie einen Agenten mit Unternehmensdaten verbinden oder vollständig autonome Agenten entwerfen, bietet MCP eine standardisierte, zusammensetzbare Möglichkeit zur Integration, die im großen Maßstab schnell nützlich wird. Von Transportprotokollen und Sicherheitsmustern bis hin zu Registern und Governance reift das MCP-Ökosystem schnell. MCP wird weiterhin offen und von der Community gesteuert sein, sodass Entwickler heute die Möglichkeit haben, seine Entwicklung mitzugestalten.