Documentation / Exploitation / Référence / Assistant de workflow et jeux de test

Assistant de workflow et jeux de test

L’authoring s’exécute sur l’endpoint Restate, qui charge les plugins et les providers de l’instance. Les clés et les variables ASSIST_* doivent être disponibles dans ce processus. Après une mise à jour, redémarrer l’endpoint et enregistrer son déploiement ; l’enregistrement automatique inclut les deux services ci-dessous.

Service Persistance
meridianWorkflowAssist Objet par session ; échanges sérialisés, historique et propositions conservés dans Restate
meridianWorkflowTests Workflow par lancement ; un pas journalisé par cas de test

Les appels au modèle et les outils de l’assistant sont journalisés séparément. Le navigateur ne conserve que les identifiants de session/lancement, par fichier de workflow, pour reprendre leur suivi. Les contenus des échanges et les données simulées vivent dans le stockage Restate et suivent sa politique de conservation.

API

Appel Corps ou résultat
POST /api/workflows/assist { instruction, spec?, file?, sessionId?, turnId? } → 202 { sessionId, turnId, resultUrl, status: "queued" }
GET /api/workflows/assist/:id Session : running, completed ou failed, échanges, activité, proposition et tests
POST /api/workflows/tests { spec, file?, runId? } → 202 { runId, resultUrl, status: "queued" }
GET /api/workflows/tests/:id running, completed ou failed, puis rapport des cas

Une lecture sans état disponible renvoie 202 { status: "queued" }. Les identifiants sont des segments alphanumériques avec _ et -, jusqu’à cent caractères. turnId déduplique un échange dans sa session ; runId identifie un lancement unique. Réutiliser une session poursuit son historique. Une proposition ne sauvegarde ni ne publie le workflow.

L’instantané de contexte contient le catalogue, les manifestes chargés, leurs README distribués, la documentation d’authoring embarquée et les workflows actifs. Les outils ne lisent aucun chemin ni URL libre fourni par le modèle. Les sous-workflows des tests sont résolus dans cet instantané.

Variables du worker

Variable Défaut et limites
ASSIST_PROVIDER anthropic ; providers déclarés par l’instance également admis
ASSIST_MODEL claude-sonnet-4-6
ASSIST_REASONING_EFFORT high ; low, medium, high, off ; modèle compatible requis
ASSIST_THINKING_MODE Anthropic : adaptive ; manual pour les modèles Claude 4.5 détectés ou sur demande
ASSIST_MAX_ITERATIONS Absent ou 0 : aucun plafond d’appels modèle. Entier positif : budget explicite par échange, sans plafond imposé à 60.
ASSIST_CALL_TIMEOUT_MS 600 000 ms par appel ; borné entre 30 000 et 1 800 000
ASSIST_MAX_TOKENS Absent : 16 384 pour Anthropic, limite omise pour les compatibles OpenAI ; si défini, borné entre 2 048 et 128 000

Les réglages provider/modèle sont conservés au début d’une session. Une nouvelle session prend les réglages courants. Le budget d’appels est lu séparément au début de chaque nouvel échange : après modification de ASSIST_MAX_ITERATIONS et redémarrage de l’endpoint, la prochaine consigne reprend la même conversation avec le nouveau budget. Les échanges déjà en cours conservent le budget journalisé pour leur reprise durable. Les anciennes requêtes déjà en file avant cette évolution conservent leurs réglages enregistrés.

L’absence de budget permet à l’agent de poursuivre exploration, construction et tests jusqu’à soumission. Si un budget explicite est atteint, l’historique des outils est conservé ; une nouvelle consigne permet de poursuivre le travail. La limite de vingt échanges par session, les timeouts de chaque appel et les limites de contexte du modèle restent applicables. Aucun budget global lié à la requête HTTP ne coupe l’échange.

Anthropic utilise les blocs d’outils et de pensée signés du protocole Messages ; les compatibles OpenAI utilisent les appels de fonction et reasoning_effort. Avec un endpoint qui n’accepte pas ce paramètre, choisir off ou un modèle compatible. Références : Messages et pensée, Chat Completions.

Le test d’intégration pnpm test:authoring utilise un serveur Restate réel aux ports 18080 et 19070, un worker temporaire et un fournisseur simulé. Il vérifie l’arrêt/reprise du worker, la conversation, la déduplication et les tests positifs/négatifs, sans appel LLM payant.

97 documents2 sectionssource : /docs · généré au build