DeepSeek Super-agent: configuración y diseño Router/Worker

Empieza la prueba de DeepSeek Super-agent con un repositorio, un único solicitante autorizado y una cuenta dedicada del sistema operativo. Su Router convierte las solicitudes autorizadas en Tickets, mientras los Workers usan sesiones y directorios independientes. Mantén observe activado al principio, pero recuerda que las solicitudes explícitas pueden ejecutarse.

A fecha de 2026-11-09, dsh-superagent-prototype es código de investigación, no un producto oficial de DeepSeek ni un servicio listo para producción. Su manifiesto de paquete declara la versión 0.1.0 y la licencia MIT. La implementación pública también difiere del sistema interno del equipo y de la implementación descrita en su artículo de diseño.

Qué hacen Router, Ticket y Worker

La diferencia principal es la recepción continua de tareas, no otro modelo ni una nueva interfaz de programación. El paquete se ejecuta dentro de DeepSeek Harness, escucha un repositorio de GitHub y, opcionalmente, recibe mensajes de Feishu.

El modelo de dominio separa los eventos entrantes del trabajo autorizado. La evaluación, llamada Eval, decide si una posible tarea justifica crear un Ticket. Cada Ticket aceptado lleva un Mandate, que registra su autorización y alcance.

Router es la sesión principal del agente que decide cómo encaminar las solicitudes. Worker ejecuta la tarea aceptada. Las páginas de configuración llaman Executor a ese Worker.

Cada Worker tiene su propia sesión y directorio de trabajo. Los resultados vuelven a la conversación original, por ejemplo, mediante un comentario de GitHub con una solicitud de cambios o pull request. Un directorio separa las copias de trabajo; no restringe los archivos que puede leer el proceso.

Por ejemplo, dos informes de errores sin relación pueden convertirse en Tickets independientes en vez de compartir una conversación de programación. Esto resulta útil cuando coordinar las tareas entrantes exige más atención que iniciar una tarea individual.

Para un único cambio interactivo, conserva tu agente de programación actual. Para delegar trabajo acotado, empieza con subagentes de Claude Code de solo lectura y selección explícita del modelo.

Por qué observe no es un entorno aislado de seguridad

observe limita el trabajo inferido del contexto, no toda la ejecución. Las reglas de autorización permiten solicitudes explícitas en todos los modos de aceptación.

En observe, las evaluaciones positivas de tareas inferidas se registran como «would accept», sin crear trabajo a partir de ellas. En auto, una evaluación positiva puede aceptar trabajo inferido. Una persona autorizada que mencione al agente puede pedirle trabajo en cualquier modo.

La lista de personas autorizadas no es el único control de admisión. Una celda de la tabla de admisión también puede conceder autorización explícita a personas ajenas a la lista. Configura la política de un único solicitante descrita más abajo, en lugar de depender solo de observe.

Qué significa danger-full-access

Usa una cuenta del sistema operativo que contenga únicamente las credenciales del agente. La advertencia sobre aislamiento de la guía de despliegue se aplica tanto a dsh-superagent-router como a dsh-superagent-worker. Ambos se ejecutan como el usuario del sistema operativo del operador, con danger-full-access.

Los programas envoltorio para las credenciales seleccionan cuentas; no aíslan los procesos. Los Workers pueden ejecutar programas mediante rutas absolutas y leer el directorio personal del operador. La guía de implementación también concede al Router herramientas de shell y lectura de archivos.

Para la primera prueba, usa una máquina desechable o virtual con una cuenta del agente sin permisos de administrador. Mantén fuera las credenciales personales, los secretos de producción y los repositorios ajenos a la prueba. Son precauciones de despliegue, no protecciones que aporte el prototipo.

Mantén también un perfil de Harness independiente. El complemento modifica PATH y la configuración de git para todo el proceso. Deja el panel vinculado a 127.0.0.1; no expongas esta prueba como un servicio web público.

Configura una prueba solo con GitHub

Sigue estos pasos manuales con una cuenta y un perfil nuevos. El repositorio también incluye un SETUP.md para configurar el sistema con ayuda de un agente.

Comprueba los requisitos

Instala Node.js 22.19+ o 24+, pnpm, git 2.32+, Python 3.8+, tmux y GitHub CLI 2.48+. Son los requisitos documentados.

También necesitas un repositorio en github.com y un proveedor de modelos para DeepSeek Harness. GitHub Enterprise Server no es compatible. Instala git-lfs si el repositorio de destino usa Git LFS.

Usa un repositorio de prueba que no esté vacío y contenga README.md. Para la primera prueba, es preferible uno privado al que solo accedan tú y el agente.

Feishu es opcional y queda fuera de esta prueba. Su configuración documentada requiere además una aplicación de Feishu o Lark con bot y lark-cli. El proyecto indica que lo probó con la versión 1.0.90.

Inicia sesión únicamente como el agente

Crea una cuenta de usuario de GitHub dedicada y dale permiso de escritura en el repositorio de prueba. Ejecuta estos comandos en Bash desde la cuenta dedicada del sistema operativo.

unset GH_TOKEN GITHUB_TOKEN
gh auth login --hostname github.com --git-protocol https
gh api user --jq .login
gh auth setup-git --hostname github.com

Completa el inicio de sesión interactivo de GitHub CLI como el agente. El comando gh api debe mostrar su nombre de usuario. Al eliminar las dos variables evitas que las credenciales del entorno prevalezcan sobre el inicio de sesión guardado.

El paso independiente gh auth setup-git configura Git para usar GitHub CLI como asistente de credenciales. Es necesario porque la preparación y el envío de ramas usan Git directamente.

Crea el clon local con la sintaxis documentada de GitHub CLI:

read -r -p "Repository (owner/name): " TARGET_REPOSITORY
mkdir -p "$HOME/src"
gh repo clone "$TARGET_REPOSITORY" "$HOME/src/superagent-target"

Después, comprueba el acceso HTTPS por separado de gh api:

GIT_TERMINAL_PROMPT=0 git ls-remote \
  "https://github.com/$TARGET_REPOSITORY.git" HEAD

GIT_TERMINAL_PROMPT=0 git -C "$HOME/src/superagent-target" push --dry-run \
  "https://github.com/$TARGET_REPOSITORY.git" \
  HEAD:refs/heads/agent-auth-check

git ls-remote debe devolver el HEAD remoto. En un repositorio público, esa lectura puede funcionar de forma anónima. La comprobación con push --dry-run prueba la conexión de envío sin actualizar referencias remotas.

Ambos comandos deben terminar correctamente. Aun así, la comprobación final de entrega será el envío real de la rama para crear el PR.

Este ejemplo usa gh directamente porque toda la cuenta del sistema operativo pertenece al agente. No reutilices la configuración con varias sesiones de GitHub de una cuenta personal.

Instala un perfil dedicado de Harness

Usa la versión de Harness fijada en la guía de despliegue: 0.2.1-rc.3. El manifiesto del paquete exige que engines.dsh cumpla ^0.2.1-alpha.2.

Define DSH_HOME antes de ejecutar cualquier comando dsh. La referencia de CLI de esa versión sitúa los perfiles con nombre en $DSH_HOME/profiles/<name>. Aquí se elige explícitamente $HOME/.dsh para esta prueba.

Los siguientes comandos de Bash son solo para una instalación nueva:

export DSH_HOME="$HOME/.dsh"

npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git
cd dsh-superagent-prototype
pnpm install
pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"

No vuelvas a ejecutar el comando de creación del perfil en una instalación existente. Sustituye el perfil y elimina su cordis.patch.yml. Para actualizar, sigue el procedimiento de la guía de despliegue.

Confirma que existe el manifiesto del perfil antes de escribir la configuración de la máquina. Continúa en la misma sesión de Bash:

test -f "$DSH_HOME/profiles/superagent/package.json" || exit 1

cat > "$DSH_HOME/profiles/superagent/cordis.patch.yml" <<EOF
- id: webserver
  config:
    host: 127.0.0.1
    port: 3082
- id: dsh-superagent
  config:
    stateDir: "$DSH_HOME/state/superagent"
EOF

if tmux list-sessions >/dev/null 2>&1; then
  tmux set-environment -g DSH_HOME "$DSH_HOME"
  if tmux has-session -t '=dsh-superagent' 2>/dev/null; then
    tmux set-environment -t '=dsh-superagent' DSH_HOME "$DSH_HOME"
  fi
fi

scripts/dsh-superagent start
scripts/dsh-superagent status

El script del servicio ejecuta dsh --profile superagent mediante tmux. Un servidor nuevo de tmux hereda el entorno exportado. El bloque también actualiza el entorno de tmux de un servidor o una sesión existentes.

Abre http://127.0.0.1:3082 en un navegador de la máquina del servidor. En los ajustes de Harness, Open configuration file debe abrir la ruta superagent/cordis.patch.yml indicada arriba. Detente si abre otra ubicación. No sobrescribas ese parche después de añadir la configuración del proveedor.

Selecciona Superagent en la barra lateral. Es normal ver una advertencia de configuración pendiente hasta completar los ajustes del repositorio y de la cuenta. Antes de configurar la recepción de solicitudes, completa la sección de selección del modelo que aparece más abajo.

Configura la recepción de solicitudes y los árboles de trabajo por Ticket

Usa Superagent → Settings y sus grupos documentados.

En Sources → GitHub, indica tu repositorio como owner/name y establece gh como CLI del agente. Deja desactivados los interruptores que reciben todos los Issues, pull requests, comentarios y eventos de CI de la rama predeterminada. Mantén Feishu desactivado.

En Eval → On each Source → GitHub, deja únicamente tu nombre de usuario personal en GitHub accounts that may originate work. Elimina las demás entradas y deja vacía la lista de bots. Pon en ignore todas las celdas visibles de admisión para personas ajenas a la lista, incluidas las que se dirigen al agente. Guarda los ajustes con el modo de aceptación observe.

Estos valores predeterminados para personas ajenas a la lista están definidos en la matriz de admisión. Restringen las solicitudes de trabajo nuevo. No impiden que los mensajes de conversaciones suscritas lleguen como contexto a Tickets existentes. Limita la conversación de prueba a ti y al agente.

En Execution, empieza con una concurrencia de 1 para la prueba. Conserva la raíz de directorios predeterminada. Pega lo siguiente en el campo del comando de preparación; se ejecuta con sh y su sintaxis también es válida en Bash.

git -C "$HOME/src/superagent-target" fetch --no-tags \
  "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" \
  "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&
git -C "$HOME/src/superagent-target" worktree add \
  -b "agent/$DSH_SUPERAGENT_NAME" \
  "$DSH_SUPERAGENT_DIR" \
  "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"

Esto adapta la receta de árboles de trabajo de la guía de despliegue al clon creado antes. Obtiene la revisión correspondiente y crea la rama y la copia de trabajo del Ticket. Sin un comando de preparación, el Worker empieza en un directorio vacío.

En Prompts, configura la identidad del autor de los commits y el texto que informa de la participación del agente. Exige que una persona haga las fusiones y no proporciones una cuenta de fusión independiente. Las instrucciones del prompt son orientación, no una protección impuesta por el repositorio.

¿Puedes usar otro modelo?

Sí, mediante los proveedores configurados en DeepSeek Harness. La guía de proveedores de la etiqueta dsh-v0.2.1-rc.3 documenta estos pasos para la versión instalada.

Abre Settings → Models en Harness. Introduce y guarda la clave API en la tarjeta de DeepSeek, o elige Add model provider para otro proveedor compatible. Introduce las credenciales localmente en esa interfaz, no en una conversación de GitHub.

Para Custom model API, indica un Provider ID en minúsculas, la URL base, el protocolo API correspondiente, las credenciales y al menos un modelo. Usa los valores documentados por tu proveedor. Guardar un proveedor no demuestra que su modelo pueda realizar las llamadas a herramientas necesarias.

Después, usa Choose workspace para añadir y seleccionar $HOME/src/superagent-target, siguiendo la guía de la interfaz web de esa versión. Inicia una sesión normal y elige un modelo configurado en su selector. Esa selección establece el valor predeterminado para las sesiones nuevas.

Abre otra sesión nueva y comprueba que muestra el mismo proveedor y modelo antes de enviar una solicitud. Pídele que lea README.md y devuelva su primer encabezado sin editar nada. Compara la respuesta con el archivo. No uses ninguno de los preajustes gestionados dsh-superagent-* para esta prueba.

Después, selecciona explícitamente ese proveedor y modelo probados en Superagent → Settings → Eval y Execution. Eval proporciona el modelo de Router y de evaluación; Execution, el del Worker. Esta prueba no depende de un valor predeterminado sin confirmar. Deja cualquiera de esas selecciones sin definir solo después de verificar el modelo predeterminado del perfil.

La selección de Executor se aplica al crear una sesión. Las sesiones existentes de Worker conservan su modelo y Retry reutiliza la misma sesión. Comprueba cualquier cambio posterior de modelo con un Ticket nuevo.

Verifica una solicitud y localiza el fallo

Verifica una solicitud completa de GitHub y su respuesta antes de pedir cambios de código. Que el panel esté funcionando no demuestra que la autorización, la preparación y las llamadas al modelo sean correctas.

Primero, vuelve a ejecutar scripts/dsh-superagent status. Exige un código de salida 0 y ninguna incidencia de configuración. Publica un comentario nuevo en un issue desde la cuenta personal autorizada. Sustituye @AGENT_LOGIN por el nombre de usuario del agente:

@AGENT_LOGIN Read README.md and reply here with its first heading.
Do not edit files, push a branch, or open a pull request.

El procedimiento de prueba de la guía de despliegue sitúa el Ticket resultante en Overview. Comprueba que la respuesta en la conversación original de GitHub contiene el encabezado correcto.

Cuando funcione, pide un pequeño cambio en la documentación y un pull request para revisión humana. Confirma que la rama se envió realmente, que el PR pertenece a la cuenta del agente y que el diff respeta el alcance. Son comprobaciones de aceptación, no resultados garantizados del modelo.

Si no aparece un Ticket, revisa el usuario autorizado, las celdas de admisión, el repositorio y el estado de la fuente GitHub. Después, publica un comentario nuevo mencionando al agente.

Ante fallos del servicio, el script devuelve 1 para problemas del proceso o de ejecución, 2 para errores de componentes y 3 para configuración incompleta. Reiniciar puede ayudar con 1; corrige la causa indicada si devuelve 2 o 3.

Para fallos transitorios del modelo o de la red, la guía de ejecución especifica tres reintentos con esperas crecientes. Incluyen los códigos HTTP 408, 429 y 5xx. Los fallos del comando de preparación quedan excluidos de ese reintento automático.

Recupera un comando de preparación fallido

Revisa el error de preparación registrado y el directorio del Ticket antes de seleccionar Retry. La implementación del arranque ejecuta la preparación solo cuando ese directorio no existe. Si existe, lo considera preparado, aunque contenga trabajo incompleto.

Cuando el directorio no exista, corrige el problema de credenciales o del comando de preparación y selecciona Retry. El nuevo arranque vuelve a intentar la preparación.

Cuando exista, copia su ruta desde los detalles del Ticket e inspecciónalo en Bash:

read -r -p "Ticket directory (absolute path): " TICKET_DIR
git -C "$TICKET_DIR" rev-parse --show-toplevel
git -C "$TICKET_DIR" status --short --branch

El directorio raíz mostrado debe ser el del Ticket, no una copia de trabajo situada en un directorio superior. Comprueba la rama y el estado del árbol de trabajo, los archivos esperados y cada paso de preparación que hubiera fallado.

Reintenta en un directorio existente solo después de completar y verificar su preparación. Retry no lo reconstruye. Si no puedes restaurar una copia incompleta con seguridad, consérvala, detén ese Ticket, corrige el comando y envía una solicitud en un issue nuevo. Confirma que el Ticket de sustitución usa un directorio nuevo antes de continuar.

Una vez que un Ticket falla, los mensajes de CI y de bots no reactivan su Worker. Debe intervenir una persona. Detén el servicio de prueba cuando termines:

scripts/dsh-superagent stop

Cuándo mantenerlo en ejecución

Mantén el prototipo únicamente cuando sus decisiones de asignación y los cambios entregados justifiquen el trabajo de operación. Empieza con un alcance reducido. Aumenta la concurrencia solo después de medir los resultados útiles y el uso del proveedor.

Compara el coste por cambio aceptado, no solo el precio del modelo. Incluye en el presupuesto la asignación de solicitudes, la evaluación, las llamadas del Worker y la recuperación. La guía de coste por tarea de agentes de programación ofrece un método para comparar un modelo junto con su entorno de ejecución.

No equipares una demostración interna con este código público. El repositorio advierte que algunos diseños del artículo más amplio no están implementados. Mantén el despliegue aislado y sujeto a revisión humana hasta que tus comprobaciones justifiquen ampliar su uso.