Framework d'intelligence agentique adaptatif utilisant Strands Agents

Les organisations qui construisent des agents IA font face à un défi commun : chaque demande, qu'il s'agisse d'une simple vérification de statut ou d'une analyse complexe, est généralement acheminée vers un seul modèle volumineux et coûteux. Cette approche unique pour tous peut faire grimper les coûts d'API, introduire une latence imprévisible et empêcher le fonctionnement hors ligne. Même les requêtes de routine qui pourraient être résolues localement finissent par nécessiter un aller-retour réseau complet vers un grand modèle de langage (LLM) hébergé dans le cloud.

Le Framework d'intelligence agentique adaptatif (AAIF), construit avec Strands Agents, adopte une approche différente. Au lieu d'acheminer toutes les demandes vers un seul grand modèle, AAIF utilise de petits modèles de langage (SLM) pour traiter les tâches de routine localement. Les demandes plus complexes sont acheminées vers des modèles hébergés dans le cloud via Amazon Bedrock. Cette approche s'appuie sur la position de recherche de Belcak et al. chez NVIDIA. Ils soutiennent que les petits modèles de langage sont « suffisamment puissants, intrinsèquement plus adaptés et nécessairement plus économiques pour de nombreuses invocations dans les systèmes agentiques. » Construit sur Strands Agents, le framework démontre comment une orchestration intelligente des modèles peut aider à réduire les coûts tout en maintenant une faible latence pour les opérations locales.

Dans cet article, nous présentons les composants clés d'AAIF en utilisant Strands Agents avec des SLM locaux via Ollama et des modèles cloud via Amazon Bedrock. Nous utilisons un scénario de surveillance Internet des objets (IoT) comme implémentation de référence.

Aperçu de la solution

AAIF organise le traitement IA en trois couches, chacune optimisée pour différents types de tâches, comme le montre la Figure 1 :

1. L'orchestration intelligente utilise un SLM léger (llama3.2:1b) comme couche de prise de décision. Cet orchestrateur classe les demandes entrantes et les achemine vers la couche de traitement appropriée sans règles codées en dur.
2. Le traitement local gère les tâches de routine comme la récupération de télémétrie des appareils et l'analyse d'images à l'aide de SLM exécutés sur du matériel local via Ollama. Ces tâches s'accomplissent avec une faible latence et sans dépendance au cloud.
3. Le traitement cloud gère les analyses de motifs complexes et les recommandations stratégiques via des modèles de pointe dans Amazon Bedrock. Ces demandes nécessitent un contexte plus large et un raisonnement en plusieurs étapes que les SLM ne peuvent pas fournir de manière fiable.

Figure 1 : Les trois couches de traitement AAIF pour l'orchestration intelligente, le traitement local et le traitement cloud

La Figure 1 montre l'architecture complète du système AAIF. Au centre se trouve l'agent Strands, qui se connecte à un runtime Ollama hébergeant à la fois le modèle orchestrateur à 1B paramètres et le modèle de vision. L'agent expose trois outils : get_device_telemetry pour la récupération locale des données de capteurs, analyze_camera_feed pour le traitement de vision sur l'appareil via llama3.2-vision, et get_expert_insights qui appelle Amazon Bedrock via boto3 pour des analyses complexes. Les demandes entrantes des utilisateurs transitent par l'orchestrateur SLM, qui classe chaque demande et l'envoie soit à un outil local, soit au point de terminaison cloud selon la complexité de la tâche.

Figure 2 : Architecture complète du système AAIF montrant l'agent Strands, le runtime Ollama, les intégrations d'outils et la connectivité Amazon Bedrock

Le framework s'adapte à vos contraintes de déploiement plutôt que de vous obliger à restructurer votre infrastructure autour de lui. Cette architecture s'exécute sur des appareils en périphérie comme un Raspberry Pi avec 8 Go de mémoire, dans des déploiements entièrement cloud où toute infinition passe par Amazon Bedrock, ou dans des configurations hybrides combinant la rapidité locale au raisonnement cloud. La flexibilité vient de la séparation de la logique de routage (l'orchestrateur SLM) des outils de traitement, que vous pouvez échanger ou reconfigurer indépendamment selon le matériel disponible et la connectivité réseau.

Prérequis

Pour cette procédure, vous devez disposer des prérequis suivants :

• Un compte AWS.
• Amazon Bedrock avec accès aux modèles configuré dans la Région requise.
• Python 3.10+ installé.
• Ollama installé avec les modèles suivants téléchargés :
  • ollama pull llama3.2:1b (orchestrateur).
  • ollama pull llama3.2-vision (analyse de vision).
• Strands Agents installé : pip install strands-agents strands-agents-tools.
• AWS Command Line Interface (AWS CLI) configuré avec les informations d'identification appropriées.
• Boto3 installé : pip install boto3.

Configurez l'environnement

Créez un répertoire de projet et démarrez le serveur Ollama :

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

Récupérez les modèles requis :

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

Créez un fichier appelé aaif_agent.py et ajoutez les composants suivants.

Implémentez des outils de traitement local

Strands Agents utilise le décorateur @tool pour définir les capacités que les agents peuvent invoquer. Commencez par créer des outils pour le traitement local.

Le premier outil récupère les données de télémétrie de l'appareil. Dans un environnement de production, celui-ci se connecterait à de véritables capteurs IoT. Pour cette démonstration, il utilise des données d'appareil simulées :

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

Le second outil effectue une analyse visuelle à l'aide d'un SLM local. Le modèle llama3.2-vision s'exécute entièrement sur le matériel local, ce qui signifie que les flux vidéo sensibles des caméras ne quittent pas l'appareil :

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}"

Mettre en œuvre le traitement dans le cloud

Pour les analyses complexes qui nécessitent un raisonnement plus large, créez un outil qui appelle Amazon Bedrock. Cet outil n'est invoqué que lorsque l'orchestrateur détermine que les modèles locaux ne peuvent pas traiter la requête :

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}"

Configurer l'agent Strands avec une orchestration intelligente

Le cœur d'AAIF est la configuration de l'agent Strands. L'agent utilise un SLM local (llama3.2:1b) comme orchestrateur. Strands Agents prend en charge plusieurs fournisseurs de modèles, et ici nous utilisons le fournisseur Ollama pour exécuter l'orchestrateur localement :

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,
    ],
)

L'orchestrateur propulsé par le SLM analyse chaque requête et la route vers l'outil approprié sans correspondance par mots-clés codée en dur. Le routage s'effectue grâce à la compréhension de la requête par le modèle :

Tableau 1 : Requêtes, routage et estimations de latence pour l'inférence locale par rapport à l'inférence dans le cloud

Exécuter l'agent

Une fois l'agent configuré, vous pouvez interagir directement avec lui :

# 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)

L'agent classifie automatiquement chaque requête et la route vers la couche de traitement appropriée. Aucune règle de routage explicite n'est nécessaire.

S'adapter à différents scénarios de déploiement

L'architecture AAIF s'adapte à différentes exigences d'infrastructure en modifiant la configuration du modèle :

Lorsque votre charge de travail s'exécute entièrement dans le cloud et qu'aucun matériel en périphérie n'est disponible, remplacez la configuration du modèle Ollama par Amazon Bedrock pour tout le traitement. Ceci route chaque requête via une inférence cloud gérée, vous offrant une mise à l'échelle automatique sans nécessiter de ressources GPU locales. Les équipes disposant d'une connectivité fiable à faible latence et sans contraintes de résidence des données bénéficieront le plus de cette configuration :

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"
)

La configuration hybride conserve intact l'orchestrateur SLM local tout en ajoutant des modèles cloud pour les requêtes qui dépassent les capacités du modèle local. Il s'agit de la configuration AAIF par défaut présentée dans cette démonstration. Elle convient aux environnements où la plupart des requêtes sont assez courantes pour être résolues localement, mais où certaines nécessitent le raisonnement plus large d'un modèle de plus grande taille. Des économies peuvent être réalisées grâce aux quelque 80 % du trafic qui ne touchent pas un point de terminaison d'API payant.

Pour les environnements totalement isolés (air-gapped) ou soumis à des exigences strictes de souveraineté des données, remplacez l'outil cloud par un modèle local plus grand et exécutez tout le traitement sur l'appareil. Un modèle de 3B paramètres fonctionnant sur un matériel doté d'une mémoire adéquate peut gérer des tâches modérément complexes que l'orchestrateur 1B aurait autrement transmises. Le compromis est une profondeur de raisonnement réduite sur les requêtes les plus difficiles, mais l'avantage est que les données ne quittent pas les locaux :

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

Perspectives : appel d'outils centralisé avec les serveurs MCP

L'implémentation dans cet article utilise des appels d'outils locaux définis directement dans le code de l'agent. Pour les déploiements en production avec plusieurs agents partageant des outils entre services, exposez ces outils en tant que serveurs Model Context Protocol (MCP). MCP fournit une interface standardisée pour la découverte et l'invocation d'outils, ce qui vous permet de centraliser la gestion des outils et de les réutiliser entre différents agents et environnements. Dans la Figure 3, nous montrons comment convertir les outils AAIF en serveurs MCP pour un appel d'outils distribué et centralisé.

Dans la configuration distribuée illustrée à la Figure 3, l'appareil 1 agit comme le hub d'orchestration, exécutant l'agent Strands avec le routeur SLM et un outil de télémétrie local. Il se connecte via le protocole MCP à l'appareil 2, qui exécute un serveur de traitement visuel en périphérie avec llama3.2-vision. L'appareil 3 sert de passerelle d'analytique cloud connectée à Amazon Bedrock. Du point de vue de l'orchestrateur, tous les outils distants apparaissent comme des appels de fonctions locales, car la couche de transport MCP gère la sérialisation et la communication réseau de manière transparente.

Figure 3 : Intelligence distribuée avec les serveurs MCP

Nettoyage

Pour éviter des frais futurs, effectuez les étapes de nettoyage suivantes :

1. Désactivez l'accès aux modèles Amazon Bedrock : ouvrez la console Amazon Bedrock, choisissez Model access, puis révoquez l'accès à Amazon Nova Lite. Pour des étapes détaillées, consultez Manage model access dans le Amazon Bedrock User Guide.
2. Arrêtez le serveur Ollama et supprimez les modèles pour libérer de l'espace disque local (environ 2 Go) :

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

3. Supprimez le répertoire du projet si vous n'avez plus besoin de l'exemple de code :

   rm -rf aaif-demo

Conclusion

Nous avons montré comment créer des agents d'IA économiques à l'aide de l'Adaptive Agentic Intelligence Framework avec Strands Agents. En acheminant les demandes courantes vers des SLM locaux et en réservant les modèles cloud sur Amazon Bedrock pour les analyses complexes, AAIF peut contribuer à réduire les coûts d'API tout en maintenant une faible latence pour les opérations courantes.

Avant d'exécuter ce modèle en production, ajoutez des contrôles d'IA responsable au chemin d'inférence cloud, car ces demandes contiennent des sorties d'outils, des données récupérées et des entrées utilisateur. Vous pouvez associer Amazon Bedrock Guardrails au Strands BedrockModel avec un ID et une version de garde-fou. Celui-ci applique alors des filtres de contenu pour les catégories nuisibles, des filtres contre l'injection d'invites et des vérifications d'ancrage contextuel qui bloquent les réponses non étayées par les données sources. Pour appliquer les mêmes politiques au niveau SLM local, appelez l'API autonome ApplyGuardrail sur ses entrées et sorties. Ainsi, chaque demande suit une norme de sécurité unique, quel que soit le modèle qui la traite.

Ce modèle d'architecture s'applique au-delà de la surveillance IoT. Un organisme de santé pourrait exécuter la surveillance des patients localement tout en acheminant l'aide au diagnostic vers des modèles cloud. Une entreprise de services financiers pourrait traiter les transactions sur site et réserver la capacité cloud pour l'analyse des risques. Une équipe de fabrication pourrait exécuter des modèles de vision de contrôle qualité à la périphérie tout en envoyant les demandes d'optimisation vers le cloud.

Pour en savoir plus sur la création d'agents avec Strands Agents, consultez la documentation de Strands Agents. Pour obtenir des informations sur les modèles de fondation disponibles, consultez Amazon Bedrock.

À propos des auteurs