Eigenen AI-Agent auf einem VPS bauen

Was ein AI-Agent tatsächlich ist

Ein AI-Agent ist eine Schleife um ein Sprachmodell. Das Modell liest 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 weiter, bis die Aufgabe erledigt ist. Das ist die gesamte Grundidee. Ein einfacher Chatbot antwortet einmal und beendet sich. Ein Agent arbeitet weiter und führt zwischen seinen eigenen Durchläufen tatsächliche Aktionen aus, bis er ein von Ihnen vorgegebenes Ziel erreicht. Die Schleife ist klein genug, um sie selbst an einem Nachmittag zu schreiben. Damit beginnt ein stufenweiser Lernpfad zum Erstellen von Agents von Grund auf, bevor Sie zusätzlich Tools, Speicher und Sicherheitsmechanismen einbauen.

Die Aktion ist der entscheidende Teil. Ein Sprachmodell erzeugt für sich allein nur Text. Es kann keine Datei lesen, keine API aufrufen und keinen Befehl ausführen. Ein Agent stellt dem Modell eine Gruppe von Tools bereit, die es verwenden darf, sowie eine Möglichkeit, diese anzufordern. Wenn das Modell das Web durchsuchen oder eine Datei schreiben möchte, erledigt es die Arbeit nicht selbst. Es erzeugt eine strukturierte Anfrage, Ihr Code führt das Tool aus, und die Antwort wird als Nächstes vom Modell gelesen. Das Modell liefert die Beurteilung. Ihr Server stellt die ausführenden Möglichkeiten bereit.

Nicht jede Aufgabe benötigt einen Agent. Ihn standardmäßig einzusetzen, ist ein häufiger Fehler. Wenn die Schritte im Voraus bekannt sind, ist ein einfaches Script unkomplizierter, schneller und zuverlässiger. „Diese Seite jede Stunde abrufen und mir den Preis per E-Mail senden“ ist ein geplanter Job und kein Agent. Erstellen Sie einen Agent, wenn der Ablauf nicht im Voraus feststeht und das Modell die gefundenen Informationen prüfen und entscheiden muss, was als Nächstes zu tun ist. Der Nachteil eines Agents ist seine Unvorhersehbarkeit. Setzen Sie ihn daher nur ein, wenn die zusätzliche Flexibilität diesen Nachteil rechtfertigt.

Werkzeuge: So arbeitet ein Agent

Ein Werkzeug ist jede Fähigkeit, die Sie dem Modell zur Verfügung stellen und so beschreiben, dass es erkennt, wann es darauf zugreifen soll. Eine Datei lesen, einen Shell-Befehl ausführen, eine Datenbank abfragen oder eine Nachricht senden: Jede dieser Funktionen ist ein Werkzeug mit einem Namen, einer kurzen Beschreibung und einer Liste von Eingaben. Sie definieren die Werkzeuge; das Modell entscheidet, wann es sie aufruft. Die Websuche ist normalerweise das erste Werkzeug, das sich lohnt. Wenn Sie bereits eine eigene SearXNG-Instanz betreiben, können Sie sie in das Such-Backend des Agents umwandeln, statt für eine kommerzielle Search-API zu bezahlen.

Der Mechanismus ist überall gleich, unabhängig vom verwendeten Modell. Das Modell gibt eine strukturierte Anfrage zurück, die ein Werkzeug benennt und seine Eingaben ausfüllt. Ihr Code erkennt diese Anfrage, führt die zugehörige Funktion aus und sendet das Ergebnis im nächsten Turn zurück. Das Modell liest das Ergebnis und ruft entweder ein weiteres Werkzeug auf oder schreibt seine endgültige Antwort. Function Calling ist die technische Grundlage jedes Agents. Die Schleife, die diesen Ablauf steuert, umfasst nur wenige Zeilen gewöhnlichen Codes.

Hier liegt auch Ihre Kontrolle. Das Modell kann die Ausführung eines Befehls anfordern. Ausgeführt wird jedoch erst dann etwas, wenn Ihr Code dies veranlasst. An dieser Stelle integrieren Sie Bestätigungsabfragen für gefährliche Aktionen, Einschränkungen für den Zugriff eines Werkzeugs und ein Protokoll aller Aktionen des Agents. Ein Agent ist nur so sicher wie die Werkzeuge, die Sie ihm geben, und die Prüfungen, die Sie davor schalten.

MCP: eine standardisierte Möglichkeit, Tools zu verbinden

Eine eigene Integration für jeden Dienst manuell zu schreiben, wird schnell mühsam. Das Model Context Protocol, kurz MCP, ist ein offener Standard, der dieses Problem löst. Statt für Ihre Dateien, Ihre Datenbank und Ihren Issue-Tracker jeweils ein neues Tool zu programmieren, verbinden Sie den Agenten mit einem MCP-Server, der diese Systeme bereits als Tools bereitstellt. Der Agent verwendet ein einheitliches Protokoll. Der Server übernimmt die Kommunikation mit dem tatsächlichen System.

Der Vorteil ist die Wiederverwendbarkeit. Ein MCP-Server, den jemand für einen von Ihnen verwendeten Dienst geschrieben hat, steht Ihrem Agenten ohne zusätzlichen Integrationscode zur Verfügung. Einen von Ihnen geschriebenen Server kann jeder Agent verwenden, der das Protokoll unterstützt. Einige Self-Hosted-Anwendungen liefern inzwischen eigene MCP-Server mit: openGym, ein Trainings-Tracker stellt einen schreibgeschützten MCP-Server bereit. Dadurch kann ein Agent Fragen zu Ihrer Trainingshistorie beantworten, ohne sie ändern zu können. Auf einem VPS ist das relevant, weil Sie MCP-Server als eigene kleine Dienste neben dem Agenten ausführen können. Jeder Server erhält nur die Zugriffsrechte, die er benötigt. Wenn sich die Systeme hinter diesen Servern in einem Netzwerk befinden, das der VPS nicht erreichen kann, etwa eine Datenbank zu Hause oder im Büro, können Sie dieses Netzwerk mit einem Subnet-Router in Ihr Tailnet bekanntmachen. Der Agent erreicht die Systeme dann über private Adressen, ohne etwas im öffentlichen Internet bereitzustellen. Die Einrichtung beschreibe ich unter MCP-Server auf einem VPS ausführen.

Speicher und Abruf

Ein Sprachmodell verfügt zwischen Aufrufen über kein eigenes Gedächtnis. Alles, was es über die aktuelle Aufgabe wissen muss, muss ihm in jedem Durchlauf übergeben werden. Für kurze Aufgaben ist das unproblematisch, weil die gesamte Unterhaltung in eine Anfrage passt. Wie viel hineinpasst, hängt vom Kontextfenster ab. Ein von Ollama bereitgestelltes Self-Hosted-Modell verwendet standardmäßig ein kleines Kontextfenster und verwirft unbemerkt die ältesten Durchläufe. Daher lohnt es sich, num_ctx an den von Ihrer Schleife erzeugten Datenverkehr anzupassen, bevor Sie dem Agenten Vergesslichkeit vorwerfen. Für längere Aufgaben müssen Sie den Speicher selbst verwalten. Dafür sind zwei Muster wichtig.

Das erste Muster ist ein Notizblock. Sie stellen dem Agenten eine Datei bereit, die er lesen und beschreiben kann, und weisen ihn an, seine Erkenntnisse darin fortlaufend festzuhalten. Beim nächsten Durchlauf oder in der nächsten Sitzung liest er die Datei erneut ein und setzt seine Arbeit fort. Dabei wird der Speicher als einfaches Dokument umgesetzt. Das funktioniert, weil der Agent die Datei wie ein weiteres Tool behandelt.

Das zweite Muster ist der Abruf. Wenn der Agent Wissen aus einer großen Dokumentensammlung benötigt, die niemals in eine einzelne Anfrage passen würde, speichern Sie diese Dokumente in einer durchsuchbaren Form. Bei Bedarf übernehmen Sie dann nur die relevanten Teile in den Kontext des Modells. Dieses Muster heißt Retrieval-Augmented Generation oder RAG. Der Agent stellt eine Frage. Ihr Code findet die wenigen passenden Textstellen. Nur diese werden an das Modell übergeben. Der Speicher liegt auf Ihrem Server. Ihre privaten Dokumente verlassen ihn daher nicht.

Viele Agents, ein Koordinator

Ein Agent mit vielen Tools reicht für die meisten Aufgaben aus. Wenn ein Auftrag umfangreich ist oder sich von selbst in mehrere Teile gliedert, ist eine andere Struktur sinnvoll: ein Koordinator-Agent, der spezialisierte Sub-Agents beauftragt. Der Koordinator teilt das Ziel in einzelne Aufgaben auf, übergibt jede davon an einen für diese Art von Arbeit geeigneten Sub-Agent und führt die Ergebnisse zusammen. Für die Delegation ist ein Kanal zwischen den einzelnen Teilen erforderlich. Die einfachste Variante läuft bereits auf Ihrem Server: zwei Claude-Code-Sitzungen auf demselben VPS können sich gegenseitig Nachrichten senden. Damit können Sie kostengünstig testen, wie Übergaben funktionieren, bevor Sie eine eigene Koordinationslogik entwickeln.

Der Vorteil liegt in der Fokussierung. Ein Sub-Agent mit einer klar begrenzten Aufgabe und einer kleinen Tool-Auswahl trifft bessere Entscheidungen als ein Generalist, der alles gleichzeitig bearbeiten muss. Unabhängige Teilaufgaben können zudem parallel ausgeführt werden. Die Koordination verursacht jedoch zusätzlichen Aufwand. Verwenden Sie daher zunächst nur einen Agent, bis eine Aufgabe eindeutig mehrere Agents erfordert. Beginnen Sie mit einer einfachen Struktur und fügen Sie Agents erst hinzu, wenn ein einzelner Agent die Aufgabe erkennbar nicht mehr bewältigt.

Self-hosted oder gehostet: Welches Modell führt Ihren Agenten aus

Das Modell ist der einzige Teil eines Agenten, den Sie nicht selbst betreiben müssen. Die Entscheidung über seinen Standort ist die wichtigste Entscheidung, die Sie treffen werden. Ein gehostetes Modell, das über eine API angesprochen wird, bietet die stärkste Reasoning-Leistung, ohne dass Sie etwas betreiben müssen: Sie senden Text und erhalten Text zurück. Ein Self-hosted-Modell läuft auf Ihrem eigenen Server. Dadurch bleiben alle Anfragen privat, Sie zahlen einen festen Preis statt einer Gebühr pro Token, und Sie sind nicht davon abhängig, dass ein anderer Dienst verfügbar bleibt. Der Nachteil betrifft die Leistungsfähigkeit und den Betriebsaufwand. Die besten gehosteten Modelle sind leistungsfähiger als die Modelle, die Sie selbst betreiben können. Beim Eigenbetrieb müssen Sie außerdem ausreichend Speicher bereitstellen, damit das Modell geladen werden kann.

Dieser letzte Punkt ist in der Praxis entscheidend. Das Modell muss in den Arbeitsspeicher Ihres Servers passen. Wenn Sie eine GPU verwenden, muss es außerdem in deren Videospeicher passen. Ein Modell, das für die Hardware zu groß ist, kann nicht geladen werden. Bevor Sie einen Self-hosted-Agenten planen, prüfen Sie, ob das gewünschte Modell auf die vorhandene Maschine passt:

Wenn die Werte nicht ausreichen, haben Sie drei Möglichkeiten: Wählen Sie ein kleineres Modell, verwenden Sie eine aggressivere Quantisierung, um es zu verkleinern, oder nutzen Sie eine gehostete API für das Reasoning und behalten Sie nur Ihre Tools und Daten auf dem Server. Viele Self-hosted-Agenten beginnen mit einem lokalen Modell über Ollama auf einem VPS und wechseln für die anspruchsvollsten Schritte zu einer gehosteten API.

Der Server ist der gefährliche Teil

Ein Agent, der Shell-Befehle ausführen und Dateien schreiben kann, ist leistungsfähig. Genau deshalb ist er gefährlich. Das Urteilsvermögen des Modells ist gut, aber nicht perfekt. Eine fehlerhafte Anweisung, ein Bug oder eine manipulierte Eingabe kann einen hilfreichen Agenten dazu bringen, die falsche Datei zu löschen oder ein Geheimnis offenzulegen. Die Sicherheitsmaßnahmen sind nicht optional. Auf einem Server sind sie der wichtigste Teil.

Einige Vorgehensweisen decken den größten Teil der Anforderungen ab. Führen Sie den Agenten als dedizierten Benutzer ohne privilegierte Rechte aus, niemals als root. So bleiben die Auswirkungen eines Fehlers begrenzt. Dieselbe Überlegung gilt für das Ausführen von Diensten als Benutzer ohne privilegierte Rechte. Speichern Sie seine Geheimnisse, beispielsweise API keys, nicht im Code. Sie dürfen nur für diesen Benutzer lesbar sein. Isolieren Sie außerdem die Tools, die auf das System zugreifen. So kann der Agent nur die Ressourcen erreichen, die er tatsächlich benötigt. Wenn Sie nicht jede Prüfung selbst schreiben möchten, decken die zu installierenden DeepSeek Harness plugins dieselben Anforderungen mit fertigen Komponenten ab: Regeln für Tool-Berechtigungen, Scans auf Prompt Injection und eine Begrenzung der Ausgaben des Agenten, bevor er angehalten wird. Ein konkretes Beispiel für die Absicherung eines realen selbst gehosteten Agenten finden Sie unter OpenClaw sicher auf einem VPS ausführen. Wenn Sie die Intelligenz lieber von einem gehosteten Modell bereitstellen lassen möchten, überträgt der begleitende Leitfaden zum Erstellen eines Agenten mit Claude auf einem VPS dieselben Prinzipien auf ein bestimmtes Modell.

Ein konkretes Beispiel ist einen persönlichen Agenten im Stil von OpenClaw erstellen, bei dem diese Komponenten eingesetzt werden. Wenn Sie lieber einen fertigen Agenten ausführen möchten, beginnen Sie mit Hermes Agent auf einem VPS selbst hosten oder Agent Zero auf Ihrem eigenen Server ausführen. Die besten selbst gehosteten AI agents im Jahr 2026 vergleicht alle behandelten fertigen Optionen direkt miteinander.

FAQ

Was ist der Unterschied zwischen einem KI-Agenten und einem Chatbot?

Ein Chatbot beantwortet eine Nachricht und beendet sich. Ein Agent durchläuft eine Schleife: Das Modell entscheidet über eine Aktion, Ihr Code führt sie aus, das Ergebnis wird an das Modell zurückgegeben, und der Vorgang wiederholt sich, bis die Aufgabe abgeschlossen ist. Der Unterschied besteht darin, dass ein Agent zwischen seinen Antworten tatsächlich Aktionen ausführt. Dazu ruft er Tools auf, um Dateien zu lesen, Befehle auszuführen oder Dienste abzufragen, anstatt nur Text zu erzeugen.

Benötige ich eine GPU, um einen KI-Agenten auf einem VPS auszuführen?

Nur wenn Sie das Modell selbst hosten. Die Agentenschleife, die Tools und der Speicher sind gewöhnlicher Code, der auf einem normalen VPS ohne GPU problemlos läuft. Eine GPU ist relevant, wenn Sie das Sprachmodell auf eigener Hardware ausführen möchten, weil das Modell in den Speicher passen muss. Wenn Sie ein gehostetes Modell über eine API verwenden, findet die aufwendige Berechnung an anderer Stelle statt. Ein einfacher VPS ist dann ausreichend.

Was ist MCP, und benötige ich es zum Erstellen eines Agenten?

MCP, das Model Context Protocol, ist ein offener Standard, um einen Agenten mit Tools und Datenquellen zu verbinden. Sie benötigen MCP nicht zwingend, da Sie jedes Tool selbst schreiben können. MCP erspart Ihnen diese Arbeit. Sie können vorhandene Server für gängige Dienste wiederverwenden und Ihre eigenen Systeme einmalig für jeden Agenten verfügbar machen. Mit zunehmender Zahl der Integrationen wird diese Vereinfachung immer nützlicher.

Ist es sicher, einem KI-Agenten Zugriff auf meinen Server zu geben?

Das kann sicher sein, wenn Sie den Agenten ausreichend einschränken. Ein Agent, der Befehle ausführt, ist nur so sicher wie das Konto, unter dem er läuft, und die Tools, die Sie zulassen. Führen Sie ihn als unprivilegierter Benutzer aus, halten Sie seine Secrets außerhalb seines Zugriffs, kapseln Sie Tools mit Dateisystemzugriff in einer Sandbox und verlangen Sie eine Freigabe für schwer rückgängig zu machende Aktionen. Behandeln Sie den Agenten wie nicht vertrauenswürdigen Code, der zufällig intelligent ist, und geben Sie ihm nur die für die Aufgabe erforderlichen Berechtigungen.