Commencer avec NeMo Relay

Guidez un nouvel utilisateur vers une valeur visible de Relay avec l'essai applicable le moins compliqué. Ne commencez pas par un déploiement en production ou l'architecture complète de Relay. Concentrez la première exécution sur un seul chemin de succès observable.

Choisir un chemin Try-Now

Évaluez ces chemins dans l'ordre. Utilisez le premier qui correspond à l'objectif déclaré de l'utilisateur et à son environnement existant.

CLI try-now (par défaut) : choisissez cette option pour une demande générique « essayer Relay » ou quand l'utilisateur souhaite de la valeur sans modifier le code applicatif. Exécutez Codex, Claude Code ou Hermes via le wrapper CLI local. Consultez CLI Try-Now.
Built-in integrations try-now : choisissez cette option quand une application LangChain, LangGraph, Deep Agents ou OpenClaw existante possède la limite d'exécution. Préférez l'intégration maintenue et supportée au wrapping manuel. Consultez Built-In Integrations Try-Now.
Language-specific manual try-now : choisissez cette option quand l'application Python, Node.js ou Rust de l'utilisateur possède directement ses sites d'appels tool ou LLM et qu'aucune intégration maintenue n'est la meilleure limite. Consultez Manual Language Try-Now.

Ne demandez pas à l'utilisateur de choisir parmi les trois si sa demande, son manifeste ou son framework identifie déjà la limite. Pour une demande non spécifiée, utilisez le chemin CLI. Quand plus d'un agent CLI est disponible, posez une seule question concise pour sélectionner l'agent.

Résoudre l'installation sans boucler

Sélectionnez le chemin try-now avant de choisir un package d'installation.

Chemin CLI -> vérifiez nemo-relay --version ; s'il manque, utilisez nemo-relay-install pour le résultat CLI.
Chemin intégration built-in -> utilisez nemo-relay-install pour le package framework ou harness nommé.
Chemin langage manuel -> utilisez nemo-relay-install pour le package langage détecté.

Si l'installation a déjà réussi, conservez le chemin choisi et continuez à partir de son étape suivante. Ne posez pas à nouveau la question du chemin d'installation et ne rebondissez pas entre les skills d'installation et de démarrage.

Appliquer le contrat de première valeur commun

Suivez la référence sélectionnée, puis :

Inspectez l'environnement cible et la configuration Relay existante avant de proposer des modifications.
Expliquez la limite d'attachement et montrez le changement minimal exact.
Obtenez une confirmation avant d'écrire la configuration, de modifier le code applicatif ou de lancer une exécution consommant un modèle.
Utilisez un essai non-sensible et en lecture seule et exercez un chemin tool et LLM représentatif quand la surface sélectionnée expose les deux.
Vérifiez la preuve observable à partir du chemin sélectionné plutôt que de traiter un résultat applicatif réussi comme preuve que Relay est actif.
Résumez les relations root, tool et model capturées sans déverser les prompts, les credentials ou les payloads d'événements complets.

Expliquez uniquement les concepts visibles dans le résultat : la limite d'attachement choisie, les scopes et la parenté, les événements de cycle de vie capturés, et comment les subscribers ou le plugin Observability rendent ces événements inspectables. Gardez l'instrumentation et l'export distincts.

Continuer avec un plugin

Arrêtez le workflow try-now initial quand les vérifications de succès du chemin sélectionné passent. Alors faites d'un plugin built-in supplémentaire la prochaine étape principale suggérée.

Expliquez la progression principale de Relay : instrumentez une limite d'exécution une fois, puis modifiez ou étendez le comportement via la configuration du plugin sans réécrire régulièrement ces sites d'appels. La configuration et la reconfiguration faciles des plugins est la valeur principale à démontrer après la première preuve observable.

Si le chemin sélectionné n'a pas utilisé l'Observability gérée par plugin, ajoutez-la d'abord pour établir le chemin plugin réutilisable. Si l'Observability a déjà produit la preuve, demandez quel résultat importe ensuite et recommandez exactement un plugin :

Adaptive -> comportement runtime adaptatif et optimisation
NeMo Guardrails -> vérifications de politique autour de l'exécution gérée
PII Redaction -> assainissement des payloads d'observabilité sensibles
Model Pricing -> estimations de coût pour les réponses LLM gérées

Utilisez l'aperçu des plugins pour sélectionner le composant suivant. Prévisualisez sa plus petite configuration, obtenez une confirmation et vérifiez son comportement avant d'ajouter un autre plugin en couches.

Utilisez un autre handoff uniquement après que l'utilisateur accepte ou refuse la progression des plugins, ou quand la limite démontrée ne couvre pas encore le workflow prévu :

Expansion applicative directe -> nemo-relay-instrument-calls
Exporteurs supplémentaires ou configuration d'observabilité durable -> nemo-relay-plugin-observability
Un package différent ou une intégration supportée -> nemo-relay-install
Chargement persistant de Claude Code ou Codex -> nemo-relay-install ; pour Codex Desktop, complétez sa barrière de sécurité recovery-note avant de modifier la configuration globale
Hooks manquants, trafic gateway ou événements -> nemo-relay doctor, nemo-relay doctor --json, ou nemo-relay-debug-runtime-integration

Ne configurez pas les backends OTLP de production, la tarification des modèles, les guardrails, l'ajustement adaptatif, les plugins personnalisés, les exemples Go ou FFI pendant le démarrage rapide. Mentionnez les plugins optionnels uniquement après la preuve initiale et ajoutez uniquement celui que l'utilisateur sélectionne.

Points d'entrée publics

Utilisez ces points d'entrée publics pour la documentation actuelle du produit :

nemo-relay-get-started