Agent IoT oparty na Strands Agents to programowy agent AI, który korzysta z narzędzi do obsługi danych i urządzeń podłączonych do sieci. W opisanych przykładach może monitorować czujniki, łączyć lokalne przetwarzanie z analizą w chmurze albo koordynować roboty. To trzy odrębne wzorce, a nie jeden gotowy system.
Rozróżnienie jest praktyczne: od niego zależy, które zadania wykonują urządzenia na miejscu, a które wymagają połączenia z chmurą.
Trzy wzorce dla różnych zadań
AWS opisuje dwa przykłady monitorowania IoT: architekturę AAIF oraz wdrożenie rolnicze z AWS IoT Greengrass. Projekt Strands Agents przedstawia osobno siatkę do koordynowania robotów i innych urządzeń.
| Wzorzec | Opisane zadanie | Co działa lokalnie | Rola chmury i granica łączności |
| AAIF | Monitorowanie urządzeń, telemetrii i obrazów | Lokalny model koordynuje zadania, a narzędzia obsługują lokalne dane i analizę obrazu | Amazon Bedrock obsługuje wybrane, bardziej złożone analizy |
| AWS IoT Greengrass | Monitorowanie wilgotności gleby, zdrowia roślin i urządzenia | Odczyt czujnika i sprawdzanie stanu urządzenia mogą działać bez połączenia z chmurą | Analiza obrazu rośliny korzystająca z Bedrock wymaga łączności |
| Strands Robots | Odkrywanie i koordynowanie wielu robotów lub urządzeń | Zenoh domyślnie łączy urządzenia w lokalnej sieci równorzędnej | AWS IoT Core służy w opisie projektu do obsługi flot rozproszonych lub zarządzanych z chmury |
AAIF: lokalne zadania i symulowana telemetria
Adaptive Agentic Intelligence Framework (AAIF) dzieli pracę na trzy warstwy: lokalną orkiestrację, czyli wybieranie i kierowanie zadaniami, lokalne przetwarzanie oraz analizę w chmurze przez Amazon Bedrock. W przykładzie AWS rolę lokalnego koordynatora pełni model llama3.2:1b; narzędzia lokalne korzystają z Ollama, a wybrane zapytania trafiają do Bedrock.
Przykład telemetrii nie odczytuje prawdziwych czujników. Funkcja get_device_telemetry wybiera urządzenie z zakodowanego w Pythonie słownika przykładowych danych. AWS opisuje podłączenie rzeczywistych czujników jako krok dla wersji produkcyjnej. Z kolei analyze_camera_feed wykorzystuje lokalny model llama3.2-vision, a narzędzie get_expert_insights wysyła zapytanie do Bedrock.
Dla osoby oceniającej tę architekturę ważny jest więc podział zadań, a nie wartości z demonstracyjnej telemetrii. Lokalna analiza może obsłużyć część pracy, natomiast wybrane zadania zależą od dostępu do usługi chmurowej. Ścieżka Bedrock w przykładzie wymaga poświadczeń AWS i dostępu do modelu. Wywołania modeli w Bedrock są rozliczane za każde żądanie.
Przykład AAIF wymaga Pythona 3.10 lub nowszego. Kod Bedrock opublikowany przez AWS zawiera zastępczy identyfikator modelu, a użyte w nim komentarze // nie są poprawną składnią komentarzy w Pythonie. Nie jest to więc kod gotowy do uruchomienia w niezmienionej postaci.
Greengrass: czujniki na brzegu, analiza obrazów w chmurze
W osobnym przykładzie rolniczym AWS uruchamia komponent Strands Agents w AWS IoT Greengrass na Raspberry Pi 5. Czujnik cyfrowej wilgotności gleby łączy się przez GPIO 17. Agent i lokalny panel wymieniają żądania oraz odpowiedzi za pomocą tematów MQTT gg/monitor/request i gg/monitor/response. MQTT to protokół przesyłania krótkich komunikatów między urządzeniami.
Ten przykład pokazuje konkretny podział odpowiedzialności: lokalne odczyty czujnika i zapytania o stan urządzenia mogą działać podczas przerwy w łączności, ale analiza zdjęcia rośliny przez Amazon Bedrock wymaga dostępu do sieci. Jeśli urządzenie ma nadal reagować na wilgotność lub zgłaszać własny stan podczas awarii internetu, te zadania muszą pozostać lokalne.
Panel internetowy zarządza kamerą i udostępnia jej zdjęcia przez localhost:8080/snapshot. Komponent agenta pobiera migawkę z tego adresu, zamiast samodzielnie przejmować kamerę. W przykładzie AWS użyto Raspberry Pi 5 z 4 lub 8 GB RAM, 64-bitowego Raspberry Pi OS, modułu kamery v2 lub v3, Greengrass Core oraz Pythona 3.9 lub nowszego. To wymagania tego wdrożenia, odrębne od wymagań przykładu AAIF.
Strands Robots: koordynacja urządzeń w sieci
Strands Robots dotyczy innego zadania niż odczyt czujników: agenci mają odkrywać urządzenia w sieci i koordynować pracę robotów. Opis projektu wskazuje Zenoh jako domyślny transport dla urządzeń w tej samej sieci lokalnej, a AWS IoT Core jako rozwiązanie dla floty rozproszonej między sieciami lub zarządzanej z chmury.
W opisanym zastosowaniu agent może sprawdzać stan urządzeń, przekazywać im polecenia w języku naturalnym, rozsyłać komunikaty i uruchomić zatrzymanie całej floty w sytuacji awaryjnej. Przykład symulacyjny wykorzystuje ramię Universal Robots UR10e w MuJoCo; według projektu symulacja nie wymaga fizycznego robota ani GPU.
Integracja z Model Hardware Standard (MHS), standardem opisującym ujednolicony dostęp do sprzętu, jest przedstawiona jako funkcja przedpremierowa w ograniczonym programie badawczym. Urządzenie udostępnia w tym modelu operacje read i write oraz deklarowane ograniczenia, blokady i zatrzymania awaryjne.
Który wzorzec pasuje do zadania?
Do monitorowania urządzeń i kierowania wybranych analiz do chmury służy opis AAIF. Przykład Greengrass jest bardziej konkretnym wzorcem pracy na brzegu: wskazuje komputer, interfejs czujnika, sposób wymiany komunikatów i to, które zadania zależą od internetu. Strands Robots odpowiada na potrzebę koordynowania wielu fizycznych urządzeń, a nie tylko pobierania telemetrii.
Wybierając architekturę, zacznij od zadania, które ma działać mimo utraty połączenia. Odczyt czujnika i kontrola stanu mogą pozostać lokalne w przykładzie Greengrass; analiza obrazu w Bedrock wymaga sieci. W przypadku floty robotów kluczowy jest z kolei wybór komunikacji lokalnej albo rozproszonej. To rozdziela trzy zastosowania, które łatwo wrzucić do jednego worka pod etykietą agenta IoT.
