DeveloperOct 13, 2026
Gemini 4 : transformer des tutoriels vidéo en compétences d'ingénierie RL en production
Eigent
Des tutoriels vidéo RL aux compétences d'ingénierie RL en production
Les équipes derrière Terminal-Bench et Harbor ont partagé beaucoup de connaissances durement acquises en ingénierie RL : comment elles empaquettent les tâches, comment elles repèrent les agents qui trichent, comment elles transforment les rollouts en données d'entraînement. L'essentiel se trouve dans de longues conférences.
Trois de ces conférences représentent environ une heure et demie de vidéo. Chaque minute en vaut la peine - mais elles sont difficiles à réutiliser. La prochaine fois que vous construirez un environnement, vous ferez à nouveau défiler les timelines pour retrouver la diapositive dont vous vous souvenez.
Nous avons donc confié le visionnage à une équipe d'agents. Avec Gemini 4 dans Eigent, un seul brief a transformé trois conférences sur Terminal-Bench en quatre compétences sous forme de fichiers pour l'ingénierie d'environnements RL en production, ainsi qu'un rapport avec liens vers les sources qui montre d'où vient chaque idée.
Le workflow complet en un coup d'œil
C'est vous qui choisissez les conférences. Ensuite, un seul brief vous mène jusqu'à des compétences que vos agents peuvent réutiliser. Chaque étape laisse un fichier, pour que vous puissiez vérifier le travail à chaque étape.
| Étape | Ce qui se passe | Ce que vous obtenez |
|---|---|---|
| Choisir | Sélectionner les conférences YouTube dont vous voulez apprendre | Une courte liste de liens vidéo dans le brief |
| Regarder | Télécharger sous-titres et images, et regarder chaque conférence en entier | Un plan horodaté de chaque conférence |
| Analyser | Extraire méthodes, enseignements, résultats rapportés et mises en garde | Points d'apprentissage étiquetés OBSERVED, INFERRED ou UPDATED |
| Comparer | Confronter les conférences entre elles | Leurs points d'accord, leurs différences et la façon dont chacune comble les lacunes des autres |
| Distiller | Regrouper méthodes et enseignements par capacité pratique | Un SKILL.md et un evidence.md par compétence |
| Valider | Vérifier la structure, exécuter les scripts, tester une compétence sur une nouvelle tâche | Chaque compétence marquée STRUCTURALLY CHECKED, EXECUTED ou UNTESTED |
| Rapporter | Construire et servir un rapport HTML sur 127.0.0.1 | Conférences intégrées, horodatages cliquables et matrice de couverture qui montre les lacunes |
| Réutiliser | Indiquer un SKILL.md à un collaborateur | Ingénierie d'environnements RL en production sur votre propre projet |
Voici comment le faire vous-même, étape par étape - y compris une leçon que nous avons tirée de la rédaction du brief.
Ce que vous obtiendrez
- Des compétences réutilisables - chacune est un
SKILL.mdaccompagné d'unevidence.md, rédigées pour qu'un autre agent puisse les appliquer sans regarder les conférences. - Un rapport HTML avec liens vers les sources - servi en local, avec chaque conférence intégrée, un plan horodaté et des points d'apprentissage sur lesquels cliquer pour aller directement au bon moment.
- Une matrice de couverture - quelle compétence couvre quelle partie du workflow RL, et quels domaines aucune conférence n'aborde.
- Une traçabilité honnête - chaque affirmation étiquetée OBSERVED, INFERRED ou UPDATED, et chaque compétence marquée comme exécutée, vérifiée structurellement ou non testée.
Avant de commencer
- Eigent installé sur votre machine.
- Une clé API Gemini.
- Les liens YouTube dont vous voulez que vos agents apprennent. Nous avons utilisé ces trois :
| Conférence | Chaîne | Durée |
|---|---|---|
| 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 |
Ajoutez votre clé API Gemini
- Ouvrez Settings → Models.
- Trouvez Gemini et ouvrez ses paramètres.
- Collez votre API key.
- Réglez le model type sur
gemini-4. - Cliquez sur Save.
Sélectionnez Gemini 4
- Sur l'écran d'accueil, ouvrez le sélecteur de modèle sous la zone de saisie.
- Choisissez Gemini → gemini-4.
- Réglez le niveau de réflexion si vous le souhaitez - la valeur par défaut fonctionne.
Collez le brief
Copiez le brief ci-dessous dans la zone de saisie Cowork with. Remplacez les liens par vos propres vidéos, et réglez la ligne Docker sur allowed ou 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.
Quelques parties de ce brief font l'essentiel du travail :
- Use only these videos maintient vos agents sur les sources que vous avez choisies - pas de remplacement, pas d'ajout.
- Capture insights, not only procedures garantit que le pourquoi accompagne le comment. Nous y revenons plus bas.
- Capability honesty empêche quiconque de décrire une image vidéo que personne n'a réellement vue.
- Les étiquettes OBSERVED / INFERRED / UPDATED séparent les faits, l'interprétation et les mises à jour vérifiées dans la documentation.
- Les distinctions de données séparent les jeux de données de tâches, les trajectoires, les exemples supervisés et l'optimisation de politique RL - pour que l'export de trajectoires ne soit jamais confondu avec un entraînement.
Ce que nous avons changé dans le brief - et pourquoi
L'exécution de notre vidéo utilisait une version antérieure de ce brief. Elle a fait beaucoup de choses correctement. Gemini 4 a regardé les trois conférences, recoupé les détails avec la documentation et le dépôt de Harbor, et construit quatre compétences. Le script de chaque compétence s'est exécuté de bout en bout sur une tâche qu'aucune conférence n'utilise : réparer un analyseur de configuration Python appelé fix-ini-interpolator.
Mais en lisant les compétences, nous avons remarqué quelque chose. Elles s'appuyaient fortement sur les fonctionnalités de Harbor - structure des dossiers de tâches, formats de trajectoires et commandes CLI. Les enseignements qui les sous-tendent restaient pour la plupart dans le rapport.
Et les conférences regorgent d'enseignements. Le rapport lui-même en a relevé plusieurs :
- Le scaffold compte autant que le modèle. Annuler tôt les commandes bloquées a rapporté environ 5 à 10 %, et mélanger plusieurs modèles dans une même exécution environ 5 à 6 % (conférence Ray Summit, 18:05–19:23).
- Anticipez le passage à l'échelle. Un ordinateur portable plafonne à environ six conteneurs simultanés, ce qui explique le passage des équipes à des sandboxes cloud (les trois conférences).
- Le reward hacking est le surapprentissage du RL. Traitez un score étrangement élevé comme vous traiteriez une perte de validation étrangement basse (conférence AI Engineer, 06:35).
Une compétence qui sait seulement comment utiliser un outil ne peut pas vous dire quand l'approche échoue, ni quoi faire sur une stack sans cet outil. Nous avons donc fait quatre changements :
- Les enseignements deviennent un livrable à part entière. Chaque section vidéo et chaque compétence consignent désormais le raisonnement des intervenants, leurs leçons, leurs résultats et leurs mises en garde - chacun avec un horodatage.
- Le principe d'abord, l'outil ensuite. Harbor et Terminal-Bench sont une façon d'appliquer une méthode, pas la méthode elle-même.
- Pas de simples surcouches d'outils. Chaque compétence doit avoir une section d'enseignements clés et une voie indépendante des outils. Retirez les commandes : la compétence doit encore enseigner quelque chose.
- La validation le vérifie. Chaque compétence doit comporter au moins trois enseignements sourcés, sinon elle échoue à la vérification structurelle.
Nous avons aussi corrigé une petite incohérence. L'ancien brief parlait des « deux vidéos » mais listait trois liens. Gemini 4 l'a remarqué, l'a signalé dans le rapport et a analysé les trois - mais la nouvelle formulation fonctionne quel que soit le nombre de vidéos.
Laissez vos agents travailler
Envoyez le brief. Gemini 4 planifie le travail et lance les agents. Ensuite, l'exécution suit le brief :
- Regarder chaque conférence - sous-titres, images, diapositives et démos en direct - en conservant les horodatages.
- Distiller les méthodes et les enseignements en compétences, chacune avec son propre fichier de preuves.
- Valider les compétences et consigner ce qui a été vérifié, exécuté ou laissé non testé.
- Générer le rapport et le servir sur
127.0.0.1.
Lors de notre exécution, les agents ont téléchargé les trois conférences, extrait plus de 25 images clés, récupéré les transcriptions horodatées complètes et recoupé les détails de Harbor avec la documentation officielle - puis supprimé les fichiers vidéo téléchargés, comme le demande le brief.
Ouvrez le rapport
Le rapport s'ouvre sur un serveur local - dans notre exécution, http://127.0.0.1:8000. Voici ce que vous y trouverez :
- Capacités - ce dont les agents disposaient et ce qui leur manquait, du visionnage vidéo à l'aperçu dans le navigateur.
- Résumé et sources - chaque conférence avec sa chaîne, sa date de publication, sa durée, ses vues et les dépôts associés.
- Une section par conférence - la vidéo intégrée avec un lecteur à confidentialité renforcée, un plan horodaté et des points d'apprentissage étiquetés.
- Comparaison des conférences - leurs points d'accord, leurs différences et la façon dont chacune comble les lacunes des autres.
- Une section par compétence - objectif, étapes clés, preuves et commande de validation exacte.
- Limites - ce qui est resté non testé et pourquoi, comme les sandboxes cloud et les API de modèles payantes.
Lisez la matrice de couverture
La matrice montre quelle compétence couvre quelle partie du workflow RL - et où les conférences laissent des lacunes.
| Domaine | Task Scaffolder | Verifier & Anti-Cheat | Rollout Collector | SFT Dataset Preparer |
|---|---|---|---|---|
| Définir tâches, observations, actions et conditions de fin | Principal | Secondaire | Principal | - |
| Environnements reproductibles et réinitialisation | Principal | Secondaire | Secondaire | - |
| Construire vérificateurs et fonctions de récompense | Secondaire | Principal | - | - |
| Détecter le reward hacking et les faux succès | - | Principal | Secondaire | - |
| Collecter, noter et examiner les trajectoires | - | - | Principal | Secondaire |
| Préparer les données pour l'entraînement SFT et l'évaluation | - | - | - | Principal |
| Lacune : mathématiques du gradient de politique RL et fonctionnement interne des trainers | Non couvert | Non couvert | Non couvert | Tenu à part |
| Lacune : façonnage dense de la récompense de processus au niveau des étapes | Non couvert | Récompense de résultat uniquement | Non couvert | Non couvert |
Les deux lignes de lacunes comptent. Les conférences citent des trainers comme SkyRL et Tinker sans jamais montrer la boucle d'entraînement - les compétences ne prétendent donc pas la couvrir.
Mettez les compétences au travail
Chaque compétence se trouve dans son propre dossier dans rl-env-skills/ :
sandboxed-task-environment-scaffolder- créer et valider des tâches conteneurisées reproductibles.verifier-and-anti-cheat-auditor- construire des vérificateurs de résultat et les auditer contre le reward hacking.rollout-trajectory-collector-and-debugger- exécuter des rollouts en sandbox, enregistrer les trajectoires et classer les échecs.trajectory-to-sft-dataset-preparer- filtrer les trajectoires vérifiées en données SFT propres, strictement séparées de l'entraînement RL.
Indiquez-en une à un collaborateur et confiez-lui une vraie tâche, par exemple :
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 compétence contient la procédure, les règles de décision et les critères de réussite. Le fichier de preuves contient les justificatifs - et avec le nouveau brief, les enseignements suivent aussi.
Adaptez-le à vos besoins
Le brief fonctionne pour n'importe quel ensemble de conférences techniques. Remplacez les liens vidéo et la liste des priorités, et gardez le reste :
- Gardez les règles sur les enseignements. Ce sont elles qui transforment un manuel d'outil en jugement durement acquis.
- Gardez les règles d'honnêteté. Les vérifications de capacités et les étiquettes d'affirmations rendent le résultat fiable.
- Gardez l'étape de validation. Une compétence qui n'a jamais été exécutée est une note, pas une compétence.
Une heure et demie de conférences n'a pas à rester une heure et demie de conférences. Confiez-les à vos agents - et gardez ce qu'ils apprennent.
Crédits : réalisé avec Gemini 4 et Eigent. Conférences de Mike Merrill (Ray Summit 2025), Alex Shaw et Ryan Marten (AI Engineer), et des fondateurs de Terminal-Bench sur Latent Space - regardez les originaux sur YouTube. Musique : "Wallpaper" Kevin MacLeod (incompetech.com), sous licence Creative Commons: By Attribution 4.0.
