Hermes Agent von Nous Research - Deutsche Einführung und OpenClaw-Integration

Was ist der Hermes Agent?

Der Hermes Agent ist ein Produkt von Nous Research, einem Open-Source-Forschungskollektiv, das sich seit mehreren Jahren der Pflege und Veröffentlichung offener Sprachmodelle verschrieben hat. Anders als kommerzielle Anbieter, die ihre Modellgewichte hinter API-Türen verstecken, stellt Nous Research seine Hermes-Familie als Open-Weights-Modelle bereit. Das bedeutet: Du kannst die Modelldateien herunterladen, lokal ausführen, fine-tunen, in eigene Systeme integrieren und sogar kommerziell nutzen, ohne von einem zentralen API-Anbieter abhängig zu sein. Diese Philosophie macht Nous Research zu einem zentralen Akteur der OSS-AI-Bewegung und unterscheidet die Gruppe deutlich von Closed-Source-Häusern wie OpenAI oder Anthropic.

Die Hermes-Modellfamilie umfasst inzwischen mehrere Generationen. Hermes 3 wurde im Jahr 2024 veröffentlicht und basiert auf Llama 3.1 als Grundlagenmodell. Es gibt Varianten mit 8 Milliarden, 70 Milliarden und 405 Milliarden Parametern, sodass Anwender je nach Hardware und Anwendungsfall die passende Größe wählen können. Hermes 4 wird im Forschungsumfeld bereits diskutiert und soll laut Roadmap-Andeutungen weiter an Tool-Use, Reasoning und Strukturierter-Output-Stabilität arbeiten. Für den Praxiseinsatz ist Hermes 3 70B aktuell der Sweet-Spot zwischen Qualität und Hardware-Bedarf, während die 8B-Variante auch auf Consumer-GPUs lauffähig ist.

Der eigentliche Hermes Agent ist mehr als nur ein Modell. Es handelt sich um eine Agent-Plattform, die das jeweilige Hermes-Modell in einen Tool-fähigen Loop einbettet. Konkret bedeutet das: Der Agent kann Funktionen aufrufen, externe APIs nutzen, Code ausführen, Webseiten abrufen und mehrstufige Aufgaben planen. Diese Plattform ist erreichbar unter hermes-agent.nousresearch.com und stellt einen OpenAI-kompatiblen Endpunkt zur Verfügung. Das macht die Integration in bestehende Software-Stacks unkompliziert, weil viele Bibliotheken den OpenAI-API-Vertrag bereits unterstützen.

Beim Lizenzmodell gibt es zwei Ebenen. Die Modellgewichte selbst stehen unter der Llama-3-Community-Lizenz, weil sie auf Metas Llama-Foundation aufbauen. Diese Lizenz erlaubt kommerzielle Nutzung, knüpft aber Bedingungen an Anwender mit über 700 Millionen monatlich aktiven Nutzern. Für die meisten Mittelstands- und SaaS-Projekte ist das praktisch keine Einschränkung. Der Code rund um den Hermes Agent, also die Tool-Loop-Implementierung und die zugehörigen Hilfsbibliotheken, steht überwiegend unter Apache-2.0 oder MIT, was eine sehr permissive Verwertung erlaubt. Das ist ein deutlicher Vorteil gegenüber proprietären Agent-Frameworks, deren Lizenzbedingungen oft im Kleingedruckten Stolpersteine bereithalten.

Die Roadmap von Nous Research deutet auf mehrere parallele Entwicklungslinien hin. Erstens sollen die Modelle selbst weiter verbessert werden, mit Fokus auf längere Kontextfenster, bessere Werkzeugnutzung und reduzierten Halluzinationsraten bei strukturierten Antworten. Zweitens wird die Agent-Plattform um Multi-Agent-Funktionen erweitert, sodass mehrere Hermes-Instanzen kooperativ Aufgaben lösen können. Drittens arbeitet das Team an einer engeren Anbindung an das Model Context Protocol, kurz MCP, das sich als Standard für Tool-Definitionen etabliert. Diese Stoßrichtung entspricht der allgemeinen Bewegung im Agent-Ökosystem und macht Hermes für künftige Architekturen anschlussfähig.

Wer tiefer einsteigen will, findet die offiziellen Repositorien auf GitHub unter dem NousResearch-Account. Dort liegen sowohl die Modell-Konfigurationen als auch Beispielcode für die Agent-Schleife, Evaluations-Skripte und Fine-Tuning-Vorlagen. Die Community ist aktiv auf Discord erreichbar, was bei Integrationsfragen oft schneller weiterhilft als jedes Issue-Tracker-Ticket. Wenn du also auf der Suche nach einer offenen, technisch sauberen und kommerziell nutzbaren Alternative zu den großen geschlossenen Anbietern bist, lohnt sich ein eingehender Blick auf den Hermes Agent.

Hermes vs. OpenClaw - wo liegen die Unterschiede?

Auf den ersten Blick wirken Hermes Agent und OpenClaw wie Konkurrenten, weil beide das Wort Agent im Namen tragen. Tatsächlich operieren sie auf unterschiedlichen Ebenen des Stacks. Hermes ist primär ein Modellanbieter mit angeschlossener Inferenz-Plattform. OpenClaw hingegen ist primär ein Framework, also die Klebeschicht, die Modelle, Tools, Speicher und Orchestrierungs-Logik zu einem lauffähigen Agent verbindet. Wer das nicht trennt, baut sich schnell architektonische Schmerzpunkte ein, die später schwer zurückzudrehen sind.

Die Multi-Agent-Strategie ist ein guter Vergleichspunkt. Hermes konzentriert sich auf einzelne, sehr leistungsfähige Agenten, die in ihrer eigenen Schleife arbeiten. Die Plattform unterstützt zwar parallele Sessions, hat aber keinen ausgeprägten Schwerpunkt auf koordinierter Multi-Agent-Choreografie. OpenClaw setzt dagegen explizit auf Sub-Agents, Worker-Orchestrierung und das Aufteilen großer Aufgaben in kleinere Subprobleme. Das ist besonders wertvoll, wenn du komplexe Pipelines baust, in denen ein Planer-Agent Aufgaben an spezialisierte Worker delegiert. Wer also Multi-Agent-Architekturen plant, profitiert vom OpenClaw-Framework, kann aber innerhalb dieser Architektur einzelne Knoten mit Hermes-Modellen betreiben.

Beim Tool-Ökosystem zeigt sich ein ähnliches Muster. Hermes liefert eine klare Tool-Aufruf-Konvention, die mit JSON-Schemas arbeitet und vom Modell sehr zuverlässig eingehalten wird. Damit endet aber im Wesentlichen das Tool-Angebot, weil die Konkretisierung der Tools dem Anwender überlassen bleibt. OpenClaw kommt mit einer ganzen Bibliothek vorgefertigter Tools für Dateisystem, Web, Datenbanken und Shell-Operationen. Das spart in der Praxis viele Stunden Glue-Code, weil du nicht jedes Standard-Werkzeug neu schreiben musst. Wer Hermes als Modell und OpenClaw als Werkzeugkasten kombiniert, bekommt das Beste aus beiden Welten.

Der MCP-Support-Stand ist ein weiteres Differenzierungsmerkmal. Das Model Context Protocol hat sich innerhalb weniger Monate als de-facto-Standard für Tool-Server etabliert. OpenClaw unterstützt MCP nativ, sodass du beliebige MCP-Server direkt einbinden kannst, ohne Adapter zu schreiben. Hermes arbeitet aktuell an einer engeren MCP-Integration, ist aber noch nicht so tief in den Standard verzahnt. Das heißt nicht, dass MCP mit Hermes nicht funktioniert. Du musst nur etwas mehr Konfiguration einplanen oder die OpenClaw-MCP-Bridge nutzen, um Hermes als reines Modell hinter einer MCP-fähigen Orchestrierung zu fahren.

Die ideale Kombination aus beiden Tools ergibt sich aus der Frage, wo du Energie investieren willst. Wenn dein Team viel Zeit in Modelltraining, Fine-Tuning und Inferenz-Optimierung steckt, ist Hermes ein natürlicher Partner, weil du die Open-Weights nutzen kannst. Wenn dein Team eher an Geschäftslogik, Tool-Integration und Workflow-Orchestrierung arbeitet, ist OpenClaw der bessere Hebel. In der Praxis sehen wir oft, dass Teams OpenClaw als Framework nehmen und Hermes als einen von mehreren Modell-Providern hinterlegen, neben GPT-4o für komplexere Tool-Use-Fälle und einem lokalen Modell für Datenschutz-kritische Pfade.

Ein letzter Aspekt betrifft die Reife der jeweiligen Dokumentation und Beispielprojekte. OpenClaw hat aufgrund seines Framework-Charakters eine größere Sammlung an Tutorials, Quickstarts und Pattern-Beispielen. Hermes punktet mit detaillierter Modellbeschreibung, Benchmark-Daten und Evaluations-Reports. Beide Dokumentationen ergänzen sich gut, sodass eine kombinierte Lektüre dir ein vollständiges Bild vermittelt, wie moderne Agent-Architekturen aufgebaut werden. Verstehe Hermes als das Pferd und OpenClaw als die Kutsche, wenn du das Bild brauchst.

Hermes als Provider in OpenClaw nutzen

Die Integration von Hermes in OpenClaw läuft über den Provider-Mechanismus, den OpenClaw für unterschiedliche Modellanbieter bereithält. Da Hermes einen OpenAI-kompatiblen Endpunkt anbietet, kannst du den vorhandenen OpenAICompatProvider verwenden, ohne neuen Code zu schreiben. Dieser Provider akzeptiert eine Base-URL, einen API-Schlüssel und einen Modellnamen, was praktisch alle Hermes-Konstellationen abdeckt, egal ob du gegen die offizielle Plattform oder einen selbst gehosteten Inferenz-Server fährst.

Das Endpoint-Setup ist denkbar einfach. Die offizielle Hermes-Plattform stellt ihren OpenAI-kompatiblen Endpunkt unter der URL hermes-agent.nousresearch.com/v1 bereit. Hinter dieser Adresse liegen die Standard-Routen wie /chat/completions und /embeddings, sodass alle gängigen Bibliotheken funktionieren. Wenn du selbst hostest, etwa über vLLM, Text Generation Inference oder Ollama, ändert sich nur die Base-URL, alles andere bleibt identisch. Das macht den Wechsel zwischen Cloud und lokalem Setup nahezu friktionsfrei.

Beim API-Key-Handling gilt die übliche Hygiene. Speichere den Schlüssel niemals im Code, sondern lade ihn aus einer Umgebungsvariable oder einem Secret-Manager. Für lokale Entwicklung reicht eine .env-Datei, die du in .gitignore aufnimmst. Für produktive Deployments empfehle ich einen dedizierten Secret-Speicher wie HashiCorp Vault, AWS Secrets Manager oder Doppler. Der Hermes-Schlüssel ist genauso sensibel wie ein OpenAI-Schlüssel, weil er Zugriff auf bezahlte Inferenz-Kapazität ermöglicht. Im folgenden Beispiel siehst du, wie du den Provider mit OpenClaw initialisierst:

from openclaw.providers.openai_compat import OpenAICompatProvider
import os

provider = OpenAICompatProvider(
    base_url="https://hermes-agent.nousresearch.com/v1",
    api_key=os.environ["HERMES_API_KEY"],
    model="hermes-3-llama-3.1-70b",
)

Mit dieser Konfiguration steht der Provider sofort allen OpenClaw-Komponenten zur Verfügung. Du kannst ihn in einen Agent-Loop einhängen, in einer Pipeline nutzen oder als Fallback-Modell für andere Provider hinterlegen. Wichtig ist, dass du den Modellnamen exakt so schreibst, wie ihn die Hermes-Plattform erwartet, weil falsche Namen mit einer wenig hilfreichen 404 quittiert werden. Die aktuell verfügbaren Namen findest du in der Hermes-Dokumentation unter dem Abschnitt Available Models.

Fallback-Strategien sind in der Praxis Gold wert, weil kein Provider zu hundert Prozent ausfallsicher ist. OpenClaw unterstützt eine Provider-Kette, in der du mehrere Provider hintereinander hängst. Wenn der primäre Provider einen Fehler zurückgibt oder ein Timeout auslöst, fragt OpenClaw automatisch den nächsten Provider an. Eine sinnvolle Reihenfolge könnte zum Beispiel Hermes als primär, GPT-4o als sekundär und ein lokales Llama-Modell als Notfall-Pfad sein. So bleibt dein Agent auch dann funktionsfähig, wenn ein einzelner Anbieter Probleme hat. Achte aber darauf, dass die Modelle ähnliche Tool-Use-Fähigkeiten haben, sonst springt dein Agent semantisch hin und her.

Ein häufig übersehener Punkt ist das Token-Budget. Hermes 3 70B unterstützt Kontexte von bis zu 128.000 Tokens, was großzügig ist, aber nicht unbegrenzt. Wenn du lange Konversationen, große Dokumente oder umfangreiche Tool-Outputs verarbeitest, läufst du schneller in Limits, als dir lieb ist. OpenClaw bietet hier ein eingebautes Kontextfenster-Management, das ältere Nachrichten zusammenfasst oder ausblendet, sobald das Limit nahe ist. Aktiviere diese Funktion gleich beim Setup, dann hast du später keine Überraschungen, wenn ein Agent plötzlich mit Truncation-Errors aussteigt.

Wann Hermes lokal mit Ollama hosten?

Lokales Hosting ist für viele Teams ein zentrales Argument pro Hermes, weil es Datenhoheit, Kostenkontrolle und Offline-Tauglichkeit vereint. Ollama hat sich als pragmatische Lösung etabliert, weil es die Komplexität von Modell-Servern hinter einem einfachen CLI versteckt. Mit ollama pull hermes3 holst du dir die Modellgewichte und mit ollama serve startest du einen lokalen OpenAI-kompatiblen Endpunkt auf Port 11434. Diesen Endpunkt bindest du dann genauso in OpenClaw ein, wie du es mit dem Cloud-Endpunkt von Hermes tun würdest. Der Unterschied ist nur die Base-URL, die jetzt auf localhost zeigt.

Beim Hardware-Bedarf hängt alles an der Modellgröße. Hermes 3 8B läuft auf einer Consumer-GPU mit 12 Gigabyte VRAM erstaunlich flott. Eine RTX 4070 Ti oder eine gebrauchte RTX 3090 reicht für sinnvolle Inferenz-Geschwindigkeiten. Hermes 3 70B ist ein anderer Schnack. Hier brauchst du entweder eine A100 80G, zwei RTX 4090 mit Tensor-Parallelismus oder einen Mac Studio mit 192 Gigabyte Unified Memory. Bei Quantisierung auf 4-Bit, was Ollama standardmäßig nutzt, sinkt der Speicherbedarf um etwa drei Viertel, ohne die Antwortqualität dramatisch zu verschlechtern. Für Hermes 3 405B brauchst du Datacenter-Hardware oder eine spezialisierte Cloud-Instanz, weshalb dieser Maßstab praktisch nie lokal gefahren wird.

Der Latenz-Vergleich zur Cloud ist nüchtern zu betrachten. Eine Cloud-Inferenz von Hermes liefert eine Antwort typischerweise in einer bis anderthalb Sekunden für die ersten Tokens. Lokale 8B-Modelle auf einer RTX 4090 erreichen sehr ähnliche Werte, weil das Round-Trip-Network entfällt. Lokale 70B-Modelle sind langsamer, oft im Bereich von zwei bis vier Sekunden bis zum ersten Token, abhängig von Quantisierung und Batch-Größe. Für interaktive Chatbots ist das spürbar, für Hintergrund-Pipelines vollkommen unkritisch. Wer also Echtzeit-Anforderungen hat, sollte die 8B-Variante oder einen Cloud-Endpunkt bevorzugen, während Batch-Workloads von der Kostenersparnis lokaler 70B-Inferenz profitieren.

Bei den Kosten lohnt sich eine ehrliche Rechnung. Eine Cloud-Inferenz von GPT-4o liegt bei etwa 2,5 Cent je 1.000 Tokens, Hermes 3 70B in der Cloud bei rund 0,8 Cent. Bei einem täglichen Volumen von 10 Millionen Tokens summiert sich das schnell auf einen vierstelligen Monatsbetrag. Lokal hast du nur Stromkosten, plus die Abschreibung der Hardware. Eine RTX 4090 zieht unter Vollast etwa 450 Watt, was bei deutschen Strompreisen rund 12 Cent pro Stunde Strom kostet. Bei Vollauslastung sind das knapp 90 Euro pro Monat, ohne Hardware-Kosten gerechnet. Wer kontinuierlich hohe Volumina fährt, amortisiert die Hardware oft in weniger als einem Jahr.

Privacy-Argumente sind in regulierten Branchen oft der eigentliche Treiber. Wenn du in einer Anwaltskanzlei, einer Arztpraxis, einem Versicherer oder einer Bank arbeitest, sind Mandanten-, Patienten- oder Kundendaten so sensibel, dass eine Cloud-Inferenz juristisch oder regulatorisch ausgeschlossen ist. Lokale Hermes-Inferenz löst das Problem elegant, weil keine Daten den eigenen Perimeter verlassen. Du brauchst weder Auftragsverarbeitungsverträge mit US-Anbietern noch komplizierte Daten-Anonymisierungs-Pipelines. Das spart in der Praxis viele Compliance-Stunden und gibt rechtssichere Architektur. Bei Edge-Setups, etwa in der Industrie oder im Außendienst, ist Offline-Betrieb sogar funktionale Voraussetzung, wenn die Internetverbindung nicht garantiert ist.

Praxis-Vergleich - gleicher Agent, drei Provider

Um die Unterschiede greifbar zu machen, haben wir denselben OpenClaw-Agent mit identischer Tool-Konfiguration und identischem System-Prompt gegen drei verschiedene Provider laufen lassen. Die Aufgabe war eine typische Recherche-Operation: Webseite abrufen, Inhalt zusammenfassen, in eine Datenbank schreiben und eine Slack-Nachricht senden. Der Agent musste also vier Tools koordinieren und die Ergebnisse strukturiert zurückgeben. Die folgenden Werte sind Median-Werte aus 50 Durchläufen, also nicht einzelne Glücks- oder Pechfälle.

Was du beim Lesen der Tabelle beachten solltest: Latenz ist die Zeit bis zur ersten sinnvollen Token-Ausgabe, nicht die Gesamtdauer der Aufgabe. Die Kosten beziehen sich auf 1.000 Tokens kombiniert aus Input und Output, was eine konservative Annäherung ist. Die Spalte Beste Eignung fasst zusammen, wofür der jeweilige Provider in der Praxis die richtige Wahl ist. Eine vollständige Bewertung über alle Achsen würde den Rahmen sprengen, aber die Richtung wird klar.

Die Werte streuen je nach Tageszeit, Tool-Konfiguration und Prompt-Länge erheblich. Cloud-Latenzen schwanken zwischen 0,5 und 2,5 Sekunden, lokale Latenzen je nach Hardware und Modellgröße zwischen 0,8 und 6 Sekunden. Kosten variieren mit Anbieter-Preisplänen und Mengenrabatten. Nimm die Tabelle also als Orientierung, nicht als Festwert. Wer eine eigene Entscheidungsgrundlage braucht, sollte den eigenen Anwendungsfall mit allen drei Varianten messen, statt sich auf fremde Benchmarks zu verlassen.

Provider	Latenz (P50)	Kosten je 1k Tokens	Beste Eignung
GPT-4o	0,8 s	2,5 ct	Tool-Use-lastig
Hermes 3 70B	1,5 s	0,8 ct	Open-Weights, lange Kontexte
Hermes lokal	2,5 s	~0 ct (Strom)	Datenhoheit, Offline

Aus der Tabelle lassen sich drei Faustregeln ableiten. Erstens: Wenn dein Agent dutzende Tool-Aufrufe pro Anfrage koordiniert und jeder einzelne Aufruf perfekt sitzen muss, ist GPT-4o aktuell der zuverlässigste Pfad. Zweitens: Wenn du große Dokumente verarbeitest oder in der Open-Weights-Strategie gut aufgehoben bist, liefert Hermes 3 70B ein hervorragendes Preis-Leistungs-Verhältnis bei guter Tool-Use-Qualität. Drittens: Wenn Datenhoheit oder Offline-Betrieb nicht verhandelbar sind, ist die lokale Hermes-Variante alternativlos und liefert für viele Aufgaben überraschend gute Ergebnisse. Die Wahl ist also weniger eine Frage des besten Modells, sondern des passenden Modells für deinen Kontext.

Empfehlung der Akademie

Die OpenClaw Akademie empfiehlt Hermes immer dann, wenn deine Strategie auf Open-Weights und langfristige Anbieterunabhängigkeit setzt oder wenn DSGVO-Druck spürbar ist. Open-Weights bedeutet, dass du jederzeit die Möglichkeit behältst, das Modell selbst zu hosten, fine-zu-tunen oder auf eine andere Inferenz-Plattform zu wechseln. Diese Flexibilität ist gerade für mittelständische SaaS-Anbieter wertvoll, weil sie das klassische Vendor-Lock-in vermeidet. Bei DSGVO-relevanten Workloads liefert lokale Hermes-Inferenz eine saubere Antwort auf die Frage, wo deine Daten verarbeitet werden, weil sie nirgendwo hingehen.

GPT-4 oder dessen aktuelle Nachfolger empfehlen wir, wenn dein Anwendungsfall die letzten paar Prozent Tool-Accuracy braucht und du bereit bist, dafür höhere Token-Kosten und Anbieter-Bindung zu akzeptieren. Typische Felder sind hochkomplexe Coding-Agents, juristische Recherche-Pipelines mit vielen verschachtelten Schritten oder hochwertige Kundenservice-Bots, bei denen jede Halluzination teuer ist. In diesen Szenarien lohnt sich der Aufpreis, weil Fehlerkosten den Modellpreis deutlich übersteigen.

Lokales Hosting empfehlen wir bei Privacy-First-Architekturen, regulierten Branchen und Edge-Setups. Wer einen Sprachassistenten in einer Arztpraxis baut, einen Vertragsanalyse-Agenten für eine Kanzlei betreibt oder eine Industrie-Steuerung mit AI-Features versieht, ist mit lokaler Inferenz strategisch klar besser positioniert. Die Investition in Hardware amortisiert sich dabei oft schneller, als du glaubst, und du gewinnst eine Architektur, die auch dann funktioniert, wenn ein API-Anbieter morgens die Preise verdoppelt oder einen Endpunkt abschaltet. In Summe ist die Antwort auf die Provider-Frage selten ein einzelner Anbieter, sondern eine durchdachte Kombination, in der jeder Provider die Rolle übernimmt, für die er am besten geeignet ist.