Unterschiede zum gehosteten Dienst
Sieh dir an, welche Funktionen nur selbst gehostetes Claude Managed Agents hat, welche gehosteten Funktionen ihm fehlen, welche sich anders verhalten und welche zuerst eine Server-Einstellung brauchen.
Ein selbst gehosteter Claude Managed Agents-Server hat dieselbe API wie Anthropics gehosteter Managed Agents-Dienst, abgesehen von den Unterschieden auf dieser Seite. Die Tabellen sagen, was du jeweils tun kannst. Prüfe sie, bevor du eine Anwendung auf deinen Server verlagerst. Aus dem gehosteten Dienst wird nichts kopiert, auch nicht der Sitzungsverlauf. Erstelle deine Agenten, Skills, Vault-Anmeldedaten und Memory Stores auf deinem Server neu.
Funktionen, die nur dein Server hat
| Funktion | Was sie tut | Wie du sie einrichtest |
|---|---|---|
| Eine Auswahl an Inferenzanbietern | Der Server kann Modellaufrufe statt an die Claude API an einen Cloud-Anbieter oder dein eigenes Modell-Gateway senden. | Inferenzanbieter |
| Single Sign-on | Personen rufen den Server mit einem Token von deinem OpenID Connect-Identitätsanbieter auf. Der Server weist jedem Aufrufer anhand der Gruppen im Token eine Rolle zu. Der Server-API-Key funktioniert weiterhin. | Single Sign-on |
| Dein eigener Secret-Manager | Der Server kann das Secret aller neuen Vault-Anmeldedaten statt in seiner eigenen Datenbank in deinem Secret-Manager speichern. | Secret-Manager |
| Agentenidentität | Der Server kann ein kurzlebiges Token signieren und es mit den Aufrufen eines Agenten an einen MCP-Server senden. Der MCP-Server oder das Gateway prüft das Token anhand öffentlicher Schlüssel, die du veröffentlichst. | Agentenidentität |
Funktionen, die nicht verfügbar sind
| Funktion | Was passiert | Was du stattdessen tun kannst |
|---|---|---|
| Cloud-Umgebungen | Es gibt nur self_hosted-Umgebungen. Eine Anfrage für eine Cloud-Umgebung gibt einen 400-Fehler zurück. | Stelle für jede Umgebung selbst gehostete Worker bereit. |
| Der Rest der Claude API, etwa die Messages API und die Models API | Der Server stellt ihn nicht bereit. Die Aufrufe des SDK an /v1/messages und /v1/models geben einen 404-Fehler zurück. | Sende diese Anfragen an die Claude API oder an deinen Anbieter, von einem Client aus, der nicht auf deinen Server zeigt. |
| Datei-Sitzungsressourcen sowie die Files API | Der Server lehnt file-Ressourcen ab, und /v1/files existiert nicht. memory_store-Ressourcen funktionieren. | Lege Dateien im Arbeitsverzeichnis des Workers ab. Siehe Daten in eine Sitzung hinein- und aus ihr herausbringen. Um dem Modell ein Bild oder ein PDF zu zeigen, sende es als base64 in einer Nachricht. |
mcp_oauth-Vault-Anmeldedaten | Der Server lehnt sie beim Erstellen ab, weil er keinen OAuth-Flow zum Aktualisieren eines Tokens hat. | Speichere das Token als static_bearer-Anmeldedaten. Aktualisiere die Anmeldedaten mit einem neuen Token, bevor das alte abläuft. |
Vorgefertigte docx-, pdf-, pptx- und xlsx-Skills | Der Server lehnt einen Agenten ab, der sie deklariert. Es gibt nur Skills, die du hochlädst. | Lade ihre Quellen aus dem Skills-Repository herunter und lade sie als benutzerdefinierte Skills hoch. |
| Geplante Deployments und Dreams | Der Server hat keine Routen dafür. | Starte Sitzungen über deinen eigenen Scheduler, etwa einen Cron-Job. Für Dreams gibt es keinen Ersatz. |
| Webhooks | Der Server sendet keine Webhooks, daher startet ein Worker, der auf einen Webhook hin startet, nie. | Verfolge eine Sitzung über ihren Event-Stream oder liste ihre Events auf. Lass deine Worker laufen, damit sie pollen können. |
Funktionen, die sich anders verhalten
| Funktion | Was anders ist | Was du tun kannst |
|---|---|---|
| Claude Console | Die Claude Console unter platform.claude.com zeigt nicht an, was sich auf deinem Server befindet. | Verwende die Console auf deinem Server. |
| Tool-Aufrufe | Die Modell-Turns einer Sitzung laufen auch dann, wenn kein Worker ihre Umgebung pollt. Der erste Tool-Aufruf wartet dann ohne Fehler, bis ein Worker ihn ausführt. | Wenn eine Sitzung bei einem Tool-Aufruf stehen bleibt, prüfe, ob ein Worker ihre Umgebung pollt. |
| Memory Stores | Die API ist vollständig. Der Worker, nicht der Server, kopiert jeden angehängten Store in die Sandbox und schreibt Änderungen zurück. Siehe Memory Stores in selbst gehosteten Sandboxes. | Führe deine Worker mit der neuesten Version von ant aus, mit einem beschreibbaren Verzeichnis /mnt/memory. |
| Uploads benutzerdefinierter Skills | Der Server entpackt kein ZIP-Archiv. Der Upload eines solchen Archivs gibt einen 400-Fehler mit der Meldung SKILL.md not found in uploaded files zurück. | ant apply und der Helper files_from_dir des Python SDK funktionieren unverändert. Bei allem anderen lade die Dateien des Skills als separate Teile hoch und beginne den Dateinamen jedes Teils mit dem Ordner des Skills, wie in my-skill/SKILL.md. |
| Multiagenten-Orchestrierung | Ein Agent kann nur an Subagenten delegieren, die du auflistest. Dynamische Workflows, der Advisor und Subagenten, die der Agent selbst definiert, sind nicht verfügbar. Der Server akzeptiert einen Block multiagent nur, wenn sein type den Wert coordinator hat. Die Beispiele in Multiagenten-Orchestrierung setzen type auf multiagent_20261001, was einen 400-Fehler zurückgibt. Ein Block mit einer Einstellung advisor gibt ebenfalls einen 400-Fehler zurück. | Setze multiagent auf {"type": "coordinator", "agents": [...]}. Liste 1 bis 20 Agenten in agents auf. Jeder Eintrag hat eine der Formen eines vordefinierten Agenten. |
| GitHub-Repository-Sitzungsressourcen | Der Server lehnt github_repository-Ressourcen ab, bis du ihre Git-Hosts in seinen Einstellungen auflistest. Der Server erkennt keine Skills im Verzeichnis .claude/skills eines Repositorys, daher hänge Skills an den Agenten an. | Siehe Git-Repositories brauchen einen Eintrag in der Allowlist. |
| MCP-Server | Der Server verbindet sich nur mit den MCP-Hosts, die du in seinen Einstellungen auflistest. | Siehe MCP-Server brauchen einen Eintrag in der Allowlist. |
| Web-Tools | Die Tools web_search und web_fetch sind deaktiviert, bis du sie in den Einstellungen des Servers aktivierst. | Siehe Web-Tools brauchen eine Server-Einstellung. |
environment_variable-Vault-Anmeldedaten | Der Server lehnt sie ab, bis du das Egress-Gateway aktivierst, einen Proxy zwischen deinen Sandboxes und dem Internet. | Siehe Umgebungsvariablen-Anmeldedaten. Ohne das Gateway stellst du deiner Sandbox die CLI- und API-Anmeldedaten, die sie braucht, über deine eigenen Tools bereit. |
| Ergebnisse benutzerdefinierter Tools | Der Server sendet dem Modell den gesamten Text eines Ergebnisses eines benutzerdefinierten Tools. Wenn ein Ergebnis für das Kontextfenster des Modells zu groß ist, antwortet der Server trotzdem mit 200, und die Sitzung endet dann mit einem session.error. | Kürze lange Ergebnisse in deinem Client, bevor du sie sendest. |
| Ergebnisse von MCP-Tools | Der Server kürzt ein Ergebnis, das größer ist als seine Einstellung mcp.max_result_bytes, die standardmäßig 100 KiB beträgt. Er teilt dem Modell mit, dass das Ergebnis gekürzt wurde, und der Rest geht verloren. Der gehostete Dienst kürzt lange Ergebnisse ebenfalls, kann aber für eine Sitzung in einer Cloud-Sandbox das vollständige Ergebnis in einer Datei speichern. | Um das Limit zu ändern, setze mcp.max_result_bytes in der Einstellungsdatei. |
| Per URL gesendete Bilder und Dokumente | Der Server akzeptiert einen image- oder document-Block mit einer url-Quelle, aber das Modell sieht ihn nie, und es gibt keinen Fehler. Dasselbe passiert mit einem image-Block mit einer file-Quelle. | Sende die Daten als base64 oder, bei einem Dokument, als text. |
Der Sitzungsstatus rescheduling | Der Server wiederholt einen Modellaufruf, der aus einem vorübergehenden Grund fehlschlägt, und meldet jeden Versuch im Event-Stream, wie es der gehostete Dienst tut. Der Status der Sitzung bleibt zwischen den Versuchen running, daher passt ein Filter statuses[]=rescheduling auf keine Sitzungen. | Lies Wiederholungsversuche aus dem Event-Stream. |
| Sitzungsmetadaten, mit einem Modell-Gateway | Wenn die Server-Einstellung inference.credentials.assertion.forward_metadata Schlüssel der Sitzungsmetadaten auflistet, gibt eine Aktualisierung, die einen davon hinzufügt, entfernt oder ändert, einen 400-Fehler zurück. | Setze diese Schlüssel, wenn du die Sitzung erstellst. Zur Einstellung siehe Kurzlebige Gateway-Tokens. |
Funktionen, die eine Server-Einstellung brauchen
Jede dieser Funktionen ist deaktiviert oder lehnt jeden Host ab, bis du die Einstellungsdatei des Servers änderst.
MCP-Server brauchen einen Eintrag in der Allowlist
Der Server verbindet sich nur mit MCP-Servern, deren Hosts du unter mcp.allowed_hostnames in seiner Einstellungsdatei auflistest:
mcp:
allowed_hostnames:
- mcp.example.comHosts müssen exakt übereinstimmen, ohne Wildcards und ohne Subdomains, und die Liste ist standardmäßig leer. Solange der Host eines MCP-Servers nicht auf der Liste steht, weigert sich dein Server, einen Agenten zu speichern, der ihn nennt.
Ein MCP-Server in deinem privaten Netzwerk braucht keinen MCP-Tunnel. Trage seine URL in die Agentendefinition ein, wie MCP-Connector beschreibt, und füge seinen Host der Allowlist hinzu. Für die URL gelten zwei Regeln:
- Sie muss
httpsverwenden, es sei denn, der MCP-Server befindet sich auf der Loopback-Adresse. - Wenn ihr Host ein Name ist, der nur auf private oder reservierte Adressen aufgelöst wird, verweigert dein Server standardmäßig die Verbindung. Wähle die Lösung, die zu deinem Fall passt:
| Dein Fall | Lösung |
|---|---|
Die Adresse liegt in 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16, und du kontrollierst die DNS-Einträge des Namens | Behalte den Namen bei und liste ihn außerdem unter mcp.private_hostnames in der Einstellungsdatei auf. |
| Jeder andere Fall | Verwende die IP-Adresse anstelle des Namens, in der URL und auf der Allowlist. Das Zertifikat des MCP-Servers muss diese Adresse nennen. |
Git-Repositories brauchen einen Eintrag in der Allowlist
Beim gehosteten Dienst können Sitzungen, die selbst gehostete Sandboxes verwenden, keine github_repository-Ressourcen haben. Auf deinem Server können Sitzungen das. Der Server lehnt diese Ressourcen ab, bis du ihre Git-Hosts in seiner Einstellungsdatei auflistest. Agenten können nur auf die Branches pushen, die du auflistest:
git:
allowed_hostnames:
- github.com
allowed_push_refs:
- refs/heads/agent/Beachte diese Punkte:
- URL: Der Host muss nicht
github.comsein, aber die URL muss HTTPS verwenden. - Token: Das Token, das dein Client sendet, erreicht die Sandbox nie, weil der Git-Verkehr über deinen Server läuft, der das Token hinzufügt.
- Branches: Agenten wird die Liste der Branches nicht mitgeteilt, daher nenne einen Branch in deinem Prompt.
- Force-Pushes: Der Server lehnt Force-Pushes nicht ab, daher kann ein Agent jeden Branch überschreiben, den du auflistest. Um Force-Pushes abzulehnen, schütze den Branch auf deinem Git-Host.
Zugriff auf GitHub zeigt die Anfrage und wie du ein Token rotierst. Wenn ein Klonen fehlschlägt, erhält die Sitzung ein session.error-Event, das die Ursache nennt. Um einen Push zu prüfen, suche den Branch auf deinem Git-Host. Das Log des Servers meldet ok, selbst bei einem Push, den dein Host abgelehnt hat.
Web-Tools brauchen eine Server-Einstellung
Die Tools web_search und web_fetch sind standardmäßig deaktiviert. Um sie zu aktivieren, füge Folgendes zur Einstellungsdatei des Servers hinzu:
web_tools:
enabled: trueMit dieser Einstellung allein gelten die eigenen Domainlisten und das eigene Inhaltslimit jedes Agenten, wie beim gehosteten Dienst.
Um die Tools für jeden Agenten einzuschränken, setze web_tools.allowed_domains, web_tools.blocked_domains oder web_tools.max_content_tokens. Jede dieser Einstellungen aktiviert die Tools außerdem. Der Server verweigert das Speichern eines Agenten, der mehr verlangt, als diese Einstellungen erlauben. Er verweigert zum Beispiel einen Agenten, der eine Domain außerhalb von web_tools.allowed_domains erlaubt oder ein größeres Inhaltslimit setzt. Wenn ein solcher Agent bereits existiert, kann er keine Sitzung starten, bis du ihn aktualisierst.
Solange die Tools deaktiviert sind, hängt das, was mit einem Agenten passiert, von den Einträgen für web_search und web_fetch in seinem Toolset ab:
| Das Toolset hat | Was passiert |
|---|---|
| Keinen Eintrag für eines der beiden Tools | Der Agent läuft ohne die Tools, und kein Fehler weist darauf hin. |
Einen Eintrag, der sein Tool nur deaktiviert, etwa {"name": "web_fetch", "enabled": false} | Dasselbe. |
| Einen Eintrag, der sein Tool aktiviert lässt oder seine Domainlisten, sein Inhaltslimit oder seinen Standort setzt | Der Server verweigert das Speichern des Agenten oder das Starten einer Sitzung für ihn. |
Welche Web-Tools es gibt, hängt außerdem von deinem Inferenzanbieter ab.
Unterschiede, die von deinem Inferenzanbieter abhängen
Einige Funktionen funktionieren nur bei bestimmten Werten der Server-Einstellung inference.provider. Die Tabelle zeigt, was bei den anderen Werten passiert. Einige dieser Fälle geben keinen Fehler zurück.
Die Zeilen für web_search und web_fetch gelten, nachdem du die Web-Tools aktiviert hast. Bis dahin funktioniert keines der beiden Tools bei irgendeinem Anbieter.
| Funktion | Funktioniert, wenn inference.provider folgenden Wert hat | Bei den anderen Werten | Was zu tun ist |
|---|---|---|---|
web_search-Tool | anthropic, vertex, foundry | Der Server bietet dem Modell das Tool nie an. Agenten werden weiterhin gespeichert und ausgeführt und listen das Tool weiterhin auf, aber das Modell kann es nicht aufrufen. | Gib dem Agenten ein benutzerdefiniertes Tool oder einen MCP-Server, der sucht. |
web_fetch-Tool | anthropic, foundry | Dasselbe wie bei web_search. | Gib dem Agenten ein benutzerdefiniertes Tool oder einen MCP-Server, der Seiten abruft. |
inference_geo | anthropic | Der Server verweigert das Speichern eines Agenten, der es setzt. | Entferne inference_geo aus dem Agenten. |
Fast Mode (speed: "fast") | Hängt vom Anbieter und vom Modell des Agenten ab | Ein Agent, der ihn setzt, muss zwei Prüfungen bestehen. Beim Speichern des Agenten: Der Modellkatalog des Servers muss das Modell des Agenten als eines auflisten, das den Fast Mode akzeptiert. Andernfalls verweigert der Server das Speichern des Agenten. Bei jedem Turn: Wenn der Anbieter den Fast Mode für dieses Modell oder Deployment nicht bereitstellt, endet der Turn mit einem Fehler. | Entferne speed aus dem Agenten. Siehe Modelle, die den Fast Mode akzeptieren. |
Bei anthropic fordert der Server standardmäßig das serverseitige Fallback der Claude API an. Wenn ein Sicherheitsklassifikator eine Anfrage ablehnt, kann dann ein anderes Claude-Modell, möglicherweise ein weniger leistungsfähiges, sie beantworten. Anthropic wählt das Modell aus, und kein Event meldet den Wechsel, aber beim Lesen der Sitzung wird die ID dieses Modells angezeigt. Um das Fallback zu deaktivieren, setze inference.model_fallback: false. Bei den anderen Anbietern beendet eine solche Anfrage den Turn mit einer Ablehnung.
In der Dokumentation deines Anbieters steht, welche Modelle und Regionen die einzelnen Funktionen unterstützen. Benutzerdefinierte Tools, MCP-Tools und die Tools, die dein Worker ausführt, sind bei jedem Anbieter gleich.
Modelle, die den Fast Mode akzeptieren
Standardmäßig listet der Modellkatalog des Servers vier Modelle als solche auf, die den Fast Mode akzeptieren: Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8 und Claude Opus 4.6. Bei Claude Opus 4.6 akzeptiert die Claude API die Anfrage, führt sie aber mit Standardgeschwindigkeit aus. Diese Werte von inference.provider sind Ausnahmen:
foundry: Der Katalog listet nur Claude Opus 5.5 auf.gatewaymitformat: vertex-raw-predict: Der Katalog listet kein Modell auf.vertex: Der Katalog listet kein Modell auf, und keine Einstellung ändert das.
Um zu ändern, was der Katalog auflistet, siehe Modelleinträge.
Wenn du bereits selbst gehostete Sandboxes betreibst
Die Worker-Software ist dieselbe, daher können sich deine Worker mit deinem Server verbinden. Eigene Worker betreiben listet die drei Werte für den Prozess auf, der pollt, und was du zuerst ändern musst. Ein Worker, der auf einen Webhook hin startet, funktioniert hier nicht.
War diese Seite hilfreich?