postgresql ai-agents vector-database weaviate architecture

Die beste Datenbank für einen Programmier-Agenten: PostgreSQL für den Zustand, hybride Suche für die Wiederauffindbarkeit.

Die beste Datenbank für einen Coding-Agenten: PostgreSQL für den Ausführungszustand, Tool-Aufrufe und Artefakte, plus eine hybride Suchschicht mit einer Ausgangskorrespondenz, sobald das Abrufen von Informationen wichtig wird.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 20267 Min. Lesezeit1720 Wörter

Quellen: The Best Database for Coding Agents? Postgres for State, Weaviate for Recall

Wählen Sie eine Datenbank für einen Programmieragenten anhand dessen aus, was der Agent den ganzen Tag über tut, und nicht anhand der KI-Bezeichnung. Ein Agent, der sandbox-basierte Befehle ausführt, Tools aufruft, Logs streamt, Dateien erstellt, fehlgeschlagene Schritte erneut versucht und nach Unterbrechungen fortsetzt, kümmert sich hauptsächlich um Buchhaltung mit Nebeneffekten. Für diese Buchhaltung ist PostgreSQL die zuverlässige Standardlösung. Ein Vektorlager wie Weaviate findet erst später als separate Schicht Verwendung, wenn das Produkt ähnliche frühere Fehler und Lösungen nach ihrem Inhalt finden muss.

Beginnen Sie mit einem einzigen Toolaufruf

Verfolgen Sie einen einzelnen Toolaufruf durch das System. Bevor er ausgeführt wird, markiert die Plattform den Aufruf als gestartet, verknüpft ihn mit einem Lauf, reserviert eine Idempotenzschlüssel, notiert, welches Sandbox verwendet wird, und stellt nachfolgende Aufgaben in die Warteschlange. Nach Abschluss wird der Status, Metadaten der Ausgabe sowie Artefakte aufgezeichnet, die Gesamtnutzung aktualisiert und der übergeordnete Lauf vorangetrieben.

Diese Schreibvorgänge bilden eine logische Abfolge. Bei Transaktionen werden sie entweder gemeinsam abgeschlossen oder gar nicht, und andere Sitzungen sehen niemals einen halbfertigen Zustand. Betrachten wir nun die Fehlerfälle: Ein Prozess stirbt zwischen „Tool abgeschlossen“ und „Erweiterte Ausführung“, wobei die Wiederherstellung deterministisch sein muss. Es kommt zu zwei Wiederholungsversuchen, und eine eindeutige Beschränkung sollte Duplikate ablehnen. Ein Artefakt verweist auf eine nicht existierende Ausführung, und eine Fremdschlüsselbeschränkung sollte die Zeile ablehnen. Nichts davon ist außergewöhnlich – es handelt sich um gewöhnliche Aufgaben in Datenbanken, auf die sich Programmieragenten ständig stützen, weshalb sie jede Art von „AI-eigenem“ Marketing überwiegen.

Die Daten sind relational

Die Kernentitäten eines Ausführungsagenten sind nicht geheimnisvoll, und sie sind miteinander verbunden:

Ausführungen enthalten den Lebenszykluszustand, den Eigentümer, den Arbeitsbereich, das Modell, Zeitstempel, das Budget sowie das endgültige Ergebnis.
Schritte sind geplante oder abgeschlossene Arbeitseinheiten mit gegenseitigen Abhängigkeiten.
Toolaufrufe speichern Eingaben, Ausgaben, Status, Latenzzeit, Anzahl der Wiederholungsversuche sowie Idempotenzschlüssel.
Sandbox-Ausführungen beschreiben die Umgebung, Metadaten der Befehle, den Abbruchcode, den Ressourcenverbrauch sowie den Grund für das Ende.
Ereignisse bilden eine nur zum Hinzufügen geeignete Historie für Debugging, Streaming und Wiedergabe.
Artefakte verweisen auf Patches, Berichte, generierte Dateien oder Speicherorte in Objektspeichern.
Checkpointe speichern das, was benötigt wird, um einen Workflow wieder aufzunehmen.

Jedes Element benötigt eine stabile Identität sowie explizite Verbindungen zu den anderen. Primärschlüssel, eindeutigkeitsbeschränkungen, Prüfbeschränkungen und Fremdschlüssel erschweren das Erstellen ungültiger Zustände, wobei Fremdschlüssel insbesondere sicherstellen, dass jeder Toolaufruf zu einer tatsächlichen Ausführung gehört und jedes Artefakt auf seinen Ersteller zurückverfolgt werden kann.

Halten Sie die für die Koordination wichtigen Felder in typisierten Spalten mit geeigneten Indizes bereit: Status, Mieter, Ausführungs-ID, Zeitstempel, Versuchszahl und Idempotenzschlüssel. Sie ermöglichen die Planung, das Filtern, die Aufbewahrung sowie die Erstellung von Dashboards. Ihr Verstecken in einem großen, nicht differenzierten JSON-Dokument erschwert die Einhaltung dieser Regeln erheblich.

Wo jsonb hingehört

Tools ändern sich schnell. Einige liefern Compiler-Diagnosen, andere erzeugen Browser-Events, wieder andere berichten Metadaten des Repositoriums. Ein fester Spalte für jedes mögliche Feld wäre verschwenderisch, und jsonb eignet sich für die variablen Teile: Tool-Argumente, Provider-Antworten, Sandbox-Konfigurationen sowie Modellmetadaten. PostgreSQL kann mit Operatoren und Pfadausdrücken in JSON abfragen und Schlüssel sowie Werte mit GIN indizieren, wobei die damit verbundenen Kompromisse im offiziellen Handbuch dokumentiert sind.

Das funktionierende Muster besteht aus einem typisierten relationellen Rahmen um einen flexiblen Payload. Alles, was für Integrität oder häufige Abfragen benötigt wird, bleibt in Spalten, während Erweiterungsdaten in jsonb gespeichert werden. Dadurch werden beide Extreme vermieden: entweder brüchige Spalten für jedes Experiment oder ein undurchsichtiger Dokumentenspeicher, der alle Beziehungen dem Anwendungscode überlässt.

Speicherung an das Zugriffsmodell anpassen

Nicht alles muss in der Hauptdatenbank gespeichert werden. Kurze Auszüge aus stderr, normalisierte Fehlerdetails, Abbruchcodes sowie suchbare Zusammenfassungen passen neben das Ausführungsprotokoll. Große Konsolein Ausgaben, Repository-Archive, Binärdateien, Screenshots sowie Build-Ausgaben gehen in der Regel in das Objektspeichersystem, wobei PostgreSQL sie über dauerhafte Metadaten und Checksummen verweist.

Diese Trennung hält die Datensätze klein, während die Herkunft bewahrt bleibt. Die Datenbank bleibt die Quelle der Wahrheit darüber, ob ein Artefakt existiert, welcher Ausführungsvorgang es erzeugt hat, wo es sich befindet und wie die Aufbewahrungsfristen gelten, während das Objektspeichersystem große, unveränderliche Datenblöcke kostengünstiger verarbeiten kann. Eine Vorsichtsmaßnahme: Lassen Sie niemals das Protokoll behaupten, dass ein Upload erfolgreich war, solange der Workflow kein Wiederherstellungsplan für teilweise fehlgeschlagene Vorgänge hat.

Die Ereignisgeschichte ist ebenfalls hilfreich. Anstatt ständig ein großes Dokument mit allen Abläufen neu zu schreiben, sollten sinnvolle Übergänge aufgezeichnet und eine kompakte Zeile mit dem aktuellen Zustand für schnelle Abfragen bereitgehalten werden. Die Geschichte dient der Überprüfung und Diagnose, die Prognose dem Produkt-UI sowie dem Scheduler – beides kann in PostgreSQL innerhalb derselben Transaktionen gespeichert werden.

Das Schreibprotokoll ist genauso wichtig wie der Engine

In der Produktion treten häufig doppelte Lieferungen, Abstürze der Arbeitsprozesse, Netzwerkzeitüberschreitungen sowie Ergebnisse von Tools auf, die niemand bestätigen kann. Die Wahl einer Datenbank ist nur die halbe Lösung. Ein funktionsfähiges Protokoll sieht wie folgt aus:

Geben Sie wiederholbaren Operationen eine Idempotenzschlüssel zu, der durch eine eindeutige Beschränkung abgesichert ist.
Modellieren Sie Lebenszyklusänderungen als benannte Zustandsübergänge und nicht als freie Statusaktualisierungen.
Committen Sie verwandte Zeilen in einer Transaktion, sobald eine teilweise Sichtbarkeit falsch wäre.

Verwenden Sie einen Ausgangskorb, wenn eine gespeicherte Änderung eine Nachricht oder einen Indexierungsjob auslösen muss.

Halten Sie Rohereignisse dort unveränderlich, wo eine Prüfung erforderlich ist, und erstellen Sie bei Bedarf neue Prognosen daraus.

Speichern Sie Zeitüberschreitungen sowie „unbekanntes Ergebnis“ getrennt von bestätigten Fehlern.

Diejenigen, die nach der besten Datenbank für einen Coding-Agenten suchen, speichern nicht nur Chatnachrichten. Sie koordinieren Nebeneffekte wie das Bearbeiten von Dateien, das Ausführen unsicheren Codes, den Aufruf bezahlter APIs sowie die Veröffentlichung von Änderungen. Die Zustandslage muss so gestaltet sein, dass jeder Übergang überprüfbar und wiederherstellbar ist.

Wann sich eine Abrufschicht lohnt

PostgreSQL bleibt die Hauptempfehlung. Fügen Sie einen speziellen Abrufspeicher hinzu, wenn das Produkt eine besondere Anforderung hat: das Suchen in der bisherigen Ausführungshistorie nach Bedeutung sowie nach exaktem Text. Typische Abfragen lauten „Welche früheren Ausführungen sind nach einem Upgrade einer Abhängigkeit fehlgeschlagen?“, „Welche Fehler wurden mit diesem Stack Trace behoben?“ und „Welche Werkzeugkette hat einen unzuverlässigen Test behoben?“

In dieser Suche spielen genaue Token weiterhin eine Rolle: Ausnahmenamen, Paketversionen, Compilercodes, Flags, Dateinamen und Hash-Werte. Dennoch beschreiben Benutzer denselben Fehler auf viele verschiedene Weise. Eine reine Schlüsselwortsuche überseht konzeptionelle Zusammenhänge, während eine reine Vektorähnlichkeitssuche die wörtlichen Zeichenfolgen, auf die Ingenieure angewiesen sind, unterschätzen kann. Eine hybride Suche berücksichtigt beides. Weaviate ist ein solcher Motor, der Vektorsuche und BM25-Schlüsselwortsuche gleichzeitig ausführt und die Ergebnisbewertungen zu einer einzigen Rangliste zusammenführt – sodass ein wörtlicher Code wie ERR_MODULE_NOT_FOUND als Schlüsselwortbeleg dient, während der Satz „Der Laufzeitumgebung gelingt es nicht, ein importiertes Paket zu auflösen“ als semantischer Beleg gilt.

Halten Sie die Grenzen explizit fest. PostgreSQL ist für die kanonischen Ausführungen, Toolaufrufe, Berechtigungen und den Status verantwortlich. Ein asynchroner Worker liest die gespeicherten Änderungen, erstellt ein Abrufdokument aus ausgewählten Feldern und fügt es in den Suchindex ein. Bei Treffern werden die PostgreSQL-ID angegeben, sodass die Anwendung das autoritative Datensatz holt und den Zugriff erneut überprüft, bevor etwas angezeigt wird. Selbst wenn das Indexieren zurückbleibt oder neu erstellt werden muss, bleibt die Korrektheit der Ausführung unberührt.

Ein zweites System macht nur dann Sinn, wenn semantische Wiederherstellung tatsächlich eine Funktion darstellt. Davor reichen die Volltextsuche von PostgreSQL in Kombination mit gut indizierten strukturierten Abfragen aus.

Eine fünfteilige Referenzstruktur

Authoritatives Zustandsmodell in PostgreSQL. Ausführungen, Schritte, Toolaufrufe, Ergebnisse aus Sandboxes, Metadaten der Artefakte, Kontrollpunkte sowie Zugriffsbeziehungen.
Große Payloads im Objektspeicher. PostgreSQL speichert Standorte, Hash-Werte, Inhaltstypen, Eigentümer sowie Daten zur Aufbewahrungsfrist.
Eine Ausgangskiste für gespeicherte Änderungen. Worker übertragen UI-Updates in Echtzeit, planen nachfolgende Aufgaben und erstellen Suchprojektionen, ohne mit ungespeicherten Daten konkurrieren zu müssen.
Abruf von Dokumenten aus einem Vektor- oder Hybridindex, falls erforderlich. Enthält Zusammenfassungen, normalisierte Fehlermeldungen, Befehle, ausgewählte Protokollauszüge, Beschreibungen zu Korrekturen sowie filterbare Metadaten.
Suchergebnisse werden gegen PostgreSQL abgeglichen. Der Index findet mögliche Kandidaten, während die Datenbank weiterhin die Autorität bezüglich des aktuellen Zustands und der Berechtigungen bleibt.

Die Löschung und Beibehaltung werden ebenfalls einfacher zu verstehen. Eine Löschung oder Bearbeitung beginnt in PostgreSQL, gelangt über den Ausgangskorb, löscht die damit verbundenen Objekte und aktualisiert die Suchprojektion, sodass die Quelle der Wahrheit niemals zweideutig ist.

Was man frühzeitig vermeiden sollte

Eine Vektordatenbank nur weil ein LLM vorhanden ist. Frühe operative Fragen sind meist strukturiert, wie z. B. Ausführungen für einen Benutzer in einem bestimmten Status, kürzlich fehlgeschlagene Schritte, langsame Toolaufrufe oder Ausführungen, die mit einem Commit verbunden sind. Gewöhnliche Indizes beantworten diese Fragen.
Ein einziger JSON-Blob für den gesamten Agentenzustand. Dadurch geht kurzfristige Bequemlichkeit zugunsten schwacher Einschränkungen, unpraktischer gleichzeitiger Aktualisierungen und schwieriger Lebenszyklusabfragen verloren. Flexible Metadaten sind in Ordnung, aber ein unstrukturiertes System zur Datenspeicherung nicht.

Suche innerhalb der kritischen Transaktion. Der Agent sollte einen Tool-Aufruf abschließen, selbst wenn die semantische Indizierung verzögert ist. Die Ausgangskorrespondenz und die asynchrone Projektion schützen diese Grenze.

Checkliste

Wählen Sie zunächst PostgreSQL, wenn Sie benötigen:

ACID-Transaktionen mit mehreren Zeilen anstelle von Ausführungsprotokollen,
erzwungene Verbindungen zwischen Ausführungen, Schritten, Aufrufen, Benutzern und Artefakten,
sichere Wiederholungsversuche sowie Konkurrenzkontrolle,
einfaches Filtern nach Status, Zeit, Eigentümer, Kosten oder Ergebnis,
jsonb-Metadaten, die weiterhin abgefragt werden können,
ein dauerhafter Datensatz zur Wiederherstellung und Prüfung.

Fügen Sie einen hybriden Suchmotor hinzu, wenn Sie außerdem benötigen:

sinnbasierte Suche in der Historie früherer Ausführungen und Tool-Aufrufe,
ein Ranking, das genaue Fehlerangaben sowie ähnliche Formulierungen gleichwertig berücksichtigt.
die Suche nach verwandten Vorfällen, Lösungen sowie funktionierenden Arbeitsabläufen,
eine Abfrageschicht, die aus kanonischen Datensätzen regeneriert werden kann.

Schnelle Antworten

Sollte die Vektordatenbank die primäre Backend-Lösung sein? In der Regel nicht. Die Hauptlast entsteht durch transaktionale Abläufe: Ausführungen, Toolaufrufe, Ergebnisse, Wiederholungsversuche und Beziehungen. Eine Vektordatenbank dient einer separaten Abfragelast.

Ist jsonb ausreichend für Metadaten von Agenten? Oft schon, insbesondere für sich entwickelnde Tool-Pakete sowie anbieterbezogene Details, sofern typisierte Spalten Identifikatoren und Lebenszyklusfelder enthalten. Es ergänzt das Schema, ersetzt es aber nicht.

Warum hybride Suche für Logs? Ingenieurdaten enthalten präzise Token neben natürlicher Sprache. BM25 zeigt exakte Codes, Paketnamen und Dateinamen an, während die Vektor Suche unterschiedlich formulierte Beschreibungen derselben Fehler verknüpft.

Das beste Design beruht auf einer Aufgabenteilung und nicht auf einem Wettbewerb zwischen relationellen und Vektorsystemen. PostgreSQL bildet die transaktionale Grundlage: Er führt Ausführungen durch, protokolliert sie, speichert die Historie von Toolaufrufen, Metadaten, Kontrollpunkte sowie Artefakte. Wenn die Ausführungshistorie zu einem Wissenswert wird, fügt eine hybride Suchschicht obenauf die Fähigkeit zur Wiederabrufung hinzu. Postgres für den Zustandsmanagement, ein Suchindex für die Wiederabrufung.