Amazon Bedrock Agents vs. The Control Plane: Ein architektonischer Überblick

Für DevOps-Ingenieure und -Architekten, die innerhalb des AWS-Perimeters tätig sind Amazon Bedrock-Agenten—architektonisch bekannt als AgentCore-Laufzeit— ist der Standardpfad für die Erstellung agentischer Workflows. Es standardisiert die komplexen rekursiven Schleifen, die für Agenten erforderlich sind, und übernimmt die Argumentation, den Speicher und die API-Orchestrierung, die Entwickler zuvor mithilfe von Bibliotheken wie Lang-Kette.

Die Einführung eines Managed-Agent-Frameworks erfordert jedoch häufig einen Kompromiss zwischen anfänglicher Geschwindigkeit und langfristiger Architekturkontrolle. Es verbindet die Anwendungslogik mit der Orchestrierungsphilosophie eines bestimmten Cloud-Anbieters. In diesem Bericht wird die technische Architektur der Amazon Bedrock Agents analysiert, die betrieblichen Realitäten im Hinblick auf die Beobachtbarkeit bewertet und sie einem agnostischen Ansatz der Steuerungsebene gegenübergestellt, der TrueFoundry-Plattform.

Die Anatomie der Amazon Bedrock Agent Runtime

Bedrock Agents fungieren als Orchestrierungs-Engine, die für die Ausführung mehrstufiger Aufgaben entwickelt wurde. Im Gegensatz zu einem statusfreien InvokeModel-API-Aufruf arbeitet ein Agent als zustandsbehaftete Schleife.

Bei der Definition eines Agenten in Bedrock konfigurieren Entwickler drei verschiedene Primitive:

1. Die Aktionsgruppe: Ein OpenAPI-Schema Definition der Fähigkeiten des Agenten. Diese sind in der Regel zugeordnet AWS Lambda Funktionen, die die Berechnungsebene für die Werkzeugausführung bereitstellen.
2. Die Wissensbasis: Eine Vector-Store-Integration (typischerweise Amazon OpenSearch Serverlos), das RAG-Funktionen zur Erdung des Modells bereitstellt.
3. Die Orchestrierungsvorlage: Die Prompt-Engineering-Logik, die das Modell anweist, Benutzereingaben zu interpretieren, das richtige Lambda auszuwählen und die Ausgabe zu analysieren.

Die Argumentationsschleife

Das Hauptnutzen ist die Automatisierung der Argumentationsschritte. Wenn ein Benutzer fragt, ob er „das Inventar für Objekt X überprüfen und die Datenbank aktualisieren“ möchte, zerlegt die Runtime diese Anfrage:

• Schritt 1: Stellt fest, dass CheckInventory Lambda erforderlich ist.
• Schritt 2: Konstruiert die Nutzlast.
• Schritt 3: Führt das Lambda aus und liest die Antwort.
• Schritt 4: Legt fest, dass UpdateDatabase der nächste logische Schritt ist, basierend auf der vorherigen Ausgabe.

Abbildung 1: Die rekursive Orchestrierungsschleife, die von AWS Bedrock Agents verwaltet wird.

Operative Kompromisse

Managed Services beschleunigen die Erstbereitstellung, aber die Abläufe am zweiten Tag — Debugging, Skalierung und Migration — machen oft die Kosten der Abstraktion deutlich.

Überlegungen zur Beobachtbarkeit

In einer vollständig verwalteten Laufzeit ist die Prompt-Schleife abstrahiert. Die Systemanweisungen und Tooldefinitionen werden von AWS erstellt und hinter der Servicegrenze an das LLM gesendet.

Wenn ein Agent halluziniert oder das falsche Tool aufruft, kann das Debuggen komplex sein, da das unformatierte Kontextfenster und die dazwischenliegenden Schritte zum Denken oft implizit verwaltet werden. Dies kann dazu führen, dass sich Teams auf Folgendes konzentrieren Debuggen der endgültigen Ausgabe anstatt den granularen Argumentationsprozess zu überprüfen.

Architekturen, die ein KI-Gateway wie TrueFoundry verwenden, halten die Orchestrierungslogik transparent. Das „Gehirn“ des Agenten läuft auf Ihrer Infrastruktur und stellt sicher, dass jede Aufforderung, jedes Token und jede Argumentation in Tracking-Tools wie Telemetrie öffnen oder Arize.

Die AWS-zentrierte Werkzeugkette

Bedrock Agents sind für das AWS-Ökosystem optimiert. Das native Aufrufen eines Tools bedeutet in der Regel, dass das Tool als Lambda-Funktion existiert.

Wenn ein Unternehmen externe Tools wie eine Snowflake-Datenbank, eine Salesforce-API oder einen auf Azure gehosteten Dienst verwendet, koordinieren sich Entwickler häufig über Wrapper-Lambdas in AWS, um die Lücke zu schließen. Dies kann zu zusätzlicher Latenz und zusätzlichem Wartungsaufwand führen.

Die Branche vereint sich derzeit rund um Modellkontextprotokoll (MCP), ein offener Standard, der es Agenten ermöglicht, eine universelle Verbindung zu Datenquellen herzustellen. TrueFoundry wurde wie folgt konzipiert MCP-nativ, das als neutraler Hub fungiert, über den ein Agent gleichzeitig eine Verbindung zu einem Google Drive-MCP-Server, einer lokalen Postgres-Datenbank und einer AWS Lambda-Funktion herstellen kann, ohne dass benutzerdefinierte Infrastruktur-Wrapper erforderlich sind.

TrueFoundry: Die Steuerebenenarchitektur

TrueFoundry schlägt eine vor Kontrollebene Architektur. Anstatt das Modell, die Laufzeit und die Tools in einem einzigen vertikalen Cloud-Dienst zu bündeln, werden sie bei diesem Ansatz entkoppelt.

Hier fungiert der Cloud-Anbieter (AWS, Azure, GCP) als skalierbares Backend für Berechnungen und Modelle, während das TrueFoundry Gateway die steuerbare Schnittstelle für Anwendungen bleibt.

Routing und Wirtschaftlichkeit

Ein entscheidendes Merkmal von Bedrock Agents ist die architektonische Bindung an Bedrock-Modelle (Titan, Claude, Llama on Bedrock). Komplexe Agenten führen viele Schritte aus, und verwenden dabei ein High-End-Modell wie Claude 3.5 Sonett denn jeder Schritt einer rekursiven Schleife kann die Kosten in die Höhe treiben.

TrueFoundry erleichtert semantisches Routing. Das Gateway analysiert die Komplexität eines Schritts; wenn der Agent lediglich ein Datum aus einer Zeichenfolge extrahieren muss, leitet die Anfrage an ein kostengünstigeres Modell weiter (wie Meta Lama) gehostet auf AWS-Spot-Instanzen. Wenn der Schritt eine komplexe Argumentation erfordert, wird er zu GPT-4o oder Claude 3.5 Opus weitergeleitet.

Abbildung 2: Die Routing-Logik von TrueFoundry optimiert die Wirtschaftlichkeit der Einheiten, indem sie die Komplexität der Aufgaben an den kostengünstigsten Anbieter anpasst.

Vergleich der Funktionen: Managed Service und Control Plane

In dieser Tabelle werden die Funktionen des von AWS verwalteten Services der TrueFoundry-Steuerungsebene gegenübergestellt.

Das Argument der hybriden Infrastruktur

Für viele Unternehmen ist die Zukunft nicht „All-In on AWS“ oder „All-In on Azure“, sondern ein hybrider Zustand, der von der Schwere der Daten und den Kosten bestimmt wird.

AgentCore zeichnet sich dadurch aus, dass der gesamte Lebenszyklus der Daten — von der Erfassung bis zur Inferenz — in AWS stattfindet. Da agentische Workflows jedoch immer größer werden, benötigen sie häufig Zugriff auf Daten in Microsoft SharePoint, auf Customer Data Platforms in der Google Cloud oder auf lokalen Warehouses.

TrueFoundry ermöglicht eine Cloud-übergreifendes Routing-Muster. Die Logik des Agenten befindet sich in der Steuerungsebene und ermöglicht es ihm, auf Tools in verschiedenen Clouds zuzugreifen, ohne komplexe VPNs zu durchlaufen oder API-Gateways manuell zu konfigurieren. Dies macht den Stack zukunftssicher; wenn Azure OpenAI-Dienst veröffentlicht ein neues Modell, das Claude übertrifft, oder wenn Llama 3 für einen bestimmten Anwendungsfall praktikabel wird, ist das Umschalten der zugrunde liegenden Engine eher eine Konfigurationsänderung als eine Codeumschreibung.

Abbildung 3: Die TrueFoundry-Routing-Architektur ermöglicht den cloudübergreifenden Datenzugriff.

Zusammenfassung der Empfehlung

Die Wahl zwischen dem von AWS verwalteten Service und der TrueFoundry-Steuerungsebene ist praktisch eine Wahl zwischen Geschwindigkeit der Integration und architektonische Optionalität.

• Standardisieren Sie auf AWS Bedrock Agents, wenn: Ihr Entwicklungsteam ist klein, die Anwendungslogik besteht hauptsächlich aus AWS Lambda-Funktionen, und es ist nicht erforderlich, Modelle außerhalb des Bedrock-Portfolios zu verwenden.
• Wählen Sie TrueFoundry, wenn: Sie bauen eine Plattform auf, die mehrere interne Teams mit unterschiedlichen Bedürfnissen bedienen muss. Sie benötigen eine zentrale Governance, um Budgets und Sicherheitsrichtlinien in AWS und Azure zu verwalten, oder Sie beabsichtigen, Open-Source-Modelle auf Spot-Instances zu nutzen, um die Wirtschaftlichkeit hochvolumiger Agenten-Workloads zu kontrollieren.

‍