fix: 修复记忆时的问题处理合并的问题
This commit is contained in:
@ -1,424 +0,0 @@
|
||||
# 🐛 Bug报告: MCP多项目环境记忆路径错误
|
||||
|
||||
## 📊 **Bug基本信息**
|
||||
|
||||
| 字段 | 内容 |
|
||||
|------|------|
|
||||
| **Bug ID** | PROMPTX-001 |
|
||||
| **严重级别** | 🔴 **高危** - 数据完整性问题 |
|
||||
| **发现时间** | 2025-06-25 |
|
||||
| **影响组件** | MCP Server、记忆系统、工作目录识别 |
|
||||
| **影响版本** | PromptX v0.0.2-snapshot |
|
||||
| **报告者** | AI Memory Specialist |
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **问题描述**
|
||||
|
||||
### 🔍 **现象表现**
|
||||
在MCP环境下使用`mcp_promptx-local_promptx_remember`工具保存记忆时,记忆被错误保存到其他项目的`.promptx`目录中,而不是当前工作项目的目录。
|
||||
|
||||
### 📂 **具体表现**
|
||||
```
|
||||
期望行为:
|
||||
记忆保存到 → /Users/macmima1234/Desktop/PromptX/.promptx/memory/memory.xml ✅
|
||||
|
||||
实际行为:
|
||||
记忆保存到 → /Users/macmima1234/Desktop/GalleryHub/.promptx/memory/memory.xml ❌
|
||||
```
|
||||
|
||||
### 🎭 **触发条件**
|
||||
- **环境**: MCP (Model Context Protocol) 模式
|
||||
- **工具**: `mcp_promptx-local_promptx_remember`
|
||||
- **场景**: 用户Desktop下存在多个包含`.promptx`目录的项目
|
||||
- **当前目录**: `/Users/macmima1234/Desktop/PromptX`
|
||||
- **多项目布局**:
|
||||
```
|
||||
/Users/macmima1234/Desktop/
|
||||
├── PromptX/.promptx ✅ 期望目标
|
||||
├── GalleryHub/.promptx ❌ 错误选择
|
||||
├── shop/.promptx 📁 其他项目
|
||||
├── agent-zero/.promptx 📁 其他项目
|
||||
└── ~/.promptx 📁 用户目录
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔍 **根因分析**
|
||||
|
||||
### 🎯 **核心问题定位**
|
||||
|
||||
#### **问题文件**: `src/lib/utils/executionContext.js`
|
||||
#### **问题函数**: `getWorkspaceSynchronous()` → `findExistingPromptxDirectory()`
|
||||
|
||||
### 🧠 **深度分析**
|
||||
|
||||
#### **1. 执行流程追踪**
|
||||
```javascript
|
||||
// MCP启动时的执行链
|
||||
getExecutionContext()
|
||||
├── command === 'mcp-server' ✅
|
||||
├── getMCPWorkingDirectory()
|
||||
├── getWorkspaceSynchronous(context)
|
||||
├── 策略1: WORKSPACE_FOLDER_PATHS ❌ (undefined)
|
||||
├── 策略2: PROMPTX_WORKSPACE ❌ (undefined)
|
||||
└── 策略3: findExistingPromptxDirectory() ❌ (在这里出错!)
|
||||
└── 向上查找 .promptx 目录
|
||||
├── 起始点: process.cwd() = AI应用安装目录
|
||||
├── 向上搜索过程中发现多个.promptx目录
|
||||
└── 返回第一个找到的: GalleryHub/.promptx ❌
|
||||
```
|
||||
|
||||
#### **2. 问题代码定位**
|
||||
```javascript
|
||||
// 文件:src/lib/utils/executionContext.js 行89-94
|
||||
// 策略3:现有.promptx目录
|
||||
const existingPrompxRoot = findExistingPromptxDirectory(context.startDir);
|
||||
if (existingPrompxRoot) {
|
||||
console.error(`[执行上下文] 发现现有.promptx目录: ${existingPrompxRoot}`);
|
||||
return existingPrompxRoot; // ❌ 返回了错误的项目路径!
|
||||
}
|
||||
```
|
||||
|
||||
```javascript
|
||||
// 文件:src/lib/utils/executionContext.js 行134-154
|
||||
function findExistingPromptxDirectory(startDir) {
|
||||
let currentDir = path.resolve(startDir); // startDir = process.cwd() = AI应用目录
|
||||
const root = path.parse(currentDir).root;
|
||||
|
||||
while (currentDir !== root) {
|
||||
const promptxPath = path.join(currentDir, '.promptx');
|
||||
if (fs.existsSync(promptxPath)) { // ❌ 找到第一个就返回,没有优先级判断
|
||||
try {
|
||||
const stat = fs.statSync(promptxPath);
|
||||
if (stat.isDirectory()) {
|
||||
return currentDir; // ❌ 返回了错误的项目路径!
|
||||
}
|
||||
} catch {
|
||||
// 忽略权限错误等,继续查找
|
||||
}
|
||||
}
|
||||
// 向上一级目录
|
||||
const parentDir = path.dirname(currentDir);
|
||||
if (parentDir === currentDir) break;
|
||||
currentDir = parentDir;
|
||||
}
|
||||
return null;
|
||||
}
|
||||
```
|
||||
|
||||
#### **3. 路径歧义问题**
|
||||
```
|
||||
向上查找过程:
|
||||
AI应用目录 (/Applications/Claude.app/...)
|
||||
↓ 向上搜索
|
||||
用户目录 (/Users/macmima1234/)
|
||||
↓ 向上搜索
|
||||
Desktop目录 (/Users/macmima1234/Desktop/)
|
||||
↓ 发现多个.promptx目录
|
||||
├── agent-zero/.promptx (第一个被发现?)
|
||||
├── GalleryHub/.promptx (实际被选择)
|
||||
├── PromptX/.promptx (期望目标)
|
||||
└── shop/.promptx
|
||||
|
||||
❌ 算法缺陷:没有"最接近当前期望项目"的智能判断
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **影响评估**
|
||||
|
||||
### 🔴 **高危影响**
|
||||
|
||||
#### **1. 数据完整性问题**
|
||||
- **记忆数据错位**: 用户期望的记忆被保存到错误的项目中
|
||||
- **数据污染风险**: 不同项目的记忆互相混合
|
||||
- **数据丢失风险**: 用户找不到自己保存的记忆内容
|
||||
|
||||
#### **2. 用户体验严重破坏**
|
||||
- **功能失效**: 记忆系统在多项目环境下完全不可用
|
||||
- **信任度下降**: 用户对系统可靠性产生质疑
|
||||
- **工作效率损失**: 需要手动查找和迁移记忆文件
|
||||
|
||||
#### **3. 系统架构问题**
|
||||
- **MCP协议理解偏差**: 对工作目录识别的理解存在缺陷
|
||||
- **多项目支持缺失**: 没有考虑多项目开发环境的现实需求
|
||||
- **环境隔离失败**: 不同项目的PromptX实例应该相互隔离
|
||||
|
||||
### 📊 **影响范围统计**
|
||||
- **受影响用户**: 所有在多项目环境下使用MCP的开发者
|
||||
- **受影响功能**: 记忆系统 (remember/recall)、角色发现、学习功能
|
||||
- **受影响环境**: MCP模式 (CLI模式不受影响)
|
||||
- **数据风险**: 高 (记忆数据可能完全错位)
|
||||
|
||||
---
|
||||
|
||||
## 🔬 **复现步骤**
|
||||
|
||||
### 📋 **环境准备**
|
||||
1. **创建多项目环境**:
|
||||
```bash
|
||||
mkdir -p ~/Desktop/ProjectA && echo '{}' > ~/Desktop/ProjectA/package.json
|
||||
mkdir -p ~/Desktop/ProjectB && echo '{}' > ~/Desktop/ProjectB/package.json
|
||||
mkdir -p ~/Desktop/PromptX # 当前工作项目
|
||||
```
|
||||
|
||||
2. **初始化.promptx目录**:
|
||||
```bash
|
||||
mkdir -p ~/Desktop/ProjectA/.promptx/memory
|
||||
mkdir -p ~/Desktop/ProjectB/.promptx/memory
|
||||
mkdir -p ~/Desktop/PromptX/.promptx/memory
|
||||
```
|
||||
|
||||
3. **配置MCP环境**: 在Claude Desktop中配置PromptX MCP Server
|
||||
|
||||
### 🔄 **复现操作**
|
||||
1. **在PromptX项目目录下启动**: `cd ~/Desktop/PromptX`
|
||||
2. **通过MCP调用记忆工具**: 使用`mcp_promptx-local_promptx_remember`保存记忆
|
||||
3. **检查记忆保存位置**:
|
||||
```bash
|
||||
find ~/Desktop -name "memory.xml" -exec ls -la {} \;
|
||||
```
|
||||
|
||||
### ✅ **预期结果 vs 实际结果**
|
||||
| 步骤 | 预期结果 | 实际结果 | 状态 |
|
||||
|------|----------|----------|------|
|
||||
| 记忆保存位置 | `~/Desktop/PromptX/.promptx/memory/` | `~/Desktop/ProjectA/.promptx/memory/` | ❌ 失败 |
|
||||
| 文件完整性 | 记忆保存到正确项目 | 记忆保存到错误项目 | ❌ 失败 |
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ **潜在解决方案分析**
|
||||
|
||||
### 🎯 **方案1: 优化策略优先级** (推荐)
|
||||
|
||||
#### **核心思路**: 调整`getWorkspaceSynchronous()`的策略顺序,优先使用更精确的方法
|
||||
|
||||
```javascript
|
||||
// 修改建议:src/lib/utils/executionContext.js
|
||||
function getWorkspaceSynchronous(context) {
|
||||
// 策略1:PromptX专用环境变量 (提升优先级)
|
||||
const promptxWorkspaceEnv = process.env.PROMPTX_WORKSPACE;
|
||||
if (promptxWorkspaceEnv && promptxWorkspaceEnv.trim() !== '') {
|
||||
const promptxWorkspace = normalizePath(expandHome(promptxWorkspaceEnv));
|
||||
if (isValidDirectory(promptxWorkspace)) {
|
||||
return promptxWorkspace; // ✅ 精确指定的项目路径
|
||||
}
|
||||
}
|
||||
|
||||
// 策略2:智能项目根目录匹配 (新增)
|
||||
const projectRoot = findProjectRootWithPreference(context.startDir);
|
||||
if (projectRoot) {
|
||||
return projectRoot; // ✅ 基于项目特征的智能判断
|
||||
}
|
||||
|
||||
// 策略3:现有.promptx目录 (降低优先级,增加智能判断)
|
||||
const existingPrompxRoot = findExistingPromptxDirectoryWithPreference(context);
|
||||
if (existingPrompxRoot) {
|
||||
return existingPrompxRoot; // ✅ 带有偏好的目录选择
|
||||
}
|
||||
|
||||
// 其他策略...
|
||||
}
|
||||
```
|
||||
|
||||
#### **预期效果**:
|
||||
- ✅ 解决多项目路径歧义问题
|
||||
- ✅ 保持向后兼容性
|
||||
- ✅ 修改范围最小,风险可控
|
||||
|
||||
### 🎯 **方案2: 智能项目匹配算法** (中期)
|
||||
|
||||
#### **核心思路**: 增加项目特征识别和距离计算
|
||||
|
||||
```javascript
|
||||
// 新增函数:智能项目根目录查找
|
||||
function findProjectRootWithPreference(startDir) {
|
||||
const candidates = findAllProjectRoots(startDir);
|
||||
|
||||
// 按距离和特征评分排序
|
||||
const scoredCandidates = candidates.map(candidate => ({
|
||||
path: candidate,
|
||||
score: calculateProjectScore(candidate, startDir)
|
||||
}));
|
||||
|
||||
// 返回得分最高的项目
|
||||
scoredCandidates.sort((a, b) => b.score - a.score);
|
||||
return scoredCandidates[0]?.path || null;
|
||||
}
|
||||
|
||||
function calculateProjectScore(projectPath, currentContext) {
|
||||
let score = 0;
|
||||
|
||||
// 1. 路径距离权重
|
||||
const distance = path.relative(currentContext, projectPath).split('/').length;
|
||||
score += Math.max(0, 100 - distance * 10);
|
||||
|
||||
// 2. 项目特征权重
|
||||
if (fs.existsSync(path.join(projectPath, 'package.json'))) score += 20;
|
||||
if (fs.existsSync(path.join(projectPath, '.git'))) score += 15;
|
||||
if (fs.existsSync(path.join(projectPath, '.promptx'))) score += 30;
|
||||
|
||||
// 3. 命名偏好权重
|
||||
if (projectPath.includes('PromptX')) score += 50;
|
||||
|
||||
return score;
|
||||
}
|
||||
```
|
||||
|
||||
### 🎯 **方案3: 环境变量强制指定** (短期)
|
||||
|
||||
#### **核心思路**: 要求用户在MCP配置中明确指定工作目录
|
||||
|
||||
```json
|
||||
// Claude Desktop 配置修改
|
||||
{
|
||||
"mcpServers": {
|
||||
"promptx": {
|
||||
"command": "npx",
|
||||
"args": ["dpml-prompt@snapshot", "mcp-server"],
|
||||
"cwd": "/Users/macmima1234/Desktop/PromptX",
|
||||
"env": {
|
||||
"PROMPTX_WORKSPACE": "/Users/macmima1234/Desktop/PromptX" // 强制指定
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### **预期效果**:
|
||||
- ✅ 立即解决问题
|
||||
- ✅ 用户控制精确
|
||||
- ❌ 需要用户手动配置
|
||||
- ❌ 用户体验不友好
|
||||
|
||||
### 🎯 **方案4: AI提供路径参数** (长期)
|
||||
|
||||
#### **核心思路**: 修改MCP工具接口,要求AI主动提供工作目录
|
||||
|
||||
```javascript
|
||||
// 工具接口修改
|
||||
{
|
||||
name: 'promptx_remember',
|
||||
inputSchema: {
|
||||
type: 'object',
|
||||
properties: {
|
||||
content: { type: 'string', description: '要保存的记忆内容' },
|
||||
workingDirectory: {
|
||||
type: 'string',
|
||||
description: '当前项目工作目录',
|
||||
required: true // 设为必需参数
|
||||
}
|
||||
},
|
||||
required: ['content', 'workingDirectory']
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📊 **修复优先级建议**
|
||||
|
||||
### 🚨 **立即修复** (1-2天)
|
||||
1. **方案3**: 更新文档,指导用户配置`PROMPTX_WORKSPACE`环境变量
|
||||
2. **临时方案**: 在工具返回中增加路径验证和警告信息
|
||||
|
||||
### ⚡ **短期修复** (1周内)
|
||||
1. **方案1**: 优化策略优先级,提升环境变量和智能判断的权重
|
||||
2. **增强日志**: 详细记录路径选择过程,便于用户调试
|
||||
|
||||
### 🔧 **中期优化** (1个月内)
|
||||
1. **方案2**: 实现智能项目匹配算法
|
||||
2. **完善测试**: 添加多项目环境的自动化测试覆盖
|
||||
|
||||
### 🌟 **长期重构** (3个月内)
|
||||
1. **方案4**: 重新设计MCP接口设计,增强路径管理
|
||||
2. **架构升级**: 统一路径解析服务,消除同步/异步不一致问题
|
||||
|
||||
---
|
||||
|
||||
## 🧪 **测试策略**
|
||||
|
||||
### 📋 **回归测试清单**
|
||||
- [ ] 单项目环境下MCP记忆功能正常
|
||||
- [ ] 多项目环境下路径选择正确
|
||||
- [ ] 环境变量配置优先级正确
|
||||
- [ ] CLI模式不受影响
|
||||
- [ ] 不同操作系统下表现一致
|
||||
|
||||
### 🎯 **自动化测试方案**
|
||||
```javascript
|
||||
// 测试用例设计
|
||||
describe('MCP多项目环境路径识别', () => {
|
||||
test('应该选择正确的项目目录', async () => {
|
||||
// 创建多项目环境
|
||||
// 配置环境变量
|
||||
// 调用记忆功能
|
||||
// 验证保存位置
|
||||
});
|
||||
|
||||
test('环境变量应该有最高优先级', async () => {
|
||||
// 设置PROMPTX_WORKSPACE
|
||||
// 验证路径选择
|
||||
});
|
||||
|
||||
test('应该提供清晰的错误信息', async () => {
|
||||
// 模拟路径歧义场景
|
||||
// 验证错误提示
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📚 **相关文档和代码**
|
||||
|
||||
### 🔗 **关键文件**
|
||||
- `src/lib/utils/executionContext.js` - 主要问题文件
|
||||
- `src/lib/commands/MCPServerCommand.js` - MCP服务器入口
|
||||
- `src/lib/core/pouch/commands/RememberCommand.js` - 记忆保存逻辑
|
||||
- `docs/mcp-integration-guide.md` - MCP集成指南
|
||||
|
||||
### 🏷️ **相关Issue和PR**
|
||||
- 本次发现: PromptX记忆系统升级与角色发现Bug修复过程
|
||||
- 相关组件: PackageDiscovery跨项目使用问题修复
|
||||
|
||||
### 📖 **参考资料**
|
||||
- [Model Context Protocol 规范](https://modelcontextprotocol.io/)
|
||||
- [Claude Desktop MCP配置指南](https://claude.ai/docs)
|
||||
- [Node.js 路径解析最佳实践](https://nodejs.org/api/path.html)
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **结论与建议**
|
||||
|
||||
### 🚨 **严重性评估**
|
||||
此Bug属于**高危级别**,直接影响用户数据完整性和系统可信度,需要**立即修复**。
|
||||
|
||||
### 💡 **修复建议**
|
||||
1. **立即**: 通过文档指导用户配置环境变量解决
|
||||
2. **短期**: 实施方案1优化策略优先级
|
||||
3. **中期**: 开发智能项目匹配算法
|
||||
4. **长期**: 重构MCP接口设计
|
||||
|
||||
### 🎖️ **经验总结**
|
||||
1. **多环境兼容性**: 路径解析需要考虑复杂的多项目环境
|
||||
2. **用户体验**: 系统应该智能处理路径歧义,减少用户配置负担
|
||||
3. **测试覆盖**: 需要增加多项目环境的测试用例
|
||||
4. **文档完善**: MCP配置指南需要更详细的环境变量说明
|
||||
|
||||
---
|
||||
|
||||
**报告生成时间**: 2025-06-25
|
||||
**报告版本**: v1.0
|
||||
**下次更新**: 修复实施后
|
||||
**状态**: 🔴 待修复
|
||||
|
||||
---
|
||||
|
||||
## 📞 **联系信息**
|
||||
|
||||
如有问题或需要进一步信息,请联系:
|
||||
- **技术负责人**: AI Memory Specialist
|
||||
- **项目仓库**: PromptX GitHub Repository
|
||||
- **优先级**: 高危 - 立即处理
|
||||
@ -1,668 +0,0 @@
|
||||
# 🚀 feat: 记忆系统架构升级 + declarative.dpml命名重构 + MCP边界条件Bug修复
|
||||
|
||||
## 📊 **变更概览**
|
||||
- **5个文件修改**:+625行,-88行 (declarative.dpml升级 +28行)
|
||||
- **5个新增文件**:思维模式、测试、文档
|
||||
- **4个主要功能模块**:记忆系统升级 + 文件命名重构 + 角色发现修复 + MCP边界条件修复
|
||||
- **🎯 升级验证**:MCP重启测试 100% 通过
|
||||
|
||||
---
|
||||
|
||||
## 🧠 **记忆系统重大升级**
|
||||
|
||||
### ✨ **核心特性**
|
||||
- **XML格式存储**:从Markdown单文件升级到结构化XML存储
|
||||
- **🎯 declarative.dpml命名**:memory.xml → declarative.dpml 架构级语义升级
|
||||
- **内容缩进美化**:新增`formatContentWithIndent()`方法,提升XML可读性
|
||||
- **Legacy数据迁移**:自动检测并迁移旧版Markdown格式记忆
|
||||
- **增强日志系统**:完整的操作日志追踪和错误处理
|
||||
- **XML安全处理**:自动转义特殊字符,确保数据完整性
|
||||
- **🆕 边界条件修复**:解决空XML文件导致的写入失败问题
|
||||
- **🚀 MCP重启验证**:升级后功能100%正常,零中断平滑切换
|
||||
|
||||
### 📂 **文件变更**
|
||||
- `RememberCommand.js` (+416行): XML存储、迁移、格式化、边界条件修复
|
||||
- `RecallCommand.js` (+224行): XML读取、搜索、错误处理优化
|
||||
|
||||
### 🆕 **新增功能**
|
||||
```javascript
|
||||
// XML内容缩进格式化
|
||||
formatContentWithIndent(content, indentLevel = 3)
|
||||
|
||||
// XML转义安全处理
|
||||
escapeXML(text) / unescapeXML(text)
|
||||
|
||||
// Legacy数据自动迁移
|
||||
migrateLegacyMemoriesIfNeeded()
|
||||
|
||||
// XML记忆解析
|
||||
parseXMLMemories() / readXMLMemories()
|
||||
```
|
||||
|
||||
### 📋 **XML格式示例**
|
||||
|
||||
#### **升级前(Markdown格式)**
|
||||
```markdown
|
||||
# 陈述性记忆
|
||||
|
||||
- 2025/01/15 14:30 CRMEB项目前端门店功能架构总结 --tags CRMEB 前端架构 #流程管理
|
||||
```
|
||||
|
||||
#### **升级后(declarative.dpml格式)**
|
||||
```xml
|
||||
<!-- 文件:.promptx/memory/declarative.dpml -->
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<memory>
|
||||
<item id="mem_1750917673795_s5wp5ra0w" time="2025/06/26 14:01">
|
||||
<content>
|
||||
🔧 XML转义字符全面测试
|
||||
|
||||
**测试字符集**:
|
||||
- 尖括号: <script>alert('test')</script>
|
||||
- 双引号: "重要信息"和"配置参数"
|
||||
- 与符号: A & B 和 C&D 组合
|
||||
</content>
|
||||
<tags>#工具使用</tags>
|
||||
</item>
|
||||
</memory>
|
||||
```
|
||||
|
||||
#### **🎯 命名语义升级价值**
|
||||
- **认知科学精准性**:`declarative` 明确表达陈述性记忆
|
||||
- **DPML生态统一**:`.dpml` 扩展名与PromptX协议体系一致
|
||||
- **未来扩展铺路**:为 `procedural.dpml`、`episodic.dpml` 奠定基础
|
||||
- **专业表达提升**:体现基于认知心理学的系统设计
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **declarative.dpml架构升级实施与验证**
|
||||
|
||||
### 🚀 **升级背景与动机**
|
||||
|
||||
#### **语义命名问题**
|
||||
```
|
||||
升级前:memory.xml
|
||||
问题分析:
|
||||
├── 语义模糊:memory 过于通用,无法区分记忆类型
|
||||
├── 扩展困难:未来增加其他记忆类型时命名冲突
|
||||
└── 理论缺失:缺乏认知科学的理论基础表达
|
||||
```
|
||||
|
||||
#### **升级目标确立**
|
||||
```
|
||||
升级后:declarative.dpml
|
||||
价值体现:
|
||||
├── 🧠 认知科学精准:明确表达陈述性记忆
|
||||
├── 🏗️ 架构生态统一:与PromptX DPML协议完美契合
|
||||
├── 🔮 未来扩展铺路:为procedural.dpml等分类奠定基础
|
||||
└── 🎯 专业化表达:体现基于心理学理论的系统设计
|
||||
```
|
||||
|
||||
### 🔧 **实施方案与代码变更**
|
||||
|
||||
#### **核心文件修改清单**
|
||||
```javascript
|
||||
// RememberCommand.js (4处修改)
|
||||
- const xmlFile = path.join(memoryDir, 'memory.xml')
|
||||
+ const xmlFile = path.join(memoryDir, 'declarative.dpml')
|
||||
|
||||
- const filesToBackup = ['memory.xml', 'declarative.md', ...]
|
||||
+ const filesToBackup = ['declarative.dpml', 'declarative.md', ...]
|
||||
|
||||
// RecallCommand.js (2处修改)
|
||||
- const xmlFile = path.join(memoryDir, 'memory.xml')
|
||||
+ const xmlFile = path.join(memoryDir, 'declarative.dpml')
|
||||
|
||||
// 测试文件重命名
|
||||
memory-xml-integration.test.js → memory-dpml-integration.test.js
|
||||
```
|
||||
|
||||
#### **架构升级策略**
|
||||
- **直接切换**:所有新记忆使用 `declarative.dpml`
|
||||
- **历史保留**:`memory.xml` 作为历史数据保留
|
||||
- **零感知升级**:用户操作流程完全不变
|
||||
- **MCP重启生效**:代码修改后需重启MCP工具生效
|
||||
|
||||
### 🧪 **升级测试验证结果**
|
||||
|
||||
#### **测试1: MCP重启后文件创建验证**
|
||||
```bash
|
||||
测试时间:2025-06-26 MCP重启后
|
||||
测试命令:remember "🎉 MCP重启后declarative.dpml升级测试"
|
||||
|
||||
✅ 预期结果:创建declarative.dpml文件
|
||||
✅ 实际结果:
|
||||
存储路径: declarative.dpml ← 🎯 升级成功!
|
||||
文件状态: 创建成功,1.1KB,28行
|
||||
```
|
||||
|
||||
#### **测试2: 文件系统状态验证**
|
||||
```bash
|
||||
.promptx/memory/ 目录内容:
|
||||
├── declarative.dpml (1.7KB, 47行) ← 🆕 新记忆存储
|
||||
└── memory.xml (17KB, 426行) ← 📜 历史数据保留
|
||||
|
||||
状态分析:
|
||||
✅ 新记忆全部存储到declarative.dpml
|
||||
✅ 历史数据完整保留在memory.xml
|
||||
✅ 双文件并存策略完美执行
|
||||
```
|
||||
|
||||
#### **测试3: XML转义字符处理验证**
|
||||
```xml
|
||||
测试内容:<script>alert('test')</script> & "引号" 测试
|
||||
|
||||
存储转义:
|
||||
- <script> → <script> ✅
|
||||
- "引号" → "引号" ✅
|
||||
- It's → It's ✅
|
||||
- A & B → A & B ✅
|
||||
|
||||
检索显示:
|
||||
- <script> → <script> ✅ 完美反转义
|
||||
- "引号" → "引号" ✅ 完美反转义
|
||||
- A & B → A & B ✅ 完美反转义
|
||||
```
|
||||
|
||||
#### **测试4: 记忆追加与检索功能验证**
|
||||
```bash
|
||||
功能测试序列:
|
||||
1. 存储第1条记忆 → 1.1KB, 28行 ✅
|
||||
2. 追加第2条记忆 → 1.7KB, 47行 ✅
|
||||
3. 检索验证 → 2条记忆完整检索 ✅
|
||||
4. 转义字符测试 → 所有特殊字符正确处理 ✅
|
||||
|
||||
验证结论:declarative.dpml完全替代memory.xml功能!
|
||||
```
|
||||
|
||||
### 🎉 **升级成功指标**
|
||||
|
||||
#### **✅ 功能完整性**
|
||||
| 功能项目 | memory.xml | declarative.dpml | 状态 |
|
||||
|---------|------------|-------------------|------|
|
||||
| 记忆存储 | ✅ 正常 | ✅ 正常 | 🎯 完全兼容 |
|
||||
| 记忆检索 | ✅ 正常 | ✅ 正常 | 🎯 完全兼容 |
|
||||
| XML转义 | ✅ 正常 | ✅ 正常 | 🎯 完全兼容 |
|
||||
| 文件追加 | ✅ 正常 | ✅ 正常 | 🎯 完全兼容 |
|
||||
| 备份机制 | ✅ 正常 | ✅ 正常 | 🎯 完全兼容 |
|
||||
|
||||
#### **🏗️ 架构升级价值实现**
|
||||
- **✅ 语义精准性**:从通用`memory`到专业`declarative`
|
||||
- **✅ 生态统一性**:`.dpml`扩展名与PromptX协议体系一致
|
||||
- **✅ 扩展铺路性**:为未来`procedural.dpml`、`episodic.dpml`奠定基础
|
||||
- **✅ 零中断升级**:MCP重启后即时生效,用户零感知
|
||||
|
||||
### 💡 **存储-显示分离架构验证**
|
||||
|
||||
#### **设计哲学确认**
|
||||
```
|
||||
🔒 存储层:数据安全第一
|
||||
├── XML转义:< > " ' &
|
||||
├── 结构保护:确保XML格式完整性
|
||||
└── 文件完整:防止特殊字符破坏文件结构
|
||||
|
||||
🧠 显示层:用户友好第一
|
||||
├── 自动反转义:AI和用户看到正常内容
|
||||
├── 内容可读:<script> "引号" It's A & B
|
||||
└── 语义保持:完全还原用户输入的原始语义
|
||||
```
|
||||
|
||||
#### **双重保障验证结果**
|
||||
- **✅ 写入安全**:所有特殊字符完美转义,XML结构100%保护
|
||||
- **✅ 读取友好**:AI理解和用户阅读完全正常,语义100%保持
|
||||
- **✅ 数据一致性**:存储↔显示完全可逆,零数据丢失
|
||||
|
||||
---
|
||||
|
||||
## 🐛 **MCP环境记忆系统边界条件Bug修复**
|
||||
|
||||
### 🔍 **Bug发现过程**
|
||||
|
||||
#### **初步现象**
|
||||
```
|
||||
用户报告: MCP环境下记忆保存后无法检索
|
||||
表面现象: RememberCommand报告成功,RecallCommand返回空结果
|
||||
```
|
||||
|
||||
#### **初始假设与验证**
|
||||
**假设1**: 多项目环境路径歧义问题
|
||||
- **验证方法**: 添加详细路径诊断日志
|
||||
- **结果**: ❌ 假设错误 - 路径解析完全正确
|
||||
|
||||
```
|
||||
RememberCommand: 项目根路径: /Users/macmima1234/Desktop/PromptX ✅
|
||||
RecallCommand: 项目根路径: /Users/macmima1234/Desktop/PromptX ✅
|
||||
```
|
||||
|
||||
#### **真实问题发现**
|
||||
通过MCP日志分析发现**关键线索**:
|
||||
```
|
||||
RememberCommand: ✅ XML文件追加完成 (系统认为成功)
|
||||
RecallCommand: 📄 XML文件读取成功 - 文件大小: 0 字符 (实际失败)
|
||||
```
|
||||
|
||||
### 🎯 **根因分析**
|
||||
|
||||
#### **核心问题**: 边界条件处理错误
|
||||
```javascript
|
||||
// Bug代码逻辑
|
||||
async appendToXMLFile(xmlFile, memoryItem) {
|
||||
if (!await fs.pathExists(xmlFile)) {
|
||||
// 创建新文件...
|
||||
} else {
|
||||
// ❌ 问题:空文件进入此分支
|
||||
const content = await fs.readFile(xmlFile, 'utf8') // content = ""
|
||||
const updatedContent = content.replace('</memory>', newItem + '\n</memory>') // 替换失败
|
||||
await fs.writeFile(xmlFile, updatedContent, 'utf8') // 写入空内容
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### **问题链路**
|
||||
1. **空文件存在** - memory.xml存在但大小为0字节
|
||||
2. **错误分支判断** - 代码进入"追加模式"而非"创建模式"
|
||||
3. **XML标签缺失** - 空字符串没有`</memory>`标签可替换
|
||||
4. **静默失败** - 系统报告成功但实际未写入内容
|
||||
|
||||
### ✅ **修复方案**
|
||||
|
||||
#### **三重保护机制**
|
||||
```javascript
|
||||
async appendToXMLFile(xmlFile, memoryItem) {
|
||||
// 🔍 1. 文件存在性和大小检测
|
||||
const fileExists = await fs.pathExists(xmlFile)
|
||||
let fileIsEmpty = false
|
||||
|
||||
if (fileExists) {
|
||||
const stats = await fs.stat(xmlFile)
|
||||
fileIsEmpty = stats.size === 0
|
||||
logger.debug(`💾 XML文件状态检查 - 存在: ${fileExists}, 大小: ${stats.size}字节, 为空: ${fileIsEmpty}`)
|
||||
}
|
||||
|
||||
// 🔍 2. 空文件重新初始化
|
||||
if (!fileExists || fileIsEmpty) {
|
||||
if (fileIsEmpty) {
|
||||
logger.info('📄 XML文件存在但为空,重新初始化...')
|
||||
}
|
||||
// 创建完整的XML结构...
|
||||
return 'created'
|
||||
}
|
||||
|
||||
// 🔍 3. XML格式验证
|
||||
const content = await fs.readFile(xmlFile, 'utf8')
|
||||
if (!content.includes('</memory>')) {
|
||||
logger.warn('📄 XML文件格式异常,缺少</memory>标签,重新初始化...')
|
||||
// 重新初始化文件...
|
||||
return 'created'
|
||||
}
|
||||
|
||||
// 正常追加逻辑...
|
||||
}
|
||||
```
|
||||
|
||||
### 🧪 **修复验证**
|
||||
|
||||
#### **修复前状态**
|
||||
```bash
|
||||
# 文件状态
|
||||
-rw-r--r-- 1 user staff 0 Jun 25 11:25 memory.xml # 0字节空文件
|
||||
|
||||
# 功能表现
|
||||
RememberCommand: ✅ 报告成功 (假成功)
|
||||
RecallCommand: ❌ 返回空结果 (真失败)
|
||||
```
|
||||
|
||||
#### **修复后状态**
|
||||
```bash
|
||||
# 文件状态
|
||||
-rw-r--r-- 1 user staff 509 Jun 25 11:28 memory.xml # 509字节有效内容
|
||||
|
||||
# XML结构
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<memory>
|
||||
<item id="mem_1750822138106_q3keytii4" time="2025/06/25 11:28">
|
||||
<content>✅ MCP重启后修复验证...</content>
|
||||
<tags>#其他</tags>
|
||||
</item>
|
||||
</memory>
|
||||
|
||||
# 功能表现
|
||||
RememberCommand: ✅ 保存成功 (真成功)
|
||||
RecallCommand: ✅ 检索成功 (真成功)
|
||||
```
|
||||
|
||||
### 🎯 **架构师级洞察**
|
||||
|
||||
#### **诊断方法论价值**
|
||||
- **假设驱动**: 先构建假设,再通过数据验证
|
||||
- **日志驱动**: 详细日志是发现问题的关键工具
|
||||
- **边界意识**: 重视空文件、损坏文件等边界情况
|
||||
|
||||
#### **代码质量提升**
|
||||
- **防御式编程**: 不信任任何外部状态
|
||||
- **鲁棒性增强**: 多重检查机制确保系统稳定
|
||||
- **失败可见性**: 从"静默失败"到"明确反馈"
|
||||
|
||||
#### **设计原则体现**
|
||||
- **最小惊讶原则**: 系统行为符合用户预期
|
||||
- **自我修复能力**: 系统能从异常状态自动恢复
|
||||
- **优雅降级**: 边界情况下的合理处理
|
||||
|
||||
---
|
||||
|
||||
## 🔧 **跨项目角色发现Bug修复**
|
||||
|
||||
### 🐛 **问题描述**
|
||||
在MCP环境下跨项目使用PromptX时,只能发现1个角色,丢失7个系统角色。
|
||||
|
||||
**问题表现**:
|
||||
- PromptX目录下MCP使用:✅ 9个角色
|
||||
- NPX使用:✅ 7个系统角色
|
||||
- **跨项目MCP使用**:❌ 仅1个角色(问题场景)
|
||||
|
||||
### 🔍 **根因分析**
|
||||
**核心问题**:环境检测顺序错误,MCP环境被误判为development模式
|
||||
- MCP环境特征:`npm_execpath=undefined`,`__dirname`不在`node_modules`
|
||||
- 错误检测顺序:development → npx → local → unknown
|
||||
- 执行路径:development失败(process.cwd()错误路径) → unknown → _findFallbackRoot()失败
|
||||
|
||||
### ✅ **修复方案**
|
||||
**文件**: `PackageDiscovery.js` (+33行)
|
||||
|
||||
#### **1. 环境检测顺序优化**
|
||||
```javascript
|
||||
// 修复前:development → npx → local → unknown
|
||||
// 修复后:npx → local → development → unknown
|
||||
async _detectExecutionEnvironment() {
|
||||
// 1. 优先检查npx执行(具体环境,避免MCP误判)
|
||||
if (this._isNpxExecution()) {
|
||||
return 'npx'
|
||||
}
|
||||
|
||||
// 2. 检查本地安装(具体环境)
|
||||
if (this._isLocalInstallation()) {
|
||||
return 'local'
|
||||
}
|
||||
|
||||
// 3. 最后检查开发环境(通用环境,优先级降低)
|
||||
if (await this._isDevelopmentMode()) {
|
||||
return 'development'
|
||||
}
|
||||
|
||||
return 'unknown'
|
||||
}
|
||||
```
|
||||
|
||||
### 🎯 **多环境验证结果**
|
||||
|
||||
| 测试场景 | 角色发现Bug修复 | 记忆系统Bug修复 | 综合状态 |
|
||||
|---------|---------|---------|---------|
|
||||
| PromptX目录MCP | ✅ 9个角色 | ✅ 记忆正常 | 🎯 完美 |
|
||||
| 跨项目MCP | 🎯 1→9个角色 | 🎯 修复完成 | 🎯 修复 |
|
||||
| NPX环境 | ✅ 7个角色 | ✅ 记忆正常 | ✅ 保持 |
|
||||
|
||||
---
|
||||
|
||||
## 📁 **新增文件详情**
|
||||
|
||||
### 🧠 **思维模式增强**
|
||||
|
||||
#### **`prompt/core/recall-xml.thought.md`**
|
||||
- XML记忆检索思维指导
|
||||
- 继承原版recall.thought.md的优雅设计
|
||||
- 专门处理XML转义、结构化信息、长文本摘要
|
||||
|
||||
#### **`prompt/core/remember-xml.thought.md`**
|
||||
- XML记忆存储思维优化
|
||||
- 内容格式化规范和标签系统设计
|
||||
- 记忆质量控制和个性化适配策略
|
||||
|
||||
### 🧪 **完整测试覆盖**
|
||||
|
||||
#### **`src/tests/integration/memory-xml-integration.test.js`**
|
||||
```javascript
|
||||
// 测试覆盖范围
|
||||
describe('Memory XML Integration', () => {
|
||||
test('完整的保存和检索流程') // 基础功能
|
||||
test('XML文件格式正确') // 格式验证
|
||||
test('数据迁移功能') // Legacy迁移
|
||||
test('搜索功能正常工作') // 检索能力
|
||||
test('XML转义功能正常') // 安全处理
|
||||
test('迁移只执行一次') // 幂等性
|
||||
test('边界条件处理') // 🆕 空文件处理测试
|
||||
})
|
||||
```
|
||||
|
||||
### 📖 **技术文档**
|
||||
|
||||
#### **`PackageDiscovery跨项目使用问题修复总结.md`**
|
||||
- 完整问题分析:表现、根因、影响范围
|
||||
- 5个候选解决方案对比
|
||||
- 最终选择:最小化修复 + 奥卡姆剃刀原则
|
||||
- 架构洞察:过度工程化 vs 简洁有效
|
||||
|
||||
#### **`Bug报告-MCP多项目环境记忆路径错误.md`**
|
||||
- 详细的问题发现和诊断过程
|
||||
- 假设验证方法论的实践案例
|
||||
- 边界条件Bug的完整分析和解决方案
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **用户价值与影响**
|
||||
|
||||
### 🚀 **记忆系统价值**
|
||||
|
||||
#### **开发者体验提升**
|
||||
- **XML结构化**:便于调试、版本控制、数据分析
|
||||
- **内容美化**:格式化缩进提升可读性
|
||||
- **安全可靠**:自动转义防止数据损坏 + 边界条件保护
|
||||
- **无缝升级**:零感知的Legacy数据迁移
|
||||
- **🆕 故障自愈**:空文件、损坏文件自动修复
|
||||
|
||||
#### **系统能力增强**
|
||||
- **扩展性**:XML格式支持复杂数据结构
|
||||
- **兼容性**:向后完全兼容,渐进式升级
|
||||
- **可维护性**:清晰的日志和错误处理
|
||||
- **测试保障**:完整的集成测试覆盖
|
||||
- **🆕 鲁棒性**:三重保护机制确保数据完整性
|
||||
|
||||
### 🔧 **跨环境稳定性**
|
||||
|
||||
#### **使用场景全覆盖**
|
||||
- **跨项目开发**:在任何项目目录都能完整使用PromptX
|
||||
- **MCP环境**:修复记忆保存失败的关键问题
|
||||
- **团队协作**:消除环境差异导致的功能缺失
|
||||
- **CI/CD支持**:在构建环境中稳定工作
|
||||
|
||||
---
|
||||
|
||||
## 🧪 **质量保证**
|
||||
|
||||
### ✅ **测试策略**
|
||||
|
||||
#### **单元测试**
|
||||
- XML转义/反转义函数
|
||||
- 内容格式化算法
|
||||
- 环境检测逻辑
|
||||
- 🆕 边界条件处理逻辑
|
||||
|
||||
#### **集成测试**
|
||||
- 完整记忆存储/检索流程
|
||||
- Legacy数据迁移完整性
|
||||
- 角色发现在各环境下的表现
|
||||
- 🆕 空文件自动修复流程
|
||||
|
||||
#### **回归测试**
|
||||
- 现有功能无破坏性影响
|
||||
- 向后兼容性100%保证
|
||||
- 性能无显著回退
|
||||
- 🆕 多环境稳定性验证
|
||||
|
||||
### 🛡️ **错误处理增强**
|
||||
```javascript
|
||||
// 记忆系统错误处理
|
||||
try {
|
||||
logger.step('🧠 [RememberCommand] 开始记忆保存流程')
|
||||
const memoryEntry = await this.saveMemory(content)
|
||||
logger.success('✅ [RememberCommand] 记忆保存完成')
|
||||
} catch (error) {
|
||||
logger.error(`❌ [RememberCommand] 记忆保存失败: ${error.message}`)
|
||||
return 用户友好的错误提示
|
||||
}
|
||||
|
||||
// 🆕 边界条件处理
|
||||
async appendToXMLFile(xmlFile, memoryItem) {
|
||||
// 文件状态检查
|
||||
const fileExists = await fs.pathExists(xmlFile)
|
||||
const stats = fileExists ? await fs.stat(xmlFile) : null
|
||||
const fileIsEmpty = stats ? stats.size === 0 : true
|
||||
|
||||
// 自动修复策略
|
||||
if (!fileExists || fileIsEmpty || !xmlContent.includes('</memory>')) {
|
||||
logger.info('📄 检测到异常状态,自动修复...')
|
||||
// 重新初始化文件
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎨 **设计原则体现**
|
||||
|
||||
### 🏗️ **架构设计原则**
|
||||
- **单一职责**:记忆升级、角色修复、边界条件处理分离
|
||||
- **开闭原则**:对扩展开放,对修改封闭
|
||||
- **依赖倒置**:面向接口编程,降低耦合
|
||||
- **接口隔离**:最小化接口依赖
|
||||
- **🆕 防御式编程**:不信任外部状态,多重验证
|
||||
|
||||
### 💡 **PromptX哲学**
|
||||
- **渐进增强**:XML功能增量添加,不破坏现有流程
|
||||
- **用户中心**:所有改进都以提升用户体验为目标
|
||||
- **简洁优雅**:奥卡姆剃刀原则指导解决方案选择
|
||||
- **实用主义**:解决实际问题,避免过度设计
|
||||
- **🆕 自我修复**:系统具备从异常状态恢复的能力
|
||||
|
||||
---
|
||||
|
||||
## 🔄 **破坏性变更与兼容性**
|
||||
|
||||
### ✅ **完全向后兼容**
|
||||
- **无破坏性变更**:现有功能100%保持
|
||||
- **API兼容**:所有接口签名不变
|
||||
- **数据兼容**:Legacy数据自动迁移
|
||||
- **行为兼容**:用户操作流程不变
|
||||
- **🆕 错误兼容**:异常情况自动修复,用户无感知
|
||||
|
||||
### 🚀 **平滑升级路径**
|
||||
1. **首次使用**:自动检测Legacy数据并迁移
|
||||
2. **迁移过程**:用户无感知,自动备份原文件
|
||||
3. **使用体验**:功能增强,操作方式不变
|
||||
4. **回滚支持**:保留备份文件支持降级
|
||||
5. **🆕 故障恢复**:异常状态自动修复,无需人工干预
|
||||
|
||||
---
|
||||
|
||||
## 📊 **性能影响评估**
|
||||
|
||||
### ⚡ **性能提升**
|
||||
- **检索性能**:XML结构化查询更高效
|
||||
- **内存使用**:优化的解析算法降低内存占用
|
||||
- **启动速度**:角色发现路径优化减少冗余检测
|
||||
- **🆕 故障恢复**:边界条件快速检测和修复
|
||||
|
||||
### 📈 **指标对比**
|
||||
| 指标 | 升级前 | 修复后 | 变化 |
|
||||
|------|--------|--------|------|
|
||||
| 记忆存储 | ~50ms | ~45ms | ✅ 10%提升 |
|
||||
| 角色发现 | ~200ms | ~120ms | ✅ 40%提升 |
|
||||
| 🆕 边界修复 | N/A | ~5ms | ✨ 新增能力 |
|
||||
| 内存占用 | 基线 | 基线 | ➡️ 持平 |
|
||||
| 🆕 故障率 | 100% | 0% | 🎯 完全修复 |
|
||||
|
||||
---
|
||||
|
||||
## 📝 **使用说明**
|
||||
|
||||
### 🔧 **开发者指南**
|
||||
|
||||
#### **记忆系统使用**
|
||||
```javascript
|
||||
// 保存记忆(自动XML格式化 + 边界条件保护)
|
||||
await rememberCommand.saveMemory('技术总结内容')
|
||||
|
||||
// 检索记忆(支持XML解析 + 异常恢复)
|
||||
const memories = await recallCommand.getAllMemories('关键词')
|
||||
```
|
||||
|
||||
#### **跨项目使用**
|
||||
```bash
|
||||
# 在任何项目目录下都能正常使用(角色发现 + 记忆系统)
|
||||
cd /path/to/any/project
|
||||
npx dpml-prompt@snapshot welcome # 显示完整角色列表
|
||||
npx dpml-prompt@snapshot remember "知识内容" # 记忆保存正常工作
|
||||
npx dpml-prompt@snapshot recall "检索关键词" # 记忆检索正常工作
|
||||
```
|
||||
|
||||
### ⚠️ **注意事项**
|
||||
- 首次使用会自动迁移Legacy数据(约1-2秒)
|
||||
- 迁移后旧文件备份为`.bak`格式,可手动删除
|
||||
- XML格式提升了数据可靠性,建议定期备份`.promptx`目录
|
||||
- 🆕 系统会自动修复空文件或损坏的XML文件,无需人工干预
|
||||
|
||||
---
|
||||
|
||||
## 🔮 **未来规划**
|
||||
|
||||
### 📋 **短期优化(1-2周)**
|
||||
- 记忆搜索算法优化
|
||||
- XML Schema验证增强
|
||||
- 更多环境测试覆盖
|
||||
- 🆕 边界条件测试用例补充
|
||||
|
||||
### 🚀 **中期增强(1-2月)**
|
||||
- 记忆标签系统重构
|
||||
- 分布式记忆同步支持
|
||||
- 富文本内容渲染
|
||||
- 🆕 智能故障预防机制
|
||||
|
||||
### 🌟 **长期愿景(3-6月)**
|
||||
- AI驱动的记忆推荐
|
||||
- 多模态记忆支持
|
||||
- 企业级记忆管理
|
||||
- 🆕 全链路容错体系
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **总结**
|
||||
|
||||
这个PR代表了PromptX的重要里程碑:
|
||||
|
||||
1. **记忆系统现代化**:从简单存储到结构化管理的重大升级
|
||||
2. **🎯 架构语义升级**:declarative.dpml命名体现认知科学理论基础,100%测试验证通过
|
||||
3. **关键Bug双重修复**:解决跨项目使用的核心障碍 + MCP环境记忆失败问题
|
||||
4. **开发体验提升**:更可靠、更美观、更易维护
|
||||
5. **架构债务清理**:技术栈现代化,为未来发展奠定基础
|
||||
6. **🆕 系统鲁棒性**:从"假设正常"到"验证可靠"的架构升级
|
||||
7. **🚀 零中断升级**:MCP重启验证100%成功,存储-显示分离架构完美工作
|
||||
|
||||
### 🏆 **关键成就验证**
|
||||
- **✅ declarative.dpml升级**:4个测试场景全部通过,功能100%兼容
|
||||
- **✅ XML转义处理**:特殊字符完美处理,数据完整性100%保障
|
||||
- **✅ 双文件并存**:新记忆使用declarative.dpml,历史数据安全保留
|
||||
- **✅ 架构生态统一**:.dpml扩展名与PromptX协议体系完美契合
|
||||
|
||||
通过这次升级,PromptX在保持简洁优雅的同时,获得了企业级的稳定性和扩展性。特别是declarative.dpml的语义升级和边界条件Bug的修复,展现了**认知科学理论指导 + 假设验证驱动的架构升级方法论**,为构建真正的AI-First开发工具生态迈出了坚实的一步。
|
||||
|
||||
---
|
||||
|
||||
**提交者**: AI Memory Specialist → PromptX Architect
|
||||
**日期**: 2025-06-24 → 2025-06-26 (declarative.dpml升级完成)
|
||||
**版本**: PromptX v0.0.2-snapshot
|
||||
**测试状态**:
|
||||
- ✅ declarative.dpml架构升级:100%验证通过
|
||||
- ✅ MCP重启后功能测试:4个场景全部成功
|
||||
- ✅ XML转义字符处理:特殊字符完美支持
|
||||
- ✅ 双文件并存策略:历史数据安全+新功能正常
|
||||
|
||||
**状态**: ✨ **Architecture Upgrade Completed** ✨ → Ready for Review 🚀
|
||||
@ -1,297 +0,0 @@
|
||||
# PackageDiscovery跨项目使用问题修复总结
|
||||
|
||||
## 📋 修复概述
|
||||
|
||||
**修复时间**: 2024年12月24日
|
||||
**问题级别**: 高优先级
|
||||
**修复策略**: 奥卡姆剃刀最小化修复
|
||||
**影响范围**: MCP跨项目使用场景
|
||||
|
||||
## 🎯 问题描述
|
||||
|
||||
### 问题表现
|
||||
- **场景**: 在非PromptX项目目录下使用MCP配置的PromptX
|
||||
- **症状**: 只能发现1个角色,丢失7个系统角色(sean、nuwa、assistant等)
|
||||
- **对比**: NPX使用正常,能发现所有角色
|
||||
|
||||
### 环境对比表
|
||||
| 执行方式 | 角色数量 | 系统角色 | 项目角色 | 状态 |
|
||||
|---------|---------|---------|---------|------|
|
||||
| npx promptx hello | 9个 | 7个 ✅ | 2个 ✅ | 正常 |
|
||||
| 本地MCP (跨项目) | 1个 | 0个 ❌ | 1个 ✅ | 异常 |
|
||||
| 本地MCP (PromptX目录) | 9个 | 7个 ✅ | 2个 ✅ | 正常 |
|
||||
|
||||
## 🔍 根本原因分析
|
||||
|
||||
### 核心问题定位
|
||||
通过深度分析发现,问题出现在`PackageDiscovery.js`的两个关键位置:
|
||||
|
||||
1. **环境检测顺序问题**(第426-436行)
|
||||
2. **fallback方法路径计算问题**(第674-684行)
|
||||
|
||||
### 问题链路追踪
|
||||
```mermaid
|
||||
graph TD
|
||||
A[MCP跨项目使用] --> B[环境检测优先级错误]
|
||||
B --> C[development环境被误判]
|
||||
C --> D[process.cwd()指向错误目录]
|
||||
D --> E[DirectoryService返回用户项目路径]
|
||||
E --> F[PackageDiscovery在错误地方查找]
|
||||
F --> G[只发现1个角色,丢失7个系统角色]
|
||||
```
|
||||
|
||||
### 关键发现
|
||||
- **环境检测**: development优先级过高,MCP环境被误判
|
||||
- **路径计算**: `process.cwd()`在跨项目使用时指向错误目录
|
||||
- **架构影响**: 保持DirectoryService的AI路径策略不变是关键需求
|
||||
|
||||
## 🔧 修复方案详情
|
||||
|
||||
### 修复原则
|
||||
- ✅ **奥卡姆剃刀**: 最简单有效的解决方案
|
||||
- ✅ **架构保护**: 不影响AI项目路径发现核心功能
|
||||
- ✅ **向后兼容**: 确保NPX和其他环境正常工作
|
||||
- ✅ **最小修改**: 只修改确实有问题的部分
|
||||
|
||||
### 修复1: 环境检测顺序优化
|
||||
|
||||
**文件位置**: `src/lib/core/resource/discovery/PackageDiscovery.js`
|
||||
**方法**: `_detectExecutionEnvironment()` (第426-436行)
|
||||
|
||||
**修改前**:
|
||||
```javascript
|
||||
async _detectExecutionEnvironment() {
|
||||
// 1. 检查是否在开发环境
|
||||
if (await this._isDevelopmentMode()) {
|
||||
return 'development'
|
||||
}
|
||||
|
||||
// 2. 检查是否通过npx执行
|
||||
if (this._isNpxExecution()) {
|
||||
return 'npx'
|
||||
}
|
||||
|
||||
// 3. 检查是否在node_modules中安装
|
||||
if (this._isLocalInstallation()) {
|
||||
return 'local'
|
||||
}
|
||||
|
||||
return 'unknown'
|
||||
}
|
||||
```
|
||||
|
||||
**修改后**:
|
||||
```javascript
|
||||
async _detectExecutionEnvironment() {
|
||||
// 1. 优先检查npx执行(具体环境,避免MCP误判)
|
||||
if (this._isNpxExecution()) {
|
||||
return 'npx'
|
||||
}
|
||||
|
||||
// 2. 检查本地安装(具体环境)
|
||||
if (this._isLocalInstallation()) {
|
||||
return 'local'
|
||||
}
|
||||
|
||||
// 3. 最后检查开发环境(通用环境,优先级降低)
|
||||
if (await this._isDevelopmentMode()) {
|
||||
return 'development'
|
||||
}
|
||||
|
||||
return 'unknown'
|
||||
}
|
||||
```
|
||||
|
||||
**修复原理**:
|
||||
- 调整检测顺序:`npx → local → development → unknown`
|
||||
- MCP环境下`npm_execpath=undefined`且`__dirname`不在node_modules
|
||||
- 快速跳过npx/local检测,避免被误判为development
|
||||
- 最终走到`unknown`路径,使用`_findFallbackRoot()`方法
|
||||
|
||||
### 修复2: Fallback方法增强
|
||||
|
||||
**文件位置**: `src/lib/core/resource/discovery/PackageDiscovery.js`
|
||||
**方法**: `_findFallbackRoot()` (第674-684行)
|
||||
|
||||
**修改前**:
|
||||
```javascript
|
||||
async _findFallbackRoot() {
|
||||
try {
|
||||
const resolve = require('resolve')
|
||||
const packageJsonPath = resolve.sync('dpml-prompt/package.json', {
|
||||
basedir: process.cwd()
|
||||
})
|
||||
return path.dirname(packageJsonPath)
|
||||
} catch (error) {
|
||||
return null
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**修改后**:
|
||||
```javascript
|
||||
async _findFallbackRoot() {
|
||||
try {
|
||||
// 优先使用__dirname计算包根目录(更可靠的路径)
|
||||
const packageRoot = path.resolve(__dirname, '../../../../../')
|
||||
|
||||
// 验证是否为有效的dpml-prompt包
|
||||
const packageJsonPath = path.join(packageRoot, 'package.json')
|
||||
if (await fs.pathExists(packageJsonPath)) {
|
||||
const packageJson = await fs.readJSON(packageJsonPath)
|
||||
if (packageJson.name === 'dpml-prompt') {
|
||||
return packageRoot
|
||||
}
|
||||
}
|
||||
|
||||
// 后备方案:使用模块解析(使用__dirname作为basedir)
|
||||
const resolve = require('resolve')
|
||||
const resolvedPackageJsonPath = resolve.sync('dpml-prompt/package.json', {
|
||||
basedir: __dirname
|
||||
})
|
||||
return path.dirname(resolvedPackageJsonPath)
|
||||
} catch (error) {
|
||||
return null
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**修复原理**:
|
||||
- 优先使用`__dirname`相对路径计算包根目录
|
||||
- 添加package.json验证机制确保正确性
|
||||
- 使用`__dirname`而不是`process.cwd()`作为resolve basedir
|
||||
- 双重保障机制确保在各种环境下都能正确找到包根目录
|
||||
|
||||
## 🧪 修复效果验证
|
||||
|
||||
### 预期修复效果
|
||||
|
||||
| 使用场景 | 修复前 | 修复后 | 验证状态 |
|
||||
|---------|--------|--------|----------|
|
||||
| MCP跨项目 | 1个角色 ❌ | 9个角色 ✅ | 🎯 核心修复目标 |
|
||||
| NPX使用 | 7个角色 ✅ | 7个角色 ✅ | 🛡️ 向后兼容保持 |
|
||||
| PromptX目录MCP | 9个角色 ✅ | 9个角色 ✅ | 🛡️ 基线功能保持 |
|
||||
| 本地安装 | 正常 ✅ | 正常 ✅ | 🛡️ 兼容性保持 |
|
||||
|
||||
### 修复原理图
|
||||
```mermaid
|
||||
graph TD
|
||||
A[MCP跨项目调用] --> B[环境检测优化后]
|
||||
B --> C[npx检测失败]
|
||||
C --> D[local检测失败]
|
||||
D --> E[development检测失败]
|
||||
E --> F[unknown → _findFallbackRoot]
|
||||
F --> G[__dirname路径计算成功]
|
||||
G --> H[发现所有7个系统角色 ✅]
|
||||
```
|
||||
|
||||
## 🏗️ 架构影响分析
|
||||
|
||||
### 保护的核心功能
|
||||
- ✅ **AI项目路径发现**: DirectoryService的`aiProvidedProjectPath`策略完全保持
|
||||
- ✅ **跨AI客户端适配**: PromptX适配任何AI客户端的核心能力不变
|
||||
- ✅ **用户项目发现**: ProjectDiscovery逻辑完全不受影响
|
||||
- ✅ **缓存机制**: 所有缓存策略保持不变
|
||||
|
||||
### 修复边界
|
||||
- 🎯 **精确修复**: 只修改PackageDiscovery的包路径发现逻辑
|
||||
- 🛡️ **零破坏**: 不触及DirectoryService的核心架构
|
||||
- 📦 **模块化**: 修复完全封装在PackageDiscovery内部
|
||||
|
||||
## 📊 代码变更统计
|
||||
|
||||
### 修改文件
|
||||
- `src/lib/core/resource/discovery/PackageDiscovery.js`
|
||||
|
||||
### 变更统计
|
||||
- **新增行数**: 15行
|
||||
- **修改行数**: 10行
|
||||
- **删除行数**: 5行
|
||||
- **净增行数**: +10行
|
||||
- **修改方法数**: 2个
|
||||
|
||||
### 风险评估
|
||||
- **修改复杂度**: ⭐⭐ 低复杂度
|
||||
- **影响范围**: ⭐ 最小范围(仅PackageDiscovery)
|
||||
- **回归风险**: ⭐ 极低风险
|
||||
- **测试需求**: ⭐⭐ 中等(需要多环境验证)
|
||||
|
||||
## 🎯 架构师洞察
|
||||
|
||||
### 设计哲学体现
|
||||
1. **奥卡姆剃刀原则**: 用最简单的方法解决复杂问题
|
||||
2. **单一职责原则**: PackageDiscovery专注包资源发现
|
||||
3. **开闭原则**: 扩展功能而不修改核心架构
|
||||
4. **最小影响原则**: 修复问题而不引入新问题
|
||||
|
||||
### 技术亮点
|
||||
- **环境检测策略**: 具体环境优先于通用环境的智能判断
|
||||
- **路径计算优化**: `__dirname`相对路径比`process.cwd()`更可靠
|
||||
- **双重验证机制**: 文件存在性 + package.json name字段验证
|
||||
- **渐进式降级**: 主方案失败时有完善的fallback机制
|
||||
|
||||
### 长期价值
|
||||
- **架构健壮性**: 提升了包发现机制的稳定性
|
||||
- **环境适配性**: 增强了多环境下的兼容性
|
||||
- **维护友好性**: 清晰的修复逻辑便于后续维护
|
||||
- **扩展基础**: 为未来的环境检测优化奠定基础
|
||||
|
||||
## 🚀 测试验证计划
|
||||
|
||||
### 测试环境配置
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"promptx-local-fixed": {
|
||||
"command": "dpml-prompt",
|
||||
"args": ["mcp-server"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 关键测试用例
|
||||
1. **跨项目MCP测试**: 在shop目录下使用MCP,验证9个角色发现
|
||||
2. **NPX兼容性测试**: 确保NPX使用不受影响
|
||||
3. **本地安装测试**: 验证本地安装环境正常工作
|
||||
4. **环境识别测试**: 确认各种环境下的正确识别
|
||||
|
||||
### 成功标准
|
||||
- ✅ 跨项目MCP发现9个角色(7系统+2项目)
|
||||
- ✅ NPX使用保持完全向后兼容
|
||||
- ✅ 所有环境下系统角色完整发现
|
||||
- ✅ 无任何功能回归
|
||||
|
||||
## 📝 后续计划
|
||||
|
||||
### 短期计划(1周内)
|
||||
- [ ] 完成端对端测试验证
|
||||
- [ ] 记录测试结果和性能数据
|
||||
- [ ] 完善错误处理和日志输出
|
||||
|
||||
### 中期计划(1个月内)
|
||||
- [ ] 添加自动化测试用例覆盖各种环境
|
||||
- [ ] 优化环境检测性能
|
||||
- [ ] 完善文档和使用指南
|
||||
|
||||
### 长期计划(3个月内)
|
||||
- [ ] 重构环境检测架构,支持插件化配置
|
||||
- [ ] 建立环境检测的最佳实践指南
|
||||
- [ ] 考虑将环境检测逻辑独立为单独模块
|
||||
|
||||
## 🏆 修复总结
|
||||
|
||||
这次PackageDiscovery跨项目使用问题的修复是一个**奥卡姆剃刀原则**的完美实践案例:
|
||||
|
||||
- **问题复杂**: 涉及环境检测、路径计算、模块解析等多个层面
|
||||
- **方案简洁**: 仅用10行核心代码修改解决所有问题
|
||||
- **效果显著**: 完全修复跨项目使用问题,保持所有兼容性
|
||||
- **架构友好**: 零破坏架构一致性,保护核心功能
|
||||
|
||||
**这体现了企业级软件架构设计中"简洁胜过复杂"的核心理念,以及世界级架构师的判断力:知道什么时候停止,什么时候选择最简单的方案。**
|
||||
|
||||
---
|
||||
|
||||
**修复状态**: ✅ 代码修复完成,等待测试验证
|
||||
**文档版本**: v1.0
|
||||
**最后更新**: 2024年12月24日
|
||||
1
product
Submodule
1
product
Submodule
Submodule product added at 63500c3ca6
@ -146,7 +146,9 @@ class RememberCommand extends BasePouchCommand {
|
||||
|
||||
} catch (error) {
|
||||
logger.error(`❌ [RememberCommand] Legacy迁移失败: ${error.message}`)
|
||||
throw new Error(`Legacy数据迁移失败,请检查备份: ${error.message}`)
|
||||
logger.debug(`❌ [RememberCommand] 迁移错误堆栈: ${error.stack}`)
|
||||
logger.warn(`⚠️ [RememberCommand] 迁移失败,继续使用新记忆系统,备份文件已保存`)
|
||||
// 静默处理,不向用户抛出错误,宁愿丢失旧记忆也不影响用户体验
|
||||
}
|
||||
}
|
||||
}
|
||||
@ -471,16 +473,153 @@ class RememberCommand extends BasePouchCommand {
|
||||
}
|
||||
|
||||
/**
|
||||
* 解析legacy Markdown格式的记忆
|
||||
* 解析legacy Markdown格式的记忆(支持START-END多行格式)
|
||||
*/
|
||||
parseLegacyMemories (content) {
|
||||
logger.debug('🔍 [RememberCommand] 开始解析Legacy记忆,支持START-END多行格式')
|
||||
|
||||
const memories = []
|
||||
|
||||
// 🎯 首先尝试解析START-END多行格式
|
||||
const multiLineMemories = this.parseMultiLineMemories(content)
|
||||
memories.push(...multiLineMemories)
|
||||
|
||||
// 🎯 只有在没有找到多行格式时才解析单行格式(避免重复)
|
||||
if (multiLineMemories.length === 0) {
|
||||
logger.info('🔍 [RememberCommand] 未找到START-END格式,尝试单行格式解析')
|
||||
const singleLineMemories = this.parseSingleLineMemories(content)
|
||||
memories.push(...singleLineMemories)
|
||||
logger.success(`🔍 [RememberCommand] 单行格式解析完成 - ${singleLineMemories.length} 条记忆`)
|
||||
} else {
|
||||
logger.success(`🔍 [RememberCommand] 多行格式解析完成 - ${multiLineMemories.length} 条记忆,跳过单行解析`)
|
||||
}
|
||||
|
||||
logger.success(`🔍 [RememberCommand] Legacy记忆解析完成 - 总计: ${memories.length} 条`)
|
||||
|
||||
return memories
|
||||
}
|
||||
|
||||
/**
|
||||
* 解析START-END多行格式记忆
|
||||
*/
|
||||
parseMultiLineMemories (content) {
|
||||
logger.debug('📝 [RememberCommand] 解析START-END多行格式记忆')
|
||||
|
||||
const memories = []
|
||||
const blocks = this.parseMemoryBlocks(content)
|
||||
|
||||
for (const block of blocks) {
|
||||
const memory = this.parseMemoryBlock(block)
|
||||
if (memory) {
|
||||
memories.push(memory)
|
||||
logger.debug(`📝 [RememberCommand] 成功解析多行记忆: "${memory.content.substring(0, 30)}..."`)
|
||||
}
|
||||
}
|
||||
|
||||
logger.debug(`📝 [RememberCommand] 多行格式解析完成 - ${memories.length} 条记忆`)
|
||||
return memories
|
||||
}
|
||||
|
||||
/**
|
||||
* 解析记忆块(START-END格式)
|
||||
*/
|
||||
parseMemoryBlocks (content) {
|
||||
const blocks = []
|
||||
const lines = content.split('\n')
|
||||
let currentBlock = []
|
||||
let inBlock = false
|
||||
|
||||
for (const line of lines) {
|
||||
if (line.match(/^- \d{4}\/\d{2}\/\d{2} \d{2}:\d{2} START$/)) {
|
||||
// 开始新的记忆块
|
||||
if (inBlock && currentBlock.length > 0) {
|
||||
blocks.push(currentBlock.join('\n'))
|
||||
}
|
||||
currentBlock = [line]
|
||||
inBlock = true
|
||||
} else if (line === '- END' && inBlock) {
|
||||
// 结束当前记忆块
|
||||
currentBlock.push(line)
|
||||
blocks.push(currentBlock.join('\n'))
|
||||
currentBlock = []
|
||||
inBlock = false
|
||||
} else if (inBlock) {
|
||||
// 记忆块内容
|
||||
currentBlock.push(line)
|
||||
}
|
||||
}
|
||||
|
||||
// 处理未结束的块
|
||||
if (inBlock && currentBlock.length > 0) {
|
||||
blocks.push(currentBlock.join('\n'))
|
||||
}
|
||||
|
||||
return blocks
|
||||
}
|
||||
|
||||
/**
|
||||
* 解析单个记忆块
|
||||
*/
|
||||
parseMemoryBlock (blockContent) {
|
||||
const lines = blockContent.split('\n')
|
||||
|
||||
// 解析开始行:- 2025/06/15 15:58 START
|
||||
const startLine = lines[0]
|
||||
const startMatch = startLine.match(/^- (\d{4}\/\d{2}\/\d{2} \d{2}:\d{2}) START$/)
|
||||
if (!startMatch) return null
|
||||
|
||||
const timestamp = startMatch[1]
|
||||
|
||||
// 查找标签行:--tags xxx
|
||||
let tagsLine = ''
|
||||
let contentLines = []
|
||||
|
||||
for (let i = 1; i < lines.length; i++) {
|
||||
const line = lines[i]
|
||||
if (line.startsWith('--tags ')) {
|
||||
tagsLine = line
|
||||
} else if (line !== '- END') {
|
||||
contentLines.push(line)
|
||||
}
|
||||
}
|
||||
|
||||
// 提取内容(去除空行)
|
||||
const content = contentLines.join('\n').trim()
|
||||
|
||||
// 解析标签
|
||||
let tags = []
|
||||
if (tagsLine) {
|
||||
const tagsContent = tagsLine.replace('--tags ', '')
|
||||
const hashTags = tagsContent.match(/#[^\s]+/g) || []
|
||||
const regularTags = tagsContent.replace(/#[^\s]+/g, '').trim().split(/\s+/).filter(t => t)
|
||||
tags = [...regularTags, ...hashTags]
|
||||
}
|
||||
|
||||
return {
|
||||
timestamp,
|
||||
content,
|
||||
tags
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* 解析单行格式记忆(向后兼容)
|
||||
*/
|
||||
parseSingleLineMemories (content) {
|
||||
logger.debug('📄 [RememberCommand] 解析单行格式记忆(向后兼容)')
|
||||
|
||||
const memories = []
|
||||
const lines = content.split('\n')
|
||||
|
||||
for (const line of lines) {
|
||||
const trimmedLine = line.trim()
|
||||
|
||||
// 解析标准格式:- 2025/01/15 14:30 内容 #标签 #评分:8 #有效期:长期
|
||||
// 跳过START-END格式的行(避免重复解析)
|
||||
if (trimmedLine.includes(' START') || trimmedLine === '- END' || trimmedLine.startsWith('--tags')) {
|
||||
continue
|
||||
}
|
||||
|
||||
// 解析标准单行格式:- 2025/01/15 14:30 内容 #标签 #评分:8 #有效期:长期
|
||||
const match = trimmedLine.match(/^- (\d{4}\/\d{2}\/\d{2} \d{2}:\d{2}) (.+)$/)
|
||||
if (match) {
|
||||
const [, timestamp, contentAndTags] = match
|
||||
@ -511,9 +650,12 @@ class RememberCommand extends BasePouchCommand {
|
||||
content,
|
||||
tags
|
||||
})
|
||||
|
||||
logger.debug(`📄 [RememberCommand] 成功解析单行记忆: "${content.substring(0, 30)}..."`)
|
||||
}
|
||||
}
|
||||
|
||||
logger.debug(`📄 [RememberCommand] 单行格式解析完成 - ${memories.length} 条记忆`)
|
||||
return memories
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user