Erste Schritte
Wenn du zum ersten Mal einen Agenten einrichtest, installiere zuerst die Youka-CLI und anschließend den Youka-Karaoke-Skill:Gib deinem Agenten einen Prompt
Nach der Installation von CLI und Skill kannst du deinem Agenten eine direkte Aufgabe wie diese geben:Betriebsregeln
Immer --json verwenden
In der CLI immer
--json mitgeben. In der API immer Accept: application/json setzen. Niemals menschenlesbare Ausgabe parsen.Immer einen Idempotency-Key senden
Jeder Schreibvorgang sollte einen stabilen Idempotency-Key enthalten, damit Wiederholungen nach einem Timeout das ursprüngliche Ergebnis zurückgeben, statt Arbeit zu duplizieren.
Dauerhaften Zustand erneut lesen
Vertraue keinen veralteten Mutationsantworten. Nach einer terminalen Aufgabe das Projekt oder den Export erneut lesen, um den finalen Zustand zu erhalten.
Mit Backoff pollen
Mit einem Intervall von 2–3 Sekunden beginnen. Bei langen Jobs exponentiell erhöhen. 429-Antworten beachten.
Output-Contract
Jeder CLI-Befehl im--json-Modus schreibt genau einen Umschlag nach stdout.
Erfolg:
End-to-end-Workflow
Der kanonische Agenten-Workflow ist: Projekt erstellen, warten, exportieren, Ergebnis herunterladen. Hier ist das vollständige Muster mit CLI- und SDK-Implementierungen.Hinweise zum Polling
Die meisten Schreibvorgänge geben im SDK Operation-Handles zurück. Bevorzugeclient.projects.wait(...) und client.exports.wait(...), und wechsle nur dann zu client.tasks.*, wenn du explizit Low-Level-Task-Zugriff brauchst.
In der CLI übernimmt
--wait das Polling für dich. Im SDK verwenden die Wait-Helper standardmäßig ein Intervall von 2 s und akzeptieren pollIntervalMs.
Idempotency-Keys
Jede Create- und Update-Operation unterstützt einen Idempotency-Key. Regeln:- Verwende pro logischer Mutation einen stabilen, eindeutigen, deterministischen Key. Gut:
create-song-${sourceHash}. Schlecht: eine neue UUID pro Retry. - Verwende bei Retries denselben Key erneut. Der Server erkennt die Wiederholung und liefert das ursprüngliche Ergebnis zurück.
- Keys sind pro Account begrenzt und laufen nach 24 Stunden ab.
- Wenn der Server
IDEMPOTENT_REPLAY_IN_PROGRESS(HTTP 202) zurückgibt, läuft die ursprüngliche Anfrage noch. Warten und mit demselben Key erneut versuchen.
Fehlerbehebung
Verzweige nacherror.code und error.retryable. Die häufigsten Fälle:
Änderbare Felder ermitteln
Bevor du Presets mutierst, rufe das Preset-Schema ab, damit das Modell die gültigen Felder und Werttypen kennt:youka project settings <id> --body ... senden.
Einmal pro Agent-Session abrufen und das Ergebnis cachen.
Parallele Agenten
Wenn mehrere Agenten gleichzeitig auf dasselbe Konto zugreifen:- Begrenze Idempotency-Keys auf sowohl die Agenten-Identität als auch die logische Mutation:
agent-${agentId}-create-${sourceHash}. So kollidiert der Retry eines Agenten nicht mit der frischen Anfrage eines anderen. - Lies unbegrenzt —
GET-Requests sind günstig und haben keine Nebenwirkungen. - Verwende pro Projekt eine einzelne Queue für
POST /projects/{projectId}/exports, wenn du eine geordnete Export-Historie benötigst. Andernfalls können Exporte außerhalb der Reihenfolge ankommen.
Was als Nächstes
- CLI global options — alle Flags, die Agenten zur Verfügung stehen
- SDK errors — vollständige Referenz der Fehlerklassen
- API async jobs — der Polling-Contract
- API idempotency — der Idempotency-Contract
