En este artículo
DeerFlow 2.0: Docker, sandboxes y memoria
DeerFlow 2.0 es un harness de ejecución de agentes, no otro modelo. La pregunta útil es si permite coordinar herramientas, archivos y agentes especializados con menos integración propia, manteniendo límites que puedas comprobar. El repositorio oficial de ByteDance presenta la versión 2 como una reescritura completa, no como una actualización menor de su anterior sistema de investigación profunda.
Alcance de la revisión: esta guía analiza la documentación y la implementación públicas de la rama 2.x main a fecha de . No es una noticia del día de lanzamiento, una instalación probada en ejecución ni un benchmark reproducido. Las revisiones posteriores y los checkouts antiguos de 2.0 pueden diferir. Registra el commit antes de seguir las instrucciones.
¿Qué orquesta realmente DeerFlow?
DeerFlow reúne el runtime de agentes, la ejecución de herramientas, los archivos de trabajo y las skills reutilizables en un sistema construido con LangGraph y LangChain. Su documentación de arquitectura describe el middleware de agentes y las extensiones basadas en archivos SKILL.md. No sustituye LangGraph: proporciona un entorno de ejecución más integrado sobre esas bases.
Nuestra valoración: merece una evaluación cuando una tarea debe investigar, inspeccionar archivos, ejecutar código y entregar un resultado verificable mediante varios pasos. Aporta menos cuando un script fijo o un flujo convencional con una cola ya resuelve el problema. Nuestra guía de ingeniería de harnesses de agentes aborda la decisión general. Este artículo se centra en operar DeerFlow.
Un harness puede reducir el código de coordinación. El equipo sigue definiendo qué constituye un resultado correcto, qué acciones necesitan aprobación, qué datos pueden llegar al modelo y quién gestiona los fallos. Empieza con un flujo acotado, no con un asistente general conectado a todos los sistemas de la empresa.
Configurar DeerFlow 2.0 con Docker: los pasos que faltan
Clonar y arrancar no equivale a completar la instalación inicial. Los comandos siguientes requieren Git, Make, Python 3, una shell adecuada, un motor Docker en ejecución y Docker Compose. Las instrucciones upstream revisadas exigen Compose v2.24 o posterior. Utiliza los ejemplos de configuración del mismo checkout, no fragmentos de una versión anterior.
1. Clona el repositorio upstream y genera la configuración
set -eu
git clone https://github.com/bytedance/deer-flow.git
cd deer-flow
git rev-parse HEAD
docker compose version
make configConserva el hash del commit en las notas de evaluación. El script de configuración inicial genera config.yaml, .env y frontend/.env a partir de sus ejemplos. Si ya existe una configuración en la raíz, se detiene. Eso no significa que debas borrar una configuración funcional: haz una copia y revisa el procedimiento de actualización del repositorio.
2. Configura un modelo real y elige el sandbox de las tareas
Edita los archivos generados antes de arrancar. Configura al menos un modelo compatible, utiliza credenciales reales del proveedor y revisa los requisitos del entorno del frontend. No incluyas secretos en commits ni en diagnósticos compartidos. Los nombres de modelo o claves de ejemplo no convierten una configuración aparentemente correcta en una instalación funcional.
Para una evaluación con contenedores AIO, sustituye el bloque sandbox: existente en config.yaml por esta selección mínima. No añadas otra clave YAML con el mismo nombre:
sandbox:
use: deerflow.community.aio_sandbox:AioSandboxProviderLa guía de configuración de sandboxes distingue el proveedor local de la ejecución en contenedores AIO. Ejecutar la aplicación DeerFlow en Docker no selecciona automáticamente un sandbox aislado para las tareas. Este ejemplo utiliza contenedores AIO locales, no un provisionador remoto ya configurado. Revisa los ajustes existentes del proveedor antes de cambiarlos.
3. Inicializa la imagen e inicia el stack de desarrollo
make docker-init
make docker-startAbre http://localhost:2026. El Makefile revisado clasifica make docker-start como inicio de Docker para desarrollo. Detén ese stack con make docker-stop. La ruta de producción separada es make up, junto con make prod-logs y make down. Un comando de producción no es una certificación de seguridad.
Para consultar los registros de desarrollo:
make docker-logsAntes de conectar un flujo real, realiza una prueba sintética: sube un CSV pequeño con los valores 2 y 3, pide al agente que calcule la suma mediante su herramienta de código y exige un archivo guardado con el resultado 5. Inspecciona el archivo y la traza de la herramienta de forma independiente. Una respuesta que diga «hecho» no demuestra que se ejecutó código ni que el artefacto esté disponible.
Diagnostica el arranque antes de ampliar permisos
La guía de instalación upstream sitúa config.yaml en la raíz del repositorio y documenta los datos de ejecución en .deer-flow o en la ubicación indicada mediante DEER_FLOW_HOME. Comprueba las rutas y la configuración montada antes de atribuir todos los fallos al modelo. Esta tabla propone un orden de diagnóstico, no afirma que todas las instalaciones sufran estos errores.
| Síntoma | Comprueba primero | Evita este atajo |
|---|---|---|
| Falta la configuración o se rechaza | Directorio raíz, archivo realmente montado, YAML válido y compatibilidad con el ejemplo del checkout. | Borrar una configuración funcional o duplicar claves de primer nivel. |
| La interfaz abre, pero falla el modelo | Identificador del modelo, endpoint, credenciales, acceso al proveedor y registros del gateway. | Suponer que una interfaz accesible demuestra que la configuración del modelo funciona. |
| Falla la ejecución de shell | Proveedor de sandbox seleccionado, disponibilidad de la imagen y conexión del proveedor con los contenedores. | Activar una shell local sin restricciones solo para eliminar el error. |
| La primera tarea de código parece bloqueada | Progreso de descarga de la imagen, arranque del contenedor y evidencias de timeout. | Enviar repetidamente la misma tarea costosa sin revisar los registros. |
| Los resultados desaparecen al reiniciar | Backends de estado, volúmenes persistentes, identidades y rutas de los artefactos. | Asumir que todos los componentes en memoria son duraderos. |
¿Están aislados entre sí los subagentes de DeerFlow?
Un contexto conversacional separado no implica un contenedor separado. El ejecutor de subagentes revisado puede transferir el sandbox del agente principal a la ejecución delegada. Trata a los agentes que comparten ese sandbox como participantes en un sistema de archivos común, aunque sus historiales de conversación estén separados. Un contexto nuevo del modelo no es una frontera de seguridad entre clientes.
La implementación actual del proveedor AIO asigna los sandboxes mediante la identidad del usuario y del hilo. Selecciona un backend remoto cuando se configura provisioner_url; en caso contrario utiliza el backend de contenedores locales. Ninguna de esas opciones garantiza un contenedor independiente por subagente especializado.
En el primer flujo, asigna un archivo de salida distinto a cada rama paralela, monta las entradas como solo lectura cuando sea posible y deja que un único paso de síntesis sea responsable del informe final. Prueba si una rama puede sobrescribir archivos de otra. Para clientes distintos, verifica la identidad derivada por el servidor, la autorización y los límites de almacenamiento, no nombres escritos en un prompt.
El proveedor local es otra opción: ejecuta las tareas en el entorno de la aplicación, sin crear un contenedor adicional para cada tarea. Cuando la shell local está deshabilitada, no elimines esa restricción a la ligera. Nuestro análisis de OpenSandbox trata la infraestructura de aislamiento por separado: un proveedor de sandbox y un harness completo resuelven capas diferentes.
Cómo funciona la memoria de DeerFlow y por qué sigue usando tokens
Separa tres aspectos: la conversación actual, los recuerdos reutilizables entre conversaciones y el estado de ejecución necesario para reanudar el trabajo. La configuración compartida de memoria distingue entre habilitarla, inyectarla en prompts y elegir un backend. «La memoria está activada» no demuestra que se extraigan hechos nuevos ni que todas las tareas incompletas sobrevivan a un reinicio.
En el ejemplo de configuración revisado, max_injection_tokens de DeerMem pertenece a memory.backend_config, con un valor de ejemplo de 2000. El modelo de extracción se configura por separado. Omitirlo deja la extracción automática sin configurar, aunque las operaciones de memoria sin LLM pueden seguir funcionando. Comprueba la configuración que carga realmente tu revisión.
La compactación de conversaciones es otro mecanismo. El middleware de resumen proporciona esa capa; no equivale a una memoria empresarial duradera. Un resumen puede perder detalles y el contenido añadido al contexto sigue ocupando capacidad. «Inyección acotada» no significa «memoria ilimitada sin costes de tokens».
Nuestra prueba de memoria propuesta tiene tres partes. Guarda una preferencia inocua, inicia otra conversación con la misma identidad y comprueba su recuperación. Después corrige la preferencia y verifica que el valor antiguo deja de imponerse. Por último, repite la consulta con otra identidad de prueba y confirma que no puede acceder a ella. Inspecciona tanto registros y almacenamiento como la respuesta final.
Registra el prompt real y el uso total del proveedor. Si la memoria aumenta el coste sin mejorar los resultados aceptados, reduce la información inyectada o acota el flujo. Si tu stack solo necesita una capa de memoria, contrasta esa necesidad más concreta con nuestro análisis de memoria de OpenViking, en lugar de sustituir todo el sistema por defecto.
Skills personalizadas de DeerFlow: procedimiento, no permisos
Una primera skill útil debe definir un contrato de salida repetible, no una invitación a actuar con autonomía general. El ejemplo siguiente utiliza el formato de archivos descrito anteriormente para un SKILL.md que prepara un informe de proveedores con referencias. Intégralo y pruébalo según las reglas de descubrimiento y aprobación de skills de tu checkout. No es un paquete de plugin probado en ejecución.
---
name: vendor-evidence-brief
description: Prepare a source-linked vendor brief for human review.
---
Use only the approved input documents and permitted sources.
Record a source URL or input filename for each factual claim.
Mark missing evidence as unknown; never invent a reference.
Write research branches to separate output files.
Produce a draft, not an approval or a published report.
Do not send messages, change accounts, or execute payments.La distinción es importante: «no envíes mensajes» es una instrucción, no una denegación técnica del acceso a mensajería. Aplica las restricciones mediante las herramientas y credenciales disponibles durante la ejecución. Considera los archivos de skills de terceros, sus scripts y dependencias como código o instrucciones que requieren revisión, no como ampliaciones automáticamente fiables.
Mantén el procedimiento reutilizable en la skill y los hechos específicos de cada tarea en sus entradas. Así será más fácil revisarla, comparar versiones y probarla con ejemplos válidos y maliciosos. No incrustes secretos reales de clientes en instrucciones reutilizables.
Un flujo acotado: investigación de proveedores y borrador con evidencias
Este es un diseño de piloto propuesto, no un caso de cliente de DeerFlow. Empieza con tres documentos de proveedores aprobados y una pregunta fija: ¿qué opciones cumplen un requisito técnico definido? Limita la entrega a un borrador comparativo y un archivo de evidencias. No conectes acciones de compras, pagos ni correo saliente.
| Etapa | Artefacto esperado | Prueba de aceptación |
|---|---|---|
| Preparación de entradas | Archivos aprobados y criterios de comparación explícitos. | No hay secretos innecesarios; el alcance y las fuentes permitidas quedan registrados. |
| Investigación paralela | Un archivo de evidencias por proveedor. | Cada fila factual referencia una entrada o URL permitida; lo desconocido sigue marcado como tal. |
| Síntesis | Un borrador comparativo con limitaciones. | Las afirmaciones remiten a las evidencias; la falta de pruebas no se presenta como cumplimiento ni incumplimiento. |
| Validación independiente | Un resultado de validación estructurado. | Existen los archivos exigidos, la salida es procesable y las afirmaciones muestreadas coinciden con sus fuentes. |
| Aprobación humana | Un borrador aprobado o rechazado. | Una persona identificada decide si se puede compartir el contenido o actuar a partir de él. |
Incluye una fuente deliberadamente contradictoria, un documento ausente y una ejecución interrumpida en las pruebas de aceptación. Exige que el sistema exponga la incertidumbre en lugar de inventar una respuesta impecable. Si un único agente sencillo obtiene mejores resultados, consérvalo. Añadir subagentes es una opción de implementación, no una métrica de éxito.
Checklist de DeerFlow en producción: ¿qué hay que demostrar?
Las descripciones antiguas que afirman que no existe autenticación no deben tomarse como actuales. El diseño de autenticación revisado incluye configuración inicial y tratamiento de usuarios autenticados. Completa el alta del primer administrador mediante el flujo local /setup antes de hacer el servicio accesible a terceros y prueba la autorización con cuentas separadas.
El archivo Compose de producción revisado publica el punto de entrada en 127.0.0.1 por defecto y exige BETTER_AUTH_SECRET. Conserva el acceso por loopback durante la evaluación. La exposición pública debe seguir a una revisión explícita del despliegue, no a un cambio improvisado de BIND_HOST.
Utiliza lo siguiente como criterios de lanzamiento propuestos. No significa que DeerFlow proporcione o active todos estos controles.
| Control | Prueba que debes obtener |
|---|---|
| Identidad y permisos | Un usuario no puede acceder a hilos, archivos o recuerdos de otro; las acciones privilegiadas requieren una identidad expresamente autorizada. |
| Contención del runtime | Revisa montajes, conexiones salientes, secretos y límites de recursos. Cuando AIO utiliza el socket Docker del host, evalúa por separado esa vía de control privilegiada. |
| Persistencia y recuperación | Reinicia durante una tarea, vuelve a conectar e inspecciona el estado. Verifica la restauración de copias y que los reintentos no dupliquen acciones externas. |
| Coste y cancelación | Demuestra límites de gasto, plazos, cancelación y restricciones del trabajo paralelo con fallos representativos. |
| Confianza en skills y herramientas | Revisa extensiones ejecutables, lanzadores MCP y cambios en las skills. El contenido no fiable no debe adquirir autoridad administrativa sobre herramientas. |
| Responsabilidad de actualización | Fija revisiones de aplicación e imágenes, conserva trazas depuradas, repite las pruebas y demuestra una reversión con un operador responsable. |
Para la revisión final, utiliza nuestra checklist de QA de software antes del lanzamiento como guía de entrega general y añade los casos específicos de agentes. Superar una demostración sin errores no basta para autorizar cambios de cuentas, pagos u otras acciones irreversibles.
¿Merece la pena adoptar DeerFlow?
Mide el coste por tarea aceptada = (costes totales de modelos + herramientas + runtime + revisión humana) / tareas aceptadas. Utiliza unidades contables coherentes, incorpora los intentos fallidos en esos totales, incluye la extracción de memoria y las llamadas delegadas, y compara las mismas tareas con tu solución actual. Registra también tiempos, correcciones del revisor, recuperación y acciones inseguras bloqueadas. Si no se acepta ninguna tarea, informa del fallo en lugar de calcular una media engañosa.
Elige un piloto de DeerFlow cuando un entorno integrado pueda eliminar trabajo real de orquestación. Mantén un framework más pequeño o un flujo determinista si cumple el contrato de aceptación con menos complejidad operativa. Nuestro análisis de LangChain Deep Agents ayuda a situar esa alternativa más acotada.
El servicio de desarrollo de IA de Wavect puede ayudar a definir un flujo limitado, sus permisos y sus pruebas. El caso de TwinSoft AI aporta contexto de entrega relacionado, no demuestra un despliegue de DeerFlow. Para valorar el encaje con tu sistema, comenta el flujo y sus posibles fallos con Wavect.