From 20c11c0e0d8dc1e241207ccd66cb647708e0787f Mon Sep 17 00:00:00 2001 From: SengokuCola <1026294844@qq.com> Date: Sun, 27 Apr 2025 00:43:53 +0800 Subject: [PATCH] =?UTF-8?q?doc=EF=BC=9A=E6=9B=B4=E6=96=B0=E4=BA=86?= =?UTF-8?q?=E5=BE=88=E5=A4=9Adoc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- changelogs/changelog.md | 75 +++++++++++ src/heart_flow/0.6.3TODO.md | 48 +++++++ src/heart_flow/0.6Bing.md | 84 ++++++++++++ src/heart_flow/README.md | 104 ++++----------- src/heart_flow/heartFC_chatting_logic.md | 120 ------------------ src/heart_flow/mai_state_manager.py | 4 +- src/plugins/heartFC_chat/heartFC_chat.py | 2 +- .../heartFC_chat/heartFC_chatting_logic.md | 92 ++++++++++++++ 8 files changed, 327 insertions(+), 202 deletions(-) create mode 100644 src/heart_flow/0.6.3TODO.md create mode 100644 src/heart_flow/0.6Bing.md delete mode 100644 src/heart_flow/heartFC_chatting_logic.md create mode 100644 src/plugins/heartFC_chat/heartFC_chatting_logic.md diff --git a/changelogs/changelog.md b/changelogs/changelog.md index 0ddb486bf..4fed6fb17 100644 --- a/changelogs/changelog.md +++ b/changelogs/changelog.md @@ -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 ### 摘要 diff --git a/src/heart_flow/0.6.3TODO.md b/src/heart_flow/0.6.3TODO.md new file mode 100644 index 000000000..4048fec8f --- /dev/null +++ b/src/heart_flow/0.6.3TODO.md @@ -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，却不回复，需要处理一下 diff --git a/src/heart_flow/0.6Bing.md b/src/heart_flow/0.6Bing.md new file mode 100644 index 000000000..6af057e29 --- /dev/null +++ b/src/heart_flow/0.6Bing.md @@ -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 和人格配置生成背景知识的功能。 + - 这些知识应符合角色的行为风格和可能的经历。 + - 作为一种"冷启动"或丰富角色深度的方式。 \ No newline at end of file diff --git a/src/heart_flow/README.md b/src/heart_flow/README.md index 7f6906aea..fdb3a1928 100644 --- a/src/heart_flow/README.md +++ b/src/heart_flow/README.md @@ -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 理解和运用表情包的能力，使交互更自然生动。 - - **说明**: 可能需要较多时间进行数据处理和模型调优，但对改善体验潜力巨大。 \ No newline at end of file diff --git a/src/heart_flow/heartFC_chatting_logic.md b/src/heart_flow/heartFC_chatting_logic.md deleted file mode 100644 index 1e178a6ff..000000000 --- a/src/heart_flow/heartFC_chatting_logic.md +++ /dev/null @@ -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` 队列来保存最近的循环记录，方便调试和分析。 diff --git a/src/heart_flow/mai_state_manager.py b/src/heart_flow/mai_state_manager.py index ee5cd95ee..4341e3ded 100644 --- a/src/heart_flow/mai_state_manager.py +++ b/src/heart_flow/mai_state_manager.py @@ -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: diff --git a/src/plugins/heartFC_chat/heartFC_chat.py b/src/plugins/heartFC_chat/heartFC_chat.py index 4f96353fd..903667b41 100644 --- a/src/plugins/heartFC_chat/heartFC_chat.py +++ b/src/plugins/heartFC_chat/heartFC_chat.py @@ -154,7 +154,7 @@ class HeartFChatting: 其生命周期现在由其关联的 SubHeartflow 的 FOCUSED 状态控制。 """ - CONSECUTIVE_NO_REPLY_THRESHOLD = 1 # 连续不回复的阈值 + CONSECUTIVE_NO_REPLY_THRESHOLD = 5 # 连续不回复的阈值 def __init__( self, diff --git a/src/plugins/heartFC_chat/heartFC_chatting_logic.md b/src/plugins/heartFC_chat/heartFC_chatting_logic.md new file mode 100644 index 000000000..6d51c978b --- /dev/null +++ b/src/plugins/heartFC_chat/heartFC_chatting_logic.md @@ -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` 可靠地执行消息发送任务。