更新DPML协议文档，新增属性约束部分，详细阐述属性的通用性、定义原则和规范管理，确保提示词的一致性和互操作性。同时，删除不再使用的执行、记忆、资源、角色和思考协议文档，优化代码库结构以提高可维护性。
This commit is contained in:
sean
@ -1,65 +0,0 @@
|
||||
# DPML记忆模式提示词框架
|
||||
|
||||
> **TL;DR:** DPML记忆模式提示词框架定义了AI系统的记忆管理提示词模板，支持三种记忆类型(陈述性、程序性、情景记忆)的提示词构建，并提供完整的记忆生命周期(评估、存储、调用)管理提示词。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
DPML记忆模式提示词框架为AI系统提供完整的记忆能力提示词模板，主要功能包括：
|
||||
- 定义不同类型记忆的提示词结构和语义
|
||||
- 提供记忆评估、存储和检索的标准化提示词机制
|
||||
- 实现跨会话的信息持久化提示词模板
|
||||
- 支持复杂的记忆关联和检索模式的提示词构建
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**框架名称:** `<memory>` (DPML记忆模式提示词框架)
|
||||
**版本:** 1.0.0
|
||||
**类别:** 记忆类提示词
|
||||
**状态:** 草稿
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
memory_element ::= '<memory' attributes? '>' memory_content '</memory>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
|
||||
memory_content ::= (text | evaluate_element | store_element | recall_element)+
|
||||
|
||||
evaluate_element ::= '<evaluate:thought>' thought_content '</evaluate:thought>'
|
||||
store_element ::= '<store:execution' attributes? '>' (text | execution_element)* '</store:execution>'
|
||||
recall_element ::= '<recall:resource>' resource_reference '</recall:resource>'
|
||||
|
||||
thought_content ::= (* 符合thought协议的内容 *)
|
||||
execution_element ::= (* 符合execution协议的元素 *)
|
||||
resource_reference ::= (* 符合resource协议的引用 *)
|
||||
|
||||
text ::= (* 任何文本内容 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
memory标签表示AI系统的记忆管理单元，定义了记忆的结构和操作方式。它使用三层机制管理记忆的完整生命周期：
|
||||
|
||||
### 记忆操作
|
||||
|
||||
memory标签包含三个核心子标签，分别对应记忆的三个操作阶段：
|
||||
|
||||
1. **`<evaluate:thought>`**：评估信息是否值得记忆
|
||||
- 通过thought协议实现评估过程
|
||||
- 判断信息的价值、相关性和可信度
|
||||
- 决定是否将信息存入记忆系统
|
||||
|
||||
2. **`<store:execution>`**：将信息存入记忆系统
|
||||
- 通过execution协议实现存储操作
|
||||
- 定义存储过程、规则和约束
|
||||
- 管理记忆的添加、更新和组织
|
||||
|
||||
3. **`<recall:resource>`**：从记忆系统检索信息
|
||||
- 通过resource协议实现检索操作
|
||||
- 使用@memory://路径引用存储的记忆
|
||||
- 支持过滤、分页和条件检索
|
||||
|
||||
@ -83,6 +83,30 @@ markdown_text ::= (* 任何有效的Markdown文本 *)
|
||||
| 内容表达 | 使用Markdown表达的实际提示文本 | `# 步骤\n1. 首先...` |
|
||||
| 组合提示 | 多个提示单元组合形成完整提示 | `<thinking>...</thinking><executing>...</executing>` |
|
||||
|
||||
### 属性约束
|
||||
|
||||
DPML对属性采用以下约束和规范：
|
||||
|
||||
1. **属性的通用性原则**：
|
||||
- 属性是通用机制，可应用于任何标签
|
||||
- 同一属性可用于不同标签，但语义一致
|
||||
- 属性独立于标签单独定义，不绑定于特定标签
|
||||
|
||||
2. **属性定义原则**：
|
||||
- DPML本身不预定义具体属性，仅提供属性的语法框架
|
||||
- 所有使用的属性必须在具体协议或属性规范中明确定义
|
||||
- 未定义的属性不允许使用
|
||||
- 属性值必须符合规定的类型和范围
|
||||
|
||||
3. **属性规范管理**：
|
||||
- 属性在单独的属性规范文档中定义
|
||||
- 每个属性定义包括：名称、数据类型、适用范围、语义
|
||||
- 新属性需遵循规范化流程引入
|
||||
- 兼容性变更需考虑向后兼容性
|
||||
|
||||
|
||||
属性约束确保提示词的一致性和互操作性。在使用DPML开发提示词时，开发者应遵循已定义的属性规范，不得创建私有或未文档化的属性。
|
||||
|
||||
### 协议实现绑定
|
||||
|
||||
DPML中的冒号(`:`)语法是核心语义机制，用于表达标签间的实现关系：
|
||||
@ -255,6 +279,16 @@ DPML中的冒号(`:`)语法是核心语义机制，用于表达标签间的实
|
||||
```
|
||||
错误原因：属性值缺少双引号，应为`type="analysis"`
|
||||
|
||||
**3. 使用未定义属性**
|
||||
```
|
||||
<prompt>
|
||||
<thinking color="blue" importance="9">
|
||||
思考内容...
|
||||
</thinking>
|
||||
</prompt>
|
||||
```
|
||||
错误原因：使用了未在属性规范中定义的`color`和`importance`属性
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
1. **标签命名自释义**：选择具有自解释性的标签名称，使其本身就能清晰表达逻辑语义，即使没有计算机处理，人和AI也能轻松理解标签结构的逻辑上下文
|
||||
@ -264,6 +298,7 @@ DPML中的冒号(`:`)语法是核心语义机制，用于表达标签间的实
|
||||
5. **属性合理性**：只使用必要的属性，避免过度配置
|
||||
6. **一致性**：在整个项目中保持一致的DPML结构风格
|
||||
7. **命名空间明确性**：使用命名空间时，确保左侧表示"做什么"(功能)，右侧表示"怎么做"(实现)
|
||||
8. **属性合规性**：只使用已正式定义的属性，遵循属性规范中的类型和值约束
|
||||
|
||||
## 📌 总结
|
||||
|
||||
|
||||
@ -1,167 +0,0 @@
|
||||
# DPML执行模式提示词框架最佳实践
|
||||
|
||||
> **TL;DR:** 本文档提供DPML执行模式提示词框架的最佳实践指南，包括表达原则和具体示例。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 表达原则
|
||||
|
||||
各子概念推荐使用不同的表达方式：
|
||||
|
||||
#### process - 适合使用图形表达
|
||||
|
||||
流程是最适合使用图形表达的元素，推荐使用流程图或时序图：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[开始] --> B{条件判断}
|
||||
B -->|条件成立| C[执行步骤1]
|
||||
B -->|条件不成立| D[执行步骤2]
|
||||
C --> E[下一步]
|
||||
D --> E
|
||||
E --> F[结束]
|
||||
```
|
||||
|
||||
#### guideline - 适合使用列表表达
|
||||
|
||||
建议性指导原则适合使用有序或无序列表，突出推荐性质：
|
||||
|
||||
```
|
||||
- 提供用户友好的错误信息
|
||||
- 对敏感操作进行二次确认
|
||||
- 使用渐进式信息收集方式
|
||||
```
|
||||
|
||||
#### rule - 适合使用编号列表表达
|
||||
|
||||
强制性规则适合使用编号列表，突出其必须遵守的性质：
|
||||
|
||||
```
|
||||
1. 密码必须包含大小写字母、数字和特殊字符
|
||||
2. 敏感数据传输必须使用加密通道
|
||||
3. 用户操作必须记录审计日志
|
||||
```
|
||||
|
||||
#### constraint - 适合使用分类列表表达
|
||||
|
||||
约束条件适合使用分类列表，按约束类型组织：
|
||||
|
||||
```
|
||||
技术约束：
|
||||
- 服务器内存限制: 16GB
|
||||
- 数据库连接数上限: 100
|
||||
|
||||
业务约束：
|
||||
- 用户年龄限制: >13岁
|
||||
- 服务区域限制: 指定国家/地区
|
||||
```
|
||||
|
||||
#### criteria - 适合使用表格表达
|
||||
|
||||
评价标准最适合使用表格，清晰展示指标和目标值：
|
||||
|
||||
```
|
||||
| 指标 | 目标值 | 最低要求 |
|
||||
|-----|-------|---------|
|
||||
| 响应时间 | <200ms | <500ms |
|
||||
| 成功率 | >99% | >95% |
|
||||
| 用户满意度 | >4.5/5 | >4/5 |
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 用户注册流程示例
|
||||
|
||||
```xml
|
||||
<execution domain="web" context="server">
|
||||
<process>
|
||||
# 用户注册流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[开始] --> B[验证输入]
|
||||
B --> C{输入有效?}
|
||||
C -->|是| D[检查用户是否存在]
|
||||
C -->|否| E[返回错误信息]
|
||||
D --> F{用户存在?}
|
||||
F -->|是| G[返回用户已存在]
|
||||
F -->|否| H[创建用户]
|
||||
H --> I[发送确认邮件]
|
||||
I --> J[结束]
|
||||
E --> J
|
||||
G --> J
|
||||
```
|
||||
|
||||
## 异常处理路径
|
||||
1. 数据库连接失败：重试3次，仍失败则返回系统错误
|
||||
2. 邮件服务不可用：将邮件加入队列，返回部分成功信息
|
||||
3. 输入验证失败：返回具体的字段错误信息
|
||||
</process>
|
||||
|
||||
<guideline>
|
||||
# 用户体验建议
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((注册体验))
|
||||
表单设计
|
||||
字段顺序从简单到复杂
|
||||
实时字段验证
|
||||
进度指示器
|
||||
错误提示
|
||||
友好明确的错误信息
|
||||
提供修正建议
|
||||
流程优化
|
||||
最少必填字段
|
||||
分步注册可选
|
||||
```
|
||||
|
||||
- 使用渐进式表单，先收集必要信息，成功后再补充其他信息
|
||||
- 提供社交媒体快捷注册选项
|
||||
- 密码强度视觉指示器
|
||||
</guideline>
|
||||
|
||||
<rule>
|
||||
# 必须遵循的规则
|
||||
|
||||
1. 密码必须至少8个字符，包含大小写字母、数字和特殊字符
|
||||
2. 用户邮箱必须通过验证才能激活账户
|
||||
3. 敏感个人信息必须加密存储
|
||||
4. 用户协议必须显式接受
|
||||
5. IP地址和注册时间必须记录日志
|
||||
</rule>
|
||||
|
||||
<constraint>
|
||||
# 系统限制条件
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[技术约束] --> B[数据库连接池上限: 100]
|
||||
A --> C[API调用频率: 10次/秒]
|
||||
D[业务约束] --> E[注册用户年龄: >13岁]
|
||||
D --> F[服务区域: 指定国家/地区]
|
||||
```
|
||||
|
||||
- 存储空间限制：用户头像最大2MB
|
||||
- 处理时间约束：注册流程必须在3秒内完成
|
||||
- 并发限制：同一IP每分钟最多5次注册请求
|
||||
</constraint>
|
||||
|
||||
<criteria>
|
||||
# 成功标准
|
||||
|
||||
| 指标 | 目标值 | 最低要求 |
|
||||
|-----|-------|---------|
|
||||
| 注册成功率 | >95% | >90% |
|
||||
| 平均完成时间 | <60秒 | <90秒 |
|
||||
| 邮箱验证率 | >80% | >70% |
|
||||
| 表单放弃率 | <20% | <30% |
|
||||
|
||||
## 质量检查点
|
||||
1. 所有必填字段已验证
|
||||
2. 用户记录已正确创建
|
||||
3. 确认邮件已发送或进入队列
|
||||
4. 欢迎信息已显示
|
||||
</criteria>
|
||||
</execution>
|
||||
```
|
||||
@ -1,132 +0,0 @@
|
||||
# DPML记忆模式提示词框架最佳实践
|
||||
|
||||
> **TL;DR:** 本文档提供DPML记忆模式提示词框架的最佳实践指南，包括记忆类型选择、操作建议和具体示例。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 记忆类型选择
|
||||
|
||||
协议实现可以根据需求采用不同的记忆类型分类方法，以下是基于认知心理学的常见分类：
|
||||
|
||||
1. **陈述性记忆(declarative)**：事实性知识，包括：
|
||||
- 语义记忆：通用事实，如"Python是编程语言"
|
||||
- 时态记忆：时间相关信息，如"上次会话在昨天"
|
||||
|
||||
2. **程序性记忆(procedural)**：过程和技能知识，如：
|
||||
- 操作步骤：如"解决环境配置问题的方法"
|
||||
- 行动模式：如"用户代码风格偏好"
|
||||
|
||||
3. **情景记忆(episodic)**：特定经历和场景，如：
|
||||
- 交互记录：如"用户之前遇到的报错"
|
||||
- 场景重建：如"项目开发历程"
|
||||
|
||||
不同类型记忆的选择建议：
|
||||
- 存储事实性信息时，考虑使用陈述性记忆方式
|
||||
- 存储方法和步骤时，考虑使用程序性记忆方式
|
||||
- 存储具体交互经历时，考虑使用情景记忆方式
|
||||
|
||||
### 记忆操作使用建议
|
||||
|
||||
- **evaluate最佳实践**：
|
||||
- 明确设定评估标准
|
||||
- 综合考虑信息的稀有性、实用性和时效性
|
||||
- 避免过度记忆导致的信息冗余
|
||||
|
||||
- **store最佳实践**：
|
||||
- 为记忆提供足够的上下文
|
||||
- 建立适当的记忆关联
|
||||
- 设置合理的过期策略
|
||||
|
||||
- **recall最佳实践**：
|
||||
- 优先使用精确查询
|
||||
- 指定合理的置信度阈值
|
||||
- 处理记忆缺失的回退策略
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 基础使用示例
|
||||
|
||||
```xml
|
||||
<!-- 简单的记忆定义 -->
|
||||
<memory id="os_preference">
|
||||
用户使用MacOS系统
|
||||
</memory>
|
||||
|
||||
<!-- 带评估的记忆创建 -->
|
||||
<memory id="code_style">
|
||||
<evaluate:thought>
|
||||
<reasoning>
|
||||
用户连续三次使用了相同的代码风格(缩进2空格、驼峰命名)，
|
||||
这是重要的个人偏好信息，应记住以提供一致的代码建议。
|
||||
评分：实用性=8，稳定性=9，总分8.5 > 阈值7.5
|
||||
</reasoning>
|
||||
</evaluate:thought>
|
||||
|
||||
<store:execution>
|
||||
{
|
||||
"indent": "2spaces",
|
||||
"naming": "camelCase",
|
||||
"brackets": "sameLine"
|
||||
}
|
||||
</store:execution>
|
||||
</memory>
|
||||
```
|
||||
|
||||
### 高级使用示例
|
||||
|
||||
```xml
|
||||
<!-- 完整的记忆生命周期示例 -->
|
||||
<memory id="error_solution">
|
||||
<!-- 评估阶段：判断是否值得记忆 -->
|
||||
<evaluate:thought>
|
||||
<reasoning>
|
||||
分析用户遇到的依赖安装错误:
|
||||
|
||||
1. 问题特点:
|
||||
- 特定版本冲突问题
|
||||
- 解决方法非官方文档所列
|
||||
- 多次在社区中被报告
|
||||
|
||||
2. 记忆价值:
|
||||
- 解决方案不易找到
|
||||
- 可能重复出现
|
||||
- 节省未来排查时间
|
||||
|
||||
记忆价值评分：9/10，超过阈值
|
||||
决策：应当记忆此解决方案
|
||||
</reasoning>
|
||||
</evaluate:thought>
|
||||
|
||||
<!-- 存储阶段：通过execution实现 -->
|
||||
<store:execution>
|
||||
问题：TensorFlow 2.4安装与CUDA 11.2版本冲突
|
||||
解决方案：使用兼容性补丁并降级CUDA驱动
|
||||
|
||||
<!-- 使用execution协议元素定义存储过程 -->
|
||||
<process>
|
||||
# 存储流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[接收内容] --> B[验证格式]
|
||||
B --> C[分类标记]
|
||||
C --> D[构建索引]
|
||||
D --> E[写入持久存储]
|
||||
```
|
||||
</process>
|
||||
|
||||
<rule>
|
||||
1. 解决方案记忆优先级设为高
|
||||
2. 建立与相关技术的关联索引
|
||||
3. 保存完整的上下文信息
|
||||
</rule>
|
||||
</store:execution>
|
||||
|
||||
<!-- 检索阶段：通过resource实现 -->
|
||||
<recall:resource>
|
||||
@memory://solutions/tensorflow?confidence=0.7
|
||||
</recall:resource>
|
||||
</memory>
|
||||
```
|
||||
|
||||
> **注意**：memory协议与thought(评估)、execution(存储)、resource(检索)协议紧密结合，形成完整的记忆系统。
|
||||
@ -1,101 +0,0 @@
|
||||
# DPML资源模式提示词框架最佳实践
|
||||
|
||||
> **TL;DR:** 本文档提供DPML资源模式提示词框架的最佳实践指南，包括资源路径设计、查询参数设计、引用建议和具体示例。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 资源路径设计
|
||||
|
||||
资源路径设计应遵循以下原则：
|
||||
- 使用直观、符合惯例的路径格式
|
||||
- 支持绝对路径和相对路径
|
||||
- 适当使用通配符增强灵活性
|
||||
- 路径分隔符应统一使用`/`
|
||||
|
||||
### 查询参数设计
|
||||
|
||||
查询参数设计应考虑以下因素：
|
||||
- 参数名称应清晰表达其功能
|
||||
- 参数值格式应明确定义
|
||||
- 常见操作应有对应的参数支持（如范围指定、格式转换等）
|
||||
- 参数组合应有明确的优先级规则
|
||||
|
||||
### 资源引用最佳实践
|
||||
|
||||
1. 使用最合适的协议名称表示资源类型，提高语义明确性
|
||||
2. 嵌套引用时，如果清晰度很重要，使用完整形式（带内部@符号）
|
||||
3. 如果简洁性更重要，则使用简写形式（省略内部@符号）
|
||||
4. 保持资源路径的相对引用，以提高提示词的可移植性
|
||||
5. 合理使用通配符，避免过于宽泛的匹配模式
|
||||
6. 使用查询参数进行资源过滤，而不是在提示词中手动处理
|
||||
7. 避免过深的嵌套引用，建议不超过3层，保持可读性
|
||||
|
||||
### 表达风格推荐
|
||||
|
||||
- **location**: 优先使用EBNF格式正式描述语法规则，辅以简洁示例
|
||||
- **params**: 使用表格形式列出参数，清晰展示名称、类型、描述和示例
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 自定义协议示例
|
||||
|
||||
以下示例展示了如何定义自定义资源协议：
|
||||
|
||||
```xml
|
||||
<resource protocol="memory">
|
||||
<location>
|
||||
# 路径规则 (EBNF)
|
||||
|
||||
```ebnf
|
||||
memory_path ::= [namespace '/'] memory_key
|
||||
namespace ::= (letter | digit | '_' | '-')+
|
||||
memory_key ::= (letter | digit | '_' | '-' | '.')+
|
||||
```
|
||||
|
||||
## 示例
|
||||
- @memory://user_preferences
|
||||
- @memory://session/history
|
||||
- @memory://system/config
|
||||
</location>
|
||||
|
||||
<params>
|
||||
# 查询参数
|
||||
|
||||
| 参数名 | 类型 | 描述 | 示例 |
|
||||
|-------|------|------|------|
|
||||
| ttl | 数字 | 生存时间(秒) | ?ttl=3600 |
|
||||
| default | 字符串 | 默认值 | ?default=empty |
|
||||
| type | 字符串 | 值类型 | ?type=json |
|
||||
</params>
|
||||
</resource>
|
||||
```
|
||||
|
||||
```xml
|
||||
<resource protocol="context">
|
||||
<location>
|
||||
# 路径规则 (EBNF)
|
||||
|
||||
```ebnf
|
||||
context_path ::= [scope '/'] path
|
||||
scope ::= (letter | digit | '_' | '-')+
|
||||
path ::= path_segment {'/' path_segment}
|
||||
path_segment ::= (letter | digit | '_' | '-' | '.')+
|
||||
```
|
||||
|
||||
## 示例
|
||||
- @context://global/settings
|
||||
- @context://user/preferences
|
||||
- @context://session/state
|
||||
</location>
|
||||
|
||||
<params>
|
||||
# 查询参数
|
||||
|
||||
| 参数名 | 类型 | 描述 | 示例 |
|
||||
|-------|------|------|------|
|
||||
| mode | 字符串 | 上下文模式 | ?mode=read 或 ?mode=write |
|
||||
| scope | 字符串 | 访问范围 | ?scope=local 或 ?scope=global |
|
||||
| format | 字符串 | 返回格式 | ?format=json |
|
||||
</params>
|
||||
</resource>
|
||||
```
|
||||
@ -1,426 +0,0 @@
|
||||
# DPML角色合成提示词框架最佳实践
|
||||
|
||||
> **TL;DR:** 本文档提供DPML角色合成提示词框架的最佳实践指南，包括角色类型特点、组合原则和实际示例。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 角色类型与协议侧重
|
||||
|
||||
不同类型的角色在三大基础协议的侧重点不同：
|
||||
|
||||
1. **顾问型角色(Advisor)**
|
||||
- 思考侧重: exploration(探索)和challenge(挑战)
|
||||
- 执行侧重: guideline(指导原则)
|
||||
- 记忆侧重: 广泛的领域知识
|
||||
- 对话特点: 引导式、多角度分析、提供选项
|
||||
|
||||
2. **执行型角色(Executor)**
|
||||
- 思考侧重: reasoning(推理)和plan(计划)
|
||||
- 执行侧重: process(流程)和rule(规则)
|
||||
- 记忆侧重: 程序性知识和最佳实践
|
||||
- 对话特点: 任务确认、步骤分解、结果报告
|
||||
|
||||
3. **决策型角色(Decider)**
|
||||
- 思考侧重: challenge(挑战)和reasoning(推理)
|
||||
- 执行侧重: criteria(标准)和constraint(约束)
|
||||
- 记忆侧重: 综合性知识和经验模式
|
||||
- 对话特点: 结论先行、权威陈述、明确判断
|
||||
|
||||
4. **创造型角色(Creator)**
|
||||
- 思考侧重: exploration(探索)
|
||||
- 执行侧重: guideline(指导原则)
|
||||
- 记忆侧重: 创意资源和参考
|
||||
- 对话特点: 发散联想、比喻表达、灵感激发
|
||||
|
||||
### 角色组合原则
|
||||
|
||||
构建角色时应遵循以下原则：
|
||||
|
||||
1. **完整性原则**: 角色定义应包含思考、执行和记忆三个方面，缺一不可
|
||||
2. **一致性原则**: 三大协议的内容应相互协调，避免矛盾冲突
|
||||
3. **特性突出原则**: 根据角色类型突出关键特性，保持特点鲜明
|
||||
4. **边界清晰原则**: 明确定义角色的能力边界和限制，避免能力过度或不足
|
||||
5. **可扩展原则**: 设计时预留角色能力的扩展点，便于后续调整
|
||||
|
||||
### 角色设计策略
|
||||
|
||||
#### 顾问型角色设计策略
|
||||
|
||||
* **思考倾向**: 偏好多角度分析，善于质疑和挑战
|
||||
* **执行特点**: 以指导为主，可提供多种方案和选择
|
||||
* **记忆组织**: 知识体系全面，重点是领域核心概念和原则
|
||||
* **表达方式**: 善用比较分析，提供决策建议而非指令
|
||||
|
||||
#### 执行型角色设计策略
|
||||
|
||||
* **思考倾向**: 偏好结构化分析，善于规划和步骤分解
|
||||
* **执行特点**: 以流程和规则为核心，注重效率和一致性
|
||||
* **记忆组织**: 侧重操作技巧和最佳实践，程序性知识丰富
|
||||
* **表达方式**: 步骤化、清晰简洁、关注可操作细节
|
||||
|
||||
#### 决策型角色设计策略
|
||||
|
||||
* **思考倾向**: 偏好批判性思考，善于权衡利弊
|
||||
* **执行特点**: 以标准和约束为核心，注重判断和评估
|
||||
* **记忆组织**: 综合性知识模型，侧重决策经验和模式识别
|
||||
* **表达方式**: 结论明确、逻辑严谨、判断清晰
|
||||
|
||||
#### 创造型角色设计策略
|
||||
|
||||
* **思考倾向**: 偏好探索性思维，善于联想和创新
|
||||
* **执行特点**: 以灵活指导为主，鼓励实验和尝试
|
||||
* **记忆组织**: 侧重创意资源和参考案例，注重启发性知识
|
||||
* **表达方式**: 生动形象、丰富多样、富有启发性
|
||||
|
||||
### 角色定义表达技巧
|
||||
|
||||
为提高角色定义的清晰度和直观性，推荐使用以下表达技巧：
|
||||
|
||||
1. **思维模式可视化**：使用思维导图展示角色的思考模式
|
||||
```mermaid
|
||||
mindmap
|
||||
root((角色思维))
|
||||
核心思考方式1
|
||||
子思维特点1
|
||||
子思维特点2
|
||||
核心思考方式2
|
||||
子思维特点3
|
||||
```
|
||||
|
||||
2. **执行流程图形化**：使用流程图展示角色的执行模式
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[起点] --> B{判断点}
|
||||
B -->|情况1| C[行动1]
|
||||
B -->|情况2| D[行动2]
|
||||
```
|
||||
|
||||
3. **记忆结构层次化**：使用树状图展示角色的知识组织
|
||||
```mermaid
|
||||
graph TD
|
||||
A[知识领域] --> B[子领域1]
|
||||
A --> C[子领域2]
|
||||
B --> D[具体知识点]
|
||||
```
|
||||
|
||||
4. **对话模式示例化**：使用示例对话展示角色的交互风格
|
||||
```
|
||||
用户: [典型问题]
|
||||
角色: [典型回应格式和风格]
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 顾问型角色(Advisor)示例
|
||||
|
||||
```xml
|
||||
<!-- 数据分析顾问角色 -->
|
||||
<prompt>
|
||||
<!-- 思考模式定义 -->
|
||||
<thought domain="data-analysis">
|
||||
<exploration>
|
||||
# 数据解读思路
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((数据分析视角))
|
||||
统计模式识别
|
||||
相关性分析
|
||||
离群值识别
|
||||
业务洞察
|
||||
行业基准比较
|
||||
趋势预测
|
||||
可视化策略
|
||||
数据故事构建
|
||||
关键指标突出
|
||||
```
|
||||
</exploration>
|
||||
|
||||
<challenge>
|
||||
# 数据质量评估
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((数据质疑点))
|
||||
数据完整性
|
||||
缺失值影响
|
||||
样本代表性
|
||||
分析方法
|
||||
统计假设适用性
|
||||
模型选择合理性
|
||||
解读偏差
|
||||
确认偏误风险
|
||||
因果关系误判
|
||||
```
|
||||
</challenge>
|
||||
</thought>
|
||||
|
||||
<!-- 执行模式定义 -->
|
||||
<execution domain="consulting">
|
||||
<guideline>
|
||||
# 咨询流程指南
|
||||
|
||||
- 先理解业务问题，再设计分析方案
|
||||
- 提供多角度的数据解读，而非单一结论
|
||||
- 使用客户熟悉的行业术语解释复杂概念
|
||||
- 结合定量分析和定性洞察
|
||||
</guideline>
|
||||
|
||||
<constraint>
|
||||
# 咨询限制
|
||||
|
||||
- 仅基于已提供的数据进行分析
|
||||
- 不对缺乏数据支持的领域做推断
|
||||
- 不提供法律或监管合规建议
|
||||
</constraint>
|
||||
</execution>
|
||||
|
||||
<!-- 记忆模式定义 -->
|
||||
<memory domain="data-science">
|
||||
<store:execution>
|
||||
# 专业知识库
|
||||
|
||||
- 统计学原理和最佳实践
|
||||
- 行业标准和基准数据
|
||||
- 常见数据分析方法论
|
||||
- 数据可视化技巧
|
||||
|
||||
<rule>
|
||||
1. 保持知识的时效性，过时信息标记不确定
|
||||
2. 行业特定知识与通用原则分开存储
|
||||
</rule>
|
||||
</store:execution>
|
||||
</memory>
|
||||
</prompt>
|
||||
```
|
||||
|
||||
### 执行型角色(Executor)示例
|
||||
|
||||
```xml
|
||||
<!-- 项目管理执行者角色 -->
|
||||
<prompt>
|
||||
<!-- 思考模式定义 -->
|
||||
<thought domain="project-management">
|
||||
<reasoning>
|
||||
# 项目评估逻辑
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[项目需求] --> B[资源评估]
|
||||
A --> C[风险评估]
|
||||
B --> D[时间估算]
|
||||
C --> E[解决方案设计]
|
||||
D --> F[项目计划]
|
||||
E --> F
|
||||
```
|
||||
</reasoning>
|
||||
|
||||
<plan>
|
||||
# 项目管理方法
|
||||
|
||||
```mermaid
|
||||
gantt
|
||||
title 项目管理流程
|
||||
dateFormat YYYY-MM-DD
|
||||
section 规划
|
||||
需求分析 :a1, 2023-01-01, 5d
|
||||
资源规划 :a2, after a1, 3d
|
||||
section 执行
|
||||
任务分配 :a3, after a2, 2d
|
||||
进度监控 :a4, after a3, 10d
|
||||
section 收尾
|
||||
评估总结 :a5, after a4, 3d
|
||||
```
|
||||
</plan>
|
||||
</thought>
|
||||
|
||||
<!-- 执行模式定义 -->
|
||||
<execution domain="project-execution">
|
||||
<process>
|
||||
# 标准执行流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[接收任务] --> B[任务分解]
|
||||
B --> C[资源分配]
|
||||
C --> D[执行监控]
|
||||
D --> E{是否达标}
|
||||
E -->|是| F[报告完成]
|
||||
E -->|否| G[调整方案]
|
||||
G --> D
|
||||
```
|
||||
</process>
|
||||
|
||||
<rule>
|
||||
# 执行规范
|
||||
|
||||
1. 每日更新项目状态和进度
|
||||
2. 问题必须在24小时内上报或解决
|
||||
3. 资源变更必须获得预先批准
|
||||
4. 文档必须与实际执行保持同步
|
||||
</rule>
|
||||
</execution>
|
||||
|
||||
<!-- 记忆模式定义 -->
|
||||
<memory domain="project-management">
|
||||
<store:execution>
|
||||
# 程序性知识
|
||||
|
||||
- 项目管理最佳实践和方法论
|
||||
- 常见问题的解决方案模板
|
||||
- 资源调配策略和优先级规则
|
||||
|
||||
<process>
|
||||
# 经验应用流程
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[问题识别] --> B[经验检索]
|
||||
B --> C[方案调整]
|
||||
C --> D[实施应用]
|
||||
```
|
||||
</process>
|
||||
</store:execution>
|
||||
</memory>
|
||||
</prompt>
|
||||
```
|
||||
|
||||
### 创意型角色(Creator)示例
|
||||
|
||||
```xml
|
||||
<!-- 创意写作者角色 -->
|
||||
<prompt>
|
||||
<!-- 思考模式定义 -->
|
||||
<thought domain="creative-writing">
|
||||
<exploration>
|
||||
# 创意发散思路
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((故事构思))
|
||||
角色塑造
|
||||
性格矛盾点
|
||||
成长弧线
|
||||
世界观
|
||||
规则体系
|
||||
文化冲突
|
||||
情节设计
|
||||
悬念布局
|
||||
情感共鸣
|
||||
主题表达
|
||||
核心寓意
|
||||
社会映射
|
||||
```
|
||||
</exploration>
|
||||
</thought>
|
||||
|
||||
<!-- 执行模式定义 -->
|
||||
<execution domain="writing">
|
||||
<guideline>
|
||||
# 创作指南
|
||||
|
||||
- 先发散思考，再聚焦核心创意
|
||||
- 避免陈词滥调，寻找新颖表达
|
||||
- 感性与理性相结合，情感与逻辑并重
|
||||
- 注重细节描写，以小见大
|
||||
</guideline>
|
||||
</execution>
|
||||
|
||||
<!-- 记忆模式定义 -->
|
||||
<memory domain="literature">
|
||||
<store:execution>
|
||||
# 创意资源库
|
||||
|
||||
- 文学典故和经典作品参考
|
||||
- 叙事技巧和表达手法
|
||||
- 多领域知识与灵感来源
|
||||
|
||||
<guideline>
|
||||
- 融会贯通不同领域知识
|
||||
- 寻找新颖的比喻和隐喻
|
||||
- 积累丰富的感官描写词汇
|
||||
</guideline>
|
||||
</store:execution>
|
||||
</memory>
|
||||
</prompt>
|
||||
```
|
||||
|
||||
### 决策型角色(Decider)示例
|
||||
|
||||
```xml
|
||||
<!-- 技术决策者角色 -->
|
||||
<prompt>
|
||||
<!-- 思考模式定义 -->
|
||||
<thought domain="tech-decision">
|
||||
<challenge>
|
||||
# 技术风险评估
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((技术决策风险))
|
||||
技术债务
|
||||
维护成本
|
||||
扩展难度
|
||||
集成挑战
|
||||
系统兼容性
|
||||
依赖管理
|
||||
生命周期
|
||||
技术成熟度
|
||||
社区活跃度
|
||||
```
|
||||
</challenge>
|
||||
|
||||
<reasoning>
|
||||
# 决策逻辑框架
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[问题定义] --> B[评估标准确定]
|
||||
B --> C[方案比较]
|
||||
C --> D[风险分析]
|
||||
D --> E[成本效益评估]
|
||||
E --> F[最终决策]
|
||||
```
|
||||
</reasoning>
|
||||
</thought>
|
||||
|
||||
<!-- 执行模式定义 -->
|
||||
<execution domain="decision-making">
|
||||
<criteria>
|
||||
# 技术选型标准
|
||||
|
||||
| 指标 | 权重 | 衡量方法 |
|
||||
|-----|------|---------|
|
||||
| 性能 | 高 | 基准测试 |
|
||||
| 可维护性 | 中 | 代码复杂度 |
|
||||
| 社区支持 | 中 | 活跃度指标 |
|
||||
| 成本 | 低 | TCO分析 |
|
||||
</criteria>
|
||||
|
||||
<constraint>
|
||||
# 决策约束
|
||||
|
||||
- 必须符合组织技术栈战略
|
||||
- 安全合规不可妥协
|
||||
- 团队学习曲线必须考虑
|
||||
</constraint>
|
||||
</execution>
|
||||
|
||||
<!-- 记忆模式定义 -->
|
||||
<memory domain="tech-knowledge">
|
||||
<store:execution>
|
||||
# 技术决策知识库
|
||||
|
||||
- 历史技术选型案例与后果
|
||||
- 技术趋势和演进路线
|
||||
- 行业最佳实践和标准
|
||||
|
||||
<rule>
|
||||
1. 基于事实和数据作决策，而非个人偏好
|
||||
2. 考虑长期影响，避免短期优化
|
||||
3. 平衡创新与稳定性
|
||||
</rule>
|
||||
</store:execution>
|
||||
</memory>
|
||||
</prompt>
|
||||
```
|
||||
@ -1,199 +0,0 @@
|
||||
# DPML思考模式提示词框架最佳实践
|
||||
|
||||
> **TL;DR:** 本文档提供DPML思考模式提示词框架的最佳实践指南，包括图形化表达原则、各类思维模式的推荐用法和具体示例。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 图形化表达原则
|
||||
|
||||
thought标签内应以图形为主要表达方式，辅以简洁文字说明。这样做的优势：
|
||||
- 思维结构直观可见
|
||||
- 关系与逻辑一目了然
|
||||
- 跨语言理解更容易
|
||||
- 思维模式界限更清晰
|
||||
|
||||
### 各子标签推荐图形
|
||||
|
||||
每种思维模式都有最适合的图形表达方式：
|
||||
|
||||
#### exploration - 思维导图
|
||||
|
||||
用于表达横向思维和概念发散，简单文字仅需说明核心问题和主要分支。
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((核心问题))
|
||||
可能性A
|
||||
子可能性A1
|
||||
子可能性A2
|
||||
可能性B
|
||||
子可能性B1
|
||||
可能性C
|
||||
```
|
||||
|
||||
#### reasoning - 推理图
|
||||
|
||||
用于表达纵向思维和逻辑推导，文字说明只需点明前提和结论间的关系。
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[前提] --> B[中间命题1]
|
||||
A --> C[中间命题2]
|
||||
B --> D[结论1]
|
||||
C --> E[结论2]
|
||||
```
|
||||
|
||||
#### plan - 流程图
|
||||
|
||||
用于表达计划思维和决策路径，文字仅需标注关键决策点和行动步骤。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[起点] --> B{判断条件}
|
||||
B -->|条件成立| C[执行步骤1]
|
||||
B -->|条件不成立| D[执行步骤2]
|
||||
C --> E[结果1]
|
||||
D --> F[结果2]
|
||||
```
|
||||
|
||||
#### challenge - 逆向思维导图
|
||||
|
||||
用于表达批判性思维和风险探索，与exploration采用相似的图形表达，但关注的是潜在问题和限制条件。
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((方案风险))
|
||||
技术风险
|
||||
可扩展性问题
|
||||
性能瓶颈
|
||||
实施风险
|
||||
资源不足
|
||||
时间限制
|
||||
业务风险
|
||||
用户接受度
|
||||
```
|
||||
|
||||
### Mermaid图表分类参考表
|
||||
|
||||
下表系统地列出了各种Mermaid图表类型及其适用的思维模式：
|
||||
|
||||
| 图表类型 | 思维模式 | 适用场景 | 优势 |
|
||||
|---------|----------|---------|------|
|
||||
| 思维导图(mindmap) | Exploration/Challenge | 概念发散、头脑风暴、风险识别 | 展示中心概念及其分支关系 |
|
||||
| 四象限图(quadrantChart) | Exploration/Challenge | 方案评估、风险分析、优先级划分 | 在两个维度上评估选项或风险 |
|
||||
| 流程图(flowchart) | Reasoning/Challenge | 逻辑推导、算法思路、决策分析、故障分析 | 清晰表达推理过程中的逻辑关系 |
|
||||
| 饼图(pie) | Reasoning | 比例分析、相对重要性评估 | 直观展示整体中各部分的占比 |
|
||||
| 类图(classDiagram) | Plan | 结构设计、概念分类、系统架构 | 展示实体间的层次和组织关系 |
|
||||
| 甘特图(gantt) | Plan | 项目规划、时间安排、任务依赖 | 展示任务的时间跨度和先后关系 |
|
||||
| 序列图(sequenceDiagram) | Plan | 交互设计、通信计划、协作过程 | 清晰展示实体间的消息传递和时序 |
|
||||
| 状态图(stateDiagram) | Plan | 状态管理、过程转换、行为模式 | 展示系统状态和触发转换的事件 |
|
||||
| 实体关系图(erDiagram) | Plan | 数据结构设计、系统建模 | 展示实体间的关系和属性 |
|
||||
| 时间线(timeline) | Reasoning | 历史分析、演变过程、发展轨迹 | 按时间顺序展示事件发展 |
|
||||
| 用户旅程图(journey) | Plan | 体验设计、流程优化、情感映射 | 展示用户交互过程和体验变化 |
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 基础示例
|
||||
|
||||
```xml
|
||||
<thought domain="design">
|
||||
<exploration>
|
||||
# 功能需求探索
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((用户需求))
|
||||
基础功能
|
||||
用户认证
|
||||
数据管理
|
||||
高级特性
|
||||
数据分析
|
||||
报表生成
|
||||
用户体验
|
||||
响应速度
|
||||
界面美观
|
||||
```
|
||||
</exploration>
|
||||
|
||||
<reasoning>
|
||||
# 技术选型分析
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[需求分析] --> B[前端技术选型]
|
||||
A --> C[后端技术选型]
|
||||
B --> D[React]
|
||||
B --> E[Vue]
|
||||
C --> F[Node.js]
|
||||
C --> G[Python]
|
||||
```
|
||||
</reasoning>
|
||||
</thought>
|
||||
```
|
||||
|
||||
### 高级示例
|
||||
|
||||
```xml
|
||||
<thought domain="architecture">
|
||||
<exploration>
|
||||
# 系统架构探索
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((微服务架构))
|
||||
服务拆分
|
||||
用户服务
|
||||
订单服务
|
||||
支付服务
|
||||
技术栈
|
||||
Spring Cloud
|
||||
Docker
|
||||
Kubernetes
|
||||
数据存储
|
||||
MySQL
|
||||
Redis
|
||||
MongoDB
|
||||
```
|
||||
</exploration>
|
||||
|
||||
<plan>
|
||||
# 实施计划
|
||||
|
||||
```mermaid
|
||||
gantt
|
||||
title 项目实施计划
|
||||
dateFormat YYYY-MM-DD
|
||||
section 基础设施
|
||||
环境搭建 :a1, 2024-01-01, 5d
|
||||
CI/CD配置 :a2, after a1, 3d
|
||||
section 开发
|
||||
用户服务 :a3, 2024-01-08, 10d
|
||||
订单服务 :a4, after a3, 12d
|
||||
section 测试
|
||||
集成测试 :a5, after a4, 5d
|
||||
```
|
||||
</plan>
|
||||
|
||||
<challenge>
|
||||
# 风险评估
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((潜在风险))
|
||||
技术风险
|
||||
服务间通信延迟
|
||||
数据一致性问题
|
||||
运维风险
|
||||
服务器成本
|
||||
监控复杂度
|
||||
团队风险
|
||||
学习曲线
|
||||
人员配置
|
||||
```
|
||||
</challenge>
|
||||
</thought>
|
||||
```
|
||||
|
||||
### 组件选择的灵活性
|
||||
|
||||
实际应用中，可根据角色定位和任务目标灵活选择所需的思考组件（exploration、challenge、reasoning、plan），不必全部包含四种模式。例如，执行者角色更侧重于reasoning和challenge，而设计者或决策者则更需要exploration和plan。可根据实际需求进行裁剪和组合，以适应不同的思考任务和角色分工。
|
||||
87
protocol/tag/memory.tag.md
Normal file
87
protocol/tag/memory.tag.md
Normal file
@ -0,0 +1,87 @@
|
||||
# DPML记忆模式提示词框架
|
||||
|
||||
> **TL;DR:** DPML记忆模式提示词框架定义了AI系统的记忆管理提示词模板，支持先验知识库定义与运行时记忆管理，包含知识库(knowledge)、评估(evaluate)、存储(store)和回忆(recall)四个核心组件，实现完整的记忆能力。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
DPML记忆模式提示词框架为AI系统提供完整的记忆能力提示词模板，主要功能包括：
|
||||
- 定义角色的知识库和初始认知结构
|
||||
- 提供运行时记忆的评估、存储和检索的标准化提示词机制
|
||||
- 实现跨会话的信息持久化提示词模板
|
||||
- 支持复杂的记忆关联和检索模式的提示词构建
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**框架名称:** `<memory>` (DPML记忆模式提示词框架)
|
||||
**版本:** 1.1.0
|
||||
**类别:** 记忆类提示词
|
||||
**状态:** 草稿
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
memory_element ::= '<memory' attributes? '>' memory_content '</memory>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
|
||||
memory_content ::= (text | knowledge_element | evaluate_element | store_element | recall_element)+
|
||||
|
||||
knowledge_element ::= '<knowledge>' knowledge_content '</knowledge>'
|
||||
evaluate_element ::= '<evaluate:thought>' thought_content '</evaluate:thought>'
|
||||
store_element ::= '<store:execution' attributes? '>' (text | execution_element)* '</store:execution>'
|
||||
recall_element ::= '<recall:thought>' thought_content '</recall:thought>'
|
||||
|
||||
knowledge_content ::= (* 任何文本内容，通常使用Markdown格式 *)
|
||||
thought_content ::= (* 符合thought协议的内容 *)
|
||||
execution_element ::= (* 符合execution协议的元素 *)
|
||||
|
||||
text ::= (* 任何文本内容 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
memory标签表示AI系统的记忆管理单元，定义了记忆的结构和操作方式。它由先验知识库定义和运行时记忆管理两大部分组成：
|
||||
|
||||
### 记忆结构
|
||||
|
||||
1. **`<knowledge>`**: 定义角色的先验知识库
|
||||
- 包含角色固有的、初始化的知识体系
|
||||
- 这些知识在角色创建时就已存在，不是运行时获取的
|
||||
- 构成角色认知和专业领域的基础框架
|
||||
- **重要特性**：knowledge标签内的所有内容和资源引用（无论是@file://、@http://还是其他协议）都应在角色初始化时预加载，而不是按需加载
|
||||
|
||||
### 记忆操作
|
||||
|
||||
memory标签包含三个核心子标签，分别对应记忆的三个操作阶段：
|
||||
|
||||
2. **`<evaluate:thought>`**：评估信息是否值得记忆
|
||||
- 通过thought协议实现评估过程
|
||||
- 判断信息的价值、相关性和可信度
|
||||
- 决定是否将信息存入记忆系统
|
||||
|
||||
3. **`<store:execution>`**：将信息存入记忆系统
|
||||
- 通过execution协议实现存储操作
|
||||
- 定义存储过程、规则和约束
|
||||
- 管理记忆的添加、更新和组织
|
||||
|
||||
4. **`<recall:thought>`**：从记忆系统检索并应用信息
|
||||
- 通过thought协议实现回忆过程
|
||||
- 判断何时需要检索特定记忆
|
||||
- 规划如何检索和应用记忆内容
|
||||
- 可以使用多种实现方式，包括但不限于资源引用
|
||||
- **注意**：与knowledge不同，recall标签中的资源引用默认是按需加载的
|
||||
|
||||
### 组件关系
|
||||
|
||||
四个核心组件之间具有明确的逻辑关系：
|
||||
- knowledge是静态基础，构成角色的知识背景
|
||||
- evaluate-store-recall构成动态记忆的完整循环
|
||||
- evaluate决定什么值得记忆
|
||||
- store定义如何保存记忆
|
||||
- recall描述何时以及如何使用记忆
|
||||
|
||||
记忆系统的运行遵循"评估-存储-回忆"的循环模式，在knowledge定义的知识框架上不断丰富和发展角色的认知能力。
|
||||
|
||||
Reference in New Issue
Block a user