更新DPML协议文档，新增属性约束部分，详细阐述属性的通用性、定义原则和规范管理，确保提示词的一致性和互操作性。同时，删除不再使用的执行、记忆、资源、角色和思考协议文档，优化代码库结构以提高可维护性。
This commit is contained in:
sean
60
protocol/tag/execution.tag.md
Normal file
60
protocol/tag/execution.tag.md
Normal file
@ -0,0 +1,60 @@
|
||||
# DPML执行模式提示词框架
|
||||
|
||||
> **TL;DR:** DPML执行模式提示词框架定义了结构化的执行类提示词模板，包含流程(Process)、指导原则(Guideline)、强制规则(Rule)、约束条件(Constraint)和评价标准(Criteria)五个核心子概念，用于指导AI系统完成具体任务。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
DPML执行模式提示词框架定义了AI系统执行任务的提示词模板，它的主要功能是：
|
||||
- 提供执行任务的结构化提示词定义
|
||||
- 通过标准化提示词明确执行的流程步骤、指导原则、规则、约束和评价标准
|
||||
- 帮助AI系统通过规范化提示词进行精确、可靠的任务执行
|
||||
- 提供执行状态追踪和错误处理的提示词模板
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
execution_element ::= '<execution' attributes? '>' content '</execution>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= (markdown_content | process_element | guideline_element | rule_element | constraint_element | criteria_element)+
|
||||
|
||||
process_element ::= '<process' attributes? '>' markdown_content '</process>'
|
||||
guideline_element ::= '<guideline' attributes? '>' markdown_content '</guideline>'
|
||||
rule_element ::= '<rule' attributes? '>' markdown_content '</rule>'
|
||||
constraint_element ::= '<constraint' attributes? '>' markdown_content '</constraint>'
|
||||
criteria_element ::= '<criteria' attributes? '>' markdown_content '</criteria>'
|
||||
|
||||
markdown_content ::= (* 任何有效的Markdown文本，可包含特定语法元素 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
execution标签表示一个完整的执行框架。标签内容可以包含五种不同概念的子标签，每个子标签都有明确的语义：
|
||||
|
||||
- **process**: 表示执行的具体步骤，包含正常和异常路径，是执行的核心路径定义
|
||||
- **guideline**: 表示建议性指导原则，具有灵活性和可变通性，用于推荐最佳实践
|
||||
- **rule**: 表示强制性行为准则，必须严格遵守，通常涉及安全、合规或核心质量要求
|
||||
- **constraint**: 表示客观限制条件，客观存在且不可改变，需要被动适应
|
||||
- **criteria**: 表示评价标准，用于判断执行结果是否满足要求
|
||||
|
||||
这五个子概念构成了完整的执行框架，从不同维度定义了AI系统如何执行任务。
|
||||
|
||||
### 优先级关系
|
||||
|
||||
execution框架内的子概念具有以下固定的优先级关系，这种关系定义了如何理解和解释这些概念：
|
||||
|
||||
1. **Constraint(约束)** - 最高优先级，表示客观存在的限制，不可违反
|
||||
2. **Rule(规则)** - 次高优先级，表示必须遵循的行为准则
|
||||
3. **Guideline(指导原则)** - 较低优先级，表示可灵活调整的建议性原则
|
||||
4. **Process(流程)** - 在约束和规则的框架内定义执行路径
|
||||
5. **Criteria(标准)** - 作为评价依据，验证执行结果是否满足要求
|
||||
|
||||
这种优先级关系是框架的核心语义特征：
|
||||
- 低优先级元素不能与高优先级元素产生冲突
|
||||
- Process必须在Constraint和Rule定义的边界内设计
|
||||
- Guideline在不违反Rule和Constraint的前提下可以灵活调整
|
||||
- Criteria需要考虑所有优先级更高的元素的要求
|
||||
|
||||
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定义的知识框架上不断丰富和发展角色的认知能力。
|
||||
|
||||
124
protocol/tag/resource.tag.md
Normal file
124
protocol/tag/resource.tag.md
Normal file
@ -0,0 +1,124 @@
|
||||
# DPML资源模式提示词框架
|
||||
|
||||
> **TL;DR:** DPML资源模式提示词框架定义了统一的资源引用提示词模板，支持通过`@协议名://路径`形式在提示词中访问和操作各类资源。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
DPML资源模式提示词框架用于定义特定类型的资源访问提示词，使开发者能够以标准化的方式在提示词中描述如何引用和处理各种资源。通过这个框架，可以明确资源提示词的引用语法、路径规则和查询参数，确保资源引用在不同环境中的一致性和可靠性。此框架是PromptX中资源引用协议（RP）在提示词层面的具体实现方式。
|
||||
|
||||
主要功能包括：
|
||||
- 定义资源提示词的标识和引用方式
|
||||
- 规范化资源路径的提示词语法结构和解析规则
|
||||
- 指定资源提示词支持的查询参数和格式
|
||||
- 提供资源类提示词的标准化示例
|
||||
|
||||
### 默认支持的通用协议
|
||||
|
||||
PromptX默认支持以下通用且已有共识的协议，这些协议符合`@协议名://路径`格式，遵循其业界标准语法和规则，无需在resource标签中重新定义：
|
||||
|
||||
| 协议名 | 描述 | 示例 |
|
||||
|-------|------|------|
|
||||
| file | 文件系统资源 | `@file://path/to/file.txt` |
|
||||
| http/https | HTTP/HTTPS网络资源 | `@https://example.com/api/data` |
|
||||
| ftp/sftp | 文件传输协议 | `@ftp://user:pass@host/path` |
|
||||
| ssh | 安全Shell协议 | `@ssh://user@host/path` |
|
||||
|
||||
这些通用协议的路径格式和查询参数遵循它们的标准规范。对于特定领域或自定义的协议，才需要使用resource标签进行详细定义。
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
resource_element ::= '<resource' ' protocol="' protocol_name '"' '>' content '</resource>'
|
||||
protocol_name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
content ::= (markdown_content | location_element | params_element)+
|
||||
|
||||
location_element ::= '<location>' markdown_content '</location>'
|
||||
params_element ::= '<params>' markdown_content '</params>'
|
||||
|
||||
markdown_content ::= (* 任何有效的Markdown文本，包括代码块、表格等 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
### 子标签语义
|
||||
|
||||
resource标签包含两个核心子标签，用于定义资源协议的具体内容：
|
||||
|
||||
- **location**：定义该资源协议的路径规则。通常采用EBNF形式化语法描述路径结构，并可包含示例说明。
|
||||
- **params**：定义该资源协议支持的查询参数。通常采用表格形式列出参数名称、类型、描述和用法示例。
|
||||
|
||||
location和params子标签共同构成资源协议的完整定义，前者规定了资源的定位方式，后者规定了资源的访问选项。这两部分内容决定了如何解析和处理资源引用。
|
||||
|
||||
### `@` 引用协议
|
||||
|
||||
|
||||
resource标签定义了一个资源协议，指定了如何使用`@`符号作为统一入口，遵循以下核心语法规则：
|
||||
|
||||
```ebnf
|
||||
resource_reference ::= '@' protocol_name ':' resource_location [query_params]
|
||||
resource_location ::= uri | nested_reference
|
||||
uri ::= protocol_name '://' path
|
||||
nested_reference ::= ['@'] protocol_name ':' resource_location
|
||||
path ::= path_segment {'/' path_segment}
|
||||
query_params ::= '?' param_name '=' param_value {'&' param_name '=' param_value}
|
||||
```
|
||||
|
||||
#### 基础资源引用
|
||||
|
||||
基础资源引用使用单一协议：
|
||||
```
|
||||
@protocol://path
|
||||
```
|
||||
|
||||
例如：
|
||||
- `@file://document.md` - 引用文件系统中的文档
|
||||
- `@http://example.com/api/data.json` - 引用网络资源
|
||||
- `@memory://user_preferences` - 引用内存中的数据
|
||||
|
||||
#### 嵌套资源引用
|
||||
|
||||
嵌套资源引用允许一个协议处理另一个协议的输出：
|
||||
|
||||
**完整形式**（内部使用@符号）：
|
||||
```
|
||||
@outer:@inner://path
|
||||
```
|
||||
|
||||
**简写形式**（内部省略@符号）：
|
||||
```
|
||||
@outer:inner://path
|
||||
```
|
||||
|
||||
例如：
|
||||
- `@thinking:@file://method.md` - 对文件内容应用thinking协议处理
|
||||
- `@execution:file://workflow.md` - 对文件内容应用execution协议处理
|
||||
- `@outer:middle:inner://resource` - 多层嵌套（从内向外处理）
|
||||
|
||||
#### 路径通配符
|
||||
|
||||
路径支持以下通配符模式：
|
||||
- `*` - 匹配单层中的任意文件或目录，如`@file://docs/*.md`
|
||||
- `**` - 匹配多层目录和文件，如`@file://src/**/*.js`
|
||||
- `*.ext` - 匹配特定扩展名的文件，如`@file://docs/*.txt`
|
||||
- `*.{ext1,ext2}` - 匹配多种扩展名，如`@file://src/*.{js,ts}`
|
||||
|
||||
#### 查询参数
|
||||
|
||||
查询参数提供额外的资源处理指令：
|
||||
```
|
||||
@protocol://path?param1=value1¶m2=value2
|
||||
```
|
||||
|
||||
例如：
|
||||
- `@file://document.md?line=5-10` - 只获取文件的第5-10行
|
||||
- `@http://api.example.com/data?format=json&cache=false` - 指定返回格式并禁用缓存
|
||||
|
||||
### 解析规则
|
||||
|
||||
1. 资源引用解析从左至右进行，先识别协议名称，再解析资源位置和查询参数
|
||||
2. 嵌套引用从内向外解析，内层资源引用的结果作为外层引用的输入
|
||||
3. 查询参数应用于资源加载后的处理阶段，不影响资源的基本定位
|
||||
4. 相对路径解析基于当前上下文的工作目录或基础路径
|
||||
|
||||
|
||||
65
protocol/tag/role.tag.md
Normal file
65
protocol/tag/role.tag.md
Normal file
@ -0,0 +1,65 @@
|
||||
# DPML角色合成提示词框架
|
||||
|
||||
> **TL;DR:** DPML角色合成提示词框架解释了如何通过组合思考模式、执行模式和记忆模式三大基础协议来构建完整的AI角色，支持不同类型角色的构建和定制。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
DPML角色合成提示词框架说明了如何通过基础协议的组合构建AI角色，它的主要功能是：
|
||||
- 提供角色构建的标准方法论
|
||||
- 指导如何将思考、执行和记忆协议组合以表达角色特性
|
||||
- 支持不同类型角色的灵活定制
|
||||
- 确保角色定义的一致性和完整性
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
role_composite ::= (thought_element | execution_element | memory_element)+
|
||||
|
||||
(* 复用现有协议的语法定义 *)
|
||||
thought_element ::= '<thought' attributes? '>' thought_content '</thought>'
|
||||
execution_element ::= '<execution' attributes? '>' execution_content '</execution>'
|
||||
memory_element ::= '<memory' attributes? '>' memory_content '</memory>'
|
||||
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
|
||||
(* 各协议内容定义见各自协议文档 *)
|
||||
thought_content ::= (* 见thought.protocol.md中的定义 *)
|
||||
execution_content ::= (* 见execution.protocol.md中的定义 *)
|
||||
memory_content ::= (* 见memory.protocol.md中的定义 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
角色是思考模式、执行模式和记忆模式三大基础协议的组合表达。每个协议分别定义了角色的不同方面：
|
||||
|
||||
- **thought(思考模式)**: 定义角色的思维方式、分析框架和对话风格
|
||||
- exploration: 角色的探索思维和创造性特点
|
||||
- reasoning: 角色的逻辑推理和分析方法
|
||||
- plan: 角色的计划制定和结构化能力
|
||||
- challenge: 角色的批判性思维和风险评估能力
|
||||
|
||||
- **execution(执行模式)**: 定义角色的行为规范、职责边界和工作流程
|
||||
- process: 角色执行任务的标准流程
|
||||
- guideline: 角色遵循的指导原则
|
||||
- rule: 角色必须遵守的强制规则
|
||||
- constraint: 角色面临的客观限制
|
||||
- criteria: 角色评估结果的标准
|
||||
|
||||
- **memory(记忆模式)**: 定义角色的知识储备、经验背景和专业领域
|
||||
- evaluate: 角色如何评估信息价值
|
||||
- store: 角色的知识结构和经验积累
|
||||
- recall: 角色的知识检索和应用方式
|
||||
|
||||
### 组合语义
|
||||
|
||||
在角色定义中，三大协议之间具有以下语义关系：
|
||||
|
||||
1. **互补性**: 思考、执行和记忆协议互相补充，共同构成完整角色特性
|
||||
2. **一致性**: 三个协议内容应保持内部一致，避免语义冲突
|
||||
3. **整体性**: 角色行为是三种协议共同作用的结果
|
||||
|
||||
角色组合时，各协议应保持语义上的协调，共同表达角色的完整特性。详细的组合策略和最佳实践见`practice/role-best-practice.md`文档。
|
||||
60
protocol/tag/thought.tag.md
Normal file
60
protocol/tag/thought.tag.md
Normal file
@ -0,0 +1,60 @@
|
||||
# DPML思考模式提示词框架
|
||||
|
||||
> **TL;DR:** DPML思考模式提示词框架定义了结构化的思考类提示词模板，支持四种核心思维模式的提示词构建：横向探索(exploration)、纵向推理(reasoning)、流程计划(plan)和批判挑战(challenge)，帮助AI系统进行系统性分析和推理。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
DPML思考模式提示词框架定义了AI系统进行思考分析的提示词模板和结构，它的主要功能是：
|
||||
- 提供结构化的思维分析提示词模板
|
||||
- 规范化思考类提示词的组织方式
|
||||
- 支持可视化思维导图和决策树的提示词表达
|
||||
- 帮助AI系统通过标准化提示词进行系统性、全面性的问题分析
|
||||
- 区分不同类型的思维模式提示词：探索、推理、计划和挑战
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
thought_element ::= '<thought' attributes? '>' content '</thought>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= (markdown_content | exploration_element | reasoning_element | plan_element | challenge_element)+
|
||||
markdown_content ::= (* 任何有效的Markdown文本，包括Mermaid图表 *)
|
||||
|
||||
exploration_element ::= '<exploration' attributes? '>' markdown_content '</exploration>'
|
||||
reasoning_element ::= '<reasoning' attributes? '>' markdown_content '</reasoning>'
|
||||
plan_element ::= '<plan' attributes? '>' markdown_content '</plan>'
|
||||
challenge_element ::= '<challenge' attributes? '>' markdown_content '</challenge>'
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
thought标签表示一个完整的思考过程或思维框架。标签内容可以包含四种不同思维模式的子标签，或直接使用Markdown格式表达思考内容。
|
||||
|
||||
子标签具有明确的语义：
|
||||
- **exploration**: 表示跳跃思考，发散性思维，生成可能性，寻找多种可能性、创新点和关联性
|
||||
- **reasoning**: 表示连续思考，收敛性思维，验证可能性，深入分析因果关系、逻辑链条
|
||||
- **plan**: 表示秩序思考，结构性思维，固化可能性，设计行动步骤、决策路径、组织结构、系统架构
|
||||
- **challenge**: 表示逆向跳跃思考，批判性思维，质疑可能性，寻找假设漏洞、识别潜在风险、测试极限条件
|
||||
|
||||
exploration和challenge是一对思维模式的正反两面：exploration向外发散寻找"可能是什么"，而challenge向内批判探究"可能不是什么"。二者都采用跳跃式思考，但方向相反。reasoning负责系统验证，而challenge主要提出问题点。
|
||||
|
||||
thought标签特别适合表达概念关系、逻辑推理和系统性思考，为AI提供思考分析的参考框架。
|
||||
|
||||
### 推荐的思考顺序
|
||||
|
||||
在实际思考过程中，推荐遵循如下顺序以获得系统性和全面性的分析结果：
|
||||
1. **探索（exploration）**：首先发散思考，提出尽可能多的可能性和创新点；
|
||||
2. **反思/批判（challenge）**：对探索阶段的内容进行批判性思考，识别潜在风险和假设漏洞；
|
||||
3. **推理（reasoning）**：对经过反思筛选的内容进行系统性推理和因果分析；
|
||||
4. **计划（plan）**：最后制定具体的行动方案和决策路径。
|
||||
|
||||
在复杂问题中，challenge和reasoning可多次交替，plan阶段也可穿插challenge以确保方案稳健性。
|
||||
|
||||
### 子标签的可选性
|
||||
|
||||
thought标签内的四种子标签（exploration、challenge、reasoning、plan）均为可选。实际的思考提示词可以只包含其中的一种、几种，或全部，具体内容由实际需求决定。
|
||||
|
||||
对于提示词的理解者来说，只需知道这些子标签不是必须全部出现，遇到哪些子标签就理解哪些即可，无需关心未出现的部分。
|
||||
Reference in New Issue
Block a user