Saplings désigne ici le package Python open source shobrook/saplings. Il permet à un agent à outils d’explorer plusieurs trajectoires avec Monte Carlo Tree Search (MCTS), A* ou greedy best-first search. Ce n’est ni Sapling, le gestionnaire de source de Meta, ni l’ancien package homonyme de l’auteur désormais renommé Syntaxis. L’implémentation actuelle passe par LiteLLM pour le modèle et par un evaluator—un LLM par défaut—pour noter les branches.
Il faut le considérer comme une couche de recherche pour prototypes, outils réversibles et tâches bornées, pas comme une plateforme d’agents production. Il peut quitter une mauvaise trajectoire ultérieure, mais chaque candidate tool exploré peut être réellement exécuté avant la sélection. Calcul, retrieval, code sandboxé et simulateur sont de bons premiers tests ; email, paiement, ticket ou write en base exigent une frontière externe preview/commit.
Identité exacte et état de maintenance
| Contrôle | Vérifié le 2026-08-20 | Interprétation |
|---|---|---|
| Projet canonique | GitHub shobrook/saplings ; PyPI saplings | Ne pas confondre avec Meta Sapling SCM ou Syntaxis |
| Dernier package | PyPI 6.2.0, upload 22-06-2025 | Installable, mais environ quatorze mois sans release |
| Repository | Public, non archivé ; dernier push 27-07-2025 | Les derniers commits touchent le README ; dernier fix code visible 22-06-2025 |
| Distribution | Sdist 33 kB ; aucun wheel 6.2.0 listé | pip construit localement |
| Metadata runtime | Python >=3 ; litellm/json-repair non bornés | Trop large pour prouver la compatibilité Python actuelle |
| Licence | LICENSE Apache-2.0 ; setup.py/PyPI indiquent MIT | Conflit, pas double licence explicite—clarification nécessaire |
Le statut défendable est disponible mais silencieux. Le repository n’est ni archived ni disabled et PyPI sert encore 6.2.0 ; déclarer le projet arrêté dépasserait donc les preuves. À l’inverse, une page active ne garantit pas une maintenance de compatibilité ou sécurité. Il n’existe pas de GitHub Releases, aucun fichier PyPI après juin 2025 et le sdist 6.2.0 n’embarque ni testsuite ni benchmark harness. Il faut verrouiller package et dépendances transitives, puis tester sa propre matrice Python/modèles/tools.
Le conflit de licence est un gate séparé. Le repository et le sdist contiennent le texte Apache License 2.0, tandis que setup.py déclare MIT et PyPI répète ce champ. Ce n’est pas une option dual-license documentée. Avant redistribution, intégration ou fork, demander une clarification écrite au maintainer, conserver les notices et laisser compliance déterminer les termes applicables.
Choisir un agent Saplings
| Classe | Comportement de recherche | Frontière coût/échec |
|---|---|---|
| COTAgent | Une trajectoire normale, sans search | Baseline peu coûteuse pour valider tools et evaluator |
| GreedyAgent | Génère, exécute et note des candidates puis poursuit le meilleur courant | Moins d’overhead, sans retour depuis un mauvais optimum local |
| AStarAgent | Garde des frontiers alternatives et peut changer de branche | Compromis ; un mauvais evaluator ordonne mal la frontier |
| MonteCarloAgent | Selection, rollout, backpropagation ; defaults 6.2.0 : facteur 3, profondeur 5, 10 rollouts | Plus de calls/effects possibles ; un seul root tool call avant les branches |
| Custom evaluator | Retourne score normalisé et reasoning sur mesure | Tests, contraintes exactes et rewards d’état dépassent un LLM jugeant son texte |
Un arbre ne dépasse pas sa value function. Le default evaluator envoie la trajectoire au modèle, demande 0–10, puis normalise en 0–1. Pratique en prototype, il peut confondre progrès plausible et tâche terminée. Coding doit employer compilation/tests, retrieval la couverture des sources, un environnement le vrai state reward. Conserver un holdout fixe est essentiel : changer le prompt evaluator peut modifier le search autant qu’un changement d’algorithme.
MCTS possède une limite spécifique. Il force d’abord un tool call, construit le root node, puis seulement développe les branches. Un TODO source reconnaît qu’un mauvais root peut compromettre l’arbre entier. Le système compare et backtracke des actions ultérieures, mais ne choisit pas entre plusieurs premières actions indépendantes. Une review limitée à « look-ahead et backtracking » manquerait cette différence.
Workflow d’évaluation sûr et reproductible
- Figer l’artefact.Environnement isolé,
saplings==6.2.0, lock transitif et hash du sdist. - Gate licence.Documenter Apache-2.0 contre MIT dans l’approbation dependency.
- Commencer par COTAgent.Mesurer success, coût, latence et correction des tools sans search.
- Tools replay-safe.Séparer propose/preview de commit ; sandbox, state cloné et idempotency key par branche.
- Evaluator objectif.Tests, schema, règles exactes, simulator state et sources avant self-score LLM.
- Borner l’arbre.Configurer branching factor, depth, rollouts, timeout et budget provider.
- Instrumenter.Tracer branch/parent, arguments, résultat, score, modèle, tokens, latence, retry et exception avec redaction.
- Matrice fixe.Comparer COT, Greedy, A* et MCTS avec mêmes prompts, mocks, evaluator et seeds disponibles.
- Échecs.API outage, output malformé, rate limit, action répétée, fausse preuve, truncation et désaccord evaluator.
- Un seul commit.Search produit plan, patch ou candidat ; validator ou humain autorise un write externe.
- Data path.Library locale, mais LiteLLM peut transmettre prompts, schemas et trajectories au provider choisi.
- Exit.Encapsuler Saplings derrière sa propre interface pour remplacer le dependency sans réécrire les tools.
Ce que le README compact ne résout pas
| Risque | Cause en 6.2.0 | Contrôle |
|---|---|---|
| Side effects répétés | BaseAgent exécute tous les candidate tools avant notation | Chercher sur tools purs/simulés, commit unique après sélection |
| Croissance des calls | Generation, evaluation et rollouts appellent modèles/tools | Budgets durs, timeout, cache safe read et coût par tâche résolue |
| Evaluator bias | Value par défaut = autoévaluation LLM | Rewards objectifs, plusieurs evaluators, audit humain |
| Root lock-in | MCTS crée un required root avant branch | Valider un plan ou modifier la stratégie root |
| Dependency drift | litellm/json-repair sans ranges | Lock transitif et CI d’upgrade |
| Privacy/security | Modèle voit prompt/schema/trajectory ; tool reçoit trajectory memory | Minimisation, redaction, least privilege, governance provider |
| Maintenance/licence | Releases silencieuses et metadata contradictoire | Pin/fork, scan, owner, clarification écrite |
Les side effects des branches sont la principale conclusion opérationnelle. BaseAgent.expand crée un async task pour chaque candidate, exécute le tool, puis seulement évalue les child nodes. Backtracking n’annule pas l’effet. Explorer trois variantes send_email peut envoyer trois emails même si un seul path est rendu. L’architecture sûre cherche sur descriptions, state simulé ou patches réversibles et n’expose l’action irréversible qu’après la fin.
Aucun multiplicateur de coût fixe n’est défendable. Les provider calls dépendent d’early termination, dedup, depth, rollouts, evaluator samples, tools et retries. Mesurer coût par tâche acceptée, p50/p95 latency et duplicate effects. La table benchmark du README cite le paper LATS ; ce n’est pas une reproduction Saplings 6.2.0, et le sdist n’inclut aucun runner établissant ces gains.
Saplings et alternatives réelles
| Option | Meilleur cas | Trade-off face à Saplings |
|---|---|---|
| Saplings | Petit essai Python ajoutant MCTS/A*/greedy aux tool calls | Lisible ; maintenance silencieuse, pas de runtime durable, effets à contrôler soi-même |
| ReAct/tool loop simple | Tâches séquentielles peu coûteuses avec tools vérifiables | Pas de backtracking, mais coût et writes plus prévisibles |
| LangGraph | Workflows stateful avec persistence, streaming, human review, durable execution | Plus d’orchestration ; state, checkpoints et commit gates explicites |
| LLM Reasoners | Recherche MCTS/ToT/world models et reproduction benchmark | Plus large/lourd, mieux adapté à l’étude d’algorithmes |
| Search maison | Domain simulator, reward exact et stricte policy d’effets | Plus d’ingénierie, contrôle total branches/cache/budget/transaction |
Jugement indépendant :la qualité majeure de Saplings est sa lisibilité. Search loop, Tool abstraction et evaluator se lisent sans grande plateforme, ce qui convient à l’apprentissage et au proof of concept borné. La faiblesse est l’écart entre search research et production orchestration : aucune persistence, approval queue, rollback transactionnel, durable checkpoint ou security policy publiée.
Adopter si l’environnement est clonable à faible coût, le reward objectif et les tools réversibles. Pour un service durable, posséder un fork avec locks, tests, tracing, security et licence clarifiée, ou intégrer la policy dans un runtime maintenu. Un benchmark du paper reste une hypothèse à tester sur les tâches privées, pas une validation de déploiement.
Questions fréquentes
Qu’est-ce que Saplings ?
Une bibliothèque Python de shobrook/saplings qui applique Greedy, A* ou MCTS aux trajectoires d’outils, avec LiteLLM et un evaluator de branches.
Est-il maintenu ?
Disponible et non archivé, mais silencieux. PyPI 6.2.0 date du 22-06-2025 et le dernier push du 27-07-2025. Une maintenance continue n’est pas démontrée.
Est-ce Meta Sapling ?
Non. Meta Sapling est un SCM. Ici il s’agit du package AI-agent de Jonathan Shobrook ; un ancien homonyme est devenu Syntaxis.
Quelle licence ?
Repo/sdist fournissent Apache-2.0, setup.py/PyPI disent MIT. Le maintainer doit clarifier ; compliance ne doit pas choisir silencieusement.
Tree search améliore toujours ?
Non. Elle aide si les branches sont évaluables, mais multiplie les calls et amplifie un evaluator faible. Les chiffres README viennent de LATS.
Modèles locaux ?
LiteLLM propose des routes locales, mais tool calling, structured output et token counting doivent être testés par modèle.
Pourquoi les write tools sont dangereux ?
Les candidates sont exécutés avant sélection. Utiliser preview, sandbox et un seul commit post-search.
Alternative ?
Plain loop pour simple, LangGraph pour durable approval, LLM Reasoners pour recherche, search maison avec simulator/reward exact.
Sources vérifiées
- shobrook/saplings repository and README
- Saplings 6.2.0 on PyPI
- PyPI project metadata API
- Repository and source-distribution LICENSE
- Saplings setup.py package metadata
- BaseAgent source: branching, execution and evaluation
- MonteCarloAgent source and defaults
- LiteLLM model wrapper source
- Language Agent Tree Search paper (ICML 2024)
- Tree Search for Language Model Agents paper
- LiteLLM provider documentation
- LangGraph official overview
- LLM Reasoners official repository
- Official Saplings README demo image
Revue indépendante : 2026-08-20. Entité confirmée par GitHub/PyPI. Le statut disponible mais silencieux, le conflit de licence et la distinction benchmark paper/package restent explicites.
