Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise

Contrôles du harnais et évaluation vérifiée

Statut : Actif

Portée : état actuel

Dernière revue : 2026-09-14

Responsable : runtime ax-code

Pour l’effort propre à un modèle, les commutateurs de réflexion et le rejeu du raisonnement, voir contrôles de raisonnement du modèle courant.

Contrôles facultatifs de contexte et d'outils

Activez chaque expérience indépendamment dans votre configuration AX Code :

{
  "experimental": {
    "context_recovery": true,
    "mcp_tool_discovery": true,
    "tail_reminders": true,
    "read_only_recipes": true
  }
}

Les quatre options sont désactivées par défaut. Mesurez le succès de la tâche et le temps écoulé avec votre modèle avant de les adopter ensemble. Elles conservent les permissions d’outils et les réglages d’isolation existants. Voir diagnostics de performance.

context_recovery expose context_recover et ajoute des pointeurs de source aux résumés de compactage réussis. L’outil accepte un mot-clé, un identifiant de message, un identifiant de partie facultatif et une limite de résultats. Il ne lit que la session courante, y compris l’historique d’avant compactage, et exclut la matière annulée, le raisonnement caché, et le texte ignoré ou synthétique. Il renvoie les identifiants d’origine de message et de partie, ainsi que des extraits bornés. La recherche parcourt au plus 100 parties par page et les 16,000 premiers caractères de chaque partie ; before continue vers des parties plus anciennes. Une correspondance manquante ne prouve pas que tout l’historique est dépourvu de ce texte. Les fourches utilisent leur historique copié et de nouveaux identifiants. Les affectations d’identifiants sont expurgées des extraits.

mcp_tool_discovery garde les outils intégrés disponibles et introduit tool_search pour les outils MCP connectés. Une recherche renvoie jusqu’à cinq schémas correspondants et rend ces outils disponibles à la requête de modèle suivante. Elle ne les exécute pas. Les sélections sont limitées à la session, bornées à 32 outils, et croisées avec l’admission courante à chaque requête. Les grands schémas peuvent être omis du résultat de recherche et chargés à la requête suivante. Si tool_search est refusé, le catalogue MCP admis ordinaire reste disponible. Un outil existant conflictuel nommé tool_search produit une erreur.

tail_reminders ne déplace que les rappels de tour dynamiques générés par AX Code vers la fin de la requête du fournisseur. Les messages utilisateur stockés, le raisonnement de l’assistant, l’historique d’outils et les instructions statiques restent inchangés. Cela peut changer le comportement du modèle et l’usage du cache ; cela n’établit pas à soi seul une amélioration de vitesse.

read_only_recipes expose read_recipe. Il exécute jusqu’à huit appels dépendants read, glob ou grep à travers le répartiteur d’outils normal. Chaque enfant a ses propres contrôles de permission, hooks, annulation et preuves de session. Une recette ne peut pas évaluer du code, exécuter des commandes shell, écrire des fichiers, appeler des outils MCP ni imbriquer une autre recette.

{
  "steps": [
    { "id": "files", "tool": "glob", "parameters": { "pattern": "src/**/*.ts" } },
    {
      "id": "source",
      "tool": "read",
      "parameters": { "filePath": { "$ref": { "step": "files", "path": ["paths", 0] } } }
    }
  ],
  "select": [{ "step": "source", "path": ["text"] }]
}

Les résultats glob canoniques contiennent paths et truncated ; les résultats grep contiennent matches avec path, line, text ; les résultats de lecture contiennent kind, text rendu et truncated. Sélectionnez un résultat précédent par son étape et le chemin de sa propriété propre. Les sélections de tableaux prennent en charge un filtre littéral contains et limit. Vérifiez l’état renvoyé et la troncature. La recette a une échéance d’annulation de 60 secondes, un budget d’arguments de 32KB, un budget intermédiaire de 192KB et une sortie finale bornée. L’annulation attend que l’outil possédé se stabilise. De nouvelles instructions de dépôt ou un média mettent l’exécution en pause et conservent la sortie enfant normale afin que le modèle les voie avant de continuer. Les sélections réussies ne remplacent les sorties intermédiaires que dans la requête du modèle ; les enregistrements enfants d’origine restent dans l’historique. Les parents interrompus conservent la sortie enfant.

Corriger une génération en cours

GET /session/{sessionID}/steering renvoie l’UUID de la génération active et les reçus récents. Incluez le paramètre de requête existant directory lorsque vous sélectionnez un projet à travers le serveur HTTP.

Envoyez POST /session/{sessionID}/steering avec :

{
  "expectedGeneration": "00000000-0000-4000-8000-000000000001",
  "clientID": "correction_1",
  "text": "Preserve the existing public function signature."
}

Utilisez l’UUID issu de GET, pas l’UUID d’exemple. accepted signifie que la correction est en attente. applied signifie qu’elle a été écrite comme message utilisateur à une frontière de boucle et inclut son identifiant de message ; cela ne garantit pas l’achèvement du fournisseur. rejected signifie qu’elle n’a pas été appliquée. Les hooks de cycle de vie peuvent opposer un veto à l’admission. Une correction acceptée prolonge d’une itération une génération qui allait s’achever, donc une correction envoyée sur la ligne d’arrivée est appliquée au lieu d’être rejetée ; l’annulation et les erreurs rejettent encore les corrections en attente, et une ancienne génération ne peut pas admettre du texte vers sa successeuse. Les nouvelles tentatives identiques renvoient le même reçu conservé ; un contenu différent sous un identifiant client existant renvoie HTTP 409. Le geste d’envoi immédiat ctrl+s du TUI utilise ce point de terminaison.

Appels d'outils parallèles dans une étape

Lorsque le modèle émet plusieurs appels d’outils dans un seul message d’assistant, le runtime les exécute en concurrence à travers une porte lecteur/écrivain limitée à la session. Les outils en lecture seule partagent la voie et se chevauchent ; les modifications de fichiers, bash, bash_input, les modifications de carnets, ops_apply, les outils MCP et tout batch contenant un enfant non sûr pour la concurrence prennent la voie exclusive et s’exécutent seuls dans l’ordre d’arrivée. Un appel abandonné pendant l’attente ne s’exécute jamais. Un lot garde sa propre barrière d’ordre pour les appels qu’il répartit, et les sessions enfants ont leur propre porte.

Les reçus sont locaux au processus, avec au plus 256 par session et 32 requêtes en attente. Les reçus terminaux et les entrées de session inactive peuvent être évincés. Après un redémarrage, obtenez la nouvelle génération et réconciliez les messages enregistrés ; cette API ne promet pas une consultation durable des reçus à travers les redémarrages. Le SDK généré expose session.steering et session.steer.

Orienter un suivi enregistré vers le tour en cours

POST /task-queue/{taskID}/steer admet le texte d’un suivi en file dans la génération en cours de la session, à sa prochaine frontière d’étape — le même point de livraison que POST /session/{sessionID}/steering — et annule la ligne de file dans la même requête, en enregistrant steeredInto (l’UUID de génération) et steeredAt sur la charge de la ligne pour l’audit. Les suivis seulement textuels jusqu’à 16,000 caractères sont orientables ; le texte orienté applique l’agent, le modèle et les outils du tour en cours. Les pièces jointes, les genres qui ne sont pas des suivis, les lignes déjà réglées et le texte trop grand sont rejetés avec HTTP 400, et une ligne qui bascule vers un autre état au milieu de la requête renvoie HTTP 409.

La réponse porte le dernier élément de file et un reçu nullable. Lorsqu’aucune génération n’est active, la ligne reste intacte et la réponse signale generation_not_active avec un reçu nul ; les appelants peuvent alors se rabattre sur POST /task-queue/{taskID}/send-now, qui ne fait que déplacer la ligne en tête de file et attend encore la fin du tour. Une ligne orientée n’est pas annulable, mais elle reste visible comme cancelled dans l’historique /queue avec ses champs d’audit.

Dans le TUI, le raccourci input_submit_steer (défaut ctrl+s) oriente le brouillon saisi lorsqu’il existe ; avec un compositeur vide sur une session occupée, il promeut plutôt le préfixe orientable de la file enregistrée en ordre FIFO, en s’arrêtant à la première ligne non orientable afin que les suivis ultérieurs ne la dépassent jamais. La section Suivis de la barre latérale et la boîte de dialogue /queue offrent la même action d’orientation immédiate par ligne, et un indice près des suivis en file montre la touche liée. Le SDK généré expose taskQueue.steer.

Proposer un skill à partir d'un travail vérifié

Les candidats de skill sont des enregistrements explicites dans le stockage local existant d’AX Code. Ils n’entrent pas dans la découverte des skills tant que vous ne les promouvez pas, et ils ne déclenchent jamais un appel de modèle automatique ni une réécriture d’instructions.

Créez un fichier JSON de proposition avec name, description, applicability, procedure et evidence contenant sessionID, messageID et partID. Les preuves doivent identifier un résultat verify_project original réussi, avec des enveloppes de test ou de vérification de types exécutées contre la révision Git propre courante. Une phrase de succès ou un code de sortie shell arbitraire ne suffit pas. La validation doit citer la vérification réussie d’une autre session à la même révision.

ax-code skill candidate propose --proposal proposal.json
ax-code skill candidate show verified-procedure
ax-code skill candidate validate verified-procedure --proposal independent-evidence.json
ax-code skill candidate promote verified-procedure
ax-code skill candidate retire verified-procedure

Gardez le JSON d’entrée hors du worktree ou dans un répertoire local ignoré, afin que le contrôle de révision propre reste significatif. La promotion crée .ax-code/skill/{name}/SKILL.md sans écraser un skill existant. Les preuves de source sont revérifiées avant la promotion. Les répertoires liés symboliquement sont rejetés. Le retrait ne supprime que le fichier inchangé propre au candidat ; les modifications manuelles provoquent un conflit. Redémarrez une instance de runtime existante pour rafraîchir sa découverte de skills en cache. Des contrôles réussis établissent des preuves pour ces contrôles ; revoyez l’applicabilité de la procédure avant la promotion.

Capturer une expérience appariée

Depuis une extraction des sources, utilisez :

pnpm --dir packages/ax-code exec tsx script/harness-eval.ts run /path/to/manifest.json > /path/to/runs.ndjson
pnpm --dir packages/ax-code exec tsx script/harness-eval.ts compare /path/to/runs.ndjson baseline candidate

Le manifeste d’opérateur de confiance contient un provider/model explicite, runtimeRevision, un argv CLI facultatif command, repetitions, timeoutMs, exactement deux arms nommés, et tasks. Chaque bras a des features facultatifs (les drapeaux expérimentaux ci-dessus) et toolProfile. Chaque tâche fournit id, prompt, un files en ligne (path/content) et un oracle. L’oracle est du JavaScript de confiance exécuté par Node après la sortie du processus de codage ; process.argv[1] identifie le jeu d’essai temporaire. Son code reste hors de l’espace de travail de l’agent et ne vient jamais de la réponse du modèle.

Chaque tentative obtient un jeu d’essai Git neuf. L’oracle doit échouer avec le code de sortie 1 sur le jeu d’essai initial. L’exécuteur utilise une invocation CLI sans interface fixe, alterne l’ordre des bras entre les répétitions, applique un délai, et exécute de nouveau l’oracle après une tentative achevée. elapsedMs inclut le processus de codage et la vérification après exécution ; verificationMs identifie cette dernière séparément. La préparation du jeu d’essai et le contrôle initial en échec sont exclus. Le flux enregistre chaque tentative achevée, échouée, expirée ou annulée à mesure qu’elle se termine. Les invites brutes, la sortie des sous-processus et les identifiants ne sont pas émis dans les enregistrements d’évaluation. Une cohorte interrompue reste incomplète et ne peut pas produire une comparaison appariée.

La comparaison rejette les doublons et les paires de tâche, de modèle, de cohorte ou de répétition manquantes ou non concordantes. Les tentatives échouées et non vérifiées restent dans les dénominateurs de taux de succès. Les médianes de latence et les ratios appariés sont explicitement conditionnés au succès vérifié. Le P95 exige 20 observations réussies dans une cellule tâche/modèle/cohorte/bras ; les agrégats de cellules mixtes l’omettent. La cohorte hache le manifeste, mais la révision du runtime et les conditions externes de fournisseur, de configuration et de cache exigent encore le contrôle de l’opérateur. Une petite exécution de fumée ne peut pas établir une supériorité générale de vitesse ni justifier un changement des défauts.

Sélection de capacité et diagnostics de reprise

Les requêtes autonomes peuvent inclure un paquet de contexte d’agent long lorsque le modèle a au moins 64,000 jetons de contexte, une prise en charge du raisonnement et une prise en charge des outils. Pour les modèles sans entrée de registre, les trois doivent être déclarés dans les métadonnées de modèle résolues. Le paquet supplémentaire a un plafond d’estimation de 2,048 jetons en caractères ; ce n’est pas la fenêtre de conversation. Les déclarations négatives explicites et les restrictions enregistrées empêchent l’admission. Cette optimisation du texte d’invite n’établit pas la compatibilité du cache ou de la réflexion préservée, et ne change pas les échéances ni la cadence automatiques de Super-Long. Celles-ci conservent leurs règles de qualification et de forçage existantes.

Deux échecs d’outils structurés consécutifs après le dernier message utilisateur (comptés avant les rappels de queue synthétiques) demandent un raisonnement plus profond au prochain appel de modèle lorsqu’une variante d’effort utilisable existe. Un résultat d’outil réussi remet le compte à zéro. L’effort explicite de l’utilisateur et les options de raisonnement configurées gardent la préséance. Cela change la sélection d’effort, pas les limites de nouvelles tentatives ni les permissions d’outils.

Les événements de rejeu locaux llm.request incluent capabilityResolution : protocole, fenêtre de contexte, le fait qu’un paquet de contexte ou le mode Super-Long ait été choisi, les échecs d’outils consécutifs, et la sélection de raisonnement ou une raison non appliquée. boundary: "policy-selection" décrit la décision d’AX Code ; les plugins et les SDK de fournisseurs peuvent encore modifier la requête finale. Les valeurs d’effort GPT-6 explicites sont préservées ; l’API exige low ou plus, plutôt que none ou minimal. L’événement conserve des hachages de requête plutôt que les corps d’invite ou d’identifiants. Une variante d’effort absente n’implique pas que la réflexion par défaut du fournisseur est désactivée.

La capture de harnais appariée lit les événements JSON step_finish et tool_use du CLI pour les jetons d’entrée, de sortie, de raisonnement et de lecture de cache, les appels d’outils achevés et les erreurs d’outils. Les identifiants de partie en double ne comptent qu’une fois. metricsStatus vaut observed, partial ou unavailable ; les flux tronqués ou mal formés et les tentatives interrompues retiennent les totaux. Les comparaisons signalent, pour chaque métrique, les comptes d’exécutions observées et manquantes ainsi que la médiane, y compris les tentatives échouées lorsqu’il existe des observations. Les valeurs manquantes restent manquantes. Ces compteurs décrivent les événements d’exécution émis, pas la facturation du fournisseur, l’usage des sessions enfants, ni les outils internes natifs du CLI. Un flux observé complet sans événements d’outils terminaux signale zéro appel d’outil. La vérification par l’oracle reste la source du succès de la tâche ; l’usage seul n’établit ni une reprise réussie ni une meilleure qualité.