Saplings bezeichnet hier ausschließlich das Open-Source-Python-Paket shobrook/saplings. Es lässt Tool-Agents mehrere Trajektorien mit Monte Carlo Tree Search (MCTS), A* oder Greedy Best-First Search untersuchen. Es ist weder Metas Sapling-Versionsverwaltung noch das ältere gleichnamige Paket des Autors, das inzwischen Syntaxis heißt. Die aktuelle Implementierung ruft Modelle über LiteLLM auf und lässt einen Evaluator—standardmäßig ebenfalls ein LLM—Kandidaten bewerten.
Die Bibliothek eignet sich am ehesten als überschaubare Suchschicht für reversible Tools, Simulationen und begrenzte Aufgaben, nicht als fertige Production-Agent-Plattform. Sie kann spätere Fehlentscheidungen durch einen anderen Zweig umgehen. Allerdings werden untersuchte Tool-Kandidaten gegebenenfalls real ausgeführt, bevor der Gewinner feststeht. Rechnen, Retrieval, Sandbox-Code und simulierte Umgebungen sind vernünftige erste Tests; E-Mail, Zahlung, Ticket oder Datenbank-Write brauchen eine externe Preview/Commit-Grenze.
Eindeutige Identität und Wartungsstatus
| Prüfung | Stand 2026-08-20 | Bedeutung |
|---|---|---|
| Kanonisches Projekt | GitHub shobrook/saplings; PyPI saplings | Nicht mit Meta Sapling SCM oder Syntaxis vermischen |
| Letztes Paket | PyPI 6.2.0 vom 22.06.2025 | Installierbar, aber etwa 14 Monate ohne Release |
| Repository | Öffentlich, nicht archiviert; letzter Push 27.07.2025 | Letzte Änderungen betreffen README; letzter sichtbarer Code-Fix 22.06.2025 |
| Distribution | 33-kB-Source-Distribution, kein 6.2.0-Wheel gelistet | pip baut lokal |
| Runtime-Metadaten | Python >=3; litellm/json-repair ohne Versionsgrenzen | Zu weit gefasst, um aktuelle Python-Kompatibilität zu belegen |
| Lizenz | LICENSE ist Apache-2.0; setup.py/PyPI nennen MIT | Widerspruch statt klarer Doppellizenz—Klärung nötig |
Der belastbare Status lautet verfügbar, aber still. Das Repository ist weder archiviert noch deaktiviert und PyPI liefert 6.2.0 weiter; „eingestellt“ wäre daher nicht belegt. Umgekehrt beweist eine erreichbare Paketseite keine laufende Kompatibilitäts- oder Sicherheitsarbeit. Es gibt keine GitHub Releases, keine neuere PyPI-Datei nach Juni 2025 und im 6.2.0-Sdist weder Testsuite noch Benchmark-Harness. Paket und transitive Abhängigkeiten müssen gelockt und gegen die eigene Python-, Modell- und Tool-Matrix getestet werden.
Der Lizenzkonflikt ist ein eigener Freigabepunkt. Sowohl Repository als auch Source-Distribution enthalten den vollständigen Text der Apache License 2.0. setup.py deklariert dagegen MIT und PyPI übernimmt diese Angabe. Das ist keine dokumentierte Wahlmöglichkeit zwischen zwei Lizenzen. Bei Redistribution, Produktintegration oder Fork sollte das Team eine schriftliche Maintainer-Klärung einholen, Notices aufbewahren und Compliance die wirksamen Bedingungen bestimmen lassen.
Den passenden Saplings-Agent wählen
| Klasse | Suchverhalten | Kosten- und Fehlergrenze |
|---|---|---|
| COTAgent | Eine normale Tool-Trajektorie ohne Suche | Baseline und günstigster Test für Tools und Evaluator |
| GreedyAgent | Kandidaten erzeugen, ausführen, bewerten und nur den aktuell besten fortsetzen | Weniger Suchaufwand, aber kein Backtracking aus einem lokalen Optimum |
| AStarAgent | Alternative Frontiers bleiben erhalten und können später gewählt werden | Mittelweg; schlechte Evaluatorwerte sortieren auch die Frontier schlecht |
| MonteCarloAgent | Selection, Rollout und Backpropagation; Source-Defaults: Faktor 3, Tiefe 5, maximal 10 Rollouts | Potentiell höchste Calls und Side Effects; Root Tool Call wird nur einmal vor Verzweigung erzeugt |
| Custom Evaluator | Eigene normalisierte Scores und Begründung | Tests, exakte Constraints und Environment Reward sind verlässlicher als LLM-Selbsteinschätzung |
Ein Suchbaum ist nur so brauchbar wie seine Value Function. Der Default-Evaluator sendet die Trajektorie an das konfigurierte Modell, fordert 0–10 Punkte an und normalisiert auf 0–1. Das ist bequem, kann aber plausibel klingenden Fortschritt mit echter Erledigung verwechseln. Coding sollte Compiler und Tests nutzen, Retrieval Quellenabdeckung, eine Simulation den tatsächlichen State. Ein festes Holdout-Set ist Pflicht, denn schon ein anderer Evaluator-Prompt kann das Verhalten ähnlich stark verändern wie ein anderer Suchalgorithmus.
Die aktuelle MCTS-Implementierung besitzt eine ungewöhnlich konkrete Grenze: Sie erzwingt zunächst genau einen Tool Call und baut daraus den Root Node. Ein TODO im Source weist darauf hin, dass ein falscher Root Call den gesamten Baum beschädigen kann. Erst danach beginnt die Verzweigung. Saplings kann spätere Aktionen vergleichen und zurückgehen, wählt aber nicht aus mehreren unabhängigen ersten Aktionen. Genau deshalb reicht die allgemeine Werbeformel „Look-ahead und Backtracking“ für eine sachliche Bewertung nicht aus.
Sicherer reproduzierbarer Evaluationsablauf
- Artefakt einfrieren.Isolierte Umgebung,
saplings==6.2.0, vollständiger Lockfile und PyPI-Sdist-Hash. - Lizenzgate.Apache-2.0-LICENSE gegen MIT-Metadaten im Dependency Review dokumentieren.
- Mit COTAgent beginnen.Erfolg, Kosten, Latenz und Tool-Korrektheit ohne Search messen.
- Tools replay-safe machen.Propose/Preview von Commit trennen; Sandbox, geklonter State und Idempotency Key je Branch.
- Objektiv evaluieren.Tests, Schema, exakte Regeln, Simulator-State und Quellenprüfung vor LLM-Scores.
- Baum begrenzen.Branching Factor, Depth, Rollouts, Timeout und Provider-Budget ausdrücklich konfigurieren.
- Jeden Call instrumentieren.Branch, Parent, Argumente, Resultat, Score, Modell, Tokens, Latenz, Retry und Exception ohne Secrets loggen.
- Feste Matrix.COT, Greedy, A* und MCTS mit gleichen Prompts, Mocks, Evaluator und soweit möglich Seeds vergleichen.
- Fehlerfälle testen.API-Ausfall, kaputter Output, Rate Limit, doppelte Aktion, falsche Evidenz, Context Truncation und Evaluator-Dissens.
- Nur einmal committen.Search erstellt Plan, Patch oder Kandidat; Validator oder Mensch autorisiert einen externen Write.
- Datenpfad prüfen.Die Library läuft lokal, LiteLLM kann aber Prompts, Schemas und Trajektorien zum gewählten Provider senden.
- Exit vorbereiten.Saplings hinter einer eigenen Schnittstelle kapseln, damit Tools bei einem Wechsel bestehen bleiben.
Was das kompakte README nicht löst
| Risiko | Ursache in 6.2.0 | Kontrolle |
|---|---|---|
| Mehrfache Side Effects | BaseAgent führt alle Kandidaten vor der Bewertung aus | Nur pure/simulierte Tools durchsuchen; einmal nach Auswahl committen |
| Call-Wachstum | Candidate Generation, Branch Evaluation und Rollouts rufen Modelle/Tools auf | Harte Budgets, Timeout, Cache für sichere Reads, Kosten pro gelöster Aufgabe |
| Evaluator Bias | Default ist LLM-Selbstevaluation der Trajektorie | Objektive Rewards, mehrere Evaluatoren, menschliches Audit |
| Root Lock-in | MCTS erzeugt einen required Root Call vor der Verzweigung | Plan vorher validieren oder Root-Strategie anpassen |
| Dependency Drift | litellm und json-repair ohne Versionsbereich | Transitive Locks und Upgrade-CI |
| Privacy/Security | Modell sieht Prompt, Schema, Trajektorie; Tool erhält Trajectory Memory | Minimierung, Redaction, Least Privilege und Provider Governance |
| Maintenance/Lizenz | Stille Releases und widersprüchliche Angaben | Pin/Fork, Scan, Owner und schriftliche Klärung |
Mehrfache Side Effects sind die wichtigste Betriebsgrenze. BaseAgent.expand erstellt für jeden Candidate einen asynchronen Task, führt das Tool aus und bewertet erst danach die Child Nodes. Backtracking macht diese Wirkung nicht rückgängig. Drei erkundete send_email-Varianten können drei Nachrichten verschicken, obwohl nur ein Pfad zurückgegeben wird. Sichere Systeme suchen über Beschreibungen, simulierten State oder reversible Patches und geben die irreversible Funktion erst nach Ende der Suche frei.
Ein pauschaler Kostenmultiplikator wäre erfunden. Die Call-Zahl hängt von Early Termination, Deduplizierung, Tiefe, Rollouts, Evaluator Samples, Tool-Verhalten und Retries ab. Gemessen werden sollten Kosten pro akzeptierter Aufgabe, p50/p95-Latenz und Duplicate Effects. Die Benchmark-Tabelle im README verweist ausdrücklich auf das LATS Paper. Sie ist keine Reproduktion mit Saplings 6.2.0; die Source-Distribution enthält auch keinen Runner, der diese Ergebnisse belegt.
Saplings und reale Alternativen
| Option | Bester Einsatz | Trade-off zu Saplings |
|---|---|---|
| Saplings | Kleines Python-Experiment für MCTS/A*/Greedy um Tool Calls | Lesbar und kompakt; stille Wartung, keine Durable Runtime, Side-Effect-Schutz selbst bauen |
| Plain ReAct/Tool Loop | Günstige sequenzielle Tasks mit starken, leicht prüfbaren Tools | Kein Backtracking, dafür Kosten und externe Writes besser verständlich |
| LangGraph | Stateful Production mit Persistence, Streaming, Human Review und Durable Execution | Mehr Orchestration; Checkpoints, State und Commit Gates sind explizit |
| LLM Reasoners | MCTS/ToT/World-Model-Forschung und Benchmark-Reproduktion | Breiter und schwerer, aber für Algorithmenstudien passender |
| Eigene Suche | Domain Simulator, exakter Reward und strikte Side-Effect Policy | Mehr Engineering, volle Kontrolle über Branching, Cache, Budget und Transaktion |
Unabhängiges Urteil:Saplings überzeugt durch Lesbarkeit. Search Loop, Tool-Abstraktion und Evaluator sind ohne große Plattform prüfbar—gut zum Lernen und für einen begrenzten Proof of Concept. Die Schwäche ist der Abstand zwischen Search Research und Production Orchestration: keine eingebaute Persistence, Approval Queue, Transaction Rollback, Durable Checkpoints oder veröffentlichte Security Policy.
Einsetzen, wenn die Umgebung billig klonbar, der Reward objektiv und die Tools reversibel sind. Für einen langfristigen Dienst sollte das Team einen Fork besitzen und Locks, Tests, Tracing, Security und Lizenzklärung ergänzen, oder die Policy in einer aktiv gepflegten Runtime implementieren. Paper-Benchmarks sind eine Hypothese für eigene Tasks, keine Deployment-Freigabe.
Häufige Fragen
Was ist Saplings?
Eine Python-Library von shobrook/saplings, die Greedy, A* oder MCTS um Tool-Calling-Trajektorien legt. Modelle laufen über LiteLLM, ein Evaluator bewertet Zweige.
Wird Saplings noch gepflegt?
Es ist verfügbar und nicht archiviert, aber still. PyPI 6.2.0 stammt vom 22.06.2025, der letzte Push vom 27.07.2025. Fortlaufende Wartung ist nicht belegt.
Ist es Meta Sapling?
Nein. Meta Sapling ist Source Control. Hier geht es um Jonathan Shobrooks AI-Agent-Paket; ein älteres gleichnamiges Projekt heißt heute Syntaxis.
Welche Lizenz gilt?
Repo und Sdist enthalten Apache-2.0, setup.py/PyPI nennen MIT. Der Maintainer sollte den Konflikt klären; Compliance darf nicht still eine Variante wählen.
Verbessert Tree Search jeden Agent?
Nein. Sie hilft bei zuverlässig bewertbaren Alternativen, erhöht aber Calls und verstärkt einen schwachen Evaluator. README-Werte stammen aus dem LATS Paper.
Funktionieren lokale Modelle?
LiteLLM bietet lokale Routen, doch Tool Calling, Structured Output und Token Counting müssen pro Modell geprüft werden.
Warum sind Write Tools gefährlich?
Candidate Branches werden vor der Gewinnerwahl ausgeführt. Preview, Sandbox und ein einzelner Post-Search-Commit sind nötig.
Welche Alternative?
Plain Loop für einfache Arbeit, LangGraph für durable Approval, LLM Reasoners für Forschung, eigene Suche bei exaktem Simulator/Reward.
Geprüfte Quellen
- 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
Unabhängige Prüfung: 2026-08-20. Entity per GitHub/PyPI abgegrenzt; Status bewusst als verfügbar, aber still bezeichnet. Lizenzkonflikt und Unterschied zwischen Paper- und Package-Benchmark bleiben sichtbar.
