doc：更新了很多doc
This commit is contained in:
SengokuCola
@@ -1,5 +1,80 @@
|
||||
# Changelog
|
||||
|
||||
## [0.6.3] - 2025-4-15
|
||||
|
||||
### 摘要
|
||||
- MaiBot 0.6.3 版本发布！核心重构回复逻辑，统一为心流系统管理，智能切换交互模式。
|
||||
- 引入全新的 LPMM 知识库系统，大幅提升信息获取能力。
|
||||
- 新增昵称系统，改善群聊中的身份识别。
|
||||
- 提供独立的桌宠适配器连接程序。
|
||||
- 优化日志输出，修复若干问题。
|
||||
|
||||
### 🌟 核心功能增强
|
||||
#### 统一回复逻辑 (Unified Reply Logic)
|
||||
- **核心重构**: 移除了经典 (Reasoning) 与心流 (Heart Flow) 模式的区分，将回复逻辑完全整合到 `SubHeartflow` 中进行统一管理，由主心流统一调控。保留 Heart FC 模式的特色功能。
|
||||
- **智能交互模式**: `SubHeartflow` 现在可以根据情境智能选择不同的交互模式：
|
||||
- **普通聊天 (Normal Chat)**: 类似于之前的 Reasoning 模式，进行常规回复（激活逻辑暂未改变）。
|
||||
- **心流聊天 (Heart Flow Chat)**: 基于改进的 PFC 模式，能更好地理解上下文，减少重复和认错人的情况，并支持**工具调用**以获取额外信息。
|
||||
- **离线模式 (Offline/Absent)**: 在特定情况下，麦麦可能会选择暂时不查看或回复群聊消息。
|
||||
- **状态管理**: 交互模式的切换由 `SubHeartflow` 内部逻辑和 `SubHeartflowManager` 根据整体状态 (`MaiState`) 和配置进行管理。
|
||||
- **流程优化**: 拆分了子心流的思考模块，使整体对话流程更加清晰。
|
||||
- **状态判断改进**: 将 CHAT 状态判断交给 LLM 处理，使对话更自然。
|
||||
- **回复机制**: 实现更为灵活的概率回复机制，使机器人能够自然地融入群聊环境。
|
||||
|
||||
#### 全新知识库系统 (New Knowledge Base System - LPMM)
|
||||
- **引入 LPMM**: 新增了 **LPMM (Large Psychology Model Maker)** 知识库系统，具有强大的信息检索能力，能显著提升麦麦获取和利用知识的效率。
|
||||
- **功能集成**: 集成了 LPMM 知识库查询功能，进一步扩展信息检索能力。
|
||||
- **推荐使用**: 强烈建议使用新的 LPMM 系统以获得最佳体验。旧的知识库系统仍然可用作为备选。
|
||||
|
||||
#### 昵称系统 (Nickname System)
|
||||
- **自动取名**: 麦麦现在会尝试给群友取昵称，减少对易变的群昵称的依赖，从而降低认错人的概率。
|
||||
- **持续完善**: 该系统目前仍处于早期阶段，会持续进行优化。
|
||||
|
||||
#### 记忆与上下文增强 (Memory and Context Enhancement)
|
||||
- **聊天记录压缩**: 大幅优化聊天记录压缩系统，使机器人能够处理5倍于之前的上下文记忆量。
|
||||
- **记忆提取**: 优化记忆提取功能，提高对历史对话的理解和引用能力。
|
||||
- **中期记忆调用**: 完善中期记忆调用机制，使机器人能够更自然地回忆和引用较早前的对话。
|
||||
|
||||
#### 私聊 PFC 功能增强 (Private Chat PFC Enhancement)
|
||||
- **功能修复与优化**: 修复了私聊 PFC 载入聊天记录缺失的 bug，优化了 prompt 构建，增加了审核机制，调整了重试次数，并将机器人发言存入数据库。
|
||||
- **实验性质**: 请注意，PFC 仍然是一个实验性功能，可能在未来版本中被修改或移除，目前不接受相关 Bug 反馈。
|
||||
|
||||
#### 情感与互动增强 (Emotion and Interaction Enhancement)
|
||||
- **全新表情包系统**: 新的表情包系统上线，表情含义更丰富，发送更快速。
|
||||
- **提示词优化**: 优化提示词（prompt）构建，增强对话质量和情感表达。
|
||||
- **积极性配置**: 优化"让麦麦更愿意说话"的相关配置，使机器人更积极参与对话。
|
||||
- **命名统一**: 实现统一命名功能，自动替换 prompt 内唯一标识符，优化 prompt 效果。
|
||||
- **颜文字保护**: 保护颜文字处理机制，确保表情正确显示。
|
||||
|
||||
#### 工具与集成 (Tools and Integration)
|
||||
- **动态更新**: 使用工具调用来更新关系和心情，取代原先的固定更新机制。
|
||||
- **智能调用**: 工具调用时会考虑上下文，使调用更加智能。
|
||||
- **知识库依赖**: 添加 LPMM 知识库依赖，扩展知识检索工具。
|
||||
|
||||
### 💻 系统架构优化
|
||||
#### 日志优化 (Logging Optimization)
|
||||
- **输出更清晰**: 优化了日志信息的格式和内容，使其更易于阅读和理解。
|
||||
|
||||
#### 模型与消息整合 (Model and Message Integration)
|
||||
- **模型合并**: 合并工具调用模型和心流模型，提高整体一致性。
|
||||
- **消息规范**: 全面改用 `maim_message`，移除对 `rest` 的支持。
|
||||
|
||||
#### (临时) 简易 GUI (Temporary Simple GUI)
|
||||
- **运行状态查看**: 提供了一个非常基础的图形用户界面，用于查看麦麦的运行状态。
|
||||
- **临时方案**: 这是一个临时性的解决方案，功能简陋，**将在 0.6.4 版本中被全新的 Web UI 所取代**。此 GUI 不会包含在主程序包中，而是通过一键包提供，并且不接受 Bug 反馈。
|
||||
|
||||
### 🐛 问题修复
|
||||
- **记忆检索优化**: 提高了记忆检索的准确性和效率。
|
||||
- 修复了一些其他小问题。
|
||||
|
||||
### 🔧 其他改进
|
||||
#### 桌宠适配器 (Bug Catcher Adapter)
|
||||
- **独立适配器**: 提供了一个"桌宠"独立适配器，用于连接麦麦和桌宠。
|
||||
- **获取方式**: 可在 MaiBot 的 GitHub 组织中找到该适配器，不包含在主程序内。
|
||||
|
||||
#### 一键包内容 (One-Click Package Contents)
|
||||
- **辅助程序**: 一键包中包含了简易 GUI 和 **麦麦帮助配置** 等辅助程序，后者可在配置出现问题时提供帮助。
|
||||
|
||||
## [0.6.2] - 2025-4-14
|
||||
|
||||
### 摘要
|
||||
|
||||
48
src/heart_flow/0.6.3TODO.md
Normal file
48
src/heart_flow/0.6.3TODO.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# 0.6.3 版本发布前待办事项
|
||||
|
||||
- **统一化人格配置:**
|
||||
- 检查代码中是否存在硬编码的人格相关配置。
|
||||
- 将所有硬编码的人格配置替换为使用 `individual` 模块进行管理。
|
||||
|
||||
- **在 Planner 中添加回复计数信息:**
|
||||
- 修改 `HeartFlowChatInstance` 的 `Plan` 阶段逻辑。
|
||||
- 将当前周期的回复计数（或其他相关统计信息）作为输入提供给 Planner。
|
||||
- 目的是为 Planner 提供负反馈，减少连续回复或不当回复的可能性。
|
||||
|
||||
- **恢复/检查被停止的功能:**
|
||||
- 全面审查代码，特别是对比之前的版本或设计文档。
|
||||
- 识别并重新启用那些暂时被禁用但应该恢复的功能。
|
||||
- 确认没有核心功能意外丢失。
|
||||
|
||||
- **参数提取与配置化:**
|
||||
- 识别代码中散落的各种可调参数（例如：概率阈值、时间间隔、次数限制、LLM 模型名称等）。
|
||||
- 将这些参数统一提取到模块或类的顶部。
|
||||
- 最终将这些参数移至外部配置文件（如 YAML 或 JSON 文件），方便用户自定义。
|
||||
|
||||
- **提供 HFC (HeartFlowChatInstance) 开启/关闭选项:**
|
||||
- 增加一个全局或针对特定子心流的配置选项。
|
||||
- 允许用户控制是否启用 `FOCUSED` 状态以及关联的 `HeartFlowChatInstance`。
|
||||
- 如果禁用 HFC，子心流可能只会在 `ABSENT` 和 `CHAT` 状态间切换。
|
||||
|
||||
- **添加防破线机制 (针对接收消息):**
|
||||
- 在消息处理流程的早期阶段 (例如 `HeartHC_processor` 或类似模块)，增加对接收到的消息文本长度的检查。
|
||||
- 对超过预设长度阈值的*接收*消息进行截断处理。
|
||||
- 目的是防止过长的输入（可能包含"破限"提示词）影响后续的兴趣计算、LLM 回复生成等环节。
|
||||
|
||||
- **NormalChat 模式下的记忆与 Prompt 优化:**
|
||||
- 重点审视 `NormalChatInstance` (闲聊/推理模式) 中记忆调用 (例如 `HippocampusManager` 的使用) 的方式。
|
||||
- 评估在该模式下引入工具调用 (Tool Calling) 机制以更结构化访问记忆的必要性。
|
||||
- 优化 `NormalChatInstance` 中与记忆检索、应用相关的 Prompt。
|
||||
|
||||
- **完善简易兴趣监控 GUI:**
|
||||
- 改进现有的、用于监控聊天兴趣度 (`InterestChatting`?) 的简单 GUI 界面。
|
||||
- 使其能更清晰地展示关键参数和状态，作为查看日志之外的更直观的监控方式。
|
||||
- 作为完整外部 UI 开发完成前的临时替代方案。
|
||||
|
||||
- **修复/完善中期记忆 (Midterm Memory):**
|
||||
- 检查当前中期记忆模块的状态。
|
||||
- 修复已知问题，使其能够稳定运行。
|
||||
- (优先级视开发时间而定)
|
||||
|
||||
|
||||
对于有些群频繁激活HFC，却不回复，需要处理一下
|
||||
84
src/heart_flow/0.6Bing.md
Normal file
84
src/heart_flow/0.6Bing.md
Normal file
@@ -0,0 +1,84 @@
|
||||
- **智能化 MaiState 状态转换**:
|
||||
- 当前 `MaiState` (整体状态，如 `OFFLINE`, `NORMAL_CHAT` 等) 的转换逻辑 (`MaiStateManager`) 较为简单，主要依赖时间和随机性。
|
||||
- 未来的计划是让主心流 (`Heartflow`) 负责决策自身的 `MaiState`。
|
||||
- 该决策将综合考虑以下信息：
|
||||
- 各个子心流 (`SubHeartflow`) 的活动状态和信息摘要。
|
||||
- 主心流自身的状态和历史信息。
|
||||
- (可能) 结合预设的日程安排 (Schedule) 信息。
|
||||
- 目标是让 Mai 的整体状态变化更符合逻辑和上下文。 (计划在 064 实现)
|
||||
|
||||
- **参数化与动态调整聊天行为**:
|
||||
- 将 `NormalChatInstance` 和 `HeartFlowChatInstance` 中的关键行为参数（例如：回复概率、思考频率、兴趣度阈值、状态转换条件等）提取出来，使其更易于配置。
|
||||
- 允许每个 `SubHeartflow` (即每个聊天场景) 拥有其独立的参数配置，实现"千群千面"。
|
||||
- 开发机制，使得这些参数能够被动态调整：
|
||||
- 基于外部反馈：例如，根据用户评价（"话太多"或"太冷淡"）调整回复频率。
|
||||
- 基于环境分析：例如，根据群消息的活跃度自动调整参与度。
|
||||
- 基于学习：通过分析历史交互数据，优化特定群聊下的行为模式。
|
||||
- 目标是让 Mai 在不同群聊中展现出更适应环境、更个性化的交互风格。
|
||||
|
||||
- **动态 Prompt 生成与人格塑造**:
|
||||
- 当前 Prompt (提示词) 相对静态。计划实现动态或半结构化的 Prompt 生成。
|
||||
- Prompt 内容可根据以下因素调整：
|
||||
- **人格特质**: 通过参数化配置（如友善度、严谨性等），影响 Prompt 的措辞、语气和思考倾向，塑造更稳定和独特的人格。
|
||||
- **当前情绪**: 将实时情绪状态融入 Prompt，使回复更符合当下心境。
|
||||
- 目标：提升 `HeartFlowChatInstance` (HFC) 回复的多样性、一致性和真实感。
|
||||
- 前置：需要重构 Prompt 构建逻辑，可能引入 `PromptBuilder` 并提供标准接口 (认为是必须步骤)。
|
||||
|
||||
- **扩展观察系统 (Observation System)**:
|
||||
- 目前主要依赖 `ChattingObservation` 获取消息。
|
||||
- 计划引入更多 `Observation` 类型，为 `SubHeartflow` 提供更丰富的上下文：
|
||||
- Mai 的全局状态 (`MaiStateInfo`)。
|
||||
- `SubHeartflow` 自身的聊天状态 (`ChatStateInfo`) 和参数配置。
|
||||
- Mai 的系统配置、连接平台信息。
|
||||
- 其他相关聊天或系统的聚合信息。
|
||||
- 目标：让 `SubHeartflow` 基于更全面的信息进行决策。
|
||||
|
||||
- **增强工具调用能力 (Enhanced Tool Usage)**:
|
||||
- 扩展 `HeartFlowChatInstance` (HFC) 可用的工具集。
|
||||
- 考虑引入"元工具"或分层工具机制，允许 HFC 在需要时（如深度思考）访问更强大的工具，例如：
|
||||
- 修改自身或其他 `SubHeartflow` 的聊天参数。
|
||||
- 请求改变 Mai 的全局状态 (`MaiState`)。
|
||||
- 管理日程或执行更复杂的分析任务。
|
||||
- 目标：提升 HFC 的自主决策和行动能力，即使会增加一定的延迟。
|
||||
|
||||
- **基于历史学习的行为模式应用**:
|
||||
- **学习**: 分析过往聊天记录，提取和学习具体的行为模式（如特定梗的用法、情境化回应风格等）。可能需要专门的分析模块。
|
||||
- **存储与匹配**: 需要有效的方法存储学习到的行为模式，并开发强大的 **匹配** 机制，在运行时根据当前情境检索最合适的模式。**(匹配的准确性是关键)**
|
||||
- **应用与评估**: 将匹配到的行为模式融入 HFC 的决策和回复生成（例如，将其整合进 Prompt）。之后需评估该行为模式应用的实际效果。
|
||||
- **人格塑造**: 通过学习到的实际行为来动态塑造人格，作为静态人设描述的补充或替代，使其更生动自然。
|
||||
|
||||
- **标准化人设生成 (Standardized Persona Generation)**:
|
||||
- **目标**: 解决手动配置 `人设` 文件缺乏标准、难以全面描述个性的问题，并生成更丰富、可操作的人格资源。
|
||||
- **方法**: 利用大型语言模型 (LLM) 辅助生成标准化的、结构化的人格**资源包**。
|
||||
- **生成内容**: 不仅生成描述性文本（替代现有 `individual` 配置），还可以同时生成与该人格配套的：
|
||||
- **相关工具 (Tools)**: 该人格倾向于使用的工具或能力。
|
||||
- **初始记忆/知识库 (Memories/Knowledge)**: 定义其背景和知识基础。
|
||||
- **核心行为模式 (Core Behavior Patterns)**: 预置一些典型的行为方式，可作为行为学习的起点。
|
||||
- **实现途径**:
|
||||
- 通过与 LLM 的交互式对话来定义和细化人格及其配套资源。
|
||||
- 让 LLM 分析提供的文本材料（如小说、背景故事）来提取人格特质和相关信息。
|
||||
- **优势**: 替代易出错且标准不一的手动配置，生成更丰富、一致、包含配套资源且易于系统理解和应用的人格包。
|
||||
|
||||
- **优化表情包处理与理解 (Enhanced Emoji Handling and Understanding)**:
|
||||
- **面临挑战**:
|
||||
- **历史记录表示**: 如何在聊天历史中有效表示表情包，供 LLM 理解。
|
||||
- **语义理解**: 如何让 LLM 准确把握表情包的含义、情感和语境。
|
||||
- **场景判断与选择**: 如何让 LLM 判断何时适合使用表情包，并选择最贴切的一个。
|
||||
- **目标**: 提升 Mai 理解和运用表情包的能力，使交互更自然生动。
|
||||
- **说明**: 可能需要较多时间进行数据处理和模型调优，但对改善体验潜力巨大。
|
||||
|
||||
- **探索高级记忆检索机制 (GE 系统概念):**
|
||||
- 研究超越简单关键词/近期性检索的记忆模型。
|
||||
- 考虑引入基于事件关联、相对时间线索和绝对时间锚点的检索方式。
|
||||
- 可能涉及设计新的事件表示或记忆结构。
|
||||
|
||||
|
||||
- **实现 SubHeartflow 级记忆缓存池:**
|
||||
- 在 `SubHeartflow` 层级或更高层级设计并实现一个缓存池，存储已检索的记忆/信息。
|
||||
- 避免在 HFC 等循环中重复进行相同的记忆检索调用。
|
||||
- 确保存储的信息能有效服务于当前交互上下文。
|
||||
|
||||
- **基于人格生成预设知识:**
|
||||
- 开发利用 LLM 和人格配置生成背景知识的功能。
|
||||
- 这些知识应符合角色的行为风格和可能的经历。
|
||||
- 作为一种"冷启动"或丰富角色深度的方式。
|
||||
@@ -151,11 +151,31 @@ c HeartFChatting工作方式
|
||||
- `ChatState.CHAT` (随便看看/水群): 普通聊天模式。激活 `NormalChatInstance`。
|
||||
* `ChatState.FOCUSED` (专注/认真水群): 专注聊天模式。激活 `HeartFlowChatInstance`。
|
||||
- **选择**: 子心流可以根据外部指令（来自 `SubHeartflowManager`）或内部逻辑（未来的扩展）选择进入 `ABSENT` 状态（不回复不观察），或进入 `CHAT` / `FOCUSED` 中的一种回复模式。
|
||||
- **状态转换机制** (由 `SubHeartflowManager` 驱动):
|
||||
- **激活 `CHAT`**: 当 `Heartflow` 状态从 `OFFLINE` 变为允许聊天的状态时，`SubHeartflowManager` 会根据限制（通过 `self.mai_state_info` 获取），选择部分 `ABSENT` 状态的子心流，**检查当前 CHAT 状态数量是否达到上限**，如果未达上限，则调用其 `change_chat_state` 方法将其转换为 `CHAT`。此外，`evaluate_and_transition_subflows_by_llm` 方法也会根据 LLM 的判断，在未达上限时将 `ABSENT` 状态的子心流激活为 `CHAT`。
|
||||
- **激活 `FOCUSED`**: `SubHeartflowManager` 会定期评估处于 `CHAT` 状态的子心流的兴趣度 (`InterestChatting.start_hfc_probability`)，若满足条件且**检查当前 FOCUSED 状态数量未达上限**（通过 `self.mai_state_info` 获取限制），则调用 `change_chat_state` 将其提升为 `FOCUSED`。
|
||||
- **停用/回退**: `SubHeartflowManager` 可能因 `Heartflow` 状态变化、达到数量限制、长时间不活跃、随机概率 (`randomly_deactivate_subflows`)、LLM 评估 (`evaluate_and_transition_subflows_by_llm` 判断 `CHAT` 状态子心流应休眠) 或收到来自 `HeartFChatting` 的连续不回复回调信号 (`request_absent_transition`) 等原因，调用 `change_chat_state` 将子心流状态设置为 `ABSENT` 或从 `FOCUSED` 回退到 `CHAT`。当子心流进入 `ABSENT` 状态后，如果持续一小时不活跃，才会被后台清理任务删除。
|
||||
- **注意**: `change_chat_state` 方法本身只负责执行状态转换和管理内部聊天实例（`NormalChatInstance`/`HeartFlowChatInstance`），不再进行限额检查。限额检查的责任完全由调用方（即 `SubHeartflowManager` 中的相关方法，这些方法会使用内部存储的 `mai_state_info` 来获取限制）承担。
|
||||
- **状态转换机制** (由 `SubHeartflowManager` 驱动，更细致的说明):
|
||||
- **初始状态**: 新创建的 `SubHeartflow` 默认为 `ABSENT` 状态。
|
||||
- **`ABSENT` -> `CHAT` (激活闲聊)**:
|
||||
- **触发条件**: `Heartflow` 的主状态 (`MaiState`) 允许 `CHAT` 模式，且当前 `CHAT` 状态的子心流数量未达上限。
|
||||
- **判定机制**: `SubHeartflowManager` 中的 `evaluate_and_transition_subflows_by_llm` 方法调用大模型(LLM)。LLM 读取该群聊的近期内容和结合自身个性信息，判断是否"想"在该群开始聊天。
|
||||
- **执行**: 若 LLM 判断为是，且名额未满，`SubHeartflowManager` 调用 `change_chat_state(ChatState.CHAT)`。
|
||||
- **`CHAT` -> `FOCUSED` (激活专注)**:
|
||||
- **触发条件**: 子心流处于 `CHAT` 状态，其内部维护的"开屎热聊"概率 (`InterestChatting.start_hfc_probability`) 达到预设阈值（表示对当前聊天兴趣浓厚），同时 `Heartflow` 的主状态允许 `FOCUSED` 模式，且 `FOCUSED` 名额未满。
|
||||
- **判定机制**: `SubHeartflowManager` 中的 `evaluate_interest_and_promote` 方法定期检查满足条件的 `CHAT` 子心流。
|
||||
- **执行**: 若满足所有条件，`SubHeartflowManager` 调用 `change_chat_state(ChatState.FOCUSED)`。
|
||||
- **注意**: 无法从 `ABSENT` 直接跳到 `FOCUSED`，必须先经过 `CHAT`。
|
||||
- **`FOCUSED` -> `ABSENT` (退出专注)**:
|
||||
- **主要途径 (内部驱动)**: 在 `FOCUSED` 状态下运行的 `HeartFlowChatInstance` 连续多次决策为 `no_reply` (例如达到 5 次，次数可配)，它会通过回调函数 (`request_absent_transition`) 请求 `SubHeartflowManager` 将其状态**直接**设置为 `ABSENT`。
|
||||
- **其他途径 (外部驱动)**:
|
||||
- `Heartflow` 主状态变为 `OFFLINE`，`SubHeartflowManager` 强制所有子心流变为 `ABSENT`。
|
||||
- `SubHeartflowManager` 因 `FOCUSED` 名额超限 (`enforce_subheartflow_limits`) 或随机停用 (`randomly_deactivate_subflows`) 而将其设置为 `ABSENT`。
|
||||
- **`CHAT` -> `ABSENT` (退出闲聊)**:
|
||||
- **主要途径 (内部驱动)**: `SubHeartflowManager` 中的 `evaluate_and_transition_subflows_by_llm` 方法调用 LLM。LLM 读取群聊内容和结合自身状态，判断是否"不想"继续在此群闲聊。
|
||||
- **执行**: 若 LLM 判断为是，`SubHeartflowManager` 调用 `change_chat_state(ChatState.ABSENT)`。
|
||||
- **其他途径 (外部驱动)**:
|
||||
- `Heartflow` 主状态变为 `OFFLINE`。
|
||||
- `SubHeartflowManager` 因 `CHAT` 名额超限或随机停用。
|
||||
- **全局强制 `ABSENT`**: 当 `Heartflow` 的 `MaiState` 变为 `OFFLINE` 时，`SubHeartflowManager` 会调用所有子心流的 `change_chat_state(ChatState.ABSENT)`，强制它们全部停止活动。
|
||||
- **状态变更执行者**: `change_chat_state` 方法仅负责执行状态的切换和对应聊天实例的启停，不进行名额检查。名额检查的责任由 `SubHeartflowManager` 中的各个决策方法承担。
|
||||
- **最终清理**: 进入 `ABSENT` 状态的子心流不会立即被删除，只有在 `ABSENT` 状态持续一小时 (`INACTIVE_THRESHOLD_SECONDS`) 后，才会被后台清理任务 (`cleanup_inactive_subheartflows`) 删除。
|
||||
|
||||
## 3. 聊天实例详解 (Chat Instances Explained)
|
||||
|
||||
@@ -219,77 +239,3 @@ c HeartFChatting工作方式
|
||||
self.observations.append(observation)
|
||||
```
|
||||
|
||||
### 5.2. 配置参数 (Key Parameters)
|
||||
- `sub_heart_flow_stop_time`: (已废弃，现在由 `INACTIVE_THRESHOLD_SECONDS` in `subheartflow_manager.py` 控制) 子心流在 `ABSENT` 状态持续多久后被后台任务清理，默认为 3600 秒 (1 小时)。
|
||||
- `sub_heart_flow_freeze_time`: 子心流冻结时间 (当前文档未明确体现，可能需要审阅代码确认)。
|
||||
- `heart_flow_update_interval`: 主心流更新其状态或执行管理操作的频率 (需要审阅 `Heartflow` 代码确认)。
|
||||
|
||||
### 5.3. 之后可以做的 (Future Work)
|
||||
- **智能化 MaiState 状态转换**:
|
||||
- 当前 `MaiState` (整体状态，如 `OFFLINE`, `NORMAL_CHAT` 等) 的转换逻辑 (`MaiStateManager`) 较为简单，主要依赖时间和随机性。
|
||||
- 未来的计划是让主心流 (`Heartflow`) 负责决策自身的 `MaiState`。
|
||||
- 该决策将综合考虑以下信息：
|
||||
- 各个子心流 (`SubHeartflow`) 的活动状态和信息摘要。
|
||||
- 主心流自身的状态和历史信息。
|
||||
- (可能) 结合预设的日程安排 (Schedule) 信息。
|
||||
- 目标是让 Mai 的整体状态变化更符合逻辑和上下文。 (计划在 064 实现)
|
||||
|
||||
- **参数化与动态调整聊天行为**:
|
||||
- 将 `NormalChatInstance` 和 `HeartFlowChatInstance` 中的关键行为参数（例如：回复概率、思考频率、兴趣度阈值、状态转换条件等）提取出来，使其更易于配置。
|
||||
- 允许每个 `SubHeartflow` (即每个聊天场景) 拥有其独立的参数配置，实现"千群千面"。
|
||||
- 开发机制，使得这些参数能够被动态调整：
|
||||
- 基于外部反馈：例如，根据用户评价（"话太多"或"太冷淡"）调整回复频率。
|
||||
- 基于环境分析：例如，根据群消息的活跃度自动调整参与度。
|
||||
- 基于学习：通过分析历史交互数据，优化特定群聊下的行为模式。
|
||||
- 目标是让 Mai 在不同群聊中展现出更适应环境、更个性化的交互风格。
|
||||
|
||||
- **动态 Prompt 生成与人格塑造**:
|
||||
- 当前 Prompt (提示词) 相对静态。计划实现动态或半结构化的 Prompt 生成。
|
||||
- Prompt 内容可根据以下因素调整：
|
||||
- **人格特质**: 通过参数化配置（如友善度、严谨性等），影响 Prompt 的措辞、语气和思考倾向，塑造更稳定和独特的人格。
|
||||
- **当前情绪**: 将实时情绪状态融入 Prompt，使回复更符合当下心境。
|
||||
- 目标：提升 `HeartFlowChatInstance` (HFC) 回复的多样性、一致性和真实感。
|
||||
- 前置：需要重构 Prompt 构建逻辑，可能引入 `PromptBuilder` 并提供标准接口 (认为是必须步骤)。
|
||||
|
||||
- **扩展观察系统 (Observation System)**:
|
||||
- 目前主要依赖 `ChattingObservation` 获取消息。
|
||||
- 计划引入更多 `Observation` 类型，为 `SubHeartflow` 提供更丰富的上下文：
|
||||
- Mai 的全局状态 (`MaiStateInfo`)。
|
||||
- `SubHeartflow` 自身的聊天状态 (`ChatStateInfo`) 和参数配置。
|
||||
- Mai 的系统配置、连接平台信息。
|
||||
- 其他相关聊天或系统的聚合信息。
|
||||
- 目标：让 `SubHeartflow` 基于更全面的信息进行决策。
|
||||
|
||||
- **增强工具调用能力 (Enhanced Tool Usage)**:
|
||||
- 扩展 `HeartFlowChatInstance` (HFC) 可用的工具集。
|
||||
- 考虑引入"元工具"或分层工具机制，允许 HFC 在需要时（如深度思考）访问更强大的工具，例如：
|
||||
- 修改自身或其他 `SubHeartflow` 的聊天参数。
|
||||
- 请求改变 Mai 的全局状态 (`MaiState`)。
|
||||
- 管理日程或执行更复杂的分析任务。
|
||||
- 目标：提升 HFC 的自主决策和行动能力，即使会增加一定的延迟。
|
||||
|
||||
- **基于历史学习的行为模式应用**:
|
||||
- **学习**: 分析过往聊天记录，提取和学习具体的行为模式（如特定梗的用法、情境化回应风格等）。可能需要专门的分析模块。
|
||||
- **存储与匹配**: 需要有效的方法存储学习到的行为模式，并开发强大的 **匹配** 机制，在运行时根据当前情境检索最合适的模式。**(匹配的准确性是关键)**
|
||||
- **应用与评估**: 将匹配到的行为模式融入 HFC 的决策和回复生成（例如，将其整合进 Prompt）。之后需评估该行为模式应用的实际效果。
|
||||
- **人格塑造**: 通过学习到的实际行为来动态塑造人格，作为静态人设描述的补充或替代，使其更生动自然。
|
||||
|
||||
- **标准化人设生成 (Standardized Persona Generation)**:
|
||||
- **目标**: 解决手动配置 `人设` 文件缺乏标准、难以全面描述个性的问题，并生成更丰富、可操作的人格资源。
|
||||
- **方法**: 利用大型语言模型 (LLM) 辅助生成标准化的、结构化的人格**资源包**。
|
||||
- **生成内容**: 不仅生成描述性文本（替代现有 `individual` 配置），还可以同时生成与该人格配套的：
|
||||
- **相关工具 (Tools)**: 该人格倾向于使用的工具或能力。
|
||||
- **初始记忆/知识库 (Memories/Knowledge)**: 定义其背景和知识基础。
|
||||
- **核心行为模式 (Core Behavior Patterns)**: 预置一些典型的行为方式，可作为行为学习的起点。
|
||||
- **实现途径**:
|
||||
- 通过与 LLM 的交互式对话来定义和细化人格及其配套资源。
|
||||
- 让 LLM 分析提供的文本材料（如小说、背景故事）来提取人格特质和相关信息。
|
||||
- **优势**: 替代易出错且标准不一的手动配置，生成更丰富、一致、包含配套资源且易于系统理解和应用的人格包。
|
||||
|
||||
- **优化表情包处理与理解 (Enhanced Emoji Handling and Understanding)**:
|
||||
- **面临挑战**:
|
||||
- **历史记录表示**: 如何在聊天历史中有效表示表情包，供 LLM 理解。
|
||||
- **语义理解**: 如何让 LLM 准确把握表情包的含义、情感和语境。
|
||||
- **场景判断与选择**: 如何让 LLM 判断何时适合使用表情包，并选择最贴切的一个。
|
||||
- **目标**: 提升 Mai 理解和运用表情包的能力，使交互更自然生动。
|
||||
- **说明**: 可能需要较多时间进行数据处理和模型调优，但对改善体验潜力巨大。
|
||||
@@ -1,120 +0,0 @@
|
||||
# HeartFChatting 逻辑详解
|
||||
|
||||
`HeartFChatting` 类是心流系统（Heart Flow System）中负责**专注聊天**（`ChatState.FOCUSED`）的核心组件。它的主要职责是在特定的聊天流 (`stream_id`) 中，通过一个持续的 **思考(Think)-规划(Plan)-执行(Execute)** 循环来模拟更自然、更深入的对话交互。当关联的 `SubHeartflow` 状态切换为 `FOCUSED` 时，`HeartFChatting` 实例会被创建并启动；当状态切换为其他（如 `CHAT` 或 `ABSENT`）时，它会被关闭。
|
||||
|
||||
## 1. 初始化 (`__init__`, `_initialize`)
|
||||
|
||||
- **依赖注入**: 在创建时，`HeartFChatting` 接收 `chat_id`（即 `stream_id`）、关联的 `SubMind` 实例以及 `Observation` 实例列表作为参数。
|
||||
- **核心组件**: 内部初始化了几个关键组件：
|
||||
- `ActionManager`: 管理当前循环可用的动作（如回复文本、回复表情、不回复）。
|
||||
- `HeartFCGenerator`: (`self.gpt_instance`) 用于生成回复文本。
|
||||
- `ToolUser`: (`self.tool_user`) 用于执行 `SubMind` 可能请求的工具调用（虽然在此类中主要用于获取工具定义，实际执行由 `SubMind` 完成）。
|
||||
- `HeartFCSender`: (`self.heart_fc_sender`) 专门负责处理消息发送逻辑，包括管理"正在思考"状态。
|
||||
- `LLMRequest`: (`self.planner_llm`) 配置用于执行规划任务的大语言模型请求。
|
||||
- **状态变量**:
|
||||
- `_initialized`: 标记是否完成懒初始化。
|
||||
- `_processing_lock`: 异步锁，确保同一时间只有一个完整的"思考-规划-执行"周期在运行。
|
||||
- `_loop_active`: 标记主循环是否正在运行。
|
||||
- `_loop_task`: 指向主循环的 `asyncio.Task` 对象。
|
||||
- `_cycle_history`: 一个双端队列 (`deque`)，用于存储最近若干次循环的信息 (`CycleInfo`)。
|
||||
- `_current_cycle`: 当前正在执行的循环信息 (`CycleInfo`)。
|
||||
- **懒初始化 (`_initialize`)**:
|
||||
- 在首次需要访问 `ChatStream` 前调用（通常在 `start` 方法中）。
|
||||
- 根据 `stream_id` 从 `chat_manager` 获取对应的 `ChatStream` 实例。
|
||||
- 更新日志前缀，使用聊天流的名称以提高可读性。
|
||||
|
||||
## 2. 生命周期管理 (`start`, `shutdown`)
|
||||
|
||||
- **启动 (`start`)**:
|
||||
- 外部调用此方法来启动 `HeartFChatting` 的工作流程。
|
||||
- 内部调用 `_start_loop_if_needed` 来安全地启动主循环任务 (`_hfc_loop`)。
|
||||
- **关闭 (`shutdown`)**:
|
||||
- 外部调用此方法来优雅地停止 `HeartFChatting`。
|
||||
- 取消正在运行的主循环任务 (`_loop_task`)。
|
||||
- 清理内部状态（如 `_loop_active`, `_loop_task`）。
|
||||
- 释放可能被持有的处理锁 (`_processing_lock`)。
|
||||
|
||||
## 3. 核心循环 (`_hfc_loop`)
|
||||
|
||||
`_hfc_loop` 是 `HeartFChatting` 的心脏，它以异步方式无限期运行（直到被 `shutdown` 取消），不断执行以下步骤：
|
||||
|
||||
1. **创建循环记录**: 初始化一个新的 `CycleInfo` 对象来记录本次循环的详细信息（ID、开始时间、计时器、动作、思考内容等）。
|
||||
2. **获取处理锁**: 使用 `_processing_lock` 确保并发安全。
|
||||
3. **执行思考-规划-执行**: 调用 `_think_plan_execute_loop` 方法。
|
||||
4. **处理循环延迟**: 根据本次循环是否执行了实际动作以及循环耗时，智能地引入短暂的 `asyncio.sleep`，防止 CPU 空转或过于频繁的循环。
|
||||
5. **记录循环信息**: 将完成的 `CycleInfo` 存入 `_cycle_history`，并记录详细的日志，包括循环耗时和各阶段计时。
|
||||
|
||||
## 4. 思考-规划-执行周期 (`_think_plan_execute_loop`)
|
||||
|
||||
这是每个循环内部的核心逻辑，按顺序执行：
|
||||
|
||||
### 4.1. 思考阶段 (`_get_submind_thinking`)
|
||||
|
||||
1. **触发观察**: 调用关联的 `Observation` 实例的 `observe()` 方法，使其更新对环境（如聊天室新消息）的观察。
|
||||
2. **触发子思维**: 调用关联的 `SubMind` 实例的 `do_thinking_before_reply()` 方法。**关键**: 会将上一个循环的 `CycleInfo` 传递给 `SubMind`，使其了解上一次行动的决策、理由以及是否发生了重新规划，从而实现更连贯的思考。
|
||||
3. **获取思考结果**: `SubMind` 返回其当前的内心想法 (`current_mind`)。
|
||||
|
||||
### 4.2. 规划阶段 (`_planner`)
|
||||
|
||||
1. **输入**: 获取 `SubMind` 的当前想法 (`current_mind`)、`SubMind` 通过工具调用收集到的结构化信息 (`structured_info`) 以及观察到的最新消息。
|
||||
2. **构建提示词**: 调用 `_build_planner_prompt` 方法，将上述信息以及机器人个性、当前可用动作等整合进一个专门为规划器设计的提示词中。
|
||||
3. **定义动作工具**: 使用 `ActionManager.get_planner_tool_definition()` 获取当前可用动作（如 `no_reply`, `text_reply`, `emoji_reply`）的 JSON Schema，将其作为 "工具" 提供给 LLM。
|
||||
4. **调用 LLM**: 使用 `self.planner_llm` 向大模型发送请求，**强制要求**模型调用 `decide_reply_action` 这个"工具"，并根据提示词内容决定使用哪个动作以及相应的参数（如 `reasoning`, `emoji_query`）。
|
||||
5. **处理 LLM 响应**: 使用 `process_llm_tool_response` 解析 LLM 返回的工具调用请求，提取出决策的动作 (`action`)、理由 (`reasoning`) 和可能的表情查询 (`emoji_query`)。
|
||||
6. **检查新消息与重新规划**:
|
||||
- 调用 `_check_new_messages` 检查自规划阶段开始以来是否有新消息。
|
||||
- 如果检测到新消息，有一定概率（当前为 30%）触发**重新规划**。这会再次调用 `_planner`，但会传入一个特殊的提示词片段（通过 `_build_replan_prompt` 生成），告知 LLM 它之前的决策以及现在需要重新考虑。
|
||||
7. **输出**: 返回一个包含最终决策结果（`action`, `reasoning`, `emoji_query` 等）的字典。如果 LLM 调用或解析失败，`action` 会被设为 "error"。
|
||||
|
||||
### 4.3. 执行阶段 (`_handle_action`)
|
||||
|
||||
根据规划阶段返回的 `action`，分派到不同的处理方法：
|
||||
|
||||
- **`_handle_text_reply` (文本回复)**:
|
||||
1. `_get_anchor_message`: 获取一个用于回复的锚点消息。**注意**: 当前实现是创建一个系统触发的占位符消息作为锚点，而不是实际观察到的最后一条消息。
|
||||
2. `_create_thinking_message`: 调用 `HeartFCSender` 的 `register_thinking` 方法，标记机器人开始思考，并获取一个 `thinking_id`。
|
||||
3. `_replier_work`: 调用回复器生成回复内容。
|
||||
4. `_sender`: 调用发送器发送生成的文本和可能的表情。
|
||||
- **`_handle_emoji_reply` (仅表情回复)**:
|
||||
1. 获取锚点消息。
|
||||
2. `_handle_emoji`: 获取表情图片并调用 `HeartFCSender` 发送。
|
||||
- **`_handle_no_reply` (不回复)**:
|
||||
1. 记录不回复的理由。
|
||||
2. `_wait_for_new_message`: 进入等待状态，直到关联的 `Observation` 检测到新消息或超时（当前 300 秒）。
|
||||
|
||||
## 5. 回复器逻辑 (`_replier_work`)
|
||||
|
||||
- **输入**: 规划器给出的回复理由 (`reason`)、锚点消息 (`anchor_message`)、思考ID (`thinking_id`)，以及通过 `self.sub_mind` 获取的结构化信息和当前想法。
|
||||
- **处理**: 调用 `self.gpt_instance` (`HeartFCGenerator`) 的 `generate_response` 方法。这个方法负责构建最终的生成提示词（结合思考、理由、上下文等），调用 LLM 生成回复文本。
|
||||
- **输出**: 返回一个包含多段回复文本的列表 (`List[str]`)，如果生成失败则返回 `None`。
|
||||
|
||||
## 6. 发送器逻辑 (`_sender`, `_create_thinking_message`, `_send_response_messages`, `_handle_emoji`)
|
||||
|
||||
`HeartFChatting` 类本身不直接处理 WebSocket 发送，而是将发送任务委托给 `HeartFCSender` 实例 (`self.heart_fc_sender`)。
|
||||
|
||||
- **`_create_thinking_message`**: 准备一个 `MessageThinking` 对象，并调用 `sender.register_thinking(thinking_message)`。
|
||||
- **`_send_response_messages`**:
|
||||
- 检查对应的 `thinking_id` 是否仍然有效（通过 `sender.get_thinking_start_time`）。
|
||||
- 遍历 `_replier_work` 返回的回复文本列表 (`response_set`)。
|
||||
- 为每一段文本创建一个 `MessageSending` 对象。
|
||||
- 调用 `sender.type_and_send_message(bot_message)` 来发送消息。`HeartFCSender` 内部会处理模拟打字延迟、实际发送和消息存储。
|
||||
- 发送完成后，调用 `sender.complete_thinking(chat_id, thinking_id)` 来清理思考状态。
|
||||
- 记录实际发送的消息 ID 到 `CycleInfo` 中。
|
||||
- **`_handle_emoji`**:
|
||||
- 使用 `emoji_manager` 根据 `emoji_query` 获取表情图片路径。
|
||||
- 将图片转为 Base64。
|
||||
- 创建 `MessageSending` 对象（标记为 `is_emoji=True`）。
|
||||
- 调用 `sender.send_and_store(bot_message)` 来发送并存储表情消息（这个方法不涉及思考状态）。
|
||||
|
||||
## 7. 循环信息记录 (`CycleInfo`)
|
||||
|
||||
- `CycleInfo` 类用于记录每一次思考-规划-执行循环的详细信息，包括：
|
||||
- 循环 ID (`cycle_id`)
|
||||
- 开始和结束时间 (`start_time`, `end_time`)
|
||||
- 是否执行了实际动作 (`action_taken`)
|
||||
- 决策的动作类型 (`action_type`) 和理由 (`reasoning`)
|
||||
- 各阶段的耗时计时器 (`timers`)
|
||||
- 关联的思考消息 ID (`thinking_id`)
|
||||
- 是否发生了重新规划 (`replanned`)
|
||||
- 详细的响应信息 (`response_info`)，包括生成的文本、表情查询、锚点消息 ID、实际发送的消息 ID 列表以及 `SubMind` 的思考内容。
|
||||
- `HeartFChatting` 维护一个 `_cycle_history` 队列来保存最近的循环记录，方便调试和分析。
|
||||
@@ -37,7 +37,7 @@ class MaiState(enum.Enum):
|
||||
return 1000
|
||||
|
||||
if self == MaiState.OFFLINE:
|
||||
return 10
|
||||
return 0
|
||||
elif self == MaiState.PEEKING:
|
||||
return 30
|
||||
elif self == MaiState.NORMAL_CHAT:
|
||||
@@ -51,7 +51,7 @@ class MaiState(enum.Enum):
|
||||
return 1000
|
||||
|
||||
if self == MaiState.OFFLINE:
|
||||
return 10
|
||||
return 0
|
||||
elif self == MaiState.PEEKING:
|
||||
return 20
|
||||
elif self == MaiState.NORMAL_CHAT:
|
||||
|
||||
@@ -154,7 +154,7 @@ class HeartFChatting:
|
||||
其生命周期现在由其关联的 SubHeartflow 的 FOCUSED 状态控制。
|
||||
"""
|
||||
|
||||
CONSECUTIVE_NO_REPLY_THRESHOLD = 1 # 连续不回复的阈值
|
||||
CONSECUTIVE_NO_REPLY_THRESHOLD = 5 # 连续不回复的阈值
|
||||
|
||||
def __init__(
|
||||
self,
|
||||
|
||||
92
src/plugins/heartFC_chat/heartFC_chatting_logic.md
Normal file
92
src/plugins/heartFC_chat/heartFC_chatting_logic.md
Normal file
@@ -0,0 +1,92 @@
|
||||
# HeartFChatting 逻辑详解
|
||||
|
||||
`HeartFChatting` 类是心流系统（Heart Flow System）中实现**专注聊天**（`ChatState.FOCUSED`）功能的核心。顾名思义，其职责乃是在特定聊天流（`stream_id`）中，模拟更为连贯深入之对话。此非凭空臆造，而是依赖一个持续不断的 **思考(Think)-规划(Plan)-执行(Execute)** 循环。当其所系的 `SubHeartflow` 进入 `FOCUSED` 状态时，便会创建并启动 `HeartFChatting` 实例；若状态转为他途（譬如 `CHAT` 或 `ABSENT`），则会将其关闭。
|
||||
|
||||
## 1. 初始化简述 (`__init__`, `_initialize`)
|
||||
|
||||
创生之初，`HeartFChatting` 需注入若干关键之物：`chat_id`（亦即 `stream_id`）、关联的 `SubMind` 实例，以及 `Observation` 实例（用以观察环境）。
|
||||
|
||||
其内部核心组件包括：
|
||||
|
||||
- `ActionManager`: 管理当前循环可选之策（如：不应、言语、表情）。
|
||||
- `HeartFCGenerator` (`self.gpt_instance`): 专司生成回复文本之职。
|
||||
- `ToolUser` (`self.tool_user`): 虽主要用于获取工具定义，然亦备 `SubMind` 调用之需（实际执行由 `SubMind` 操持）。
|
||||
- `HeartFCSender` (`self.heart_fc_sender`): 负责消息发送诸般事宜，含"正在思考"之态。
|
||||
- `LLMRequest` (`self.planner_llm`): 配置用于执行"规划"任务的大语言模型。
|
||||
|
||||
*初始化过程采取懒加载策略，仅在首次需要访问 `ChatStream` 时（通常在 `start` 方法中）进行。*
|
||||
|
||||
## 2. 生命周期 (`start`, `shutdown`)
|
||||
|
||||
- **启动 (`start`)**: 外部调用此法，以启 `HeartFChatting` 之流程。内部会安全地启动主循环任务。
|
||||
- **关闭 (`shutdown`)**: 外部调用此法，以止其运行。会取消主循环任务，清理状态，并释放锁。
|
||||
|
||||
## 3. 核心循环 (`_hfc_loop`) 与 循环记录 (`CycleInfo`)
|
||||
|
||||
`_hfc_loop` 乃 `HeartFChatting` 之脉搏，以异步方式不舍昼夜运行（直至 `shutdown` 被调用）。其核心在于周而复始地执行 **思考-规划-执行** 之周期。
|
||||
|
||||
每一轮循环，皆会创建一个 `CycleInfo` 对象。此对象犹如史官，详细记载该次循环之点滴：
|
||||
|
||||
- **身份标识**: 循环 ID (`cycle_id`)。
|
||||
- **时间轨迹**: 起止时刻 (`start_time`, `end_time`)。
|
||||
- **行动细节**: 是否执行动作 (`action_taken`)、动作类型 (`action_type`)、决策理由 (`reasoning`)。
|
||||
- **耗时考量**: 各阶段计时 (`timers`)。
|
||||
- **关联信息**: 思考消息 ID (`thinking_id`)、是否重新规划 (`replanned`)、详尽响应信息 (`response_info`，含生成文本、表情、锚点、实际发送ID、`SubMind`思考等)。
|
||||
|
||||
这些 `CycleInfo` 被存入一个队列 (`_cycle_history`)，近者得观。此记录不仅便于调试，更关键的是，它会作为**上下文信息**传递给下一次循环的"思考"阶段，使得 `SubMind` 能鉴往知来，做出更连贯的决策。
|
||||
|
||||
*循环间会根据执行情况智能引入延迟，避免空耗资源。*
|
||||
|
||||
## 4. 思考-规划-执行周期 (`_think_plan_execute_loop`)
|
||||
|
||||
此乃 `HeartFChatting` 最核心的逻辑单元，每一循环皆按序执行以下三步：
|
||||
|
||||
### 4.1. 思考 (`_get_submind_thinking`)
|
||||
|
||||
* **第一步：观察环境**: 调用 `Observation` 的 `observe()` 方法，感知聊天室是否有新动态（如新消息）。
|
||||
* **第二步：触发子思维**: 调用关联 `SubMind` 的 `do_thinking_before_reply()` 方法。
|
||||
* **关键点**: 会将**上一个循环**的 `CycleInfo` 传入，让 `SubMind` 了解上次行动的决策、理由及是否重新规划，从而实现"承前启后"的思考。
|
||||
* `SubMind` 在此阶段不仅进行思考，还可能**调用其配置的工具**来收集信息。
|
||||
* **第三步：获取成果**: `SubMind` 返回两部分重要信息：
|
||||
1. 当前的内心想法 (`current_mind`)。
|
||||
2. 通过工具调用收集到的结构化信息 (`structured_info`)。
|
||||
|
||||
### 4.2. 规划 (`_planner`)
|
||||
|
||||
* **输入**: 接收来自"思考"阶段的 `current_mind` 和 `structured_info`，以及"观察"到的最新消息。
|
||||
* **目标**: 基于当前想法、已知信息、聊天记录、机器人个性以及可用动作，决定**接下来要做什么**。
|
||||
* **决策方式**:
|
||||
1. 构建一个精心设计的提示词 (`_build_planner_prompt`)。
|
||||
2. 获取 `ActionManager` 中定义的当前可用动作（如 `no_reply`, `text_reply`, `emoji_reply`）作为"工具"选项。
|
||||
3. 调用大语言模型 (`self.planner_llm`)，**强制**其选择一个动作"工具"并提供理由。可选动作包括：
|
||||
* `no_reply`: 不回复（例如，自己刚说过话或对方未回应）。
|
||||
* `text_reply`: 发送文本回复。
|
||||
* `emoji_reply`: 仅发送表情。
|
||||
* 文本回复亦可附带表情（通过 `emoji_query` 参数指定）。
|
||||
* **动态调整（重新规划）**:
|
||||
* 在做出初步决策后，会检查自规划开始后是否有新消息 (`_check_new_messages`)。
|
||||
* 若有新消息，则有一定概率触发**重新规划**。此时会再次调用规划器，但提示词会包含之前决策的信息，要求 LLM 重新考虑。
|
||||
* **输出**: 返回一个包含最终决策的字典，主要包括：
|
||||
* `action`: 选定的动作类型。
|
||||
* `reasoning`: 做出此决策的理由。
|
||||
* `emoji_query`: (可选) 如果需要发送表情，指定表情的主题。
|
||||
|
||||
### 4.3. 执行 (`_handle_action`)
|
||||
|
||||
* **输入**: 接收"规划"阶段输出的 `action`、`reasoning` 和 `emoji_query`。
|
||||
* **行动**: 根据 `action` 的类型，分派到不同的处理函数：
|
||||
* **文本回复 (`_handle_text_reply`)**:
|
||||
1. 获取锚点消息（当前实现为系统触发的占位符）。
|
||||
2. 调用 `HeartFCSender` 的 `register_thinking` 标记开始思考。
|
||||
3. 调用 `HeartFCGenerator` (`_replier_work`) 生成回复文本。**注意**: 回复器逻辑 (`_replier_work`) 本身并非独立复杂组件，主要是调用 `HeartFCGenerator` 完成文本生成。
|
||||
4. 调用 `HeartFCSender` (`_sender`) 发送生成的文本和可能的表情。**注意**: 发送逻辑 (`_sender`, `_send_response_messages`, `_handle_emoji`) 同样委托给 `HeartFCSender` 实例处理，包含模拟打字、实际发送、存储消息等细节。
|
||||
* **仅表情回复 (`_handle_emoji_reply`)**:
|
||||
1. 获取锚点消息。
|
||||
2. 调用 `HeartFCSender` 发送表情。
|
||||
* **不回复 (`_handle_no_reply`)**:
|
||||
1. 记录理由。
|
||||
2. 进入等待状态 (`_wait_for_new_message`)，直到检测到新消息或超时（目前300秒），期间会监听关闭信号。
|
||||
|
||||
## 总结
|
||||
|
||||
`HeartFChatting` 通过 **观察 -> 思考（含工具）-> 规划 -> 执行** 的闭环，并利用 `CycleInfo` 进行上下文传递，实现了更加智能和连贯的专注聊天行为。其核心在于利用 `SubMind` 进行深度思考和信息收集，再通过 LLM 规划器进行决策，最后由 `HeartFCSender` 可靠地执行消息发送任务。
|
||||
Reference in New Issue
Block a user