这个 B站插件,是给 Agent 用的

想真把一条 B站视频看明白，往往得先翻简介，再抓字幕，滚评论区找观点，最后复制粘贴成笔记。换个视频，重来一遍。

直接把标题丢给通用大模型也不靠谱：它拿不到站内数据，没字幕、没弹幕、没评论，只能靠标题猜。

bili-cli 就是来补这块的。它把 B站的查询、字幕、弹幕、评论、搜索封成工具指令，交给 DSH 里的 Agent 自己规划、自己调用。

项目地址：https://github.com/kukemc/bili-cli 。作者 kukemc，TypeScript/Node，MIT 协议。它不算爆款独立工具，更像 DSH 生态里“养鱼”配套的常用基础组件，近期社区反复被提到，装了不显眼、少了又别扭。

最容易踩的坑：很多人以为 bili-cli 是终端里能直接敲的 B 站命令行工具，装完才发现 shell 里根本跑不起来。

它不是独立 CLI，而是 DSH（DeepSeek Harness）插件体系里的一条 Skill，必须由 dsh 环境加载，Agent 才会拿到这批 B站能力。市面上还有个 bilibili-cli，是独立 Python 命令行工具，和这个项目没关系，搜教程时容易走错门。

它能干的事挺具体：BV 号或链接换标题、简介、UP 主、播放量、分P、发布时间；拉字幕和 protobuf 原始弹幕并导出文本；搜视频、番剧、专栏、直播间；读 UP 主投稿和合集；抓评论区和楼中楼；可选挂 BBDown 做下载代理。账号类功能要登录 cookie，偏实验性质。

落到场景，就是让 Agent 总结单条视频、把字幕弹幕喂进分析流程、快速摸一个 UP 主的选题分布。它真正的价值不在功能条数，而在于这些能力由大模型自主编排——你只说一句需求，它自己判断先查信息还是先拉弹幕。

如果你还没用上 DeepSeek Harness，这一步暂时没意义，跳过。确认环境后，在 dsh 里执行：

dsh plugin add https://github.com/kukemc/bili-cli 

装完记得重启 DSH，Agent 才会加载新的工具指令。Cordis 插件热加载不一定生效，重启别省。

重启后别在终端里找命令，直接进对话：

获取 BVxxxx 视频的弹幕和字幕，并总结内容

它会自行规划：调工具拿元数据、拉 protobuf 弹幕、导出字幕文本，最后汇总。这条链路跑通，基本说明插件装对了。分P、UP 主、发布时间也能一起拿到。

查询和字幕是核心能力，走插件自己的接口。只有要把视频/音频保存到本地时，才需要额外配置 BBDown（拉流）和 ffmpeg（转码）。这两个都是可选依赖，不装不影响前面两步。

踩坑提醒：收藏夹、历史记录、关注列表这些要看登录 cookie，作者也标了“偏实验”。先用公开数据把流程走顺，再考虑 cookie；真要试，拿小号小范围验证。B站风控对异常调用挺敏感。

这个插件走的是逆向出来的 B站非公开接口，没有官方授权。B站改一次接口字段，对应功能就可能报错；风控一收紧，原来能拉到的字幕、弹幕、评论就可能变成空数组。这不是它不够努力，是这类工具的正常情况。

账号层面的风险更实际。cookie 登录模式下，批量查询、翻页拉评论很容易触发限流，严重时账号会被临时限制甚至封掉。用主账号跑任务，相当于把大号交给一个社区插件去承担风控。真想玩，注册个小号，或者用没绑手机的空号。

合规边界也划一下：弹幕、评论的批量爬取和批量下载，属于违反 B站用户协议的行为。个人学习、本地看内容没问题，但不要做商用采集，也不要把拉下来的资源二次分发。

还有一点容易被忽略：它强依赖 DSH，不能单独当命令行工具在终端跑。社区实验插件的更新节奏跟着 DSH 和 B站接口走，别放进生产链路的关键路径。

bili-cli 的定位其实很窄，就是 DSH 生态里给 B站打的一块能力补丁，让 Agent 顺手把站内数据拿到手边。它不打算替代下载器，也不承诺接口一直在线。把它当成“会自己找 B站素材的助手”来用，心态就对了；把它当生产环境里的采集管道，迟早要出问题。

如果你手上已经跑着 DSH，想让模型自己规划“先查元数据，再拉字幕弹幕，最后做总结”，它确实省心。反过来，你只是想要一个敲命令就能跑的下载或查询工具，没必要为了这点需求再搭一套环境，去找独立命令行工具更干脆。

最后聊个我一直在纠结的事：你们现在是把“拉字幕还是先看评论”这种决策交给 Agent 自己判断，还是干脆把流程固定成固定步骤？我这边两种做法来回改了好几轮——放权给模型灵活，但结果不稳定；步骤写死可复现，但遇到新视频类型又变死板。有踩过这个坑的朋友，评论区说说你们最后怎么定的。