Keyboard shortcuts

Press ← or → to navigate between chapters

Press ? to show this help

Press Esc to hide this help

id: ADR-008 title: Ancrer le mode objectif dans le plan de contrôle des tâches durables date: 2026-06-25 status: accepted relates-to:

  • https://github.com/zeroclaw-labs/zeroclaw/issues/8303
  • https://github.com/zeroclaw-labs/zeroclaw/issues/7929
  • https://github.com/zeroclaw-labs/zeroclaw/pull/8217
  • crates/zeroclaw-runtime
  • crates/zeroclaw-config
  • crates/zeroclaw-tools

ADR-008 : Mode d’objectif d’ancrage dans le plan de contrôle des tâches durables

Contexte

Le mode objectif transforme une interaction avec un agent d’une réponse unique en un travail autonome orienté vers un objectif utilisateur. Un objectif peut survivre au message entrant qui l’a initié, se mettre en pause en attendant une entrée ou une dépendance externe, reprendre après un redémarrage du daemon, et consommer des ressources de modèle sur plusieurs appels de travail, de vérification ou délégués.

Ce type de travail nécessite une autorité durable unique pour son cycle de vie. Le système doit être en mesure de déterminer quel travail est actif, quel travail est éligible pour exécuter un nouveau tour, quel travail est en pause, quel travail est terminal, et quel acteur ou route est autorisé à le reprendre ou l’annuler. Une convention de prompt ou un registre parallèle rendrait ces réponses dépendantes d’un état dupliqué.

La comptabilité budgétaire ajoute une contrainte supplémentaire de source de vérité. Les tokens et les coûts sont des faits produits par les appels aux fournisseurs de modèles. Le budget restant est dérivé d’une limite et de l’utilisation consommée ; le stocker comme son propre compteur mutable créerait un second système de comptabilité.

Le mode objectif franchit également une limite de confiance. Une commande slash et une requête générée par un modèle peuvent toutes deux exprimer qu’un objectif doit démarrer, mais ni l’une ni l’autre ne doit pouvoir auto-autoriser des faits d’exécution de confiance tels que l’identité de l’appelant, la route, le canal ou l’éligibilité de l’agent.

Les principales options envisagées étaient le chat multi-tours ordinaire avec guidage par prompt, un sous-système d’objectifs séparé, ou l’ancrage du mode objectif dans le plan de contrôle de tâches durables existant avec un état d’extension spécifique aux objectifs.

Décision

Nous ancrerons le mode objectif dans le plan de contrôle des tâches durables plutôt que de construire un système de tâches objectif parallèle.

Le plan de contrôle des tâches est la source de vérité pour le cycle de vie des objectifs, la propriété, la route, le principal, la relation parent et l’éligibilité à la reprise. L’état spécifique à un objectif peut étendre les enregistrements de tâches, mais il ne doit pas dupliquer les informations de cycle de vie, d’identité, de route, d’horodatage, de livraison ou d’état terminal appartenant à l’enregistrement de tâche.

L’utilisation de modèle consommée reste la propriété du registre d’utilisation canonique. Les budgets d’objectif sont des limites interprétées par rapport aux enregistrements d’utilisation ; le budget restant est toujours dérivé, jamais stocké comme un second total mutable.

La pause, la reprise, l’annulation, la récupération après redémarrage et la complétion sont des décisions de politique du plan de contrôle. Le texte d’une invite peut expliquer ou demander ces transitions, mais il ne les autorise pas.

Tous les chemins d’entrée des objectifs utilisent un unique point d’admission de confiance côté Rust. Le contexte d’exécution fournit des faits fiables tels que la surface, le canal, le principal, la route et l’éligibilité de l’agent ; les arguments fournis par le modèle ne peuvent pas déclarer ces faits.

L’achèvement de l’objectif nécessite une décision d’achèvement explicite de la part du contrôleur d’objectif. Le silence, l’absence d’autres appels d’outils ou un message de l’assistant qui semble final ne suffisent pas à marquer le travail autonome durable comme terminé.

Conséquences

Le mode Goal hérite du cycle de vie existant des tâches supervisées au lieu d’ajouter un second registre de tâches. Cela permet de conserver la récupération après redémarrage, l’annulation et les futures améliorations de la supervision rattachées à un seul contrat du plan de contrôle.

Le plan de contrôle devient responsable de la distinction entre les travaux d’objectif en pause mais reprenables et les travaux terminaux, perdus ou encore en cours d’exécution. Cela accroît l’importance des transitions précises d’état des tâches et de la politique de reprise après redémarrage.

Le contrôle des budgets devient auditable, car la consommation est dérivée des enregistrements d’utilisation faisant autorité. Cela signifie également que le mode objectif ne peut pas produire de résultats corrects tant que chaque appel de modèle susceptible d’imputer des dépenses à un objectif ne signale pas son utilisation avec l’attribution à cet objectif.

La délégation et le travail en arrière-plan doivent respecter les mêmes limites de cycle de vie et d’utilisation. Le travail qui ne peut pas signaler son achèvement et son utilisation à l’objectif propriétaire ne peut pas participer au mode objectif en toute sécurité.

Un point de contrôle d’admission unique et fiable empêche les chemins d’entrée initiés par les commandes et les modèles de devenir des systèmes d’autorisation distincts. Le coût est que chaque surface prise en charge doit acheminer l’entrée des objectifs via le mécanisme partagé de commande/admission.

Les choix d’implémentation détaillés, notamment la syntaxe des commandes, l’inventaire des raisons de pause, la forme des charges utiles, la configuration du vérificateur et la mise en production progressive, sont laissés aux plans d’implémentation et aux PRs de suivi. Ils doivent rester cohérents avec les limites de source de vérité définies dans ce ADR.

Références