Installer NeMo Relay

Choisissez le package ou l'exécutable en fonction du résultat souhaité par l'utilisateur. Arrêtez-vous après l'installation et les vérifications de disponibilité basiques. Ne configurez pas le comportement runtime, n'écrivez pas plugins.toml, ne créez pas de scopes, n'enregistrez pas de middleware, et ne construisez pas d'exemple de première app à partir de cette skill. Gardez l'installation séparée de l'instrumentation de première utilisation.

Choisir Le Chemin D'Installation

Si l'utilisateur demande d'installer NeMo Relay mais n'identifie pas une cible ou un résultat souhaité, posez une seule question de clarification courte avant de donner les commandes :

Quel chemin d'installation voulez-vous : CLI pour l'utilisation coding-agent/passerelle locale, package language pour une app Python/Node.js/Rust, ou intégration framework pour LangChain, LangGraph, Deep Agents, OpenClaw, ou Hermes ?

Ne posez pas la question si l'utilisateur nomme déjà un CLI, langage, framework, harness, source checkout, ou fichier projet cible comme pyproject.toml, package.json, ou Cargo.toml.

Utilisez cet ordre du moins au plus spécifique à l'application :

CLI pour une demande générique « essayer Relay », une exécution coding-agent temporaire, la passerelle locale, ou une configuration explicite de host-plugin persistant. Lisez CLI Installation.
Intégration maintenue quand l'utilisateur utilise déjà OpenClaw, Hermes, LangChain, LangGraph, ou Deep Agents. Lisez Maintained Integration Installation.
Package language quand une application Python, Node.js ou Rust possède directement ses sites d'appel tool ou model. Lisez Language Package Installation.
Source checkout uniquement pour les contributeurs ou les changements non publiés. Suivez le guide de développement du repository à la place des commandes de package publiées.

Pour les demandes « essayer Relay », préférez le CLI et l'exécution transparente temporaire. Ne faites pas de l'installation de host-plugin persistant la valeur par défaut.

Protéger La Continuité De Codex Desktop

Avant l'installation persistante de Codex, déterminez si l'utilisateur opère depuis Codex Desktop. L'installation persistante nemo-relay install codex change le provider Codex actif et peut faire apparaître les threads Desktop actuels ou anciens comme manquants après redémarrage en raison d'un bug de filtrage de provider en amont. Les threads ne sont pas supprimés.

Pour les utilisateurs de Codex Desktop :

Recommandez d'abord l'exécution transparente temporaire.
Si l'utilisateur veut toujours l'installation persistante, lisez la section Codex Desktop dans CLI Installation.
Prévisualisez l'installation et l'emplacement proposé de la note de récupération.
Obtenez une confirmation avant d'écrire la note de récupération ou la configuration Codex globale.
Rendez assets/codex-desktop-recovery.md comme NEMO_RELAY_CODEX_DESKTOP_RECOVERY.md à la racine du workspace de l'utilisateur avant d'exécuter l'installateur persistant.
Ne redémarrez pas Codex Desktop tant que l'utilisateur n'a pas le chemin du fichier de récupération.

Ne désinspectez pas, ne copiez pas, ne supprimez pas, n'éditez pas, et ne réécrivez pas directement les fichiers de session Codex, la configuration d'application privée, ou l'état SQLite pour contourner le bug de visibilité. Les commandes install, uninstall, et doctor nemo-relay supportées peuvent gérer la configuration du provider et du hook générée par Relay.

Installer Et Vérifier

Inspectez le manifest cible, l'environnement, le système d'exploitation, l'architecture, et l'installation existante avant de changer quoi que ce soit.
Chargez uniquement la référence pour le chemin sélectionné.
Préservez le gestionnaire de packages existant du projet et l'environnement virtuel.
Utilisez la dernière version compatible sauf si l'utilisateur ou le projet requiert une version exacte.
Montrez la commande d'installation exacte avant d'exécuter un installateur distant ou de modifier un manifest de projet.
Exécutez uniquement la vérification de disponibilité basique du chemin sélectionné.
Rapportez ce qui a été installé, où c'était installé, et le résultat de vérification. Puis arrêtez-vous.

Les chemins language documentés principalement sont Rust, Python, et Node.js. Traitez Go et raw FFI comme des surfaces avancées orientées source, pas comme des installs de package normales. Ne traitez pas un premier scope, subscriber, gateway, config plugin, ou appel LLM comme vérification d'installation.

Utiliser Doctor Pour La Préparation CLI Et Les Problèmes De Configuration

Connaissez nemo-relay doctor, mais utilisez-le dans la bonne portée :

Exécutez nemo-relay doctor quand l'utilisateur a installé le CLI et rapporte des problèmes de config, gateway, agent-readiness, plugin, exporter, ou model-pricing.
Utilisez nemo-relay doctor --json quand la sortie structurée aidera un agent à inspecter les vérifications programmatiquement.
Utilisez nemo-relay doctor --plugin claude-code, nemo-relay doctor --plugin codex, ou nemo-relay doctor --plugin all uniquement pour les installations persistantes de host-plugin.
Ne requérez pas de plugin doctor pour les exécutions transparentes. La configuration des exécutions transparentes ne requiert pas d'état persistant de host-plugin.
N'utilisez pas doctor comme preuve qu'une dépendance de package Python, Node.js, ou Rust a été installée. Vérifiez avec les vérifications du gestionnaire de packages language/import.

Quand doctor rapporte des défaillances, résumez les vérifications échouées et la remédiation spécifique qu'il suggère. Ne bouclez pas sur la réinstallation de chaque package sauf si la vérification échouée pointe vers une installation cassée ou manquante.

Transférer Après L'Installation

Choisissez le workflow suivant à partir du résultat immédiat de l'utilisateur :

Utilisez nemo-relay-get-started pour un premier scope fonctionnel, appel tool, appel LLM, ou configuration de plugin d'essai.
Utilisez la documentation CLI NeMo Relay ou la configuration spécifique à l'hôte pour un workflow host-plugin CLI local, pas une configuration runtime d'application.
Utilisez la skill de plugin ou instrumentation correspondante pour la configuration runtime, les fichiers plugin, l'observabilité, ou le comportement adaptatif.

Erreurs Courantes

Évitez ces erreurs de portée d'installation :

Utiliser la configuration de développement du repository quand l'utilisateur n'a besoin que d'un package publié.
Installer le CLI quand l'utilisateur a besoin d'une liaison d'application, ou installer une liaison quand l'utilisateur n'a besoin que de l'exécutable local nemo-relay.
Traiter l'installation de host-plugin persistant comme la façon par défaut d'essayer Relay, au lieu de commencer par l'exécution transparente temporaire.
Épingler des anciennes versions sauf si l'utilisateur ou le projet requiert explicitement cette version.
Continuer vers plugins.toml, l'enregistrement de middleware, les scopes, ou les exemples quick-start avant que l'étape d'installation soit vérifiée.

Docs Publiques À Référencer

Utilisez ces points d'entrée publics pour confirmer les conseils d'installation actuels :

nemo-relay-install