refactor(cache): 重构工具缓存机制并优化LLM请求重试逻辑
将工具缓存的实现从`ToolExecutor`的装饰器模式重构为直接集成。缓存逻辑被移出`cache_manager.py`并整合进`ToolExecutor.execute_tool_call`方法中，简化了代码结构并使其更易于维护。 主要变更： - 从`cache_manager.py`中移除了`wrap_tool_executor`函数。 - 在`tool_use.py`中，`execute_tool_call`现在包含完整的缓存检查和设置逻辑。 - 调整了`llm_models/utils_model.py`中的LLM请求逻辑，为模型生成的空回复或截断响应增加了内部重试机制，增强了稳定性。 - 清理了项目中未使用的导入和过时的文档文件，以保持代码库的整洁。
This commit is contained in:
minecraft1024a
@@ -1,89 +0,0 @@
|
||||
# 💻 Command组件详解
|
||||
|
||||
## 📖 什么是Command
|
||||
|
||||
Command是直接响应用户明确指令的组件，与Action不同，Command是**被动触发**的，当用户输入特定格式的命令时立即执行。
|
||||
|
||||
Command通过正则表达式匹配用户输入，提供确定性的功能服务。
|
||||
|
||||
### 🎯 Command的特点
|
||||
|
||||
- 🎯 **确定性执行**：匹配到命令立即执行，无随机性
|
||||
- ⚡ **即时响应**：用户主动触发，快速响应
|
||||
- 🔍 **正则匹配**：通过正则表达式精确匹配用户输入
|
||||
- 🛑 **拦截控制**：可以控制是否阻止消息继续处理
|
||||
- 📝 **参数解析**：支持从用户输入中提取参数
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Command组件的基本结构
|
||||
|
||||
首先，Command组件需要继承自`BaseCommand`类，并实现必要的方法。
|
||||
|
||||
```python
|
||||
class ExampleCommand(BaseCommand):
|
||||
command_name = "example" # 命令名称，作为唯一标识符
|
||||
command_description = "这是一个示例命令" # 命令描述
|
||||
command_pattern = r"" # 命令匹配的正则表达式
|
||||
|
||||
async def execute(self) -> Tuple[bool, Optional[str], bool]:
|
||||
"""
|
||||
执行Command的主要逻辑
|
||||
|
||||
Returns:
|
||||
Tuple[bool, str, bool]:
|
||||
- 第一个bool表示是否成功执行
|
||||
- 第二个str是执行结果消息
|
||||
- 第三个bool表示是否需要阻止消息继续处理
|
||||
"""
|
||||
# ---- 执行命令的逻辑 ----
|
||||
return True, "执行成功", False
|
||||
```
|
||||
**`command_pattern`**: 该Command匹配的正则表达式，用于精确匹配用户输入。
|
||||
|
||||
请注意：如果希望能获取到命令中的参数，请在正则表达式中使用有命名的捕获组，例如`(?P<param_name>pattern)`。
|
||||
|
||||
这样在匹配时，内部实现可以使用`re.match.groupdict()`方法获取到所有捕获组的参数，并以字典的形式存储在`self.matched_groups`中。
|
||||
|
||||
### 匹配样例
|
||||
假设我们有一个命令`/example param1=value1 param2=value2`，对应的正则表达式可以是：
|
||||
|
||||
```python
|
||||
class ExampleCommand(BaseCommand):
|
||||
command_name = "example"
|
||||
command_description = "这是一个示例命令"
|
||||
command_pattern = r"/example (?P<param1>\w+) (?P<param2>\w+)"
|
||||
|
||||
async def execute(self) -> Tuple[bool, Optional[str], bool]:
|
||||
# 获取匹配的参数
|
||||
param1 = self.matched_groups.get("param1")
|
||||
param2 = self.matched_groups.get("param2")
|
||||
|
||||
# 执行逻辑
|
||||
return True, f"参数1: {param1}, 参数2: {param2}", False
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Command 内置方法说明
|
||||
```python
|
||||
class BaseCommand:
|
||||
def get_config(self, key: str, default=None):
|
||||
"""获取插件配置值，使用嵌套键访问"""
|
||||
|
||||
async def send_text(self, content: str, reply_to: str = "") -> bool:
|
||||
"""发送回复消息"""
|
||||
|
||||
async def send_type(self, message_type: str, content: str, display_message: str = "", typing: bool = False, reply_to: str = "") -> bool:
|
||||
"""发送指定类型的回复消息到当前聊天环境"""
|
||||
|
||||
async def send_command(self, command_name: str, args: Optional[dict] = None, display_message: str = "", storage_message: bool = True) -> bool:
|
||||
"""发送命令消息"""
|
||||
|
||||
async def send_emoji(self, emoji_base64: str) -> bool:
|
||||
"""发送表情包"""
|
||||
|
||||
async def send_image(self, image_base64: str) -> bool:
|
||||
"""发送图片"""
|
||||
```
|
||||
具体参数与用法参见`BaseCommand`基类的定义。
|
||||
@@ -9,7 +9,7 @@
|
||||
## 组件功能详解
|
||||
|
||||
- [🧱 Action组件详解](action-components.md) - 掌握最核心的Action组件
|
||||
- [💻 Command组件详解](command-components.md) - 学习直接响应命令的组件
|
||||
- [💻 Command组件详解](PLUS_COMMAND_GUIDE.md) - 学习直接响应命令的组件
|
||||
- [🔧 Tool组件详解](tool-components.md) - 了解如何扩展信息获取能力
|
||||
- [⚙️ 配置文件系统指南](configuration-guide.md) - 学会使用自动生成的插件配置文件
|
||||
- [📄 Manifest系统指南](manifest-guide.md) - 了解插件元数据管理和配置架构
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## 📖 什么是工具
|
||||
|
||||
工具是MoFox_Bot的信息获取能力扩展组件。如果说Action组件功能五花八门，可以拓展麦麦能做的事情，那么Tool就是在某个过程中拓宽了麦麦能够获得的信息量。
|
||||
工具是MoFox_Bot的信息获取能力扩展组件。如果说Action组件功能五花八门，可以拓展麦麦能做的事情，那么Tool就是在某个过程中拓宽了MoFox_Bot能够获得的信息量。
|
||||
|
||||
### 🎯 工具的特点
|
||||
|
||||
|
||||
@@ -1,121 +0,0 @@
|
||||
# “月层计划”系统架构设计文档
|
||||
|
||||
## 1. 系统概述与目标
|
||||
|
||||
本系统旨在为MoFox_Bot引入一个动态的、由大型语言模型（LLM）驱动的“月层计划”机制。其核心目标是取代静态、预设的任务模板，转而利用LLM在程序启动时自动生成符合Bot人设的、具有时效性的月度计划。这些计划将被存储、管理，并在构建每日日程时被动态抽取和使用，从而极大地丰富日程内容的个性和多样性。
|
||||
|
||||
---
|
||||
|
||||
## 2. 核心设计原则
|
||||
|
||||
- **动态性与智能化:** 所有计划内容均由LLM实时生成，确保其独特性和创造性。
|
||||
- **人设一致性:** 计划的生成将严格围绕Bot的核心人设进行，强化角色形象。
|
||||
- **持久化与可管理:** 生成的计划将被存入专用数据库表，便于管理和追溯。
|
||||
- **消耗性与随机性:** 计划在使用后有一定几率被消耗（删除），模拟真实世界中计划的完成与迭代。
|
||||
|
||||
---
|
||||
|
||||
## 3. 系统核心流程规划
|
||||
|
||||
本系统包含两大核心流程：**启动时的计划生成流程**和**日程构建时的计划使用流程**。
|
||||
|
||||
### 3.1 流程一：启动时计划生成
|
||||
|
||||
此流程在每次程序启动时触发，负责填充当月的计划池。
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[程序启动] --> B{检查当月计划池};
|
||||
B -- 计划数量低于阈值 --> C[构建LLM Prompt];
|
||||
C -- prompt包含Bot人设、月份等信息 --> D[调用LLM服务];
|
||||
D -- LLM返回多个计划文本 --> E[解析并格式化计划];
|
||||
E -- 逐条处理 --> F[存入`monthly_plans`数据库表];
|
||||
F --> G[完成启动任务];
|
||||
B -- 计划数量充足 --> G;
|
||||
```
|
||||
|
||||
### 3.2 流程二：日程构建时计划使用
|
||||
|
||||
此流程在构建每日日程的提示词（Prompt）时触发。
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
H[构建日程Prompt] --> I{查询数据库};
|
||||
I -- 读取当月未使用的计划 --> J[随机抽取N个计划];
|
||||
J --> K[将计划文本嵌入日程Prompt];
|
||||
K --> L{随机数判断};
|
||||
L -- 概率命中 --> M[将已抽取的计划标记为删除];
|
||||
M --> N[完成Prompt构建];
|
||||
L -- 概率未命中 --> N;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 数据库模型设计
|
||||
|
||||
为支撑本系统，需要新增一个数据库表。
|
||||
|
||||
**表名:** `monthly_plans`
|
||||
|
||||
| 字段名 | 类型 | 描述 |
|
||||
| :--- | :--- | :--- |
|
||||
| `id` | Integer | 主键，自增。 |
|
||||
| `plan_text` | Text | 由LLM生成的计划内容原文。 |
|
||||
| `target_month` | String(7) | 计划所属的月份，格式为 "YYYY-MM"。 |
|
||||
| `is_deleted` | Boolean | 软删除标记，默认为 `false`。 |
|
||||
| `created_at` | DateTime | 记录创建时间。 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 详细模块规划
|
||||
|
||||
### 5.1 LLM Prompt生成模块
|
||||
|
||||
- **职责:** 构建高质量的Prompt以引导LLM生成符合要求的计划。
|
||||
- **输入:** Bot人设描述、当前月份、期望生成的计划数量。
|
||||
- **输出:** 一个结构化的Prompt字符串。
|
||||
- **Prompt示例:**
|
||||
```
|
||||
你是一个[此处填入Bot人设描述，例如：活泼开朗、偶尔有些小迷糊的虚拟助手]。
|
||||
请为即将到来的[YYYY年MM月]设计[N]个符合你身份的月度计划或目标。
|
||||
|
||||
要求：
|
||||
1. 每个计划都是独立的、积极向上的。
|
||||
2. 语言风格要自然、口语化，符合你的性格。
|
||||
3. 每个计划用一句话或两句话简短描述。
|
||||
4. 以JSON格式返回，格式为：{"plans": ["计划一", "计划二", ...]}
|
||||
```
|
||||
|
||||
### 5.2 数据库交互模块
|
||||
|
||||
- **职责:** 提供对 `monthly_plans` 表的增、删、改、查接口。
|
||||
- **规划函数列表:**
|
||||
- `add_new_plans(plans: list[str], month: str)`: 批量添加新生成的计划。
|
||||
- `get_active_plans_for_month(month: str) -> list`: 获取指定月份所有未被删除的计划。
|
||||
- `soft_delete_plans(plan_ids: list[int])`: 将指定ID的计划标记为软删除。
|
||||
|
||||
### 5.3 配置项规划
|
||||
|
||||
需要在主配置文件 `config/bot_config.toml` 中添加以下配置项，以控制系统行为。
|
||||
|
||||
```toml
|
||||
# ----------------------------------------------------------------
|
||||
# 月层计划系统设置 (Monthly Plan System Settings)
|
||||
# ----------------------------------------------------------------
|
||||
[monthly_plan_system]
|
||||
|
||||
# 是否启用本功能
|
||||
enable = true
|
||||
|
||||
# 启动时，如果当月计划少于此数量，则触发LLM生成
|
||||
generation_threshold = 10
|
||||
|
||||
# 每次调用LLM期望生成的计划数量
|
||||
plans_per_generation = 5
|
||||
|
||||
# 计划被使用后，被删除的概率 (0.0 到 1.0)
|
||||
deletion_probability_on_use = 0.5
|
||||
```
|
||||
|
||||
---
|
||||
**文档结束。** 本文档纯粹为架构规划，旨在提供清晰的设计思路和开发指引，不包含任何实现代码。
|
||||
Reference in New Issue
Block a user