resolve conflict

This commit is contained in:
2026-03-29 22:26:16 +08:00
12 changed files with 844 additions and 44 deletions

View File

@@ -11,14 +11,13 @@
"id": "9a5781991bf94030",
"type": "leaf",
"state": {
"type": "markdown",
"type": "bases",
"state": {
"file": "docs/dify/用户注册及添加成员.md",
"mode": "source",
"source": false
"file": "未命名 1.base",
"viewName": "表格"
},
"icon": "lucide-file",
"title": "用户注册及添加成员"
"icon": "lucide-table",
"title": "未命名 1"
}
},
{
@@ -27,30 +26,44 @@
"state": {
"type": "markdown",
"state": {
"file": "docs/Obsidian笔记体系/Projects/aitsc/ai提示词常用命令.md",
"file": "docs/Obsidian笔记体系/Daily/2026-01-13.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "ai提示词常用命令"
"title": "2026-01-13"
}
},
{
"id": "efa2dc303e8e694d",
"id": "59894255df52f532",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "docs/cursor/cursor.md",
"file": "docs/Obsidian笔记体系/Projects/知你-调测/知你--调测.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "cursor"
"title": "知你--调测"
}
},
{
"id": "c40cc65d2419fc22",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "docs/学习笔记/Android WindowManagerService (WMS) 架构深度解析(第一次提示词).md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "Android WindowManagerService (WMS) 架构深度解析(第一次提示词)"
}
}
],
"currentTab": 2
"currentTab": 3
}
],
"direction": "vertical"
@@ -82,7 +95,7 @@
"state": {
"type": "search",
"state": {
"query": "计算云",
"query": "path:\"docs/Obsidian笔记体系/Config/\" ",
"matchingCase": false,
"explainSearch": false,
"collapseAll": false,
@@ -107,7 +120,7 @@
}
],
"direction": "horizontal",
"width": 300
"width": 457.5
},
"right": {
"id": "1e41a867da6b7f39",
@@ -203,46 +216,47 @@
},
"left-ribbon": {
"hiddenItems": {
"bases:新建数据库": false,
"switcher:打开快速切换": false,
"graph:查看关系图谱": false,
"canvas:新建白板": false,
"daily-notes:打开/创建今天的日记": false,
"templates:插入模板": false,
"command-palette:打开命令面板": false,
"bases:新建数据库": false
"command-palette:打开命令面板": false
}
},
"active": "efa2dc303e8e694d",
"active": "c40cc65d2419fc22",
"lastOpenFiles": [
"docs/cursor/cursor使用技巧.md",
"docs/学习笔记/php/云服务器龙虾.md",
"docs/学习笔记/龙虾能力.md",
"docs/Obsidian笔记体系/Projects/aitsc/ai提示词常用命令.md",
"docs/学习笔记/龙虾配置.md",
"docs/学习笔记/腾讯云相关账户.md",
"docs/学习笔记/腾讯云龙虾.md",
"docs/学习笔记/php/php学习目录.md",
"docs/cursor/cursor.md",
"docs/学习笔记/Android整机性能分析与问题定位实战指南.md",
"未命名 1.base",
"docs/Obsidian笔记体系/Projects/提示词大师/提示词大师.md",
"docs/Obsidian笔记体系/Projects/提示词大师",
"docs/学习笔记/Android WindowManagerService (WMS) 架构深度解析(第一次提示词).md",
"docs/学习笔记/Android WindowManagerService核心原理深度解析专家第二次提示词.md",
"docs/学习笔记/两份提示词对比.md",
"docs/学习笔记/前端学习.md",
"docs/学习笔记/效率提升.md",
"docs/学习笔记/Android性能分析标准化操作手册.md",
"docs/Obsidian笔记体系/Daily/2026-01-13.md",
"docs/学习笔记/Android游戏整机性能卡顿与丢帧根因分析与优化指南.md",
"docs/# Android WindowManagerService (WMS) 架构深度解析(专家第一次提示词).md",
"docs/Obsidian笔记体系/Projects/知你-调测/知你--调测.md",
"docs/学习笔记/Android整机性能分析与问题定位实战指南.md",
"docs/学习笔记/DevOps学习.md",
"docs/cursor/cursor使用技巧.md",
"docs/Obsidian/高频命令.md",
"docs/cursor/cursor.md",
"docs/Obsidian笔记体系/Projects/聊天平台/测试用例.md",
"docs/Obsidian笔记体系/Projects/聊天平台/知你客服 6 号(检索增强记忆).md",
"docs/Obsidian笔记体系/Projects/聊天平台/聊天模型记忆解解方案.md",
"docs/Obsidian笔记体系/Projects/聊天平台/未命名.md",
"docs/Obsidian笔记体系/Projects/聊天平台/知你客服5号的设计.md",
"docs/Obsidian笔记体系/Projects/聊天平台/agent智能体性能调测.md",
"docs/Obsidian笔记体系/Projects/聊天平台/接入方式.md",
"docs/Obsidian笔记体系/Projects/聊天平台/聊天平台.md",
"docs/adb调试命令/adb常用命令.md",
"docs/Obsidian笔记体系/Projects/聊天平台/app.md",
"docs/Obsidian笔记体系/Projects/聊天平台/数据库配置.md",
"docs/Obsidian笔记体系/Projects/saars开发/数据库配置.md",
"docs/Obsidian笔记体系/Projects/saars开发/aiapply/智能配置助手功能已完成.md",
"docs/Obsidian笔记体系/Projects/saars开发/aiapply/聊天智能机器人(苏苏).md",
"docs/Obsidian笔记体系/Projects/saars开发/aiapply/电商系统用户订单处理流程设计方案.md",
"docs/Obsidian笔记体系/Projects/saars开发/aiapply/个人简历.md",
"docs/Obsidian笔记体系/Projects/saars开发/aiapply/# 创建Agent经验总结.md",
"docs/Obsidian笔记体系/Projects/aitsc/ai提示词常用命令.md",
"docs/Obsidian笔记体系/Projects/聊天平台",
"docs/Obsidian笔记体系/Projects/aitsc",
"docs/Obsidian笔记体系/Daily/2026-01-14.md",
"docs/Obsidian笔记体系/Daily/2024-06-02.md",
"docs/Obsidian笔记体系/Daily/2026-01-15.md",
"docs/Obsidian笔记体系/Daily/2026-01-20.md",
"docs/学习笔记/高级性能问题分析.md",
"未命名 1.base",
"docs/Obsidian笔记体系/Projects/提示词大师",
"docs/学习笔记/产品经理",
"Pasted image 20260129111501.png",
"Pasted image 20260129111451.png",
@@ -258,7 +272,6 @@
"docs/Obsidian笔记体系/Projects/女童生长激素项目",
"docs/学习笔记/php",
"docs/cursor/php",
"com.xiaomi.appstore.appclaim.signature.verification.apk",
"docs/android面试/系统原理/DPMS常见面试题"
"com.xiaomi.appstore.appclaim.signature.verification.apk"
]
}

View File

@@ -0,0 +1,13 @@
编写脚本:向知你客服发送测试消息、拉取执行性能数据并生成分析报告。
完整节点耗时表与上述优化说明已写入 知你客服-节点耗时分析与优化方案.md可直接打开查看脚本在 backend/scripts/test_agent_and_analyze_performance.py需要时可再次运行以复测或对比优化前后耗时。
下一步:
若需要和之前完全一致的对外格式,可在 SAARS 或 8037 的 end 后增加一层轻量转换只做字段映射不再调 LLM

View File

@@ -0,0 +1 @@
你可以直接说:要“先能登录+看会话+发一条消息”即可,我就按这个范围写;若要加上 Room 离线、Socket.IO、FCM也可以一起排进去。

View File

@@ -0,0 +1,319 @@
# 知你客服 Agent 智能聊天 App 接入方案
## 一、结论
**可以接入。**「知你客服」是平台上的已发布聊天智能体,支持记忆管理、意图识别与多轮对话,通过平台提供的 **执行 API** 即可在智能聊天 App 中调用,由 App 后端或前端携带平台用户 Token 调用即可。
---
## 二、接入方式概览
| 方式 | 适用场景 | 说明 |
|------|----------|------|
| **方式一App 后端代理** | 推荐,移动端/多端 App | App 后端用平台账号拿 Token代用户调执行 API再把结果返回给 App |
| **方式二:前端直连** | Web 版聊天、用户已在平台登录 | 前端拿到平台 Token 后直接调执行 API同域名或配置 CORS |
| **方式三:内嵌平台对话页** | 快速上线 | 用 iframe 或 H5 打开平台「使用」页的对话界面,无需对接 API |
---
## 三、方式一App 后端代理(推荐)
### 3.1 流程
1. 在平台为「对接用」创建一个账号(如 `app-service@yourcompany.com`),并登录拿到 **access_token**
2. 在平台 **Agent 管理** 中打开「知你客服」,复制其 **Agent ID**(或通过「获取 Agent 列表」接口查到)。
3. App 用户发消息时App 后端:
   - 用上述 token 调「创建执行」接口,传入 `agent_id``input_data`(见下)。
   - 轮询「执行状态」或「执行详情」,直到 `status``completed`
   -`output_data` 中取出回复内容返回给 App 用户。
### 3.2 接口说明(与知你客服约定)
- **Base URL**`http(s)://你的平台域名:8037`(如 `http://101.43.95.130:8037`
**1登录拿 Token**
```http
POST /api/v1/auth/login
Content-Type: application/x-www-form-urlencoded
username=app-service&password=xxx
```
响应示例:
```json
{ "access_token": "eyJ...", "token_type": "bearer" }
```
**2创建执行发用户消息给知你客服**
```http
POST /api/v1/executions
Authorization: Bearer <access_token>
Content-Type: application/json
{
  "agent_id": "Agent ID",
  "input_data": {
    "query": "",
    "user_id": "appID"
  }
}
```
- `query`:必填,用户本轮输入。
- `user_id`建议传。知你客服工作流里用「缓存」做记忆时key 一般为 `user_memory_{user_id}`,传了才能按用户隔离多轮记忆。
响应示例:
```json
{
  "id": "execution_uuid",
  "agent_id": "...",
  "status": "pending",
  "task_id": "celery_task_id",
  "created_at": "2026-01-22T..."
}
```
**3轮询执行结果**
```http
GET /api/v1/executions/{execution_id}/status
Authorization: Bearer <access_token>
```
返回中有 `status``pending` / `running` / `completed` / `failed`。为 `completed` 后再取详情。
```http
GET /api/v1/executions/{execution_id}
Authorization: Bearer <access_token>
```
响应中的 `output_data` 即为工作流输出,其中会包含客服回复内容(具体字段以知你客服工作流 End 节点输出为准,常见为 `reply``content``output` 等)。
### 3.3 App 后端实现要点
- Token 管理:登录一次,将 `access_token` 缓存在服务端(注意过期时间,过期前重新登录或使用 refresh 若平台支持)。
- 每个 App 用户建议固定一个 `user_id`(如 open_id、user_uuid保证多轮对话记忆正确。
- 轮询间隔建议 0.51 秒,最多轮询约 3060 秒,超时可按「请求超时」处理。
---
## 四、方式二:前端直连
适用于「用户已在低代码平台登录」的 Web 聊天场景:
1. 前端从平台登录接口拿到 `access_token`
2. 用户发消息时,前端直接:
   - `POST /api/v1/executions`body 同上(`agent_id` + `input_data`)。
   - 轮询 `GET /api/v1/executions/{id}/status``GET /api/v1/executions/{id}`
3.`output_data` 中的回复展示在聊天界面。
注意:需保证前端请求能带 Cookie/Header 到 8037 端口,且平台 CORS 已放行该前端域名(当前配置见 `docker-compose.dev.yml``CORS_ORIGINS`)。
---
## 五、方式三:内嵌平台对话页
- 在 Agent 管理中对「知你客服」点击 **「使用」**,会打开平台自带的对话页。
- 在智能聊天 App 内用 **WebView / iframe** 打开该对话页 URL即可在 App 内使用知你客服,无需对接执行 API。
- 优点:零开发量;缺点:界面与账号体系受平台限制,且无法深度定制 UI 与用户标识(多端统一记忆需平台支持「使用」页传 user_id 等参数,若当前不支持可向平台侧确认是否可扩展)。
---
## 六、知你客服输入输出约定(建议在平台上确认)
- **输入**`input_data`
  - `query`(必填):用户当前轮次文本。
  - `user_id`建议App 侧用户唯一 ID用于记忆 key。
- **输出**`output_data`
  - 以实际工作流 End 节点输出为准,可在平台「执行历史」中跑一轮对话,查看该执行详情中的 `output_data` 结构,再在 App 中解析展示。
---
## 七、获取 Agent ID
- 方式 A在 Agent 管理列表中,用浏览器开发者工具查看「知你客服」对应行的接口或 DOM可看到 `id`
- 方式 B调用平台接口需登录
```http
GET /api/v1/agents?search=
Authorization: Bearer <access_token>
```
在返回列表中找到名称为「知你客服」的项,取其 `id` 作为上述 `agent_id`
---
## 八、小结
| 项目 | 说明 |
|------|------|
| 是否可接入 | 可以,通过执行 API 或内嵌「使用」页 |
| 推荐方式 | 智能聊天 App 用 **App 后端代理**(方式一) |
| 认证 | 使用平台账号登录得到的 Bearer Token |
| 多轮记忆 | 在 `input_data` 中传稳定 `user_id` |
| 文档与调试 | 可访问 `http(s)://域名:8037/docs` 查看并调试执行、状态、详情等接口 |
若后续需要「无登录、仅用 API Key 调用知你客服」,需在平台侧为 Agent 增加 API Key 鉴权接口,再在 App 后端用 Key 替代 Token 调用即可;当前版本按上述 Token 方式即可完成接入。

View File

@@ -0,0 +1,3 @@
# 数据库配置 - 腾讯云数据库
DATABASE_URL=mysql+pymysql://root:!Rjb12191@gz-cynosdbmysql-grp-d26pzce5.sql.tencentcdb.com:24936/liaotian_db?charset=utf8mb4

View File

@@ -0,0 +1,57 @@
## 一、在 8037 平台里优化(编辑 / 设计)
你截图里的「知你客服」有 记忆管理缓存节点  意图识别LLM 节点),这两块对延迟影响最大。
### 1. 意图识别 / LLM 节点(优先做)
- 换更快或更小的模型
在「编辑」或「设计」里找到意图识别的 LLM 节点,看能否切换模型(例如从大模型改为小一号或“快速”模型),优先保证意图识别快。
- 降低生成长度
若有 max_tokens / 最大生成长度,适当调小,能明显缩短首字返回时间和总耗时。
- 按需调 temperature
若当前偏高且不要求创意,可略降低,有时能减少采样时间。
### 2. 记忆管理 / 缓存节点
- 在「设计」里看缓存节点的配置:容量、过期时间、查询条件。
- 避免过大或过长的历史被每次都查一遍;能缩短「最近 N 轮」或「只查当前会话」会更好。
- 若平台支持「缓存后端」选择(如内存 vs 外存),优先内存,减少 I/O 延迟。
### 3. 流程设计(设计里看)
- 看是否有不必每次请求都走的节点(例如多余的重试、二次 LLM 调用),能省则省。
- 把最轻、最快的逻辑如简单规则、缓存命中尽量放在前面LLM 调用尽量靠后、且只调用必要次数。
---
## 二、SAARS 后端与 8037 的部署/网络(不改业务代码)
- 8052 访问 8037 的地址
若 8052 和 8037 在同一台机(如都在 101.43.95.130确认用的是 http://127.0.0.1:8037 或本机内网 IP避免绕公网减少网络延迟。
- 8037 所在机器资源
 8037 跑在同一台机,保证该机 CPU/内存充足 LLM 是远程 API则优化到该 API 的网络(同区、专线等),这些都会直接影响「知你客服」的响应时间。
---
## 三、可做的检查清单(先不做代码改动)
| 位置 | 检查项 | 预期效果 |
| ------- | -------------------- | -------- |
| 8037 编辑 | 意图识别 LLM换更快/更小模型 | 明显缩短首包时间 |
| 8037 编辑 | LLMmax_tokens 调小 | 减少总生成时间 |
| 8037 设计 | 缓存节点:容量与查询范围 | 减少记忆查询耗时 |
| 8037 设计 | 流程:去掉多余节点、顺序优化 | 减少无效等待 |
| 部署/网络 | 8052 调 8037 用本机或内网地址 | 降低网络 RTT |
建议先在 8037 里点「编辑」或「设计」,把意图识别的 LLM 模型和 max_tokens 调一档再测一次「知你客服」的回复速度若仍慢再按上面逐项排查缓存和流程。若你愿意后续再通过改 SAARS 的轮询间隔等做优化,可以再说,我们再针对代码给一版最小改动方案。

View File

@@ -0,0 +1 @@
写个脚本开始测试知你客服6号要求第一次告诉它我叫小七爱吃苹果。第二轮问西安有啥玩的第三轮问题北京有啥玩的第四轮问他中国有多少个省第五轮问它陕西有多少市。第六轮问他我叫什么名字

View File

@@ -0,0 +1,81 @@
知你客服 6 号(检索增强记忆)已按「检索 + 最近几轮」混合方案做完,并完成引擎扩展与导入。摘要如下。
---
## 1. 引擎新增/改动
### 新增 embedding 节点
- 类型embedding
- 作用:调用 OpenAI 兼容的 Embedding API默认 DeepSeek把文本变成向量。
- 输入 text / content / query / user_input 中取第一个非空作为待向量化文本。
- 输出:{ embedding: number[], text: string }
- 配置provider默认 deepseek、model默认 deepseek-embedding
### vector_db 节点:按 user 持久化
- collection = user_memory 且输入里带 user_id 
- Redis 读写key = vector_memory:{user_id}TTL 7 天。
- search先从 Redis 拉取该 user 的向量列表再算相似度、取 top_k。
- upsert先加载该 user 列表,插入/更新后再写回 Redis。
### get_node_input补充 user_id
- 若某节点输入里没有 user_id会从 start 节点(执行入参)里补上,供按 user 的向量检索/写入使用。
---
## 2. 知你客服 6 号流程(检索 + 最近几轮)
1. start → cache-query → transform-merge
与 5 号一致拿到当前用户输入、记忆 conversation_history、user_profile、user_id。
1. 检索分支
- embedding-query对当前 user_input 做向量化。
- merge-retrieve合并「merge 的完整输出」与「embedding 结果」。
- transform-prepare-search拼出 embedding、user_id、memory、user_input 供检索和后续用。
- vector-searchcollection=user_memorytop_k=5用 Redis 里该 user 的向量做相似度检索。
- merge-context合并「prepare-search 输出」与「检索结果列表」。
- code-build-context
- 检索结果 → 拼成「相关历史(检索)」字符串。
- memory.conversation_history 取最近 4 条 → 拼成「最近几轮」字符串。
- 输出user_input、memory.user_profile、memory.relevant_from_retrieval、memory.recent_turns。
1. llm-unified
使用上面构造的「相关历史」+「最近几轮」+ 用户信息生成回复格式同 5 号,含 intent、reply、user_profile
1. 解析与提取
json 解析 → transform-extract-reply-and-profile 得到 right回复、user_profile_update。
1. 写入向量库(每轮一次)
- code-build-turn-for-vector用当前 query + right 拼成本轮文本如「用户xxx\n助手yyy」并生成 id、带出 user_id依赖引擎注入
- embedding-turn对本轮文本做向量化。
- merge-for-upsert  transform-for-vector-upsert拼出 embedding、text、user_id、id。
- vector-upsertcollection=user_memory user_id 写入 Redis供之后检索。
1. 记忆与输出
与 5 号相同transform-cache-input  code-add-count  condition-need-summary → 摘要分支 / 追加分支 → cache-update-* → transform-output-format  end。

View File

@@ -0,0 +1,75 @@
## 1. 引擎改动(不改架构)
- 条件节点透传
条件节点在返回 branch 的同时把整份 input_data 写入 output分支内节点可继续使用 memory、user_input、right、user_id 等。
- Cache 写入支持 memory_value
当 cache 节点 operation=set 且输入里带有 memory_valuedict直接用它作为要写入的值不再走模板求值仍会对其中的 conversation_history 做相邻去重并截断到最近 8 条。
- 去重与截断统一
 conversation_history 的相邻去重和「保留最近 8 条」统一放在「存储前」一步,无论 value 来自模板还是 memory_value。
---
## 2. 知你客服 5 号设计
- 记忆结构
在 4 号基础上增加 conversation_summary字符串
{ conversation_summary, conversation_history, user_profile, context }。
cache-query 的 default_value 已包含 conversation_summary: ""。
- 主 LLM 输入
主 LLM 同时看「对话摘要」和「最近几轮」:
对话摘要(之前聊过的要点):{{memory.conversation_summary}}\n最近几轮{{memory.conversation_history}}。
- 何时做摘要
 code 节点  history_count = len(memory.conversation_history),条件节点 判断 {history_count} >= 4
- ≥4 条true走摘要分支
- 透传 + 摘要 LLMdeepseek-chatmax_tokens=150把当前历史压成一段 ≤100 字摘要;
- merge 合并「透传数据」与「摘要文本」
- code 拼出 memory_valueconversation_summary = 新摘要conversation_history = 仅当前 1 轮(当前用户句 + 当前助手句);
- cache-update-summary  memory_value 写入不写 value 模板)。
- <4 条false走追加分支
- transform 拼好要追加的数据
- cache-update-append 用原有 value 模板追加一轮并保留 conversation_summary沿用已有或空
- 无需新节点类型
全部用现有节点start、cache、transform、llm、json、condition、code、merge、end。
---
## 3. 文件与使用
- 脚本backend/scripts/create_zhini_customer_service_v5.py
- 导出 JSON知你客服5号-导入用.json
- 已通过 API 创建知你客服5号ID: 20e76481-5186-46f7-bd85-f0719151b785
使用方式:
- 只生成 JSONpython backend/scripts/create_zhini_customer_service_v5.py
- 生成并导入 8037python backend/scripts/create_zhini_customer_service_v5.py --import
- 更新已有 5 号python backend/scripts/create_zhini_customer_service_v5.py --update
在前端 Agent 管理 里发布「知你客服5号」后即可测试。长对话时例如先聊几轮再问「刚才我说了什么」5 号会通过「摘要 + 最近几轮」保留更多上下文,记忆能力优于只保留最近 8 条的 4 号。

View File

@@ -0,0 +1,121 @@
已在项目根目录下创建 saars 聊天平台骨架并按你提供的《全栈聊天助手平台开发技术规范》做了对齐摘要如下。
---
## 1. 目录结构aiagent/saars/
saars/
├── backend/                    # Flask 后端
   ├── app/
      ├── api/               # RESTauth, chat, files, admin_api
      ├── models/            # User, Role, Conversation, Message
      ├── services/          # ChatEngineService, FileService
      ├── admin/             # Flask-AdminRBAC
      ├── utils/             # 密码哈希
      ├── config.py
      └── socket_events.py   # WebSocketSocketIO
   ├── tests/                 # pytest test_auth
   ├── requirements.txt
   ├── run.py
   └── Dockerfile
├── android-app/               # Android 客户端Java
   ├── app/
      ├── src/main/java/com/saars/chatplatform/
         ├── data/remote/   # ApiService (Retrofit)
         ├── domain/repository/
         └── presentation/  # MainActivity
      └── build.gradle       # Retrofit, OkHttp, Socket.IO, Room, Material3
   ├── build.gradle
   └── settings.gradle
├── docker-compose.yml         # backend + PostgreSQL 14 + Redis 7
└── README.md
---
## 2. 后端Flask已实现要点
- Flask 2.3+REST 风格 APICORS、Limiter。
- Flask-SocketIO + eventlet实时连接与房间connect / join_conversation / new_message
- PostgreSQL + SQLAlchemyUser、Role、Conversation、MessageFlask-Migrate 预留需在本地执行 flask db init / flask db migrate / flask db upgrade
- JWTFlask-JWT-Extended登录、刷新、/me。
- Redis config 中配置 REDIS_URL用于会话/扩展(当前逻辑可接 Redis
- 聊天引擎ChatEngineService — 会话列表、发消息、拉取消息、撤回、消息状态。
- 文件上传FileService + /api/v1/files/upload限制 10MB允许图片和文档扩展名。
- 管理端Flask-AdminBootstrap4User/Role/Conversation/Message 的 ModelView/api/v1/admin 下用户列表、更新用户、会话列表、统计 admin 角色RBAC
---
## 3. AndroidJava骨架
- minSdk 30targetSdk 34Java未使用 Kotlin
- MVVM 结构data/remote/ApiServiceRetrofit、domain/repository/ChatRepository、presentation/MainActivity。
- 依赖Retrofit 2.9、OkHttp、Socket.IO-Client、Room、Material、Lifecycle/ViewModel。
- 资源strings、themes、colors、activity_main 布局需自行补充 mipmap 图标或使用默认
---
## 4. 运行与后续步骤
后端(本地):
cd saars/backend
python -m venv venv && source venv/bin/activate  # Windows: venv\Scripts\activate
pip install -r requirements.txt
export FLASK_ENV=development
export DATABASE_URL=postgresql://postgres:postgres@localhost:5432/chat_platform
export REDIS_URL=redis://localhost:6379/0
flask db init && flask db migrate -m "init" && flask db upgrade
python run.py
Docker
cd saars && docker-compose up -d
# 首次在 backend 容器内执行上述 flask db init/migrate/upgrade
Android
cd saars/android-app && ./gradlew assembleDebug
规范中其余项OAuth 2.0 占位、FCM、Room 实体与 DAO、Chart.js 管理端图表、端到端加密、CI/CD 配置等)可在该骨架基础上按文档逐步补齐。若你希望先做某一块(例如先打通登录+一条消息流,或先做管理端 RBAC说明优先级即可继续细化实现。

View File

@@ -0,0 +1,106 @@
业内在做聊天机器人时,通常用下面几类方式应对「历史太长、存不下、模型也吃不下」的问题,你可以对照知你客服当前做法做取舍。
---
## 1. 滑动窗口Sliding Window
——你已经在用
只保留最近 N 轮/最近 N token 的原始对话发给模型更早的直接丢掉。
- 优点:实现简单、延迟可控、不超上下文。
- 缺点:早期重要信息会丢。
- 适用:短对话、客服/问答、对「很久以前说过什么」不敏感的场景。
知你客服的「最近 8 条 + 截断」就是这一种。
---
## 2. summarization / 对话压缩Summarization
不直接传全部历史,而是定期把旧对话压缩成一段摘要,和最近几轮一起发给模型。
- 做法举例:每 510 轮或每 N token用一个小模型/规则把「之前聊了什么、结论是什么」压成几句话(例如:「用户咨询了陕西地市数量,已告知 10 个地级市;随后问了西安天气。」),再和最近 23 轮原始对话一起进 prompt。
- 优点:在有限 token 里保留更长时间的语义长对话也能「记得梗概」。
- 缺点:要额外做摘要(成本/延迟),摘要质量会影响后续回复。
- 业内:很多带「长期记忆」的对话系统都会用「摘要 + 最近几轮」的组合。
---
## 3. 分层 / 长短记忆Hierarchical Memory
把记忆拆成「短期」和「长期」:
- 短期:最近几轮原始对话(滑动窗口),保证当前话题连贯。
- 长期:结构化信息(用户偏好、关键事实、已解决事项等),用紧凑格式存(键值、列表、几句话描述),每次只取和当前 query 最相关的几条塞进 prompt。
这样存可以很多,但发给模型的只是一小段「短期 + 精选长期」,既克服「存不下」也克服「模型吃不下」。
---
## 4. 检索增强记忆Retrieval-Augmented Memory
不按「时间顺序」截断,而是按「相关性」选要传给模型的历史:
- 把所有历史(或摘要)存进向量库/检索系统(按句或按轮做 embedding
- 每次请求时:用当前用户输入做 query检索出最相关的 K 条历史(或 K 段摘要只把这 K 条放进 prompt。
- 优点长对话里「很久以前但和当前问题相关」的内容仍能被用上token 用在「有用」的句子上。
- 缺点:需要向量存储与检索、延迟和成本略高。
- 业内:不少智能客服、带「记忆」的对话产品会采用「检索 + 最近几轮」混合。
---
## 5. 结构化记忆Structured Memory
不存整段对话,而是抽成结构化信息再喂给模型:
- 例如:用户画像(地区、偏好)、已澄清的实体(产品名、订单号)、意图/槽位、关键结论(「用户已接受方案 A」
- 存成 JSON/键值或固定模板的「记忆卡片」,每次只把和当前话题相关的几条拼成一小段文字进 prompt。
- 优点token 利用率高、可控、可解释;模型输入长度稳定。
- 缺点:要设计 schema 和抽取逻辑(规则或小模型)。
---
## 6. 大上下文模型 + 预算控制Long Context + Budget
用超长上下文模型 128K、1M token多塞一些原始历史同时做显式 token 预算
- 例如:系统提示 500、当前输入 300、历史 4000、预留回复 1000在「历史」预算内用滑动窗口或「摘要 + 最近几轮」填充。
- 优点:能带更多轮原始对话,体验更连贯。
- 缺点:长上下文贵、慢,且模型对「中间部分」的利用往往不如开头/结尾,所以业内仍会配合截断或摘要。
---
## 7. 小结:如何「克服」这个问题
|思路|本质|典型场景|
|---|---|---|
|滑动窗口|只保留最近 N 轮/ N token|客服、简单问答(你当前做法)|
|摘要/压缩|旧对话压成短文,和最近几轮一起送|长对话、需要「记得之前聊过什么」|
|分层记忆|短期原始 + 长期结构化/摘要|带用户画像、多轮任务的对话|
|检索增强|按相关性取历史,不按时间全塞|知识型、支持「很久以前提到过」的机器人|
|结构化记忆|只存和传递关键事实/槽位|任务型、表单填写、强可控回复|
|长上下文+预算|用大 context 但控制每部分 token|高端对话产品,配合上述手段|
所以业内并不是单靠「存更多轮」或「无脑塞长历史」,而是:
- 存储可以多存DB/向量库/摘要),
- 送给模型:通过截断、摘要、检索、结构化把「该让模型看到什么」控制在 token 预算内。
知你客服目前是「存储有限 + 只传最近 8 条」的滑动窗口;若以后要「记更多、用更久」,可以在不改大模型的前提下,加上摘要或检索/结构化记忆中的一种或两种,就能在同样 token 限制下明显提升「记忆」能力。

View File

@@ -251,6 +251,16 @@ nav:
- Obsidian笔记体系/Projects/女童生长激素项目/项目目录位置.md
- Obsidian笔记体系/Projects/提示词大师/提示词大师.md
- Obsidian笔记体系/Projects/aitsc/ai提示词常用命令.md
- Obsidian笔记体系/Projects/聊天平台/agent智能体性能调测.md
- Obsidian笔记体系/Projects/聊天平台/app.md
- Obsidian笔记体系/Projects/聊天平台/接入方式.md
- Obsidian笔记体系/Projects/聊天平台/数据库配置.md
- Obsidian笔记体系/Projects/聊天平台/未命名.md
- Obsidian笔记体系/Projects/聊天平台/测试用例.md
- Obsidian笔记体系/Projects/聊天平台/知你客服 6 号(检索增强记忆).md
- Obsidian笔记体系/Projects/聊天平台/知你客服5号的设计.md
- Obsidian笔记体系/Projects/聊天平台/聊天平台.md
- Obsidian笔记体系/Projects/聊天平台/聊天模型记忆解解方案.md
- gerrit:
- gerrit/gerrit上传代码详细指南.md
- gerrit/gerrit分支规范.md