删除多个不再使用的协议文档，包括命令执行思维框架、上下文协议、经验协议、角色协议、任务协议和资源引用协议，清理代码库以提高可维护性。
This commit is contained in:
sean
@ -1,137 +0,0 @@
|
||||
<thinking type="analysis" domain="command-execution" method="systematic">
|
||||
|
||||
# 命令行执行思维框架
|
||||
|
||||
## 核心思考维度
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((命令行执行))
|
||||
命令分析
|
||||
目的理解
|
||||
语法结构
|
||||
预期输出
|
||||
环境评估
|
||||
平台差异
|
||||
上下文状态
|
||||
必要依赖
|
||||
风险考量
|
||||
数据安全
|
||||
权限需求
|
||||
可逆性
|
||||
优化思考
|
||||
效率提升
|
||||
可读性
|
||||
组合优化
|
||||
结果解读
|
||||
成功标志
|
||||
异常分析
|
||||
后续行动
|
||||
```
|
||||
|
||||
## 命令分析思考
|
||||
|
||||
### 目的理解
|
||||
- 这个命令要完成什么任务？
|
||||
- 这个命令在当前任务流程中的作用是什么？
|
||||
- 有没有更符合意图的替代命令？
|
||||
|
||||
### 语法结构
|
||||
- 命令的基本结构是否正确？
|
||||
- 参数使用是否恰当？
|
||||
- 是否存在语法优化空间？
|
||||
|
||||
### 预期输出
|
||||
- 预期得到什么样的输出？
|
||||
- 如何判断命令执行是否达到预期？
|
||||
|
||||
## 环境评估思考
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[环境分析] --> B{平台类型?}
|
||||
B -->|Windows| C[考虑CMD/PowerShell语法]
|
||||
B -->|Unix/Linux| D[考虑Bash/Zsh语法]
|
||||
B -->|macOS| E[考虑macOS特性]
|
||||
C & D & E --> F{工作目录正确?}
|
||||
F -->|否| G[调整工作目录]
|
||||
F -->|是| H{依赖检查}
|
||||
H -->|缺失| I[安装/加载依赖]
|
||||
H -->|完整| J[环境就绪]
|
||||
|
||||
style A fill:#4da6ff,stroke:#0066cc,color:white
|
||||
style B fill:#ffa64d,stroke:#cc7a30,color:white
|
||||
style F fill:#4dbb5f,stroke:#36873f,color:white
|
||||
style H fill:#d94dbb,stroke:#a3378a,color:white
|
||||
```
|
||||
|
||||
### 上下文状态
|
||||
- 当前工作目录是否正确？
|
||||
- 是否已经满足命令执行的前提条件？
|
||||
- 是否需要先设置环境变量？
|
||||
|
||||
## 风险考量思考
|
||||
|
||||
### 安全评估表
|
||||
| 风险类型 | 问题思考 | 缓解措施 |
|
||||
|---------|---------|---------|
|
||||
| 数据安全 | 命令是否会修改或删除重要数据？ | 检查命令范围，提前备份 |
|
||||
| 权限控制 | 命令是否需要特定权限？ | 验证权限是否最小化 |
|
||||
| 中断风险 | 命令是否可能造成系统中断？ | 评估执行时间点，准备回滚方案 |
|
||||
| 可逆性 | 操作是否可逆？ | 设计回滚策略 |
|
||||
|
||||
## 优化思考
|
||||
|
||||
### 效率提升
|
||||
- 能否通过管道组合多个命令？
|
||||
- 是否可以使用通配符简化操作？
|
||||
- 是否可以通过别名或函数封装常用操作？
|
||||
|
||||
### 命令优化示例
|
||||
```
|
||||
# 优化前
|
||||
find . -name "*.txt" | xargs grep "pattern"
|
||||
|
||||
# 优化后
|
||||
grep -r "pattern" --include="*.txt" .
|
||||
```
|
||||
|
||||
## 结果解读思考
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> 执行命令
|
||||
执行命令 --> 成功: 返回码为0
|
||||
执行命令 --> 失败: 返回码非0
|
||||
|
||||
成功 --> 结果分析: 验证输出
|
||||
失败 --> 错误分析: 诊断问题
|
||||
|
||||
结果分析 --> 后续行动
|
||||
错误分析 --> 修正策略
|
||||
|
||||
修正策略 --> 执行命令: 重试
|
||||
后续行动 --> [*]
|
||||
```
|
||||
|
||||
### 异常分析思考
|
||||
- 错误信息揭示了什么问题？
|
||||
- 是命令本身错误还是环境问题？
|
||||
- 有没有常见的解决方案？
|
||||
|
||||
### 后续行动
|
||||
- 基于执行结果，下一步应该做什么？
|
||||
- 是否需要保存或处理输出？
|
||||
- 是否需要通知用户特定信息？
|
||||
|
||||
## 决策模型
|
||||
|
||||
处理命令行任务的决策模型:
|
||||
|
||||
1. **理解** - 深入理解命令目的和上下文
|
||||
2. **评估** - 全面评估环境条件和执行风险
|
||||
3. **优化** - 思考如何使命令更高效和安全
|
||||
4. **执行** - 在适当条件下执行命令
|
||||
5. **分析** - 解读结果并决定后续行动
|
||||
|
||||
</thinking>
|
||||
@ -1,81 +0,0 @@
|
||||
# context 应用协议
|
||||
|
||||
> **TL;DR:** context标签用于定义AI系统中各类上下文信息的结构和语义，采用简单直观的HTML风格属性标记，专注于"什么是上下文"，是实现CAP(情境感知提示模式)的核心表达机制。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<context>`
|
||||
|
||||
### 目的与功能
|
||||
|
||||
context标签在提示工程中提供了情境信息的标准定义方式，主要功能包括：
|
||||
- 定义上下文信息的名称和分类
|
||||
- 提供简洁明了的上下文描述
|
||||
- 支持基本的元数据标注
|
||||
- 为其他模式提供情境依赖的决策支持
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
context_element ::= '<context' attributes? '>' content '</context>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= text
|
||||
text ::= (* 任何文本内容，用于简要描述上下文 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
context标签用于在提示词中定义上下文信息。采用简洁的HTML风格属性标记方式，通过id指定唯一标识符，通过class指定分类，标签内容直接描述该上下文的含义。它作为CAP模式的具体实现，为AI系统提供了清晰简洁的上下文定义能力。实际的上下文感知执行逻辑由execution协议负责实现。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 核心属性
|
||||
|
||||
context标签主要使用以下属性：
|
||||
|
||||
- **id**: 定义上下文的唯一标识符，如`id="rootDir"`, `id="userName"`
|
||||
- **class**: 定义上下文的分类/维度，如`class="project"`, `class="user"`, `class="system"`
|
||||
|
||||
|
||||
### 内容组织
|
||||
|
||||
context标签内容应简洁明了，直接描述该上下文的含义和用途，无需复杂的结构和格式。
|
||||
|
||||
### 维度分类指南
|
||||
|
||||
使用class属性定义context维度时，建议遵循以下标准分类：
|
||||
|
||||
- **project**: 项目相关上下文，如根目录、语言、框架等
|
||||
- **user**: 用户相关上下文，如用户名、偏好、技能水平等
|
||||
- **system**: 系统相关上下文，如操作系统、硬件资源等
|
||||
- **environment**: 环境相关上下文，如IDE、终端、网络状况等
|
||||
- **task**: 任务相关上下文，如当前目标、进度、限制条件等
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
```html
|
||||
<!-- 项目根目录 -->
|
||||
<context id="rootDir" class="project">项目根目录路径</context>
|
||||
|
||||
<!-- 项目编程语言 -->
|
||||
<context id="language" class="project">项目主要编程语言</context>
|
||||
|
||||
<!-- 项目框架 -->
|
||||
<context id="frameworks" class="project">项目使用的框架列表</context>
|
||||
|
||||
<!-- 操作系统类型 -->
|
||||
<context id="osType" class="system">操作系统类型</context>
|
||||
|
||||
<!-- 用户名称 -->
|
||||
<context id="userName" class="user">用户名称</context>
|
||||
|
||||
<!-- IDE类型 -->
|
||||
<context id="ideType" class="environment">集成开发环境类型</context>
|
||||
|
||||
<!-- 任务目标 -->
|
||||
<context id="taskGoal" class="task">当前任务的主要目标</context>
|
||||
```
|
||||
@ -1,75 +0,0 @@
|
||||
# experience 应用协议
|
||||
|
||||
> **TL;DR:** experience标签用于定义AI系统中经验知识的结构和语义，采用简单直观的HTML风格属性标记，专注于"什么是经验"，是实现系统自我优化和经验积累的核心表达机制。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<experience>`
|
||||
|
||||
### 目的与功能
|
||||
|
||||
experience标签在提示工程中提供了经验知识的标准定义方式，主要功能包括：
|
||||
- 定义经验信息的名称和分类
|
||||
- 提供简洁明了的经验描述
|
||||
- 支持基本的元数据标注
|
||||
- 为系统提供可复用的问题解决知识
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
experience_element ::= '<experience' attributes? '>' content '</experience>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= text
|
||||
text ::= (* 任何文本内容，用于简要描述经验 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
experience标签用于在提示词中定义经验知识。采用简洁的HTML风格属性标记方式，通过id指定唯一标识符，通过class指定经验的分类维度，标签内容直接描述该经验的含义。它作为系统知识积累的具体实现，为AI系统提供了清晰简洁的经验定义能力。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 核心属性
|
||||
|
||||
experience标签主要使用以下属性：
|
||||
|
||||
- **id**: 定义经验的唯一标识符，如`id="solution_pattern"`，`id="error_response"`
|
||||
- **class**: 定义经验的分类/维度，如`class="problem_solving"`，`class="system"`，`class="user"`
|
||||
|
||||
### 内容组织
|
||||
|
||||
experience标签内容应简洁明了，直接描述该经验的含义和用途，无需复杂的结构和格式。
|
||||
|
||||
### 维度分类指南
|
||||
|
||||
使用class属性定义experience维度时，建议遵循以下标准分类：
|
||||
|
||||
- **problem_solving**: 问题解决相关经验，如常见问题的解决方案和策略
|
||||
- **system**: 系统相关经验，如系统行为模式、限制和最佳实践
|
||||
- **user**: 用户相关经验，如用户交互模式和偏好
|
||||
- **domain**: 领域相关经验，如特定专业领域的知识和最佳实践
|
||||
- **optimization**: 优化相关经验，如性能提升和效率改进的方法
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
```html
|
||||
<!-- 问题解决经验 -->
|
||||
<experience id="error_handling_strategy" class="problem_solving">处理错误的最佳策略</experience>
|
||||
|
||||
<!-- 系统经验 -->
|
||||
<experience id="resource_limitation" class="system">系统资源限制与应对策略</experience>
|
||||
|
||||
<!-- 用户经验 -->
|
||||
<experience id="user_interaction_pattern" class="user">用户交互偏好与行为模式</experience>
|
||||
|
||||
<!-- 领域经验 -->
|
||||
<experience id="code_optimization_approach" class="domain">代码优化方法论</experience>
|
||||
|
||||
<!-- 优化经验 -->
|
||||
<experience id="performance_tuning" class="optimization">系统性能调优技巧</experience>
|
||||
```
|
||||
|
||||
@ -1,72 +1,194 @@
|
||||
# memory 应用协议
|
||||
|
||||
> **TL;DR:** memory标签用于定义AI系统的记忆持久化能力，支持跨会话知识存储和检索，采用简单直观的方式表达记忆内容。
|
||||
> **TL;DR:** memory标签定义了AI系统的记忆管理框架，支持三种记忆类型(陈述性、程序性、情景记忆)和完整的记忆生命周期(评估、存储、调用)，使AI能够高效地创建和利用长期知识。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<memory>`
|
||||
**版本:** 1.0.0
|
||||
**类别:** 记忆
|
||||
**状态:** 草稿
|
||||
|
||||
### 目的与功能
|
||||
|
||||
memory标签定义了AI系统记忆的内容与标识，主要功能包括：
|
||||
- 提供简洁的记忆内容定义方式
|
||||
- 通过唯一标识符区分不同记忆
|
||||
- 实现跨会话的信息传递能力
|
||||
- 支持记忆内容的简明描述
|
||||
memory协议为AI系统提供完整的记忆能力框架，主要功能包括：
|
||||
- 定义不同类型记忆的结构和语义
|
||||
- 提供记忆评估、存储和检索的标准化机制
|
||||
- 实现跨会话的信息持久化
|
||||
- 支持复杂的记忆关联和检索模式
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
memory_element ::= '<memory' attributes? '>' content '</memory>'
|
||||
memory_element ::= '<memory' attributes? '>' memory_content '</memory>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= text
|
||||
text ::= (* 任何文本内容，用于描述记忆 *)
|
||||
|
||||
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标签用于在提示词中定义需要持久化的记忆内容。通过id属性提供唯一标识，标签内容直接描述该记忆的含义。它使系统能够保存和利用过去的交互经验和知识，从而增强系统在长期交互中的连续性和一致性。
|
||||
memory标签表示AI系统的记忆管理单元，定义了记忆的结构和操作方式。它使用三层机制管理记忆的完整生命周期：
|
||||
|
||||
### 记忆操作
|
||||
|
||||
memory标签包含三个核心子标签，分别对应记忆的三个操作阶段：
|
||||
|
||||
1. **`<evaluate:thought>`**：评估信息是否值得记忆
|
||||
- 通过thought协议实现评估过程
|
||||
- 判断信息的价值、相关性和可信度
|
||||
- 决定是否将信息存入记忆系统
|
||||
|
||||
2. **`<store:execution>`**：将信息存入记忆系统
|
||||
- 通过execution协议实现存储操作
|
||||
- 定义存储过程、规则和约束
|
||||
- 管理记忆的添加、更新和组织
|
||||
|
||||
3. **`<recall:resource>`**：从记忆系统检索信息
|
||||
- 通过resource协议实现检索操作
|
||||
- 使用@memory://路径引用存储的记忆
|
||||
- 支持过滤、分页和条件检索
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 核心属性
|
||||
### 记忆类型选择
|
||||
|
||||
memory标签主要使用以下属性：
|
||||
协议实现可以根据需求采用不同的记忆类型分类方法，以下是基于认知心理学的常见分类：
|
||||
|
||||
- **id**: 记忆的唯一标识符，如`id="context"`, `id="history"`, `id="preferences"`
|
||||
1. **陈述性记忆(declarative)**：事实性知识，包括：
|
||||
- 语义记忆：通用事实，如"Python是编程语言"
|
||||
- 时态记忆：时间相关信息，如"上次会话在昨天"
|
||||
|
||||
### 可选属性
|
||||
2. **程序性记忆(procedural)**：过程和技能知识，如：
|
||||
- 操作步骤：如"解决环境配置问题的方法"
|
||||
- 行动模式：如"用户代码风格偏好"
|
||||
|
||||
在特定场景下，也可以使用以下可选属性：
|
||||
3. **情景记忆(episodic)**：特定经历和场景，如：
|
||||
- 交互记录：如"用户之前遇到的报错"
|
||||
- 场景重建：如"项目开发历程"
|
||||
|
||||
- **type**: 记忆类型，如`type="session"`, `type="long-term"`, `type="episodic"`
|
||||
- **priority**: 记忆优先级，如`priority="high"`, `priority="normal"`, `priority="low"`
|
||||
不同类型记忆的选择建议：
|
||||
- 存储事实性信息时，考虑使用陈述性记忆方式
|
||||
- 存储方法和步骤时，考虑使用程序性记忆方式
|
||||
- 存储具体交互经历时，考虑使用情景记忆方式
|
||||
|
||||
### 内容组织
|
||||
### 记忆操作使用
|
||||
|
||||
memory标签内容应简洁明了，直接描述该记忆的含义和用途，无需复杂的结构和格式。
|
||||
- **evaluate最佳实践**：
|
||||
- 明确设定评估标准
|
||||
- 综合考虑信息的稀有性、实用性和时效性
|
||||
- 避免过度记忆导致的信息冗余
|
||||
|
||||
- **store最佳实践**：
|
||||
- 为记忆提供足够的上下文
|
||||
- 建立适当的记忆关联
|
||||
- 设置合理的过期策略
|
||||
|
||||
- **recall最佳实践**：
|
||||
- 优先使用精确查询
|
||||
- 指定合理的置信度阈值
|
||||
- 处理记忆缺失的回退策略
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 基础使用示例
|
||||
|
||||
```html
|
||||
<!-- 上下文感知记忆 -->
|
||||
<memory id="context">上下文感知记忆</memory>
|
||||
<!-- 简单的记忆定义 -->
|
||||
<memory id="os_preference">
|
||||
用户使用MacOS系统
|
||||
</memory>
|
||||
|
||||
<!-- 对话历史记忆 -->
|
||||
<memory id="history">用户对话历史记录</memory>
|
||||
<!-- 带评估的记忆创建 -->
|
||||
<memory id="code_style">
|
||||
<evaluate:thought>
|
||||
<reasoning>
|
||||
用户连续三次使用了相同的代码风格(缩进2空格、驼峰命名)，
|
||||
这是重要的个人偏好信息，应记住以提供一致的代码建议。
|
||||
评分：实用性=8，稳定性=9，总分8.5 > 阈值7.5
|
||||
</reasoning>
|
||||
<decision>store</decision>
|
||||
</evaluate:thought>
|
||||
|
||||
<!-- 用户偏好记忆 -->
|
||||
<memory id="preferences">用户个性化偏好设置</memory>
|
||||
|
||||
<!-- 项目信息记忆 -->
|
||||
<memory id="project">项目相关信息和配置</memory>
|
||||
|
||||
<!-- 决策历史记忆 -->
|
||||
<memory id="decisions">重要决策历史记录</memory>
|
||||
<store:execution>
|
||||
{
|
||||
"indent": "2spaces",
|
||||
"naming": "camelCase",
|
||||
"brackets": "sameLine"
|
||||
}
|
||||
</store:execution>
|
||||
</memory>
|
||||
```
|
||||
|
||||
> **注意**: 实际的记忆存储和检索逻辑应由系统底层实现，memory标签专注于定义记忆的标识和基本含义。
|
||||
### 高级使用示例
|
||||
|
||||
```html
|
||||
<!-- 完整的记忆生命周期示例 -->
|
||||
<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,121 +0,0 @@
|
||||
# role 应用协议
|
||||
|
||||
> **TL;DR:** role标签定义AI系统在响应过程中扮演的单一专业角色，提供明确的职责、专业知识和行为准则，是实现RRP(角色响应协议)的核心表达机制。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<role>`
|
||||
|
||||
### 目的与功能
|
||||
|
||||
role标签为AI系统提供清晰的角色定义框架，主要功能包括：
|
||||
- 定义AI需要扮演的专业角色特性和领域知识
|
||||
- 提供角色专有的行为准则和响应原则
|
||||
- 设置角色视角下的专业知识体系和术语
|
||||
- 明确角色的职责范围和响应边界
|
||||
|
||||
## 🧰 设计原则
|
||||
|
||||
定义role应用协议时，特别强调以下核心设计原则：
|
||||
|
||||
1. **职责单一**：每个role专注于定义单一专业角色，不包含角色切换机制
|
||||
2. **约定大于配置**：使用合理的默认角色结构，减少复杂配置
|
||||
3. **最小可行产品**：专注于角色的核心定义要素，确保基础使用场景
|
||||
4. **奥卡姆剃刀原则**：保持角色定义的简洁性，避免不必要的复杂属性
|
||||
5. **一致性**：与其他协议保持一致的设计风格
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
role_element ::= '<role' attributes? '>' content '</role>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= markdown_content
|
||||
markdown_content ::= (* 任何有效的Markdown文本，描述角色特性 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
role标签用于明确定义AI系统在特定场景中需要扮演的专业角色。它提供了角色的专业背景、知识领域、行为准则和预期输出格式等信息，使AI能够从特定专业角色的视角生成更加专业、一致和符合预期的响应。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 推荐属性
|
||||
|
||||
可以考虑使用以下属性来增强role标签的语义：
|
||||
|
||||
- **name**: 角色名称，如`name="软件架构师"`
|
||||
- **domain**: 专业领域，如`domain="系统设计"`
|
||||
- **expertise**: 专业水平，如`expertise="expert"`
|
||||
- **tone**: 沟通风格，如`tone="professional"`
|
||||
- **perspective**: 思考视角，如`perspective="systems-thinking"`
|
||||
|
||||
### 内容组织
|
||||
|
||||
推荐在标签内使用以下结构组织内容：
|
||||
|
||||
1. **职责范围**: 明确定义角色的职责边界
|
||||
2. **专业知识**: 列出角色所具备的专业知识体系
|
||||
3. **行为准则**: 描述角色的专业行为标准
|
||||
4. **术语表**: 角色常用的专业术语定义
|
||||
5. **输出格式**: 角色回应的标准格式要求
|
||||
|
||||
### 可视化表达
|
||||
|
||||
角色知识结构可使用mermaid图表表示：
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((软件架构师))
|
||||
系统设计
|
||||
高可用性
|
||||
可扩展性
|
||||
性能优化
|
||||
技术选型
|
||||
框架评估
|
||||
技术栈兼容性
|
||||
架构模式
|
||||
微服务
|
||||
事件驱动
|
||||
领域驱动
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
```xml
|
||||
<role name="软件架构师" domain="系统设计" expertise="expert" tone="professional">
|
||||
## 职责范围
|
||||
- 分析系统需求并转化为技术架构设计
|
||||
- 评估并选择适合项目的技术栈和架构模式
|
||||
- 设计系统组件结构和交互关系
|
||||
- 确定非功能性需求的技术实现方案
|
||||
|
||||
## 专业知识
|
||||
- 分布式系统架构设计原则
|
||||
- 微服务架构模式与实践
|
||||
- API设计与版本控制策略
|
||||
- 系统性能优化与可扩展性保障
|
||||
|
||||
## 行为准则
|
||||
- 始终从整体系统视角思考问题
|
||||
- 关注架构决策对可维护性和未来扩展的影响
|
||||
- 使用准确的技术术语和清晰的图示表达设计思路
|
||||
- 平衡技术理想与实际约束，提供务实可行的方案
|
||||
|
||||
## 术语表
|
||||
- **解耦**: 降低系统组件间的依赖程度
|
||||
- **服务边界**: 微服务架构中的职责划分边界
|
||||
- **技术债**: 设计或实现中的妥协导致的未来额外工作
|
||||
|
||||
## 输出格式
|
||||
架构设计文档应包含：
|
||||
1. 架构概述
|
||||
2. 组件设计
|
||||
3. 接口规范
|
||||
4. 部署模型
|
||||
5. 关键技术决策说明
|
||||
</role>
|
||||
```
|
||||
@ -1,190 +0,0 @@
|
||||
# task 应用协议
|
||||
|
||||
> **TL;DR:** task标签用于定义可重用的任务模板，支持任务的静态描述和动态执行，是实现任务模板化和标准化执行的核心机制。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<task>`
|
||||
|
||||
### 目的与功能
|
||||
|
||||
task标签提供了任务模板化的框架，主要功能包括：
|
||||
- 定义标准化的任务结构和执行流程
|
||||
- 支持任务的参数化配置和动态绑定
|
||||
- 提供任务执行的验证和约束条件
|
||||
- 实现任务模板的复用和组合
|
||||
- 容器化封装任务执行环境和上下文
|
||||
|
||||
## 🧰 设计原则
|
||||
|
||||
定义task应用协议时，特别强调以下核心设计原则：
|
||||
|
||||
1. **职责单一**：每个task专注于定义单一完整的任务流程
|
||||
2. **约定大于配置**：使用合理的默认任务结构，减少不必要的配置
|
||||
3. **最小可行产品**：专注于任务定义的核心要素，确保基础执行场景
|
||||
4. **奥卡姆剃刀原则**：保持任务定义的简洁性，避免过度复杂的结构
|
||||
5. **一致性**：与其他协议保持一致的设计风格
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
task_element ::= '<task' attributes? '>' content '</task>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= markdown_content
|
||||
markdown_content ::= (* 任何有效的Markdown文本，描述任务结构 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
task标签用于定义可重用的任务模板。它提供了任务的结构化描述，包括目标定义、执行环境和成功标准，使任务可以被标准化执行和重复使用。通过与role标签的配合，可以实现特定角色执行特定任务的精确控制。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 核心设计原则
|
||||
|
||||
在设计task标签时，建议遵循以下核心原则：
|
||||
|
||||
1. **职责单一**：每个task专注于定义单一完整的任务流程
|
||||
2. **约定大于配置**：使用合理的默认任务结构，减少不必要的配置
|
||||
3. **最小可行产品**：专注于任务定义的核心要素，确保基础执行场景
|
||||
4. **奥卡姆剃刀原则**：保持任务定义的简洁性，避免过度复杂的结构
|
||||
5. **一致性**：与其他协议保持一致的设计风格
|
||||
|
||||
### 推荐属性
|
||||
|
||||
可以考虑使用以下属性来增强task标签的语义：
|
||||
|
||||
- **id**: 任务唯一标识，如`id="code-review-task"`
|
||||
- **type**: 任务类型，如`type="analysis"`
|
||||
- **priority**: 任务优先级，如`priority="high"`
|
||||
- **timeout**: 执行超时时间，如`timeout="30m"`
|
||||
- **requires**: 依赖的角色或资源，如`requires="architect"`
|
||||
|
||||
### OES框架内容组织
|
||||
|
||||
强烈推荐使用OES框架组织任务内容，这种结构借鉴了容器化思想，使任务更加清晰和可执行：
|
||||
|
||||
1. **目标(Objective)**
|
||||
- 明确定义任务的具体预期结果
|
||||
- 设定任务边界和约束
|
||||
- 说明任务的价值和意义
|
||||
|
||||
2. **环境(Environment)**
|
||||
- **背景信息**：任务相关的上下文和背景
|
||||
- **资源需求**：执行任务所需的数据、工具和参考资料
|
||||
- **约束条件**：技术、业务和资源限制
|
||||
- **执行规范**：风格指南、质量标准和工作流程
|
||||
- **上下文关联**：与其他任务的关系和依赖
|
||||
|
||||
3. **成功标准(Success Criteria)**
|
||||
- **基础达标**：最低要求和基本功能
|
||||
- **预期品质**：符合项目整体质量标准的指标
|
||||
- **验证方法**：如何验证任务是否成功完成
|
||||
- **结果格式**：交付物的具体格式和内容要求
|
||||
|
||||
### 任务网络构建
|
||||
|
||||
对于复杂项目，推荐构建任务网络，通过以下方式连接多个任务：
|
||||
|
||||
1. **垂直连接**：上级任务的成功标准成为下级任务的目标
|
||||
2. **水平连接**：前序任务的产物成为后续任务的环境组成部分
|
||||
|
||||
### 可视化表达
|
||||
|
||||
任务执行流程可使用mermaid图表表示：
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[输入验证] --> B{参数检查}
|
||||
B -->|通过| C[执行准备]
|
||||
B -->|失败| H[错误处理]
|
||||
C --> D[主要步骤]
|
||||
D --> E[结果验证]
|
||||
E -->|成功| F[输出结果]
|
||||
E -->|失败| G[回滚处理]
|
||||
H --> I[任务终止]
|
||||
G --> I
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
```xml
|
||||
<task id="code-review" type="analysis" requires="senior-developer" timeout="30m">
|
||||
## 目标(Objective)
|
||||
对提交的代码变更进行全面的代码审查，确保代码质量和一致性，并提供具体改进建议。
|
||||
目标范围包括代码风格、性能、安全性和业务逻辑正确性评估。
|
||||
|
||||
## 环境(Environment)
|
||||
### 背景信息
|
||||
- 项目使用Git流程管理代码
|
||||
- 团队遵循Google代码风格指南
|
||||
- 代码审查是合并请求流程的必要环节
|
||||
|
||||
### 资源需求
|
||||
- **diff_files**: 需要审查的文件列表
|
||||
- **base_branch**: 基准分支名称
|
||||
- **review_focus**: 重点关注的方面
|
||||
|
||||
### 约束条件
|
||||
- 审查必须在30分钟内完成
|
||||
- 必须使用团队标准的代码审查清单
|
||||
- 严重安全问题需立即上报
|
||||
|
||||
### 执行规范
|
||||
1. **预检查**
|
||||
- 验证文件可访问性
|
||||
- 检查diff格式正确性
|
||||
- 确认审查权限
|
||||
|
||||
2. **静态分析**
|
||||
- 代码风格检查
|
||||
- 潜在问题扫描
|
||||
- 复杂度评估
|
||||
|
||||
3. **逻辑审查**
|
||||
- 业务逻辑正确性
|
||||
- 异常处理完整性
|
||||
- 性能影响评估
|
||||
|
||||
4. **安全审查**
|
||||
- 安全漏洞检查
|
||||
- 敏感信息扫描
|
||||
- 权限控制审查
|
||||
|
||||
## 成功标准(Success Criteria)
|
||||
### 基础达标
|
||||
- 所有必要的检查项已完成
|
||||
- 没有严重或阻塞性问题
|
||||
- 代码符合团队编码标准
|
||||
|
||||
### 预期品质
|
||||
- 提供至少3个有价值的改进建议
|
||||
- 验证测试覆盖率达到团队标准
|
||||
- 确认新代码没有引入性能退化
|
||||
|
||||
### 结果格式
|
||||
```json
|
||||
{
|
||||
"status": "approved|rejected|needs_revision",
|
||||
"summary": "审查总结",
|
||||
"issues": [
|
||||
{
|
||||
"type": "security|performance|style",
|
||||
"severity": "high|medium|low",
|
||||
"description": "问题描述",
|
||||
"suggestion": "改进建议"
|
||||
}
|
||||
],
|
||||
"metrics": {
|
||||
"files_reviewed": 10,
|
||||
"issues_found": 5,
|
||||
"review_time": "25m"
|
||||
}
|
||||
}
|
||||
```
|
||||
</task>
|
||||
```
|
||||
@ -1,235 +0,0 @@
|
||||
# 资源引用(RP) 模式协议
|
||||
|
||||
> **TL;DR:** 资源引用协议定义了使用@符号统一引用各类资源的语法规则，支持基础资源定位和嵌套引用，实现提示词中的资源无缝集成。
|
||||
|
||||
## 🔍 协议概述
|
||||
|
||||
**协议名称:** 资源引用协议 (Resource Protocol, RP)
|
||||
**版本:** 1.0.0
|
||||
**状态:** 草稿
|
||||
**作者:** PromptX团队
|
||||
**创建日期:** 2023-06-25
|
||||
**最后更新:** 2023-06-25
|
||||
|
||||
### 目的与范围
|
||||
|
||||
资源引用协议旨在提供一种统一的语法机制，使提示词能够无缝引用和整合各种类型的资源，包括文件、目录、网络资源以及特定的应用协议。本协议定义了资源定位的基本语法、组合规则和链式调用机制，使提示词能够更加灵活地整合和使用外部资源。
|
||||
|
||||
### 相关协议
|
||||
|
||||
- DPML核心协议：提供基础的标记语言结构
|
||||
- 应用协议：如thinking、executing等可以与资源协议组合使用
|
||||
|
||||
## 📝 语法规则
|
||||
|
||||
### 形式化定义
|
||||
|
||||
```ebnf
|
||||
resource_reference ::= '@' protocol_name ':' resource_location [query_params]
|
||||
resource_location ::= uri | nested_reference
|
||||
uri ::= protocol_name '://' path
|
||||
nested_reference ::= ['@'] protocol_name ':' resource_location
|
||||
|
||||
protocol_name ::= alphanumeric_string
|
||||
path ::= path_segment {'/' path_segment}
|
||||
path_segment ::= alphanumeric_string | '.' | '..' | wildcard_pattern
|
||||
wildcard_pattern ::= '*' | '**' | '*.' file_extension
|
||||
|
||||
query_params ::= '?' param_name '=' param_value {'&' param_name '=' param_value}
|
||||
param_name ::= alphanumeric_string
|
||||
param_value ::= alphanumeric_string | quoted_string
|
||||
|
||||
alphanumeric_string ::= (letter | digit | '_' | '-')+
|
||||
letter ::= 'a' | 'b' | ... | 'z' | 'A' | 'B' | ... | 'Z'
|
||||
digit ::= '0' | '1' | ... | '9'
|
||||
quoted_string ::= '"' {any_char_except_quote} '"'
|
||||
file_extension ::= letter+
|
||||
```
|
||||
|
||||
### 词法元素
|
||||
|
||||
| 元素 | 形式 | 描述 |
|
||||
|------|------|------|
|
||||
| 资源引用标记 | @ | 所有资源引用都以@符号开始 |
|
||||
| 协议名称 | 任意协议名 | 指定被引用资源的协议类型 |
|
||||
| 协议分隔符 | : | 分隔协议名称和资源位置 |
|
||||
| 协议路径分隔符 | :// | 用于URI路径的分隔符 |
|
||||
| 路径段分隔符 | / | 分隔路径中的不同部分 |
|
||||
| 查询参数开始 | ? | 标识查询参数的开始 |
|
||||
| 参数分隔符 | & | 分隔多个查询参数 |
|
||||
| 参数赋值 | = | 分隔参数名和参数值 |
|
||||
| 通配符 | *, ** | 用于在路径中匹配一个或多个文件/目录 |
|
||||
|
||||
### 组合规则
|
||||
|
||||
1. 单一协议引用：`@protocol://path`，例如`@file://document.md`
|
||||
2. 嵌套协议引用：`@outer:@inner://path`，例如`@thinking:@file://method.md`
|
||||
3. 嵌套协议简写：内部协议可省略@，例如`@outer:inner://path`，例如`@thinking:file://method.md`
|
||||
4. 路径中支持通配符：
|
||||
- `*` 匹配单层中的任意文件或目录，如`@file://docs/*.md`
|
||||
- `**` 匹配多层目录和文件，如`@file://src/**/*.js`
|
||||
- `*.ext` 匹配特定扩展名的文件，如`@file://docs/*.txt`
|
||||
|
||||
这些规则构成了资源引用协议的核心，简洁而灵活地满足各种引用场景。
|
||||
|
||||
## 🧩 语义定义
|
||||
|
||||
### 核心概念
|
||||
|
||||
| 概念 | 定义 | 示例 |
|
||||
|------|------|------|
|
||||
| 基础资源 | 指向物理存储或网络位置的基本资源类型 | @file://document.txt |
|
||||
| 应用协议 | 指向特定应用协议定义的资源 | @thinking://brainstorm |
|
||||
| 资源路径 | 定位具体资源的路径信息 | projects/main/doc.md |
|
||||
| 查询参数 | 提供资源处理或过滤的额外信息 | ?section=2&format=md |
|
||||
| 嵌套引用 | 一个协议引用另一个协议 | @thinking:@file://method.md |
|
||||
| 通配符 | 用于匹配多个资源的模式 | docs/*.md, src/**/*.js |
|
||||
|
||||
### 解释规则
|
||||
|
||||
1. 资源引用解析从左至右进行，先识别协议名称，再解析资源位置和查询参数
|
||||
2. 嵌套引用从内向外解析，内层资源引用的结果作为外层引用的输入
|
||||
3. 如果资源类型未指定具体实现方式，则使用该类型的默认解释器
|
||||
4. 查询参数应用于资源加载后的处理阶段，不影响资源的基本定位
|
||||
5. 相对路径解析基于当前上下文的工作目录或基础路径
|
||||
6. 通配符解析遵循常见的glob模式规则
|
||||
|
||||
## ✅ 约束与验证
|
||||
|
||||
### 必要约束
|
||||
|
||||
1. 协议名称必须是已注册的协议类型
|
||||
2. 资源路径必须符合目标系统的路径要求和访问权限
|
||||
3. 嵌套引用的深度不应超过3层，以保持可读性和解析效率
|
||||
4. 查询参数必须是目标协议类型支持的参数
|
||||
|
||||
### 验证规则
|
||||
|
||||
资源引用的验证包括以下步骤：
|
||||
1. 语法验证：检查是否符合EBNF定义的语法结构
|
||||
2. 协议验证：检查引用的协议类型是否已注册
|
||||
3. 路径验证：检查资源路径是否合法且可访问
|
||||
4. 参数验证：检查查询参数是否被目标协议类型支持
|
||||
5. 安全验证：检查资源引用是否符合安全策略
|
||||
|
||||
### 错误处理
|
||||
|
||||
当遇到无效的资源引用时，应采取以下处理方式：
|
||||
1. 语法错误：返回错误描述，指出错误位置和期望格式
|
||||
2. 资源不存在：返回资源未找到的错误，可能提供相似资源的建议
|
||||
3. 访问受限：返回权限错误，并说明所需权限
|
||||
4. 参数无效：返回参数错误，说明支持的参数格式
|
||||
5. 解析超时：对于复杂的链式调用，如果解析时间超过预设限制，返回超时错误
|
||||
|
||||
## 🔄 扩展机制
|
||||
|
||||
### 扩展点
|
||||
|
||||
资源引用协议可在以下方面进行扩展：
|
||||
1. 新的协议类型：注册新的协议
|
||||
2. 协议处理器：为协议类型定义处理逻辑
|
||||
3. 查询参数：扩展特定协议类型支持的查询参数
|
||||
|
||||
### 扩展规则
|
||||
|
||||
创建资源协议扩展时，应遵循以下规则：
|
||||
1. 新协议类型必须使用唯一的标识符，避免与现有类型冲突
|
||||
2. 扩展必须提供完整的处理器实现，包括资源定位、加载和转换
|
||||
3. 扩展应提供错误处理机制和回退策略
|
||||
4. 扩展必须遵循基本的安全原则，不应引入新的安全风险
|
||||
|
||||
### 扩展示例
|
||||
|
||||
```
|
||||
// 定义新的协议类型
|
||||
@custom://resource-path?param=value
|
||||
|
||||
// 嵌套协议示例
|
||||
@outer:@inner://path/to/resource
|
||||
|
||||
// 多层嵌套示例
|
||||
@outer:middle:@inner://path
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 有效示例
|
||||
|
||||
```
|
||||
// 基础资源引用
|
||||
@file://documents/report.md
|
||||
|
||||
// 含有通配符的引用
|
||||
@file://docs/*.md
|
||||
|
||||
// 多层通配符引用
|
||||
@file://src/**/*.js
|
||||
|
||||
// 特定扩展名通配符
|
||||
@file://project/*.{js,ts}
|
||||
|
||||
// HTTP资源引用
|
||||
@http://example.com/api/data.json
|
||||
|
||||
// 嵌套资源引用（完整形式）
|
||||
@thinking:@file://method.md
|
||||
|
||||
// 嵌套资源引用（简写形式）
|
||||
@thinking:file://method.md
|
||||
|
||||
// 多层嵌套（完整形式）
|
||||
@outer:@middle:@inner://resource
|
||||
|
||||
// 多层嵌套（简写形式）
|
||||
@outer:middle:inner://resource
|
||||
|
||||
// 带查询参数的引用
|
||||
@file://document.md?section=intro&format=html
|
||||
```
|
||||
|
||||
### 无效示例
|
||||
|
||||
```
|
||||
// 缺少协议名称
|
||||
@://document.txt
|
||||
// 错误原因: 必须指定协议名称
|
||||
|
||||
// 缺少资源路径
|
||||
@file://
|
||||
// 错误原因: 必须提供资源路径
|
||||
|
||||
// 非法字符在路径中
|
||||
@file://doc<ument>.txt
|
||||
// 错误原因: 路径包含非法字符
|
||||
|
||||
// 查询参数格式错误
|
||||
@file://code.py?lines:10-20
|
||||
// 错误原因: 查询参数应使用=赋值
|
||||
```
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
1. 使用最合适的协议名称表示资源类型，提高语义明确性
|
||||
2. 嵌套引用时，如果清晰度很重要，使用完整形式（带内部@符号）
|
||||
3. 如果简洁性更重要，则使用简写形式（省略内部@符号）
|
||||
4. 保持资源路径的相对引用，以提高提示词的可移植性
|
||||
5. 合理使用通配符，避免过于宽泛的匹配模式
|
||||
6. 使用查询参数进行资源过滤，而不是在提示词中手动处理
|
||||
7. 避免过深的嵌套引用，保持可读性
|
||||
|
||||
### 常见问题
|
||||
|
||||
**Q: 资源引用是否支持通配符?**
|
||||
A: 是的，协议支持`*`（单层匹配）、`**`（多层匹配）和`*.ext`（特定扩展名匹配）等通配符模式
|
||||
|
||||
**Q: 如何引用资源的特定部分?**
|
||||
A: 使用查询参数来指定资源的特定部分，如`@file://document.md?section=introduction`
|
||||
|
||||
**Q: 如何处理多种文件扩展名的通配符?**
|
||||
A: 可以使用花括号表示多选项，如`@file://src/*.{js,ts,jsx}`匹配多种扩展名
|
||||
|
||||
**Q: 嵌套引用有深度限制吗?**
|
||||
A: 为了保持可读性，建议嵌套深度不超过3层，虽然语法上没有严格限制
|
||||
|
||||
**Q: 嵌套引用中的URI如何处理?**
|
||||
A: 在嵌套引用中，内层URI会被完整处理后传递给外层协议，如`@outer:http://example.com`中，http协议的结果会传递给outer协议处理
|
||||
@ -33,10 +33,11 @@ DPML适用于所有需要结构化表达提示词的场景，包括但不限于A
|
||||
```ebnf
|
||||
document ::= element | (element document)
|
||||
element ::= '<' tag attributes '>' content '</' tag '>' | '<' tag attributes '/>'
|
||||
tag ::= name
|
||||
tag ::= [namespace ':'] name
|
||||
namespace ::= name
|
||||
name ::= [A-Za-z][A-Za-z0-9_-]*
|
||||
attributes ::= (attribute attributes) | ε
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [A-Za-z][A-Za-z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= markdown_text | (element content) | ε
|
||||
markdown_text ::= (* 任何有效的Markdown文本 *)
|
||||
@ -71,6 +72,38 @@ markdown_text ::= (* 任何有效的Markdown文本 *)
|
||||
| 内容表达 | 使用Markdown表达的实际提示文本 | `# 步骤\n1. 首先...` |
|
||||
| 组合提示 | 多个提示单元组合形成完整提示 | `<thinking>...</thinking><executing>...</executing>` |
|
||||
|
||||
### 命名空间绑定
|
||||
|
||||
命名空间是DPML的核心语义机制，用于表达标签间的语义继承和协议复用：
|
||||
|
||||
1. **协议实现绑定**：通过命名空间前缀表示一个标签通过特定协议实现
|
||||
```xml
|
||||
<store:execution>
|
||||
<!-- 表示store标签通过execution协议实现 -->
|
||||
</store:execution>
|
||||
```
|
||||
|
||||
在DPML中，`A:B`表示"A通过B实现"，读作"A implemented with B"。冒号左侧表示"做什么"(功能)，右侧表示"怎么做"(实现方式)。
|
||||
|
||||
2. **多协议组合**：一个标签可以通过不同命名空间的子标签组合多个协议
|
||||
```xml
|
||||
<memory>
|
||||
<store:execution>存储操作...</store:execution>
|
||||
<recall:resource>检索操作...</recall:resource>
|
||||
</memory>
|
||||
```
|
||||
|
||||
3. **协议继承关系**：命名空间前缀表示标签继承了指定协议的所有结构和规则
|
||||
```xml
|
||||
<!-- memory协议中的store子标签通过execution协议实现 -->
|
||||
<memory>
|
||||
<store:execution>
|
||||
<process>...</process>
|
||||
<rule>...</rule>
|
||||
</store:execution>
|
||||
</memory>
|
||||
```
|
||||
|
||||
### 解释规则
|
||||
|
||||
1. 标签名决定提示单元的主要语义类型（思考、执行等）
|
||||
@ -79,70 +112,6 @@ markdown_text ::= (* 任何有效的Markdown文本 *)
|
||||
4. 嵌套标签表示包含关系，内层提示单元属于外层提示单元的组成部分
|
||||
5. 同级标签按顺序解释，表示提示流程的先后次序
|
||||
|
||||
## ✅ 约束与验证
|
||||
|
||||
### 必要约束
|
||||
|
||||
1. 标签名必须符合命名规则：以字母开头，可包含字母、数字、下划线和连字符
|
||||
2. 属性值必须使用双引号包围
|
||||
3. 标签必须正确闭合，开闭标签名称必须一致
|
||||
4. 标签嵌套必须正确，不允许交叉嵌套
|
||||
5. Markdown内容必须是有效的Markdown语法
|
||||
|
||||
### 验证规则
|
||||
|
||||
DPML文档可通过以下步骤验证：
|
||||
1. 检查XML结构的有效性（标签配对、属性格式等）
|
||||
2. 验证标签名是否属于预定义集合或符合扩展规则
|
||||
3. 检查必需属性是否存在且值有效
|
||||
4. 验证Markdown内容的格式有效性
|
||||
5. 检查引用资源的可访问性
|
||||
|
||||
### 错误处理
|
||||
|
||||
遇到语法错误时的处理优先级：
|
||||
1. 标签结构错误（未闭合、交叉嵌套）：终止解析，报告错误位置
|
||||
2. 未知标签或属性：发出警告但继续解析，将其视为自定义扩展
|
||||
3. Markdown语法错误：尽可能宽容处理，按文本呈现
|
||||
4. 资源引用错误：报告无法访问的资源，但继续处理其他内容
|
||||
|
||||
## 🔄 扩展机制
|
||||
|
||||
### 扩展点
|
||||
|
||||
DPML提供以下扩展点：
|
||||
1. 自定义标签：通过命名空间机制创建新的语义标签
|
||||
2. 自定义属性：为现有标签添加新的控制属性
|
||||
3. 内容增强：在Markdown中嵌入特殊语法或命令
|
||||
4. 外部引用：导入和复用外部DPML组件
|
||||
|
||||
### 扩展规则
|
||||
|
||||
1. 自定义标签应使用命名空间前缀：`<ns:tag>`
|
||||
2. 自定义属性可直接添加，但建议使用命名空间：`ns:property="value"`
|
||||
3. 内容增强应使用明确的语法标记，避免与Markdown冲突
|
||||
4. 扩展必须向下兼容，标准解析器应能忽略无法理解的扩展而不中断处理
|
||||
|
||||
### 扩展示例
|
||||
|
||||
```xml
|
||||
<!-- 命名空间定义 -->
|
||||
<prompt xmlns:ai="https://promptx.ai/ns/ai">
|
||||
<!-- 自定义标签 -->
|
||||
<ai:model type="gpt4">
|
||||
<!-- 标准标签 -->
|
||||
<thinking>
|
||||
# 分析方法
|
||||
使用**系统思维**方法
|
||||
</thinking>
|
||||
|
||||
<!-- 自定义属性 -->
|
||||
<executing ai:temperature="0.7">
|
||||
执行步骤...
|
||||
</executing>
|
||||
</ai:model>
|
||||
</prompt>
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
@ -211,6 +180,35 @@ DPML提供以下扩展点：
|
||||
</prompt>
|
||||
```
|
||||
|
||||
**4. 跨协议组合示例**
|
||||
```
|
||||
<memory>
|
||||
<!-- 存储操作通过execution协议实现 -->
|
||||
<store:execution>
|
||||
<content>用户操作系统：MacOS 13.4</content>
|
||||
|
||||
<process>
|
||||
# 存储流程
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[接收内容] --> B[验证格式]
|
||||
B --> C[写入存储]
|
||||
```
|
||||
</process>
|
||||
|
||||
<rule>
|
||||
1. 记忆写入必须原子化
|
||||
2. 冲突时保留高置信度版本
|
||||
</rule>
|
||||
</store:execution>
|
||||
|
||||
<!-- 检索操作通过resource协议实现 -->
|
||||
<recall:resource>
|
||||
@memory://system/os_info?confidence=0.8
|
||||
</recall:resource>
|
||||
</memory>
|
||||
```
|
||||
|
||||
### 无效示例
|
||||
|
||||
**1. 标签未闭合**
|
||||
@ -239,19 +237,15 @@ DPML提供以下扩展点：
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
1. **语义清晰度**：选择表意明确的标签名，让提示结构一目了然
|
||||
2. **适度分层**：合理使用嵌套结构，避免过深的层次导致可读性下降
|
||||
3. **内容聚焦**：每个标签内容应关注单一职责，避免功能混杂
|
||||
4. **属性合理性**：只使用必要的属性，避免过度配置
|
||||
5. **一致性**：在整个项目中保持一致的DPML结构风格
|
||||
1. **标签命名自释义**：选择具有自解释性的标签名称，使其本身就能清晰表达逻辑语义，即使没有计算机处理，人和AI也能轻松理解标签结构的逻辑上下文
|
||||
2. **语义清晰度**：选择表意明确的标签名，让提示结构一目了然
|
||||
3. **适度分层**：合理使用嵌套结构，避免过深的层次导致可读性下降
|
||||
4. **内容聚焦**：每个标签内容应关注单一职责，避免功能混杂
|
||||
5. **属性合理性**：只使用必要的属性，避免过度配置
|
||||
6. **一致性**：在整个项目中保持一致的DPML结构风格
|
||||
7. **命名空间明确性**：使用命名空间时，确保左侧表示"做什么"(功能)，右侧表示"怎么做"(实现)
|
||||
|
||||
### 常见问题
|
||||
## 📌 总结
|
||||
|
||||
**Q: DPML与纯Markdown相比有什么优势？**
|
||||
A: DPML提供了语义结构，使提示词的不同部分（思考、执行等）有明确区分，便于解析和处理，同时保留了Markdown的灵活性。
|
||||
DPML通过结合标签语言的结构化能力和Markdown的内容表现力，为提示词工程提供了一种既规范又灵活的表达方式。其核心优势在于清晰的语义结构、协议复用机制和人类可读性，特别适合构建复杂、模块化的AI交互提示系统。
|
||||
|
||||
**Q: 如何在DPML中引用外部资源？**
|
||||
A: 可以通过标签属性引用外部资源，如`<resource src="path/to/file">`，或使用特定的资源引用语法（参见资源引用协议）。
|
||||
|
||||
**Q: DPML的解析器需要特殊实现吗？**
|
||||
A: DPML可以通过组合现有的XML解析器和Markdown解析器实现，先解析XML结构，再处理各标签内的Markdown内容。
|
||||
Reference in New Issue
Block a user