Von KI Agent auf eigenem VPS bauen
Erfahren Sie, wie Sie einen KI Agent mit einer Loop um ein Language Model entwickeln. Lernen Sie den Einsatz von Tools, MCP und Memory auf Ihrem VPS kennen.
Was ein KI-Agent tatsächlich ist
Ein KI-Agent ist eine Schleife, die um ein Sprachmodell (Language Model) gelegt ist. Das Modell analysiert die Situation, entscheidet sich für eine Aktion, Ihr Code führt diese Aktion aus, das Ergebnis geht zurück an das Modell, und die Schleife läuft erneut, bis die Aufgabe erledigt ist. Das ist das Grundkonzept. Ein einfacher Chatbot antwortet einmal und stoppt. Ein Agent arbeitet kontinuierlich weiter und führt zwischen seinen eigenen Schritten echte Aktionen aus, bis er ein vorgegebenes Ziel erreicht hat.
Die Aktion ist der entscheidende Teil. Ein Sprachmodell allein erzeugt nur Text. Es kann keine Datei lesen, keine API aufrufen und keinen Befehl ausführen. Ein Agent stellt dem Modell einen Satz an Tools zur Verfügung, die es benutzen darf, sowie eine Methode, um diese anzufordern. Wenn das Modell das Web durchsuchen oder eine Datei schreiben möchte, erledigt es die Arbeit nicht selbst. Es gibt eine strukturierte Anfrage aus, Ihr Code führt das Tool aus, und die Antwort wird als nächstes Element an das Modell zurückgegeben. Das Modell liefert die Logik; Ihr Server liefert die Ausführung.
Nicht jede Aufgabe benötigt einen Agenten. Die Standardnutzung eines Agenten ist ein häufiger Fehler. Wenn die Schritte im Voraus bekannt sind, ist ein einfaches Skript einfacher, schneller und zuverlässiger. „Rufe diese Seite jede Stunde ab und sende mir den Preis per E-Mail“ ist ein geplanter Job (Scheduled Job), kein Agent. Bauen Sie einen Agenten, wenn der Pfad nicht im Voraus festgelegt ist und das Modell die Funde analysieren muss, um über das weitere Vorgehen zu entscheiden. Die Kosten eines Agenten liegen in der Unvorhersehbarkeit; nutzen Sie diese Flexibilität nur, wenn sie sich lohnt.
Tools: Wie ein Agent agiert
Ein Tool ist jede Fähigkeit, die Sie dem Modell übergeben, sofern sie präzise genug beschrieben ist, damit das Modell weiß, wann es darauf zugreifen muss. Eine Datei lesen, einen Shell-Befehl ausführen, eine Datenbank abfragen oder eine Nachricht senden: Jedes davon ist ein Tool mit einem Namen, einer kurzen Beschreibung und einer Liste von Inputs. Sie definieren die Tools; das Modell entscheidet, wann es sie aufruft.
Der Mechanismus ist universell, unabhängig vom verwendeten Modell. Das Modell gibt eine strukturierte Anfrage zurück, die ein Tool benennt und die Inputs ausfüllt. Ihr Code erkennt diese Anfrage, führt die entsprechende Funktion aus und sendet das Ergebnis im nächsten Schritt zurück. Das Modell liest das Ergebnis und ruft entweder ein weiteres Tool auf oder schreibt seine finale Antwort. Function Calling ist das Fundament jedes Agenten, und die Schleife, die es antreibt, besteht nur aus wenigen Zeilen Standard-Code.
Hier liegt auch Ihre Kontrolle. Das Modell kann den Ausführen eines Befehls anfordern, aber es wird nichts ausgeführt, bis Ihr Code die Ausführung bestätigt. In dieser Lücke implementieren Sie Bestätigungsabfragen (Approval Prompts) für gefährliche Aktionen, Beschränkungen für den Zugriff von Tools und ein Protokoll (Log) über alle Aktivitäten des Agenten. Ein Agent ist nur so sicher wie die Tools, die Sie ihm geben, und die Prüfungen, die Sie vorschalten.
MCP: Ein Standard zur Verbindung von Tools
Jede Integration für jeden Dienst manuell neu zu schreiben, ist ineffizient. Das Model Context Protocol (MCP) ist ein offener Standard, der dieses Problem löst. Anstatt ein neues Tool für Ihre Dateien, Ihre Datenbank und Ihren Issue-Tracker zu programmieren, verweisen Sie den Agenten auf einen MCP-Server, der diese Funktionen bereits als Tools bereitstellt. Der Agent spricht ein einziges Protokoll; der Server übernimmt die Kommunikation mit dem eigentlichen System.
Der Vorteil ist die Wiederverwendbarkeit. Ein MCP-Server, den jemand anderes für einen Dienst geschrieben hat, steht Ihrem Agenten ohne neuen Integrationsaufwand zur Verfügung. Ein selbst geschriebener Server ist für jeden Agenten nutzbar, der das Protokoll unterstützt. Auf einem VPS ist dies wichtig, da Sie MCP-Server als eigene kleine Dienste neben dem Agenten ausführen können, wobei jeder nur die benötigten Berechtigungen besitzt. Die Einrichtung beschreibe ich in running MCP servers on a VPS.
Speicher und Abruf (Retrieval)
Ein Sprachmodell besitzt kein eigenes Gedächtnis zwischen den Aufrufen. Alles, was es über die aktuelle Aufgabe wissen muss, muss in jedem Schritt neu übergeben werden. Bei kurzen Aufgaben ist das unproblematisch, da die gesamte Konversation in eine Anfrage passt. Bei längeren Aufgaben müssen Sie den Speicher selbst verwalten; dabei gibt es zwei relevante Muster.
Das erste ist ein Scratchpad (Notizblock). Sie geben dem Agenten eine Datei zum Lesen und Schreiben und weisen ihn an, seine Erkenntnisse laufend zu protokollieren. Im nächsten Schritt oder in der nächsten Sitzung liest er die Datei aus und macht an der entsprechenden Stelle weiter. Dies ist Speicher in Form eines einfachen Dokuments, was funktioniert, weil der Agent die Datei wie ein weiteres Tool behandelt.
Das zweite ist Retrieval. Wenn der Agent Wissen aus einer großen Menge an Dokumenten benötigt, die nicht in eine einzelne Anfrage passen, speichern Sie diese Dokumente in einer durchsuchbaren Form. Nur die relevanten Textstellen werden bei Bedarf in den Kontext des Modells geladen. Dieses Muster wird Retrieval-Augmented Generation (RAG) genannt. Der Agent stellt eine Frage, Ihr Code findet die passenden Textstellen, und nur diese werden an das Modell gesendet. Der Speicher befindet sich auf Ihrem Server, sodass Ihre privaten Dokumente diesen niemals verlassen.
Viele Agenten, ein Koordinator
Ein einzelner Agent mit vielen Tools reicht für die meisten Aufgaben aus. Wenn eine Aufgabe groß ist oder sich natürlich in Teile aufteilt, ist eine andere Struktur hilfreich: ein Koordinator-Agent, der Aufgaben an spezialisierte Sub-Agenten delegiert. Der Koordinator zerlegt das Ziel in Teilaufgaben, übergibt jedes Teil an einen für diesen Zweck gebauten Sub-Agenten und kombiniert die Ergebnisse.
Der Vorteil ist die Fokussierung. Ein Sub-Agent mit einem engen Aufgabenbereich und einem kleinen Tool-Set trifft bessere Entscheidungen als ein Generalist, der alles gleichzeitig bearbeiten muss. Zudem können unabhängige Teilaufgaben gleichzeitig ausgeführt werden. Der Nachteil ist der Koordinationsaufwand; bleiben Sie daher bei einem einzelnen Agenten, bis eine Aufgabe eindeutig mehr Kapazität erfordert. Beginnen Sie einfach und fügen Sie Agenten erst hinzu, wenn ein einzelner Agent an seine Grenzen stößt.
Self-hosted oder Hosted: Welches Modell treibt Ihren Agenten an?
Das Modell ist der einzige Teil eines Agenten, den Sie nicht selbst betreiben müssen. Die Entscheidung über den Standort ist die wichtigste Entscheidung. Ein gehostetes Modell, das über eine API angesprochen wird, bietet die stärkste Logik ohne eigenen Betrieb: Sie senden Text und erhalten Text zurück. Ein selbst gehostetes (self-hosted) Modell läuft auf Ihrem eigenen Server. Dies hält jede Anfrage privat, kostet einen Festpreis statt pro Token und ist nicht von der Verfügbarkeit externer Anbieter abhängig. Der Kompromiss liegt zwischen Leistungsfähigkeit und Aufwand. Die besten gehosteten Modelle sind leistungsfähiger als das, was Sie selbst betreiben können; ein eigener Betrieb erfordert zudem ausreichend Arbeitsspeicher.
Dieser letzte Punkt ist die praktische Hürde. Ein Modell muss in den Arbeitsspeicher Ihres Servers passen; bei Nutzung einer GPU muss es in den Videospeicher passen. Ein zu großes Modell lässt sich nicht laden. Bevor Sie einen selbst gehosteten Agenten planen, prüfen Sie, ob das gewünschte Modell auf Ihre Hardware passt:
Falls die Werte nicht passen, haben Sie drei Optionen: Wählen Sie ein kleineres Modell, nutzen Sie eine aggressivere Quantisierung zur Komprimierung oder verwenden Sie eine gehostete API für die Logik und halten Sie nur Ihre Tools und Daten auf dem Server. Viele selbst gehostete Agenten starten mit einem lokalen Modell über Ollama on a VPS und nutzen für komplexe Schritte eine gehostete API als Fallback.
Der Server ist der kritische Punkt
Ein Agent, der Shell-Befehle ausführen und Dateien schreiben kann, ist mächtig, und genau deshalb gefährlich. Die Logik des Modells ist gut, aber nicht perfekt. Eine fehlerhafte Anweisung, ein Bug oder eine bösartige Eingabe können einen hilfreichen Agenten in ein Werkzeug verwandeln, das falsche Dateien löscht oder Geheimnisse preisgibt. Sicherheitsmaßnahmen sind obligatorisch; auf einem Server sind sie der wichtigste Aspekt.
Einige Gewohnheiten reduzieren das Risiko erheblich. Führen Sie den Agenten als dedizierten, unprivilegierten Benutzer aus (niemals als root), um den Schaden bei Fehlern zu begrenzen; Details dazu finden Sie in running services as an unprivileged user. Halten Sie Geheimnisse wie API-Keys außerhalb des Codes und nur für diesen Benutzer lesbar. Sandboxing ist für Tools, die auf das System zugreifen, zwingend erforderlich, damit der Agent nur auf das zugreifen kann, was er wirklich benötigt. Ein praxisnahes Beispiel zur Härtung eines selbst gehosteten Agenten finden Sie unter running OpenClaw safely on a VPS. Wenn Sie lieber ein gehostetes Modell für die Intelligenz nutzen möchten, bietet der Leitfaden building an agent with Claude on a VPS dieselben Prinzipien mit einem spezifischen Modell.
Für ein praktisches Beispiel wendet building an OpenClaw-style personal agent diese Komponenten an. Wenn Sie eine fertige Lösung suchen, starten Sie mit self-hosting Hermes Agent on a VPS oder running Agent Zero on your own server. the best self-hosted AI agents in 2026 vergleicht alle hier behandelten fertigen Optionen direkt miteinander.
FAQ
Was ist der Unterschied zwischen einem KI-Agenten und einem Chatbot?
Ein Chatbot beantwortet eine Nachricht und stoppt. Ein Agent läuft in einer Schleife: Das Modell entscheidet über eine Aktion, Ihr Code führt sie aus, das Ergebnis geht zurück an das Modell, und der Vorgang wiederholt sich, bis die Aufgabe abgeschlossen ist. Der Unterschied besteht darin, dass ein Agent zwischen seinen Schritten echte Aktionen ausführt (z. B. Dateien lesen, Befehle ausführen oder Dienste abfragen), anstatt nur Text zu generieren.
Benötige ich eine GPU, um einen KI-Agenten auf einem VPS auszuführen?
Nur, wenn Sie das Modell selbst hosten. Die Agenten-Schleife, die Tools und der Speicher sind gewöhnlicher Code, der problemlos auf einem Standard-VPS ohne GPU läuft. Eine GPU ist notwendig, wenn Sie das Sprachmodell auf eigener Hardware ausführen möchten, da das Modell in den Speicher passen muss. Bei der Nutzung eines gehosteten Modells über eine API findet die rechenintensive Arbeit woanders statt; ein einfacher VPS reicht aus.
Was ist MCP und brauche ich es, um einen Agenten zu bauen?
MCP (Model Context Protocol) ist ein offener Standard, um einen Agenten mit Tools und Datenquellen zu verbinden. Sie benötigen es nicht zwingend, da Sie jedes Tool manuell programmieren können. MCP spart jedoch Arbeit, da Sie bestehende Server für gängige Dienste wiederverwenden und Ihre eigenen Systeme einmalig für jeden Agenten bereitstellen können. Es ist eine Komfortfunktion, die bei steigender Anzahl an Integrationen an Bedeutung gewinnt.
Ist es sicher, einem KI-Agenten Zugriff auf meinen Server zu geben?
Es ist sicher, wenn Sie ihn einschränken. Ein Agent, der Befehle ausführt, ist nur so sicher wie das Benutzerkonto, unter dem er läuft, und die Tools, die Sie erlauben. Führen Sie ihn als unprivilegierten Benutzer aus, halten Sie Geheimnisse außer Reichweite, nutzen Sie Sandboxing für Tools mit Dateisystemzugriff und fordern Sie eine Bestätigung für Aktionen an, die nicht leicht rückgängig zu machen sind. Behandeln Sie den Agenten als unvertrauenswürdigen Code, der lediglich intelligent agiert, und geben Sie ihm nur die Berechtigungen, die für die Aufgabe notwendig sind.