Drei KI-Agenten für SQL, Wissenssuche und diese Website – mit den wichtigsten Entscheidungen zu Sicherheit, Kosten und Zuverlässigkeit.

Bei den meisten „KI-Agenten“-Inhalten handelt es sich um eine Demo: eine raffinierte Aufnahme, ein einziger glücklicher Pfad, keine Fehlerbehandlung, keine Kostenobergrenze, kein Plan für den Fall, dass das Modell falsch ist. Das ist es nicht. Nachfolgend sind drei KI-Agentensysteme aufgeführt, die ich in der Produktion betreibe – jeden Tag, auf der Grundlage realer Daten, mit echten Sicherheitsschienen. Jedes ersetzt Arbeit, die ein Mensch früher von Hand verrichtete.

Es geht nicht um „Schau mal, KI“. Der Punkt ist das technische Muster, das ein Modell in ein System verwandelt, auf das Sie sich tatsächlich verlassen können: Es in Ihren Daten verankern, die erlaubten Funktionen eingrenzen, ordnungsgemäß ausfallen und es kostengünstig halten.

Die drei Systeme

System	Ersetzt	Schnittstelle	Stapel
SQL-Agent	„Hey, kannst du diesen Bericht abrufen?“ Anfragen an einen Entwickler	CLI + Telegramm	TypeScript, SQL-Datenbank, OpenRouter
md-agent	Suche in verstreuten Dokumenten nach einer Antwort	Telegramm	TypeScript, SQLite FTS5, OpenRouter
/api/ai (diese Seite)	Allgemeine „Fragen Sie nach meiner Arbeit“-E-Mails	Web (serverseitig)	Cloudflare Workers AI

1. SQL-Agent – natürliche Sprache für schreibgeschütztes SQL

Das Problem. Geschäftsdaten befinden sich in einer SQL-Datenbank. Die Leute, die Antworten brauchen – Eigentümer, Analysten, Buchhalter – schreiben kein SQL. So wird jede Frage zu einem Ticket: „Wie viele Bestellungen kamen letzten Monat von Stammkunden?“ Ein Entwickler unterbricht seine Arbeit, schreibt ein SELECT und fügt eine Tabelle wieder ein. Es ist repetitiv, langsam und blockiert beide Seiten.

Was es tut. sql-agent nimmt eine Frage in einfachem Englisch oder Russisch, generiert ein schreibgeschütztes SELECT, führt es in der Datenbank aus und gibt die Zeilen zurück – plus optional eine Zusammenfassung in einfacher Sprache.

"How many orders from repeat customers last month?"
        ↓  (LLM: schema-aware SELECT generation)
   SELECT count(*) FROM orders WHERE ...
        ↓  (read-only execution + row cap)
   rows → "412 orders, 38% from repeat customers"

Der schwierige Teil ist nicht das SQL, sondern die Sicherheit. Ein Datenbankagent in natürlicher Sprache, der beliebige Abfragen schreiben kann, ist eine Belastung. Die Entscheidungen, die es sicher genug machten, unbeaufsichtigt zu laufen:

• Aufgrund der Konstruktion schreibgeschützt. Der Agent erzeugt immer nur SELECT. Schreibvorgänge und Schemaänderungen werden vor der Ausführung abgelehnt.
• Abfrageprotokollierung. Jede generierte Abfrage wird mit der ursprünglichen Frage protokolliert, sodass alles Fragwürdige im Nachhinein überprüfbar ist.
• Zeilenbegrenzungen und Zeitüberschreitungen. Eine generierte Abfrage, die 40 Millionen Zeilen scannt, kann die Datenbank nicht herunterfahren – die Ergebnisse werden begrenzt und abgebrochen.
• Das Modell ist austauschbar; die Sicherheit ist es nicht. Es läuft auf OpenRouter (standardmäßig Claude Sonnet 4, GLM als Fallback), aber der schreibgeschützte Wächter lebt in meinem Code, nicht im Goodwill des Modells.

Geschäftsanalog. Dies ist genau das System, das ein Shopify-Shop-Inhaber oder ein Betriebsleiter benötigt: Stellen Sie eine Frage in Ihren eigenen Worten, erhalten Sie eine Nummer und warten Sie nie wieder auf einen Entwickler, der einen Routinebericht erhält.

2. md-agent – ein LLM, das auf einer Markdown-Wissensdatenbank basiert

Das Problem. Wissen ist verstreut – Besprechungsnotizen, Prozessdokumente, Entscheidungen, Runbooks – über Dutzende von Markdown-Dateien. Die Stichwortsuche findet Wörter, keine Antworten. Die Leute stellen also entweder Fragen, die bereits beantwortet wurden, noch einmal oder geben auf und treffen Entscheidungen ohne den Kontext.

Was es tut. md-agent ist ein Telegram-Bot, der Fragen beantwortet, die auf Ihrer Markdown-Wissensdatenbank basieren: Er ruft zuerst die relevanten Blöcke ab (SQLite FTS5-Volltextsuche) und übergibt sie dann zur Beantwortung an das LLM. Es geht um „Abrufen und dann antworten“, nicht um freie Generierung.

question → FTS5 retrieve top-k MD chunks → LLM answers FROM those chunks
                                              ↓
                              "no relevant chunks" → honest "I don't know"

Die Entscheidungen, die es zur Produktionsqualität machten:

• Geerdet, nicht halluziniert. Die Antwort ist auf den abgerufenen Kontext beschränkt. Wenn in der KB nichts Relevantes steht, sagt es das, anstatt etwas zu erfinden – die wichtigste Eigenschaft eines vertrauenswürdigen Wissensagenten.
• Leanes Hosting. Es läuft auf einem VPS mit 1 CPU und 2 GB RAM. Ein Wissensdatenbank-Assistent benötigt weder eine GPU noch einen großen Server.
• Free-Tier-Modelle. Der Standardwert ist ein kostenloser OpenRouter-Endpunkt (DeepSeek V3). Die Architektur ist nicht von einem bestimmten Modell oder einer bestimmten Rechnung abhängig.
• Git-Sicherheitsnetz. Die Wissensdatenbank ist versioniert, sodass Änderungen wiederherstellbar sind.

Geschäftsanalog. Interne Wissenssuche und Support-Ablenkung – das gleiche Muster, das ein Support-Team davon abhält, ewig dieselben fünf Fragen zu beantworten.

3. Der Agent auf dieser Site

Diese Site verfügt über einen eigenen kleinen Agenten unter /api/ai. Es ist das leichteste der drei und dient dazu, das Muster zu minimalen Kosten anzuzeigen:

• Nur serverseitig. Keine API-Schlüssel im Browser. Der Browser ruft eine Route auf; Die Route ruft das Modell auf.
• Begrenzte Eingabe. Eingabeaufforderungen sind begrenzt; Nutzlasten sind größenbegrenzt.
• Ratenbegrenzt. Ein Schiebefenster pro IP stoppt Missbrauch.
• Anmutige Verschlechterung. Wenn die Modellbindung fehlt (z. B. eine statische Bereitstellung), wird dies angezeigt, anstatt abzustürzen.
• Günstiges Modell. Es läuft auf einem kleinen Workers-KI-Modell (Llama 3.1 8B) – nicht weil kleine Modelle besser sind, sondern weil ein Portfolio-Assistent kein Grenzmodell benötigt und Kostendisziplin ein Teil des Problems ist.

Das Muster hinter allen dreien

Entfernen Sie die Unterschiede und die gleichen fünf Entscheidungen erscheinen in jedem Produktionsagenten, den ich versende:

1. Erden Sie es. Antworten stammen aus Ihren Daten (abgerufenes SQL-Schema, abgerufene Dokumente, eine kuratierte Systemeingabeaufforderung) – nicht aus der Vorstellungskraft des Modells.
2. Gebunden. Schreibgeschützt. Begrenzte Reihen. Gedeckelte Token. Ablehnung von Anfragen, die außerhalb des Geltungsbereichs liegen.
3. Protokollieren und prüfen. Jede Aktion ist im Nachhinein nachvollziehbar.
4. Fehlerhaft scheitern. Modell heruntergefahren, Bindung fehlt, missbräuchliche Eingaben – das System verschlechtert sich, es stürzt nicht ab und verliert keine internen Komponenten.
5. Halten Sie es günstig. Passen Sie die Größe des Modells an die jeweilige Aufgabe an. Ein Wissensbot benötigt kein 20-Dollar-Token-Modell; Eine schwierige Argumentationsaufgabe sollte nicht auf der billigsten Lösung ausgeführt werden.

Eine Demo überspringt alle fünf. Die Produktion erfordert alle fünf.

Wo dies in meiner Arbeit auftaucht

Das sind keine isolierten Experimente. Die gleichen Muster ziehen sich durch alles, was ich baue – ak-payload (ein Payload-CMS + Next.js-Commerce-Plattform), ak-blog (diese Website) und die Kunden-Fallstudien. Überall dort, wo repetitive, datengebundene Arbeiten anfallen, ist ein ortsansässiger Agent mit begrenztem Umfang in der Regel das richtige Werkzeug. Auf der Website werden spezielle Seiten für diese Projekte eingerichtet.

Vor- und Nachteile des Aufbaus gegenüber dem Kauf eines SaaS

Erstellen, wenn der Workflow zentral ist, die Daten vertraulich sind oder die SaaS-Rechnung mit der Nutzung auf schmerzhafte Weise skaliert (die klassische Zapier-Falle). Kaufen, wenn es sich um eine Standardintegration handelt, bei der Sie nie einen Unterschied machen werden.

Die drei oben genannten Agenten sind alle „Build“ – da sie echte Geschäftsdaten berühren, das Sicherheitsmodell wichtig ist und sich die Kosten pro Anfrage eines SaaS-Äquivalents schnell summieren.

TL;DR

System	Was es beweist	Wichtige Sicherheitsentscheidung
SQL-Agent	NL → SQL in der Produktion	Aufgrund der Konstruktion schreibgeschützt
md-agent	Geerdete KB-Fragen und Antworten zu einem 2-GB-VPS	Abrufen und dann antworten; ehrlich „Ich weiß nicht“
/api/ai	Serverseitiger Agent mit minimalen Kosten	Begrenzte Eingabe + elegante Verschlechterung

Ein KI-Agent ist ein System um ein Modell, nicht das Modell selbst. Das Modell ist der einfache Teil. Die Erdung, die Sicherheitsgeländer, die Kostenobergrenze und der sanfte Ausfall – das ist die Arbeit, und das macht es zuverlässig genug, um jeden Tag zu laufen.Wenn Sie einen sich wiederholenden, datengebundenen Arbeitsablauf haben, den heute eine Person manuell erledigt, ist ein Produktionsagent genau das Richtige für Sie – erzählen Sie mir davon.