1. 为什么要把 MediaGo 的 HTTP API 接进自动化流程MediaGo 是一个带内置嗅探能力的跨平台视频下载器底层调用 yt-dlp支持超过一千个站点的解析桌面端用 Electron 打包后端是 Go同时提供 Docker 镜像和一套完整的 HTTP API。它解决的问题很具体以前下载网页视频要先开 F12 找 m3u8或者装浏览器扩展嗅探换个站点规则就失效MediaGo 把嗅探、解析、下载、转码串成一条链路扩展点一下就把资源丢给桌面端处理。但真正让开发者在意的是它的 HTTP API。浏览器扩展本身就是通过这套 API 和桌面端通信的也就是说凡是扩展能做的事你的脚本都能做创建下载任务、查询进度、管理下载列表、触发格式转换。把 MediaGo 跑在服务器上它就从「一个软件」变成了「一个下载服务」多台设备共用同一个实例。这篇要解决的是更靠前的一步批量下载时链接来源五花八门页面结构经常变人工整理任务列表很费时间。我的做法是让 AI 帮忙做链接解析和任务编排而调用模型需要一个统一的 Key。TaoToken 提供的就是这样一个入口一个 Key 覆盖多种模型省掉在多个平台之间来回切换的麻烦。下面给出 config.toml 与 Docker Compose 的可复制骨架演示用统一 Key 接入 AI 辅助解析下载链接并附上 curl 验证请求与嗅探结果比对的动作。适合谁看需要批量下载视频素材的开发者、想把下载流程接进自己工作流的人、在服务器上部署下载服务供团队共用的运维同学。如果你只是偶尔下几个视频桌面端点一点就够了不必折腾 API。2. 前置准备TaoToken 统一 Key 与 MediaGo 服务2.1 拿到统一 KeyTaoToken 的定位是模型调用的统一入口注册后在控制台创建 API Key 即可。地址是 https://taotoken.net/api 控制台里可以管理 Key、查看用量、切换模型。创建好的 Key 形如sk-xxxxxxxx后面所有请求都用它做鉴权。需要说明的是这个 Key 只用于调用模型接口不参与 MediaGo 本身的下载鉴权。MediaGo 的 HTTP API 默认监听本地端口没有额外的 token 机制所以部署时要注意网络暴露范围别把 8899 直接开到公网。2.2 部署 MediaGo官方镜像在 Docker Hub 和 GHCR 都有支持 amd64 和 arm64。最简的一条命令是docker run -d --name mediago -p 8899:8899 -v /path/to/mediago:/app/mediago caorushizi/mediago:3.5.0但实际用起来我更推荐 Docker Compose因为要挂载配置、要固定版本、要配环境变量Compose 文件写一次以后改起来清楚。下面这份骨架可以直接复制# docker-compose.yml version: 3.8 services: mediago: image: caorushizi/mediago:3.5.0 container_name: mediago restart: unless-stopped ports: - 8899:8899 volumes: - ./data:/app/mediago - ./downloads:/app/downloads environment: - TZAsia/Shanghai - MEDIAGO_PORT8899 # 下面两个变量供你自己的脚本读取MediaGo 本身不消费 - TAOTOKEN_API_BASEhttps://taotoken.net/api - TAOTOKEN_API_KEYsk-你的Key启动docker compose up -d docker compose logs -f mediago看到服务监听 8899 就说明起来了。浏览器打开http://服务器IP:8899能看到 Web UI同一局域网下的手机、平板也能直接访问。2.3 config.toml 骨架MediaGo 的配置目录挂在./data下核心配置文件是config.toml。不同版本字段名可能有差异下面这份是通用骨架按需增删# data/config.toml [server] host 0.0.0.0 port 8899 [download] # 下载文件保存目录容器内路径 save_dir /app/downloads # 同时进行的最大任务数按机器性能调 max_concurrent 3 # 单个任务重试次数 retry 2 [sniffer] # 内置嗅探开关 enabled true # 嗅探超时单位秒 timeout 15 [convert] # 内置格式转换依赖 ffmpeg enabled true # 默认输出容器格式 default_format mp4 [ai] # 这里指向统一入口供外部脚本读取 api_base https://taotoken.net/api api_key sk-你的Key model claude-sonnet注意[ai]段不是 MediaGo 官方定义的配置项而是我为了让自己写的辅助脚本有个统一读取位置而加的。如果你的版本对未知字段报错把这段挪到单独的.env文件里即可。3. 可复制配置用统一 Key 做链接解析与任务编排3.1 整体思路批量下载的痛点在「链接从哪来」。常见来源有三类一是手动收集的页面 URL 列表二是某个站点列表页里的详情链接三是别人发来的一堆分享链接。这些链接里有些是视频页有些是播放页有些直接就是 m3u8。人工判断很累。我的做法是写一个 Python 脚本把原始链接列表丢给模型让模型输出结构化的任务描述哪些是可直接下载的直链哪些需要先访问页面嗅探哪些是无效链接。模型返回 JSON脚本再按 JSON 调 MediaGo 的 HTTP API 创建任务。3.2 调用统一 Key 做解析# parse_links.py import os import json import requests API_BASE os.environ.get(TAOTOKEN_API_BASE, https://taotoken.net/api) API_KEY os.environ[TAOTOKEN_API_KEY] SYSTEM_PROMPT 你是一个视频链接解析助手。 输入是一批原始链接请对每个链接输出一个 JSON 对象字段如下 - url: 原始链接 - type: 取值 direct / page / invalid - reason: 简短说明判断依据 - suggested_name: 建议的保存文件名不含扩展名 只输出 JSON 数组不要输出其他文字。 def parse_links(raw_links): payload { model: claude-sonnet, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: \n.join(raw_links)}, ], temperature: 0, } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } resp requests.post( f{API_BASE}/v1/chat/completions, headersheaders, jsonpayload, timeout60, ) resp.raise_for_status() content resp.json()[choices][0][message][content] return json.loads(content) if __name__ __main__: links [ https://example.com/watch?vabc123, https://cdn.example.com/video/xyz.m3u8, not-a-url, ] result parse_links(links) print(json.dumps(result, ensure_asciiFalse, indent2))跑一下export TAOTOKEN_API_KEYsk-你的Key python parse_links.py返回大致是这样[ {url: https://example.com/watch?vabc123, type: page, reason: 带 watch 参数的详情页需嗅探, suggested_name: abc123}, {url: https://cdn.example.com/video/xyz.m3u8, type: direct, reason: m3u8 直链, suggested_name: xyz}, {url: not-a-url, type: invalid, reason: 不是合法 URL, suggested_name: } ]拿到这个结果脚本就能分流direct直接建任务page先交给 MediaGo 嗅探invalid丢掉。3.3 调 MediaGo HTTP API 建任务MediaGo 的 API 路径以实际版本为准下面用通用形式演示。核心是 POST 一个任务对象# create_task.py import requests MEDIAGO_BASE http://127.0.0.1:8899 def create_download(url, nameNone): payload { url: url, name: name or , type: auto, } resp requests.post(f{MEDIAGO_BASE}/api/tasks, jsonpayload, timeout30) resp.raise_for_status() return resp.json() def list_tasks(): resp requests.get(f{MEDIAGO_BASE}/api/tasks, timeout30) resp.raise_for_status() return resp.json() if __name__ __main__: print(create_download(https://cdn.example.com/video/xyz.m3u8, xyz)) print(list_tasks())把 3.2 和 3.3 串起来就是一个完整的「AI 解析 → 建任务」流水线。你可以把原始链接列表放在一个 txt 里脚本读进来批量处理。4. 验证请求与嗅探结果比对4.1 curl 验证模型接口先用 curl 确认统一 Key 能通curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: claude-sonnet, messages: [{role: user, content: 只回复两个字通了}], temperature: 0 }返回里choices[0].message.content是「通了」说明 Key 和网络都没问题。如果返回 401检查 Key 有没有多余空格返回 404检查路径是不是/v1/chat/completions。4.2 curl 验证 MediaGo 服务# 健康检查看服务是否活着 curl -s http://127.0.0.1:8899/api/health # 建一个测试任务 curl -s -X POST http://127.0.0.1:8899/api/tasks \ -H Content-Type: application/json \ -d {url:https://cdn.example.com/video/xyz.m3u8,name:test,type:auto} # 查任务列表 curl -s http://127.0.0.1:8899/api/tasks4.3 嗅探结果比对这一步是重点。MediaGo 的嗅探能力在 Web UI 里能直观看到打开一个视频页扩展图标上会显示检测到的资源数量。API 侧对应的动作是提交页面 URL 后查询嗅探结果。比对方法拿同一个页面一次走 Web UI 手动嗅探一次走 API 提交看两边拿到的资源列表是否一致。如果 API 返回的资源比 UI 少通常是嗅探超时太短把config.toml里的timeout从 15 调到 30 再试。如果 API 完全没结果检查提交的 URL 是不是详情页而不是播放页有些站点的资源只在播放器初始化后才加载。# 提交页面 URL 触发嗅探 curl -s -X POST http://127.0.0.1:8899/api/sniff \ -H Content-Type: application/json \ -d {url:https://example.com/watch?vabc123} # 查询嗅探结果 curl -s http://127.0.0.1:8899/api/sniff/result?urlhttps://example.com/watch?vabc123提示不同版本的 MediaGo 嗅探接口路径可能不同以你部署版本的文档为准。上面是通用形式实际字段名对照 Web UI 的 Network 面板抓一下最准。5. 本篇常见错排查5.1 容器起来了但 Web UI 打不开先看端口映射。docker compose ps确认 8899 映射成功然后curl http://127.0.0.1:8899/api/health在服务器本机测。本机能通、外部不通多半是防火墙或安全组没放行。别急着把端口开到公网MediaGo 的 API 没有鉴权暴露出去等于把下载服务送人。5.2 模型返回的不是合法 JSON模型偶尔会在 JSON 外面包一层 json 代码块或者加一句「好的以下是结果」。处理办法是在脚本里做一次清洗找到第一个[和最后一个]截取中间部分再json.loads。另外把temperature设成 0能显著降低格式漂移。5.3 下载任务创建成功但文件没出现检查save_dir指向的路径在容器内是否存在以及宿主机挂载目录有没有写权限。docker compose exec mediago ls -la /app/downloads看一眼。如果目录是空的说明任务建了但没真正开始查任务状态是不是卡在 pending通常是并发数满了调大max_concurrent。5.4 嗅探拿到的链接下载 403有些站点的资源链接带时效签名嗅探出来的时候有效过几分钟就失效。解决办法是嗅探到之后立刻建任务别攒着批量处理。如果必须攒就在建任务前重新嗅探一次。5.5 格式转换报 ffmpeg 找不到MediaGo 内置转换依赖 ffmpeg官方镜像里一般已经带了。如果你用的是自己构建的镜像确认 ffmpeg 在 PATH 里。docker compose exec mediago which ffmpeg验证一下。6. 把下载服务接进你的工作流到这一步你手上应该有一个跑在 Docker 里的 MediaGo 实例一个能调模型的统一 Key以及一套「AI 解析链接 → 建下载任务 → 比对嗅探结果」的脚本骨架。这套东西的价值在于可复用链接来源变了改的是提示词下载目标变了改的是 API 参数模型换了Key 不用换。如果你主要做的是长期编码和 Agent 类任务需要更稳定的调用配额和更细的用量管理可以了解一下 Coding Plan地址是 https://taotoken.net/coding-plan 。如果只是想先验证模型对话通不通直接去模型对话页面试一句就行https://taotoken.net/chat 。Key 的管理和创建在控制台https://taotoken.net/console 接口文档在 https://taotoken.net/doc 需要新建 Key 的话走 https://taotoken.net/api-keys 。最后留一个我踩过的坑MediaGo 的 API 路径在不同小版本之间改过升级镜像前先把当前版本的接口抓一遍存下来别直接docker compose pull就上不然脚本半夜挂了你都不知道。 MediaGo 内置嗅探 + TaoToken 统一 Key：跨平台视频下载器的 HTTP API 配置骨架
1. 为什么要把 MediaGo 的 HTTP API 接进自动化流程MediaGo 是一个带内置嗅探能力的跨平台视频下载器底层调用 yt-dlp支持超过一千个站点的解析桌面端用 Electron 打包后端是 Go同时提供 Docker 镜像和一套完整的 HTTP API。它解决的问题很具体以前下载网页视频要先开 F12 找 m3u8或者装浏览器扩展嗅探换个站点规则就失效MediaGo 把嗅探、解析、下载、转码串成一条链路扩展点一下就把资源丢给桌面端处理。但真正让开发者在意的是它的 HTTP API。浏览器扩展本身就是通过这套 API 和桌面端通信的也就是说凡是扩展能做的事你的脚本都能做创建下载任务、查询进度、管理下载列表、触发格式转换。把 MediaGo 跑在服务器上它就从「一个软件」变成了「一个下载服务」多台设备共用同一个实例。这篇要解决的是更靠前的一步批量下载时链接来源五花八门页面结构经常变人工整理任务列表很费时间。我的做法是让 AI 帮忙做链接解析和任务编排而调用模型需要一个统一的 Key。TaoToken 提供的就是这样一个入口一个 Key 覆盖多种模型省掉在多个平台之间来回切换的麻烦。下面给出 config.toml 与 Docker Compose 的可复制骨架演示用统一 Key 接入 AI 辅助解析下载链接并附上 curl 验证请求与嗅探结果比对的动作。适合谁看需要批量下载视频素材的开发者、想把下载流程接进自己工作流的人、在服务器上部署下载服务供团队共用的运维同学。如果你只是偶尔下几个视频桌面端点一点就够了不必折腾 API。2. 前置准备TaoToken 统一 Key 与 MediaGo 服务2.1 拿到统一 KeyTaoToken 的定位是模型调用的统一入口注册后在控制台创建 API Key 即可。地址是 https://taotoken.net/api 控制台里可以管理 Key、查看用量、切换模型。创建好的 Key 形如sk-xxxxxxxx后面所有请求都用它做鉴权。需要说明的是这个 Key 只用于调用模型接口不参与 MediaGo 本身的下载鉴权。MediaGo 的 HTTP API 默认监听本地端口没有额外的 token 机制所以部署时要注意网络暴露范围别把 8899 直接开到公网。2.2 部署 MediaGo官方镜像在 Docker Hub 和 GHCR 都有支持 amd64 和 arm64。最简的一条命令是docker run -d --name mediago -p 8899:8899 -v /path/to/mediago:/app/mediago caorushizi/mediago:3.5.0但实际用起来我更推荐 Docker Compose因为要挂载配置、要固定版本、要配环境变量Compose 文件写一次以后改起来清楚。下面这份骨架可以直接复制# docker-compose.yml version: 3.8 services: mediago: image: caorushizi/mediago:3.5.0 container_name: mediago restart: unless-stopped ports: - 8899:8899 volumes: - ./data:/app/mediago - ./downloads:/app/downloads environment: - TZAsia/Shanghai - MEDIAGO_PORT8899 # 下面两个变量供你自己的脚本读取MediaGo 本身不消费 - TAOTOKEN_API_BASEhttps://taotoken.net/api - TAOTOKEN_API_KEYsk-你的Key启动docker compose up -d docker compose logs -f mediago看到服务监听 8899 就说明起来了。浏览器打开http://服务器IP:8899能看到 Web UI同一局域网下的手机、平板也能直接访问。2.3 config.toml 骨架MediaGo 的配置目录挂在./data下核心配置文件是config.toml。不同版本字段名可能有差异下面这份是通用骨架按需增删# data/config.toml [server] host 0.0.0.0 port 8899 [download] # 下载文件保存目录容器内路径 save_dir /app/downloads # 同时进行的最大任务数按机器性能调 max_concurrent 3 # 单个任务重试次数 retry 2 [sniffer] # 内置嗅探开关 enabled true # 嗅探超时单位秒 timeout 15 [convert] # 内置格式转换依赖 ffmpeg enabled true # 默认输出容器格式 default_format mp4 [ai] # 这里指向统一入口供外部脚本读取 api_base https://taotoken.net/api api_key sk-你的Key model claude-sonnet注意[ai]段不是 MediaGo 官方定义的配置项而是我为了让自己写的辅助脚本有个统一读取位置而加的。如果你的版本对未知字段报错把这段挪到单独的.env文件里即可。3. 可复制配置用统一 Key 做链接解析与任务编排3.1 整体思路批量下载的痛点在「链接从哪来」。常见来源有三类一是手动收集的页面 URL 列表二是某个站点列表页里的详情链接三是别人发来的一堆分享链接。这些链接里有些是视频页有些是播放页有些直接就是 m3u8。人工判断很累。我的做法是写一个 Python 脚本把原始链接列表丢给模型让模型输出结构化的任务描述哪些是可直接下载的直链哪些需要先访问页面嗅探哪些是无效链接。模型返回 JSON脚本再按 JSON 调 MediaGo 的 HTTP API 创建任务。3.2 调用统一 Key 做解析# parse_links.py import os import json import requests API_BASE os.environ.get(TAOTOKEN_API_BASE, https://taotoken.net/api) API_KEY os.environ[TAOTOKEN_API_KEY] SYSTEM_PROMPT 你是一个视频链接解析助手。 输入是一批原始链接请对每个链接输出一个 JSON 对象字段如下 - url: 原始链接 - type: 取值 direct / page / invalid - reason: 简短说明判断依据 - suggested_name: 建议的保存文件名不含扩展名 只输出 JSON 数组不要输出其他文字。 def parse_links(raw_links): payload { model: claude-sonnet, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: \n.join(raw_links)}, ], temperature: 0, } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } resp requests.post( f{API_BASE}/v1/chat/completions, headersheaders, jsonpayload, timeout60, ) resp.raise_for_status() content resp.json()[choices][0][message][content] return json.loads(content) if __name__ __main__: links [ https://example.com/watch?vabc123, https://cdn.example.com/video/xyz.m3u8, not-a-url, ] result parse_links(links) print(json.dumps(result, ensure_asciiFalse, indent2))跑一下export TAOTOKEN_API_KEYsk-你的Key python parse_links.py返回大致是这样[ {url: https://example.com/watch?vabc123, type: page, reason: 带 watch 参数的详情页需嗅探, suggested_name: abc123}, {url: https://cdn.example.com/video/xyz.m3u8, type: direct, reason: m3u8 直链, suggested_name: xyz}, {url: not-a-url, type: invalid, reason: 不是合法 URL, suggested_name: } ]拿到这个结果脚本就能分流direct直接建任务page先交给 MediaGo 嗅探invalid丢掉。3.3 调 MediaGo HTTP API 建任务MediaGo 的 API 路径以实际版本为准下面用通用形式演示。核心是 POST 一个任务对象# create_task.py import requests MEDIAGO_BASE http://127.0.0.1:8899 def create_download(url, nameNone): payload { url: url, name: name or , type: auto, } resp requests.post(f{MEDIAGO_BASE}/api/tasks, jsonpayload, timeout30) resp.raise_for_status() return resp.json() def list_tasks(): resp requests.get(f{MEDIAGO_BASE}/api/tasks, timeout30) resp.raise_for_status() return resp.json() if __name__ __main__: print(create_download(https://cdn.example.com/video/xyz.m3u8, xyz)) print(list_tasks())把 3.2 和 3.3 串起来就是一个完整的「AI 解析 → 建任务」流水线。你可以把原始链接列表放在一个 txt 里脚本读进来批量处理。4. 验证请求与嗅探结果比对4.1 curl 验证模型接口先用 curl 确认统一 Key 能通curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: claude-sonnet, messages: [{role: user, content: 只回复两个字通了}], temperature: 0 }返回里choices[0].message.content是「通了」说明 Key 和网络都没问题。如果返回 401检查 Key 有没有多余空格返回 404检查路径是不是/v1/chat/completions。4.2 curl 验证 MediaGo 服务# 健康检查看服务是否活着 curl -s http://127.0.0.1:8899/api/health # 建一个测试任务 curl -s -X POST http://127.0.0.1:8899/api/tasks \ -H Content-Type: application/json \ -d {url:https://cdn.example.com/video/xyz.m3u8,name:test,type:auto} # 查任务列表 curl -s http://127.0.0.1:8899/api/tasks4.3 嗅探结果比对这一步是重点。MediaGo 的嗅探能力在 Web UI 里能直观看到打开一个视频页扩展图标上会显示检测到的资源数量。API 侧对应的动作是提交页面 URL 后查询嗅探结果。比对方法拿同一个页面一次走 Web UI 手动嗅探一次走 API 提交看两边拿到的资源列表是否一致。如果 API 返回的资源比 UI 少通常是嗅探超时太短把config.toml里的timeout从 15 调到 30 再试。如果 API 完全没结果检查提交的 URL 是不是详情页而不是播放页有些站点的资源只在播放器初始化后才加载。# 提交页面 URL 触发嗅探 curl -s -X POST http://127.0.0.1:8899/api/sniff \ -H Content-Type: application/json \ -d {url:https://example.com/watch?vabc123} # 查询嗅探结果 curl -s http://127.0.0.1:8899/api/sniff/result?urlhttps://example.com/watch?vabc123提示不同版本的 MediaGo 嗅探接口路径可能不同以你部署版本的文档为准。上面是通用形式实际字段名对照 Web UI 的 Network 面板抓一下最准。5. 本篇常见错排查5.1 容器起来了但 Web UI 打不开先看端口映射。docker compose ps确认 8899 映射成功然后curl http://127.0.0.1:8899/api/health在服务器本机测。本机能通、外部不通多半是防火墙或安全组没放行。别急着把端口开到公网MediaGo 的 API 没有鉴权暴露出去等于把下载服务送人。5.2 模型返回的不是合法 JSON模型偶尔会在 JSON 外面包一层 json 代码块或者加一句「好的以下是结果」。处理办法是在脚本里做一次清洗找到第一个[和最后一个]截取中间部分再json.loads。另外把temperature设成 0能显著降低格式漂移。5.3 下载任务创建成功但文件没出现检查save_dir指向的路径在容器内是否存在以及宿主机挂载目录有没有写权限。docker compose exec mediago ls -la /app/downloads看一眼。如果目录是空的说明任务建了但没真正开始查任务状态是不是卡在 pending通常是并发数满了调大max_concurrent。5.4 嗅探拿到的链接下载 403有些站点的资源链接带时效签名嗅探出来的时候有效过几分钟就失效。解决办法是嗅探到之后立刻建任务别攒着批量处理。如果必须攒就在建任务前重新嗅探一次。5.5 格式转换报 ffmpeg 找不到MediaGo 内置转换依赖 ffmpeg官方镜像里一般已经带了。如果你用的是自己构建的镜像确认 ffmpeg 在 PATH 里。docker compose exec mediago which ffmpeg验证一下。6. 把下载服务接进你的工作流到这一步你手上应该有一个跑在 Docker 里的 MediaGo 实例一个能调模型的统一 Key以及一套「AI 解析链接 → 建下载任务 → 比对嗅探结果」的脚本骨架。这套东西的价值在于可复用链接来源变了改的是提示词下载目标变了改的是 API 参数模型换了Key 不用换。如果你主要做的是长期编码和 Agent 类任务需要更稳定的调用配额和更细的用量管理可以了解一下 Coding Plan地址是 https://taotoken.net/coding-plan 。如果只是想先验证模型对话通不通直接去模型对话页面试一句就行https://taotoken.net/chat 。Key 的管理和创建在控制台https://taotoken.net/console 接口文档在 https://taotoken.net/doc 需要新建 Key 的话走 https://taotoken.net/api-keys 。最后留一个我踩过的坑MediaGo 的 API 路径在不同小版本之间改过升级镜像前先把当前版本的接口抓一遍存下来别直接docker compose pull就上不然脚本半夜挂了你都不知道。