Saplings significa aquí el paquete Python de código abierto shobrook/saplings. Permite que un agente con herramientas explore varias trayectorias mediante Monte Carlo Tree Search (MCTS), A* o greedy best-first search. No es Sapling, el sistema de control de versiones de Meta, ni el paquete antiguo del autor que antes tuvo el mismo nombre y ahora se llama Syntaxis. La implementación actual usa LiteLLM para invocar modelos y un evaluator—por defecto otro LLM—para puntuar ramas candidatas.
Debe tratarse como una capa de búsqueda para prototipos con herramientas reversibles y tareas acotadas, no como una plataforma completa para agentes en producción. Puede apartarse de una mala decisión posterior, pero los tools explorados pueden ejecutarse realmente antes de seleccionar la mejor rama. Cálculo, retrieval, código en sandbox y simuladores son buenos primeros casos; correo, pagos, tickets o escrituras de base de datos necesitan una barrera externa de preview y commit.
Identidad exacta y estado de mantenimiento
| Comprobación | Verificado el 2026-08-20 | Interpretación |
|---|---|---|
| Proyecto canónico | GitHub shobrook/saplings; PyPI saplings | No mezclar con Meta Sapling SCM ni Syntaxis |
| Último paquete | PyPI 6.2.0, subido 22-06-2025 | Disponible, pero unos catorce meses sin release |
| Repositorio | Público, no archivado; último push 27-07-2025 | Los últimos commits son del README; último fix de código visible 22-06-2025 |
| Distribución | Sdist de 33 kB; no se lista wheel para 6.2.0 | pip construye localmente |
| Metadatos runtime | Python >=3; litellm/json-repair sin versiones fijadas | El rango es demasiado amplio para probar compatibilidad moderna |
| Licencia | El LICENSE es Apache-2.0; setup.py/PyPI dicen MIT | Es un conflicto, no una declaración de doble licencia |
El estado defendible es disponible, pero quieto. El repositorio no está archived ni disabled y PyPI conserva 6.2.0, por lo que declararlo discontinuado iría más allá de las pruebas. A la vez, una página accesible no demuestra mantenimiento de compatibilidad o seguridad. No hay GitHub Releases, no hay archivos PyPI posteriores a junio de 2025 y el sdist 6.2.0 no incluye suite de tests ni benchmark harness. Hay que bloquear paquete y dependencias transitivas y ejecutar una matriz privada de Python, modelos y tools.
La discrepancia de licencia es un gate independiente. El repositorio y el sdist contienen el texto completo de Apache License 2.0; setup.py declara MIT y PyPI repite ese campo. No es una opción dual documentada. Antes de redistribuir, integrar o mantener un fork, se debe pedir aclaración al maintainer, conservar notices y hacer que compliance determine los términos aplicables.
Cómo elegir un agente de Saplings
| Clase | Comportamiento de búsqueda | Frontera de coste y fallo |
|---|---|---|
| COTAgent | Una trayectoria normal sin search | Baseline barato para validar tools y evaluator |
| GreedyAgent | Genera, ejecuta y puntúa candidatos; continúa con el mejor actual | Menos overhead, pero no vuelve desde un óptimo local equivocado |
| AStarAgent | Mantiene frontiers alternativas y puede cambiar de rama | Punto medio; si el evaluator falla también falla el orden |
| MonteCarloAgent | Selection, rollout y backpropagation; defaults 6.2.0: factor 3, profundidad 5, 10 rollouts | Más calls/efectos potenciales; el root tool call se genera una sola vez antes de ramificar |
| Custom evaluator | Devuelve score normalizado y reasoning propios | Tests, reglas exactas y state rewards superan a un LLM juzgando su prosa |
El árbol no puede superar a su value function. El evaluator por defecto envía la trayectoria al modelo, solicita una nota 0–10 y la normaliza a 0–1. Es cómodo para explorar, pero puede confundir progreso plausible con tarea completa. Un agente de código debería usar compilación y tests; retrieval, cobertura y soporte de fuentes; un entorno, reward del estado real. Debe mantenerse un conjunto holdout porque cambiar el prompt del evaluator puede alterar la búsqueda tanto como cambiar el algoritmo.
MCTS tiene una frontera específica: fuerza un primer tool call, crea con él el root node y solo después expande ramas. Un TODO del source reconoce que un root equivocado perjudica todo el árbol. Por tanto, puede mirar y volver en acciones posteriores, pero no compara varias primeras acciones independientes. Una review que repita únicamente «look-ahead y backtracking» ocultaría esta diferencia de implementación.
Flujo de evaluación seguro y reproducible
- Congelar el artefacto.Entorno aislado,
saplings==6.2.0, lockfile transitivo y hash del sdist. - Gate de licencia.Registrar el conflicto Apache-2.0 contra MIT en la aprobación de dependencias.
- Empezar por COTAgent.Medir success, coste, latencia y corrección de tools sin search.
- Tools replay-safe.Separar propose/preview de commit; sandbox, estado clonado e idempotency key por rama.
- Evaluator objetivo.Priorizar tests, schema, constraints, simulator state y comprobación de fuentes sobre self-score.
- Limitar el árbol.Configurar branching factor, depth, rollouts, timeout y presupuesto del provider.
- Instrumentar calls.Registrar branch, parent, argumentos, resultado, score, modelo, tokens, latencia, retry y excepción, con redaction.
- Matriz fija.Comparar COT, Greedy, A* y MCTS con mismos prompts, mocks, evaluator y seeds si existen.
- Casos de fallo.API caída, output roto, rate limit, acción repetida, evidencia falsa, truncation y desacuerdo de evaluator.
- Un solo commit.Search produce plan, patch o candidato; validator o humano aprueba una única escritura externa.
- Ruta de datos.La librería es local, pero LiteLLM puede enviar prompts, schemas y trayectorias al provider configurado.
- Salida preparada.Encapsular Saplings tras una interfaz propia para cambiarlo sin rehacer tools.
Lo que el README compacto no resuelve
| Riesgo | Causa en 6.2.0 | Control |
|---|---|---|
| Efectos repetidos | BaseAgent ejecuta todos los candidate tools antes de puntuar | Buscar con tools puros/simulados y hacer commit una vez |
| Crecimiento de calls | Generación, evaluación y rollouts invocan modelos/tools | Budgets duros, timeout, cache seguro y coste por tarea resuelta |
| Sesgo de evaluator | La función por defecto es autoevaluación LLM | Rewards objetivos, varios evaluators y auditoría humana |
| Root lock-in | MCTS crea un required root antes de las ramas | Validar plan primero o modificar estrategia root |
| Dependency drift | litellm/json-repair no tienen ranges | Lock transitivo y CI de upgrades |
| Privacidad/seguridad | Modelo ve prompt/schema/trajectory; tools reciben memoria de trayectoria | Minimizar, redactar, least privilege y governance del provider |
| Mantenimiento/licencia | Releases quietos y metadata contradictoria | Pin/fork, scan, owner y aclaración escrita |
Los side effects de ramas son la conclusión operativa principal. BaseAgent.expand crea una tarea async para cada candidate, ejecuta el tool y solo después evalúa child nodes. Backtracking no deshace esos efectos. Explorar tres variantes de send_email puede enviar tres mensajes aunque se devuelva un solo path. El diseño seguro busca sobre descripciones, state simulado o patches reversibles y expone la acción irreversible únicamente después de terminar.
No existe un multiplicador de coste fijo verificable. Los provider calls dependen de early termination, deduplicación, depth, rollouts, evaluator samples, comportamiento del tool y retries. Hay que medir coste por tarea aceptada, p50/p95 latency y duplicate effects. La tabla del README cita el paper LATS; no es una reproducción de Saplings 6.2.0, y el sdist no lleva runner que establezca esas ganancias.
Saplings frente a alternativas reales
| Opción | Mejor caso | Trade-off frente a Saplings |
|---|---|---|
| Saplings | Experimento Python pequeño que añade MCTS/A*/greedy a tool calls | Legible; mantenimiento quieto, sin runtime durable y controles de efectos a cargo del usuario |
| ReAct/tool loop normal | Trabajo secuencial barato con tools fuertes y verificables | Sin backtracking, pero coste y writes externos son más previsibles |
| LangGraph | Workflows stateful con persistence, streaming, human review y durable execution | Más orquestación; state, checkpoints y commit gates explícitos |
| LLM Reasoners | Investigación de MCTS, ToT, world models y reproducción | Más amplio/pesado; mejor para estudiar algoritmos |
| Búsqueda propia | Domain simulator, reward exacto y política estricta de efectos | Más ingeniería, control total de branches, cache, budget y transacciones |
Juicio independiente:la mejor cualidad de Saplings es su legibilidad. Se puede revisar el search loop, Tool y evaluator sin adoptar una plataforma grande, algo útil para aprender y para un proof of concept acotado. Su debilidad es la distancia entre search research y production orchestration: no aporta persistence, approval queue, rollback transaccional, checkpoints durables ni security policy publicada.
Es razonable cuando el entorno se clona barato, el reward es objetivo y los tools son reversibles. Para un servicio duradero, hay que poseer un fork con locks, tests, tracing, security y licencia aclarada, o implementar la policy en un runtime mantenido. Un benchmark del paper es una hipótesis para tasks privadas, no una aprobación de despliegue.
Preguntas frecuentes
¿Qué es Saplings?
Una biblioteca Python de shobrook/saplings que aplica Greedy, A* o MCTS a trayectorias con tools, usa LiteLLM y un evaluator para puntuar ramas.
¿Sigue mantenido?
Está disponible y no archivado, pero quieto. PyPI 6.2.0 es de 22-06-2025 y el último push de 27-07-2025. El mantenimiento continuo no está demostrado.
¿Es Meta Sapling?
No. Meta Sapling es source control. Este es el paquete AI-agent de Jonathan Shobrook; otro paquete antiguo homónimo se renombró Syntaxis.
¿Qué licencia aplica?
Repo/sdist incluyen Apache-2.0, mientras setup.py/PyPI dicen MIT. El maintainer debe resolver el conflicto; compliance no debe elegir en silencio.
¿Tree search siempre mejora?
No. Puede ayudar con alternativas evaluables, pero multiplica calls y amplifica un evaluator débil. Los números del README vienen del paper LATS.
¿Admite modelos locales?
LiteLLM ofrece rutas locales, pero tool calling, structured output y token counting deben probarse modelo por modelo.
¿Por qué son peligrosos los write tools?
Los candidates se ejecutan antes de elegir. Use preview, sandbox y un único commit después de search.
¿Alternativas?
Plain loop para simple, LangGraph para durable approval, LLM Reasoners para investigación o search propia con simulator/reward exactos.
Fuentes revisadas
- 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
Revisión independiente: 2026-08-20. GitHub/PyPI confirmaron la entidad. El estado se expresa como disponible pero quieto; no se ocultan el conflicto de licencia ni la diferencia entre benchmark del paper y del package.
