[RFC] 070 - 分支对话

[arvinxx]

背景

允许用户在任何一个消息下开启新对话

设计思路

灵活可扩展对话系统设计

User:

总体思路

我们的设计旨在创造一个灵活且易用的对话系统，支持在主话题下创建分支对话（Thread）。在分支中，用户可以继续探索相关主题或进行独立提问。通过扁平化的数据库结构，我们能够有效管理消息和线程之间的关系，同时保留必要的上下文信息，即使源消息被删除。

设计大纲

1. 核心概念

   • Topic: 顶级对话的容器，承载主要的对话主题。
   • Thread: 支持分支对话的结构，分为两种类型：continuation（延续性）和 standalone（独立）。
   • Message: 对话中的单条内容，关联特定的 Thread。

2. 数据结构设计

   • Topic 表
     • 用于存储对话主题及其元数据。

   export const topics = pgTable('topics', {
     clientId: text('client_id'),
     createdAt: createdAt(),
     favorite: boolean('favorite').default(false),
     id: text('id').$defaultFn(() => idGenerator('topics')).primaryKey(),
     sessionId: text('session_id').references(() => sessions.id, { onDelete: 'cascade' }),
     title: text('title'),
     updatedAt: updatedAt(),
     userId: text('user_id').references(() => users.id, { onDelete: 'cascade' }).notNull(),
   }, (t) => ({
     clientIdUnique: unique('topic_client_id_user_id_unique').on(t.clientId, t.userId),
   }));

   • Thread 表
     • 存储线程信息及其与消息的关系。

   export const threads = pgTable('threads', {
     id: text('id').$defaultFn(() => idGenerator('threads')).primaryKey(),
     title: text('title').notNull(),
     type: text('type', { enum: ['continuation', 'standalone'] }).notNull(),
     status: text('status', { enum: ['active', 'archived'] }).default('active'),
     topicId: text('topic_id').references(() => topics.id, { onDelete: 'cascade' }).notNull(),
     sourceMessageId: text('source_message_id').references(() => messages.id, { onDelete: 'set null' }).notNull(),
     parentThreadId: text('parent_thread_id').references(() => threads.id, { onDelete: 'set null' }),
     createdAt: createdAt(),
     updatedAt: updatedAt(),
     lastActiveAt: timestamp('last_active_at').defaultNow(),
     sourcePreview: text('source_preview'), // 存储被删除的源消息的预览
     userId: text('user_id').references(() => users.id, { onDelete: 'cascade' }).notNull(),
   });

   • Message 表
     • 记录每条消息信息。

   export const messages = pgTable('messages', {
     id: text('id').$defaultFn(() => idGenerator('messages')).primaryKey(),
     content: text('content').notNull(),
     createdAt: createdAt(),
     updatedAt: updatedAt(),
     threadId: text('thread_id').references(() => threads.id, { onDelete: 'cascade' }), // 消息所属的线程
     // 其他相关字段...
   });

3. 操作和逻辑

   • 分支创建:
     • 用户可以基于现有的消息创建新线程，并指定类型（continuation 或 standalone）。
   • 消息删除处理:
     • 如果源消息被删除，线程的 sourcePreview 字段将被更新为源消息的前100个字符，方便用户了解删除的消息内容。
   • 用户界面:
     • 清晰地展示主线和分支结构，确保用户能够直观理解对话流。

4. 可视化展示

   • 使用画布展示不同线程之间的关系，支持鼠标悬停和点击事件查看详细信息。

5. 扩展性

   • 设计模式允许未来的功能添加，如对话合并、内容自动归档等。

结论

通过这种设计，我们能够构建一个灵活和可扩展的对话系统，使用户能够有效地管理和探索对话内容，同时保持系统的复杂性在可控范围内。这种设计既考虑到了数据的完整性和一致性，又关注用户体验。

User:

基于这样的结构，请演绎一下用户的可能使用方式。尽可能列举全

Assistant:

用户在这样一个支持分支对话的系统中，可能会通过多种方式进行交互和使用。以下是一些可能的使用场景和方式：

1. 开始对话

• 创建新话题:
  • 用户启动一段全新的对话，输入主题，通过系统创建一个新的 Topic。

2. 创建分支对话

• 基于消息创建分支:
  • 在现有对话中，用户可以选择一条消息，然后创建一个新的 Thread。用户可以选择该线程的类型为 continuation（延续性）或 standalone（独立）。

3. 消息发送与回复

• 发送消息:
  • 用户在指定的 Thread 中输入内容并发送消息，系统将该消息记录到 Message 表。
• 引用消息:
  • 用户可以在新消息中引用之前的消息，以提供上下文，系统支持引用功能。

4. 查看对话

• 浏览信息:
  • 用户可以在界面上浏览已有的话题和线程，查看各个线程下的消息。
• 消息筛选与搜索:
  • 提供搜索和筛选功能，让用户能够快速找到特定话题或消息。

5. 处理和删除消息

• 删除消息:
  • 用户可以选择删除某条消息，系统会更新相关的线程信息，包括更新 sourcePreview 字段以反映已删除消息的内容。

6. 归档和状态管理

• 归档线程:
  • 用户可以选择将不再活跃的 Thread 归档，这样可以保持界面的简洁性。
• 恢复归档线程:
  • 归档的线程可以随时恢复，用户能够继续查看或参与讨论。

7. 对话结构可视化

• 查看对话结构:
  • 用户可以通过可视化界面查看话题和线程的结构，清晰了解对话的脉络和分支。
• 交互式查看:
  • 鼠标悬停某个线程或消息，用户可以查看更详细的信息，如摘要、时间戳等。

8. 高级功能

• 合并对话:
  • 用户可以选择将两个相关的 Thread 合并，形成一个新的讨论线索。
• 标记重要消息:
  • 用户可以为特定消息添加标签或标记，以便于后续快速查找。

9. 个性化设置

• 设置优先级:
  • 根据需要，用户可以调整不同线程的显示优先级，确保重要话题始终显示在上方。
• 自定义通知:
  • 用户可以设置接收特定消息或线程的通知，以便及时了解讨论动态。

11. 强调回顾和总结

• 生成总结:
  • 用户可以请求系统为某个 Thread 生成讨论总结，方便回顾主要观点。

这种设计允许用户根据不同需求灵活地使用系统，侧重在使用体验的直观性和多样性上，确保每个用户都能找到适合自己的对话方式。

User:

详细展开讨论下基于消息创建分支这个场景下的用户操作会有哪些

Assistant:

用户在基于消息创建分支对话的场景下，可能会经历以下详细操作步骤。我们可以将整个流程分为几个主要阶段：选择消息、选择分支类型、输入信息、确认操作和后续互动。

1. 选择消息

• 浏览消息: 用户在当前对话中浏览之前发送的消息。系统设计可能包括时间轴、消息列表或卡片式展示，方便用户快速定位。
• 选择目标消息: 用户通过点击或悬停操作选择要创建分支的目标消息。通常，目标消息在界面上会有视觉提示，表明已被选中。

2. 创建分支操作

• 创建分支按钮: 用户在选择消息后，界面上可能会出现“创建分支”或类似的操作按钮，用户点击后进入分支创建界面。
• 分支类型选择:
  • Continuation（延续性）: 用户选择该选项时，新线程将与目标消息保持一致的上下文。系统会自动填入目标消息的相关信息（如标题或摘要）。
  • Standalone（独立）: 用户选择该选项，新线程将与目标消息无关，允许用户重新定义上下文。用户需手动输入上下文信息。

3. 输入信息

• 线程标题:
  • 对于 continuation 类型，系统可能自动生成标题，用户可以进行编辑；对于 standalone 类型，用户需要自行输入标题。
• 消息内容:
  • 用户在新线程中输入消息内容，可以选择回复特定主题或发表新见解。
• 附件和引用:
  • 用户可以选择向新消息添加附件（如文件、图片等），或引用前面的消息文本以提供更具体的上下文。

4. 确认创建

• 界面预览:
  • 系统可能会提供新线程的预览（如标题、内容和引用的消息），用户可以在确认前查看。
• 确认操作:
  • 用户点击“确认”或“创建分支”按钮，系统将创建新线程并将其关联至目标消息。

5. 触发后续操作

• 浏览新线程:
  • 系统将用户自动导航至新创建的 Thread，方便用户继续讨论。
• 发送新消息:
  • 用户可以立即在新线程内发送消息，继续讨论相关话题。
• 返回主线程:
  • 用户可以方便地返回最初的话题或其他相关分支，便于整个对话的流转。

6. 后续互动

• 查看消息更新:
  • 用户在新线程中讨论时，系统将实时显示参与者的消息，保持对话的流畅性。
• 参与其他线程:
  • 用户可以选择参与相关的其他线程，形成更复杂的讨论结构，系统可以为用户推送新消息或活跃线程的通知。
• 编辑或删除分支:
  • 用户在后续可以对新分支的消息进行编辑或删除，系统会及时更新信息。

7. 反馈与建议

• 建议改进:
  • 系统可以在用户操作完成后，询问用户对创建分支的体验和反馈，以便优化用户体验。
• 智能回复:
  • 在用户生成新消息后，系统可能建议潜在的回复或相关主题，以便用户更好地探讨新链接。

总结

这样的操作流程旨在为用户提供直观、高效且灵活的分支创建能力，确保用户能够轻松地拓展对话话题，增加讨论的深度和广度。通过简练的界面设计和流畅的交互体验，可以有效地提升用户的满意度和系统的使用效率。

[canisminor1990]

• 6 归档和状态管理：归档需要主观手动，而且其实进一步增加了结构的复杂度，显示情况下其实对于topic的手动维护频率较低，建议考虑按活跃度进行自动的折叠展示，比较降低认知成本
• 7 不确定 Hover 展示详情是否会挡视野，或者可以考虑准备两种 topic 的展示切换，List 和 Card
• 8 合并不如考虑可以选择引用某几个 topic/thread
• 9 在现有收藏外额外再添加优先级感觉也会增加复杂度，建议用活跃度替代

名词上我感觉 subtopic 子话题 比 thread 线程更容易理解

[arvinxx]

• 归档准备参考 Discord 这个来感觉就行，Discord 有按时间自动归档的逻辑，超过x天就直接隐藏。只有点击了这个话题才显示激活的子话题
• 状态标记，比如是否是废弃了的 thread 比较重要
• 实体关系上计划使用 thread 替代 subTopic ，便于写代码的时候做区分。对用户展示上感觉可以用子话题
• 合并感觉用处不是很大，应该不会做

[arvinxx]

前置重构 PR：

• ♻️ refactor: refactor chat conversation #4689
• 将原本的 Desktop/Mobile 实现挪至 features/ChatInput ♻️ refactor: move ChatInput to @features/ChatInput #4699

[arvinxx]

关键实现梳理

前端数据加工

核心逻辑：对话展示用的 message data list 和 发给 ai 的 message data list 是两个 list。

• 对话展示用的 message list：首先会过滤掉所有的 tool（不展示 tool）
• ai 的 message list：包含 tool

分支对话会需要在 Portal 里重新实现一遍请求逻辑，因此 message list 也是两套。

• 针对展示用的对话列表，记为 DisplayChats
• 针对发给 ai 的对话列表，记为 AIChats

因此在 main 对话区域，就会由两个selector

• mainDisplayChats
• mainAIChats

基于这两个 selector，会有对应的衍生的selectors:

• mainDisplayChatIDs: 只包含 message id 的展示 chat 列表；
• mainAIChatsWithHistoryConfig: 基于 mainAIChats，带有历史记录配置的消息；
• mainAIChatsMessageString： 基于历史记录配置拼接 message content 的字符串序列，用于算 token；

在 portal 区域，应该也需要对应的一些 selector

[arvinxx]

Thread 功能列表

Topic 区域

• Topic 展示 Thread list
• Thread 删除、重命名
• 在 Thread 中点击 Item 在 Main chat 激活 Thread

MainChat

• 在 Main Chat 中展示 message 关联的 threads
• Main Chat 中创建 Thread （ActionBar 新增 branch action）
• 针有 thread 的 message 禁用删除
• 允许点击子话题在 Portal 展开 Thread
• 激活 Thread 的情况下暂不支持创建子 Thread（未来再做）
• Tool Message 不提供 branching

Portal Thread

• 创建 Thread 时配置 type
• 发送 message 创建并添加 thread
• Portal Thread 不显示 branch action
• 清楚展示子话题标记
• 子话题前的消息不允许展示任何 action
• 子话题前的消息不允许编辑
• 发送 Thread 消息时只 loading Thread 的 send button
• portal message 在 url 持久化，下次打开仍然自动展开
• Portal 的 token 统计需要单独计算
• Portal Message 展示
  • Portal Thread 的消息历史范围
• Portal Thread 的插件调用
  • 需要包含 thread Id
  • 隐藏在 Portal 打开的按钮
  • Artifacts 不允许在 Portal 中打开
• 移动端适配（所有 Portal 统一走高浮层）

其他

• i18n

[arvinxx]

这周应该能发，但保险起见会先用 Feature Flag 默认关闭，要尝鲜自行开启，体验和反馈 1~2 周，等 12 月中再改成默认开启

[arvinxx]

@SAnBlog 已发布，v1.34.0 可用

[SAnBlog]

@SAnBlog 已发布，v1.34.0 可用

that's so good

[CGamesPlay]

This is great! Is there any documentation on how to enable the feature flag?

[arvinxx]

@CGamesPlay Nothing need, it's enabled by default now