Strands Agents ist ein quelloffenes Python-SDK zum Bau von KI-Agenten, die Werkzeuge aufrufen können. Für IoT beschreibt AWS damit lokale Sensorüberwachung und eine Greengrass-Installation am Gerät; das Strands-Agents-Projekt behandelt außerdem die Koordination vernetzter Roboter. Entscheidend ist, welche Arbeit lokal erledigt wird und wofür eine Verbindung zur Cloud nötig ist.
Drei Muster für drei verschiedene Aufgaben
| Muster | Aufgabe | Lokal | Rolle der Cloud und Netzabhängigkeit |
| Adaptive Agentic Intelligence Framework (AAIF) | Geräte- und Sensordaten überwachen | Ein kleines Sprachmodell koordiniert lokale Werkzeuge und Modelle. | Amazon Bedrock übernimmt ausgewählte komplexe Analysen. |
| Greengrass-Implementierung für Landwirtschaft | Bodenfeuchte, Pflanzenbilder und Gerätezustand prüfen | Ein Strands-Agent auf einem Raspberry Pi 5 liest Sensordaten und fragt den Gerätezustand ab. | Amazon Bedrock analysiert Pflanzenbilder; dafür ist eine Netzwerkverbindung nötig. |
| Strands Robots | Mehrere Roboter oder Geräte koordinieren | Zenoh verbindet Geräte im selben lokalen Netzwerk. | AWS IoT Core ist für verteilte oder cloudverwaltete Flotten vorgesehen. |
AAIF: lokale Werkzeuge, aber simulierte Sensordaten
AWS beschreibt AAIF als dreiteiliges Muster: Ein kleines Sprachmodell übernimmt die Orchestrierung, also die Auswahl und Koordination von Werkzeugen. Lokale Modelle und Werkzeuge erledigen einfache Aufgaben; ausgewählte komplexere Anfragen gehen an Amazon Bedrock. Als lokales Orchestrierungsmodell verwendet das Beispiel llama3.2:1b; für die lokale Bildanalyse dient llama3.2-vision.
Die Telemetrie im AAIF-Beispiel stammt jedoch nicht von angeschlossenen Sensoren. Die Funktion get_device_telemetry greift auf ein fest codiertes Python-Wörterbuch zurück und wählt daraus zufällig ein Gerät. AWS beschreibt eine Verbindung zu echten Sensoren als möglichen Schritt für einen Produktionseinsatz.
Für das AAIF-Beispiel nennt AWS Python 3.10 oder neuer und Ollama. Der Cloud-Pfad setzt außerdem AWS-Zugangsdaten und Zugriff auf ein Modell in Bedrock voraus. AWS gibt an, dass Bedrock-Aufrufe pro Anfrage Kosten verursachen.
Der veröffentlichte AAIF-Code enthält für die Bedrock-Modell-ID einen Platzhalter und verwendet // für Kommentare. Python erkennt diese Schreibweise nicht als Kommentar, daher lässt sich der Ausschnitt nicht unverändert als lauffähiges Beispiel übernehmen.
Greengrass: Sensorarbeit am Gerät, Bildanalyse in der Cloud
In einer separaten Landwirtschafts-Implementierung beschreibt AWS Strands Agents als Komponente von AWS IoT Greengrass auf einem Raspberry Pi 5 mit 4 oder 8 GB Arbeitsspeicher. Ein digitaler Bodenfeuchtesensor ist an GPIO 17 angeschlossen. Die Komponenten tauschen Anfragen und Antworten über MQTT aus, ein Nachrichtenprotokoll für Gerätekommunikation. Dafür nennt AWS die Themen gg/monitor/request und gg/monitor/response.
Die lokale Aufgabenteilung hat eine konkrete Folge bei Netzunterbrechungen: Bodenfeuchte abfragen und den Gerätezustand prüfen funktioniert in diesem Beispiel weiterhin. Die Analyse von Pflanzenbildern benötigt Amazon Bedrock und damit eine Netzwerkverbindung.
Auch die Kamera ist klar zugeordnet: Das lokale Dashboard greift auf sie zu und stellt Schnappschüsse über localhost:8080/snapshot bereit. So konkurriert die Agentenkomponente nicht selbst mit dem Dashboard um den Kamerazugriff. AWS nennt für diese separate Implementierung Python 3.9 oder neuer, Raspberry Pi OS in der 64-Bit-Version und AWS CLI 2.0 oder neuer.
Strands Robots koordiniert Geräte statt Sensorwerte auszuwerten
Strands Robots beschreibt einen anderen Einsatz: Agenten sollen mehrere Roboter oder Geräte in einem Netzwerk entdecken und koordinieren. Für Geräte im selben lokalen Netzwerk ist Zenoh der vorgesehene Standardtransport; für verteilte oder cloudverwaltete Flotten beschreibt das Projekt AWS IoT Core.
Als Beispiel führt das Projekt einen Universal Robots UR10e in einer MuJoCo-Simulation an. Für diese Simulation seien weder eine GPU noch physische Hardware erforderlich. Die Unterstützung des Model Hardware Standard (MHS), einer Schnittstelle für den Zugriff auf Gerätefunktionen, bezeichnet das Projekt als Vorabversion innerhalb einer begrenzten Forschungsvorschau.
Wer Sensorwerte lokal erfassen und den Gerätezustand prüfen will, findet das passende Muster im Greengrass-Beispiel. AAIF zeigt, wie lokale Werkzeuge mit ausgewählten Cloud-Analysen zusammenspielen. Geht es dagegen darum, vernetzte Roboter gemeinsam zu steuern, beschreibt Strands Robots ein separates Mesh-Muster.
