Adaptives agentenbasiertes Intelligenz-Framework mit Strands Agents

Organisationen, die KI-Agenten entwickeln, sehen sich einer häufigen Herausforderung gegenüber: Jede Anfrage – sei es eine routinemäßige Statusabfrage oder eine komplexe Analyse – wird typischerweise an ein einzelnes großes, teures Modell weitergeleitet. Dieser Einheitsansatz kann die API-Kosten in die Höhe treiben, unvorhersehbare Latenz verursachen und den Offline-Betrieb unmöglich machen. Selbst routinemäßige Abfragen, die lokal gelöst werden könnten, erfordern am Ende einen vollständigen Netzwerk-Roundtrip zu einem in der Cloud gehosteten großen Sprachmodell (LLM).

Das Adaptive Agentic Intelligence Framework (AAIF), das mit Strands Agents entwickelt wurde, verfolgt einen anderen Ansatz. Statt alle Anfragen an ein einzelnes großes Modell zu leiten, verwendet AAIF kleine Sprachmodelle (SLMs), um Routineaufgaben lokal zu bearbeiten. Komplexere Anfragen werden über Amazon Bedrockan in der Cloud gehostete Modelle weitergeleitet. Dieser Ansatz baut auf der Forschungsposition von Belcak et al. bei NVIDIAauf. Sie argumentieren, dass kleine Sprachmodelle „für viele Aufrufe in agentenbasierten Systemen ausreichend leistungsfähig, von Natur aus besser geeignet und zwingend wirtschaftlicher sind“. Das auf Strands Agents basierende Framework zeigt, wie intelligente Modell-Orchestrierung dazu beitragen kann, Kosten zu senken und gleichzeitig niedrige Latenz für lokale Vorgänge zu bewahren.

In diesem Beitrag führen wir durch die Hauptkomponenten von AAIF mit Strands Agents, lokalen SLMs über Ollama und Cloud-Modellen über Amazon Bedrock. Wir verwenden ein Internet-of-Things-(IoT-)Überwachungsszenario als Referenzimplementierung.

Lösungsübersicht

AAIF gliedert die KI-Verarbeitung in drei Ebenen, die jeweils für unterschiedliche Aufgabentypen optimiert sind, wie Abbildung 1 zeigt:

1. Die intelligente Orchestrierung verwendet ein leichtgewichtiges SLM (llama3.2:1b) als Entscheidungsebene. Dieser Orchestrator klassifiziert eingehende Anfragen und leitet sie ohne hartcodierte Regeln an die entsprechende Verarbeitungsebene weiter.
2. Die lokale Verarbeitung übernimmt Routineaufgaben wie den Abruf von Gerätetelemetriedaten und die Bildanalyse mithilfe von SLMs, die über Ollamaauf lokaler Hardware ausgeführt werden. Diese Aufgaben werden mit niedriger Latenz und ohne Cloud-Abhängigkeit abgeschlossen.
3. Die Cloud-Verarbeitung übernimmt komplexe Musteranalysen und strategische Empfehlungen durch Frontier-Modelle in Amazon Bedrock. Diese Anfragen benötigen einen breiteren Kontext und mehrstufiges Denken, das SLMs nicht zuverlässig bereitstellen können.

Abbildung 1: Die drei AAIF-Verarbeitungsebenen für intelligente Orchestrierung, lokale Verarbeitung und Cloud-Verarbeitung

Abbildung 1 zeigt die vollständige AAIF-Systemarchitektur. Im Zentrum sitzt der Strands-Agent, der eine Verbindung zu einer Ollama-Laufzeitumgebung herstellt, die sowohl das Orchestrator-Modell mit 1B Parametern als auch das Vision-Modell hostet. Der Agent stellt drei Tools bereit: get_device_telemetry für den lokalen Abruf von Sensordaten, analyze_camera_feed für die Vision-Verarbeitung auf dem Gerät über llama3.2-vision und get_expert_insights, das über boto3 Amazon Bedrock für komplexe Analysen aufruft. Eingehende Benutzeranfragen durchlaufen den SLM-Orchestrator, der jede Anfrage klassifiziert und sie je nach Aufgabenkomplexität entweder an ein lokales Tool oder an den Cloud-Endpunkt weiterleitet.

Abbildung 2: Vollständige AAIF-Systemarchitektur mit dem Strands-Agent, der Ollama-Laufzeitumgebung, Tool-Integrationen und der Amazon-Bedrock-Konnektivität

Das Framework passt sich Ihren Bereitstellungsbeschränkungen an, statt dass Sie Ihre Infrastruktur um es herum umbauen müssen. Diese Architektur läuft auf Edge-Geräten wie einem Raspberry Pi mit 8 GB Arbeitsspeicher, in vollständigen Cloud-Bereitstellungen, bei denen die gesamte Inferenz an Amazon Bedrock geht, oder in hybriden Konfigurationen, die lokale Geschwindigkeit mit Cloud-Denkleistung kombinieren. Die Flexibilität ergibt sich aus der Trennung der Routing-Logik (dem SLM-Orchestrator) von den Verarbeitungstools, die Sie je nach verfügbarer Hardware und Netzwerkverbindung unabhängig austauschen oder neu konfigurieren können.

Voraussetzungen

Für diese Anleitung sollten Sie die folgenden Voraussetzungen erfüllen:

• Ein AWS-Konto.
• Amazon Bedrock Modellzugriff, der in der erforderlichen Region konfiguriert ist.
• Python 3.10+ installiert.
• Ollama installiert, mit den folgenden heruntergeladenen Modellen:
  • ollama pull llama3.2:1b (Orchestrator).
  • ollama pull llama3.2-vision (Vision-Analyse).
• Strands Agents installiert: pip install strands-agents strands-agents-tools.
• AWS Command Line Interface (AWS CLI) mit geeigneten Anmeldeinformationen konfiguriert.
• Boto3 installiert: pip install boto3.

Umgebung einrichten

Erstellen Sie ein Projektverzeichnis und starten Sie den Ollama-Server:

mkdir aaif-demo && cd aaif-demo
ollama serve

Laden Sie die erforderlichen Modelle herunter:

ollama pull llama3.2:1b
ollama pull llama3.2-vision

Erstellen Sie eine Datei mit dem Namen aaif_agent.py und fügen Sie die folgenden Komponenten hinzu.

Tools für die lokale Verarbeitung implementieren

Strands Agents verwendet den @tool Decorator, um Fähigkeiten zu definieren, die Agents aufrufen können. Beginnen Sie mit der Erstellung von Tools für die lokale Verarbeitung.

Das erste Tool ruft Gerätetelemetriedaten ab. In einer Produktionsumgebung würde es sich mit echten IoT-Sensoren verbinden. Für diese Anleitung verwendet es simulierte Gerätedaten:

from strands import Agent, tool
import random

DEVICE_TELEMETRY = {
    "sensor-001": {
        "device_type": "Temperature Sensor",
        "location": "Building A - Floor 2",
        "temperature": 72.5,
        "humidity": 45.2,
        "status": "normal"
    },
    "camera-001": {
        "device_type": "Security Camera",
        "location": "Main Entrance",
        "fps": 30,
        "resolution": "1080p",
        "status": "recording"
    },
    "hvac-001": {
        "device_type": "HVAC Controller",
        "location": "Building A - Central",
        "set_temp": 71.0,
        "current_temp": 72.5,
        "mode": "cooling",
        "status": "active"
    }
}

@tool
def get_device_telemetry() -> str:
    """Retrieve current telemetry data from connected IoT devices."""
    device_id = random.choice(list(DEVICE_TELEMETRY.keys()))
    device_data = DEVICE_TELEMETRY[device_id]

    report = f"Device: {device_id} ({device_data['device_type']})\n"
    report += f"Location: {device_data['location']}\n"
    report += f"Status: {device_data['status']}\n"
    for key, value in device_data.items():
        if key not in ['device_type', 'location', 'status']:
            report += f"{key}: {value}\n"
    return report

Das zweite Tool führt eine Bildanalyse mit einem lokalen SLM durch. Das Modell llama3.2-vision läuft vollständig auf lokaler Hardware, was bedeutet, dass sensible Kamerabilder das Gerät nicht verlassen:

import ollama

@tool
def analyze_camera_feed(image_path: str) -> str:
    """Analyze visual data from cameras using local vision model."""
    stream = ollama.chat(
        model='llama3.2-vision',
        messages=[{
            'role': 'user',
            'content': 'Describe this image in one sentence. '
            'What are the 3 most important things you see?',
            'images': [image_path]
        }],
        stream=True,
    )

    full_response = ""
    for chunk in stream:
        chunk_content = chunk['message']['content']
        print(chunk_content, end='', flush=True)
        full_response += chunk_content

    return f"Object Detection Report:\n{full_response}"

Cloud-Verarbeitung implementieren

Für komplexe Analysen, die umfassenderes Schlussfolgern erfordern, erstellen Sie ein Tool, das Amazon Bedrock aufruft. Dieses Tool wird nur aufgerufen, wenn der Orchestrator feststellt, dass lokale Modelle die Anfrage nicht bewältigen können:

import boto3

@tool
def get_expert_insights(context_data: str, question: str) -> str:
    """Get advanced analysis and expert recommendations
    for complex questions via Amazon Bedrock."""
    client = boto3.client("bedrock-runtime", region_name="us-east-1")

    conversation = [
        {
            "role": "user",
            "content": [
                {"text": f"Context: {context_data}\n\nQuestion: {question}"}
            ],
        }
    ]

    response = client.converse(
        modelId="<<model_id>", //Refer model id [details](https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)
        messages=conversation,
        inferenceConfig={
            "maxTokens": 512,
            "temperature": 0.5,
            "topP": 0.9
        }
    )

    response_text = response["output"]["message"]["content"][0]["text"]
    return f"Expert Analysis:\n{response_text}"

Den Strands-Agenten mit intelligenter Orchestrierung konfigurieren

Der Kern von AAIF ist die Strands-Agentenkonfiguration. Der Agent verwendet ein lokales SLM (llama3.2:1b) als Orchestrator. Strands Agents unterstützt mehrere Modellanbieter, und hier verwenden wir den Ollama-Anbieter, um den Orchestrator lokal auszuführen:

from strands.models.ollama import OllamaModel

model = OllamaModel(
    model_id="llama3.2:1b",
    host="http://localhost:11434",
    params={
        "max_tokens": 300,
        "temperature": 0.3,
    },
)

system_prompt = """You are a monitoring assistant for operational facilities.
You have access to device telemetry tools, analysis capabilities,
and expert insights to help monitor operations effectively.

When users ask for:
- Device status or telemetry: use get_device_telemetry
- Image or data analysis: use analyze_camera_feed
- Expert advice or complex questions: use get_expert_insights

Always return the complete tool results directly to the user."""

agent = Agent(
    model=model,
    system_prompt=system_prompt,
    tools=[
        get_device_telemetry,
        analyze_camera_feed,
        get_expert_insights,
    ],
)

Der SLM-basierte Orchestrator analysiert jede Anfrage und leitet sie ohne hartcodierte Keyword-Übereinstimmung an das entsprechende Tool weiter. Die Weiterleitung erfolgt über das Verständnis des Modells für die Anfrage:

Tabelle 1: Anfragen, Weiterleitungen und Latenzschätzungen für lokale Inferenz im Vergleich zu Cloud-Inferenz

Den Agenten ausführen

Nachdem der Agent konfiguriert ist, können Sie direkt mit ihm interagieren:

# Local processing - device telemetry
response = agent("What's the current status of our devices?")
print(response)

# Local processing - vision analysis
response = agent("Analyze the camera feed from camera-001")
print(response)

# Cloud processing - complex analysis
response = agent(
    "Based on current telemetry patterns, "
    "what optimization strategies do you recommend?"
)
print(response)

Der Agent klassifiziert jede Anfrage automatisch und leitet sie an die entsprechende Verarbeitungsebene weiter. Es sind keine expliziten Weiterleitungsregeln erforderlich.

An verschiedene Bereitstellungsszenarien anpassen

Die AAIF-Architektur passt sich an unterschiedliche Infrastrukturanforderungen an, indem die Modellkonfiguration geändert wird:

Wenn Ihre Workload vollständig in der Cloud läuft und keine Edge-Hardware verfügbar ist, ersetzen Sie die Ollama-Modellkonfiguration durch Amazon Bedrock für die gesamte Verarbeitung. Dadurch wird jede Anfrage über verwaltete Cloud-Inferenz geleitet, was Ihnen Auto Scaling ohne lokale GPU-Ressourcen ermöglicht. Teams mit zuverlässiger Konnektivität mit geringer Latenz und ohne Anforderungen an den Datenstandort profitieren am meisten von dieser Konfiguration:

from strands.models import BedrockModel

model = BedrockModel(
    model_id="<<model_id>", //Refer model id [details](https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)
    region_name="us-east-1"
)

Die Hybridkonfiguration behält den lokalen SLM-Orchestrator bei und fügt Cloud-Modelle für Anfragen hinzu, die die Fähigkeiten des lokalen Modells übersteigen. Dies ist die in dieser Anleitung gezeigte Standardkonfiguration von AAIF. Sie eignet sich für Umgebungen, in denen die meisten Anfragen routinemäßig genug sind, um lokal gelöst zu werden, während einige das umfassendere Schlussfolgern eines größeren Modells erfordern. Kosteneinsparungen können durch die etwa 80 Prozent des Datenverkehrs entstehen, die keinen kostenpflichtigen API-Endpunkt treffen.

Für Umgebungen, die vollständig luftisoliert sind oder strenge Anforderungen an die Datenhoheit haben, ersetzen Sie das Cloud-Tool durch ein größeres lokales Modell und führen Sie die gesamte Verarbeitung auf dem Gerät durch. Ein Modell mit 3B-Parametern auf Hardware mit ausreichend Speicher kann mäßig komplexe Aufgaben bewältigen, die der 1B-Orchestrator andernfalls eskalieren würde. Der Nachteil ist eine verringerte Schlussfolgertiefe bei den schwierigsten Abfragen, aber der Vorteil ist, dass die Daten das Gelände nicht verlassen:

model = OllamaModel(
    model_id="llama3.2:3b", # Larger local model for complex tasks
    host="http://localhost:11434",
)

Ausblick: Zentralisiertes Tool-Aufrufen mit MCP-Servern

Die Implementierung in diesem Beitrag verwendet lokale Tool-Aufrufe, die direkt im Agentencode definiert sind. Für Produktionsbereitstellungen mit mehreren Agenten, die Tools über Dienste hinweg gemeinsam nutzen, stellen Sie diese Tools als Model Context Protocol (MCP)-Server bereit. MCP bietet eine standardisierte Schnittstelle für Tool-Erkennung und -Aufruf, sodass Sie das Tool-Management zentralisieren und Tools über verschiedene Agenten und Umgebungen hinweg wiederverwenden können. In Abbildung 3 zeigen wir, wie AAIF-Tools in MCP-Server für verteiltes, zentralisiertes Tool-Aufrufen umgewandelt werden.

In der verteilten Konfiguration wie in Abbildung 3 gezeigt fungiert Gerät 1 als orchestrierender Hub und betreibt den Strands-Agenten mit dem SLM-Router und einem lokalen Telemetrie-Tool. Es verbindet sich über das MCP-Protokoll mit Gerät 2, das einen Edge-Vision-Verarbeitungsserver mit llama3.2-vision betreibt. Gerät 3 dient als Cloud-Analytics-Gateway, das mit Amazon Bedrock verbunden ist. Aus Sicht des Orchestrators erscheinen alle entfernten Tools als lokale Funktionsaufrufe, da die MCP-Transportschicht Serialisierung und Netzwerkkommunikation transparent behandelt.

Abbildung 3: Verteilte Intelligenz mit MCP-Servern

Aufräumen

Um zukünftige Kosten zu vermeiden, führen Sie die folgenden Aufräumschritte durch:

1. Deaktivieren Sie den Modellzugriff für Amazon Bedrock: Öffnen Sie die Amazon Bedrock-Konsole, wählen Sie Model accessund entziehen Sie den Zugriff für Amazon Nova Lite. Detaillierte Schritte finden Sie unter Manage model access im Amazon Bedrock User Guide.
2. Stoppen Sie den Ollama-Server und entfernen Sie Modelle, um lokalen Speicherplatz freizugeben (etwa 2 GB):

   ollama stop
   ollama rm llama3.2:1b
   ollama rm llama3.2-vision

3. Löschen Sie das Projektverzeichnis, wenn Sie den Beispielcode nicht mehr benötigen:

   rm -rf aaif-demo

Fazit

Wir haben gezeigt, wie sich kostengünstige KI-Agenten mit dem Adaptive Agentic Intelligence Framework und Strands Agents erstellen lassen. Indem AAIF Routineanfragen an lokale SLMs weiterleitet und Cloud-Modelle auf Amazon Bedrock für komplexe Analysen reserviert, können die API-Kosten gesenkt werden, während die Latenz für Routinevorgänge niedrig bleibt.

Bevor Sie dieses Muster in der Produktion einsetzen, fügen Sie dem Cloud-Inferenzpfad Kontrollmechanismen für verantwortungsvolle KI hinzu, da diese Anfragen Tool-Ausgaben, abgerufene Daten und Benutzereingaben enthalten. Sie können Amazon Bedrock Guardrails mit einer Guardrail-ID und Version an das Strands BedrockModel anhängen. Es wendet dann Inhaltsfilter für schädliche Kategorien, Prompt-Injection-Filter und kontextuelle Grounding-Prüfungen an, die Antworten blockieren, die nicht durch die Quelldaten gestützt werden. Um dieselben Richtlinien auf die lokale SLM-Stufe anzuwenden, rufen Sie die eigenständige ApplyGuardrail-API für ihre Ein- und Ausgaben auf. Auf diese Weise folgt jede Anfrage einem einzigen Sicherheitsstandard, egal welches Modell sie verarbeitet.

Dieses Architekturmuster ist nicht auf IoT-Monitoring beschränkt. Eine Gesundheitsorganisation könnte Patientenüberwachung lokal betreiben, während sie Diagnoseunterstützung an Cloud-Modelle weiterleitet. Ein Finanzdienstleistungsunternehmen könnte Transaktionen on-premises verarbeiten und Cloud-Kapazität für die Risikoanalyse reservieren. Ein Fertigungsteam könnte Qualitätskontroll-Visionmodelle am Edge ausführen, während es Optimierungsanfragen an die Cloud sendet.

Um mehr über den Aufbau von Agenten mit Strands Agents zu erfahren, besuchen Sie die Strands Agents documentation. Informationen zu verfügbaren Foundation Models finden Sie unter Amazon Bedrock.

Über die Autoren