Saltar al contenido principal
Referencia completa del ámbito de Outposts: la CLI del worker, la fleet API, la distribución del binario devin-remote y el contrato de creación para orquestadores personalizados.

Autenticación

Los workers y los orquestadores se autentican con un token de API v3 que pertenece a un usuario de servicio. El rol asignado al usuario de servicio concede al token los ámbitos de Outposts correspondientes: Outposts está dentro del ámbito de tu cuenta y se comparte entre todas sus organizaciones.

CLI

devin worker start

Sondea la cola de un outpost, reclama sesiones, descarga el binario devin-remote correcto y atiende las sesiones. Ejecútalo desde el directorio que contiene los repositorios clonados de la sesión.
El Environment del worker también puede incluir DEVIN_CHROME_PATH para hacer que las sesiones usen un binario de Chrome/Chromium para las funciones del navegador.

devin worker outpost create

Crea un outpost: una cola de sesiones identificada por un nombre y atendida por tu infraestructura. Requiere el ámbito de orquestador.
Muestra el ID del nuevo outpost (outpost_env-...). También puedes crear outposts en la aplicación web, en Settings → Environment → Outposts.

devin worker outpost delete

Elimina un outpost. Requiere el ámbito de orquestador.

Fleet API

Todos los endpoints se encuentran en https://api.devin.ai/opbeta/outposts/ y usan un Bearer token:
Los recursos siguen una estructura de metadata / spec / status al estilo de Kubernetes, y la cola sigue la semántica de Kubernetes de listar primero y luego observar, con entrega de al menos una vez.

Objetos

Entrada de cola (devins)

Cada sesión en cola está representada por una entrada de cola: spec.network_policy indica si el acceso de red de la sesión está restringido (enabled) y cuáles son los destinos permitidos (allow): patrones de hostname con comodines ({"hostname": ...}), direcciones/CIDR IPv4 ({"ipv4": ...}) o direcciones/CIDR IPv6 ({"ipv6": ...}).

Outpost

Listar sesiones en cola

Respuesta de ejemplo:
Semántica de paginación y entrega:
  • Pasa el cursor de cada respuesta a la siguiente solicitud mientras has_next_page sea true.
  • La entrega es de al menos una vez: una sesión en el límite entre páginas puede aparecer en ambas, así que actualiza o inserta las entradas por metadata.session_id en lugar de tratar cada elemento como nuevo (el CAS de reclamo hace que los duplicados no causen problemas).
  • Cuando has_next_page pase a ser false, guarda el cursor devuelto como posición inicial de un watch.

Detectar cambios

Transmite eventos enviados por el servidor. Los eventos MODIFIED se emiten cuando cambia la entrada en cola de una sesión (las sesiones que acaban de ponerse en cola también llegan como MODIFIED); los eventos DELETED se emiten cuando esta se elimina. Cada campo data de SSE contiene:
Semántica de watch:
  • Conserva el cursor de nivel superior de cada evento después de procesarlo; vuelve a conectarte con el último cursor guardado para reproducir los cambios que ocurrieron mientras estabas desconectado.
  • La entrega es de al menos una vez; admite eventos duplicados.
  • Los flujos terminan al cabo de un máximo de cinco minutos; se espera un bucle de watch con reconexión.
  • Los filtros phase y acceptor_id se ignoran cuando watch=true; filtra los eventos recibidos por watch usando los campos del object de cada evento.
  • Si omites el cursor, se empieza desde el principio, así que usa listar y luego watch para una reconciliación normal.

Obtener una entrada de la cola

Devuelve la entrada en la cola correspondiente a una sesión.

Reclamar una sesión

Reclama de forma atómica la sesión para la identidad del worker especificada. Si otro worker la reclamó primero, la solicitud falla con 409. Si el reclamo se realiza correctamente, la respuesta incluye status.connect_token y status.gateway_url: las credenciales que devin-remote necesita para conectarse (consulta el contrato de creación). Al reclamarla, se garantiza que un worker estará listo dentro del plazo de reclamo asignado por el servidor (status.claim_deadline); los reclamos vencidos vuelven a la cola automáticamente.

Liberar un reclamo

Libera el reclamo del worker para que la sesión vuelva inmediatamente a la cola (p. ej., si falla el aprovisionamiento).

Outposts

Cuerpo de la solicitud para crear:
Las operaciones de creación, GET y eliminación requieren el ámbito del orquestador; cada respuesta del outpost informa de status.queue_depth y status.active_claims en tiempo real.

Distribución remota del binario

El comando devin worker start descarga automáticamente el binario devin-remote adecuado. Los orquestadores personalizados que no usan Devin CLI pueden obtenerlo directamente de:
Identifica la versión más reciente:
Descargar y verificar:
Plataformas disponibles: Si la entrada de la cola de la sesión incluye un spec.remote_binary_sha, usa ese SHA en lugar de latest; esto fija la sesión a una versión probada específica.

Contrato de creación

Si tu orquestador inicia devin-remote por sí mismo en lugar de usar devin worker start, créalo de la siguiente manera:
con las siguientes variables de entorno: Proporciona al remoto un entorno limpio que contenga solo las variables anteriores más las variables básicas del sistema (PATH, HOME, USER, LOGNAME, TMPDIR, LANG, TZ y — para la captura de pantalla de la transmisión del escritorio en Linux/X11 — DISPLAY, WAYLAND_DISPLAY, XAUTHORITY). No expongas al remoto nada que el agente no deba poder ver: el shell del agente lo hereda. Expectativas adicionales del ciclo de vida:
  • Directorio de trabajo: inicia el remoto desde el directorio que contiene los repositorios de la sesión (la misma regla que devin worker start).
  • Fin de la sesión: cuando la sesión termina (se suspende o finaliza), Devin notifica al remoto y este sale por sí solo con estado 0. Trata una salida limpia como el fin de la sesión: confirma que status.session_status de la entrada de la cola sea suspended o terminated (la actualización de estado puede retrasarse unos segundos respecto de la salida, así que vuelve a consultarlo unas cuantas veces), luego libera el reclamo. Como fallback, también sondea status.session_status mientras el remoto está en ejecución y finaliza el proceso tú mismo una vez que llegue a terminated (o desaparezca la entrada de la cola).