Zum Hauptinhalt springen
Diese Anleitung erklärt, wie man Agenten (Assistenten) von einem Langdock Workspace in einen anderen migriert, indem man die Agents API verwendet. Dies ist nützlich, wenn du Agenten-Konfigurationen über verschiedene Workspaces hinweg replizieren, Agenten während einer organisatorischen Umstrukturierung verschieben oder Backup-Kopien deiner Agenten erstellen möchtest.

Bevor du startest

  • Agents API: Dies ist die Agents API mit nativer Vercel AI SDK Kompatibilität.

Überblick

Der Migrationsprozess umfasst zwei Hauptschritte:
  1. Export: Abrufen der Agenten-Konfiguration aus dem Quell-Workspace mit der Agent Get API
  2. Import: Erstellen eines neuen Agenten im Ziel-Workspace mit der Agent Create API

Voraussetzungen

Bevor du beginnst, stelle sicher, dass du folgendes hast:
  1. Zwei API-Schlüssel mit Agenten API Berechtigung:
    • Einen API-Schlüssel für den Quell-Workspace (wo der Agent aktuell existiert)
    • Einen API-Schlüssel für den Ziel-Workspace (wohin du den Agenten migrieren möchtest)
  2. Zugriff auf den Agenten: Dein Quell-Workspace API-Schlüssel muss Zugriff auf den Agenten haben, den du migrieren möchtest
  3. Übereinstimmende Ressourcen im Ziel-Workspace (falls zutreffend):
    • Wenn der Ziel-Workspace keinen Zugriff auf dasselbe Modell hat, setze model im Skript vor der Migration auf einen verfügbaren Deployment-Namen
    • Wenn der Agent benutzerdefinierte Aktionen verwendet, müssen diese Integrationen im Ziel-Workspace aktiviert sein
    • Anhänge müssen separat hochgeladen werden (sie werden nicht automatisch übertragen)
    • Skills müssen im Ziel-Workspace existieren. Skill-UUIDs aus dem Quell-Workspace werden nicht übertragen
    • Sub-Agenten und Workflows müssen im Ziel-Workspace existieren. Ihre UUIDs aus dem Quell-Workspace werden nicht übertragen

Schritt 1: Agent aus dem Quell-Workspace exportieren

Verwende die Agent Get API, um die verfügbaren Einstellungen deines Agenten abzurufen:

Die Antwort verstehen

Die Get API gibt die folgenden Agenten-Einstellungen zurück:
  • name, description, instruction - Die Identität und der System-Prompt des Agenten
  • emojiIcon - Das Emoji-Icon, das für den Agenten angezeigt wird
  • model - Kennung des verwendeten Modells
  • temperature - Kreativitätseinstellung (0-1)
  • conversationStarters - Vorgeschlagene Prompts für Benutzer
  • inputType - Der konfigurierte Eingabetyp
  • inputFields - Formularfelder, inklusive slug, options, fileTypes und emailDomain
  • webSearchEnabled, imageGenerationEnabled, canvasEnabled - Fähigkeits-Flags
  • extendedThinking - Ob Extended Thinking aktiviert ist
  • actions - Benutzerdefinierte Integrations-Aktionen
  • attachments - UUIDs der angehängten Dateien
  • knowledgeFolderIds - UUIDs der verbundenen Ordner
  • skillIds - UUIDs der angehängten Skills
  • subAgents - Angehängte Sub-Agenten, jeweils mit agentId und requiresConfirmation
  • workflowIds - UUIDs der angehängten Workflows
  • owner - aktueller Eigentümer ({ id, name, email }), oder null wenn nicht zugewiesen
  • access - aktuelle Freigabe, wenn der Schlüssel eine direkte Editor- oder Eigentümerfreigabe hat. Siehe Agent Get API
canvasEnabled ist in diesen Endpoints schreibgeschützt und wird bei dieser Migration nicht übertragen. owner wird ebenfalls nicht übertragen. access nutzt IDs aus dem Quell-Workspace und wird nicht kopiert. Der User, dem der API-Schlüssel gehört, wird Eigentümer im Ziel-Workspace.

Schritt 2: Konfiguration transformieren

Die Get API-Antwort verwendet etwas andere Feldnamen als die Create API erwartet. Du musst die Felder mappen:

Feld-Mapping Referenz

Schritt 3: Agent im Ziel-Workspace erstellen

Verwende die Agent Create API, um den Agenten im Ziel-Workspace zu erstellen:

Vollständiges Migrations-Skript

Hier ist ein vollständiges Skript, das alle Schritte kombiniert:

Spezialfälle behandeln

Formularfelder

Jedes Feld enthält slug, options, fileTypes und emailDomain. Kopiere inputFields in die Create API Anfrage und lass description weg, wenn der Wert null ist. Die Create API lehnt null für diese Eigenschaft ab. options ist [], wenn ein Feld keine Auswahl hat, und fileTypes und emailDomain dürfen null sein.

Aktionen (Benutzerdefinierte Integrationen)

Aktionen referenzieren Integrationen, die im Ziel-Workspace aktiviert sein müssen. Aktions-UUIDs sind spezifisch für das Integrations-Setup jedes Workspaces.
Schließe Aktionen von der initialen Migration aus und konfiguriere sie manuell im Ziel-Workspace, nachdem der Agent erstellt wurde.

Anhänge

Anhangs-UUIDs referenzieren Dateien, die im Quell-Workspace gespeichert sind. Diese Dateien werden nicht automatisch übertragen. Um Anhänge zu migrieren:
  1. Lade die Dateien aus dem Quell-Workspace herunter
  2. Lade sie erneut in den Ziel-Workspace mit der Upload Attachment API hoch
  3. Aktualisiere den Agenten mit den neuen Anhangs-UUIDs

Skills

Erstelle oder importiere die Skills im Ziel-Workspace mit der Skills API und setze danach skillIds am neuen Agenten. Skill-IDs aus dem Quell-Workspace werden nicht wiederverwendet.

Sub-Agenten und Workflows

Erstelle die Sub-Agenten und Workflows im Ziel-Workspace und setze danach subAgents und workflowIds am neuen Agenten. IDs aus dem Quell-Workspace werden nicht wiederverwendet. requiresConfirmation kannst du an jedem Sub-Agenten übernehmen. Ein Agent mit Nur direkt lässt sich nicht anhängen, und jeder Workflow muss aktiv sein.

OAuth-Verbindungen

Vorausgewählte OAuth-Verbindungen werden nicht über die API unterstützt. Benutzer müssen OAuth-Verbindungen nach der Migration über die Langdock-Oberfläche konfigurieren.

Mehrere Agenten migrieren

Um mehrere Agenten zu migrieren, durchlaufe einfach eine Liste von Agenten-IDs:

Checkliste nach der Migration

Überprüfe nach der Migration eines Agenten folgendes im Ziel-Workspace:
  • Agent erscheint in der Agenten-Liste mit korrektem Namen und Emoji
  • Beschreibung und Anweisungen wurden korrekt übertragen
  • Gesprächsstarter sind vorhanden
  • Fähigkeiten (Websuche, Bildgenerierung, etc.) sind korrekt aktiviert
  • Eingabefelder sind richtig konfiguriert (für STRUCTURED Eingabetyp)
  • OAuth-Verbindungen manuell über die Oberfläche konfigurieren
  • Erforderliche Dateien erneut hochladen und anhängen
  • Skills mit IDs aus dem Ziel-Workspace anhängen
  • Sub-Agenten und Workflows mit IDs aus dem Ziel-Workspace anhängen
  • Benutzerdefinierte Aktionen/Integrationen bei Bedarf konfigurieren
  • Agent testen, indem eine Nachricht gesendet wird

Einschränkungen

Behalte diese Einschränkungen bei der Planung deiner Migration im Hinterkopf:
  1. Anhänge werden nicht übertragen - Dateien müssen im Ziel-Workspace erneut hochgeladen werden
  2. Aktionen müssen möglicherweise neu konfiguriert werden - Integrations-Aktions-UUIDs sind workspace-spezifisch
  3. OAuth-Verbindungen erfordern manuelle Einrichtung - Können nicht über die API konfiguriert werden
  4. Modellzugriff muss übereinstimmen - Die Create API lehnt ein Modell ab, das im Ziel-Workspace nicht verfügbar ist. Setze vor der Migration einen verfügbaren Deployment-Namen
  5. Gesprächsverlauf wird nicht migriert - Nur die Agenten-Konfiguration wird übertragen
  6. Skills werden nicht übertragen - Erstelle die Skills im Ziel-Workspace und hänge sie mit skillIds an
  7. Sub-Agenten und Workflows werden nicht übertragen - Erstelle sie im Ziel-Workspace und hänge sie mit subAgents und workflowIds an
Langdock blockiert bewusst Browser-basierte Anfragen, um deinen API-Schlüssel zu schützen und die Sicherheit deiner Anwendungen zu gewährleisten. Weitere Informationen findest du in unserem Guide zu Best Practices für API-Schlüssel.