--- title: "DeerFlow 2.0: Docker, sandboxes y memoria" canonical: https://wavect.io/es/blog/deerflow-2-docker-setup-sandbox-memory/ language: es description: "Configura DeerFlow 2.0 con Docker, distingue el aislamiento de subagentes y sandboxes, revisa los límites de memoria y prepara su despliegue en producción." image: "https://wavect.io/img/blog/headers/header_deerflow-2-docker-setup-sandbox-memory.png" --- [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min de lectura · 28 sep 2026 Última revisión 28 de septiembre de 2026 [**Siguiente**](/es/blog/agent-harness-engineering/) # DeerFlow 2.0: Docker, sandboxes y memoria Resumen DeerFlow 2.0 es el harness de agentes de código abierto de ByteDance para coordinar modelos, herramientas, subagentes, skills y ejecución. Para una evaluación local con Docker, prepara la configuración, selecciona el proveedor de sandbox y ejecuta make docker-init y make docker-start. Separar las conversaciones no implica separar los sandboxes, y la memoria persistente no elimina el consumo de tokens. Arrancar correctamente inicia la validación; no demuestra que el sistema esté listo para producción. **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](https://github.com/bytedance/deer-flow) 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 28 de septiembre de 2026. 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](https://github.com/bytedance/deer-flow/blob/main/backend/docs/ARCHITECTURE.md) 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](/es/blog/agent-harness-engineering/) 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 config ``` Conserva el hash del commit en las notas de evaluación. El [script de configuración inicial](https://github.com/bytedance/deer-flow/blob/main/scripts/configure.py) 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:AioSandboxProvider ``` La [guía de configuración de sandboxes](https://github.com/bytedance/deer-flow/blob/main/backend/docs/CONFIGURATION.md) 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-start ``` Abre `http://localhost:2026`. El [Makefile](https://github.com/bytedance/deer-flow/blob/main/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-logs ``` Antes 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](https://github.com/bytedance/deer-flow/blob/main/backend/docs/SETUP.md) 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](https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/subagents/executor.py) 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](https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/community/aio_sandbox/aio_sandbox_provider.py) 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](/es/blog/opensandbox-ai-agent-sandbox-review/) 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](https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/config/memory_config.py) 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](https://github.com/bytedance/deer-flow/blob/main/config.example.yaml) 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](https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/agents/middlewares/summarization_middleware.py) 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](/es/blog/openviking-agent-memory-review/), 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](https://github.com/bytedance/deer-flow/blob/main/backend/docs/AUTH_DESIGN.md) 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](https://github.com/bytedance/deer-flow/blob/main/docker/docker-compose.yaml) 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](/es/software-development-guide/software-qa-checklist-before-launch/) 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](/es/blog/langchain-deep-agents-review/) ayuda a situar esa alternativa más acotada. El [servicio de desarrollo de IA de Wavect](/es/services/artificial-intelligence/) puede ayudar a definir un flujo limitado, sus permisos y sus pruebas. El [caso de TwinSoft AI](/es/case-studies/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](/es/contact/). ## Preguntas frecuentes sobre DeerFlow 2.0 ### ¿Qué es DeerFlow 2.0? DeerFlow 2.0 es el harness de agentes de código abierto de ByteDance, construido sobre LangGraph y LangChain. Combina ejecución, subagentes, herramientas, integración con sandboxes, memoria y skills. No es un nuevo modelo fundacional ni garantiza el éxito de un flujo de trabajo. ### ¿Basta con git clone y después make docker-start? No como instalación inicial completa. Primero prepara los archivos de configuración y entorno, configura un modelo funcional, selecciona el proveedor de sandbox e inicializa su imagen. Después inicia el stack de desarrollo. ### ¿Cada subagente de DeerFlow tiene su propio contenedor Docker? No debe darse por hecho. El aislamiento de la conversación y el del sandbox son distintos. Los subagentes pueden utilizar el sandbox del agente principal y compartir archivos. Verifica los límites del proveedor y del despliegue concretos. ### ¿Por qué la memoria de DeerFlow no aprende información nueva? Revisa tanto la configuración compartida de memoria como el backend elegido. En el ejemplo de DeerMem analizado, la extracción automática necesita un modelo de extracción configurado. Comprueba también credenciales, identidad, almacenamiento y registros. Inyectar recuerdos existentes y extraer hechos nuevos son operaciones distintas. ### ¿La memoria de DeerFlow elimina los costes de tokens? No. Los recuerdos inyectados, el contenido recuperado, los resúmenes y las llamadas de extracción pueden consumir tokens. La métrica relevante es el coste total por tarea aceptada, incluidos los intentos fallidos y la revisión humana, no el tamaño de un único prompt. ### ¿Se puede utilizar DeerFlow en producción? Evalúa primero una revisión fijada con tu carga de trabajo. El repositorio incluye autenticación y un comando Docker específico para producción. Aun así, necesitas permisos, persistencia, contención, recuperación, límites de gasto y responsabilidades operativas verificados. Modelos e infraestructura ## Continúa por este clúster Selección de modelos, economía de inferencia, despliegue local, compresión y serving. [Empieza por el artículo fundamental**Alojar LLMs en la UE: Cuándo Salen a Cuenta los Open Weights**](/es/blog/self-hosting-llms-eu-cost/) - [LiteAgents SDK: routing por turno, instalación y migración](/es/blog/liteagents-sdk-per-turn-model-routing/) - [mcp-memory-service: memoria compartida para Claude Code y Cursor](/es/blog/mcp-memory-service-claude-code-cursor/) - [Claude Opus 5.5: usos, prompts y niveles de esfuerzo](/es/blog/claude-opus-5-5-best-use-cases-workflows/) - [Laya y Jev en empresas: 6 flujos de trabajo prácticos](/es/blog/laya-jev-business-workflows-roi/) - [Laya vs Jev: benchmarks y riesgo para startups de IA](/es/blog/laya-vs-jev-benchmark-ai-startup-moat/) [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min de lectura · 28 sep 2026 Última revisión 28 de septiembre de 2026 [**Siguiente**](/es/blog/agent-harness-engineering/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/es/blog/deerflow-2-docker-setup-sandbox-memory/#webpage", "@type": "WebPage", "dateModified": "2026-09-28", "inLanguage": "es", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-09-28", "url": "https://wavect.io/es/blog/deerflow-2-docker-setup-sandbox-memory/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "DeerFlow 2.0 es el harness de agentes de código abierto de ByteDance para coordinar modelos, herramientas, subagentes, skills y ejecución. Para una evaluación local con Docker, prepara la configuración, selecciona el proveedor de sandbox y ejecuta make docker-init y make docker-start. Separar las conversaciones no implica separar los sandboxes, y la memoria persistente no elimina el consumo de tokens. Arrancar correctamente inicia la validación; no demuestra que el sistema esté listo para producción.", "articleBody": " Resumen del blog/IA y agentes/Modelos e infraestructura DeerFlow 2.0: Docker, sandboxes y memoria Resumen DeerFlow 2.0 es el harness de agentes de código abierto de ByteDance para coordinar modelos, herramientas, subagentes, skills y ejecución. Para una evaluación local con Docker, prepara la configuración, selecciona el proveedor de sandbox y ejecuta make docker-init y make docker-start. Separar las conversaciones no implica separar los sandboxes, y la memoria persistente no elimina el consumo de tokens. Arrancar correctamente inicia la validación; no demuestra que el sistema esté listo para producción. 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 28 de septiembre de 2026. 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 config Conserva 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:AioSandboxProvider La 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-start Abre 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-logs Antes de conectar un flujo real, realiza una", "articleSection": "Ingeniería de IA", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "repositorio oficial de ByteDance", "url": "https://github.com/bytedance/deer-flow" }, { "@type": "WebPage", "name": "documentación de arquitectura", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/docs/ARCHITECTURE.md" }, { "@type": "WebPage", "name": "script de configuración inicial", "url": "https://github.com/bytedance/deer-flow/blob/main/scripts/configure.py" }, { "@type": "WebPage", "name": "guía de configuración de sandboxes", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/docs/CONFIGURATION.md" }, { "@type": "WebPage", "name": "Makefile", "url": "https://github.com/bytedance/deer-flow/blob/main/Makefile" }, { "@type": "WebPage", "name": "guía de instalación upstream", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/docs/SETUP.md" }, { "@type": "WebPage", "name": "ejecutor de subagentes", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/subagents/executor.py" }, { "@type": "WebPage", "name": "implementación actual del proveedor AIO", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/community/aio_sandbox/aio_sandbox_provider.py" }, { "@type": "WebPage", "name": "configuración compartida de memoria", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/config/memory_config.py" }, { "@type": "WebPage", "name": "ejemplo de configuración", "url": "https://github.com/bytedance/deer-flow/blob/main/config.example.yaml" }, { "@type": "WebPage", "name": "middleware de resumen", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/packages/harness/deerflow/agents/middlewares/summarization_middleware.py" }, { "@type": "WebPage", "name": "diseño de autenticación", "url": "https://github.com/bytedance/deer-flow/blob/main/backend/docs/AUTH_DESIGN.md" }, { "@type": "WebPage", "name": "archivo Compose de producción", "url": "https://github.com/bytedance/deer-flow/blob/main/docker/docker-compose.yaml" } ], "dateModified": "2026-09-28", "datePublished": "2026-09-28", "description": "DeerFlow 2.0 es el harness de agentes de código abierto de ByteDance para coordinar modelos, herramientas, subagentes, skills y ejecución. Para una evaluación local con Docker, prepara la configuración, selecciona el proveedor de sandbox y ejecuta make docker-init y make docker-start. Separar las conversaciones no implica separar los sandboxes, y la memoria persistente no elimina el consumo de tokens. Arrancar correctamente inicia la validación; no demuestra que el sistema esté listo para producción.", "headline": "DeerFlow 2.0: Docker, sandboxes y memoria", "image": "https://wavect.io/img/blog/headers/header_deerflow-2-docker-setup-sandbox-memory.svg", "inLanguage": "es", "keywords": "DeerFlow 2.0, Configuración de Docker, Harness de agentes", "mainEntityOfPage": { "@id": "https://wavect.io/es/blog/deerflow-2-docker-setup-sandbox-memory/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/es/blog/deerflow-2-docker-setup-sandbox-memory/", "wordCount": 3015 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/es/", "name": "Inicio", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/overview/", "name": "Resumen del blog", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/topics/ai-agents/", "name": "IA y agentes", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/clusters/models-infrastructure/", "name": "Modelos e infraestructura", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/deerflow-2-docker-setup-sandbox-memory/", "name": "DeerFlow 2.0: Docker, sandboxes y memoria", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "DeerFlow 2.0 es el harness de agentes de código abierto de ByteDance, construido sobre LangGraph y LangChain. Combina ejecución, subagentes, herramientas, integración con sandboxes, memoria y skills. No es un nuevo modelo fundacional ni garantiza el éxito de un flujo de trabajo." }, "name": "¿Qué es DeerFlow 2.0?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No como instalación inicial completa. Primero prepara los archivos de configuración y entorno, configura un modelo funcional, selecciona el proveedor de sandbox e inicializa su imagen. Después inicia el stack de desarrollo." }, "name": "¿Basta con git clone y después make docker-start?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No debe darse por hecho. El aislamiento de la conversación y el del sandbox son distintos. Los subagentes pueden utilizar el sandbox del agente principal y compartir archivos. Verifica los límites del proveedor y del despliegue concretos." }, "name": "¿Cada subagente de DeerFlow tiene su propio contenedor Docker?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Revisa tanto la configuración compartida de memoria como el backend elegido. En el ejemplo de DeerMem analizado, la extracción automática necesita un modelo de extracción configurado. Comprueba también credenciales, identidad, almacenamiento y registros. Inyectar recuerdos existentes y extraer hechos nuevos son operaciones distintas." }, "name": "¿Por qué la memoria de DeerFlow no aprende información nueva?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Los recuerdos inyectados, el contenido recuperado, los resúmenes y las llamadas de extracción pueden consumir tokens. La métrica relevante es el coste total por tarea aceptada, incluidos los intentos fallidos y la revisión humana, no el tamaño de un único prompt." }, "name": "¿La memoria de DeerFlow elimina los costes de tokens?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Evalúa primero una revisión fijada con tu carga de trabajo. El repositorio incluye autenticación y un comando Docker específico para producción. Aun así, necesitas permisos, persistencia, contención, recuperación, límites de gasto y responsabilidades operativas verificados." }, "name": "¿Se puede utilizar DeerFlow en producción?" } ] } ```