鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册
站长：程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
59
14
58
精选

哔哩哔哩 MCP demo 的设计与实现

yes
yes
2025-06-12 11:46
阅读 5211
yes
2025-06-12 11:46
阅读 5211

哔哩哔哩 MCP demo 的设计与实现

好久没发贴了，最近在学习mcp，这是一个基于Model Context Protocol (MCP) 的哔哩哔哩视频demo，包含服务器端和客户端的完整实现，有想学习mcp的小伙伴可以学习体验一下这个项目。

💡 提示: 实现过程鱼皮面试鸭mcp的实现 https://www.cnblogs.com/yupi/p/18814281

📁 项目结构

▼
text
复制代码
spring/
├── mcp-bilibili-server-main/     # MCP服务器端 - 提供哔哩哔哩API封装
│   ├── src/
│   │   └── main/
│   │       ├── java/              # Java源代码
│   │       └── resources/         # 配置文件
│   ├── pom.xml                    # Maven配置
│   └── README.md                  # 服务器端文档
│
└── mcp-bilibili-client/          # MCP客户端 - AI智能管理界面
    ├── src/
    │   ├── main/
    │   │   ├── java/              # Java源代码
    │   │   └── resources/         # 配置文件和静态资源
    │   └── test/                  # 测试代码
    ├── pom.xml                    # Maven配置
    └── README.md                  # 客户端文档

🌟 核心特性

🖥️ MCP服务器端 (mcp-bilibili-server-main)

  • 基于Spring Boot 3.2.5 + JDK 21
  • Spring AI MCP Server 1.0.0 标准实现
  • STDIO通信模式 - 支持标准输入输出通信
  • 完整的哔哩哔哩API封装

🛠️ 提供的MCP工具

  1. setSessdata - 设置哔哩哔哩登录状态
  2. searchVideos - 基础视频搜索
  3. searchVideosFromWeb - 高级视频搜索（支持排序、筛选）
  4. createDownloadTask - 创建视频下载任务
  5. getDownloadStatus - 查询下载任务状态
  6. getServerStatus - 获取服务器运行状态

🤖 MCP客户端 (mcp-bilibili-client)

  • 基于Spring Boot 3.2.5 + JDK 21
  • Spring AI MCP Client 1.0.0 标准实现
  • 集成通义千问AI - 智能意图分析
  • 双模式界面 - AI聊天 + 手动控制
  • 实时步骤展示 - 完整的操作流程可视化

🎯 客户端功能

  1. AI智能助手 - 自然语言交互，自动识别用户意图
  2. 手动控制台 - 传统的API调用界面
  3. 实时状态监控 - 连接状态、工具列表、服务器状态
  4. 批量操作支持 - 搜索后自动批量下载
  5. 错误处理机制 - 环环相扣，快速失败

🚀 快速开始

📋 环境要求

  • Java 21+
  • Maven 3.6+
  • 哔哩哔哩账号 (用于获取SESSDATA)
  • 通义千问API密钥 (用于AI功能)

🔧 安装与配置

1. 下载项目

代码已发布到GitHub，大家可以自行下载（如果可以麻烦大家点点star）

▼
bash
复制代码
 https://github.com/q2260391948/bilibili-mcp

2. 配置服务器端

▼
bash
复制代码
cd mcp-bilibili-server-main
cp src/main/resources/application-example.yml src/main/resources/application.yml
# 编辑配置文件，设置必要的参数

3. 配置客户端

▼
bash
复制代码
cd ../mcp-bilibili-client
cp src/main/resources/application-example.yml src/main/resources/application.yml
# 配置通义千问API密钥和MCP服务器路径

4. 构建项目

▼
bash
复制代码
# 构建服务器端
cd mcp-bilibili-server-main
mvn clean package -DskipTests

# 构建客户端
cd ../mcp-bilibili-client
mvn clean package -DskipTests

🏃‍♂️ 运行应用

一：进入server

更新配置

a3f43e5aa8224f0f2c2de95a2f3602b.png

打包

999662cf383714e92b1d2cfb038e7fc.png

二：使用client进行调用

本地Client替换为本地的jar包路径

8a381016d42393958fa3e98c65d6217.png

启动

39de94ef66c878caf6a3e7bca24d9c5.png

三：使用外部client进行调用

配置 cursor mcp配置

▼
json
复制代码
{
  "mcpServers": {
    "bilibili-downloader": {
      "command": "C:\\Users\\Administrator\\.jdks\\ms-21.0.7\\bin\\java.exe",
      "args": [
        "-Dspring.ai.mcp.server.stdio=true",
        "-Dspring.main.web-application-type=none",
        "-Dlogging.pattern.console=",
        "-jar",
         //此处需替换为本地 Serever jar包绝对路径
        "E:\\学习\\MCP\\spring\\mcp-bilibili-server-main\\target\\bilibili-mcp-server-1.0.0-SNAPSHOT.jar"
      ],
      "env": {
        "JAVA_HOME": "C:\\Users\\Administrator\\.jdks\\ms-21.0.7"
      }
    }
  }
}

效果

绿色表示已经连接到了 MCP server，红色则表示连接失败

7e419d4e244d90929db482d7ca160fa.png 浅浅调用一下吧~

b5b78e150a23eb8082c392f362947c9.png

60798d1a477db6a8960ffb1f247c4c1.png

5b20606cc83f0453a35a9319bb078e5.png

Cherry Studio 调用

a59a2b83d6b8ff0faba6ce3abf055b0.png

bee0d41ca79803eb5ae0e98e048316b.png

🌐 访问界面

启动客户端后，可以通过以下地址访问：

  • AI智能助手: http://localhost:8090/ai-chat.html
  • 手动控制台: http://localhost:8090/index.html
  • API文档: http://localhost:8090/swagger-ui.html (如果启用)

📖 使用指南

🤖 AI智能助手使用

AI助手支持自然语言交互，以下是一些使用示例：

1. 设置登录信息

▼
text
复制代码
设置SESSDATA=XXX

2. 搜索视频

▼
text
复制代码
搜索JAVA学习的视频

cbfd1db342402885902f5bb999aa8a3.png

3. 下载(单个/批量)

▼
text
复制代码
下载JAVA学习的所有视频

单个

d6fe5f7548d7a0ace506d07c5f517bb.png

eb01ad7e6a0bdb1741bd078c97fc87f.png

批量

c83098231beb5dc581335d461037bff.png

cc15e708b56b02b8498430814dd20f1.png

4. 检查状态

▼
text
复制代码
检查系统状态

🎛️ 手动控制台使用

手动控制台提供传统的表单界面，支持：

  • 系统状态监控
  • 登录信息设置
  • 视频搜索（基础和高级）
  • 下载任务管理

🏗️ 技术架构

📊 整体架构图

▼
text
复制代码
┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│   前端界面       │    │   MCP客户端      │    │   MCP服务器     │
│ (HTML/JS/CSS)  │    │ (Spring Boot)    │    │ (Spring Boot)   │
├─────────────────┤    ├──────────────────┤    ├─────────────────┤
│ • AI聊天界面    │───▶│ • 通义千问集成   │───▶│ • 哔哩哔哩API   │
│ • 手动控制台    │    │ • MCP客户端      │    │ • 下载管理      │
│ • 实时反馈      │    │ • 意图分析       │    │ • 状态监控      │
└─────────────────┘    └──────────────────┘    └─────────────────┘
                                │                        │
                                ▼                        ▼
                       ┌──────────────────┐    ┌─────────────────┐
                       │   AI分析引擎     │    │  哔哩哔哩平台   │
                       │ (通义千问API)    │    │ (外部API服务)   │
                       └──────────────────┘    └─────────────────┘

🔧 核心组件

MCP服务器端

  • BilibiliMcpServerApplication - 主启动类
  • MCP工具实现 - 各种哔哩哔哩操作的封装
  • STDIO通信 - 标准输入输出通信协议
  • 配置管理 - Spring Boot配置体系

MCP客户端

  • BilibiliMcpClientApplication - 主启动类
  • SimpleAIService - 基于推理的意图分析
  • AIBilibiliService - 通义千问AI集成（可选）
  • BilibiliClientService - MCP客户端调用封装
  • Web界面 - AI聊天和手动控制界面

📡 通信协议

项目使用标准的MCP (Model Context Protocol) 进行通信：

▼
text
复制代码
客户端 ──STDIO──▶ 服务器
       ◀────────
  • 协议版本: MCP 1.0.0
  • 通信方式: STDIO (标准输入输出)
  • 数据格式: JSON-RPC 2.0
  • 工具调用: 同步调用模式

🛠️ 开发指南

📝 添加新的MCP工具

服务器端

  1. 在服务器端实现新的工具方法
  2. 添加对应的参数验证
  3. 更新工具列表

客户端

  1. 在BilibiliClientService中添加调用方法
  2. 在AI服务中添加意图识别
  3. 更新前端界面（如需要）

🧪 测试

单元测试

▼
bash
复制代码
# 服务器端测试
cd mcp-bilibili-server-main
mvn test

# 客户端测试
cd mcp-bilibili-client
mvn test

集成测试

▼
bash
复制代码
# 启动服务器后，运行客户端测试
mvn test -Dtest=IntegrationTest

📦 构建与部署

开发环境

▼
bash
复制代码
mvn spring-boot:run

生产环境

▼
bash
复制代码
mvn clean package
java -jar target/app.jar

Docker部署

▼
dockerfile
复制代码
FROM openjdk:21-jre-slim
COPY target/app.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

🔧 配置说明

服务器端配置 (mcp-bilibili-server-main)

▼
yaml
复制代码
spring:
  ai:
    mcp:
      server:
        stdio: true  # 启用STDIO通信
  application:
    name: bilibili-mcp-server

# 哔哩哔哩相关配置
bilibili:
  api:
    base-url: https://api.bilibili.com
    timeout: 30s
  download:
    path: ./downloads
    concurrent: 3

客户端配置 (mcp-bilibili-client)

▼
yaml
复制代码
spring:
  ai:
    dashscope:
      api-key: ${AI_API_KEY}  # 通义千问API密钥
      chat:
        options:
          model: qwen-plus
    mcp:
      client:
        enabled: true
        stdio:
          connections:
            bilibili-server:
              command: java
              args:
                - -jar
                - ../mcp-bilibili-server-main/target/bilibili-mcp-server-1.0.0-SNAPSHOT.jar

server:
  port: 8090

🔍 故障排除

常见问题

1. MCP连接失败

症状: 客户端显示"MCP客户端未连接" 解决方案:

  • 检查服务器是否正常启动
  • 确认JAR文件路径正确
  • 查看日志中的详细错误信息

2. AI调用失败

症状: AI分析返回错误 解决方案:

  • 检查通义千问API密钥是否正确
  • 确认网络连接正常
  • 查看API调用限制

3. 视频下载失败

症状: 下载任务创建失败 解决方案:

  • 确认SESSDATA已正确设置
  • 检查视频链接或BV号有效性
  • 确认磁盘空间充足

4. 权限问题

症状: 无法访问哔哩哔哩API 解决方案:

  • 检查SESSDATA是否过期
  • 确认账号状态正常
  • 检查IP是否被限制

📋 日志排查

启用调试日志

▼
yaml
复制代码
logging:
  level:
    com.demo.mcp: DEBUG
    org.springframework.ai: DEBUG
    root: INFO

关键日志位置

  • MCP通信日志: org.springframework.ai.mcp
  • 业务逻辑日志: com.demo.mcp
  • HTTP请求日志: org.springframework.web

📊 性能监控

关键指标

  • MCP连接状态: 客户端与服务器的连接健康度
  • API响应时间: 哔哩哔哩API调用延迟
  • 下载任务数量: 当前活跃的下载任务
  • 内存使用率: JVM内存占用情况

监控端点

  • 健康检查: /actuator/health
  • 指标信息: /actuator/metrics
  • MCP状态: /api/bilibili/status

🔐 安全说明

敏感信息保护

  • SESSDATA: 妥善保管，定期更换
  • API密钥: 使用环境变量，不要硬编码
  • 日志脱敏: 避免在日志中输出敏感信息

网络安全

  • HTTPS: 生产环境建议使用HTTPS
  • 防火墙: 限制不必要的端口访问
  • 认证授权: 考虑添加用户认证机制

🤝 贡献指南

提交代码

  1. Fork项目
  2. 创建特性分支
  3. 提交更改
  4. 创建Pull Request

代码规范

  • 使用Java代码规范
  • 添加必要的注释
  • 编写单元测试
  • 更新相关文档

💡 提示: 这是一个教育和学习项目，仅作为学习使用，遵守相关平台的使用条款。

Java
GitHub
开源
AI
AI编程
59
58
分享
操作
评论
相关内容
0个评论
全部评论
点击登录，快来和大家讨论吧～
表情
图片

目录

🔥 热门文章
1
手把手教你设计一个成熟的 Agent Harness
2530
2
我用 REA 逆向了付费颜色 APP，结果很意外！
570
3
离谱，DeepSeek 崩了 5 小时，大家却喊：梁圣恩情还不完？？
420
4
DeepSeek 全新模型发布，性价比最高的一集！
380
5
B 站上 DeepSeek 闹鱼灾了，我发起《大肥鱼清除计划》！
370
6
自己学习ai，直接买cursor 的套餐，还是买gpt 或者claude 的套餐?
360
7
又一个国产版 Codex 神器，也来卷办公了！
330
8
day3-如何写出一个高质量的 Skill（组内分享） 高质量 Skill 不是“一个调得很顺的巨型 Prompt”，而是一个可验证、可回归、可维护的能力包。 先定义“什么算好”，再实现“怎么做好”。评估体系先于 Skill 本身成型。 下面用“故障诊断 Markdown 转 YAML”作为例子，但方法是通用的。 --- 一、先想清楚：Skill 到底是什么 一个 Skill 至少包含四部分： 部分 作用 接口 输入什么、输出什么、边界在哪 流程 分几步做，每步的产物是什么 规则 硬约束、经验规则、失败模式 降级策略 不确定时怎么办，而不是硬编一个看似合理的结果 高质量 Skill 的共同点：职责单一、接口清晰、规则可定位、输出可验证。 反例：把几十条经验全塞进一个主 Prompt，改一条规则要重调整个 Prompt，评估时也不知道是哪条规则退化。 --- 二、核心方法：先建评估，再写 Skill 不要先写转换器再补测试。正确顺序是： 1. 定义输出契约：什么算合法、什么算合格； 2. 建金标准集：一小批人工认可“可放行”的样本； 3. 先写评估 Skill：让它在金标准集上跑出基线； 4. 再迭代生成 Skill：每次修改跑同一套评估，无退化且目标维度提升才算正向。 这就是评估驱动开发：评估是 Skill 的单元测试，金标准集是回归锚点。 --- 三、评估 Skill：三层门禁，逐层递进 前一层不过，后一层不跑。每层留可追溯证据。 第 1 层：确定性硬门禁 用解析器、Schema、校验器完成，不消耗模型成本。 · 输出可解析； · 必填字段齐全，类型/枚举合法； · 引用目标存在，无悬空引用、无不可达节点； · 关键路径至少有一条能到达预期出口。 不通过直接打回。 第 2 层：语义断言 用脚本 + 结构遍历检查“逻辑对不对”，仍然保持确定性。 通用检查项： · 覆盖率：源材料里的关键步骤、分支、条件，输出里是否都有对应？ · 完整性：每个判断节点是否都有明确出口？有没有死胡同？ · 可达性：每条路径是否都能到达预期终点？有没有无出口循环？ · 顺序与依赖：有先后依赖的操作，是否保留了顺序？有没有被拍平成无序列表？ 例子：故障诊断转换中，检查“每个判断项是否有是/否/异常出口”“每条路径是否能到根因”。 第 3 层：LLM-as-Judge 只处理解析器表达不了的维度：忠实度、完整性、可执行性。 但 Judge 会漂移，不能单独放行，必须建立在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化，换模型必须用金标准集重新校准。 通用 Judge 维度： 维度 问什么 忠实度 输出是否忠实源材料意图？有没有自行发明内容？ 完整性 关键步骤、条件、证据是否保留？隐式知识有没有被压成空话？ 收敛性 输出是否仍指向原目标，而不是发散？ 可执行性 下游不依赖源材料能否直接使用？ --- 四、金标准集：回归测试的锚点 不需要一开始就标注几百份。用已认可的样本当种子，扩到 15～30 份，覆盖失败模式而非随机抽样： · 完整正例：典型流程； · 边界/异常分支：异常路径、循环、前置失败回退； · 已知易错模式：实际踩过的坑； · 留出集：不参与调优，只用于最终验收，防过拟合。 金标准不需要完美，只需要当前标准下认可可放行。 回归指标：关键路径用 pass^k（k 次全过），稳定性用 pass@k。 --- 五、工程约束：让批量产出可重放 · 幂等：同输入 + 同 Skill 版本 + 同规则 → 输出一致，否则无法判断变好是 Skill 改了还是随机波动； · 隔离不阻断：单份失败进隔离队列，记录失败层和原因，不阻塞其余； · 版本绑定：规则、rubric、金标准集进 Git；每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”； · 抽样人工复核：Judge 临界样本 + 易错模式，人工抽检结果反过来校准 rubric。 --- 六、Skill 本身怎么写 · SKILL.md 控制篇幅，写清：输入约定、输出契约、分步流程、硬规则、降级策略； · 经验规则放 references/ 或 rules/，按失败模式分类，不要全塞进主 Prompt； · 不确定时标 needs_review: true，不要硬编看似合理的结果； · 迭代由评估报告驱动：报告告诉你哪层挂了、哪类失败模式，你改对应规则文件，而不是漫无目的调 Prompt。 --- 七、落地顺序（不要反过来） 1. 固化输出契约：Schema + 结构约束； 2. 建金标准集：从已认可的 + 最易出错的样本开始； 3. 先写评估 Skill：跑出基线报告； 4. 再迭代生成 Skill：每次修改对比逐项通过率，无退化且目标提升才算正向； 5. 批量运行 + 隔离回放：失败进队列，结束后人工抽检； 6. 评估 Skill 自身版本化：换 Judge 模型必须重新校准。 --- 八、给组员的三条硬要求 1. 不许凭感觉说“变好了”：每次修改必须附评估报告对比，逐项通过率说话。 2. 不许跳过确定性门禁直接看 Judge 分数：前两层挂了，Judge 分数没有意义。 3. 不许把规则堆进主 Prompt：规则按失败模式分文件，评估报告要能定位到具体文件。 --- 一句话收尾 生成 Skill 决定“能不能做”，评估 Skill 决定“敢不敢用”。 先让评估体系站稳，再让生成器迭代。这样交付的不是一堆“看起来还行”的产出，而是一套可证明、可回归、可交接的 Skill 质量体系。
310
9
AI 越强，被它拒绝的代价就越大 我有时候会想：AI 越来越厉害之后，有些事情，会不会反而越来越难做？ 这个想法看起来有点矛盾。AI 明明在降低门槛，让不会写代码的人做出软件，让不会画画的人生成图片，让一个人完成过去需要整支团队才能完成的工作。但今天用 Codex 的时候，AI 拒绝帮我编写 SQL 注入的请求体，而那还是我有源码、在本地跑测试的情况。那么，往后是否只会更难？ 我们假设某一天，AI 说：「这个请求违规，我不能帮助你。」到那个时候，你还有多少能力，能绕过它，把事情做完？ 这里的「违规」需要打个引号。平台的规则、模型的判断、法律的要求，以及一件事实际有没有造成伤害，彼此之间并不总是画得上等号。一个请求可能确实危险，也可能只是缺少上下文被误判，或者恰好落在某家公司的限制范围里。 无论是哪种情况，随着我们越来越依赖 AI，这句拒绝都可能变得越来越贵。 今天，一个程序员让 AI 帮忙写代码，AI 拒绝了，他大概率还有别的办法：查文档、找开源项目、问同行，或者自己写。麻烦一点，慢一点，但路还在。 可如果十年之后，大部分程序都由 AI 完成，情况就不一样了。 很多人从接触编程的第一天起，就习惯了描述需求、等待生成、运行结果、继续迭代。他们能做出相当复杂的产品，却未必经历过独立处理底层问题的训练。平时，这种能力结构完全够用，效率甚至更高。只有 AI 拒绝的时候，他们才会发现：平常被省掉的那段学习过程，恰好是此刻最需要的东西。 到那时，一次拒绝的成本，可能就从「今晚多花两个小时」，变成「先花半年学会这门技术」。 拿 SQL 注入举个稍显极端的例子：往后，连真正理解这类攻击如何发生、能够独立构造测试的人，会不会也越来越少？ 这里也包括那些有正当需求的人。一个开发者想检查自己的旧系统，一个经过授权的安全研究员想复现漏洞，假如 AI 识别到危险模式就拒绝，而使用者又只熟悉「让 AI 帮我检查」，这项原本可以独立完成的工作，就这样卡住了。 但是安全专家不会因此消失，但这类技能可能越来越集中在少数人手里。你仍然可以找专家，只是要付出更多的钱、更多的时间，以及更高的沟通成本。 类似的困境，未必只发生在网络安全领域。 你想从一个停止维护的软件里取回自己的数据，需要解析它的旧文件格式。AI 判断这涉及规避保护措施，拒绝继续。你拥有这些数据，却没有能力把它们读出来。 你买了一台设备，厂商停止提供服务。你想修改程序让它继续运转，过程中需要处理某种访问限制。AI 不愿协助，而你所掌握的维修方式，早已只剩下「把报错发给 AI」。 你想给常用的网站写一个辅助工具，减少重复操作。平台将此归入自动化限制，AI 也据此拒绝。过去会写脚本的人可以自己判断、自己处理；未来的使用者，可能连从哪里开始都不知道。 这些例子有一个共同点：当工具同时承担了「执行工作」和「传授知识」的角色，它的拒绝就不只是挡住了一次任务，也挡住了获得这种能力的机会。 更麻烦的是，这种依赖往往是我们主动选择的，而且每一步都很合理。 既然 AI 几秒钟就能做好，为什么还要花几个月学习？既然公司可以采购成熟的 AI 服务，为什么还要养一支负责基础工作的团队？既然市场上已经很少有人手写这些东西，学校为什么还要花大量时间教？ 对个人、公司和学校来说，这些选择都有现实依据。但叠加起来，整个社会保留的独立能力就可能越来越少。等到某项能力突然受到限制，我们才发现，备用方案早已在追求效率的过程中被一点点削掉了。 所以，「AI 越强，做事越便宜」可能只描述了未来的一半。 另一半是：被允许的事情越来越便宜，被拒绝的事情依然需要人工完成，却要面对更少的人才、更高的报价，以及越来越难获得的知识。两边的成本差距，会越拉越大。 有人会说，可以换一个模型，或者用本地模型。这确实是重要的选项。只要工具之间还有充分竞争，开放模型还足够可用，限制就未必能形成真正的门槛。 但备用方案也需要维护。它需要硬件、知识、软件生态，以及一群仍然理解这些系统的人。如果大多数人已经习惯了最方便的商业服务，那么「理论上还有别的办法」和「普通人实际用得起、用得明白」，之间仍然可能隔着很远。 我担心的，正是这段距离。 我不指望 AI 对任何请求都照单全收。对明显会伤害他人的行为设置限制，有充分的理由。但我们也需要关心：限制由谁定义，误判有没有申诉渠道，用户能不能换工具，以及脱离这个工具之后，还剩下多少独立行动的能力。 保留这些能力，平时看起来甚至有点低效，明明可以自动生成，还要理解原理；明明可以一键完成，还要知道手动怎么做。 但这些看似多余的知识，会在工具拒绝、失效、涨价或改变规则的那一刻，成为真正的选择权。 AI 越强，我们可能越需要留意它说「不」的那一刻。 因为那句话的分量，最终取决于：它拒绝之后，我们还能做什么。
310
10
什么是LLM
300
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
墨得问题墨得问题