Zelf een AI-agent bouwen op een VPS: handleiding

Wat een AI-agent daadwerkelijk is

Een AI-agent is een lus die om een taalmodel heen is gebouwd. Het model leest de situatie, beslist over één actie, uw code voert die actie uit, het resultaat gaat terug naar het model en de lus draait opnieuw totdat de taak is voltooid. Dat is het hele concept. Een standaard chatbot antwoordt één keer en stopt. Een agent gaat door, voert echte acties uit tussen zijn eigen beurten door, totdat hij een doel bereikt dat u hem hebt gegeven. De lus is klein genoeg om in een middag zelf te schrijven, wat het startpunt is van een stapsgewijs pad om agents vanaf nul te leren, voordat er tools, geheugen en beveiliging aan worden toegevoegd.

De actie is het belangrijkste onderdeel. Op zichzelf produceert een taalmodel alleen tekst. Het kan geen bestand lezen, een API aanroepen of een commando uitvoeren. Een agent geeft het model een set tools die het mag gebruiken en een manier om erom te vragen. Wanneer het model het web wil doorzoeken of een bestand wil schrijven, doet het het werk niet zelf. Het verstuurt een gestructureerd verzoek, uw code voert de tool uit en het antwoord komt terug als het volgende dat het model leest. Het model levert het oordeel; uw server levert de handen.

Niet elke taak heeft een agent nodig, en het is een veelgemaakte fout om er standaard naar te grijpen. Als de stappen vooraf bekend zijn, is een simpel script eenvoudiger, sneller en betrouwbaarder. "Haal elk uur deze pagina op en e-mail mij de prijs" is een geplande taak, geen agent. Bouw een agent wanneer het pad niet vooraf vastligt, wanneer het model moet kijken naar wat het vindt en moet beslissen wat de volgende stap is. De prijs van een agent is onvoorspelbaarheid, dus betaal die alleen wanneer de flexibiliteit de moeite waard is.

Tools: hoe een agent handelt

Een tool is elke functionaliteit die u aan het model toevoegt, mits deze voldoende is beschreven zodat het model weet wanneer het deze moet gebruiken. Een bestand lezen, een shell-commando uitvoeren, een database bevragen, een bericht versturen: elk onderdeel is een tool met een naam, een korte beschrijving en een lijst met invoerparameters. U definieert de tools; het model bepaalt wanneer het deze aanroept. Zoeken op het web is meestal de eerste tool die de moeite waard is om toe te voegen. Als u al uw eigen SearXNG-instantie beheert, kunt u deze als zoek-backend voor de agent gebruiken in plaats van te betalen voor een commerciële zoek-API.

Het mechanisme is overal hetzelfde, ongeacht welk model u gebruikt. Het model retourneert een gestructureerd verzoek waarin een tool wordt benoemd en de invoer wordt ingevuld. Uw code ziet dat verzoek, voert de bijbehorende functie uit en stuurt het resultaat terug in de volgende beurt. Het model leest het resultaat en roept ofwel een andere tool aan, of schrijft het definitieve antwoord. Function calling vormt de basis van elke agent, en de lus die dit aanstuurt bestaat uit slechts enkele regels standaardcode.

Dit is ook waar uw controle ligt. Het model kan vragen om een commando uit te voeren, maar er gebeurt niets totdat uw code besluit het uit te voeren. In die tussenruimte kunt u goedkeuringsvragen plaatsen voor risicovolle acties, limieten instellen voor wat een tool mag aanpassen en een logboek bijhouden van alles wat de agent heeft gedaan. Een agent is slechts zo veilig als de tools die u verstrekt en de controles die u daarvoor plaatst.

MCP: een standaardmanier om tools te verbinden

Het handmatig schrijven van een nieuwe integratie voor elke service is inefficiënt. Het Model Context Protocol, of MCP, is een open standaard die dit probleem oplost. In plaats van een nieuwe tool te programmeren voor uw bestanden, database en issue tracker, koppelt u de agent aan een MCP-server die deze zaken al als tools aanbiedt. De agent spreekt één protocol; de server voert het werk uit om met het daadwerkelijke systeem te communiceren.

Het voordeel is hergebruik. Een MCP-server die door iemand anders is geschreven voor een service die u gebruikt, wordt direct beschikbaar voor uw agent zonder nieuwe integratiecode. Een server die u zelf schrijft, is bruikbaar door elke agent die het protocol ondersteunt. Sommige zelfgehoste applicaties leveren er inmiddels zelf een mee: openGym, een workout-tracker biedt een read-only MCP-server aan, zodat een agent vragen over uw trainingsgeschiedenis kan beantwoorden zonder deze te kunnen wijzigen. Op een VPS is dit relevant, omdat u MCP-servers als afzonderlijke kleine services naast de agent kunt draaien, elk met alleen de benodigde toegangsrechten. Wanneer de systemen achter die servers zich op een netwerk bevinden dat de VPS niet kan zien, zoals een database thuis of op kantoor, zorgt het adverteren van dat netwerk naar uw tailnet met een subnet router ervoor dat de agent ze via privéadressen kan bereiken zonder iets bloot te stellen aan het openbare internet. Ik behandel de configuratie in het draaien van MCP-servers op een VPS.

Geheugen en ophalen van gegevens

Een taalmodel heeft geen eigen geheugen tussen aanroepen door. Alles wat het model over de huidige taak moet weten, moet bij elke beurt opnieuw worden aangeleverd. Voor een korte taak is dit geen probleem, omdat het volledige gesprek in één verzoek past. Hoeveel er precies in past, hangt af van het contextvenster. Een zelfgehost model dat via Ollama wordt aangeboden, krijgt standaard een klein venster dat stilletjes de oudste gespreksrondes verwijdert. Daarom is het verstandig om num_ctx in te stellen op basis van het verkeer dat uw loop genereert voordat u de agent ervan beschuldigt dingen te vergeten. Voor langere taken moet u het geheugen zelf beheren; hiervoor zijn twee patronen nuttig om te kennen.

Het eerste patroon is een kladblok. U geeft de agent een bestand waarnaar hij kan lezen en schrijven, en instrueert hem om opgedane kennis gaandeweg vast te leggen. Bij de volgende beurt, of de volgende sessie, leest de agent het bestand opnieuw in en gaat verder waar hij gebleven was. Dit is geheugen in de vorm van een eenvoudig document, en het werkt omdat de agent het bestand simpelweg als een ander hulpmiddel beschouwt.

Het tweede patroon is het ophalen van gegevens (retrieval). Wanneer de agent kennis nodig heeft uit een grote verzameling documenten die nooit in één verzoek zou passen, slaat u deze documenten op in een doorzoekbare vorm. U haalt alleen de relevante fragmenten naar het blikveld van het model wanneer deze nodig zijn. Dit patroon wordt retrieval-augmented generation, of RAG, genoemd. De agent stelt een vraag, uw code zoekt de bijbehorende passages op, en alleen die fragmenten worden naar het model gestuurd. De opslag bevindt zich op uw eigen server, waardoor uw privédocumenten deze nooit verlaten.

Veel agents, één coördinator

Eén agent met veel tools volstaat voor de meeste taken. Wanneer een taak omvangrijk is of zich op natuurlijke wijze laat opsplitsen, is een andere opzet effectiever: een coördinator-agent die taken delegeert aan gespecialiseerde sub-agents. De coördinator breekt het doel op in stukken, wijst elk onderdeel toe aan een sub-agent die is ingericht voor dat specifieke werk, en voegt de resultaten samen. Delegatie vereist een kanaal tussen de onderdelen, en de meest eenvoudige versie daarvan is al aanwezig op uw server: twee Claude Code-sessies op dezelfde VPS kunnen berichten naar elkaar sturen. Dit is een laagdrempelige manier om te ervaren hoe overdrachten verlopen voordat u zelf coördinatiemechanismen bouwt.

Het voordeel is focus. Een sub-agent met een beperkte taak en een kleine set tools neemt betere beslissingen dan een generalist die alles tegelijk moet afhandelen, en onafhankelijke onderdelen kunnen gelijktijdig worden uitgevoerd. De kosten zitten in de coördinatie, wat een reële factor is; houd het daarom bij één agent totdat een taak duidelijk om meer vraagt. Begin eenvoudig en voeg pas agents toe wanneer één agent zichtbaar tekortschiet.

Zelf gehost of extern gehost: welk model voert uw agent uit

Het model is het enige onderdeel van een agent dat u niet zelf hoeft te draaien, en de keuze waar dit model draait, is de belangrijkste beslissing die u zult nemen. Een gehost model, dat via een API wordt benaderd, biedt u de krachtigste redeneervermogens zonder dat u zelf beheer hoeft uit te voeren: u verstuurt tekst en ontvangt tekst terug. Een zelf gehost model draait op uw eigen server, waardoor elk verzoek privé blijft, u een vast bedrag betaalt in plaats van kosten per token, en u nooit afhankelijk bent van de uptime van derden. De keerzijde is de capaciteit en de benodigde inspanning. De beste gehoste modellen zijn geavanceerder dan wat u zelf kunt draaien, en het draaien van een eigen model vereist voldoende geheugen om het model te laden.

Dat laatste punt is het praktische knelpunt. Een model moet in het geheugen van uw server passen, en als u een GPU gebruikt, in het videogeheugen. Een model dat te groot is voor de hardware zal niet laden. Voordat u een zelf gehoste agent plant, moet u controleren of het gewenste model op uw machine past:

Als de cijfers niet overeenkomen, heeft u drie opties: kies een kleiner model, gebruik een agressievere kwantisatie om het model te verkleinen, of gebruik een gehoste API voor het redeneerwerk en bewaar alleen uw tools en data op de server. Veel zelf gehoste agents beginnen met een lokaal model via Ollama op een VPS en schakelen terug naar een gehoste API voor de meest complexe stappen.

De server is het gevaarlijke onderdeel

Een agent die shell-commando's kan uitvoeren en bestanden kan schrijven is krachtig, en dat is precies waarom het gevaarlijk is. Het oordeelsvermogen van het model is goed maar niet perfect, en een verkeerde instructie, een bug of een kwaadwillende invoer kan een behulpzame agent veranderen in een agent die de verkeerde dingen verwijdert of geheimen lekt. Beveiliging is geen optionele taak, en op een server is dit het meest cruciale onderdeel.

Enkele gewoontes wegen het zwaarst. Laat de agent draaien als een toegewezen gebruiker zonder privileges, nooit als root, zodat een fout een beperkte impact heeft; dezelfde redenering geldt voor het draaien van services als een gebruiker zonder privileges. Houd geheimen, zoals API keys, buiten de code en zorg dat deze alleen leesbaar zijn voor die specifieke gebruiker. Sandbox de tools die het systeem aanraken, zodat de agent alleen toegang heeft tot wat strikt noodzakelijk is. Als u niet elke controle handmatig wilt schrijven, dekken de DeepSeek Harness plugins die het installeren waard zijn hetzelfde terrein met kant-en-klare onderdelen: regels voor tool-permissies, scans op prompt injection en een limiet op wat de agent kan verbruiken voordat deze stopt. Voor een uitgewerkt voorbeeld van het beveiligen van een echte zelfgehoste agent, zie veilig OpenClaw draaien op een VPS. Als u liever een gehost model gebruikt voor de intelligentie, past de bijbehorende gids over het bouwen van een agent met Claude op een VPS dezelfde ideeën toe met een specifiek model als basis.

Voor een uitgewerkt voorbeeld past het bouwen van een persoonlijke agent in OpenClaw-stijl deze onderdelen toe. Als u liever een kant-en-klare agent gebruikt, begin dan bij Hermes Agent zelf hosten op een VPS of Agent Zero draaien op uw eigen server, en de beste zelfgehoste AI-agents in 2026 vergelijkt elke kant-en-klare optie die we behandelen, zij aan zij.

FAQ

Wat is het verschil tussen een AI-agent en een chatbot?

Een chatbot beantwoordt een bericht en stopt daarna. Een agent doorloopt een lus: het model bepaalt een actie, uw code voert deze uit, het resultaat gaat terug naar het model, en dit proces herhaalt zich totdat de taak is voltooid. Het verschil is dat een agent tussen de beurten door daadwerkelijke acties onderneemt door tools aan te roepen om bestanden te lezen, commando's uit te voeren of services te bevragen, in plaats van alleen tekst te genereren.

Heb ik een GPU nodig om een AI-agent op een VPS te draaien?

Alleen als u het model zelf host. De agent-lus, de tools en het geheugen zijn gewone code die prima draait op een standaard VPS zonder GPU. Een GPU is van belang wanneer u het taalmodel op uw eigen hardware wilt draaien, omdat het model in het geheugen moet passen. Als u een gehost model via een API gebruikt, vindt de zware berekening elders plaats en volstaat een bescheiden VPS.

Wat is MCP en heb ik dit nodig om een agent te bouwen?

MCP, het Model Context Protocol, is een open standaard voor het verbinden van een agent met tools en databronnen. U heeft dit niet strikt nodig, aangezien u elke tool handmatig kunt schrijven. MCP bespaart u dat werk door bestaande servers voor veelvoorkomende services te hergebruiken en uw eigen systemen eenmalig beschikbaar te stellen voor elke agent. Het is een gemak dat de moeite waard wordt naarmate het aantal integraties toeneemt.

Is het veilig om een AI-agent toegang te geven tot mijn server?

Dit kan veilig zijn, mits u de agent isoleert. Een agent die commando's uitvoert, is slechts zo veilig als het account waaronder deze draait en de tools die u toestaat. Draai de agent als een gebruiker zonder bevoorrechte rechten, houd de geheimen buiten bereik, sandbox de tools die het bestandssysteem benaderen en vereis goedkeuring voor acties die moeilijk ongedaan te maken zijn. Behandel de agent als niet-vertrouwde code die toevallig slim is, en geef deze alleen toegang tot wat strikt noodzakelijk is voor de taak.