Do you need to file a feature request?
Feature Request Description
背景
我们基于 DeepTutor 构建一个独立移动端 APP(Vue3 + Capacitor),让孩子通过手机/平板连接服务器上的 DT 进行辅导对话。APP 需要与指定的 TutorBot 进行长时间持续多轮对话。
当前问题
execute-stream API(POST /api/v1/plugins/capabilities/chat/execute-stream)存在以下限制:
- 协议不含
bot_id 字段——无法指定用哪个 TutorBot 回复
- 协议不含
session_id 字段——实测带回 session_id 后 DT 不认,每次请求独立处理
- 不写 History——与 QQ Bot channel 不同,execute-stream 通道不会自动写入对话历史
导致结果:每轮对话都是"新对话",上下文丢失。
Related Module
API/Backend
Use Case
期望的支持方式(三选一即可)
方案 A:扩展 execute-stream 协议(推荐)
在现有 execute-stream 请求体中增加两个字段,DT 内部处理多轮上下文:
{
"content": "用户消息",
"capability": "chat",
"bot_id": "app-testing",
"session_id": "上一轮返回的 session_id(首轮不传)",
"enabledTools": [],
"knowledgeBases": [],
"language": "zh",
"llmSelection": {
"profile_id": "llm-profile-xxx",
"model_id": "llm-model-xxx"
}
}
行为:
- 首轮不传
session_id,DT 创建新 session 并返回
- 后续轮次传
session_id,DT 从 History 中加载上下文
- 对话历史写入 DT 的 History(与 QQ Bot channel 行为一致)
方案 B:开放 bot-level Session API
新增 RESTful session 管理端点:
POST /api/v1/tutorbot/{bot_id}/sessions 创建会话
GET /api/v1/tutorbot/{bot_id}/sessions 列出会话
GET /api/v1/tutorbot/{bot_id}/sessions/{id} 获取会话历史
DELETE /api/v1/tutorbot/{bot_id}/sessions/{id} 删除会话
execute-stream 增加 session_id 参数,指向上述创建的 session。
方案 C:开放 History API(退一步方案)
如果上述两种改动较大,退一步:开放 History 读写接口,让外部 Gateway 自行管理上下文:
GET /api/v1/tutorbot/{bot_id}/history?session_id=xxx 读取历史
POST /api/v1/tutorbot/{bot_id}/history 写入消息
DELETE /api/v1/tutorbot/{bot_id}/history?session_id=xxx 清除历史
Additional Context
我们需要的最小能力
核心就一条:通过 HTTP API 与指定 bot 进行有上下文的多轮对话。
如果上述方案都无法支持,我们将自行实现一个轻量 Gateway(消息存档 + 上下文拼接 + SSE 透传),但这种方式是 workaround,会增加延迟和复杂度。
环境
- DeepTutor 版本:v1.4.0
- 部署方式:Docker (ghcr.io/hkuds/deeptutor:latest)
- LLM:本地 llama.cpp
联系方式
Perter Tian 12267933@qq.com 或者bitter_tian2001@163.com
如有需要可进一步讨论技术细节。
Do you need to file a feature request?
Feature Request Description
背景
我们基于 DeepTutor 构建一个独立移动端 APP(Vue3 + Capacitor),让孩子通过手机/平板连接服务器上的 DT 进行辅导对话。APP 需要与指定的 TutorBot 进行长时间持续多轮对话。
当前问题
execute-streamAPI(POST /api/v1/plugins/capabilities/chat/execute-stream)存在以下限制:bot_id字段——无法指定用哪个 TutorBot 回复session_id字段——实测带回session_id后 DT 不认,每次请求独立处理导致结果:每轮对话都是"新对话",上下文丢失。
Related Module
API/Backend
Use Case
期望的支持方式(三选一即可)
方案 A:扩展 execute-stream 协议(推荐)
在现有 execute-stream 请求体中增加两个字段,DT 内部处理多轮上下文:
{ "content": "用户消息", "capability": "chat", "bot_id": "app-testing", "session_id": "上一轮返回的 session_id(首轮不传)", "enabledTools": [], "knowledgeBases": [], "language": "zh", "llmSelection": { "profile_id": "llm-profile-xxx", "model_id": "llm-model-xxx" } }行为:
session_id,DT 创建新 session 并返回session_id,DT 从 History 中加载上下文方案 B:开放 bot-level Session API
新增 RESTful session 管理端点:
execute-stream 增加
session_id参数,指向上述创建的 session。方案 C:开放 History API(退一步方案)
如果上述两种改动较大,退一步:开放 History 读写接口,让外部 Gateway 自行管理上下文:
Additional Context
我们需要的最小能力
核心就一条:通过 HTTP API 与指定 bot 进行有上下文的多轮对话。
如果上述方案都无法支持,我们将自行实现一个轻量 Gateway(消息存档 + 上下文拼接 + SSE 透传),但这种方式是 workaround,会增加延迟和复杂度。
环境
联系方式
Perter Tian 12267933@qq.com 或者bitter_tian2001@163.com
如有需要可进一步讨论技术细节。