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.
Il s’agit d’une carte de classification, pas d’un plan de suppression. Ne supprimez pas et n’externalisez pas un outil tant que le remplacement ne préserve pas le contrat de l’opérateur : config, politique de sécurité, reçus d’outils, visibilité d’audit, compatibilité et rollback.
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/.
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 local. Ils sont enregistrés par default_tools et à nouveau par le registre complet.
| 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’envoi de messages doivent partager le backend de session daemon/gateway et les limites de propriété des 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. |
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 | Surface de mutation de l’état local. | Envisagez une délimitation plus claire entre les fonctionnalités et la configuration, car les deux modifient l’état local en dehors des flux de modification de fichiers standards. |
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. |
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. | Il provoque des effets de bord sur les dépôts locaux et distants, donc tout remplacement externe doit conserver les vérifications des politiques, les reçus et la visibilité explicite de l’opérateur. |
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.
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.