Konzeptioneller Unterschied Funktionsraster Verwandte Themen

AgentCore Harness im Vergleich zu Runtime

AgentCore Harness und AgentCore Runtime lösen verschiedene Teile desselben Problems. Diese Seite erklärt den konzeptionellen Unterschied und bietet einen Vergleich der einzelnen Funktionen, um Ihnen die Auswahl zu erleichtern.

Konzeptioneller Unterschied

AgentCore Runtime ist eine serverlose Hosting-Umgebung. Sie bringen Agentencode — geschrieben in einem beliebigen Framework oder ohne Framework — mit dem BedrockAgentCoreApp Einstiegspunkt des AgentCore SDK ein, packen ihn in einen ARM64-Container, übertragen ihn an Amazon ECR und stellen ihn bereit. Die Orchestrierungsschleife gehört Ihnen. Um ein anderes AgentCore Primitiv (Memory, Gateway, Browser, Code Interpreter, Outbound Identity) zu verwenden, rufen Sie es von Ihrem Code aus auf, normalerweise über das SDK. AgentCore Runtime stellt die Infrastruktur bereit — Isolierung, Skalierung, Sitzungen, Auth Gating und Observability Plumbing —, während die Agentenlogik der Code ist, den Sie schreiben.

AgentCore Harness ist ein verwaltetes Agenten-Harness — die Orchestrierungsschleife selbst wird bereitgestellt und von Strands Agents unterstützt. Sie deklarieren den Agenten (Modell, Systemaufforderung, Tools, Arbeitsspeicher, Grenzwerte) als Konfiguration und AgentCore führen den Loop aus. Bei den meisten Funktionen handelt es sich um ein einzelnes Konfigurationsfeld: Das Wechseln eines Modells oder das Hinzufügen eines Tools ist eine Änderung der Konfiguration, keine erneute Bereitstellung. Der Harness ist eine verwaltete Abstraktion, die innerhalb von Runtime ausgeführt wird und Harness-Operationen CloudTrail unter aufzeichnet. AWS::BedrockAgentCore::Runtime

Für fast jedes Feature ist das Muster dasselbe:

Harness — Konfiguration, kein Code.
Runtime — Sie schreiben Code, normalerweise mit dem AgentCore SDK und Ihrem Framework.

In der Tabelle unten sind die Ausnahmen pro Feature explizit aufgeführt.

Funktionsraster

Das Unterstützte? In den Spalten wird die folgende Legende verwendet:

✅ - Wird unterstützt, ohne dass ein benutzerdefinierter Code erforderlich ist.
🔵 - Wird unterstützt, aber Sie müssen Ihre eigene Implementierung beibehalten.
🟣 - Die Konfiguration ermöglicht es, aber Code ist erforderlich, um es vollständig nutzen zu können.
❌ - Wird nicht unterstützt.

Merkmal/Fähigkeit	Harness: unterstützt?	Gurtzeug: Kundencode erforderlich?	Laufzeit: unterstützt?	Runtime: Kundencode erforderlich?
Modellauswahl (Bedrock/OpenAI/Gemini/LiteLLM)	✅	Nein	🔵	Ja
Wechseln Sie während der Sitzung den Modellanbieter	✅	Nein	🔵	Ja
Built-in Shell und Tools `file_operations`	✅	Nein	🔵	Ja
Fähigkeiten der Agenten	✅	Nein	🔵	Ja
Beobachtbarkeit	✅	Nein	🔵	Ja
AgentCore Gedächtnis — kurzfristig	✅	Nein	🔵	Ja
AgentCore Langzeitgedächtnis (Semantik, Zusammenfassung, Benutzerpräferenz, episodisch)	✅	Nein	🔵	Ja
Per-user Speicherbereich (Akteurs-ID)	✅	Nein	🔵	Ja
AgentCore Gateway	✅	Nein	🔵	Ja
AgentCore Browser	✅	Nein	🔵	Ja
AgentCore Code-Interpreter	✅	Nein	🔵	Ja
MCP-Servertools (remote)	✅	Nein	🔵	Ja
Inline-/clientseitige Tools	🔵	Ja	🔵	Ja
Context-window Kürzung	✅	Nein	🔵	Ja
Benutzerdefiniertes Container-Image /Umgebung	🟣	Gemischt	🟣	Gemischt
Ausführungsbeschränkungen (`maxIterations`,`timeoutSeconds`,`maxTokens`, idle/lifetime)	✅	Nein	🔵	Ja
Dateisystem — vom Dienst verwalteter Sitzungsspeicher	✅	Nein	✅	Nein
Dateisystem - EFS-Zugriffspunkt	✅	Nein	✅	Nein
Dateisystem — Zugriffspunkt für S3-Dateien	✅	Nein	✅	Nein
Umgebungsvariablen	✅	Nein	✅	Nein
Direkte Ausführung von Shell-Befehlen (`InvokeAgentRuntimeCommand`API)	✅	Nein	✅	Nein
Eingehende Authentifizierung — IAM (SigV4)	✅	Nein	✅	Nein
Eingehende Authentifizierung — OAuth	✅	Nein	✅	Nein
Ausgehende Authentifizierung//Identitätstoken-Tresor (OAuth- und API-Schlüssel)	✅	Nein	🔵	Ja
Isolierung von Sitzungen	✅	Nein	✅	Nein
VPC-Netzwerke	✅	Nein	✅	Nein
Streaming-Antworten	✅	Nein	🔵	Ja
Versionierung und Endpunkte	✅	Nein	✅	Nein
Wahl des Agenten-Frameworks	❌	N/A	🔵	Ja
Bidirektionales Streaming	❌	N/A	🔵	Ja
Non-agent-loop Muster (Grafik, Workflow-Stil)	❌	N/A	🔵	Ja
Hook	❌	N/A	🔵	Ja