Het creëren van een NetAI Speeltuin voor Experimenten met Agentic AI

Hallo allemaal en welkom bij de nieuwste aflevering van “Hank deelt zijn AI-reis.” 🙂 Kunstmatige intelligentie (AI) blijft een hot topic, en terugkomend van Cisco Live in San Diego, was ik enthousiast om me te verdiepen in de wereld van agentic AI.

Met aankondigingen zoals Cisco’s eigen agentic AI-oplossing, AI Canvas, en discussies met partners en andere ingenieurs over deze volgende fase van AI-mogelijkheden, werd mijn nieuwsgierigheid gewekt: Wat betekent dit allemaal voor ons netwerkingenieurs? Bovendien, hoe kunnen we beginnen te experimenteren en te leren over agentic AI?

Ik begon mijn verkenning van het onderwerp agentic AI, door een breed scala aan content te lezen en te bekijken om een dieper begrip van het onderwerp te krijgen. Ik zal in deze blog niet ingaan op een gedetailleerde definitie, maar hier zijn de basisprincipes van hoe ik erover denk:

Agentic AI is een visie op een wereld waarin AI niet alleen vragen beantwoordt die we stellen, maar zelfstandiger begint te werken. Gedreven door de doelen die we stellen, en gebruikmakend van de tools en systemen die we leveren, kan een agentic AI-oplossing de huidige staat van het netwerk bewaken en acties ondernemen om ervoor te zorgen dat ons netwerk precies werkt zoals bedoeld.

Klinkt behoorlijk futuristisch, toch? Laten we ons verdiepen in de technische aspecten van hoe het werkt – stroop je mouwen op, ga naar het lab, en laten we wat nieuwe dingen leren.

Wat zijn AI “tools”?

Het eerste wat ik wilde verkennen en beter begrijpen, was het concept van “tools” binnen dit agentic framework. Zoals je je misschien herinnert, is de LLM (large language model) die AI-systemen aandrijft in feite een algoritme dat is getraind op enorme hoeveelheden data. Een LLM kan je vragen en instructies “begrijpen”. Op zichzelf is de LLM echter beperkt tot de data waarop hij is getraind. Zelfs een webzoekopdracht naar actuele filmtijden kan de LLM niet uitvoeren zonder een “tool” die hem in staat stelt een webzoekopdracht uit te voeren.

Sinds de allereerste dagen van de GenAI-hype, hebben ontwikkelaars “tools” gebouwd en toegevoegd aan AI-toepassingen. Aanvankelijk was de creatie van deze tools ad hoc en varieerde afhankelijk van de ontwikkelaar, LLM, programmeertaal en het doel van de tool. Maar recentelijk heeft een nieuw framework voor het bouwen van AI-tools veel opwinding gekregen en begint het een nieuwe “standaard” te worden voor toolontwikkeling.

Dit framework staat bekend als het Model Context Protocol (MCP). Oorspronkelijk ontwikkeld door Anthropic, het bedrijf achter Claude, kan elke ontwikkelaar MCP gebruiken om tools te bouwen, genaamd “MCP-servers”, en elk AI-platform kan fungeren als een “MCP-client” om deze tools te gebruiken. Het is belangrijk om te onthouden dat we nog steeds in de zeer vroege dagen van AI en AgenticAI zijn; echter, momenteel lijkt MCP de aanpak te zijn voor toolontwikkeling. Dus besloot ik me erin te verdiepen en uit te zoeken hoe MCP werkt door mijn eigen zeer eenvoudige NetAI Agent te bouwen.

Ik ben lang niet de eerste netwerkingenieur die in dit gebied wil duiken, dus ik begon met het lezen van een paar zeer behulpzame blogposts van mijn vriend Kareem Iskander, Head of Technical Advocacy bij Learn with Cisco.

Deze gaven me een goede start over de belangrijkste onderwerpen, en Kareem was vriendelijk genoeg om wat voorbeeldcode te leveren voor het maken van een MCP-server. Ik was klaar om zelf verder te verkennen.

Het creëren van een lokale NetAI speeltuinlab

Vandaag de dag is er geen tekort aan AI-tools en platforms. Er is ChatGPT, Claude, Mistral, Gemini, en nog veel meer. Zeker, ik maak regelmatig gebruik van veel van hen voor verschillende AI-taken. Echter, voor het experimenteren met agentic AI en AI-tools, wilde ik iets dat 100% lokaal was en niet afhankelijk was van een cloud-verbonden service.

Een belangrijke reden voor deze wens was dat ik wilde zorgen dat al mijn AI-interacties volledig op mijn computer en binnen mijn netwerk bleven. Ik wist dat ik zou gaan experimenteren in een volledig nieuw ontwikkelingsgebied. Ik zou ook gegevens over “mijn netwerk” naar de LLM sturen voor verwerking. En hoewel ik non-productie lab systemen zou gebruiken voor alle tests, hield ik toch niet van het idee om cloud-gebaseerde AI-systemen te gebruiken. Ik zou me vrijer voelen om te leren en fouten te maken als ik wist dat het risico laag was. Ja, laag… Niets is volledig zonder risico.

Gelukkig was dit niet de eerste keer dat ik lokaal LLM-werk overwoog, en ik had een paar mogelijke opties klaar om te gaan. De eerste is Ollama, een krachtige open-source engine voor het lokaal uitvoeren van LLM’s, of in ieder geval op je eigen server. De tweede is LMStudio, en hoewel het zelf niet open source is, heeft het een open source basis, en het is gratis te gebruiken voor zowel persoonlijke als “op het werk” experimenten met AI-modellen. Toen ik een recente blog las van LMStudio over MCP-ondersteuning die nu is opgenomen, besloot ik het te proberen voor mijn experimenten.

LMStudio is een client voor het uitvoeren van LLM’s, maar het is zelf geen LLM. Het biedt toegang tot een groot aantal LLM’s die beschikbaar zijn om te downloaden en uit te voeren. Met zoveel LLM-opties beschikbaar, kan het overweldigend zijn wanneer je begint. De belangrijkste dingen voor deze blogpost en demonstratie zijn dat je een model nodig hebt dat is getraind voor “toolgebruik”. Niet alle modellen zijn dat. En bovendien werken niet alle “tool-gebruikende” modellen daadwerkelijk met tools. Voor deze demonstratie gebruik ik het google/gemma-2-9b model. Het is een “open model” gebouwd met hetzelfde onderzoek en de tooling achter Gemini.

Het volgende wat ik nodig had voor mijn experimenten was een eerste idee voor een tool om te bouwen. Na wat nadenken, besloot ik dat een goede “hello world” voor mijn nieuwe NetAI-project een manier zou zijn voor AI om “show commands” van een netwerkapparaat te verzenden en te verwerken. Ik koos pyATS als mijn NetDevOps-bibliotheek voor dit project.

Naast dat het een bibliotheek is waar ik erg bekend mee ben, heeft het als voordeel dat het automatische uitvoer verwerking naar JSON mogelijk maakt via de bibliotheek van parsers die zijn inbegrepen in pyATS. Ik zou ook binnen slechts een paar minuten een eenvoudige Python-functie kunnen genereren om een show-commando naar een netwerkapparaat te sturen en de uitvoer als startpunt terug te krijgen.

Hier is die code:

“`python
def send_show_command(
command: str,
device_name: str,
username: str,
password: str,
ip_address: str,
ssh_port: int = 22,
network_os: Optional[str] = “ios”,
) -> Optional[Dict[str, Any]]:

# Structureer een dictionary voor de apparaatconfiguratie die geladen kan worden door PyATS
device_dict = {
“devices”:
device_name:
“os”: network_os,
“credentials”:
“default”: “username”: username, “password”: password
,
“connections”:
“ssh”: “protocol”: “ssh”, “ip”: ip_address, “port”: ssh_port
,

}
testbed = load(device_dict)
device = testbed.devices[device_name]

device.connect()
output = device.parse(command)
device.disconnect()

return output
“`

Tussen de blogposts van Kareem en de handleiding voor het opstarten van FastMCP 2.0, leerde ik dat het angstaanjagend eenvoudig was om mijn functie om te zetten in een MCP Server/Tool. Ik hoefde slechts vijf regels code toe te voegen.

“`python
from fastmcp import FastMCP

mcp = FastMCP(“NetAI Hello World”)

@mcp.tool()
def send_show_command()
.
.

if __name__ == “__main__”:
mcp.run()
“`

Nou… het was BIJNA zo eenvoudig. Ik moest enkele aanpassingen maken aan de bovenstaande basis om het succesvol te laten werken. Je kunt de volledig werkende versie van de code zien in mijn nieuw gecreëerde NetAI-Learning project op GitHub.

Wat betreft die paar aanpassingen, de veranderingen die ik heb gemaakt waren:

– Een mooie, gedetailleerde docstring voor de functie achter de tool. MCP-clients gebruiken de details uit de docstring om te begrijpen hoe en waarom ze de tool moeten gebruiken.
– Na wat experimenteren, koos ik ervoor om het “http” transport te gebruiken voor de MCP-server in plaats van de standaard en meer gebruikelijke “STDIO.” De reden dat ik deze weg insloeg was om me voor te bereiden op de volgende fase van mijn experimenten, waar mijn pyATS MCP-server waarschijnlijk zou draaien binnen de netwerklabomgeving zelf, in plaats van op mijn laptop. STDIO vereist dat de MCP-client en -server op hetzelfde host-systeem draaien.

Dus startte ik de MCP-server, hopend dat er geen fouten zouden zijn. (Oké, om eerlijk te zijn, kostte het een paar iteraties in de ontwikkeling om het zonder fouten te laten werken… maar ik schrijf deze blogpost “kookshow-stijl,” waarbij het saaie werk onderweg verborgen blijft.) Ik hou van wandelen in het bos en genieten van de rust en de natuur. Hij ging naar de winkel om boodschappen te doen.

BRON