Zum Hauptinhalt springen
Vollständige Referenz zum Outposts-Funktionsumfang: die worker-CLI, die fleet API, die Distribution der devin-remote-Binärdatei und die Spawn-Spezifikation für benutzerdefinierte Orchestratoren.

Authentifizierung

Worker und Orchestratoren authentifizieren sich mit einem v3-API-Token, das zu einem Service-Benutzer gehört. Die dem Service-Benutzer zugewiesene Rolle legt die Outposts-Geltungsbereiche des Tokens fest: Outposts sind Ihrem Konto zugeordnet und werden von allen zugehörigen Organisationen gemeinsam genutzt.

CLI

devin worker start

Fragt die Warteschlange eines Outposts regelmäßig ab, nimmt Sitzungen an, lädt die passende devin-remote-Binärdatei herunter und führt Sitzungen aus. Führen Sie den Befehl in dem Verzeichnis aus, das die ausgecheckten Repositorys der Sitzung enthält.
Die Umgebung des Workers kann außerdem DEVIN_CHROME_PATH enthalten, um Sitzungen für Browser-Funktionen auf eine Chrome-/Chromium-Binärdatei zu verweisen.

devin worker outpost create

Erstellt einen Outpost – eine benannte Warteschlange für Sitzungen, die von Ihrer Infrastruktur bedient wird. Erfordert den Geltungsbereich orchestrator.
Gibt die ID des neuen Outposts aus (outpost_env-...). Sie können Outposts auch in der Web-App unter Settings → Environment → Outposts erstellen.

devin worker outpost delete

Löscht einen Outpost. Erfordert den Geltungsbereich „orchestrator“.

Fleet API

Alle Endpunkte sind unter https://api.devin.ai/opbeta/outposts/ verfügbar und verwenden ein Bearer-Token:
Ressourcen folgen einer Kubernetes-ähnlichen metadata-/spec-/status-Struktur, und die Warteschlange verwendet die Kubernetes-Semantik „list-then-watch“ mit mindestens einmaliger Zustellung.

Objekte

Warteschlangeneintrag (devins)

Jede Sitzung in der Warteschlange wird durch einen Warteschlangeneintrag dargestellt: spec.network_policy gibt an, ob der Netzwerkzugriff der Sitzung eingeschränkt ist (enabled) und welche Ziele zulässig sind (allow): Hostname-Muster ({"hostname": ...}), IPv4-Adressen/CIDRs ({"ipv4": ...}) oder IPv6-Adressen/CIDRs ({"ipv6": ...}).

Outpost

Sitzungen in der Warteschlange auflisten

Beispielantwort:
Paginierungs- und Zustellungssemantik:
  • Übergeben Sie den Cursor jeder Antwort in die nächste Anfrage, solange has_next_page true ist.
  • Die Zustellung erfolgt mindestens einmal: Eine Sitzung an einer Seitengrenze kann auf beiden Seiten erscheinen. Führen Sie daher Upserts für Einträge anhand von metadata.session_id aus, anstatt jedes Element als neu zu behandeln (das Claim-CAS macht Duplikate unschädlich).
  • Wenn has_next_page false wird, speichern Sie den zurückgegebenen Cursor als Startposition für einen Watch.

Änderungen beobachten

Streamt Server-Sent Events. MODIFIED-Ereignisse werden ausgelöst, wenn sich der Warteschlangeneintrag einer Sitzung ändert (neu in die Warteschlange aufgenommene Sitzungen kommen ebenfalls als MODIFIED an); DELETED-Ereignisse werden ausgelöst, wenn er entfernt wird. Jedes SSE-data-Feld enthält:
Watch-Semantik:
  • Persistieren Sie nach der Verarbeitung jedes Ereignisses dessen cursor auf oberster Ebene; stellen Sie die Verbindung mit dem zuletzt persistierten Cursor wieder her, um Änderungen wiederzugeben, die während der Unterbrechung aufgetreten sind.
  • Die Zustellung erfolgt mindestens einmal — tolerieren Sie doppelte Ereignisse.
  • Streams enden nach spätestens fünf Minuten; eine Watch-Schleife mit Wiederverbindung wird erwartet.
  • phase- und acceptor_id-Filter werden ignoriert, wenn watch=true; filtern Sie beobachtete Ereignisse stattdessen anhand der Felder im object jedes Ereignisses.
  • Wenn der Cursor weggelassen wird, beginnt der Stream am Anfang. Verwenden Sie daher für den normalen Abgleich list-then-watch.

Einen Queue-Eintrag abrufen

Gibt den Warteschlangeneintrag für eine Sitzung zurück.

Eine Sitzung übernehmen

Beansprucht die Sitzung atomar für die angegebene Worker-Identität. Wenn ein anderer Worker sie zuerst beansprucht hat, schlägt die Anfrage mit 409 fehl. Eine erfolgreiche Beanspruchungsantwort enthält status.connect_token und status.gateway_url — die Zugangsdaten, die devin-remote zum Herstellen der Verbindung benötigt (siehe den Spawn-Spezifikation). Mit der Beanspruchung wird zugesichert, dass ein Worker innerhalb der vom Server zugewiesenen Claim-Deadline (status.claim_deadline) bereit ist; abgelaufene Beanspruchungen kehren automatisch in die Warteschlange zurück.

Eine Beanspruchung freigeben

Gibt die Reservierung des Workers frei, sodass die Sitzung sofort in die Warteschlange zurückkehrt (z. B. wenn die Bereitstellung fehlschlägt).

Outposts

Request-Body für das Erstellen:
Zum Erstellen, Abrufen und Löschen ist der Geltungsbereich orchestrator erforderlich; jede Outpost-Antwort enthält die aktuellen Werte von status.queue_depth und status.active_claims.

Verteilung von Remote-Binärdateien

Der Befehl devin worker start lädt automatisch die passende devin-remote-Binärdatei herunter. Benutzerdefinierte Orchestratoren, die nicht die Devin CLI verwenden, können sie direkt hier abrufen:
Neueste Version ermitteln:
Herunterladen und überprüfen:
Verfügbare Plattformen: Wenn der Warteschlangeneintrag der Sitzung ein spec.remote_binary_sha enthält, verwenden Sie diesen SHA-Wert anstelle von latest — dadurch wird die Sitzung auf eine bestimmte getestete Version angepinnt.

Spawn-Spezifikation

Wenn Ihr Orchestrator devin-remote selbst startet, statt devin worker start zu verwenden, starten Sie ihn wie folgt:
mit den folgenden Umgebungsvariablen: Geben Sie dem Remote eine saubere Umgebung, die nur die oben genannten Variablen sowie grundlegende Systemvariablen enthält (PATH, HOME, USER, LOGNAME, TMPDIR, LANG, TZ und — für die Bildschirmaufnahme des Desktop-Streams unter Linux/X11 — DISPLAY, WAYLAND_DISPLAY, XAUTHORITY). Geben Sie nichts an das Remote weiter, was der Agent nicht sehen können soll: Es wird von der Shell des Agenten vererbt. Zusätzliche Lifecycle-Erwartungen:
  • Arbeitsverzeichnis: Starten Sie das Remote in dem Verzeichnis, das die Repositories der Sitzung enthält (dieselbe Regel wie bei devin worker start).
  • Sitzungsende: Wenn die Sitzung endet (in den sleep-Zustand wechselt oder beendet wird), benachrichtigt Devin das Remote und es beendet sich selbst mit Status 0. Behandeln Sie einen sauberen Exit als Ende der Sitzung: Bestätigen Sie, dass status.session_status des Warteschlangeneintrags suspended oder terminated ist (die Statusaktualisierung kann dem Exit um einige Sekunden hinterherhinken, lesen Sie also einige Male erneut), und geben Sie dann den Claim frei. Als Fallback pollen Sie status.session_status auch, während das Remote läuft, und beenden den Prozess selbst, sobald es terminated erreicht (oder der Warteschlangeneintrag verschwindet).