睿擎平台：复刻DeepSeek蓝鲸鱼桌面宠物

最近体验 DeepSeek Harness（DSH） 时，我注意到它的「蓝鲸鱼」聊天宠物。它会聊天，也会用表情回应；比起看着聊天框里的文字，我更想把它放到桌上的小屏幕里。DSH 已经能处理对话、工具调用和插件，正好可以用来做这个尝试。

我选了睿擎平台3576做板端，Windows 上的 DSH 负责对话。现在板端的工作集中在局域网连接和文字会话：配对后把问题发给 DSH，再取回回复。屏幕表情和语音还在设计中。目前项目还在持续迭代，今天先来分享一下前期的探索过程。

工程路线：睿擎平台3576做客户端，AI人设放在DSH

板端暂时只负责拿到登录凭据、发送问题、取回回复。大模型、人设、记忆和工具都放在 PC 上，板子也不用保存 API Key。以后要改它的性格，在 DSH 里调整就行。也可灵活调整不同的对话记忆则调整DSH_SESSION_ID定义即可，session ID获取

然后在板中设置：

板端与 PC 的连接

板和 PC 连到同一个局域网。板端通过 PC 的局域网 IP 访问 DSH Desktop 的局域网入口。DSH 把这个入口叫作“手机桥”，原本用于手机等设备连接桌面端；板子也可以通过它配对和发送请求。示例端口是 43127。

概念	角色
同一 WiFi 网段	板与 PC 互通；板访问 http://:43127
“手机桥”	DSH Desktop 对局域网设备开放的配对与请求入口
Harness（本机）	仅 Windows 本机 Agent 内核（如 127.0.0.1:43129），板不可直连
Pinggy 等公网隧道	跨网段访问方案；本文没有采用

调试时先从板端 ping PC，再用 curl 请求桥的地址。板端只需要配置这个局域网地址，不用填 Harness 的本机端口：

# 板与 PC 同一局域网时exportDSH_BASE_URL="http://192.168.1.20:43127" # ← 换成 PC 的 LAN IP# 探测桥是否可达（示意）curl -sS"$DSH_BASE_URL/api/status"

文字消息的往返

板端发出的请求会经过 DSH 的局域网入口，转到 PC 本机的 Harness；模型生成回复后，再沿原路返回。

图中各部分的作用是：

1. 板端与网络：板和 PC 在同一网段，板端通过 WiFi 发送请求。

2. 局域网入口（“手机桥”）：接收板端的配对和 RPC 请求，检查凭据，再转给 PC 本机的 Harness。板子不能直接访问 Harness 的本机端口。

3. Harness：在 PC 本机处理 session.create / session.prompt / session.history，并管理会话中的人设、记忆和工具。

4. 模型和工具：模型 Key、工具和记忆都在 PC 上，板端只负责发送输入、接收回复。

5. 板端显示：目前从命令行看文字回复，接上 LVGL 后再根据对话状态切换动画。

从串口或终端查看回复，能直接分辨是网络没通、配对失败，还是会话请求出了问题。

配对与 Cookie

配对时用到两个凭据：

1. 短时 pair token：Desktop「连接手机」生成，只用来证明「此刻有人在授权配对」。

2. dsh_mobilecookie：/pair 成功后由服务端下发；之后聊天只认 cookie，不再带 token。

可以把 token 理解成临时门禁条：用它换到 cookie 后，日常请求就带 cookie。/pair 负责配对，对话使用另一条 RPC 通路。

板在 WiFi 同网条件下访问桥的 /pair，把 cookie 保存在本地；后续 RPC 携带 Cookie: dsh_mobile=… 即可。

示意（token 只用于配对，聊天阶段不再出现）：

# 1) 短时 token → 换 cookie（响应头 Set-Cookie: dsh_mobile=…）curl -sS -D -"$DSH_BASE_URL/pair?token=$DSH_PAIR_TOKEN"-o /dev/null

# 2) 之后只带 cookieexportDSH_MOBILE_COOKIE="……" # 从 Set-Cookie 落入本地，勿提交仓库curl -sS -H"Cookie: dsh_mobile=$DSH_MOBILE_COOKIE"\ "$DSH_BASE_URL/api/status"

会话与回复

板侧聊天使用 DSH 开放的 RPC 方法，例如 session.create / session.prompt / session.history。请求先到局域网入口，再由它转给 PC 本机的 Harness。

板端需要处理的几个字段：

session：多轮上下文的容器；桌面 AI 人设生效也绑定在「新会话」上。

prompt：用户这一轮的输入；助手正文往往再经 history 读回。

cookie 鉴权：RPC 请求携带 dsh_mobile，证明板已配对。

板端保存会话 ID，后续提问继续使用同一个 ID，多轮对话才能接上。

具体请求的 RPC 形态大致如下（白名单方法名，不是 /v1/chat/completions）：

POST /api/rpcCookie: dsh_mobile= <已配对 cookie> Con tent-Type: application/json

{"method":"session.prompt","paylo ad":{"sessionId":"","tex

创建会话用 session.create；发出 session.prompt 后，板端通常再调用 session.history 读取助手正文。具体字段可能随 Desktop 版本变化，调试时以当前版本的接口返回为准。

当前实现效果类似这样的

人设留在 PC，形象交给屏幕

复刻「蓝鲸鱼」时，我把「它怎么说话」和「它长什么样、怎么动」拆开处理

层	落点	改的是什么
桌面 AI（对话角色）	Windows DSH / Harness	说话口吻、自称、脾气——persona / system 前缀注入
桌面宠物（形象，后续）	板端睿擎 LVGL 屏	表情、待机循环、随对话状态变化的动画

人设注入决定的是「它怎么说话」。验证时我会新建会话，再问它的身份和说话习惯，确认回复是否符合当前人设，避免把旧会话的上下文误当成设置生效。

屏幕形象需要“倾听、思考、说话、空闲”这些状态来切换动画。现在先保留状态接口，文字对话仍可独立调试。

语音部分的打算

麦克风和喇叭还没有接入。语音部分目前按下面的方式考虑：

板端主要负责采集 PCM、播放 PCM（例如通过 Linux ALSA）。ASR / 模型 / TTS 可以由 PC 侧 DSH 编排，DSH也有相关的语音插件可定制声音，也可以接云端服务；目标是沿用文字阶段的会话和人设。

规划中的信息流：采集 → 局域网 → DSH → TTS 回放

文字会话可以继续沿用；音频采集、传输和播放则需要单独处理：

1.板端采集：麦拿到 PCM（或板侧轻量端点），经 WiFi 同网送到 PC。

2. 送入 DSH：ASR 得到文本后，带上 cookie 调用 session.prompt，尽量沿用文字聊天时的会话和人设。

3. 模型回复：Harness / LLM 产出助手正文，再由 PC 侧的 TTS 转成可播放音频。

4. 板端回放：音频经局域网回到板，喇叭播出。

5.状态同步：把 listening / thinking / speaking 等状态推给 LVGL，让声音和屏幕动画跟上同一轮对话。

音频传输方式还要结合实际硬件和 DSH 插件确定。

展望

接入 DSH 声音插件

我也会看看能否直接接入DSH 声音类插件，例如语音输入、音色/TTS、打断和流式播报。具体接口还要结合插件能力验证；如果能跑通，板端就可以继续专注采集与播放。

LVGL 屏幕与表情

显示部分计划使用睿擎平台 LVGL 显示屏，用板端的 Linux UI 栈绘制形象、表情和对话气泡。

模型直接控外设

外设控制也在考虑范围内。比如 DSH 的工具返回“转头”“点亮指示灯”或“切换表情”，板端再通过 PWM、GPIO 或 LVGL 执行。具体效果等屏幕交互基本成形后再验证。

小结

本文分享的是睿擎平台3576接入 DSH 的方法，以及桌面宠物接下来的开发方向。屏幕形象、声音和外设交互还会继续做；项目整理好后会开源，后续也会更新开发进展。