DeveloperOct 13, 2026
Gemini 4: convierte tutoriales en vídeo en habilidades de ingeniería de RL en producción
Eigent
De tutoriales de RL en vídeo a habilidades de ingeniería de RL en producción
Quienes construyen Terminal-Bench y Harbor han compartido mucho conocimiento de ingeniería de RL ganado a pulso: cómo empaquetan tareas, cómo pillan a los agentes haciendo trampas y cómo convierten los rollouts en datos de entrenamiento. Casi todo está en largas charlas de conferencias.
Tres de esas charlas suman alrededor de una hora y media de vídeo. Valen cada minuto, pero son difíciles de reutilizar. La próxima vez que construyas un entorno, volverás a recorrer líneas de tiempo buscando aquella diapositiva que recuerdas.
Así que le encargamos el visionado a un equipo de agentes. Con Gemini 4 en Eigent, un solo encargo convirtió tres charlas de Terminal-Bench en cuatro habilidades basadas en archivos para ingeniería de entornos de RL en producción, además de un informe con enlaces que muestra de dónde salió cada idea.
El flujo de trabajo completo de un vistazo
Tú eliges las charlas. A partir de ahí, un solo encargo llega hasta habilidades que tus agentes pueden reutilizar. Cada etapa deja un archivo, así que puedes revisar el trabajo paso a paso.
| Etapa | Qué ocurre | Qué obtienes |
|---|---|---|
| Elegir | Escoger las charlas de YouTube de las que quieres aprender | Una lista corta de enlaces de vídeo en el encargo |
| Ver | Descargar subtítulos y fotogramas, y ver cada charla completa | Un índice con marcas de tiempo de cada charla |
| Analizar | Extraer métodos, aprendizajes, resultados y advertencias | Puntos de aprendizaje etiquetados como OBSERVED, INFERRED o UPDATED |
| Comparar | Poner las charlas frente a frente | En qué coinciden, en qué difieren y cómo cada una cubre las lagunas de las demás |
| Destilar | Agrupar métodos y aprendizajes por capacidad práctica | Un SKILL.md y un evidence.md por habilidad |
| Validar | Comprobar la estructura, ejecutar scripts y probar una habilidad en una tarea nueva | Cada habilidad marcada como STRUCTURALLY CHECKED, EXECUTED o UNTESTED |
| Informar | Crear y servir un informe HTML en 127.0.0.1 | Charlas incrustadas, marcas de tiempo clicables y una matriz de cobertura que muestra las lagunas |
| Reutilizar | Indicar a un compañero de trabajo un SKILL.md | Ingeniería de entornos de RL en producción en tu propio proyecto |
A continuación, te explicamos cómo hacerlo tú mismo, paso a paso, incluida una lección que aprendimos al redactar el encargo.
Lo que obtendrás
- Habilidades reutilizables - cada una es un
SKILL.mdcon unevidence.md, redactadas para que otro agente pueda aplicarlas sin ver las charlas. - Un informe HTML con enlaces a las fuentes - servido en local, con todas las charlas incrustadas, un índice con marcas de tiempo y puntos de aprendizaje en los que puedes hacer clic para saltar directamente al momento.
- Una matriz de cobertura - qué habilidad cubre qué parte del flujo de trabajo de RL y qué áreas no aborda ninguna charla.
- Un registro honesto - cada afirmación etiquetada como OBSERVED, INFERRED o UPDATED, y cada habilidad marcada como ejecutada, comprobada estructuralmente o sin probar.
Antes de empezar
- Eigent instalado en tu equipo.
- Una clave de API de Gemini.
- Los enlaces de YouTube de los que quieres que aprendan tus agentes. Nosotros usamos estos tres:
| Charla | Canal | Duración |
|---|---|---|
| Introducing Terminal-Bench: Evaluating LLM Agents in Realistic Terminal Settings | Anyscale (Ray Summit 2025) | 31:23 |
| Everything Is a Rollout - Alex Shaw + Ryan Marten | AI Engineer | 21:11 |
| Terminal-Bench 2.0: Launch + Q&A with the founders | Latent Space | 35:00 |
Añade tu clave de API de Gemini
- Abre Settings → Models.
- Busca Gemini y abre su configuración.
- Pega tu API key.
- Establece el model type en
gemini-4. - Haz clic en Save.
Selecciona Gemini 4
- En la pantalla de inicio, abre el selector de modelo debajo del cuadro de entrada.
- Elige Gemini → gemini-4.
- Ajusta el nivel de razonamiento si quieres; el valor predeterminado funciona.
Pega el encargo
Copia el encargo de abajo en el cuadro de entrada Cowork with. Sustituye los enlaces por tus propios vídeos y pon la línea de Docker en allowed o not allowed.
Watch the YouTube videos listed below and turn their methods and insights into reusable,
file-based agent skills. Then publish the results as a well-designed HTML report served from a
local web server.
Videos:
- https://www.youtube.com/watch?v=zt-U4lDdenY&t=1559s
- https://www.youtube.com/watch?v=jRCpXUjz4CI
- https://www.youtube.com/watch?v=5wo0mLlG0fk&t=1815s
Use only these videos as primary sources. Do not search for, substitute, or add other videos.
You may consult official documentation and the code repositories the videos link to or name,
but only to check or update details shown in the videos.
## Focus
Extract practical, repeatable methods. Where the videos cover them, include:
- Defining tasks, observations, actions, and termination conditions.
- Creating reproducible environments and reset behaviour.
- Building verifiers and reward functions.
- Detecting reward hacking and invalid successes.
- Collecting, scoring, and reviewing agent trajectories.
- Preparing data for agent training and evaluation.
Do not invent coverage for areas the videos don't address. List those areas as gaps instead.
Capture insights, not only procedures. For every method, record why the speakers use it, what
went wrong before they did, any results or numbers they reported, and the warnings they gave.
Treat named tools and frameworks (for example Harbor or Terminal-Bench) as one implementation
of a method. Record the underlying principle first and the tool-specific steps second.
## Permissions and limits
- Allowed: reading the video pages; downloading subtitles, transcripts, and the video files
for analysis; extracting frames; reading official docs and repositories named in the
videos; creating a local virtual environment and installing open-source packages into it;
running a local static web server bound to 127.0.0.1.
- Docker: [allowed / not allowed].
- Not allowed: model training, GPU jobs, paid hosted services, calls to paid LLM APIs, or
publishing anything to a public host. For trajectory collection tests, use a scripted,
rule-based, or random policy.
- Keep all files inside ./rl-env-skills/ in the current working directory. Delete downloaded
video files when finished.
- Do not ask for confirmation for the actions allowed above. Stop and report only if a required
action falls outside them.
- If a video is private, removed, region-locked, or has no usable audio or transcript, say so in
the report. Continue with the remaining videos, and do not replace it.
## Capability honesty
Before starting, record which relevant capabilities you have: video viewing, frame
extraction, transcript access, code execution, browser preview. If you cannot inspect video
visuals, work from transcripts and mark every visual claim as "not observed".
Never describe on-screen content you did not actually see.
## Analysis
For each video:
- Record title, channel, published date, duration, and view count with the date checked.
- Watch it in full. Inspect visual demonstrations, code, diagrams, and narration where your
capabilities allow.
- Build a timestamped outline of the main sections.
- Preserve timestamps for every important procedure, decision, and warning.
- List the key insights and takeaways: design decisions and the reasons behind them, lessons
learned, failure stories, reported results, and warnings. Give each one a timestamp.
- Label each claim OBSERVED (seen or heard in the video), INFERRED (your interpretation), or
UPDATED (adapted to current official docs; cite the doc URL and the date checked).
- Re-inspect unclear moments. Record unresolved details instead of guessing.
- Paraphrase. Quotes must be under 15 words and carry a timestamp. Do not reproduce transcripts.
Then note where the videos agree, where they differ, and where one fills a gap in another.
## Skills
Create 2–4 skills grouped by practical capability. A skill may draw from several videos.
Layout:
rl-env-skills/
<skill-name>/
SKILL.md # required
evidence.md # timestamps, OBSERVED/INFERRED/UPDATED labels, source per point
scripts/ templates/ # only if they materially help; scripts must be tested
report/
index.html # the HTML report (see below)
assets/ # extracted frames or screenshots used in the report, if any
REPORT.md
manifest.json
SKILL.md must begin with YAML frontmatter:
---
name: <kebab-case, matches folder name>
description: <1–2 sentences: what it does and when to use it, including trigger phrases>
---
The body must cover: prerequisites, required inputs, key insights (the principles and lessons
behind the procedure, each with its source and timestamp), procedure (numbered steps), expected
outputs, decision rules, failure recovery, observable success checks, and a tool-agnostic path
for projects that don't use the tools shown in the videos. Another agent should be able to
apply it to a new project without watching the videos.
A skill must not be only a wrapper around one tool's features. If you removed every
tool-specific command, the insights and decision rules should still stand on their own.
Keep these four things distinct throughout: task datasets, recorded trajectories, supervised
training examples, and RL policy optimisation. Never imply that exporting trajectories is RL
training.
## Validation
- Structural: frontmatter is present and valid, the name matches the folder, every referenced
file exists, every evidence timestamp falls within the source video's duration, and every
skill has a key insights section with at least three sourced insights.
- Execution: run every script you created. Where feasible, apply at least one skill end to end on
a small example the videos don't use (e.g. a text grid-world, or a "make this failing unit
test pass" task).
- Report each item as STRUCTURALLY CHECKED, EXECUTED (with command and result), or UNTESTED
(with reason).
## HTML report (report/index.html)
### Content, in this order
1. Header: report title, date checked, the agent's capability summary (had / lacked).
2. Summary: 3–5 sentences on what was produced and the main limitations. No marketing language.
3. Sources: one row per video (title, channel, published date, duration, views with date
checked, linked code or repository, access status).
4. One section per video:
- The original video embedded with a privacy-enhanced YouTube embed
(https://www.youtube-nocookie.com/embed/<VIDEO_ID>), with a 16:9 responsive frame.
- Link to the original.
- Timestamped outline of the video.
- Key insights and takeaways, each with a clickable timestamp and a label.
- Learning points: numbered, each with a clickable timestamp that seeks the embedded player
(YouTube IFrame Player API) and an OBSERVED / INFERRED / UPDATED label.
- Unresolved details.
- If embedding is blocked, show the video thumbnail linked to youtube.com/watch?v=<ID>
and state that embedding was unavailable.
5. How the videos compare: agreements, differences, and how each fills the others' gaps.
6. One section per skill:
- Name, absolute path to SKILL.md, one-sentence purpose, and when to use it.
- Key insights the skill carries, with their sources.
- Procedure summary (the key steps, not the whole file).
- Evidence: every supporting source point as a row — video, timestamp (clickable), label,
and what the skill took from it. Include doc URLs for UPDATED items.
- Validation status with the command and result if executed.
7. Coverage matrix: skills × the videos, showing which video supports which skill, plus
the focus areas no video covered.
8. Data distinctions: a short table defining task dataset, trajectory, supervised example, and
RL policy optimisation, and which of them the skills actually produce.
9. Limitations and untested items.
10. Three copy-paste reuse requests, each in a code block with a copy button.
### Visual design: light mode, in Google's design language
- Style only: do not use Google logos or wordmarks, or suggest the report is a Google product.
- Colours: page #FFFFFF; secondary surfaces #F8F9FA; borders #DADCE0; primary text #202124;
secondary text #5F6368; links and primary actions #1A73E8. Use the Google accent set
(blue #4285F4, red #EA4335, yellow #FBBC04, green #34A853) only for status and labels,
e.g. OBSERVED blue, INFERRED yellow tint with dark text, UPDATED green, UNTESTED red.
Text must meet WCAG AA contrast.
- Type: Google Sans / Google Sans Text if available from Google Fonts, otherwise Roboto; Roboto
Mono or Google Sans Code for code and timestamps. Clear scale: one H1, H2 per section, 16px
body, 1.5 line height, comfortable line length (about 70–80 characters).
- Layout: 8px spacing grid, max content width about 1100px, sticky left table of contents on
desktop that collapses on mobile, flat cards with 1px borders or a subtle Material elevation
shadow, 8–12px corner radius, plain tables with hairline row dividers.
- Avoid the generic "AI-generated" look: no gradients, purple/indigo themes, glassmorphism,
glowing effects, emoji used as icons, sparkle icons, oversized hero banners, decorative
blobs, or hype copy ("unlock", "supercharge", "seamless"). Prefer real content, tables, and
data over decoration.
- Technical: one self-contained HTML file with inline CSS and JS. Only external requests allowed:
Google Fonts and YouTube embed/API. Responsive down to 360px width with no horizontal
page scroll. Semantic HTML, keyboard-accessible controls, alt text on images.
### Serve and verify
1. Start a static server from rl-env-skills/report/ bound to 127.0.0.1, e.g.
`python3 -m http.server 8000 --bind 127.0.0.1`. If port 8000 is busy, use the next free port.
Keep the server running when you finish.
2. Do not rely on opening the file from disk: YouTube embeds often fail without an http origin.
3. Verify: the page returns HTTP 200; every embed loads or shows the fallback; timestamp links
seek the player; all anchors and file links resolve; no console errors. If you have a browser
tool, take a desktop and a 375px-wide screenshot and save them to report/assets/.
4. Report how you verified each item, and which checks you could not run.
## Deliverables
- REPORT.md: a plain-text version of the report's findings.
- manifest.json:
{ "date_checked": "...",
"videos": [{"url","title","channel","published","duration","views","access_status"}],
"skills": [{"name","path","sources":["<video id>", "..."],
"insights": <number of sourced insights>,
"validation":"executed|structural|untested"}],
"capabilities": {"video": bool, "frames": bool, "transcripts": bool, "code_exec": bool,
"browser_preview": bool},
"report": {"path": "<absolute path to index.html>", "preview_url": "http://127.0.0.1:<port>/",
"server_command": "...", "verified": [...], "not_verified": [...]} }
- Final reply: the preview link on its own line first
(http://127.0.0.1:<port>/), then the command to restart the server if it stops, then a short
summary of the videos, skills with absolute paths, validation results, and limitations.
Algunas partes de este encargo hacen el trabajo pesado:
- Use only these videos mantiene a tus agentes en las fuentes que elegiste: sin cambios ni añadidos.
- Capture insights, not only procedures garantiza que el porqué viaje junto al cómo. Más sobre esto abajo.
- Capability honesty impide que nadie describa un fotograma de vídeo que nadie vio realmente.
- Las etiquetas OBSERVED / INFERRED / UPDATED mantienen separados los hechos, la interpretación y las actualizaciones contrastadas con la documentación.
- Las distinciones de datos mantienen separados los conjuntos de datos de tareas, las trayectorias, los ejemplos supervisados y la optimización de políticas de RL, para que exportar trayectorias nunca se confunda con entrenar.
Qué cambiamos en el encargo y por qué
La ejecución de nuestro vídeo usó una versión anterior de este encargo. Hizo muchas cosas bien. Gemini 4 vio las tres charlas, contrastó los detalles con la documentación y el repositorio de Harbor, y creó cuatro habilidades. El script de cada habilidad se ejecutó de principio a fin en una tarea que ninguna charla usa: reparar un analizador de configuración de Python llamado fix-ini-interpolator.
Pero al leer las habilidades notamos algo. Dependían demasiado de las funciones de Harbor: estructura de carpetas de tareas, formatos de trayectorias y comandos de la CLI. Los aprendizajes que había detrás se quedaron casi todos en el informe.
Y las charlas están llenas de aprendizajes. El propio informe recogió estos:
- El andamiaje importa tanto como el modelo. Cancelar pronto los comandos atascados aportó en torno a un 5–10 %, y mezclar modelos en una misma ejecución, en torno a un 5–6 % (charla de Ray Summit, 18:05–19:23).
- Planifica la escala desde el principio. Un portátil llega a unos seis contenedores simultáneos como máximo, y por eso los equipos pasaron a sandboxes en la nube (las tres charlas).
- El reward hacking es el sobreajuste del RL. Trata una puntuación sospechosamente alta como tratarías una pérdida de validación sospechosamente baja (charla de AI Engineer, 06:35).
Una habilidad que solo sabe cómo ejecutar una herramienta no puede decirte cuándo falla el enfoque, ni qué hacer en un stack sin esa herramienta. Así que hicimos cuatro cambios:
- Los aprendizajes son un resultado de primer nivel. Cada sección de vídeo y cada habilidad registran ahora el razonamiento de los ponentes, las lecciones, los resultados y las advertencias, cada uno con su marca de tiempo.
- Primero el principio, después la herramienta. Harbor y Terminal-Bench cuentan como una forma de aplicar un método, no como el método en sí.
- Nada de envoltorios de herramientas. Cada habilidad necesita una sección de aprendizajes clave y una vía independiente de herramientas. Quita los comandos y la habilidad debería seguir enseñando algo.
- La validación lo comprueba. Cada habilidad debe incluir al menos tres aprendizajes con fuente, o no pasa la comprobación estructural.
También corregimos una pequeña incoherencia. El encargo anterior decía "los dos vídeos", pero incluía tres enlaces. Gemini 4 lo detectó, lo señaló en el informe y analizó los tres, pero la nueva redacción funciona con cualquier número de vídeos.
Deja trabajar a tus agentes
Envía el encargo. Gemini 4 planifica el trabajo y pone en marcha los agentes. A partir de ahí, la ejecución sigue el encargo:
- Ver cada charla - subtítulos, fotogramas, diapositivas y demos en directo - y conservar las marcas de tiempo.
- Destilar los métodos y aprendizajes en habilidades, cada una con su propio archivo de evidencias.
- Validar las habilidades y registrar qué se comprobó, qué se ejecutó y qué quedó sin probar.
- Generar el informe y servirlo en
127.0.0.1.
En nuestra ejecución, los agentes descargaron las tres charlas, extrajeron más de 25 fotogramas clave, obtuvieron las transcripciones completas con marcas de tiempo y contrastaron los detalles de Harbor con la documentación oficial; después eliminaron los archivos de vídeo descargados, tal como pide el encargo.
Abre el informe
El informe se abre en un servidor local; en nuestra ejecución, http://127.0.0.1:8000. Esto es lo que encontrarás:
- Capacidades - qué tenían los agentes y qué les faltaba, desde ver vídeos hasta la vista previa en el navegador.
- Resumen y fuentes - cada charla con su canal, fecha de publicación, duración, visualizaciones y repositorios enlazados.
- Una sección por charla - el vídeo incrustado con un reproductor de privacidad mejorada, un índice con marcas de tiempo y puntos de aprendizaje etiquetados.
- Cómo se comparan las charlas - en qué coinciden, en qué difieren y cómo cada una cubre las lagunas de las demás.
- Una sección por habilidad - propósito, pasos clave, evidencias y el comando de validación exacto.
- Limitaciones - qué quedó sin probar y por qué, como los sandboxes en la nube y las API de modelos de pago.
Lee la matriz de cobertura
La matriz muestra qué habilidad cubre qué parte del flujo de trabajo de RL y dónde dejan lagunas las charlas.
| Área de enfoque | Task Scaffolder | Verifier & Anti-Cheat | Rollout Collector | SFT Dataset Preparer |
|---|---|---|---|---|
| Definir tareas, observaciones, acciones y condiciones de finalización | Principal | Secundaria | Principal | - |
| Entornos reproducibles y reinicio | Principal | Secundaria | Secundaria | - |
| Construir verificadores y funciones de recompensa | Secundaria | Principal | - | - |
| Detectar reward hacking y éxitos no válidos | - | Principal | Secundaria | - |
| Recopilar, puntuar y revisar trayectorias | - | - | Principal | Secundaria |
| Preparar datos para entrenamiento SFT y evaluación | - | - | - | Principal |
| Laguna: matemáticas de gradiente de política en RL y funcionamiento interno del entrenador | No cubierto | No cubierto | No cubierto | Se mantiene aparte |
| Laguna: modelado denso de recompensas de proceso a nivel de paso | No cubierto | Solo recompensa de resultado | No cubierto | No cubierto |
Las dos filas de lagunas importan. Las charlas mencionan entrenadores como SkyRL y Tinker, pero nunca muestran el bucle de entrenamiento, así que las habilidades no fingen cubrirlo.
Pon las habilidades a trabajar
Cada habilidad vive en su propia carpeta dentro de rl-env-skills/:
sandboxed-task-environment-scaffolder- crea y valida tareas reproducibles en contenedores.verifier-and-anti-cheat-auditor- construye verificadores de resultados y los audita en busca de reward hacking.rollout-trajectory-collector-and-debugger- ejecuta rollouts en sandbox, registra trayectorias y clasifica los fallos.trajectory-to-sft-dataset-preparer- filtra las trayectorias verificadas para obtener datos SFT limpios, siempre separados del entrenamiento de RL.
Indica a un compañero de trabajo una de ellas y dale una tarea real, por ejemplo:
Use rl-env-skills/verifier-and-anti-cheat-auditor/SKILL.md to design a verifier
for my "make this failing unit test pass" task. Flag any way an agent could
pass without fixing the bug.
La habilidad contiene el procedimiento, las reglas de decisión y las comprobaciones de éxito. El archivo de evidencias contiene las pruebas y, con el nuevo encargo, también los aprendizajes.
Hazlo tuyo
El encargo sirve para cualquier conjunto de charlas técnicas. Cambia los enlaces de vídeo y la lista de enfoques, y conserva el resto:
- Conserva las reglas de aprendizajes. Son las que convierten un manual de herramientas en criterio ganado a pulso.
- Conserva las reglas de honestidad. Las comprobaciones de capacidades y las etiquetas de las afirmaciones son lo que hace fiable el resultado.
- Conserva el paso de validación. Una habilidad que nunca se ha ejecutado es una nota, no una habilidad.
Una hora y media de charlas no tiene por qué seguir siendo una hora y media de charlas. Dáselas a tus agentes y quédate con lo que aprenden.
Créditos: creado con Gemini 4 y Eigent. Charlas de Mike Merrill (Ray Summit 2025), Alex Shaw y Ryan Marten (AI Engineer) y los fundadores de Terminal-Bench en Latent Space; mira los originales en YouTube. Música: "Wallpaper" Kevin MacLeod (incompetech.com), con licencia Creative Commons: By Attribution 4.0.
