[原理限制] 为什么 openclaw_youtube 暂时做不成 B 站那种“任意视频评论触发”

通用
, ,
1

截至 2026-03-18，这个方向我已经把官方 API 能走的路基本验证完了。结论先说：如果目标是像 B 站那样，机器人在 任意 YouTube 视频 下面都能发现触发评论，然后自动总结视频、结合字幕、再发评论，那么 只靠 YouTube 官方 Data API v3 基本做不成。

不是因为 YouTube 不能评论，也不是因为 OAuth 不行，而是因为最关键的那一步：发现触发评论，官方 API 没给出可用能力。

想做成的效果是什么

目标其实很明确：

  • 账号 A 或机器人账号，在任意 YouTube 视频下都能工作
  • 触发方式可以是 @fixcolar，也可以是固定激活词，比如“椰子 结合字幕总结本视频”
  • 一旦命中触发，系统自动拿到视频、评论、上下文
  • 如果有字幕，就把字幕注入给 LLM
  • 最后再由该账号自动回到这个视频评论区里发评论

B 站插件之所以能成立，是因为它不是在“扫视频评论区”，而是在读账号自己的 @ 消息流 / 回复消息流。只要全站任意视频里有人 @ 了你，B 站都会把这件事塞进消息流，所以插件才能跨视频工作。

YouTube 官方 API 这里，卡点正好就在这一步。

为什么官方 API 方案走不通

1. commentThreads.list 不能按“评论作者”查，也没有全站 mention 流

官方文档：

commentThreads.list 能用的过滤方式，核心就是这些：

  • videoId
  • allThreadsRelatedToChannelId
  • id

也就是说，你最多只能：

  • 查某个视频下的评论线程
  • 查某个频道相关的评论线程
  • 按已知 thread id 查

它 不能 做这些事：

  • 查“某个账号最近在哪些视频下评论了”
  • 查“全站哪里有人 @ 了我”
  • 查“全站哪里出现了我的激活词”

这意味着：只靠这个接口，你只能盯固定频道或固定视频，做不成“任意视频触发”。

2. comments.list 也不能按作者查历史

官方文档：

comments.list 只支持的核心过滤方式是：

  • id
  • parentId

它更像是“我已经知道 commentId 了，请把这条评论或它的回复给我拿出来”，而不是“帮我找这个人最近都评论了什么”。

所以它也解决不了“发现任意视频中的触发评论”这个问题。

3. activities.list?mine=true 也救不了

官方文档：

直觉上最像的思路，是不是可以拿账号自己的 activity feed？

但官方这里写得很明确：

  • comment 类型“not currently returned”
  • activities.list does not currently return resources for new comments

也就是说，账号自己的 activity feed 不能用来稳定拿“我刚在哪条视频下面评论了”。

4. 官方 Push Notification 也不推评论事件

官方文档：

这个推送机制推的是频道 feed 变化，本质还是围绕频道内容更新，不是评论/mention 事件流。

所以它也没法替代“全站评论发现”。

5. Gmail 评论通知不稳定，只能算旁路，不适合当主链路

官方帮助：

官方帮助里甚至专门提醒：

consecutive comments on a video may not lead to notifications for each

也就是说，连续评论未必每条都会通知。拿邮件做主触发链路，天然会漏事件。

这意味着什么

官方 API 仍然有用的部分

YouTube API 不是完全没用，它在 后半段 其实是有价值的：

  • 已知视频后，可以发顶层评论：commentThreads.insert
  • 已知 parent comment 后，可以发回复：comments.insert
  • 可以拿视频 metadata
  • 配合 yt-dlp，还能抓公开视频已有字幕

也就是说：

“评论发现”不行，但“评论发送”是可行的。

真正缺失的是前半段

缺的是：

  • 发现账号 A 自己刚刚在哪些视频下留言了
  • 发现全站哪里有人 @ 了机器人
  • 发现任意视频下是否出现了激活词评论

没有这一步，整个“像 B 站那样全站触发”的方案就立不住。

所以当前 API 版 openclaw_youtube 的定位应该怎么理解

如果只看官方 API 这条路，它比较适合这些窄场景：

  • 监控自己频道收到的评论
  • 监控固定频道/固定视频下的评论
  • 在已知 commentId / videoId 的情况下自动回帖
  • 用户明确要求“结合字幕”时，注入公开字幕

但它 不适合 这个目标：

  • 任意视频下 @fixcolar 就触发
  • 任意视频下自己发“椰子 结合字幕总结本视频”就触发

所以继续在官方 Data API 上堆参数，意义不大。不是工程量问题，而是接口本身不提供这类发现能力。

后续有哪些“曲线救国”方案

下面这些方向不是空想，而是目前真正还有希望落地的路线。

方案一：油猴脚本 / 浏览器扩展主动触发

这是我目前最看好的方案。

做法是：

  • 你打开任意 YouTube 视频页
  • 油猴脚本或扩展直接读取当前页面的 videoId
  • 你点一个按钮，或者脚本内置固定 prompt，比如“结合字幕总结本视频”
  • 前端把 videoId + prompt 发给本地服务
  • 后端拿字幕、跑 LLM，再通过 API 发评论

这条路线的好处是：

  • 不需要发现“我在哪里评论过”
  • 不依赖 YouTube 给不给通知
  • 页面只负责触发，不负责真正发表评论
  • 真正发表评论仍然可以走官方 API，稳定性更高

如果后面要做“我在任意视频页点一下就自动发总结评论”，这条路线最靠谱。

方案二：已登录浏览器轮询 YouTube Studio / 通知页

这条路线更像 B 站消息流思路的替代品。

做法是：

  • 本机维持一个已登录 YouTube 的浏览器 profile
  • 插件或守护进程定时读取 YouTube Studio 的评论页、通知页或 mention 页
  • 解析出新的评论 / 提及 / 回复事件
  • 再把发现到的事件交给 OpenClaw 和官方 API 回复

优点：

  • 能逼近“任意视频 @ 就触发”的体验

缺点：

  • 本质是网页自动化，维护成本高
  • 页面结构改版就可能失效
  • 登录态、风控、验证码都比官方 API 麻烦

方案三：半自动 comment link / commentId 交接

这是最土但最稳的办法。

做法是：

  • 你自己先在任意视频下发一条触发评论
  • 然后把评论链接或 commentId 手动丢给机器人
  • 机器人拿到后，再走后端流程回复 / 总结 / 注入字幕

它不优雅，但能最快把“生成评论内容”这半段跑通。

方案四：混合架构

这其实是比较现实的长期架构：

  • 发现侧 用浏览器页面、油猴、扩展、Studio 通知页这类非官方路径
  • 执行侧 继续用官方 API 发顶层评论或回复

也就是：

  • 前半段靠网页上下文
  • 后半段靠正式 API

这是目前最工程上可辩护的一条路。

当前阶段的结论

我觉得这个结论应该说清楚，避免后面继续在错误方向上烧时间：

  • openclaw_youtube 如果坚持“只用官方 Data API”，它只能做成固定频道/固定视频评论机器人
  • 如果目标是“像 B 站那样任意视频触发”，必须放弃“纯 API 发现”这个假设
  • 真正能落地的，是 浏览器侧发现 + API 侧回复 的混合方案

换句话说：

YouTube 这件事，不是“不能做”，而是“不能只靠官方评论 API 做”。

这也是当前阶段最重要的结论。