# Human-Clone 系统需求调研记录

## 调研日期
2025-01-04

## 项目概述
Human-Clone 系统需求分析

## 第一轮调研

### 用户回答记录
**问题**: 这个human-clone系统的主要用途是什么？
**回答**: human 和 clone 之间相互协作，且可以和其他 clone、human 之间相互通讯的系统。现阶段首先解决的是通讯问题。

### 初步需求分析
- **核心功能**: 多主体间通讯协作系统
- **主体类型**: human, clone
- **通讯模式**: 
  - human ↔ clone
  - clone ↔ clone  
  - human ↔ human (通过系统)
- **当前优先级**: 通讯功能

### 下一步调研方向
需要深入了解通讯的具体需求和技术细节。

### 第二轮调研记录

**问题**: 这些主体之间的通讯主要是通过什么形式？文字、语音、还是视频？
**回答**: 第一步先解决主体之间文字形式的通讯

### 需求更新
- **通讯方式**: 首先实现文字通讯
- **开发阶段**: 第一阶段专注文字通讯功能
- **通讯模式**: 实时异步通讯

### 第三轮调研记录

**问题**: 系统需要支持实时通讯（如聊天室形式）还是异步通讯（如邮件/留言形式）？
**回答**: 基本属于实施通讯，但是是异步的，计划采用 redis 订阅的方式来实现信息传递，每一个主体都会有一个 redis-adapter，负责发送和接收消息

### 技术架构初步确定
- **消息传递**: Redis 订阅/发布模式
- **组件设计**: 每个主体配备 redis-adapter
- **消息处理**: 发送/接收消息统一处理

### 第四轮调研记录

**问题**: 每个主体（human/clone）需要有自己的身份标识吗？比如用户名、ID之类的？
**回答**: 需要有 id —— uuid 格式、实体名称（name)、redis-adapter 里和 redis 相关订阅 channel 相关的配置信息

### 主体身份设计
- **唯一标识**: UUID格式ID
- **显示名称**: 实体名称(name)
- **配置信息**: redis-adapter配置（订阅channel等）

### 第五轮调研记录

**问题**: 消息需要有哪些基本字段？比如发送者、接收者、时间戳、消息内容？
**回答**: 需要，其中发送者、接收者都使用 id

### 消息结构设计
- **发送者**: UUID格式ID
- **接收者**: UUID格式ID  
- **时间戳**: 消息发送时间
- **消息内容**: 文字内容
- **消息类型**: 点对点通讯

### 第六轮调研记录

**问题**: 是否需要支持群发消息（一个发送者同时发给多个接收者）？
**回答**: 此阶段不需要

### 功能范围明确
- **当前阶段**: 仅支持点对点消息
- **群发功能**: 后续版本考虑

### 第七轮调研记录

**问题**: 系统需要存储历史消息记录吗？
**回答**: 需要

### 数据持久化需求
- **消息存储**: 需要保存历史消息记录
- **存储方案**: 待确定（数据库选择）

### 第八轮调研记录

**问题**: 历史消息需要保存多长时间？
**回答**: 先不讨论历史记录的问题，先解决通信问题

### 开发优先级调整
- **当前重点**: 通讯功能实现
- **历史记录**: 后续阶段处理

### 第九轮调研记录

**问题**: redis-adapter 需要哪些具体的配置信息？比如 Redis 服务器地址、端口、认证信息等？
**回答**: redis 服务器地址、端口、db、channel

### redis-adapter 配置设计
- **服务器地址**: Redis host
- **端口**: Redis port
- **数据库**: Redis DB number
- **频道**: 订阅/发布的 channel

### 第十轮调研记录

**问题**: 每个主体是使用相同的 channel 还是各自有独立的 channel？如果是独立的，channel 的命名规则是什么？
**回答**: 每个主体都是独立的 channel，channel 的命名就是主体的 id

### Channel 设计方案
- **Channel 分配**: 每个主体独立 channel
- **命名规则**: 使用主体的 UUID 作为 channel 名称
- **通讯机制**: 目标主体监听自己的 channel 接收消息

### 第十一轮调研记录

**问题**: 当一个主体要发送消息给另一个主体时，是如何知道接收者的 channel 名称的？是否需要一个主体注册发现机制？
**回答**: 主体注册发现机制可以放到下一个迭代，此次只假设可以通过目标主体的 id 就可以获得目标主体的订阅 redis 参数，包括服务器、端口、db、channel

### 主体发现机制设计
- **当前版本**: 假设可通过 ID 获取目标的 Redis 连接参数
- **后续迭代**: 实现主体注册发现机制
- **参数获取**: 服务器地址、端口、DB、channel 通过 ID 直接获得

### 第十二轮调研记录

**问题**: redis-adapter 是否需要处理连接断开重连、消息发送失败重试等异常情况？
**回答**: 目前不需要

### 异常处理设计
- **当前版本**: 不处理连接重连和重试机制
- **设计原则**: 专注核心通讯功能，异常处理后续考虑

### 第十三轮调研记录

**问题**: 消息的发送和接收是否需要确认机制？比如接收者收到消息后需要回复确认？
**回答**: 不需要

### 消息确认机制
- **确认机制**: 不需要消息确认
- **通讯模式**: 单向发送，无回复确认
- **简化设计**: 降低复杂度，专注基础通讯

### 第十四轮调研记录

**问题**: 系统是否需要区分不同类型的消息？比如普通消息、系统消息、命令消息等？
**回答**: 不需要

### 消息类型设计
- **消息分类**: 不区分消息类型
- **统一处理**: 所有消息均为普通文字消息
- **简化架构**: 无需消息类型判断和处理逻辑

### 第十五轮调研记录

**问题**: 每个主体的 redis-adapter 是需要同时监听多个 channel（包括自己的和其他主体的）还是只监听自己的 channel？
**回答**: 只监听自己的

### 监听机制设计
- **监听范围**: 每个主体只监听自己的 channel
- **消息接收**: 通过订阅自己的 ID channel 接收消息
- **消息发送**: 向目标主体的 ID channel 发布消息

### 需求调研总结

基于15轮调研，Human-Clone 系统第一版本的核心需求已明确：

#### 系统架构
- **主体类型**: human、clone
- **通讯模式**: 点对点文字通讯
- **技术方案**: Redis 订阅/发布模式
- **身份标识**: UUID + name

#### 核心组件
- **redis-adapter**: 每个主体一个，负责发送/接收消息
- **配置参数**: 服务器地址、端口、DB、channel(=主体ID)
- **监听机制**: 只监听自己的 channel

#### 消息格式
- **发送者ID**: UUID格式
- **接收者ID**: UUID格式
- **时间戳**: 发送时间
- **内容**: 文字消息

#### 功能边界
- ✅ 点对点文字通讯
- ❌ 群发消息
- ❌ 历史消息存储
- ❌ 连接重连机制
- ❌ 消息确认机制
- ❌ 消息类型区分
- ❌ 主体注册发现

### 第十六轮调研记录

**问题**: 发送消息时是否需要引入发送缓存队列来解耦主体发送和Redis发送操作？
**回答**: 在发送主体不直接调用发送消息到 redis，而是在 redis-adapter 里设置一个发送缓存 queue，通过线程循环逐个 pop 后发送到 redis，这样主体发送和 redis 发送分开，且有缓存，解耦

### 第十七轮调研记录

**问题**: 消息接收部分是否也需要类似的队列解耦设计？
**回答**: 消息接收部分，目标主体 B 的redis-adapter 收到 channel 里的消息后，推送到接收队列 receiver-queue，在线程里循环读取 queue，并调用 callback，给到 B 的函数里进行处理

### 完整架构设计优化
- **发送缓存**: redis-adapter内部设置发送队列
- **接收缓存**: redis-adapter内部设置接收队列
- **双向异步**: 发送和接收均采用队列+线程机制
- **回调机制**: 接收线程通过callback将消息传递给主体
- **完全解耦**: Redis操作与主体处理完全分离

#### 下一步行动
基于明确的需求和完整的双向异步架构设计，可以开始进行技术设计和开发实现。