A fecha de 2026-03-18, en esta dirección ya he verificado básicamente todas las vías que se pueden recorrer con la API oficial. Voy directo a la conclusión: si el objetivo es como en Bilibili, que un bot pueda descubrir comentarios disparadores debajo de cualquier video de YouTube, luego resumir automáticamente el video, combinar subtítulos y después publicar un comentario, entonces solo con la YouTube Data API v3 oficial, básicamente no se puede.
No es porque YouTube no permita comentar, ni porque OAuth no funcione, sino porque el paso más crítico: descubrir el comentario disparador, la API oficial no ofrece una capacidad utilizable.
¿Cuál es el efecto que se quiere lograr?
El objetivo en realidad es muy claro:
- La cuenta A o la cuenta del bot puede funcionar debajo de cualquier video de YouTube
- La forma de disparo puede ser
@fixcolar, o una palabra de activación fija, por ejemplo: “椰子 结合字幕总结本视频” - En cuanto se detecta el disparo, el sistema obtiene automáticamente el video, el comentario y el contexto
- Si hay subtítulos, se inyectan al LLM
- Por último, esa cuenta vuelve automáticamente a la sección de comentarios de ese video y publica un comentario
La razón por la que el plugin de Bilibili puede funcionar es porque no está “escaneando la sección de comentarios del video”, sino leyendo el flujo de mensajes de @ / flujo de respuestas de la propia cuenta. Mientras en cualquier video del sitio alguien te @, Bilibili mete eso en el flujo de mensajes, por eso el plugin puede funcionar a través de videos.
En la API oficial de YouTube, el cuello de botella está justo en ese paso.
Por qué la solución con la API oficial no funciona
1. commentThreads.list no puede filtrar por “autor del comentario”, ni existe un feed global de menciones
Documentación oficial:
Los filtros principales disponibles en commentThreads.list son básicamente estos:
videoIdallThreadsRelatedToChannelIdid
Es decir, como mucho puedes:
- Consultar los hilos de comentarios bajo un video específico
- Consultar los hilos de comentarios relacionados con un canal específico
- Consultar por un thread id ya conocido
Pero no puede hacer estas cosas:
- Consultar “en qué videos comentó recientemente una cuenta”
- Consultar “en qué parte del sitio alguien me @”
- Consultar “en qué parte del sitio apareció mi palabra de activación”
Esto significa: solo con este endpoint, solo puedes vigilar canales o videos fijos; no se puede lograr el “disparo en cualquier video”.
2. comments.list tampoco permite buscar el historial por autor
Documentación oficial:
Los filtros principales que admite comments.list son:
idparentId
Se parece más a “ya conozco el commentId, por favor dame este comentario o sus respuestas”, y no a “ayúdame a encontrar qué ha comentado recientemente esta persona”.
Así que tampoco resuelve el problema de “descubrir comentarios disparadores en cualquier video”.
3. activities.list?mine=true tampoco salva la situación
Documentación oficial:
Intuitivamente, la idea más parecida sería: ¿se puede obtener el feed de actividades de la propia cuenta?
Pero aquí la documentación oficial lo dice claramente:
- El tipo
comment“not currently returned” activities.listdoes not currently return resources for new comments
Es decir, el feed de actividades de la cuenta no se puede usar para obtener de forma estable “en qué video acabo de comentar”.
4. Las Push Notifications oficiales tampoco empujan eventos de comentarios
Documentación oficial:
Este mecanismo de push empuja cambios del feed del canal; en esencia sigue girando alrededor de actualizaciones de contenido del canal, no de un flujo de eventos de comentarios/menciones.
Así que tampoco puede sustituir el “descubrimiento de comentarios en todo el sitio”.
5. Las notificaciones por Gmail de comentarios no son estables; solo sirven como vía alternativa y no son adecuadas como vía principal
Ayuda oficial:
En la ayuda oficial incluso advierten específicamente:
consecutive comments on a video may not lead to notifications for each
Es decir, comentarios consecutivos no necesariamente generan una notificación por cada uno. Usar el correo como cadena principal de disparo, por naturaleza perderá eventos.
¿Qué implica esto?
La parte en la que la API oficial todavía es útil
La API de YouTube no es completamente inútil; en la segunda mitad sí tiene valor:
- Una vez conocido el video, se puede publicar un comentario de nivel superior:
commentThreads.insert - Una vez conocido el parent comment, se puede responder:
comments.insert - Se puede obtener metadata del video
- Con
yt-dlp, también se pueden extraer subtítulos públicos existentes de videos públicos
Es decir:
“Descubrir comentarios” no, pero “enviar comentarios” sí es viable.
Lo que realmente falta es la primera mitad
Lo que falta es:
- Descubrir en qué videos acaba de dejar un mensaje la cuenta A
- Descubrir en qué parte del sitio alguien @ al bot
- Descubrir si bajo cualquier video apareció un comentario con la palabra de activación
Sin ese paso, toda la propuesta de “disparo global como en Bilibili” no se sostiene.
Entonces, ¿cómo debería entenderse el posicionamiento de la versión API actual de openclaw_youtube?
Si solo se mira el camino de la API oficial, es más adecuada para estos escenarios estrechos:
- Monitorizar los comentarios recibidos en el propio canal
- Monitorizar comentarios bajo un canal fijo / video fijo
- Responder automáticamente en el caso de conocer
commentId/videoId - Cuando el usuario pide explícitamente “combinar subtítulos”, inyectar subtítulos públicos
Pero no es adecuada para este objetivo:
- Que en cualquier video un
@fixcolardispare - Que en cualquier video uno mismo publique “椰子 结合字幕总结本视频” y se dispare
Así que seguir apilando parámetros sobre la Data API oficial tiene poco sentido. No es un problema de carga de ingeniería, sino de que la interfaz en sí no ofrece este tipo de capacidad de descubrimiento.
Qué soluciones “por la tangente” existen a futuro
Las siguientes direcciones no son fantasía; son rutas que a día de hoy todavía tienen posibilidades reales de aterrizar.
Opción 1: script de Tampermonkey / extensión del navegador para disparo activo
Esta es la opción que veo con mejores ojos ahora mismo.
La forma de hacerlo:
- Abres cualquier página de video de YouTube
- El script de Tampermonkey o la extensión lee directamente el
videoIdde la página actual - Haces clic en un botón, o el script trae un prompt fijo incorporado, por ejemplo “结合字幕总结本视频”
- El frontend envía
videoId + promptal servicio local - El backend obtiene subtítulos, ejecuta el LLM y luego publica el comentario vía API
Ventajas de esta ruta:
- No hace falta descubrir “dónde he comentado”
- No depende de si YouTube envía o no notificaciones
- La página solo se encarga del disparo, no de publicar realmente el comentario
- Publicar el comentario aún puede ir por la API oficial, con mayor estabilidad
Si más adelante se quiere “en cualquier página de video, con un clic, publicar automáticamente un comentario-resumen”, esta ruta es la más fiable.
Opción 2: sondeo (polling) con navegador logueado a YouTube Studio / página de notificaciones
Esta ruta se parece más a un sustituto del enfoque de flujo de mensajes de Bilibili.
La forma de hacerlo:
- Mantener en la máquina un perfil de navegador con YouTube ya iniciado sesión
- Un plugin o proceso daemon lee periódicamente la página de comentarios, notificaciones o menciones de YouTube Studio
- Analiza nuevos eventos de comentarios / menciones / respuestas
- Entrega los eventos descubiertos a OpenClaw y responde con la API oficial
Ventajas:
- Puede acercarse a la experiencia de “en cualquier video, con @ se dispara”
Desventajas:
- En esencia es automatización web, con alto coste de mantenimiento
- Si cambia la estructura de la página, puede fallar
- Estado de sesión, controles de riesgo y captchas son más problemáticos que con la API oficial
Opción 3: traspaso semimanual de comment link / commentId
Es el método más tosco pero el más estable.
La forma de hacerlo:
- Primero tú mismo publicas un comentario disparador bajo cualquier video
- Luego le pasas manualmente al bot el enlace del comentario o el commentId
- El bot, al obtenerlo, sigue el flujo backend para responder / resumir / inyectar subtítulos
No es elegante, pero permite poner en marcha lo más rápido posible la mitad de “generar el contenido del comentario”.
Opción 4: arquitectura híbrida
Esta es una arquitectura a largo plazo bastante realista:
- En el lado de descubrimiento, usar rutas no oficiales como páginas del navegador, Tampermonkey, extensiones, página de notificaciones de Studio
- En el lado de ejecución, seguir usando la API oficial para publicar comentarios de nivel superior o respuestas
Es decir:
- La primera mitad depende del contexto web
- La segunda mitad depende de la API formal
Esta es por ahora una ruta defendible desde el punto de vista de ingeniería.
Conclusión de la etapa actual
Creo que esta conclusión debe decirse claramente para evitar seguir quemando tiempo en la dirección equivocada:
- Si
openclaw_youtubeinsiste en “usar solo la Data API oficial”, solo puede convertirse en un bot de comentarios para canales/videos fijos - Si el objetivo es “disparar en cualquier video como en Bilibili”, hay que abandonar la suposición de “descubrimiento puramente por API”
- Lo que realmente puede aterrizar es una solución híbrida de descubrimiento en el navegador + respuesta vía API
Dicho de otra manera:
Con YouTube, no es que “no se pueda hacer”, sino que “no se puede hacer solo con la API oficial de comentarios”.
Esta es también la conclusión más importante de la etapa actual.