Zum Hauptinhalt springen

Verwaltete Agenten

Experte
What you'll learn
  • Verstehen, was ein verwalteter (von Anthropic gehosteter) Agent-Loop für dich übernimmt
  • Die zwei zentralen Objekte unterscheiden: ein versionierter Agent vs. eine Session pro Lauf
  • Geheimnisse sicher mit Vaults einschleusen — ohne dass das Modell sie je sieht
  • Einen Agenten mit Scheduled Deployments auf einen Cron-Zeitplan setzen — kein Scheduler zu hosten
  • Wissen, wann verwaltet einem eigenen Loop überlegen ist, und welche Leitplanken weiterhin gelten

Wenn dir einen eigenen Agent-Loop zu bauen mehr Infrastruktur ist, als du selbst betreiben möchtest, führt ein verwalteter (von Anthropic gehosteter) Agent den Loop für dich aus — sodass du dich auf die Aufgabe des Agenten konzentrierst und nicht auf Session-Verkabelung, Retries, State und Scheduling.

Die zwei Objekte: Agent vs. Session​

Das ist das mentale Modell, an dem alles andere hängt. Sie sind bewusst getrennt.

  • Ein Agent ist eine persistierte, versionierte Konfiguration — Modell, System-Prompt, Tools, MCP-Server und Skills. Du erstellst ihn einmal. Jede Aktualisierung erzeugt eine neue, unveränderliche Version.
  • Eine Session ist eine Laufzeitinstanz — eine Ausführung, die per ID auf einen Agenten zeigt. Die Konfiguration liegt beim Agenten, niemals bei der Session.
Pro tip

Sessions pinnen auf die Agent-Version, mit der sie erstellt wurden: laufende Sessions behalten ihre Version, neue Sessions erhalten die neueste. So lieferst du Konfigurationsänderungen aus, ohne laufende Arbeit zu unterbrechen.

Was dir „verwaltet“ einbringt​

Statt den Loop selbst zu bauen und zu hosten, erhältst du gehostete Bausteine:

  • Sessions — persistente Läufe, die du pro Ausführung erstellst und fortsetzt; Events werden über SSE gestreamt.
  • Umgebungen — Container-Infrastruktur, entweder cloud (von Anthropic gehostet) oder self_hosted (Tools laufen in deiner eigenen VPC). Ein Container pro Session ist der Arbeitsbereich des Agenten.
  • Memory-Stores — persistenter State über Sessions hinweg, mit Versionierung und Redaktion, ohne dass du eine Datenbank verdrahten musst.
  • Vaults — Geheimnisse für MCP-Authentifizierung und andere Dienste.
  • Geplante Deployments — Agenten, die nach einem Cron-Zeitplan laufen, unbeaufsichtigt.

Einen Agenten erstellen (versionierte Konfiguration) und dann eine Session dagegen laufen lassen

# 1. Create the agent once
POST /v1/agents        -> returns $AGENT_ID
# 2. Each execution is a session pinned to that agent
POST /v1/sessions      { "agent": "$AGENT_ID" }

Vaults: Geheimnisse, die das Modell nie sieht​

Ein autonomer Agent benötigt oft einen API-Schlüssel — aber das Modell sollte ihn niemals lesen. Vault-Credentials (mcp_oauth, static_bearer, environment_variable) werden beim Egress substituiert: ein environment_variable-Credential wird zur Ausführungszeit in die Sandbox eingeschleust und ist für das Modell niemals sichtbar.

Watch out

Das ist das sichere Muster, um einem Agenten mächtigen Zugriff zu geben. Füge keine Schlüssel in den System-Prompt oder eine Nachricht ein — sie werden Teil des Kontexts, den das Modell (und deine Logs) sehen können. Lege sie in einen Vault.

Geplante Deployments: ein Agent auf einem Cron​

Ein Deployment hängt einen Cron-Zeitplan an einen Agenten. Wenn der Zeitplan auslöst, startet es eine frische Session und schließt seine Aufgabe ab — kein Scheduler, den du bauen oder hosten musst. Gut für einen nächtlichen Datenabgleich, einen wöchentlichen Compliance-Scan oder eine tägliche Zusammenfassung.

Guided walkthrough1 of 4
  1. POST /v1/deployments mit agent, environment_id, initial_events (muss eine user.message enthalten) und einem schedule: ein POSIX-Cron-Ausdruck plus eine IANA-Zeitzone.

Ein wöchentlicher Compliance-Scan, freitags um 20:00 Uhr New Yorker Zeit

POST /v1/deployments
{
"name": "Weekly compliance scan",
"agent": "$AGENT_ID",
"environment_id": "$ENVIRONMENT_ID",
"initial_events": [
  {"type": "user.message", "content": [{"type": "text", "text": "Run the compliance scan and summarize findings."}]}
],
"schedule": {"type": "cron", "expression": "0 20 * * 5", "timezone": "America/New_York"}
}
Pro tip

Cron ist minute hour day-of-month month day-of-week, mit Granularität auf Minutenebene. DST verwendet Wanduhrzeit-Semantik: eine Zeit, die bei der Umstellung auf Sommerzeit nicht existiert, wird übersprungen; eine Zeit, die bei der Umstellung auf Winterzeit zweimal auftritt, löst zweimal aus. Wähle für alles Sensible eine Zeitzone und eine Uhrzeit, die diese Grenzfälle vermeidet.

Wann verwaltet vs. benutzerdefiniert wählen​

Wähle verwaltet, wenn…Wähle einen eigenen Loop / SDK, wenn…
Du Hosting, State, Scheduling und Geheimnisse erledigt haben möchtestDu volle Kontrolle über den Loop und die Tools brauchst
Du schnell prototypisierstDu strikte Anforderungen an eigene Infrastruktur/Compliance hast
Betriebliche Einfachheit wichtiger ist als KontrolleDu tief in deinen eigenen Stack einbettest

Es ist ein Spektrum — einzelner Aufruf → Workflow → benutzerdefinierter Agent (SDK) → verwaltet. Beginne so einfach, wie es die Aufgabe erlaubt; gehe nur dann eine Stufe höher, wenn du es brauchst.

Es gelten dieselben Leitplanken​

Ob gehostet oder nicht — ein autonomer Agent führt weiterhin Aktionen aus. Behalte geringste Rechte, begrenzte Kosten/Iterationen und menschliche Freigabe für riskante Schritte bei — siehe Agenten absichern und Autonome Läufe härten.

Key takeaways
  • Verwaltete Agenten geben den Loop, Sessions, Umgebungen, Memory, Vaults und Scheduling ab, sodass du dich auf die Aufgabe konzentrierst
  • Ein Agent ist versionierte Konfiguration; eine Session ist ein Lauf, der auf eine Version pinnt — die Konfiguration liegt beim Agenten, nicht bei der Session
  • Vault-environment_variable-Credentials werden zur Ausführung eingeschleust und sind für das Modell niemals sichtbar — der sichere Weg, einem Agenten Geheimnisse zu geben
  • Ein geplantes Deployment ist ein Cron-Ausdruck + IANA-Zeitzone; jedes Auslösen erzeugt einen Lauf, und Unpause holt verpasste Auslösungen nicht nach
  • Verwaltet sitzt am gehosteten Ende von einzelner Aufruf -> Workflow -> benutzerdefiniert -> verwaltet; die Autonomie-Leitplanken gelten weiterhin

Überprüfe dich selbst​

Überprüfe dich selbst

0/3
  1. Was ist der Unterschied zwischen einem Agenten und einer Session?
  2. Wie solltest du einem verwalteten Agenten einen API-Schlüssel geben, den er benötigt?
  3. Ein geplantes Deployment wurde zwei Tage pausiert und dann wieder fortgesetzt. Was passiert mit den Auslösungen, die während der Pause ausgelöst hätten?

Weiter​