Gollem: LLM-Agenten in Go fuer die Produktion

Warum wir Go für Sprachmodell-Agentendienste verwenden

Go bietet uns drei Dinge, die für produktive Agentendienste entscheidend sind: statische Typisierung, die Schemafehler in Sprachmodell-Antworten zur Kompilierzeit aufdeckt, Goroutinen für echte parallele Werkzeugausführung ohne Nebenläufigkeitssperren und Einzelbinär-Deployment, das Abhängigkeitsprobleme zur Laufzeit beseitigt. Python eignet sich gut für Prototypen. Für Dienste mit tausenden gleichzeitiger Agentensitzungen bringt es Betriebskomplexität mit sich, die sich schnell aufsummiert.

Die globale Interpretersperre in CPython verhindert echte Parallelverarbeitung durch Python-Threads. Wenn ein Agent gleichzeitig eine Datenbank abfragen, eine externe Schnittstelle aufrufen und einen Vektorspeicher durchsuchen muss - alles in realen Arbeitsabläufen üblich - erhöht Pythons asynchrones Modell die Komplexität, während Go-Goroutinen das natürlich und kostengünstig bewältigen. Ein zentraler Vorteil für Teams, die sich auf professionelle Webentwicklung in Deutschland von Hochleistungsdiensten konzentrieren. Das Technikteam von Assembled bestätigte dies in der Praxis und bedient Millionen monatlicher Sprachmodell-Anfragen mit Go und minimalem Leistungsaufwand.

Das Deployment-Argument zählt ebenfalls. Ein Go-Agent wird zu einer einzelnen Binärdatei kompiliert. Man kopiert sie in einen Container und führt sie aus. Keine virtuellen Umgebungen, keine Versionskonflikte in Abhängigkeitsdateien, keine Überraschungen zur Laufzeit, wenn das Abbild auf dem Integrationsserver korrekt baut, sich aber auf dem Produktionsserver anders verhält. Für Teams, die Dutzende von Mikrodiensten betreiben, ist diese Einfachheit handfester Mehrwert.

Strukturierte Ausgaben mit Go-Typen

Wenn ein Sprachmodell strukturierte Daten zurückgibt, ermöglicht Gos Typsystem die Validierung zur Kompilierzeit, anstatt Schemafehler um 3 Uhr morgens in der Produktion zu entdecken. Gollem generiert automatisch JSON-Schemata aus Struct-Tags.

// JSON-Schema wird automatisch aus Go-Struct-Tags generiert
type AnalysisResult struct {
    Summary  string   `json:"summary" description:"Kurze Zusammenfassung" required:"true"`
    Severity string   `json:"severity" description:"Risikoebene" enum:"low,medium,high,critical"`
    Score    int      `json:"score" description:"Konfidenz 0-100" minimum:"0" maximum:"100"`
    Tags     []string `json:"tags" description:"Relevante Klassifizierungsetiketten"`
}

Das Sprachmodell erhält dieses Schema und muss eine passende Ausgabe erzeugen. Verstöße gegen Aufzählungswerte und außerhalb des Bereichs liegende Werte zeigen sich beim Parsen, nicht still in den Produktionsdaten. Das ist einer der unterschätztesten Vorteile beim Aufbau von Agenten-Infrastruktur in Go - das Typsystem übernimmt Arbeit, die sonst Laufzeit-Validierungscode erfordern würde.

Wie Gollem aufgebaut ist

Gollem basiert auf fünf Komponenten, die jeweils eine Verantwortlichkeit übernehmen: ein einheitlicher Sprachmodell-Client, eine Sitzungs- und Historienschicht, eine Werkzeugausführungs-Pipeline, zusammensetzbare Zwischenschichten und austauschbare Verhaltensstrategien. Sie werden über klar definierte Schnittstellen verbunden, was das Ganze testbar und wartbar macht.

Agent
  +- LLM-Client (OpenAI / Claude / Gemini)
  +- Sitzung
  |     +- Historie (portabel, serialisierbar, anbieterwandelbar)
  +- Werkzeuge
  |     +- Eigene Werkzeuge (ToolSpec + Run)
  |     +- MCP-Werkzeugsätze (Stdio / StreamableHTTP)
  +- Zwischenschichten-Pipeline
  |     +- Verdichter (Token-Limit-Handling)
  |     +- Werkzeug-Zwischenschichten (Richtliniendurchsetzung, Protokollierung)
  |     +- Eigene Zwischenschichten
  +- Strategie
        +- Einfach (Standardschleife)
        +- ReAct
        +- Plan-and-Execute
        +- Reflexion

Das in der Produktion wertvollste Element ist die Historienschicht. Gespräche sind serialisierbar und zwischen Anbietern portabel. Man kann eine Sitzung in Redis speichern, von einem beliebigen Worker aufnehmen lassen, sie vom OpenAI-Format in das Claude-Format umwandeln, wenn man den Anbieter wechselt, und dort weitermachen, wo man aufgehört hat. Das ermöglicht zustandslose Worker-Architekturen - keine klebrigen Sitzungen, kein gemeinsamer Speicher, saubere horizontale Skalierung. Für verteilte Systeme mit Warteschlangen und Workern ist das wichtiger als die meisten Rahmenwerk-Funktionen.

Die Verdichter-Zwischenschicht löst Token-Limits automatisch. Wenn ein Gespräch das Kontextfenster des Modells überschreitet, fasst der Verdichter die ältesten 70 % der Nachrichten mithilfe des Sprachmodells selbst zusammen und wiederholt den Vorgang. Anstatt abzustürzen, bewahrt der Agent den semantischen Faden des Gesprächs. Seitdem wir es in unseren Stapel aufgenommen haben, mussten wir uns in der Produktion nie mehr mit diesem Problem befassen.

Schleifenschutz ist eingebaut. Die Standardgrenze liegt bei 128 Iterationen, konfigurierbar mit WithLoopLimit. Ein Agent, der in einer Denkschleife gefangen ist, verbraucht Token und blockiert Ressourcen. Harte Grenzen sind eine Produktionsanforderung. Ein Zuverlässigkeitsstandard, der für jeden GEO und AI SEO Dienst auf Basis von Agenteninfrastruktur entscheidend ist.

Werkzeugausführung und Richtliniendurchsetzung

Werkzeuge sind die Schnittstelle zwischen Ihrem Sprachmodell-Agenten und der realen Welt. Wenn ein Agent Datenbanken abfragen, E-Mails senden, Datensätze ändern oder externe Schnittstellen aufrufen kann, ist die Sicherheit der Werkzeugausführung die Sicherheit Ihres gesamten Systems. Gollems Ansatz hier war ausschlaggebend dafür, dass wir es vertrauensvoll für Kundenprojekte einsetzen. Der bei professionellen SEO-Website-Audit-Tools Anwendung findet, wo hunderte Endpunkte analysiert werden, spiegelt diese Sicherheitsarchitektur wider.

Jedes Werkzeug definiert eine typisierte ToolSpec und eine Run-Methode. Die Spezifikation ist deklarativ - Parameternamen, Typen, Beschreibungen, Einschränkungen und Standardwerte sind alle explizit. Das Sprachmodell erhält die Spezifikation als JSON-Schema und kann Werkzeuge nur innerhalb definierter Grenzen aufrufen.

type SearchTicketsTool struct{}

func (t SearchTicketsTool) Spec() gollem.ToolSpec {
    return gollem.ToolSpec{
        Name:        "search_tickets",
        Description: "Supporttickets nach Anfrage und optionalem Statusfilter durchsuchen",
        Parameters: map[string]*gollem.Parameter{
            "query":  gollem.String().WithDescription("Suchanfrage").Required(),
            "status": gollem.String().WithDescription("Optionaler Status: open|closed|pending"),
            "limit":  gollem.Integer().WithDescription("Maximale Ergebnisse").WithDefault(20),
        },
    }
}

func (t SearchTicketsTool) Run(ctx context.Context, args map[string]any) (map[string]any, error) {
    // Echte Integration: DB, Elasticsearch, Jira, Zendesk
    // Produktion: hier Zeitüberschreitungen, Wiederholungen, Sicherungsschalter hinzufügen
    return map[string]any{"tickets": results}, nil
}

Werkzeuge zu definieren reicht nicht aus. Ein Agent, der nicht vertrauenswürdige Eingaben verarbeitet - Benutzeranfragen, externe Dokumente, Daten aus anderen Systemen - kann dazu gebracht werden, Werkzeuge aufzurufen, die er nicht aufrufen sollte, oder mit Parametern, die er nicht akzeptieren sollte. Das ist nicht theoretisch. Es ist die zentrale Angriffsfläche produktiver Agenten. Gollems Antwort darauf ist ToolMiddleware: ein zusammensetzbarer Wrapper um jede Werkzeugausführung, der Richtlinien auf Rahmenwerk-Ebene durchsetzt.

func AllowlistTools(allowed map[string]struct{}, logger *slog.Logger) gollem.ToolMiddleware {
    return func(next gollem.ToolHandler) gollem.ToolHandler {
        return func(ctx context.Context, req *gollem.ToolExecRequest) (*gollem.ToolExecResponse, error) {
            name := req.Tool.Name
            if _, ok := allowed[name]; !ok {
                logger.Warn("Werkzeug durch Richtlinie blockiert", "tool", name)
                return &gollem.ToolExecResponse{
                    Result: map[string]any{"error": "Werkzeug ist durch Richtlinie nicht erlaubt"},
                }, nil
            }

            resp, err := next(ctx, req)

            // Prüfpfad: Wer hat was aufgerufen, wie lange, welche Fehler
            if resp != nil {
                logger.Info("Werkzeug ausgeführt",
                    "tool", name,
                    "duration_ms", resp.Duration,
                    "err", resp.Error,
                )
            }
            return resp, err
        }
    }
}

Dieses Muster kennt jeder, der HTTP-Zwischenschichten in Go geschrieben hat. Man kann Zulassungslisten, Ratenbegrenzung, rollenbasierte Zugriffskontrolle und Protokollierung in eine Pipeline stapeln, in der jede Schicht eine Aufgabe erfüllt. Wir wenden das auf jeden Agenten an, den wir für Kunden bauen - der Richtlinien-Durchsetzungspunkt liegt auf Rahmenwerk-Ebene, unabhängig von der Agentenlogik. Wenn das Sprachmodell dazu gebracht wird, ein nicht auf der Zulassungsliste stehendes Werkzeug anzufordern, wird es vor der Ausführung blockiert und protokolliert.

MCP-Integration und realer Sicherheitskontext

Das Modellkontextprotokoll (MCP) standardisiert, wie Agenten mit externen Werkzeugen und Datenquellen verbunden werden. Gollem unterstützt zwei Transportwege: Stdio für lokale MCP-Server und StreamableHTTP für entfernte. MCP-Werkzeuge werden als ToolSet geladen und durchlaufen dieselbe Zwischenschichten-Pipeline wie jedes andere Werkzeug.

Diese Einheitlichkeit ist wichtig, weil MCP reale Sicherheitsprobleme hatte. Im Jahr 2025 wurden kritische Sicherheitslücken in Anthropics offiziellem Git-MCP-Server entdeckt, darunter die Ausführung von Fremdcode durch Eingabe-Injektion. Forscher fanden über 1.800 MCP-Server, die ohne Authentifizierung zugänglich waren. Ein inoffizieller Postmark-MCP-Server mit 1.500 wöchentlichen Downloads wurde so verändert, dass alle E-Mails still an einen Angreifer weitergeleitet wurden. Das sind reale Produktionsvorfälle, keine Theorien.

Wenn wir MCP-Server in Kundenprojekten einbinden, behandeln wir sie nach dem Prinzip des vollständigen Misstrauens: strenge Zulassungslisten, Protokollierung bei jedem Aufruf, isolierte Ausführungsumgebungen. Gollems Zwischenschichten-Ebene macht das einheitlich, unabhängig davon, ob das Werkzeug aus einer eingebauten Implementierung oder einem externen MCP-Server stammt.

Verhaltensstrategien: Das richtige Ausführungsmuster wählen

Gollem bietet vier eingebaute Strategien: einfache Schleife, ReAct, Plan-and-Execute und Reflexion. Jede ist ein anderes Ausführungsmuster, das für verschiedene Aufgabentypen geeignet ist. Das Rahmenwerk macht diese Wahl explizit - man wählt beim Erstellen des Agenten eine Strategie, und das Verhalten folgt aus dieser Entscheidung.

In der Praxis verwenden wir ReAct für die meisten kundenseitigen Agenten - es bewältigt das Muster "Ich muss ein paar Dinge überprüfen, bevor ich antworte" gut, ohne einen vollständigen Vorabplan zu erfordern. Plan-and-Execute ist unsere erste Wahl für Automatisierungsabläufe, bei denen der Kunde den Plan vor Ausführungsbeginn sehen muss, was in regulierten Umgebungen wichtig ist. Reflexion setzen wir gezielt ein - die Selbstbewertungsschleife liefert für codeintensive Aufgaben bessere Ergebnisse, aber die Tokenkosten erfordern Budgetplanung. Dies ist auch für professionelles Online-Marketing-Plattformen wertvoll, die auf konversationeller KI setzen.

// Einfache Schleife (Standard)
agent, _ := gollem.New(ctx, llmClient, gollem.WithTools(myTools))

// ReAct-Strategie
agent, _ := gollem.New(ctx, llmClient,
    gollem.WithTools(myTools),
    gollem.WithStrategy(react.New()),
)

// Plan-and-Execute - Planungsmodell kann sich vom Ausführungsmodell unterscheiden
agent, _ := gollem.New(ctx, llmClient,
    gollem.WithTools(myTools),
    gollem.WithStrategy(planexec.New()),
)

// Schleifenbegrenzung - in der Produktion immer setzen
agent, _ := gollem.New(ctx, llmClient,
    gollem.WithTools(myTools),
    gollem.WithStrategy(react.New()),
    gollem.WithLoopLimit(20),
)

Strategien lassen sich kombinieren. Reflexion kann auf ReAct aufgesetzt werden für iterative Verbesserung mit adaptivem Denken. Die Strategy-Schnittstelle ist offen, sodass eigene Ausführungsmuster für bereichsspezifische Anforderungen implementiert werden können. Wir haben einige davon für Kunden mit ungewöhnlichen mehrstufigen Arbeitsabläufen entwickelt, die sich nicht sauber auf die eingebauten Muster abbilden lassen. Bis hin zu Websites für Zahnkliniken in Deutschland, die agentengesteuertes Terminmanagement einsetzen - diesen Ansatz anwenden.

Beobachtbarkeit und Tests in der Produktion

Standardüberwachungswerkzeuge decken Sprachmodell-Agenten nicht ausreichend ab. Sie verfolgen HTTP-Latenz und Fehlerquoten, aber ein Agent, der 45 Sekunden braucht, ist nicht unbedingt defekt - er könnte mitten in einem komplexen Plan-and-Execute-Ablauf denken. Ohne agentenspezifische Beobachtbarkeit kann man nicht unterscheiden, ob er "wie erwartet arbeitet" oder "in einer Schleife feststeckt und Token verbrennt". Gollems Ausführungsnachverfolgung erfasst die vollständige Denkkette: angewandte Strategie, aufgerufene Werkzeuge, übergebene Parameter, Schrittdauern und was der Agent als nächstes entschieden hat. Backends sind austauschbar - man leitet zu Datadog, Jäger oder eigenem Speicher über eine einzige Schnittstelle.

Die Kennzahlen, die wir für jede produktive Agentenbereitstellung überwachen:

• Token-Nutzung pro Anfrage - aufgeschlüsselt nach Denkschritt, nicht nur nach gesamter Ein- und Ausgabe
• Latenzverteilung - P50 und P99, einschließlich Werkzeugaufruf-Latenz getrennt von Sprachmodell-Latenz
• Richtlinienverstöße - durch Zulassungsliste oder rollenbasierte Zugriffskontrolle blockierte Werkzeugaufrufe
• Kosten pro Ausführung - Kosten nach Anbieter und Modell, unverzichtbar für Dienstgüteplanung. Unverzichtbar für produktive Google SEO-Workflows, bei denen Agentenaktionen direkt die Rankings beeinflussen.
• Schleifenabbrüche - wie oft Agenten die Schleifengrenze erreichen, was auf Denkprobleme hinweist

Agentenlogik ohne API-Aufrufe testen

Gollem stellt Scheimimplementierungen für LLMClient, Session und Tool bereit. Das bedeutet, umfassende Tests für das Agentenverhalten können ohne einen einzigen API-Aufruf geschrieben werden. Ein Schein-Sprachmodell-Client gibt vorbestimmte Antworten zurück, sodass man testen kann, wie der Agent ein unerwartetes Format, einen fehlgeschlagenen Werkzeugaufruf oder das Erreichen der Schleifengrenze behandelt - ohne auf echte API-Antworten zu warten oder Token-Kosten zu verursachen.

Integrationstests verwenden Umgebungsvariablen-Prüfungen und werden automatisch übersprungen, wenn keine Zugangsdaten vorhanden sind. Das ist gängige Ingenieursdisziplin, aber es lohnt sich, das hervorzuheben, weil viele KI-Rahmenwerke Tests als nachträglichen Gedanken behandeln. Wenn man einen Regressionstest für einen bestimmten Agentenverhaltensfehler schreiben kann, kann man Updates vertrauensvoll in die Produktion bringen.

Diese Testbarkeit ist eines der Signale, nach denen wir bei der Bewertung von Rahmenwerken für Kundenprojekte suchen. Sie bedeutet, dass die Rahmenwerk-Autoren von Anfang an an den Produktionseinsatz gedacht haben - nicht nur "funktioniert es", sondern "kann man sicherstellen, dass es nach Änderungen weiter funktioniert". Ein sauberer Ansatz für professionelles Webdesign und Infrastruktur, der Produktionsumgebungen schlank hält - dies spiegelt die gleichen Prinzipien wider.

Ein vollständiger Produktionsagent in unter 50 Zeilen

Hier ist ein Supportticket-Analyse-Agent, der alles Besprochene zusammenführt: Sprachmodell-Client-Einrichtung, Werkzeugregistrierung, Zwischenschichten-Stapel, ReAct-Strategie und Schleifenbegrenzung. Das ist nah an dem, was wir für Kundensupport-Automatisierungsabläufe bereitstellen.

package main

import (
    "context"
    "log/slog"
    "os"

    "github.com/m-mizutani/gollem"
    "github.com/m-mizutani/gollem/llm/openai"
    "github.com/m-mizutani/gollem/strategy/react"
)

func main() {
    ctx := context.Background()
    logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))

    // 1. Sprachmodell-Client - openai gegen claude oder gemini tauschen ohne weitere Änderungen
    client, err := openai.New(ctx)
    if err != nil {
        logger.Error("Fehler beim Erstellen des Sprachmodell-Clients", "err", err)
        os.Exit(1)
    }

    // 2. Dem Agenten verfügbare Werkzeuge
    tools := []gollem.Tool{
        SearchTicketsTool{},
        GetCustomerHistoryTool{},
        UpdateTicketStatusTool{},
    }

    // 3. Zulassungsliste - Agent darf nur diese drei Werkzeuge aufrufen
    allowed := map[string]struct{}{
        "search_tickets":       {},
        "get_customer_history": {},
        "update_ticket_status": {},
    }

    // 4. Agent zusammensetzen: Zwischenschichten + Strategie + Schleifenbegrenzung
    agent, err := gollem.New(ctx, client,
        gollem.WithTools(tools),
        gollem.WithToolMiddleware(AllowlistTools(allowed, logger)),
        gollem.WithStrategy(react.New()),
        gollem.WithLoopLimit(20),
    )
    if err != nil {
        logger.Error("Fehler beim Erstellen des Agenten", "err", err)
        os.Exit(1)
    }

    // 5. Ausführen
    result, err := agent.Prompt(ctx, "Ticket #4521 analysieren und eine Lösung vorschlagen")
    if err != nil {
        logger.Error("Agentenausführung fehlgeschlagen", "err", err)
        os.Exit(1)
    }

    logger.Info("Agent abgeschlossen", "result", result.Content)
}

Die Zulassungsliste begrenzt den Agenten auf genau drei Werkzeuge, unabhängig davon, was die Anfrage ihn zu tun versucht. ReAct ermöglicht es ihm, das Ticket zu suchen, die Kundenhistorie zu prüfen und über beides nachzudenken, bevor er eine Lösung vorschlägt. Die Schleifenbegrenzung von 20 bedeutet, dass er nicht unendlich läuft, wenn etwas mit der Denkkette schiefläuft. Das ist die Basiskonfiguration, die wir als Ausgangspunkt für jedes neue Agentenprojekt verwenden. Einschliesslich Plattformen für Haushaltsgeräte-Reparaturdienste, die hohe Volumina an Kundenanfragen bearbeiten - diesen Ansatz skaliert.

Deployment: Eine Binärdatei, keine Überraschungen

Gollem-Agenten werden zu einer einzelnen Binärdatei ohne Laufzeitabhängigkeiten kompiliert. Unser Bereitstellungsmuster:

• Bauen: go build -o agent-service ./cmd/agent - eine Binärdatei, läuft überall
• Container: Minimales oder leeres Basisabbild - Binärdatei plus TLS-Zertifikate, sonst nichts
• Konfiguration: Umgebungsvariablen für Sprachmodell-Schlüssel, Werkzeug-Endpunkte, Zwischenschichten-Einstellungen
• Skalierung: Horizontale Kubernetes-Replikate - zustandslos, weil Sitzungshistorie aus externem Speicher (Redis oder PostgreSQL) geladen wird

Zustandsloses Design bedeutet, dass jedes Replikat jede Anfrage verarbeiten kann. Sitzungshistorie wird aus dem Speicher geladen, der Agent führt aus, die Historie wird zurückgespeichert. Keine klebrigen Sitzungen, keine Koordination zwischen Instanzen. Das skaliert sauber und vereinfacht die Störungsbehandlung - man kann jedes Replikat jederzeit beenden, ohne den Gesprächszustand zu verlieren.

Was wir nach dem Einsatz von Gollem in der Produktion schlussfolgern

Gollems Wert liegt nicht in Neuartigkeit - er liegt darin, die richtigen Ingenieursentscheidungen getroffen zu haben: Zwischenschichten für Richtlinien, portable Historie für zustandslose Architektur, explizite Verhaltensstrategien, Scheinschnittstellen für Tests und harte Grenzen für Schleifenschutz. Das sind die Dinge, die den Unterschied machen zwischen einer Demo, die funktioniert, und einem Dienst, den man um 2 Uhr morgens überwachen, prüfen und vertrauen kann.

Der Markt für KI-Agenten wächst schnell, und die 40-Prozent-Projektabbruchrate, die Gartner nennt, ist das direkte Ergebnis von Teams, die Agenten ohne die betriebliche Disziplin zu ihrem Betrieb bereitstellen. Die Teams, die erfolgreich sind, behandeln Agenten als Dienstkomponenten - mit Dienstgütevereinbarungen, Sicherheitsrichtlinien, Kostenkontrolle und ordentlichen Tests.

Wichtigste Erkenntnisse aus unserem Umgang mit Gollem:

• Gos Typsystem erkennt Sprachmodell-Antwortfehler zur Kompilierzeit - weniger Überraschungen in der Produktion als bei Python-Entsprechungen
• Die Werkzeug-Zwischenschichten-Pipeline bietet einen Richtlinien-Durchsetzungspunkt unabhängig von der Agentenlogik - unverzichtbar für vertrauenslosen Werkzeugzugang
• Portable Historie ermöglicht zustandslose Worker-Architekturen - saubere horizontale Skalierung ohne klebrige Sitzungen
• Vier eingebaute Strategien decken die meisten Produktionsanwendungsfälle ab; die offene Strategie-Schnittstelle behandelt den Rest
• Scheinschnittstellen machen Agentenverhalten ohne API-Aufrufe testbar - Regressionstests sind möglich und lohnenswert

Bei Webdelo helfen wir Unternehmen, KI-Agentensysteme in B2B-Arbeitsabläufe zu integrieren - von Supportautomatisierung über interne Wissensabfrage bis hin zu mehrstufigen Geschäftsprozessagenten. Wenn Sie ein agentisches KI-Projekt planen und die Architektur besprechen möchten, bevor Sie eine Zeile Code schreiben, sprechen wir gerne mit Ihnen über die Abwägungen.