Zum Hauptinhalt springen
Das Agent SDK spawnt und überwacht einen claude CLI-Subprocess, der eine Shell, ein Arbeitsverzeichnis und Sitzungsdateien auf der Festplatte besitzt. Das Hosting unterscheidet sich vom Hosting eines zustandslosen API-Wrappers. Jeder laufende Agent ist ein langlebiger Prozess, der an lokalen Zustand gebunden ist, was beeinflusst, wie Sie Ressourcen zuordnen, Sitzungen persistieren und über Mandanten skalieren. Diese Seite behandelt das Self-Hosting auf Ihrer eigenen Infrastruktur: verstehen Sie das Subprocess-Modell, wählen Sie ein Sitzungsmuster, stellen Sie den Container bereit und behandeln Sie Produktionsbedenken wie Persistenz, Observability, Authentifizierung und Multi-Tenant-Isolation. Für bereitstellbare Dockerfiles und Kubernetes-Manifeste siehe das Hosting-Cookbook. Wenn Sie keine Infrastrukturkontrolle, benutzerdefinierte Isolation oder Ihre eigene Datenebene benötigen, erwägen Sie stattdessen Managed Agents: eine gehostete REST-API, bei der Anthropic den Agent und die Sandbox ausführt, sodass Ihre Anwendung Ereignisse sendet und Ergebnisse zurückstreamt, ohne dass Sie eine Hosting-Infrastruktur betreiben müssen.
Für Sicherheitshärtung über grundlegendes Sandboxing hinaus, einschließlich Netzwerkkontrollen, Verwaltung von Anmeldedaten und Isolationsoptionen, siehe Sichere Bereitstellung.

Das Subprocess-Modell

Jede Hosting-Entscheidung auf dieser Seite folgt aus der Art und Weise, wie das SDK den Agent ausführt. Wenn Ihr Code query() aufruft, spawnt das SDK einen separaten claude CLI-Prozess und kommuniziert mit ihm über stdio. Dieser Subprocess besitzt die Shell, das Arbeitsverzeichnis und die JSONL-Sitzungstranskripte auf der lokalen Festplatte. Request-Fluss: Client zu Ihrer App, die einen claude CLI-Subprocess über stdio im Container spawnt; der Subprocess schreibt auf die lokale Festplatte und ruft api.anthropic.com über HTTPS auf Eine Agent-Sitzung wird einer Subprocess zugeordnet. Das Ausführen von N gleichzeitigen Sitzungen bedeutet N Subprozesse, jeder mit seinem eigenen Prozessbaum und einer Transkriptdatei. Standardmäßig erben sie alle das Arbeitsverzeichnis Ihrer Anwendung. Übergeben Sie daher cwd bei jedem query()-Aufruf, wenn Sitzungen separate Dateisysteme benötigen:
query({ prompt, options: { cwd: "/work/session-a" } })

Status, der auf der lokalen Festplatte gespeichert ist

Drei Arten von Agent-Status befinden sich standardmäßig im Dateisystem des Containers. Keine von ihnen überlebt einen Container-Neustart, ein Scale-Down oder einen Wechsel zu einem anderen Knoten.
StatusStandardort
Sitzungstranskripte~/.claude/projects/, oder das Verzeichnis projects/ unter CLAUDE_CONFIG_DIR, falls gesetzt
CLAUDE.md Speicherdateien~/.claude/CLAUDE.md für die Benutzerebene und das Arbeitsverzeichnis der Sitzung für die Projektebene
Arbeitsverzeichnis-ArtefakteDas Arbeitsverzeichnis der Sitzung
Um Transkripte über Hosts hinweg zu persistieren, konfigurieren Sie einen SessionStore-Adapter. Speicherdateien und andere Arbeitsverzeichnis-Artefakte benötigen ihre eigene Speicherstrategie, wie z. B. ein bereitgestelltes Volume oder eine Objektspeicher-Synchronisierung. Informationen dazu, wie Sitzungen, Wiederaufnahme und Forking auf API-Ebene funktionieren, finden Sie unter Sitzungen.

Wählen Sie ein Sitzungsmuster

Diese vier Muster decken den Sitzungslebenszyklus ab: wie lange ein Container im Verhältnis zu den Sitzungen, die er bedient, existiert. Für den Ort, an dem der Container ausgeführt wird, hat das Hosting-Kochbuch bereitstellbaren Code für lokales Docker, Modal und Kubernetes. Wählen Sie hier ein Sitzungsmuster und ein Bereitstellungsziel aus dem Kochbuch.

Ephemere Sitzungen

Erstellen Sie einen Container für jede Benutzeraufgabe und zerstören Sie ihn, wenn die Aufgabe abgeschlossen ist. Am besten für einmalige Aufgaben. Der Benutzer kann möglicherweise noch mit der KI interagieren, während die Aufgabe abgeschlossen wird, aber nach Abschluss wird der Container zerstört. Beispielworkloads umfassen Fehleruntersuchung und -behebung, Rechnungs- und Belegextraktion, Dokumentenübersetzung und Medientransformation. Der Container führt einen einmaligen Einstiegspunkt aus, der das SDK aufruft und beendet wird. Das folgende Beispiel zeigt eine minimale TypeScript-Version. Speichern Sie es als entrypoint.mts oder setzen Sie "type": "module" in package.json, damit await auf oberster Ebene verfügbar ist.
import { query } from "@anthropic-ai/claude-agent-sdk";

const prompt = process.env.TASK_PROMPT!;
for await (const message of query({ prompt, options: { maxTurns: 20 } })) {
  console.log(message);
}

Langfristige Sitzungen

Führen Sie persistente Container-Instanzen aus, die häufig mehrere SDK-Prozesse pro Container hosten, um laufende Arbeiten zu bedienen. Am besten für Agenten, die autonome Maßnahmen ergreifen, Inhalte bereitstellen oder hochvolumige Nachrichtenströme verarbeiten. Beispielworkloads umfassen einen E-Mail-Agenten, der eingehende Post sortiert und beantwortet, einen Website-Builder, der eine pro Benutzer bearbeitbare Website über Container-Ports hostet, und einen Chatbot, der kontinuierlichen Datenverkehr von einer Plattform wie Slack verarbeitet. Der Container stellt einen HTTP- oder WebSocket-Endpunkt bereit und ordnet jede aktive Sitzung einer langlebigen Abfrage und dem dahinter liegenden Unterprozess zu. In TypeScript verwenden Sie streamInput(), um Züge zu einer aktiven Sitzung hinzuzufügen, und startup(), um Unterprozesse vor eingehendem Datenverkehr vorzuwärmen. In Python verwenden Sie ClaudeSDKClient, um eine Sitzung über Züge hinweg offen zu halten. Dimensionieren Sie den Container so, dass er die maximale Anzahl gleichzeitiger Sitzungen im Speicher halten kann.

Hybrid-Sitzungen

Ephemere Container, die beim Start aus einem SessionStore rehydriert werden und Updates zurück persistieren. Am besten für Sitzungen, die viele Interaktionen umfassen, aber zwischen ihnen untätig sind. Der Container wird während Leerlaufperioden heruntergefahren und wieder hochgefahren, wenn der Benutzer zurückkehrt. Beispielworkloads umfassen einen persönlichen Projektmanager mit gelegentlichen Check-ins, tiefe Recherche, die über Stunden pausiert und fortgesetzt wird, und einen Kundenservice-Agenten, der die Tickethistorie über Interaktionen hinweg lädt. Stimmen Sie das Leerlauf-Timeout Ihres Anbieters darauf ab, wie häufig Sie erwarten, dass Benutzer zurückkehren. Das Herunterfahren eines Containers ohne konfiguriertes SessionStore verliert das Transkript damit, daher ist der Store für dieses Muster erforderlich, nicht optional. Das Muster basiert auf der Wiederaufnahme einer Sitzung nach ID mit einem angehängten gemeinsamen Store:
import { query, type SessionStore } from "@anthropic-ai/claude-agent-sdk";

declare const userInput: string;
declare const sessionId: string;          // looked up from your database by user
declare const sessionStore: SessionStore; // S3, Redis, Postgres, or your own adapter

for await (const message of query({
  prompt: userInput,
  options: { resume: sessionId, sessionStore },
})) {
  // ...
}
Siehe Sitzungsspeicher für die vollständige SessionStore-Schnittstelle und Referenzadapter.

Multi-Agent-Container

Führen Sie mehrere SDK-Unterprozesse in einem Container aus. Am besten für Agenten, die eng zusammenarbeiten müssen, beispielsweise Multi-Agent-Simulationen, bei denen die Agenten in einer gemeinsamen Umgebung miteinander interagieren. Geben Sie jedem Agenten sein eigenes Arbeitsverzeichnis, damit sie die Dateien des anderen nicht überschreiben, und isolieren Sie das Einstellungsladen, damit pro-Agent CLAUDE.md-Dateien nicht über Agenten hinweg durchsickern. Siehe Multi-Tenant-Isolation für die spezifischen Optionen.

Container bereitstellen

Container-basiertes Sandboxing

Führen Sie das SDK in einem sandboxierten Container aus, um Prozessisolation, Ressourcenlimits, Netzwerkkontrolle und ein kurzlebiges Dateisystem zu erreichen. Mehrere Anbieter spezialisieren sich auf sandboxierte Container-Umgebungen, die zum Modell des Agent SDK passen. Fragen, die Sie bei der Wahl eines Anbieters beantworten sollten:
  • Wer betreibt die Sandbox: Ein Sandbox-as-a-Service-Anbieter betreibt die Infrastruktur für Sie, während selbst gehostete Optionen Ihnen Software zur Verfügung stellen, die Sie auf Ihren eigenen Systemen ausführen können.
  • Cold-Start-Latenz: Wie lange dauert es von „Sandbox erstellen” bis „bereit, die erste Anfrage zu akzeptieren”. Kurzlebige Muster benötigen Sub-Sekunden-Starts. Langfristige Muster tolerieren mehr.
  • Persistenter Speicher: Ob der Anbieter dauerhafte Volumes oder nur kurzlebige Festplatte anbietet. Das Hybrid-Muster benötigt dauerhaften Speicher irgendwo, ob in der Sandbox oder daneben.
  • Preismodell: Pro-Sekunde, Pro-Anfrage oder pauschale stündliche Abrechnung. Pro-Sekunde-Preisgestaltung eignet sich für bursty kurzlebige Workloads. Stündlich eignet sich für langfristige Sitzungen.
  • Netzwerk: Unterstützung für benutzerdefinierte Egress-Regeln, ausgehende Proxys und privates VPC-Peering für regulierte Umgebungen.
Anbieter zur Evaluierung: Für selbst gehostete Optionen wie Docker, gVisor und Firecracker sowie detaillierte Isolationskonfiguration siehe Isolationstechnologien.

Laufzeit-Abhängigkeiten

Der Container benötigt nur die Laufzeit Ihres SDK:
  • Python 3.10+ für das Python SDK oder Node.js 18+ für das TypeScript SDK
  • Beide SDK-Pakete enthalten eine native Claude Code-Binärdatei für die Host-Plattform, daher ist keine separate Claude Code- oder Node.js-Installation für die erzeugte CLI erforderlich
Die gebündelte Binärdatei ist an die SDK-Paketversion gebunden, daher ist das Aktualisieren des SDK die Methode zum Aktualisieren der CLI. Das SDK folgt semver: Nehmen Sie Patch-Releases kontinuierlich an und überprüfen Sie das TypeScript- oder Python-Changelog, bevor Sie ein Minor-Release annehmen.

Ressourcen

1 GiB RAM, 5 GiB Festplatte und 1 CPU pro Agent ist ein angemessener Ausgangspunkt für eine neu gestartete Instanz. Der Speicherverbrauch wächst mit der Sitzungsdauer und der Tool-Aktivität, daher sollten Sie für die Sitzungslängen und Parallelität dimensionieren, die Sie tatsächlich benötigen, anstatt für die untätige Baseline. Siehe Skalierung und Parallelität, um zu erfahren, wie Sie Agents pro Host berechnen.

Netzwerk

Das SDK benötigt ausgehende HTTPS zu api.anthropic.com oder zu Ihrem regionalen Endpunkt des Anbieters, wenn Sie auf Bedrock oder Vertex ausführen. Wenn Ihre Agents MCP-Server oder externe Tools verwenden, benötigen sie auch ausgehenden Zugriff auf diese Endpunkte. Für die Produktion leiten Sie ausgehenden Datenverkehr durch einen Egress-Proxy, der Domain-Allowlists durchsetzt, Anmeldeinformationen injiziert und Anfragen protokolliert. Siehe Sichere Bereitstellung für das vollständige Muster. Für eingehenden Datenverkehr stellen Sie einen HTTP- oder WebSocket-Port auf dem Container bereit. Ihre Anwendung verarbeitet Client-Anfragen auf diesem Port und ruft das SDK intern auf; der Unterprozess selbst lauscht nicht im Netzwerk.

Produktionsbedenken behandeln

Arbeiten Sie diese Entscheidungen durch, bevor Sie einen selbstgehosteten Agenten bereitstellen.

Sitzungs- und Zustandspersistenz

Der standardmäßige lokale Datenträger geht bei Neustart, Herunterskalierung oder Verschiebung auf einen anderen Knoten verloren. Für jede Sitzung, die ein Benutzer fortsetzen möchte, spiegeln Sie das Transkript mit einem SessionStore-Adapter auf dauerhaften Speicher. Siehe Referenzimplementierungen für S3-, Redis- und Postgres-Adapter sowie eine Konformitätssuite für Ihre eigenen. Drei Dinge, die Sie über das Verhalten von SessionStore wissen sollten:
  • Nur Transkripte: SessionStore spiegelt Transkripte, nicht CLAUDE.md-Speicherdateien oder andere Arbeitsverzeichnis-Artefakte. Mounten Sie ein gemeinsames Volume oder synchronisieren Sie diese separat.
  • Spiegelung, keine Ersetzung: Der Unterprozess schreibt zuerst auf die lokale Festplatte, und der Store erhält eine Kopie jedes Batches. Lokale Schreibvorgänge bleiben maßgeblich.
  • mirror_error-Meldungen: Wenn der Store ablehnt oder eine Zeitüberschreitung auftritt, gibt das SDK eine { type: "system", subtype: "mirror_error" }-Meldung aus und setzt die Abfrage ohne Wiederholung fort. Warnen Sie vor diesen, wenn die Store-Dauerhaftigkeit wichtig ist.

Observability

Agent SDK-Agenten sind langlebige Prozesse, die Werkzeugaufrufe über viele API-Roundtrips hinweg spawnen. Ohne Telemetrie können Sie nicht sehen, welche Werkzeuge ausgeführt wurden, wie lange sie dauerten oder wo eine Sitzung stecken blieb. Das SDK erbt die OpenTelemetry-Konfiguration aus der Umgebung. Legen Sie die OTEL-Umgebungsvariablen auf Container- oder Orchestrator-Ebene fest, damit jeder query()-Aufruf Spans, Metriken und Log-Ereignisse an Ihren Collector exportiert. Das folgende Beispiel aktiviert OTLP-Export für alle drei Signale. CLAUDE_CODE_ENHANCED_TELEMETRY_BETA ist nur für Traces erforderlich; lassen Sie es weg, wenn Sie nur Metriken und Logs exportieren.
".env'
CLAUDE_CODE_ENABLE_TELEMETRY=1
CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1
OTEL_TRACES_EXPORTER=otlp
OTEL_METRICS_EXPORTER=otlp
OTEL_LOGS_EXPORTER=otlp
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.example.com:4318
Eingabetext und Werkzeugeingaben sind standardmäßig nicht in Exporten enthalten. Siehe Sensible Daten in Exporten steuern für die Opt-in-Flags und Observability für den vollständigen Signalkatalog.

Authentifizierung und Geheimnisse

Drei Authentifizierungsbedenken sind zum Zeitpunkt des Hostings wichtig:
  • Anthropic API: Der Unterprozess liest ANTHROPIC_API_KEY aus seiner Umgebung. Stellen Sie es von Ihrem Secret Manager bereit, oder setzen Sie ANTHROPIC_BASE_URL, um Modellaufrufe durch einen Proxy zu leiten, der den Schlüssel außerhalb des Containers injiziert. Siehe Credential Management für das Proxy-Muster und SDK-Übersicht für unterstützte Authentifizierungsmethoden.
  • Eingehend: Setzen Sie Authentifizierung an einem Gateway vor dem Agent-Container. Der Agent sollte vorauthentifizierte Anfragen erhalten und sollte nicht die Komponente sein, die Benutzer-Token validiert.
  • Ausgehende Werkzeuge: Halten Sie Werkzeug-Anmeldedaten aus der Agent-Umgebung. Leiten Sie ausgehende Aufrufe durch einen Proxy, der API-Schlüssel injiziert, nachdem die Anfrage den Container verlässt. Der Agent tätigt den Aufruf; der Proxy fügt die Anmeldedaten hinzu.

Skalierung und Parallelität

Jede Sitzung läuft in ihrem eigenen Unterprozess, daher ist die Parallelität auf einem Host durch die Anzahl der Unterprozesse begrenzt, die sein RAM halten kann. Dimensionieren Sie jeden Host mit dieser Formel:
Agenten pro Host = (Host-RAM - Overhead) / (RAM-Obergrenze pro Sitzung)
Messen Sie die RAM-Obergrenze pro Sitzung, indem Sie eine repräsentative Sitzung bis zu Ihrer Zieldauer unter Ihrer erwarteten Werkzeuglast ausführen und den Peak-RSS aufzeichnen. Der 1-GiB-Startpunkt in Ressourcen ist ein Minimum, nicht die Obergrenze. Horizontal-Skalierungs-Routing hängt von Ihrem Muster ab. Für lang laufende Sitzungen, bei denen Container viele Sitzungen halten, führen Sie einen Pool von Containern hinter einem Load Balancer aus und heften Sie jede Sitzung mit konsistentem Hashing auf sessionId an einen Container. Eine angeheftete Sitzung trifft immer wieder auf denselben Container und daher auf denselben laufenden Unterprozess, bis er entfernt oder der Container neu gestartet wird. Große Fanouts von gleichzeitigen Subagenten aus einer einzelnen Sitzung können API-Ratenlimits treffen. Teilen Sie die Arbeit in kleinere Batches auf, anstatt eine breite Verteilung auszugeben.

Kosten

Die Anthropic-Token-Kosten dominieren typischerweise die Container-Infrastrukturkosten um eine Größenordnung oder mehr. Ein minimal bereitgestellter Container läuft ungefähr $0,05 pro Stunde, während eine einzelne lange Agent-Sitzung Dollar in Token ausgeben kann. Siehe Kostenverfolgung für Token-Buchhaltung pro Sitzung.

Multi-Tenant-Isolation

Das standardmäßige SDK-Verhalten liest Einstellungen und CLAUDE.md-Speicherdateien aus dem Dateisystem. In einem gemeinsamen Container, der mehrere Mandanten bedient, können diese Dateien den Kontext eines Mandanten in die Sitzung eines anderen Mandanten durchsickern lassen. Um Mandanten in einem gemeinsamen Container zu isolieren:
  • Übergeben Sie settingSources: [] in TypeScript oder setting_sources=[] in Python, damit keine Dateisystem-Einstellungen geladen werden.
  • Setzen Sie CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 in env. Auto Memory bei ~/.claude/projects/<project>/memory/ wird unabhängig von settingSources in den System-Prompt geladen. Siehe Was settingSources nicht steuert für die anderen Eingaben, die bedingungslos geladen werden.
  • Zeigen Sie CLAUDE_CONFIG_DIR auf ein mandantenspezifisches Verzeichnis, damit Mandanten die globale Konfiguration ~/.claude.json nicht teilen.
  • Verwenden Sie ein mandantenspezifisches Arbeitsverzeichnis. Übergeben Sie cwd explizit bei jedem query()-Aufruf.
  • Wenden Sie mandantenspezifische Egress-Regeln bei Ihrem Proxy an, wie z. B. unterschiedliche ausgehende IPs, Anmeldedaten oder Domain-Allowlists, damit ein kompromittierter Mandant keine Daten über die ausgehende Richtlinie eines anderen Mandanten exfiltrieren kann.
Das folgende Beispiel wendet die vier SDK-Ebenen-Optionen zusammen an. Konstruieren Sie tenantDir und configDir so, dass jeder Mandant einen Pfad erhält, den kein anderer Mandant lesen kann. In TypeScript ersetzt env die Unterprozess-Umgebung, daher verteilen Sie ...process.env, um geerbte Variablen wie PATH und ANTHROPIC_API_KEY zu behalten. In Python wird env auf die geerbte Umgebung zusammengeführt.
import { query } from "@anthropic-ai/claude-agent-sdk";

declare const prompt: string;
declare const tenantDir: string;
declare const configDir: string;

for await (const message of query({
  prompt,
  options: {
    cwd: tenantDir,
    settingSources: [],
    env: {
      ...process.env,
      CLAUDE_CONFIG_DIR: configDir,
      CLAUDE_CODE_DISABLE_AUTO_MEMORY: "1",
    },
  },
})) {
  // ...
}
Für mandantenspezifische Netzwerkkontrollen siehe Sichere Bereitstellung.

Bekannte Einschränkungen

Berücksichtigen Sie diese in Ihrem Bereitstellungsdesign.
EinschränkungWas zu tun ist
Kein Sitzungs-Timeout auf oberster EbeneEine Sitzung läuft nicht automatisch ab. Legen Sie maxTurns in Options fest, um zu begrenzen, wie viele Tool-Use-Rundläufe der Agent durchführt, bevor er stoppt.
Speicherwachstum über lange SitzungenBegrenzen Sie die Sitzungslänge oder recyceln Sie Subprozesse regelmäßig. Siehe Skalierung und Parallelität.
Große parallele Subagent-Ausfächerungen können Ratenlimits treffenTeilen Sie die Arbeit in kleinere Batches auf, anstatt eine breite Verteilung auszugeben.
Keine Wanduhr-Frist pro SubagentBegrenzen Sie jeden Subagent mit maxTurns in seiner AgentDefinition. Nur für Hintergrund-Subagenten setzt CLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS einen Stall-Watchdog, der aktiviert wird, wenn ein run_in_background-Subagent keine Ausgabe mehr produziert; dies ist keine Gesamtlaufzeit-Frist.

Nächste Schritte