talking-with · 情感聊天端

下方是脱敏后的演示版, 单文件 standalone, sandbox 内运行 — 可见 chat / gen / speak 三 tab 围绕同一张角色卡协作的形态, 以及 4 套主题切换.

模型层训出权重, 交互层把这套权重变成"用户能跟虚拟人产生情感关系的端". 这一层只有一个组件, 因为它担的是体系唯一的对外 surface — 用户不进 ComfyUI, 不写 API call, 不装本地依赖, 打开浏览器 / 把 PWA install 到桌面就能跟虚拟人聊天.

选 fork 酒馆 (SillyTavern) 是因为它本身就是为情感聊天 + 角色扮演设计的, 不是为 task / 助手设计的. 沿用角色卡 v3 spec 作为 persona 载体, 上游消费 Cognition 层 evie-agent 给出的 persona state 与 dispatch 决策, 下游让用户跟一个有连贯人格的虚拟人聊天 — 不是 chatbot 一来一回, 是情感连接 + 长程关系. 生图 (本地/远程 ComfyUI dispatch) 与语音 (faster-whisper) 都为对话场景服务, 让情感对话更立体, 而不是被当成独立的生图工具或语音助手.

虚拟人愿景的核心不是"更强的助手", 是"能让人产生情感连接的 entity". 这就要求交互层不能走"task → response"的工具范式, 必须走"角色 → 对话 → 关系"的陪伴范式. 多模态 (生图/语音) 是手段而不是目的 — 让对话更立体, 让虚拟人在用户脑中具象化, 而不是把它当多模态 ChatGPT 用.

酒馆架构提供的角色卡 v3 + 长程对话 + 情感聊天范式是当前最接近这件事的工程基底, 它本身就是为情感 + 角色扮演设计的, 不是为 task / 工具设计的. 我们 fork 它, 替换掉它的多 LLM 接入层换成自己的 Cloudflare Workers 中转 + 4 provider router, 加入 ComfyUI dispatch 让生图随对话情境自动选 ckpt, 加入 faster-whisper 让语音输入直接进对话流 — 始终把"对话 + 角色 + 情感"放在中心.

已发布并在日常使用, 是体系里少数 live 状态的组件之一. 走 vanilla JS 单文件主控的路线 — 避开框架, 把 Service Worker 兼容性放在第一位, 优先保证 install / offline / 多平台一致.

• 已落地: 基于酒馆 (SillyTavern) 架构 fork, 角色卡 v3 spec 兼容 — 这是情感聊天的基底. 16k LOC vanilla JS 单文件主控; 20+ Cloudflare Workers endpoint (LLM 中转 + 鉴权 + 图片签名); Multi-LLM router 4 providers (Claude / Ollama / OpenRouter / OpenAI-compat); ComfyUI dispatch 按对话情境自动选 ckpt 生图; faster-whisper 本地 + 远程语音转录直接进对话; 4 套主题; PWA 离线; chat / gen / speak 三 tab — 三 tab 都围绕同一张角色卡运转, 不是独立工具.
• 探索中: TTS 输出 channel 接入, 让虚拟人能"出声"回应; 与 evie-agent state machine 集成, 让情感状态跨 tab / 跨会话共享; native 包装 (PWA → Tauri / Capacitor) 评估中.
• 待解决: persona 一致性在长对话中会 drift, 角色感人格容易被冲淡; 长程情感记忆还没接 vault, 跨会话记不住关系; 情感连接质量没有度量手段, 现在只能凭感觉.

• 把 evie-agent state machine 真正接进来, 让 persona / mood / context 在 tab 间和会话间共享, 长程关系不再每次重置.
• TTS channel 落地, 完成 voice → reply → voice 的闭环, 让虚拟人能"出声"回应, 而不只是文字.
• 长程情感记忆持久化到 vault, 跨设备 + 跨会话记得住关系, 不再受单浏览器 storage 限制.
• Native 壳评估 (Tauri / Capacitor) — 先决定要不要脱离浏览器, 再决定走哪条.
• 情感连接质量度量 — 找一个比"用户满意度"更细的指标, 让"虚拟人是否在场"这件事可观察.