Inventaire des outils intégrés
Utilisez cette page pour décider si un outil appelable par un agent doit rester dans le binaire principal, devenir feature-gated, passer à un plugin WASM, être livré sous forme de package de skill, ou utiliser une intégration MCP ou basée sur la CLI.
For the proposed tier of each tool the runtime registry builds, the core set the runtime retains, and why the runtime keeps more than the FND-001 baseline, see Tiers and the retained core set.
Wait, I need to correct myself: the source is English and must be translated to French. Here is the translation:
Pour le niveau proposé de chaque outil que le registre d’exécution construit, l’ensemble central conservé par l’exécution, et la raison pour laquelle l’exécution conserve davantage que la base de référence FND-001, voir Niveaux et ensemble central conservé.
Ceci est une carte de classification, et non un plan de suppression. Ne supprimez pas et n’externalisez pas un outil tant que son remplacement ne préserve pas le contrat opérateur : configuration, politique de sécurité, reçus d’outils, visibilité d’audit, compatibilité et retour arrière. Cette règle est la politique « cœur allégé » acceptée dans la RFC #6165 ; voir Politique de remplacement d’abord.
La source de vérité du registre runtime est crates/zeroclaw-runtime/src/tools/mod.rs, notamment default_tools, all_tools_with_runtime et register_skill_tools_with_context_and_runtime. Les implémentations d’outils partagées se trouvent principalement sous crates/zeroclaw-tools/.
Sélection par défaut visible par le modèle
La sélection minimale de référence est CORE_TOOL_NAMES dans crates/zeroclaw-config/src/builtin_tools.rs : onze outils intégrés, restreints par les politiques existantes de l’agent et de l’appelant. La valeur par défaut, [tools].optional = ["*"], correspond au mode complet ; en mode minimal, les outils intégrés supplémentaires doivent être nommés dans [tools].optional avant la construction. Consultez Outils minimaux et complets pour la disponibilité à la compilation et les instructions de récupération. Les plugins configurés, les serveurs MCP, les compétences et les périphériques conservent leurs propres chemins d’activation et d’autorisation.
Les catégories ci-dessous décrivent la propriété de l’implémentation et les emplacements futurs possibles. Elles ne déclarent ni le catalogue de modèles, ni n’autorisent la suppression d’une implémentation existante. git_operations reste parmi les onze approuvés, tandis que sa classification à long terme et ses exigences de remplacement préalable restent détaillées ci-dessous.
Catégories de classification
| Seau | Signification | Action suivante |
|---|---|---|
| Conserver intégré | Fait partie du contrat d’agent de base ou étroitement couplé à la politique d’exécution, aux reçus, à la mémoire, aux sessions ou à la délégation. | Conserver dans le core à moins que le contrat de l’agent ne soit modifié par un RFC. |
| Candidat à l’activation par commutateur de fonctionnalité | Le comportement de première partie reste du ressort de ZeroClaw, mais le coût lié aux dépendances, à la plateforme, à la taille binaire ou au risque opérateur ne devrait pas affecter les compilations minimales. | Ajouter ou resserrer un verrou de fonctionnalité/configuration avant d’envisager sa suppression. |
| Externaliser plus tard | Capacité utile, mais le propriétaire à long terme devrait être un plugin, un package de compétences, un serveur MCP ou une CLI externe car le comportement encapsule principalement un produit, une API de fournisseur ou un workflow optionnel. | Conserver la compatibilité jusqu’à ce que l’interface externe soit stable et documentée. |
| Aucune action pour le moment | Les données actuelles ne suffisent pas pour choisir un autre emplacement. | Conserver en place et revoir avec les justificatifs de la source, de l’utilisation et du remplacement. |
Conserver intégré
Ces outils forment la surface de travail minimale de l’agent en local. default_tools les enregistre avec deliver_file, un outil de niveau 2 qui n’est admis que pour les tours ACP, et le registre complet les enregistre à nouveau tous les sept.
| Outil(s) | Pourquoi ils restent |
|---|---|
shell | Exécute les commandes locales sous la politique de shell, le bac à sable, l’adaptateur d’exécution, la garde de chemin et les reçus de ZeroClaw. |
file_read, file_write, file_edit | Assumer le contrat de fichier de l’espace de travail, le comportement de persistance, la garde de chemin et la surface d’audit. |
glob_search, content_search | Fournir la découverte locale sans nécessiter de syntaxe de commande spécifique au shell. |
Ces outils de registre complet devraient également rester intégrés car ce sont des primitives d’exécution, de mémoire, de coordination ou de contrôle d’opérateur plutôt que des intégrations de produits optionnelles.
| Outil(s) | Pourquoi ils restent |
|---|---|
memory_store, memory_recall, memory_forget, memory_export, memory_purge | La mémoire à long terme est un contrat d’exécution de première partie et utilise les règles de propriété de la mémoire partagée. |
cron_add, cron_list, cron_remove, cron_update, cron_run, cron_runs, schedule | La planification affecte l’exécution autonome, la propriété et l’historique des exécutions ; gardez-la visible dans la politique dans core. |
spawn_subagent, delegate, send_message_to_peer | La délégation fait partie du modèle d’exécution des agents et doit partager les profils de risque, les outils, la mémoire et les contraintes parent/enfant. |
ask_user, escalate_to_human, reaction, poll, channel_room | Ce sont des primitives d’interaction d’opérateur de pontage de canaux avec des handles de canaux à liaison tardive et des reçus. |
sessions_current, sessions_list, sessions_history, sessions_send | La visibilité des sessions et l’accès à l’historique partagent le backend de session daemon/gateway ainsi que les frontières de propriété des agents. sessions_send est un ajout legacy obsolète à l’historique de discussion : il ne notifie pas et n’exécute pas de session. Utilisez send_message_to_peer pour la messagerie entre agents. |
model_routing_config, model_switch, proxy_config | Ceux-ci exposent le plan de contrôle de routage model/proxy actuel et ne doivent pas s’écarter du comportement de la source de configuration. |
TodoWrite | Maintient la liste de tâches structurées de l’agent dans la surface d’outils d’exécution ; conserve son nom d’outil stable et son comportement de cycle de vie dans le cœur. |
read_skill et les outils définis par skill avec kind = "shell", kind = "http", ou kind = "builtin" | Les Skills sont une surface d’extension intentionnelle, mais le pont d’exécution qui transforme les skills installés en outils est central. |
model_routing_config upsert_agent est une surface de mise à jour partielle : les champs omis concernant l’agent, le profil de risque et le profil d’exécution restent inchangés, et sa sauvegarde par chemins modifiés préserve les valeurs TOML et les commentaires non liés. Les contrôles explicites de risque ou d’exécution isolent le profil de l’agent nommé avant la modification, au lieu de modifier un profil partagé. Comme la délégation automatique de même risque compare les noms de profil, isoler un changement explicite de profil de risque peut supprimer cette relation implicite avec les anciens pairs du profil ; configurez les pairs comme délégués explicites si cette portée doit être conservée. L’outil refuse de modifier un schéma sur disque plus ancien tant que zeroclaw config migrate ne l’a pas mis à jour. L’outil écrit toujours en dehors de l’admission du commit de configuration ; la publication à l’exécution et la coordination entre écrivains concurrents sur le même chemin restent donc des préoccupations distinctes.
Candidats au verrou de fonctionnalité
Ces outils sont first-party aujourd’hui, mais ils méritent des frontières explicites de fonctionnalités/configuration car ils ajoutent une surface de plateforme, de dépendances, de réseau ou d’UI.
| Outil(s) | Limite | Classification |
|---|---|---|
browser, browser_open, browser_delegate, text_browser | Dépendant de la configuration et du runtime. | Conserver le premier partie, mais continuer à resserrer les contrôles des fonctionnalités/configurations car l’automatisation des navigateurs représente une surface de confiance importante. |
http_request, web_fetch, web_search_tool | Accès réseau contrôlé par la configuration. | Conserver la première partie tandis que SSRF, liste autorisée, routage des fournisseurs et comportement des récépissés restent sous la responsabilité de ZeroClaw. Ne réexaminer qu’après que les remplaçants MCP/plugin pourront exprimer la même politique réseau. |
Outils SOP (sop_list, sop_execute, sop_advance, sop_approve, sop_status et sop_workshop conditionnel) | Accès conditionné par le handle d’exécution ; sop_workshop nécessite également une mémoire procédurale. | Conserver en première partie ; le cycle de vie des SOP, les approbations, la mémoire procédurale et les enregistrements d’audit constituent un état d’exécution, et non une intégration externe générique. |
| Outils de plugins WASM | Pont hôte conditionné par des fonctionnalités de compilation et la configuration. | Conservez le pont hôte au premier tiers ; les fonctionnalités individuelles des plugins devraient se trouver en dehors du core. |
execute_pipeline | Chaînage d’outils contrôlé par la configuration. | Maintenir restreint jusqu’à ce que la politique de chaînage des outils, les reçus par étape et les listes d’autorisation des appelants soient suffisamment stables pour déterminer s’il s’agit d’une fonctionnalité centrale. |
knowledge | Surface de connaissances conditionnée par configuration. | Maintenir verrouillé tant que relationship memory et graph workflows sont encore en cours de promotion vers la documentation et les compétences côté utilisateur. |
file_upload, file_upload_bundle, file_download | Transfert de données conditionné par la configuration. | Garder l’accès restreint ; il s’agit d’outils de transfert de données sensibles aux politiques et nécessitent un remplacement explicite avant leur externalisation. |
backup, data_management | La sauvegarde modifie l’état local ; la gestion des données expose actuellement uniquement un aperçu de la rétention et les statistiques de stockage. | Conservez des limites de configuration explicites. Réactivez la purge confirmée de la gestion des données uniquement une fois que ses catégories gérées, son comportement de confirmation et d’audit, ainsi que son contrat de restauration sont définis. |
screenshot, image_info, canvas | Surface d’outil visuel/UI. | Conserver pour l’instant ; classer avec la surface/outil visuelle une fois les limites du plugin et du tableau de bord définies. |
llm_task | Exécution de sous-tâches dépendante du fournisseur. | Conserver jusqu’à ce que l’exécution de sous-tâche à portée de fournisseur ait un contrat distinct de la délégation. |
security_ops | Opérations de sécurité contrôlées par la configuration. | Maintenir verrouillé ; les opérations de sécurité nécessitent une visibilité sur les politiques first-party jusqu’à ce qu’un plugin puisse exposer des permissions, des accusés de réception et un rollback équivalents. |
verifiable_intent | Politique de confiance régie par la configuration. L’outil vi_verify est temporairement retiré du registre visible par le modèle. | Maintenez-les à accès restreint et fournis par le projet ; l’émission et la vérification des intentions influent sur la politique de confiance et doivent rester internes jusqu’à ce que la frontière des informations d’identification soit stable. Aucun vérificateur de chaîne n’existe encore ; vi_verify n’est donc pas enregistré, même lorsque verifiable_intent.enabled = true ; l’activation de la section ne fait pour l’instant qu’émettre un avertissement signalant cette lacune, consigné au démarrage du processus, de nouveau lors de chaque rechargement du démon et une fois de plus lorsqu’un zeroclaw config patch fait passer la section de désactivée à activée, et signalé par zeroclaw doctor et l’API de configuration sous la forme de l’avertissement de validation verifiable_intent_tool_withheld, afin qu’il subsiste malgré observability.log_persistence = "none". Le fait de ne pas exposer l’outil ne supprime pas les chemins de code de bibliothèque pour l’émission et la vérification, qui restent disponibles pour les intégrateurs. Ne rétablissez l’enregistrement que derrière un parcours de vérification et d’évaluation qui consomme le résultat vérifié d’une chaîne, en retirant les deux canaux dans cette même modification. |
Sondes matérielles (hardware_board_info, hardware_memory_map, hardware_memory_read) | Accès matériel contrôlé par les périphériques. | Conserver les composants de première partie lorsque les outils matériels sont ajoutés via le chemin du registre des périphériques et accéder aux périphériques physiques conformément aux règles d’autorisation ZeroClaw. |
web_fetch est niveau 1 parce que FND-001 D5 le classe comme essentiel, et sa restriction de configuration [web_fetch].enabled reste en place.
Externaliser plus tard
Ce sont les candidats les plus solides pour être déplacés hors du binaire principal une fois que la surface de remplacement existe. D’ici là, maintenez-les compatibles et visibles pour les politiques.
| Outil(s) | Dossier probable à long terme | Pourquoi |
|---|---|---|
notion, jira, microsoft365, google_workspace, linkedin, composio | Plugin, serveur MCP ou intégration basée sur CLI. | Ceux-ci encapsulent principalement des produits tiers et des modèles d’authentification qui peuvent évoluer indépendamment du runtime principal. |
claude_code, claude_code_runner, codex_cli, gemini_cli, opencode_cli | Intégration ou paquet de compétences basé sur la CLI. | Le CLI externe gère déjà l’authentification, le comportement des commandes et la cadence de publication ; ZeroClaw devrait préserver les reçus et la politique s’il les invoque. |
email_search, email_read | Plugin compagnon de canal ou serveur MCP. | La recherche/lecture d’e-mails est utile mais liée à l’authentification de compte externe et à la configuration du canal plutôt qu’au contrat d’agent de base. |
discord_search | Plugin compagnon de chaîne ou compétence de requête d’archive. | Cela dépend d’une base de données d’archives Discord générée par le canal ; conservez-la à proximité de ce canal jusqu’à ce que l’API d’archivage soit explicite. |
image_gen, cloud_ops, cloud_patterns, project_intel, report_template | Package de compétences, plugin ou serveur MCP. | Ce sont des workflows optionnels ou des wrappers de vendor/data-service plutôt que des primitives d’exécution de base. |
weather | Package de skill ou skill basé sur HTTP ; plus tard plugin ou serveur MCP si la parité nécessite un formatage personnalisé ou une politique. | L’outil intégré actuel est un wrapper sans clé de wttr.in. Une recherche minimale s’adapte à la forme de skill HTTP, mais l’externalisation complète nécessite encore la parité pour la sortie formatée, la politique de proxy tool.weather et le nom de l’outil intégré / le comportement d’auto-approbation. |
pushover | Chemin de notification commun via system.notify, ainsi qu’un plugin de service à portée restreinte. | Sa forme principale est la notification de périphérique, ce qui recoupe la capacité de nœud standard ; l’authentification spécifique à Pushover, la transmission, les modes de défaillance et la compatibilité des adaptateurs doivent encore être validés avant de sortir du runtime principal. |
git_operations | Intégration basée sur une CLI ou plugin au périmètre étroit. | Elle produit des effets de bord sur les dépôts locaux et distants. Tout remplacement externe doit donc préserver les vérifications de politique, les reçus et la visibilité explicite pour l’opérateur. Les opérations sur les worktrees valident chaque cible demandée et chaque chemin de métadonnées du worktree lié par rapport à l’autorisation de lecture/écriture applicable. La liste ne renvoie que les entrées dont le chemin de worktree se résout et dont les métadonnées peuvent être validées par l’autorisation de lecture applicable. Les liens symboliques de métadonnées sont rejetés plutôt que suivis, y compris lorsque leur cible serait autrement autorisée. Les commandes en lecture seule ne doivent pas exécuter les filtres de contenu, les vérificateurs de signature ou les commandes de diff de sous-modules imbriqués configurés dans le dépôt, ne doivent pas résoudre les mailmaps, ni inspecter l’état du worktree des sous-modules ; elles conservent en revanche les identifiants de commit des gitlinks modifiés du superprojet. Elles interdisent le transport Git et désactivent la récupération implicite des objets promisor, de sorte que les objets indisponibles d’un clone partiel échouent au lieu de déclencher un transport choisi par le dépôt. Les commandes classées en écriture préservent les hooks et filtres Git et appliquent la frontière de sandbox configurée par agent. Avec [runtime] kind = "docker", les commandes classées en écriture sont rejetées avant le lancement de toute commande Git de ce type, car Git n’entre pas dans le conteneur d’exécution ; les commandes classées en lecture restent inchangées, et l’outil shell demeure le chemin d’exécution de commandes dans le conteneur. En mode d’exécution natif, un sandbox sans effet (no-op) ne confine donc pas Git. Seul Landlock étend ce sandbox aux racines sœurs configurées ; les autres backends de sandbox peuvent rejeter les écritures en dehors de l’espace de travail de l’agent, monter l’espace de travail en lecture seule, omettre l’espace de travail ou masquer la configuration Git globale. |
git_operations est niveau 1 car FND-001 D5 le classe comme noyau. La ligne ci-dessus indique un emplacement ultérieur possible, qui nécessiterait d’abord de modifier D5.
claude_code, codex_cli, gemini_cli et opencode_cli sont de niveau 2 car ils s’exécutent via le bac à sable partagé du runtime ; l’externalisation reste une piste pour plus tard.
Aucune action pour le moment
Conservez ces surfaces en place jusqu’à ce qu’une autre tranche de conception produise de meilleures preuves :
calculator: minuscule, léger en dépendances, et suffisamment inoffensif pour que le déplacer puisse coûter plus de complexité que ce qu’il économise.tool_searchet activation différée de MCP : fait partie du flux de découverte MCP actuel, mais la frontière exacte à long terme dépend du travail plugin/MCP de la v0.8.2.- Outils de réinitialisation/suppression de session : des implémentations existent, mais le registre d’agents n’enregistre pas les variantes destructives non scopées par défaut. Maintenez cette frontière sauf si une surface opérateur/admin en a explicitement besoin.
Niveaux et ensemble de base conservé
Un niveau indique où un outil d’agent intégré doit être placé dans le contrat de composition du runtime proposé dans PR #11090 : construit par le runtime, ou candidat à une source d’outils détenue par l’application. Le test de niveau consiste à vérifier si l’outil peut être construit à partir du seul ToolRequest de ce contrat, c’est-à-dire à partir de config, agent_alias, de la SecurityPolicy résolue, du RuntimeAdapter sélectionné et du handle de mémoire de l’agent. Un outil est couplé à l’hôte s’il nécessite un autre handle de runtime, ou si le runtime modifie la façon dont il s’exécute en fonction de son nom : émission d’événements, admission des tours, rebinding de la mémoire, injection d’arguments, garde-fous de boucle, ou sélection des consignes de prompt. Les tables d’affichage et de description indexées par nom, comme la table des types d’outils ACP, la liste de divulgation des arguments Matrix et les descriptions d’outils de la boucle de l’agent, ne comptent pas. Les outils qui passent le test mais restent dans le runtime sont consignés comme des jugements au cas par cas. Si le contrat change avant sa fusion, mettre à jour ici le test de niveau pour le faire correspondre.
Cette classification est une proposition pour #10998, qui exige que l’ensemble de base approuvé, ainsi que la justification de toute dérogation, soit consigné dans le tableau de suivi des livraisons du runtime et de la passerelle, #7432.
Les niveaux indiquent qui construit un outil selon le contrat de composition ; les catégories ci-dessus indiquent son lieu d’accueil à long terme, de sorte qu’un outil peut être de niveau 2 et être un candidat à l’externalisation.
Les tableaux couvrent les outils que all_tools_with_runtime construit, ainsi que les quatre que l’assemblage du registre délimité crée. Ils omettent les outils périphériques du crate matériel, qui dépendent des cartes configurées ; les outils de plugins WASM, les outils définis par des skills et les wrappers MCP, dont les noms sont déterminés à l’exécution ; vi_verify, qui est délibérément retiré ; les outils de réinitialisation et de suppression de session, que le registre d’agent n’enregistre pas ; et skills_list, skill_view et skill_manage, que seule la revue de skills en arrière-plan, optionnelle, enregistre.
I don’t see any tables in your message, so there’s nothing to translate or edit yet. I also can’t open or change crates/zeroclaw-tools/src/inventory.rs from here. Please paste the three tier tables, and the relevant part of inventory.rs if you want them kept in sync. I’ll work from those.
Niveau 1 : essentiel
Tier 1 est l’ensemble de base conservé : la référence de base de FND-001 D5, inchangée, qui désigne les outils dont un agent utile a besoin sans aucun plugin installé.
| Outil | Pourquoi c’est essentiel |
|---|---|
shell | L’approche générale pour agir sur l’hôte, selon la politique du shell et l’adaptateur d’exécution. L’environnement d’exécution la construit sur le bac à sable propre à chaque agent, qu’il partage avec git_operations et les CLI de programmation. |
file_read | Lire l’espace de travail est le minimum pour toute tâche. Cela s’exécute derrière le garde de chemin. |
file_write | Écrit les résultats dans l’espace de travail, derrière le garde de chemin et les règles de persistance de l’environnement d’exécution. |
file_edit | Effectue des modifications précises sans réécrire les fichiers entiers, sous le même garde-fou que les écritures. |
glob_search | Trouve les fichiers de l’espace de travail sans dépendre de la syntaxe du shell. |
content_search | Recherche le contenu de l’espace de travail sans dépendre de la syntaxe du shell. |
git_operations | Travail sur le dépôt via la frontière de commandes Git du runtime, qui encapsule le même bac à sable partagé. |
memory_store | Le chemin d’écriture de la mémoire à long terme, un contrat d’exécution de première partie. |
memory_recall | Le chemin de lecture de la mémoire à long terme. |
memory_forget | Le chemin de suppression, afin que les souvenirs erronés ou indésirables puissent être supprimés. |
web_fetch | La capacité réseau minimale : une page, renvoyée sous forme de texte brut. |
web_fetch reste soumis à [web_fetch].enabled, dont la valeur par défaut est true.
Niveau 2 : couplé à l’hôte
Les outils de niveau 2 sont conservés dans le runtime au-delà de l’ensemble principal, et le runtime continue de les construire.
| Famille | Outils | Pourquoi le runtime continue de le construire |
|---|---|---|
| Planification | cron_add, cron_list, cron_remove, cron_update, cron_run, cron_runs, schedule | Le magasin cron d’exécution et le planificateur. Le runtime adapte aussi son comportement à cinq de ces noms : les consignes de dialecte shell pour cron_add, cron_update et schedule ; l’injection d’arguments approuvée par le runtime pour ces trois noms et pour cron_run ; les valeurs par défaut de livraison pour cron_add ; et les tours d’agent cron sans liste d’autorisation propre excluent cron_add, cron_update, cron_remove, cron_run et schedule. |
| Plan de mémoire | memory_export, memory_purge | Le registre scellé relie les cinq outils de mémoire ensemble lorsqu’une session est épinglée au plan de mémoire privé de son propriétaire, et la liste partagée des noms d’outils de mémoire les traite comme une seule unité. |
| Exécution de l’agent | spawn_subagent, delegate, send_message_to_peer | Ils démarrent des tours enfants ou pairs via la boucle d’agent du runtime et y transmettent l’appelant : sa politique de sécurité et le périmètre d’étape SOP pour spawn_subagent, sa politique de délégation et, pour les cibles bornées, ses plafonds pour delegate, et son identité en tant que principal du tour pair pour send_message_to_peer. delegate possède l’instantané des outils parents, et la boucle d’outils exempte spawn_subagent et delegate du regroupement des appels en double par nom. |
| Plan de contrôle | model_switch, model_routing_config, proxy_config | L’état de changement de modèle, limité au tour, que la boucle d’outils du runtime installe. Les deux derniers modifient la configuration : tous deux réécrivent le fichier de configuration, et proxy_config définit en outre le proxy d’exécution à l’échelle du processus que lisent les outils de requête HTTP et de récupération web. Ils peuvent être construits à partir des entrées de test par niveau, donc les conserver sous la responsabilité du runtime est un choix de jugement consigné ici. |
| Pont de canaux | ask_user, escalate_to_human, reaction, poll, channel_room, send_via, git_forge | Des tables de canaux à liaison tardive que l’assemblage renvoie à son appelant, qui les remplit ensuite ; reaction et git_forge partagent une même table, ask_user et send_via en partagent une autre. |
| Sessions | sessions_current, sessions_list, sessions_history, sessions_send | The ACP session read view, qui n’est transmise que par le chemin de l’agent ACP ; le backend de session lui-même est ouvert à partir de la configuration. |
| SOP | sop_list, sop_execute, sop_advance, sop_approve, sop_status, sop_workshop | Le moteur SOP et le journal d’audit. |
| Compétences | read_skill | |The skills loader, and the channel prompt path selects the skills prompt mode by whether read_skill is available. |
Wait, I need to be careful here. The source is in English and needs translation to French. Translation:
Le chargeur de compétences, et le chemin de prompt du canal sélectionne le mode de prompt des compétences selon que read_skill est disponible.|
|Liste des tâches|TodoWrite|Le runtime n’émet des événements de plan que pour ce nom, et c’est l’unique flux du suivi de tâches ZeroCode.|
|Canvas|canvas|La zone de travail partagée avec la passerelle.|
|Livraison ACP|deliver_file|Admis uniquement sur les tours ACP ; ses fonctions auxiliaires sont utilisées par le serveur ACP.|
|Lié au fournisseur|llm_task|Construit un fournisseur à partir des identifiants de l’agent, en dehors de la source du fournisseur.|
|Les CLI de programmation liées au bac à sable|claude_code, codex_cli, gemini_cli, opencode_cli|L’exécuteur de la CLI de codage encapsule l’adaptateur d’exécution et le bac à sable partagé. Activation facultative par configuration, mais construit à l’exécution.|
|Configuration en direct|a2a_discover, a2a_send, a2a_get_task, a2a_cancel, file_download|Ils détiennent le handle de configuration en direct ; le client A2A utilise également un cache de routes à l’échelle du processus.|
|Défini à l’exécution|security_ops|Réside dans le crate runtime et utilise ses modules de playbook de sécurité et de vulnérabilités.|
|Construit en dehors de l’usine|execute_pipeline, tool_search, mcp_resources, mcp_prompts|Généré par l’assemblage du registre délimité à partir du registre lui-même ou du registre MCP.|
La liste partagée des noms d’outils de mémoire est MEMORY_TOOL_NAMES dans crates/zeroclaw-tools/src/lib.rs.
Je n’ai pas reçu de chaîne à traduire. Pouvez-vous coller le texte anglais que vous voulez traduire en français ?
Les outils de niveau 3 peuvent être construits à partir de ToolRequest seul, le répertoire de travail étant repris depuis le SecurityPolicy résolu. Ils sont candidats pour la source d’outils détenue par l’application et pour une fonctionnalité d’outils optionnels (proposée sous le nom tools-extra).
| Famille | Outils | Enregistré avec une configuration par défaut |
|---|---|---|
| Utilitaires | calculator, weather, pushover, screenshot, image_info | Toujours |
| Navigateur | browser_open, browser, browser_delegate, text_browser | browser_open oui, car la section browser est activée par défaut ; les autres non. |
| Réseau | http_request, web_search_tool | Oui, les deux sont activés par défaut. |
| Intégrations SaaS | notion, jira, linkedin, composio, google_workspace, microsoft365 | Non |
| Rapport | project_intel, report_template | Non |
| Coureur de code | claude_code_runner | Non |
| Opérations | backup, data_management, cloud_ops, cloud_patterns | backup oui ; les autres non |
| Médias et transfert | image_gen, file_upload, file_upload_bundle | Non |
| Compagnons de canal | discord_search, email_search, email_read | Non |
| Knowledge | knowledge | Non |
L’enregistrement avec une configuration par défaut suit les valeurs par défaut de la configuration : [browser].enabled, [http_request].enabled, [web_search].enabled et [backup].enabled valent true par défaut, tandis que [browser].automation_enabled et toutes les autres gardes de cette table sont désactivées ou non définies. Neuf outils de niveau 3 sont donc enregistrés avec une configuration par défaut : calculator, weather, pushover, screenshot, image_info, browser_open, http_request, web_search_tool et backup. Les configurations existantes reçoivent ces neuf outils sans avoir à les activer explicitement ; toute gestion conditionnelle ultérieure doit donc d’abord migrer ces configurations.
Écart par rapport à la référence FND-001
FND-001 D5 nomme onze outils du noyau et indique : « Tous les autres sont enregistrés par les plugins installés. » Cette classification s’en écarte : 51 outils restent construits à l’exécution au-delà de ces onze. La plupart ont besoin d’un handle d’exécution que ToolRequest ne transporte pas, ou ont un comportement d’exécution qui dépend de leur nom. Les autres passent le test de niveau et sont conservés par jugement : cron_list et cron_runs, qui partagent le store cron avec le reste de l’ordonnancement ; security_ops, qui utilise les modules playbook et vulnérabilités du runtime ; et model_routing_config et proxy_config. llm_task construit son propre fournisseur ; selon le contrat, il faudrait la source des fournisseurs, que ToolRequest ne transporte pas. Ce qui devrait changer pour qu’une famille puisse être déplacée :
ToolRequesttransporte le bac à sable partagé par agent. Les CLI de codage pourraient ensuite être déplacées ;shelletgit_operationsrestent dans le cœur dans les deux cas.ToolRequesttransporte le handle de configuration actif. Les outils A2A etfile_downloadpourraient alors être déplacés.ToolRequesttransporte leChannelSourcede la génération, etChannelSourcepeut aussi lister les canaux en cours d’exécution. Ainsi, les outils de pont entre canaux recherchent les canaux au lieu de lire des dictionnaires que l’appelant remplit après l’assemblage. Le pont entre canaux pourrait alors être déplacé.ToolRequesttransporte la source du fournisseur de la génération.llm_taskpourrait alors être déplacé.- Le moteur SOP et le journal d’audit, la vue de lecture des sessions ACP et le magasin canvas accèdent aux outils via le contrat. Les familles SOP, sessions et canvas pourraient alors être déplacées.
- Le runtime reconnaît les outils de plan, de livraison, de mémoire, de planification et de lecture des compétences grâce à une identité typée, qu’il vérifie avec
ToolProvenance::Nativeet non sur la seule base du nom, y compris lorsqu’il sélectionne le mode de prompt des compétences. Le rattachement de la mémoire demande à nouveau à la source des outils avec le handle de mémoire routé. Les familles liste de tâches, livraison ACP, plan de mémoire et compétences pourraient alors être déplacées, de même quecron_add,cron_update,cron_remove,cron_runetschedule. security_ops,model_routing_config,proxy_config,cron_listetcron_runsne nécessitent aucune modification de contrat ; les déplacer relève d’une décision, et non d’un prérequis.- Aucune modification ci-dessus ne déplace l’exécution de l’agent,
model_switch, ni les quatre outils construits en dehors de la factory : ceux-ci dépendent de la boucle de tour ou du registre assemblé.
Aucune de ces modifications n’est proposée. PR #11090 garde ces éléments internes en dehors de ToolRequest afin qu’ils ne deviennent pas un contrat public, et un handle de configuration vivant remettrait en cause sa règle selon laquelle une requête appartient à une seule génération de configuration.
Ce que cette classification ne fait pas
- Il ne supprime, ne restreint ni ne déplace aucun outil. Le registre enregistre les mêmes outils dans les mêmes conditions qu’auparavant.
- Cela n’assouplit pas la politique de remplacement d’abord. Chaque suppression, mise en place de garde ou déplacement ultérieur nécessite toujours son propre ticket et sa propre PR, accompagnés de preuves de remplacement, y compris pour les outils de niveau 3.
Politique de remplacement prioritaire
I’m set up to translate English technical documentation strings into French, so I can’t run the RFC #6165 removal, feature-gate, or migration review. Your message also ends at “these rules:” with no rules listed.
If you have a string to translate, paste it and I’ll return the French version.
- Une intégration intégrée fonctionnelle reste disponible jusqu’à ce que son remplaçant soit réel, documenté et examiné de manière indépendante.
- La revue de remplacement doit couvrir la migration de configuration, la politique de sécurité, les reçus d’outils ou le comportement d’audit le cas échéant, la compatibilité et le retour arrière.
- Chaque suppression concrète, feature gate ou migration nécessite sa propre issue et sa propre PR, accompagnée de la preuve de remplacement correspondante.
- Le RFC ne pré-approuve aucune suppression, aucun mécanisme de activation conditionnelle (feature gate), aucune migration ni aucun changement de comportement à l’exécution.
- Le nettoyage du schéma V4 fait l’objet d’une décision distincte, dans le cadre de #8310. Il ne constitue pas une exception générale permettant de supprimer une intégration fonctionnelle sans chemin de remplacement.
Les règles de migration ci-dessous sont les questions auxquelles cette revue doit répondre avant qu’un outil intégré ne quitte le cœur.
Règles de migration
Avant de déplacer un outil hors du cœur, le remplacement doit répondre :
- Quelle config reste first-party, et quelle config est déplacée vers le plugin, le skill, le serveur MCP ou la CLI ?
- Comment le remplacement préserve-t-il les contrôles d’autonomie, les listes d’autorisation/refus, les reçus d’outil, les journaux d’audit et l’attribution ?
- Comment les configurations existantes échouent ou migrent lorsque l’outil intégré disparaît ?
- Les opérateurs peuvent-ils voir que la capacité est installée, activée, désactivée, bloquée ou manquante ?
- Quel est le chemin de rollback si le package externe casse ?
Si une preuve de code est nécessaire pour une tranche future, choisissez un candidat à faible rayon d’explosion dans le tableau « Externalize later » et validez le chemin de remplacement sans supprimer l’outil intégré dans la même PR.