Agent时代为何打造音乐CLI让搜索更高效

先设想两个常见的使用场景。

深夜，你正专注地写代码，想换一首合适的歌。以往的流程是：手离开键盘，切换到手机或桌面 App，刷几轮推荐列表，三首歌都不合心意，思路中断，最后随便放一首凑合。现在的流程：在对话框里顺手发一句「帮我找几首适合深夜写代码的音乐」，AI 处理完成后，BGM 自动切换，还附带一句推荐理由——你甚至没有离开编辑器。

另一个场景：用飞书办公了半天，想看看照片放松眼睛。直接在飞书发一句「用我的红心歌单帮我生成一个照片墙」，结果立刻呈现。这就是 ncm-cli 加上 OpenClaw 今天能够实现的效果。

“不知道听什么”一直是个痛点，直到 OpenClaw 出现

如大家所知，OpenClaw 代表了 Agent 交互方式的重大转折：AI 不再局限于浏览器中的对话界面，它可以成为你 IM 里随时响应的助手，并在你的机器上执行真实操作。

我们意识到，在这样的背景下，音乐是一个非常合适的场景来验证这个范式。为什么？因为「不知道听什么」是我们日常遇到的最典型的模糊意图之一——你不想搜索某首具体的歌曲，你想要的是「符合当下状态的音乐」。这种模糊意图正是 AI 擅长的领域，用传统搜索界面反而别扭。而且音乐操作有一个天然的特点：输入和输出分离。你用手机发送消息（输入），电脑播放音乐（输出）。OpenClaw 的跨设备特性与这个场景完美契合。

我们是怎么思考工具形态的

确定这件事值得做之后，第一个问题是：做成什么形态？App 不合适——需要维护 UI，更新较重，与 AI Agent 集成反而绕了弯路。插件或 SDK 依赖特定平台，换一个 Agent 就得重做。

我们选择了 CLI。这个判断背后有一个非常直接的逻辑：CLI 命令是 AI Agent 最天然的工具调用形式。一个 ncm-cli play --song xxx 的命令，对于 Claude、OpenClaw 里的 AI 或者任何其他 Agent 框架来说，调用方式完全一致。CLI 本身不依赖任何 AI 框架，它就是一个能被任何工具调用的原子化工具。

同时，CLI 也保留了「直接使用」的可能性——人工输入命令、Shell 脚本集成、自动化流水线，都没问题。基于这个形态，我们还设计了两个 Skill 来真正融入 Agent 中：

netease-music-cli —— 适合「我知道要听什么」的场景。搜索歌曲、播放、控制队列、管理歌单，直接高效。这个 Skill 有一个有意思的设计：我们没有在 Skill 定义中枚举所有命令，而是让 AI 自己通过 --help 逐渐发现功能。AI 接到任务后，会先执行 ncm-cli --help 查看顶层选项，再根据需要进入具体子命令查看参数，最后执行操作。整个过程与人第一次使用一个新 CLI 工具的探索方式完全一致。

这个设计有两个好处：一是 Skill 定义本身不需要随命令的增加或减少而更新；二是与后面介绍的动态命令系统形成了自然的协同——服务端新下发一个命令，AI 下次就能通过 --help 发现并使用它，整条链路不需要人工介入。

netease-music-assistant —— 适合「我不知道听什么」的场景。它会先读取你的红心歌曲，分析你的偏好（曲风、情绪、时间段习惯），然后制定多维度搜索策略，从歌单、专辑、单曲多个维度混合推荐，每条结果都附带个性化推荐理由，还会自动去重（不重复推荐你已经收藏或近期推荐过的内容）。两个 Skill 的分工非常清晰：前者是执行层，后者是决策层。

我们做了什么

ncm-cli 支持三种使用方式：

• AI Agent 集成（推荐）：自然语言操作，智能推荐，手机端控制
• CLI 命令行：脚本集成，精确控制
• TUI：播放器终端沉浸式体验

命令设计：不是从按钮出发，从 AI“原子操作”的视角出发

命令覆盖范围的选取，我们不是从「用户会点哪些按钮」出发，而是从「AI 完成一个音乐任务需要哪些原子操作」出发。

AI 处理一个请求，本质上是一个多步推理加执行的过程。以「帮我播放一首适合现在心情的歌」为例，AI 需要能够做这些事：

围绕这个流程，我们把命令分成了几个层次：

• 感知层：执行前先了解当前状态，避免盲目操作（state、queue）
• 发现层：找到候选内容（search、recommend daily/fm/heartbeat）
• 用户画像层：理解用户偏好，个性化决策（user favorite、user history、user listen-ranking）
• 执行层：实际播放控制（play、pause、next、seek、volume）
• 管理层：持久化操作，帮用户整理收藏（playlist create/add/remove、song like）

另外有一个细节值得一提：所有命令默认输出 JSON，格式稳定，AI 可以直接解析，不需要额外做文本处理。

动态命令：让 CLI 保持「活」的

传统 CLI 有一个固有限制：命令是编译进代码的，新增一个功能，必须改代码、发版、等待用户升级，整条链路很长。

ncm-cli 引入了一套动态命令系统，核心思想是：把命令的定义从代码里移到服务端。

传统 CLI 的发版链路：

动态命令的更新流程：

CLI 启动时，会向服务端发送一次同步请求，告知「我本地已经缓存了哪些命令的哪个版本」。服务端只返回有变化的部分，CLI 用这些增量数据在本地重建命令树。

效果是：业务团队可以独立地添加、修改、下线命令，用户不需要升级客户端，下次启动就能用到新功能。CLI 从一个静态工具变成了一个持续生长的命令执行引擎。

播放形态

播放后端支持两种：

• 内置播放器（mpv）：跨平台，macOS/Linux/Windows 均可用。即使没有安装网易云音乐客户端，也能直接播放。

• 网易云音乐桌面客户端：这个模式带来了一种不同的体验——AI 操控的不是一个独立的播放进程，而是你已经安装的那个 App 本身。

  技术上，ncm-cli 通过 orpheus:// URL Scheme 向客户端发送指令，客户端后台常驻进程监听并响应。App 没有运行时会自动启动。

  这意味着：你对 AI 说「帮我播放林俊杰的曹操专辑」，打开的是完整的网易云音乐界面——专辑封面、歌词、音质、红心、社交……全套 App 体验，只是控制方式从点击变成了自然语言。

  App 没有被取代，它获得了一个新的控制界面。

TUI 播放器是我们比较喜欢的功能之一——黑胶旋转动画、卡拉 OK 风格歌词同步、场景切换，在终端里有一种独特的仪式感。

TUI 有一个值得一说的特性：它可以和 CLI 命令同时工作。TUI 运行的时候，你仍然可以在另一个终端执行 ncm-cli next、ncm-cli volume 80，TUI 界面会实时响应。这对 AI Agent 来说格外自然——Agent 发出的命令和人在 TUI 中的操作是完全对等的。

怎么用

首先你需要安装 ncm-cli：

npm install -g @music163/ncm-cli

前往 网易云音乐开放平台 完成入驻并获取 API 凭证，然后运行配置向导：

ncm-cli configure

接下来就可以使用了。有多种使用方式：

方式一：OpenClaw

安装 OpenClaw 并连接你的飞书等 IM 软件，然后安装我们提供的 skill（github.com/NetEase/ski… ），之后你就可以从手机随时控制电脑上的音乐播放。

这种方式最适合日常使用：不需要打开终端，不需要记命令，用 IM 发送消息即可。

一个有趣的例子：你在飞书发一句「用我的红心歌单帮我生成一个照片墙」。

这个请求看起来和音乐播放没什么关系，但它展示了 Agent 模式更大的想象空间——

ncm-cli 在这里不只是播放工具，而是音乐数据的结构化接口。Agent 拿到这些数据之后，可以做任何事情——生成图片、写报告、分析偏好、发邮件，取决于你的想象力和 Agent 能调用的其他工具。

这是 CLI 作为 Agent 工具的核心价值：一个专注、稳定的数据和控制接口，Agent 决定怎么用它。

方式二：Claude Code Skills

npx skills add https://github.com/NetEase/skills

安装后，直接在 Claude Code 对话：

> 帮我推荐几首适合专注的纯音乐
> 播放我最近听的歌曲
> 下一首
> 把这首歌加到红心

方式三：直接 CLI

npm install -g @music163/ncm-cli
ncm-cli configure  # 配置凭证
ncm-cli login      # 扫码登录
ncm-cli tui        # 启动 TUI 播放器
...

欢迎反馈

做这件事的初衷很简单：「合适的」音乐应该更容易「被找到」，而不是每次都要在推荐算法和自己的犹豫之间拉锯。AI Agent 提供了一个新的可能性——用自然语言表达当下的状态，让 AI 替你做决策。

ncm-cli 是我们探索这个方向的一个起点，还有很多没做好的地方。

几个问题想听听大家的想法：

• 你日常听歌的「痛点」是什么？是找歌难，还是管理歌单烦，还是别的？
• 如果 AI 能更主动地介入你的听歌体验（比如感知你的状态、主动推荐），你希望它怎么做，又不希望它怎么做？
• 如果你有技术背景，有没有想贡献的方向？

欢迎在评论区聊，也欢迎到 GitHub 提 issue。