Was ist Strands Agents? AWS' Open-Source-modellgesteuertes Agenten-SDK

Wenn Sie einen KI-Agenten als große if/else-Zustandsmaschine gebaut haben, kennen Sie das Problem: Jede neue Fähigkeit macht den Code brüchiger. Strands Agents geht anders vor. Sie geben dem Agenten ein Modell, einen System-Prompt und Tools; das Modell plant die Schritte selbst. Das Open-Source-SDK von AWS wurde im Mai 2025 unter der Apache-Lizenz 2.0 veröffentlicht und wird in Produktionsagenten innerhalb von Amazon-Teams wie Amazon Q Developer und AWS Glue eingesetzt.

Teste Apidog noch heute

Was Strands Agents tatsächlich ist

Strands Agents ist ein SDK zum Erstellen und Ausführen von KI-Agenten mit wenigen Codezeilen. Ein Agent bekommt drei Bausteine:

1. ein Modell,
2. einen System-Prompt,
3. eine Liste von Tools.

Das Modell liest den Prompt, entscheidet, welche Tools aufgerufen werden sollen, führt sie aus, bewertet die Ergebnisse und macht weiter, bis die Aufgabe erledigt ist.

Strands ist für Python und TypeScript verfügbar. Der Name spielt auf die zwei Stränge an, aus denen ein Agent besteht: Modell und Tools. AWS hat das SDK nach internem Einsatz als Open Source veröffentlicht; das Design ist daher eher auf Produktionsanforderungen als auf Demos ausgerichtet. Seit dem Vorab-Launch hat es über 150.000 PyPI-Downloads überschritten und eine 1.0-Version erreicht, die Multi-Agent-Primitive und Unterstützung für das Agent-to-Agent-Protokoll, kurz A2A, ergänzt.

Wenn Sie bereits mit anderen Agenten-SDKs gearbeitet haben, wirkt die Struktur vertraut. Strands gehört in dieselbe Kategorie wie LangGraph und Google ADK, verlässt sich aber stärker darauf, dass das Modell den Kontrollfluss steuert, statt dass Sie den Graphen selbst definieren.

Modellgetrieben statt fest codiert

Viele frühe Agenten-Frameworks verlangen, dass Sie den Workflow vorab modellieren: Knoten, Kanten, Bedingungen, Routing. Das funktioniert, aber jede neue Fähigkeit erzeugt mehr Orchestrierungscode.

Strands dreht diese Verantwortung um. Moderne Modelle können planen, Argumente verketten, Tools aufrufen und Ergebnisse reflektieren. Statt diese Logik manuell zu codieren, beschreiben Sie das Ziel und stellen Tools bereit.

Ansatz	Sie definieren	Kontrollfluss liegt in	Kosten einer neuen Fähigkeit
Fest codierte Orchestrierung	Knoten, Kanten, Bedingungen, Routing	Ihrem Graphen-Code	Graph bearbeiten, Pfade erneut testen
Modellgetrieben mit Strands	Prompt und Tool-Liste	Denk- und Tool-Call-Prozess des Modells	Tool hinzufügen, Prompt aktualisieren

Der Kompromiss: Modellgetriebene Agenten sind schneller zu bauen und zu erweitern, aber weniger deterministisch. Wenn ein Workflow jedes Mal exakt gleich ablaufen muss, können Sie weiterhin Struktur über Hooks, Multi-Agent-Muster oder ein graphenbasiertes Framework ergänzen. Strands ist vor allem dann stark, wenn Sie nicht jeden Pfad vorab modellieren möchten.

Minimaler Strands-Agent in Python

Ein einfacher Agent besteht aus einer Agent-Instanz und optionalen Tools. Tools sind normale Funktionen, die mit @tool annotiert werden.

from strands import Agent, tool

@tool
def word_count(text: str) -> int:
    """Count the words in a block of text."""
    return len(text.split())

agent = Agent(
    system_prompt="You are a concise writing assistant.",
    tools=[word_count],
)

response = agent("How many words are in this sentence?")
print(response)

Wichtig für die Implementierung:

• Der @tool-Decorator macht die Funktion für das Modell aufrufbar.
• Docstring und Type Hints beschreiben Zweck und Eingabeschema des Tools.
• Sie müssen kein separates Tool-Register pflegen.
• Der Aufruf agent(...) startet den Agenten-Loop und läuft, bis das Modell die Aufgabe als erledigt betrachtet.

Für produktive Tools sollten Sie die Eingaben defensiv validieren und externe API-Fehler explizit behandeln:

from strands import tool
import requests

@tool
def get_ticket_status(ticket_id: str) -> dict:
    """Fetch the current status of a support ticket by ticket ID."""
    if not ticket_id.strip():
        raise ValueError("ticket_id must not be empty")

    response = requests.get(
        f"https://example.com/api/tickets/{ticket_id}",
        timeout=10,
    )
    response.raise_for_status()

    return response.json()

So verhindern Sie, dass einfache API- oder Validierungsfehler später wie Modellfehler aussehen.

Tools und Modell-Anbieter

Tools sind die Schnittstelle zwischen Agent und Außenwelt. Ein Tool kann sein:

• eine selbst geschriebene Python-Funktion,
• ein Tool aus der Community,
• ein kompletter Model Context Protocol-Server, kurz MCP,
• eine Wrapper-Funktion um eine interne REST-API.

Auf Modellseite ist Strands anbieterflexibel. Standardmäßig nutzt Strands Amazon Bedrock; standardmäßig wird ein Claude-Sonnet-Modell in der Region us-west-2 verwendet. Die genaue Standardmodell-ID hat sich über SDK-Versionen hinweg geändert, daher sollten Sie Ihre installierte Version prüfen und die ID nicht blind fest codieren.

Unterstützte Optionen sind unter anderem:

• Amazon-Bedrock-Modelle mit Tool-Nutzung und Streaming,
• Anthropic Claude über die Anthropic API,
• Llama-Modelle über die Llama API,
• Ollama für lokale Entwicklung,
• andere Anbieter wie OpenAI über LiteLLM.

Der wichtige Punkt für Ihre Architektur: Der Wechsel des Providers ist eine Änderung am Modellobjekt, nicht am Agenten-Loop. Ihre Tools und Prompts bleiben gleich. Dadurch können Sie lokal mit Ollama prototypen und später auf Bedrock oder einen anderen verwalteten Anbieter wechseln.

Multi-Agenten und MCP

Ein einzelner Agent reicht für viele Aufgaben. In realen Systemen entstehen aber schnell spezialisierte Rollen: Recherche, Validierung, Planung, Ausführung, Zusammenfassung.

Strands 1.0 ergänzt dafür Multi-Agent-Primitive, darunter:

• Agent-als-Tool: Ein Agent ruft einen anderen Agenten wie ein normales Tool auf.
• Schwarm-artige Koordination: Mehrere Agenten arbeiten gemeinsam an einem Problem.
• A2A-Unterstützung: Strands-Agenten können mit Agenten kommunizieren, die auf anderen Frameworks basieren.

MCP ist ebenfalls ein zentraler Baustein. Das Model Context Protocol ist ein offener Standard, um Modelle mit Tools und Datenquellen zu verbinden. Mit Strands können Sie veröffentlichte MCP-Server anbinden und deren Tools direkt verwenden. Dadurch werden bestehende Integrationen nutzbar, ohne dass Sie eigenen Klebecode schreiben müssen.

Ein typischer Ablauf sieht so aus:

1. MCP-Server starten oder verbinden.
2. MCP-Client konfigurieren.
3. Tools des MCP-Servers abrufen.
4. Diese Tools dem Strands-Agenten übergeben.
5. Agenten-Loop mit Prompt und Modell ausführen.

Wenn Sie bereits MCP-Server betreiben, ist das oft der schnellste Weg, einem Agenten neue Fähigkeiten zu geben. Der Nachteil: Ihr Agent hängt jetzt davon ab, dass diese Server stabile und korrekt strukturierte Antworten liefern. Deshalb sollten Sie die zugrunde liegenden Endpunkte separat testen.

Strands-Agenten bereitstellen

Strands ist so ausgelegt, dass derselbe Agent lokal entwickelt und später produktiv bereitgestellt werden kann. Geeignete Targets sind unter anderem:

• Amazon Bedrock AgentCore für eine verwaltete Agenten-Laufzeitumgebung,
• AWS Lambda für ereignisgesteuerte, kurzlebige Agenten,
• AWS Fargate oder Amazon EKS für containerisierte, langlebige Dienste,
• Docker überall dort, wo Container laufen können.

Da ein Strands-Agent gewöhnlicher Python- oder TypeScript-Code ist, folgt das Packaging den normalen Regeln Ihrer App.

Eine praktische Deployment-Checkliste:

• Modellanbieter und Region explizit konfigurieren.
• API-Schlüssel über Umgebungsvariablen oder Secret Manager bereitstellen.
• Timeouts für externe Tool-Aufrufe setzen.
• Tool-Antworten validieren.
• Fehlerfälle testen, nicht nur Happy Paths.
• Observability aktivieren, damit sichtbar ist, welche Tools das Modell aufgerufen hat.
• Kosten und Rate Limits der Modell- und Tool-Anbieter überwachen.

AWS dokumentiert Observability-Hooks, mit denen Sie nachvollziehen können, welche Entscheidungen das Modell getroffen und welche Tools es genutzt hat. Diese Traces sind besonders wichtig, wenn ein Agent in Produktion unerwartete Ergebnisse liefert.

Wo Apidog passt

Strands erstellt und orchestriert den Agenten. Es erstellt nicht automatisch die APIs, die Ihr Agent aufruft. Genau dort müssen Sie planen.

Ein Strands-Agent hängt meist von zwei Arten von HTTP-Endpunkten ab:

1. der LLM-Anbieter-API hinter dem Modell,
2. REST-, Tool- oder MCP-Endpunkten hinter Ihren @tool-Funktionen.

Wenn diese Endpunkte falsche Statuscodes, unerwartete JSON-Strukturen oder instabile Antwortzeiten liefern, sieht das im Agenten oft wie ein Modellproblem aus. Tatsächlich ist es häufig ein API-Problem.

Apidog ist der Ort, an dem Sie diese APIs testen und simulieren, bevor der Agent sie nutzt.

Konkrete Einsatzfälle:

• LLM- oder Tool-Endpunkte simulieren: Beim Entwickeln des Agenten-Loops können Sie Mocks verwenden, statt bei jedem Lauf Tokens zu verbrauchen oder Rate Limits zu treffen. Der Artikel zum Aufbau eines KI-Agenten-Test-Harness mit Apidog zeigt das Muster.
• Antwortformate validieren: Prüfen Sie Statuscodes, Pflichtfelder und Datentypen, bevor ein Tool in Produktion geht. Die Anleitung zu API-Assertions zeigt, wie solche Prüfungen umgesetzt werden.
• Mock-APIs bereitstellen: Mit einer simulierten API können Sie reale Dienste nachahmen, inklusive Fehlerfällen, die Ihr Agent sauber behandeln muss.
• Umgebungen trennen: Verwalten Sie API-Schlüssel für Development, Staging und Produktion separat, damit keine Credentials im Code landen.

Apidog ist kein Agenten-Framework und übernimmt keine Orchestrierung. Strands bleibt das Gehirn des Agenten. Apidog ist die Werkbank für die darunterliegenden APIs. Sie können Apidog herunterladen und Mocks für Ihre Tool-Endpunkte einrichten, bevor Sie den Agenten gegen echte Backends laufen lassen.

Wann Sie Strands Agents verwenden sollten

Strands passt gut, wenn:

• Sie schnell einen Agenten prototypen möchten,
• Sie dem Modell die Planung überlassen können,
• Sie bereits AWS oder Bedrock verwenden,
• Sie mit einem Agenten starten und später auf Multi-Agenten erweitern möchten,
• Sie MCP-Tools ohne eigenen Integrationscode nutzen wollen,
• Ihre Tools klar definierte Ein- und Ausgaben haben.

Weniger passend ist Strands, wenn Sie strikt deterministische Abläufe benötigen, bei denen jeder Zweig vorab definiert und auditierbar sein muss. Das lässt sich teilweise mit Hooks und Multi-Agent-Strukturen abbilden, aber ein Graph-First-Framework kann dann direkter sein.

Die kurze Entscheidungshilfe:

• Unklare, offene Aufgaben: Strands.
• Feste Workflows mit vielen Regeln: Graphenbasiertes Framework.
• Hybride Systeme: Strands für flexible Aufgaben, Graphen für kritische Pfade.

Häufig gestellte Fragen

Ist Strands Agents kostenlos und Open Source?

Ja. Strands Agents ist Open Source unter der Apache-Lizenz 2.0, und der Quellcode ist auf GitHub verfügbar. Für das SDK selbst fallen keine Lizenzgebühren an. Kosten entstehen für Modellaufrufe und Cloud-Ressourcen, etwa Bedrock-Inferenz oder Lambda-Ausführung.

Muss ich Amazon Bedrock mit Strands verwenden?

Nein. Bedrock ist der Standardanbieter, aber Strands unterstützt auch die Anthropic API, die Llama API, Ollama für lokale Ausführungen und andere Anbieter über LiteLLM. Sie ändern das Modellobjekt und behalten Agenten-Loop, Tools und Prompt bei.

Was ist der Unterschied zwischen Strands und einem graphenbasierten Framework?

Strands ist modellgetrieben: Sie liefern Prompt und Tools, und das Modell entscheidet die Schritte. Graphenbasierte Frameworks verlangen, dass Sie den Kontrollfluss als Knoten und Kanten definieren. Strands ist schneller anpassbar; Graphen bieten mehr Vorhersagbarkeit und Kontrolle.

Wie teste ich die APIs, von denen mein Strands-Agent abhängt?

Testen Sie die APIs unabhängig vom Agenten. Simulieren Sie LLM- und Tool-Endpunkte, validieren Sie Antwortformate und führen Sie diese Prüfungen in CI aus. Ein Tool wie Apidog kann Mocking und Assertions übernehmen. Die Anleitung zum Testen der ChatGPT API mit Apidog behandelt Authentifizierung, Streaming und Tool-Call-Tests, die sich auf Agenten-Backends übertragen lassen.

Fazit

Strands Agents bietet einen klaren Implementierungsansatz: Modell definieren, Prompt schreiben, Tools bereitstellen und den Agenten-Loop vom Modell steuern lassen. Das SDK skaliert von einem einzelnen Agenten zu Multi-Agenten-Setups, unterstützt MCP und A2A und lässt sich über den AWS-Stack bereitstellen.

Für stabile Agenten reicht das Framework allein aber nicht aus. Ihre Tools und APIs müssen genauso zuverlässig sein wie der Agenten-Code. Testen und simulieren Sie deshalb die Endpunkte, bevor der Agent sie nutzt. Strands übernimmt die Agentenlogik; Apidog hilft dabei, die API-Infrastruktur darunter überprüfbar zu machen.