nAIxus Docs
Reference

Options de clarification de l’Agent

Configuration et contrat d’exécution de l’outil de contrôle ask_user de l’Agent.

Configuration du nœud

{
  "askUser": {
    "enabled": false,
    "maxQuestions": 2
  }
}
OptionTypeDéfautContrainte
askUser.enabledbooléenfalseActivation explicite ; aucun outil proposé si désactivé
askUser.maxQuestionsentier2De 1 à 5, par activation de l’Agent

ask_user est un outil de contrôle réservé, pas un outil ordinaire du registre. Il est disponible uniquement pour les exécutions interactives console, Webchat ou canal API reconnues par le serveur, avec publication vers le canal activée et sans validation différée de la sortie. L’interactivité dépend du type de canal côté serveur, jamais du contexte fourni par le client. Les appelants API répondent avec le même session_id et payload.user_message, comme pour un nœud Question.

Arguments de l’outil

ArgumentContrat
questionChaîne obligatoire, non vide ; 500 caractères au maximum
suggestionsTableau facultatif ; 8 chaînes non vides de 100 caractères au maximum chacune
allow_free_textBooléen, true par défaut ; false impose des suggestions

Une seule question est posée par réponse du modèle. Les autres appels de question du même lot reçoivent une erreur explicite. Tous les appels ordinaires du lot sont exécutés d’abord. À la limite configurée, les questions supplémentaires produisent une erreur d’outil ; la boucle continue dans le budget de raisonnement restant.

Suspension et reprise

  • Un point de reprise versionné est enregistré sur l’étape Agent existante avant la mise en attente.
  • La réponse acceptée devient le résultat de l’appel d’outil en attente, ou une Observation: avec ReAct.
  • La configuration du modèle/fournisseur et les graphes actifs (y compris les cibles Go to Flow) sont figés. Leur modification pendant l’attente ne change pas cette activation.
  • Les secrets des connecteurs sont résolus à nouveau à la reprise ; leur rotation et leur révocation restent applicables.
  • Les tokens et les tours de raisonnement sont cumulés. Les outils précédents et les itérations terminées ne sont pas rejoués.
  • Les réponses concurrentes utilisent la transition optimiste et le bail Worker existants ; une seule continuation est acceptée.
  • L’historique conserve la question et la réponse acceptée comme messages assistant/utilisateur. L’état interne de reprise est masqué dans les projections d’exécution et de trace.

Le point de reprise complet est limité à 256 Kio de JSON UTF-8. Les résultats textuels d’outils conservés pendant le questionnement sont limités à 16 384 caractères, avec un marqueur de troncature. Un état trop volumineux ou incompatible provoque une erreur explicite, jamais un redémarrage silencieux.

Les points de reprise suivent la conservation des données d’étape et la politique de données personnelles (PII) du tenant. L’anonymisation « avant la base de données » transforme également l’état sauvegardé ; les données supprimées ne peuvent pas être reconstruites à la reprise. Aucune politique de délai ou d’expiration n’est ajoutée.

Les suggestions restreintes doivent utiliser des libellés non sensibles. Si l’anonymisation modifie ces libellés, l’Agent échoue explicitement avant de poser la question, plutôt que de fusionner des choix distincts ou de rejeter indéfiniment des réponses valides.

Déployez des Workers compatibles avant d’activer les questions. Avant un retour à une version sans prise en charge des points de reprise, terminez ou annulez les exécutions Agent en attente : les anciens Workers ne peuvent pas reprendre cet état en sécurité. Aucune migration de base de données n’est nécessaire.

Fournisseurs

Les appels natifs utilisent des identifiants normalisés et des arguments JSON objets. Azure OpenAI et vLLM avec prise en charge des outils utilisent la boucle native. L’API personnalisée utilise ReAct par défaut, sauf si son connecteur déclare native_tools: true.

Pour Bedrock/WatsonX, configurez native_tools selon les capacités du modèle choisi. Les identifiants du connecteur fournissent la valeur par défaut ; la configuration existante extra.native_tools la remplace pour un Agent/modèle. La valeur doit être un booléen. Utilisez false pour un modèle ou serveur sans outils natifs. La même limite de tours s’applique aux chemins natif et ReAct.

AdaptateurAPI des outils
Azure OpenAIChat Completions pour les déploiements compatibles ; point d’accès /openai/v1/responses de la ressource lorsque l’API refuse explicitement les outils de fonction avec raisonnement
OpenAI (si activé)Chat Completions, avec le même routage vers Responses pour cette incompatibilité explicite entre raisonnement et outils
BedrocktoolConfig de Converse, avec les résultats d’outils parallèles regroupés dans un message utilisateur et le raisonnement signé conservé
WatsonXModelInference.chat, avec tool_choice_option pour les choix textuels et les paramètres de tokens et d’échantillonnage propres au chat
vLLM / API personnalisée/v1/chat/completions compatible OpenAI ; un suffixe de version déjà présent dans l’URL n’est pas dupliqué

Le routage vers Responses conserve le déploiement/modèle et ses paramètres de raisonnement ; il ne force jamais automatiquement reasoning_effort à none. Les appels Chat Completions compatibles restent inchangés. Les appels Responses sont retournés en bloc, utilisent store: false et transmettent les éléments de sortie conservés localement, sans dépendre d’une réponse stockée par le serveur. Un paramètre configuré sans équivalent dans Responses provoque une erreur explicite. Le déploiement et la région doivent prendre en charge cette API ; le routage ne donne aucun droit d’accès supplémentaire au modèle et ne contourne pas les restrictions du fournisseur.

Azure/OpenAI réessaie sans top_p lorsque le fournisseur refuse explicitement ce paramètre comme non pris en charge, y compris si les champs code ou param sont absents de l’erreur. Cette nouvelle tentative est journalisée et conserve les paramètres de raisonnement. Les valeurs de paramètres invalides et les températures non prises en charge différentes de la valeur par défaut provoquent toujours une erreur explicite.

L’état de raisonnement du fournisseur reste privé dans le point de reprise : il ne devient ni historique de conversation ni texte publié. Le raisonnement signé ou chiffré doit rester inchangé ; l’anonymisation ne peut pas inspecter le contenu chiffré. Si le filtrage avant la base de données modifie le contexte de raisonnement existant ou l’état de continuation du fournisseur, l’Agent échoue avant la sauvegarde, plutôt que de corrompre cet état ou de contourner la politique PII. Les nouveaux résultats d’outils non encore envoyés au fournisseur peuvent toujours être anonymisés. Ces données suivent la même limite de taille et la même politique de conservation que le point de reprise.

vLLM et l’API personnalisée conservent leur repli journalisé vers les outils décrits dans le prompt uniquement lors d’un refus explicite des outils natifs. Les schémas d’outils invalides, les échecs d’authentification et les incompatibilités entre raisonnement et point d’accès sont signalés, sans changement silencieux de stratégie.

Observabilité

SignalSignification
agent.question_asked, agent.resumedÉvénements du flux d’exécution et traces : longueur de question, nombre de suggestions et durée d’attente, sans le contenu des échanges
agent_questions_asked_total, agent_questions_answered_totalCompteurs de questions et de réponses
agent_questions_per_runNombre de questions observé à la fin d’une exécution avec questionnement
agent_answer_latency_msAttente avant une réponse acceptée
agent_waiting_human_runsNombre d’exécutions Agent sans réponse, par tenant, aux transitions d’exécution

Le nombre en attente indique du travail sans réponse, pas une nouvelle définition automatique de l’abandon. Aucun texte de question ni identifiant d’exécution ne sert de label de métrique.

Consultez le guide d’activation des questions pour la configuration et les tests.

On this page