DeveloperOct 13, 2026
Gemini 4: transforme tutoriais em vídeo em habilidades de engenharia de RL em produção
Eigent
De tutoriais de RL em vídeo a habilidades de engenharia de RL em produção
Quem constrói o Terminal-Bench e o Harbor compartilhou muito conhecimento de engenharia de RL conquistado a duras penas: como empacotam tarefas, como pegam agentes trapaceando, como transformam rollouts em dados de treinamento. A maior parte disso está em longas palestras de conferências.
Três dessas palestras somam cerca de uma hora e meia de vídeo. Valem cada minuto, mas são difíceis de reutilizar. Na próxima vez que você construir um ambiente, vai voltar a percorrer linhas do tempo atrás daquele slide de que se lembra.
Então entregamos a tarefa de assistir a uma equipe de agentes. Com o Gemini 4 no Eigent, um único briefing transformou três palestras sobre Terminal-Bench em quatro habilidades baseadas em arquivos para engenharia de ambientes de RL em produção, além de um relatório com links que mostra de onde veio cada ideia.
O fluxo de trabalho completo em resumo
Você escolhe as palestras. A partir daí, um único briefing leva até habilidades que seus agentes podem reutilizar. Cada etapa deixa um arquivo, para que você possa conferir o trabalho passo a passo.
| Etapa | O que acontece | O que você recebe |
|---|---|---|
| Escolher | Selecionar as palestras do YouTube com as quais você quer aprender | Uma lista curta de links de vídeo no briefing |
| Assistir | Baixar legendas e quadros, e assistir a cada palestra inteira | Um roteiro com marcações de tempo de cada palestra |
| Analisar | Extrair métodos, insights, resultados relatados e alertas | Pontos de aprendizado rotulados como OBSERVED, INFERRED ou UPDATED |
| Comparar | Colocar as palestras lado a lado | Onde concordam, onde divergem e como cada uma preenche as lacunas das outras |
| Destilar | Agrupar métodos e insights por capacidade prática | Um SKILL.md e um evidence.md por habilidade |
| Validar | Verificar a estrutura, executar scripts e testar uma habilidade em uma tarefa nova | Cada habilidade marcada como STRUCTURALLY CHECKED, EXECUTED ou UNTESTED |
| Relatar | Criar e servir um relatório HTML em 127.0.0.1 | Palestras incorporadas, marcações de tempo clicáveis e uma matriz de cobertura que mostra as lacunas |
| Reutilizar | Apontar um colega de trabalho para um SKILL.md | Engenharia de ambientes de RL em produção no seu próprio projeto |
Veja como fazer isso você mesmo, passo a passo, incluindo uma lição que aprendemos ao escrever o briefing.
O que você vai obter
- Habilidades reutilizáveis - cada uma é um
SKILL.mdcom umevidence.md, escritas para que outro agente possa aplicá-las sem assistir às palestras. - Um relatório HTML com links para as fontes - servido localmente, com todas as palestras incorporadas, um roteiro com marcações de tempo e pontos de aprendizado em que você pode clicar para ir direto ao momento.
- Uma matriz de cobertura - qual habilidade cobre qual parte do fluxo de trabalho de RL e quais áreas nenhuma palestra aborda.
- Um registro honesto - cada afirmação rotulada como OBSERVED, INFERRED ou UPDATED, e cada habilidade marcada como executada, verificada estruturalmente ou não testada.
Antes de começar
- Eigent instalado no seu computador.
- Uma chave de API do Gemini.
- Os links do YouTube com os quais você quer que seus agentes aprendam. Usamos estes três:
| Palestra | Canal | Duração |
|---|---|---|
| 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 |
Adicione sua chave de API do Gemini
- Abra Settings → Models.
- Encontre Gemini e abra as configurações.
- Cole sua API key.
- Defina o model type como
gemini-4. - Clique em Save.
Selecione o Gemini 4
- Na tela inicial, abra o seletor de modelo abaixo da caixa de entrada.
- Escolha Gemini → gemini-4.
- Ajuste o nível de raciocínio se quiser - o padrão funciona.
Cole o briefing
Copie o briefing abaixo na caixa de entrada Cowork with. Troque os links pelos seus próprios vídeos e defina a linha do Docker como 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.
Algumas partes deste briefing fazem o trabalho pesado:
- Use only these videos mantém seus agentes nas fontes que você escolheu - sem trocas, sem extras.
- Capture insights, not only procedures garante que o porquê acompanhe o como. Mais sobre isso abaixo.
- Capability honesty impede que alguém descreva um quadro de vídeo que ninguém realmente viu.
- Os rótulos OBSERVED / INFERRED / UPDATED mantêm separados os fatos, a interpretação e as atualizações conferidas na documentação.
- As distinções de dados mantêm separados os conjuntos de dados de tarefas, as trajetórias, os exemplos supervisionados e a otimização de políticas de RL - para que exportar trajetórias nunca seja confundido com treinamento.
O que mudamos no briefing - e por quê
A execução do nosso vídeo usou uma versão anterior deste briefing. Ela acertou em muita coisa. O Gemini 4 assistiu às três palestras, conferiu os detalhes na documentação e no repositório do Harbor e criou quatro habilidades. O script de cada habilidade rodou de ponta a ponta em uma tarefa que nenhuma das palestras usa - consertar um parser de configuração em Python chamado fix-ini-interpolator.
Mas, ao ler as habilidades, notamos algo. Elas dependiam demais dos recursos do Harbor - estrutura de pastas de tarefas, formatos de trajetória e comandos de CLI. Os insights por trás delas ficaram, em sua maioria, no relatório.
E as palestras estão cheias de insights. O próprio relatório registrou estes:
- O scaffolding importa tanto quanto o modelo. Cancelar cedo os comandos travados rendeu cerca de 5–10%, e misturar modelos em uma mesma execução rendeu cerca de 5–6% (palestra do Ray Summit, 18:05–19:23).
- Planeje a escala desde cedo. Um notebook chega no máximo a uns seis contêineres simultâneos, e é por isso que as equipes migraram para sandboxes na nuvem (as três palestras).
- Reward hacking é o overfitting do RL. Trate uma pontuação suspeitamente alta como você trataria uma perda de validação suspeitamente baixa (palestra do AI Engineer, 06:35).
Uma habilidade que só sabe como rodar uma ferramenta não consegue dizer quando a abordagem falha, nem o que fazer em um stack sem essa ferramenta. Por isso fizemos quatro mudanças:
- Insights são um resultado de primeira classe. Cada seção de vídeo e cada habilidade agora registram o raciocínio dos palestrantes, as lições, os resultados e os alertas - cada um com marcação de tempo.
- Princípio primeiro, ferramenta depois. Harbor e Terminal-Bench contam como uma forma de aplicar um método, não como o método em si.
- Nada de wrappers de ferramentas. Toda habilidade precisa de uma seção de insights principais e de um caminho independente de ferramentas. Tire os comandos, e a habilidade ainda deve ensinar algo.
- A validação verifica isso. Cada habilidade precisa trazer pelo menos três insights com fonte, ou não passa na verificação estrutural.
Também corrigimos uma pequena inconsistência. O briefing anterior dizia "os dois vídeos", mas listava três links. O Gemini 4 percebeu, registrou isso no relatório e analisou os três - mas a nova redação funciona para qualquer quantidade de vídeos.
Deixe seus agentes trabalharem
Envie o briefing. O Gemini 4 planeja o trabalho e inicia os agentes. A partir daí, a execução segue o briefing:
- Assistir a cada palestra - legendas, quadros, slides e demonstrações ao vivo - e manter as marcações de tempo.
- Destilar os métodos e insights em habilidades, cada uma com seu próprio arquivo de evidências.
- Validar as habilidades e registrar o que foi verificado, executado ou deixado sem teste.
- Gerar o relatório e servi-lo em
127.0.0.1.
Na nossa execução, os agentes baixaram as três palestras, extraíram mais de 25 quadros-chave, obtiveram as transcrições completas com marcações de tempo e conferiram os detalhes do Harbor na documentação oficial - depois apagaram os arquivos de vídeo baixados, como o briefing pede.
Abra o relatório
O relatório abre em um servidor local - na nossa execução, http://127.0.0.1:8000. Veja o que você vai encontrar:
- Capacidades - o que os agentes tinham e o que faltava, de assistir a vídeos à pré-visualização no navegador.
- Resumo e fontes - cada palestra com canal, data de publicação, duração, visualizações e repositórios vinculados.
- Uma seção por palestra - o vídeo incorporado com um player de privacidade aprimorada, um roteiro com marcações de tempo e pontos de aprendizado rotulados.
- Como as palestras se comparam - onde concordam, onde divergem e como cada uma preenche as lacunas das outras.
- Uma seção por habilidade - propósito, etapas principais, evidências e o comando de validação exato.
- Limitações - o que ficou sem teste e por quê, como sandboxes na nuvem e APIs de modelos pagas.
Leia a matriz de cobertura
A matriz mostra qual habilidade cobre qual parte do fluxo de trabalho de RL - e onde as palestras deixam lacunas.
| Área de foco | Task Scaffolder | Verifier & Anti-Cheat | Rollout Collector | SFT Dataset Preparer |
|---|---|---|---|---|
| Definir tarefas, observações, ações e condições de término | Principal | Secundária | Principal | - |
| Ambientes reproduzíveis e reinicialização | Principal | Secundária | Secundária | - |
| Construir verificadores e funções de recompensa | Secundária | Principal | - | - |
| Detectar reward hacking e sucessos inválidos | - | Principal | Secundária | - |
| Coletar, pontuar e revisar trajetórias | - | - | Principal | Secundária |
| Preparar dados para treinamento SFT e avaliação | - | - | - | Principal |
| Lacuna: matemática de gradiente de política em RL e funcionamento interno do treinador | Não coberto | Não coberto | Não coberto | Mantido à parte |
| Lacuna: modelagem densa de recompensa de processo por etapa | Não coberto | Só recompensa de resultado | Não coberto | Não coberto |
As duas linhas de lacunas importam. As palestras citam treinadores como SkyRL e Tinker, mas nunca mostram o loop de treinamento - então as habilidades não fingem cobri-lo.
Coloque as habilidades para trabalhar
Cada habilidade fica em sua própria pasta dentro de rl-env-skills/:
sandboxed-task-environment-scaffolder- cria e valida tarefas reproduzíveis em contêineres.verifier-and-anti-cheat-auditor- constrói verificadores de resultado e os audita em busca de reward hacking.rollout-trajectory-collector-and-debugger- executa rollouts em sandbox, registra trajetórias e classifica as falhas.trajectory-to-sft-dataset-preparer- filtra trajetórias verificadas em dados SFT limpos, sempre separados do treinamento de RL.
Aponte um colega de trabalho para uma delas e dê a ele uma tarefa real, por exemplo:
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.
A habilidade traz o procedimento, as regras de decisão e as verificações de sucesso. O arquivo de evidências traz as comprovações - e, com o novo briefing, os insights vêm junto.
Adapte para você
O briefing funciona para qualquer conjunto de palestras técnicas. Troque os links dos vídeos e a lista de focos, e mantenha o resto:
- Mantenha as regras de insights. São elas que transformam um manual de ferramenta em discernimento conquistado a duras penas.
- Mantenha as regras de honestidade. As verificações de capacidade e os rótulos das afirmações são o que torna o resultado confiável.
- Mantenha a etapa de validação. Uma habilidade que nunca foi executada é uma anotação, não uma habilidade.
Uma hora e meia de palestras não precisa continuar sendo uma hora e meia de palestras. Entregue-as aos seus agentes - e guarde o que eles aprendem.
Créditos: feito com Gemini 4 e Eigent. Palestras de Mike Merrill (Ray Summit 2025), Alex Shaw e Ryan Marten (AI Engineer) e dos fundadores do Terminal-Bench no Latent Space - assista aos originais no YouTube. Música: "Wallpaper" Kevin MacLeod (incompetech.com), licenciada sob Creative Commons: By Attribution 4.0.
