BossAgents × 微信智能体生态 — 编码任务规划文档

版本：1.0 | 日期：2026-06-25 | 基于需求规格文档v1.0 + 优化方案v2.0生成

项目约束（必须遵守）

关键现有模块（复用/扩展）

Phase 0 — 前置修复

TASK-0-01：JWT密钥硬编码fallback修复

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-0-01 |

| 优先级 | P0 |

| 依赖任务 | 无 |

| 预估工作量 | 0.5天 |

实现步骤：

1. 修改server/routes/miniapp-auth.js第65行：将process.env.JWT_SECRET || 'change-me-in-production'改为process.env.JWT_SECRET，移除硬编码fallback

• 在文件顶部（handleMiniappRoute函数内，第14行后）添加JWT_SECRET检查逻辑：

   // 在 handleMiniappRoute 函数体开头添加
   if (!process.env.JWT_SECRET) {
     console.error('[miniapp-auth] FATAL: JWT_SECRET environment variable is required');
     json(500, { error: '服务器配置错误：JWT_SECRET未设置' });
     return true;
   }
   

• 第65行改为：process.env.JWT_SECRET（移除|| 'change-me-in-production'）
• 第82行改为：process.env.JWT_SECRET（移除|| 'change-me-in-production'）
• 第95行改为：process.env.JWT_SECRET（移除|| 'change-me-in-production'）

1. 修改server.js启动入口：在服务器启动时添加JWT_SECRET环境变量检查

• 在server.js中server.listen回调前（约第5090行附近），添加：

   if (!process.env.JWT_SECRET) {
     console.error('FATAL: JWT_SECRET environment variable is required. Server cannot start.');
     process.exit(1);
   }
   

1. 更新.env.example文件：添加JWT_SECRET=your-secret-key-here配置项及注释说明

1. Token缓存持久化：在server/routes/miniapp-auth.js中，将Token缓存从内存Map改为文件持久化

• 新建server/services/token-cache.js，实现基于文件的Token缓存（单实例场景用JSON文件，路径server/data/token-cache.json）
• 提供get(key)、set(key, value, ttl)、delete(key)方法
• 在miniapp-auth.js中引入并使用token-cache替代内存缓存

验证方法：

• 删除.env中JWT_SECRET配置，启动node server.js，确认进程退出并输出错误提示
• 设置JWT_SECRET后启动，确认正常启动
• 重启服务器后，之前签发的Token仍可验证（文件持久化生效）

TASK-0-02：审计日志DB写入确认与修复

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-0-02 |

| 优先级 | P0 |

| 依赖任务 | 无 |

| 预估工作量 | 0.5天 |

实现步骤：

1. 确认server/utils/audit-logger.js的数据库写入逻辑：

• 读取audit-logger.js，确认logAudit()函数是否将日志写入数据库（而非仅文件）
• 检查是否有audit_logs表或sciot_audit_logs表的创建逻辑

1. 确认server/services/db-schema-init.js是否包含审计日志表初始化：

• 检查db-schema-init.js中是否有audit_logs表的CREATE TABLE语句
• 如果没有，添加审计日志表定义：

   CREATE TABLE IF NOT EXISTS audit_logs (
     id INTEGER PRIMARY KEY AUTOINCREMENT,
     category TEXT NOT NULL,
     level TEXT NOT NULL DEFAULT 'info',
     action TEXT NOT NULL,
     target_type TEXT DEFAULT '',
     user_id TEXT DEFAULT '',
     detail TEXT DEFAULT '',
     source TEXT DEFAULT '',
     metadata TEXT DEFAULT '{}',
     created_at DATETIME DEFAULT (datetime('now','localtime'))
   );
   CREATE INDEX IF NOT EXISTS idx_audit_logs_action ON audit_logs(action);
   CREATE INDEX IF NOT EXISTS idx_audit_logs_user_id ON audit_logs(user_id);
   CREATE INDEX IF NOT EXISTS idx_audit_logs_created_at ON audit_logs(created_at);
   

1. 确认server/services/audit-log.js的start/complete是否实际调用logAudit写入DB：

• 已确认：start()在第46行调用logAudit()，complete()在第78行调用logAudit()
• 需确认logAudit()底层是否成功写入数据库

1. 修复audit-logs目录空置问题：

• 如果logAudit()仅写文件不写DB，修改为优先写DB
• 在logAudit()中添加DB写入逻辑（使用db-adapter获取数据库连接）
• DB写入失败时降级写本地文件server/data/audit-logs/目录

验证方法：

• 执行一次数字员工任务（如BOM查询），查询数据库SELECT * FROM audit_logs ORDER BY id DESC LIMIT 5
• 确认数据库中有对应的start和complete两条记录
• 检查audit-logs/目录状态，确认日志存储策略

TASK-0-03：审计日志查询API

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-0-03 |

| 优先级 | P0 |

| 依赖任务 | TASK-0-02 |

| 预估工作量 | 0.5天 |

实现步骤：

1. 修改server/routes/audit-log.js：添加审计日志查询路由

• 在现有路由基础上，添加GET /api/audit-logs查询接口
• 支持查询参数：staffId（员工ID）、from（开始时间）、to（结束时间）、capability（能力类型）、page（页码，默认1）、pageSize（每页条数，默认20）
• 实现SQL查询：

   // 在 handleAuditLogRoute 函数中添加
   if (req.method === 'GET' && pathname === '/api/audit-logs') {
     const { staffId, from, to, capability, page = '1', pageSize = '20' } = query;
     let sql = 'SELECT * FROM audit_logs WHERE 1=1';
     const params = [];
     if (staffId) { sql += ' AND user_id = ?'; params.push(staffId); }
     if (from) { sql += ' AND created_at >= ?'; params.push(from); }
     if (to) { sql += ' AND created_at <= ?'; params.push(to); }
     if (capability) { sql += ' AND action LIKE ?'; params.push(`%${capability}%`); }
     sql += ' ORDER BY created_at DESC LIMIT ? OFFSET ?';
     const limit = parseInt(pageSize);
     const offset = (parseInt(page) - 1) * limit;
     params.push(limit, offset);
     // 执行查询并返回
   }
   

1. 在server.js的handleRequest中注册路由：

• 在server.js的路由分发区域，添加audit-log路由的调用
• 确保路由在认证中间件之后执行

验证方法：

• 调用GET /api/audit-logs?staffId=xxx&from=2026-01-01，确认返回审计记录列表
• 不带参数调用，确认返回默认分页结果

TASK-0-04：知识库前端接入后端搜索API

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-0-04 |

| 优先级 | P0 |

| 依赖任务 | 无 |

| 预估工作量 | 2天 |

实现步骤：

1. 确认后端搜索API端点：

• 已有server/routes/process-knowledge.js第97行：GET /api/process-knowledge/search
• 已有前端调用：src/components/anysearch/AnySearchPanel.vue第589行和src/composables/useProcessKnowledge.js第18行
• 需确认：前端是否有其他硬编码的知识库数据（如设计模式/最佳实践/AML知识）

1. 搜索src/目录下所有硬编码知识数据：

• 搜索包含"设计模式"、"最佳实践"、"AML知识"等硬编码数据的Vue组件
• 将硬编码数据替换为对/api/process-knowledge/search的fetch调用

1. 统一搜索结果格式：

• 修改server/core/knowledge-search.js的search()方法返回值，确保包含id、title、content、category、relevanceScore字段
• 在_fallbackLikeSearch()方法中，将结果映射为统一格式：

   return results.map(r => ({
     id: r.id,
     title: r.process_type || r.process_category || '',
     content: r.parameters || r.applicable_conditions || '',
     category: r.process_category || r.source_type || '',
     relevanceScore: 0.5 // LIKE搜索固定分数
   }));
   

1. 修改server/routes/process-knowledge.js搜索路由：

• 确保搜索接口返回统一格式的JSON
• 添加q参数支持（兼容query参数）
• 添加错误处理：搜索服务不可用时返回友好错误

1. 前端搜索组件改造：

• 修改src/components/anysearch/AnySearchPanel.vue，将硬编码数据替换为API调用
• 修改src/composables/useProcessKnowledge.js，统一搜索接口调用方式
• 添加搜索错误处理：显示"搜索服务暂时不可用"提示和重试按钮

1. 前端构建验证：

• 执行npm run build确认构建成功

验证方法：

• 前端知识库页面输入搜索关键词，确认发起fetch('/api/process-knowledge/search?q=...')请求
• 后端知识库新增规则后，前端搜索可立即检索到
• 搜索中文关键词"变更流程"，确认返回匹配结果

TASK-0-05：搜索降级策略（FTS5→LIKE）增强

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-0-05 |

| 优先级 | P0 |

| 依赖任务 | TASK-0-04 |

| 预估工作量 | 1天 |

实现步骤：

1. 增强server/core/knowledge-search.js的LIKE搜索：

• 在_fallbackLikeSearch()方法中，添加简单中文分词逻辑（替代jieba）
• 实现基于字符级n-gram的中文分词：

   _simpleChineseTokenize(query) {
     // 移除标点符号
     const cleaned = query.replace(/[，。！？、；：""''（）【】《》\s]/g, ' ').trim();
     const tokens = cleaned.split(/\s+/).filter(t => t.length > 0);
     // 对每个token，如果是中文且长度>2，生成2-gram
     const result = [];
     for (const token of tokens) {
       if (/[\u4e00-\u9fa5]/.test(token) && token.length > 2) {
         for (let i = 0; i <= token.length - 2; i++) {
           result.push(token.substring(i, i + 2));
         }
       } else {
         result.push(token);
       }
     }
     return result;
   }
   

1. 修改_fallbackLikeSearch()使用新分词：

• 将query.split(/\s+/)替换为this._simpleChineseTokenize(query)
• 优化LIKE查询条件，支持n-gram匹配

1. 添加搜索结果排序增强：

• 在LIKE搜索结果中，基于关键词匹配数量计算简单的relevanceScore
• 匹配字段越多、匹配关键词越多的结果排在前面

验证方法：

• 搜索中文关键词"变更流程"，确认返回包含"变更流程"的知识条目
• 搜索英文关键词"BOM"，确认返回匹配结果
• 搜索混合关键词，确认分词和匹配正常

TASK-0-06：OpenClaw/ClawBot接入可行性调研

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-0-06 |

| 优先级 | P1 |

| 依赖任务 | 无 |

| 预估工作量 | 1天 |

实现步骤：

1. 调研OpenClaw CLI是否公开可用：

• 尝试执行npx -y @tencent-weixin/openclaw-weixin-cli@latest --help
• 搜索npm registry中是否存在@tencent-weixin/openclaw-weixin-cli包
• 记录结论：可行/不可行/待定

1. 调研ClawBot插件是否对第三方开发者开放：

• 搜索微信开放平台文档中关于ClawBot/微信AI插件的说明
• 确认"我→设置→插件→ClawBot→启用"功能是否对所有开发者开放
• 记录结论

1. 调研iLink协议接入门槛：

• 搜索iLink协议文档，确认外部项目接入路径
• 评估接入所需的技术要求和审批流程
• 记录结论

1. 评估备选方案（如果OpenClaw不可行）：

• 企业微信自建应用：标准API，完全可控，工作量1-2天
• 微信公众号+客服消息接口：需公众号认证，工作量2-3天
• 小程序内嵌对话：已有bossagents-miniapp，工作量0.5天
• 对三种方案进行可行性评估、工作量估算、推荐排序

1. 产出调研报告：

• 新建docs/research/openclaw-feasibility-report.md
• 包含：结论、依据、推荐方案、风险点、下一步行动

验证方法：

• 调研报告包含三项内容的明确结论（可行/不可行/待定）
• 如果不可行，报告包含三种备选方案的评估
• 报告包含"推荐方案"和"下一步行动"章节

Phase 1 — 快速见效

TASK-1-01：微信消息接收与转发

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-01 |

| 优先级 | P0 |

| 依赖任务 | TASK-0-06 |

| 预估工作量 | 2天 |

实现步骤：

1. 新建微信通道模块server/channels/wechat-channel.js：

• 参考现有server/feishu-bot.js的实现模式
• 实现微信消息接收（回调URL验证+消息解密+消息解析）
• 支持两种接入方式：
• 方式A：ClawBot插件（如果TASK-0-06调研可行）
• 方式B：企业微信自建应用（默认方案）

1. 企业微信自建应用接入实现：

• 在wechat-channel.js中实现企微回调URL验证（GET请求，echostr解密回传）
• 实现消息接收（POST请求，XML解析→JSON转换）
• 支持文本消息、图片消息（图片消息回复"暂不支持该消息类型"）
• 消息解密使用企微提供的加解密库（@wecom/crypto或自行实现AES解密）

1. 消息转发至CapabilityDispatcher：

• 在wechat-channel.js中，将微信消息转换为统一格式：

   const dispatchRequest = {
     source: 'wechat',
     userId: msg.FromUserName,
     content: msg.Content,
     messageType: msg.MsgType,
     tenantId: extractTenantId(msg) // 从企微corpid映射
   };
   

• 调用CapabilityDispatcher.dispatch(dispatchRequest)

1. 在server.js中注册微信通道路由：

• 添加GET /api/wechat/callback（URL验证）
• 添加POST /api/wechat/callback（消息接收）
• POST路由使用collectBody(req)获取bodyStr后解析XML

1. 添加微信通道配置：

• 在config.yaml中添加wechat通道配置段：

   channels:
     wechat:
       enabled: true
       corpId: ${WECHAT_CORP_ID}
       agentId: ${WECHAT_AGENT_ID}
       token: ${WECHAT_TOKEN}
       encodingAesKey: ${WECHAT_ENCODING_AES_KEY}
       secret: ${WECHAT_SECRET}
   

• 在.env.example中添加对应环境变量

1. 安装依赖：

• pnpm add xml2js（XML解析，如果尚未安装）

验证方法：

• 配置企微自建应用参数，启动服务器
• 通过企微发送测试消息，确认CapabilityDispatcher收到source='wechat'的请求
• 确认飞书/Web通道功能不受影响

TASK-1-02：微信消息回复

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-02 |

| 优先级 | P0 |

| 依赖任务 | TASK-1-01 |

| 预估工作量 | 1天 |

实现步骤：

1. 在server/channels/wechat-channel.js中添加消息回复功能：

• 实现sendTextMessage(userId, content)方法：调用企微消息发送API
• 实现sendCardMessage(userId, cardData)方法：发送文本卡片消息
• 消息加密使用企微加解密库

1. 在CapabilityDispatcher中添加微信通道回调：

• 修改server/core/capability-dispatcher.js，在执行完成后根据source类型调用对应通道的回复方法
• 当source='wechat'时，调用wechatChannel.sendTextMessage()或wechatChannel.sendCardMessage()
• 参考现有飞书通道的回复模式（feishu-bot.js中的消息发送逻辑）

1. 消息格式适配：

• 将数字员工的执行结果转换为企微消息格式（文本/Markdown/卡片）
• 长文本自动截断（企微消息长度限制2048字符）
• 错误结果友好化处理

1. 添加通道断连处理：

• 微信API调用失败时，记录错误日志
• 实现自动重试机制（最多3次，间隔5秒）
• 触发ws-push-service告警通知

验证方法：

• 微信用户发送"查询BOM A001"，确认收到数字员工执行结果
• 执行结果较长时，确认消息格式正确且未截断关键信息
• 模拟微信API超时，确认重试机制生效

TASK-1-03：通道路由分发

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-03 |

| 优先级 | P1 |

| 依赖任务 | TASK-1-01, TASK-1-02 |

| 预估工作量 | 0.5天 |

实现步骤：

1. 确认CapabilityDispatcher已有的source路由支持：

• 读取server/core/capability-dispatcher.js，确认是否已有source字段路由逻辑
• 如果已有，确认wechat source的处理分支

1. 添加通道路由注册机制：

• 在server/core/capability-dispatcher.js中，添加通道注册表：

   const channelRegistry = {
     wechat: wechatChannel,
     feishu: feishuChannel,
     web: webChannel,
     miniapp: miniappChannel
   };
   

• 在dispatch完成后，根据source查找对应通道并发送回复

1. 添加通道健康检查：

• 在/api/health端点中，添加各通道连接状态检查
• 返回格式：{ channels: { wechat: 'connected', feishu: 'connected', web: 'active' } }

验证方法：

• 微信消息进入Dispatcher，按source='wechat'路由
• 飞书消息进入Dispatcher，功能与接入微信前完全一致
• Web消息不受影响

TASK-1-04：企微自建应用备选方案完善

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-04 |

| 优先级 | P1 |

| 依赖任务 | TASK-1-01 |

| 预估工作量 | 1天 |

实现步骤：

1. 完善企微自建应用配置流程：

• 新建docs/deploy/wechat-work-setup.md，记录企微自建应用创建步骤
• 包含：创建应用→配置回调URL→获取corpid/agentid/secret→配置.env

1. 添加企微AccessToken管理：

• 在server/channels/wechat-channel.js中，实现AccessToken获取与缓存
• Token有效期7200秒，缓存至文件（复用token-cache.js模式）
• Token过期前5分钟自动刷新

1. 添加企微消息加解密：

• 实现企微消息的AES加解密（基于encodingAesKey）
• 回调URL验证时使用token+encodingAesKey解密echostr

1. 添加消息频率限制处理：

• 企微API有消息发送频率限制，实现消息队列缓冲
• 队列使用内存级（单实例），后续可扩展为Redis

验证方法：

• 按照部署文档配置企微自建应用
• 发送消息并收到回复
• AccessToken缓存生效，避免频繁请求

TASK-1-05：小程序JWT密钥修复

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-05 |

| 优先级 | P0 |

| 依赖任务 | TASK-0-01 |

| 预估工作量 | 0.5天 |

实现步骤：

1. 确认TASK-0-01已修复miniapp-auth.js中的JWT密钥问题：

• TASK-0-01已修改server/routes/miniapp-auth.js第65、82、95行的process.env.JWT_SECRET || 'change-me-in-production'
• 本任务验证小程序登录流程在修复后正常工作

1. 修改bossagents-miniapp的登录逻辑：

• 读取bossagents-miniapp/src/pages/login/index.vue，确认登录API调用路径
• 确认登录成功后Token存储方式（localStorage/uni.setStorageSync）
• 确认Token在后续API请求中正确携带（Authorization: Bearer header）

1. 添加Token过期处理：

• 在小程序API请求拦截器中，添加401响应处理
• Token过期时自动跳转登录页

1. 验证Token缓存持久化：

• 确认TASK-0-01中的token-cache.js在小程序认证场景下正常工作
• 服务重启后，已缓存的Token仍可验证

验证方法：

• 小程序登录，Token签发使用环境变量密钥
• 服务重启后，已缓存的Token仍可验证，无需重新登录
• Token过期后，自动跳转登录页

TASK-1-06：小程序自动模式接入微信AI

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-06 |

| 优先级 | P1 |

| 依赖任务 | TASK-1-05 |

| 预估工作量 | 1天 |

实现步骤：

1. 确认微信小程序AI生态接入政策：

• 搜索微信开放平台2026年6月8日发布的小程序AI生态接入政策
• 确认是否对第三方开发者开放
• 如果未开放，标记自动模式为不可用，跳过步骤2-3

1. 小程序审核配置（如果政策开放）：

• 在小程序提交审核时，勾选"授权微信读取小程序源码"选项
• 配置小程序AI能力声明（app.json中添加相关配置）

1. 添加自动模式检测逻辑：

• 在bossagents-miniapp/src/pages/ai-chat/index.vue中，添加微信AI可用性检测
• 如果微信AI可用，优先使用微信AI能力
• 如果不可用，降级为开发模式（调用后端CapabilityDispatcher）

验证方法：

• 确认微信AI政策状态
• 如果开放：小程序提交审核后，微信AI可读取源码并提供智能服务
• 如果未开放：小程序AI功能提示"暂未开放"，提供开发模式入口

TASK-1-07：小程序对话入口

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-07 |

| 优先级 | P1 |

| 依赖任务 | TASK-1-05 |

| 预估工作量 | 1天 |

实现步骤：

1. 修改bossagents-miniapp/src/pages/ai-chat/index.vue：

• 添加文本输入框和发送按钮
• 实现与后端CapabilityDispatcher的对接
• 调用POST /api/miniapp/chat接口发送用户消息

1. 新建小程序对话API：

• 在server/routes/miniapp-auth.js中，添加POST /api/miniapp/chat路由
• 接收参数：{ message, staffId? }
• 调用CapabilityDispatcher执行，返回执行结果
• 使用collectBody(req)获取bodyStr

1. 修改bossagents-miniapp/src/pages/ai-chat/detail.vue：

• 实现对话历史展示（ChatBubble组件已有）
• 添加加载状态和错误处理
• 支持流式响应（如果后端支持SSE）

1. 前端构建验证：

• 在bossagents-miniapp目录执行构建，确认无编译错误

验证方法：

• 小程序ai-chat页面输入"帮我查BOM"，调用后端API，返回数字员工执行结果
• 对话历史正确展示
• 网络错误时显示友好提示

TASK-1-08：Memory Service核心框架 + Layer 1原子痕迹

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-08 |

| 优先级 | P0 |

| 依赖任务 | TASK-0-02 |

| 预估工作量 | 3天 |

实现步骤：

1. 新建server/services/memory-service.js：

• 定义MemoryService类，包含六层记忆的核心框架
• 构造函数接收db参数（使用db-adapter获取数据库连接）
• 定义统一接口：

   class MemoryService {
     constructor(db) { this.db = db; }
     // Layer 1: 原子痕迹
     getTraces(tenantId, filters) { ... }
     // Layer 2: 原子事实
     addFact(tenantId, fact) { ... }
     getFacts(tenantId, category) { ... }
     // Layer 3: 用户画像
     getProfile(tenantId) { ... }
     updateProfile(tenantId, updates) { ... }
     // Layer 4-6: Phase 2实现
   }
   module.exports = MemoryService; // 直接导出类
   

1. 创建记忆相关数据库表：

• 在server/services/db-schema-init.js中添加：

   -- 原子事实表
   CREATE TABLE IF NOT EXISTS memory_facts (
     factId TEXT PRIMARY KEY,
     tenantId TEXT NOT NULL,
     category TEXT NOT NULL,
     value TEXT NOT NULL,
     confidence REAL DEFAULT 0.5,
     source TEXT NOT NULL DEFAULT 'interaction',
     createdAt TEXT NOT NULL,
     supersededBy TEXT DEFAULT NULL
   );
   CREATE INDEX IF NOT EXISTS idx_memory_facts_tenant ON memory_facts(tenantId);
   CREATE INDEX IF NOT EXISTS idx_memory_facts_category ON memory_facts(tenantId, category);

   -- 用户画像表
   CREATE TABLE IF NOT EXISTS memory_profiles (
     tenantId TEXT PRIMARY KEY,
     role TEXT DEFAULT 'decision_maker',
     industry TEXT DEFAULT '',
     frequentObjectTypes TEXT DEFAULT '[]',
     approvalPreference TEXT DEFAULT 'moderate',
     preferredSuppliers TEXT DEFAULT '[]',
     lastUpdated TEXT NOT NULL
   );

   -- 演化链表
   CREATE TABLE IF NOT EXISTS memory_evolution_chain (
     entryId TEXT PRIMARY KEY,
     type TEXT NOT NULL,
     refId TEXT NOT NULL,
     action TEXT NOT NULL,
     previousValue TEXT DEFAULT NULL,
     newValue TEXT DEFAULT NULL,
     supersedes TEXT DEFAULT NULL,
     timestamp TEXT NOT NULL
   );
   

1. 实现Layer 1原子痕迹查询：

• getTraces(tenantId, filters)方法：查询audit_logs表，按tenantId过滤
• 支持按时间范围、操作类型筛选
• 返回格式：[{ auditId, traceId, source, capability, userId, startedAt, completedAt, success, duration }]

1. 添加GET /api/memory/traces路由：

• 在server.js中注册路由
• 支持查询参数：tenantId、staffId、from、to
• 需要通过tenant-middleware获取tenantId

1. 创建记忆数据文件目录：

• 创建server/data/memory/目录
• 创建server/data/memory/facts/、server/data/memory/profiles/子目录
• 作为JSON文件存储的备用路径（DB优先）

验证方法：

• 数字员工执行一次任务后，调用GET /api/memory/traces?tenantId=xxx
• 返回该租户的原子痕迹列表，含时间戳、操作类型、参数摘要
• 数据库中memory_facts和memory_profiles表已创建

TASK-1-09：Memory Layer 2原子事实提取

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-09 |

| 优先级 | P0 |

| 依赖任务 | TASK-1-08 |

| 预估工作量 | 3天 |

实现步骤：

1. 在server/services/memory-service.js中实现事实提取：

• 添加extractFacts(interaction)方法：从交互中提取关键事实
• 使用SmartLLMRouter调用LLM进行事实提取（轻量级prompt）
• 提取类别：supplier_preference（供应商偏好）、operation_habit（操作习惯）、approval_preference（审批偏好）
• prompt模板：

   从以下用户交互中提取关键事实，返回JSON数组：
   交互内容：{interaction}
   提取类别：供应商偏好、操作习惯、审批偏好、其他
   返回格式：[{"category":"...","value":"...","confidence":0.0-1.0}]
   如果无法提取事实，返回空数组[]
   

1. 实现addFact(tenantId, fact)方法：

• 生成factId（UUID格式）
• 写入memory_facts表
• 如果同类别已有相似事实，更新confidence（累加模式）
• 记录演化链（如果旧事实被替代）

1. 实现getFacts(tenantId, category)方法：

• 查询memory_facts表，按tenantId和category过滤
• 排除已被supersededBy标记的旧事实
• 按confidence降序排列

1. 添加事实提取的降级处理：

• LLM调用失败时，跳过本次事实提取
• 记录警告日志，不影响主流程
• 事实提取超时设置5秒，超时自动跳过

验证方法：

• 老板说"我偏好供应商A"→ facts表中新增{category: "supplier_preference", value: "A", confidence: 0.9}
• 老板三次选择同一操作模式→ 该操作模式的confidence提升
• LLM调用失败时，业务操作正常完成，日志记录事实提取跳过

TASK-1-10：Memory Layer 3用户画像构建

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-10 |

| 优先级 | P0 |

| 依赖任务 | TASK-1-08, TASK-1-09 |

| 预估工作量 | 2天 |

实现步骤：

1. 在server/services/memory-service.js中实现画像构建：

• getProfile(tenantId)：查询memory_profiles表，不存在则创建基础画像
• updateProfile(tenantId, updates)：更新画像字段
• buildProfileFromFacts(tenantId)：从facts表聚合画像数据

1. 实现基础画像自动创建：

• 老板首次使用系统时，自动创建基础画像：

   {
     tenantId: tenantId,
     role: 'decision_maker',
     industry: '',
     frequentObjectTypes: [],
     approvalPreference: 'moderate',
     preferredSuppliers: [],
     lastUpdated: new Date().toISOString()
   }
   

1. 实现画像自动更新逻辑：

• 从facts表中聚合供应商偏好→preferredSuppliers
• 从审计日志中统计常用对象类型→frequentObjectTypes
• 从审批行为中推断审批偏好→approvalPreference
• 更新触发条件：新增3条以上同类别事实时触发画像更新

1. 与租户中间件集成：

• 在server/middleware/tenant-middleware.js中，添加Memory Service的tenantId传递
• 确保记忆数据按租户隔离
• 在MemoryService的方法中，所有查询都带tenantId条件

1. 添加GET /api/memory/profile路由：

• 在server.js中注册路由
• 返回当前租户的用户画像

验证方法：

• 老板首次使用系统→ 自动创建基础画像
• 老板完成3次BOM查询→ 画像中frequentObjectTypes更新为["BOM"]
• 租户A的操作不影响租户B的画像

TASK-1-11：Memory System 1实时写入集成

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-11 |

| 优先级 | P0 |

| 依赖任务 | TASK-1-09, TASK-1-10 |

| 预估工作量 | 2天 |

实现步骤：

1. 修改server/core/capability-dispatcher.js：

• 在execute()方法的finally块中，添加事实提取调用
• 参考现有自进化学习器的finally块模式
• 添加逻辑：

   // 在 execute() 的 finally 块中
   try {
     const MemoryService = require('../services/memory-service');
     const memoryService = new MemoryService(db);
     const facts = await memoryService.extractFacts({
       source, capability, userInput, result, tenantId
     });
     if (facts.length > 0) {
       for (const fact of facts) {
         await memoryService.addFact(tenantId, fact);
       }
       await memoryService.buildProfileFromFacts(tenantId);
     }
   } catch (e) {
     console.warn('[Memory] 事实提取失败:', e.message);
   }
   

1. 确保finally块不影响主流程：

• 事实提取失败时，仅记录警告日志
• 不抛出异常，不影响execute()的返回结果
• 添加超时控制（5秒超时自动跳过）

1. 添加traceId传递：

• 确保CapabilityDispatcher的traceId传递至MemoryService
• 用于关联原子痕迹和原子事实

验证方法：

• 任意能力执行完成→ finally块触发事实提取，facts表实时更新
• 事实提取失败时，业务操作正常完成
• 事实提取耗时<500ms（DFX约束4.1.3）

TASK-1-12：Memory租户隔离验证

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-12 |

| 优先级 | P1 |

| 依赖任务 | TASK-1-10, TASK-1-11 |

| 预估工作量 | 0.5天 |

实现步骤：

1. 验证MemoryService所有方法的tenantId过滤：

• 逐个检查getTraces、addFact、getFacts、getProfile、updateProfile方法
• 确认所有SQL查询都包含WHERE tenantId = ?条件
• 确认所有写入操作都包含tenantId字段

1. 添加租户隔离单元测试：

• 新建server/__tests__/memory-service.test.js
• 测试场景：租户A写入事实后，租户B查询不到
• 测试场景：租户A更新画像后，租户B画像不受影响

1. 添加API层租户校验：

• 在/api/memory/*路由中，从tenant-middleware获取tenantId
• 禁止跨租户查询（请求中的tenantId必须与token中的匹配）

验证方法：

• 租户A的老板操作→ 仅更新租户A的画像和事实
• 租户B查询→ 无法获取租户A的记忆数据
• API层拒绝跨租户请求

TASK-1-13：环境检查与自动依赖安装

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-13 |

| 优先级 | P1 |

| 依赖任务 | 无 |

| 预估工作量 | 1天 |

实现步骤：

1. 修改start.bat：

• 在现有36行基础上增强，添加环境检查逻辑
• Node.js版本检查：

   for /f "tokens=1 delims=." %%v in ('node -v 2^>nul') do set NODE_VER=%%v
   set NODE_VER=%NODE_VER:v=%
   if %NODE_VER% LSS 18 (
     echo [ERROR] Node.js 18+ required, current: %NODE_VER%
     pause
     exit /b 1
   )
   

• pnpm检查：

   where pnpm >nul 2>nul
   if %ERRORLEVEL% NEQ 0 (
     echo [ERROR] pnpm not found. Install: npm install -g pnpm
     pause
     exit /b 1
   )
   

• .env文件检查：

   if not exist .env (
     if exist .env.example (
       copy .env.example .env
       echo [INFO] .env created from .env.example, please configure it
     ) else (
       echo [WARN] .env file not found
     )
   )
   

• 自动依赖安装：

   if not exist node_modules (
     echo [INFO] Installing dependencies...
     pnpm install
     if %ERRORLEVEL% NEQ 0 (
       echo [ERROR] pnpm install failed. Try: pnpm config set registry https://registry.npmmirror.com
       pause
       exit /b 1
     )
   )
   

1. 添加自动DB初始化：

   if not exist server\data\sciot_import.db (
     echo [INFO] Initializing database...
     node -e "require('./server/services/db-schema-init').init()"
   )
   

1. 添加端口占用检查：

   netstat -ano | findstr :3006 >nul
   if %ERRORLEVEL% EQU 0 (
     echo [WARN] Port 3006 is in use. Kill the process or change PORT in .env
     choice /C YN /M "Kill the process on port 3006?"
     if %ERRORLEVEL% EQU 1 (
       for /f "tokens=5" %%p in ('netstat -ano ^| findstr :3006 ^| findstr LISTENING') do (
         taskkill /PID %%p /F
       )
     )
   )
   

验证方法：

• Node.js版本低于18→ 脚本输出"Node.js 18+ required"并退出
• pnpm未安装→ 脚本输出"pnpm not found"并提供安装指引
• .env不存在→ 自动从.env.example复制
• node_modules不存在→ 自动执行pnpm install
• SQLite文件不存在→ 自动创建数据库

TASK-1-14：自动DB初始化

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-14 |

| 优先级 | P1 |

| 依赖任务 | TASK-1-13 |

| 预估工作量 | 0.5天 |

实现步骤：

1. 增强server/services/db-schema-init.js：

• 确认现有初始化逻辑覆盖所有必要表
• 添加TASK-1-08中新增的memory_facts、memory_profiles、memory_evolution_chain表
• 添加幂等性检查（CREATE TABLE IF NOT EXISTS）
• 添加初始化日志输出

1. 添加初始化入口函数：

• 确保db-schema-init.js导出init()函数
• init()函数执行所有表创建和初始数据插入
• 支持从start.bat和server.js启动时自动调用

1. 在server.js启动时调用DB初始化：

• 在server.listen之前，添加：

   try {
     const dbInit = require('./services/db-schema-init');
     if (dbInit.init) dbInit.init();
     console.log('[DB] Schema initialized');
   } catch (e) {
     console.warn('[DB] Schema init skipped:', e.message);
   }
   

验证方法：

• 首次启动，SQLite文件不存在→ 自动创建数据库并初始化表结构
• 重复启动→ 不报错，表已存在则跳过
• 新增的memory_*表已创建

TASK-1-15：Docker单命令部署

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-1-15 |

| 优先级 | P2 |

| 依赖任务 | TASK-1-13, TASK-1-14 |

| 预估工作量 | 3天 |

实现步骤：

1. 新建Dockerfile（单容器方案）：

   FROM node:22-alpine
   RUN npm install -g pnpm
   WORKDIR /app
   COPY package.json pnpm-lock.yaml ./
   RUN pnpm install --prod
   COPY . .
   RUN npm run build
   EXPOSE 3006
   HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
     CMD wget -q --spider http://localhost:3006/api/health || exit 1
   CMD ["node", "server.js"]
   

1. 添加健康检查端点/api/health：

• 在server.js中添加GET /api/health路由
• 返回各组件运行状态：

   {
     status: 'ok',
     uptime: process.uptime(),
     components: {
       database: 'connected',
       llmRouter: 'available',
       channels: { wechat: 'connected', feishu: 'connected' }
     }
   }
   

1. 添加数据卷持久化：

• 在Dockerfile中声明VOLUME /app/server/data
• 添加docker run示例：

   docker run -d -p 3006:3006 \
     -v bossagents-data:/app/server/data \
     -e JWT_SECRET=your-secret \
     -e DEEPSEEK_API_KEY=your-key \
     bossagents:latest
   

1. 优化.dockerignore：

• 添加node_modules、.git、docs等排除项

验证方法：

• 执行docker run命令→ 单容器内包含完整服务栈
• 健康检查通过后可访问
• 数据卷持久化：容器重启后数据保留

Phase 2 — 深度增强

TASK-2-01：Memory Layer 4会话摘要

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-01 |

| 优先级 | P0 |

| 依赖任务 | TASK-1-08 |

| 预估工作量 | 2天 |

实现步骤：

1. 创建会话摘要数据库表：

• 在server/services/db-schema-init.js中添加：

   CREATE TABLE IF NOT EXISTS staff_session_summaries (
     summaryId TEXT PRIMARY KEY,
     tenantId TEXT NOT NULL,
     sessionId TEXT NOT NULL,
     topic TEXT NOT NULL,
     keyDecisions TEXT DEFAULT '[]',
     outcome TEXT DEFAULT '',
     createdAt TEXT NOT NULL
   );
   CREATE INDEX IF NOT EXISTS idx_session_summaries_tenant ON staff_session_summaries(tenantId);
   CREATE INDEX IF NOT EXISTS idx_session_summaries_topic ON staff_session_summaries(tenantId, topic);
   

1. 增强server/digital-staff/conversation-manager.js：

• 添加generateSummary(sessionId)方法：使用LLM生成会话摘要
• 按"业务主题"（BOM/采购/变更/供应商/其他）分类
• 提取关键决策和结果
• prompt模板：

   分析以下会话，生成结构化摘要：
   会话内容：{conversation}
   返回格式：{"topic":"BOM|采购|变更|供应商|其他","keyDecisions":["..."],"outcome":"..."}
   

1. 在MemoryService中添加Layer 4接口：

• addSummary(tenantId, sessionId, summary)：写入staff_session_summaries表
• getSummaries(tenantId, filters)：查询摘要，支持按topic和时间范围筛选

1. 添加会话摘要生成触发：

• 在ConversationManager的会话结束时（超时或用户主动结束），触发摘要生成
• 摘要生成异步执行，不阻塞主流程

1. 添加GET /api/memory/summaries路由：

• 支持按tenantId、topic、时间范围查询

验证方法：

• 完成一次BOM查询对话→ session_summaries表新增一条BOM主题摘要
• 查询某租户的历史会话摘要→ 按业务主题分类展示
• 摘要生成失败时不影响对话主流程

TASK-2-02：Memory Layer 5心智模型

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-02 |

| 优先级 | P1 |

| 依赖任务 | TASK-2-01 |

| 预估工作量 | 3天 |

实现步骤：

1. 创建心智模型数据库表：

• 在server/services/db-schema-init.js中添加：

   CREATE TABLE IF NOT EXISTS memory_mental_models (
     tenantId TEXT PRIMARY KEY,
     riskPreference TEXT DEFAULT 'moderate',
     costSensitivity TEXT DEFAULT 'medium',
     innovationWillingness TEXT DEFAULT 'medium',
     decisionPatterns TEXT DEFAULT '[]',
     lastAnalyzedAt TEXT,
     analysisVersion INTEGER DEFAULT 0
   );
   

1. 在MemoryService中实现心智模型构建：

• buildMentalModel(tenantId)：分析审计日志和事实，构建心智模型
• 使用SmartLLMRouter调用LLM进行深度分析
• 分析维度：风险偏好、成本敏感度、创新意愿、决策模式
• prompt模板：

   基于以下历史数据，分析该用户的决策模型：
   审计日志：{auditLogs}
   事实记录：{facts}
   返回格式：{"riskPreference":"conservative|moderate|aggressive","costSensitivity":"low|medium|high","innovationWillingness":"low|medium|high","decisionPatterns":["..."]}
   

1. 实现心智模型增量更新：

• 老板连续3次选择低成本方案→ costSensitivity权重提升
• 老板连续选择创新方案→ innovationWillingness提升
• 更新时递增analysisVersion

1. 添加心智模型查询接口：

• getMentalModel(tenantId)：查询当前心智模型
• GET /api/memory/mental-model：API路由

验证方法：

• System 2分析30天审计日志后→ mental-models中生成完整心智模型
• 老板连续3次选择低成本方案→ costSensitivity提升
• 查询心智模型→ 返回当前版本和分析时间

TASK-2-03：Memory Layer 6前瞻意图

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-03 |

| 优先级 | P1 |

| 依赖任务 | TASK-2-02 |

| 预估工作量 | 2天 |

实现步骤：

1. 创建前瞻意图数据库表：

• 在server/services/db-schema-init.js中添加：

   CREATE TABLE IF NOT EXISTS memory_intentions (
     intentionId TEXT PRIMARY KEY,
     tenantId TEXT NOT NULL,
     predicted TEXT NOT NULL,
     confidence REAL DEFAULT 0.5,
     basedOn TEXT DEFAULT '',
     triggerCondition TEXT DEFAULT '',
     createdAt TEXT NOT NULL,
     updatedAt TEXT NOT NULL
   );
   CREATE INDEX IF NOT EXISTS idx_intentions_tenant ON memory_intentions(tenantId);
   

1. 在MemoryService中实现前瞻意图预测：

• predictIntentions(tenantId)：基于历史模式预测下一步需求
• 分析模式：BOM审批后90%触发采购→ 预测"采购下单"
• 使用LLM辅助预测（可选，简单模式用规则匹配）

1. 添加心跳任务定期更新：

• 复用LiteScheduler的cron调度机制
• 每15分钟执行一次前瞻意图更新
• 更新confidence和basedOn字段

1. 添加前瞻意图查询接口：

• getIntentions(tenantId)：查询当前前瞻意图
• GET /api/memory/intentions：API路由

验证方法：

• 老板刚完成BOM审批→ intentions中新增"采购下单"预测
• 心跳任务每15分钟执行→ 更新前瞻意图的confidence
• 查询前瞻意图→ 返回预测列表

TASK-2-04：Memory System 2异步分析

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-04 |

| 优先级 | P1 |

| 依赖任务 | TASK-2-02, TASK-2-03 |

| 预估工作量 | 2天 |

实现步骤：

1. 新建server/services/memory-system2.js：

• 实现System 2异步分析引擎
• 分析流程：读取审计日志→提取模式→更新心智模型→更新前瞻意图
• 超时控制：1小时超时自动中断

1. 注册LiteScheduler cron job：

• 在server/boss-scheduler/lite-scheduler.js中，添加System 2的cron调度
• 每日凌晨2点执行：

   scheduler.registerCron('0 2 * * *', 'memory-system2', async () => {
     const MemorySystem2 = require('../services/memory-system2');
     const system2 = new MemorySystem2(db);
     await system2.runAnalysis();
   });
   

1. 实现增量分析：

• 仅分析前一天新增的审计日志（基于createdAt字段）
• 分析结果增量更新心智模型和前瞻意图
• System 2分析期间不影响System 1的实时写入

1. 添加分析状态监控：

• 记录每次分析的开始时间、结束时间、处理记录数
• 分析超时时，保留已处理的部分结果
• 在/api/health中添加System 2状态

验证方法：

• cron job每日凌晨2点执行→ 分析前一天的审计日志
• System 2分析期间→ System 1实时写入不受影响
• 分析超时→ 保留部分结果，次日可补全

TASK-2-05：演化链supersedes指针

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-05 |

| 优先级 | P1 |

| 依赖任务 | TASK-2-04 |

| 预估工作量 | 2天 |

实现步骤：

1. 在MemoryService中实现演化链管理：

• recordEvolution(type, refId, action, previousValue, newValue, supersedes)：记录演化事件
• 写入memory_evolution_chain表
• 当事实被替代时，旧事实的supersededBy字段指向新事实

1. 实现演化历史查询：

• getEvolutionHistory(refId)：查询某事实/规则/画像的完整演化历史
• 通过supersedes指针追溯，从最早到最新
• 返回格式：[{entryId, action, previousValue, newValue, timestamp}]

1. 实现演化链断裂修复：

• 当supersedes指针指向的记录被删除时，标记为orphan
• 从当前有效事实重新建立链路
• 定期检查演化链完整性（可复用System 2 cron job）

1. 复用RuleEvolution的版本管理思路：

• 参考server/core/rule-evolution.js（414行）的版本管理模式
• 演化链的supersedes指针与RuleEvolution的版本管理保持一致

1. 添加演化链查询API：

• GET /api/memory/evolution/{refId}：查询演化历史

验证方法：

• 老板偏好从"供应商A"变为"供应商B"→ 演化链记录完整
• 查询某事实的演化历史→ 返回完整supersedes链路
• 演化链断裂→ 自动修复，标记orphan

TASK-2-06：任务拆解TaskDecomposer

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-06 |

| 优先级 | P0 |

| 依赖任务 | TASK-1-11 |

| 预估工作量 | 3天 |

实现步骤：

1. 新建server/core/task-decomposer.js：

• 实现TaskDecomposer类
• decompose(complexTask)：使用SmartLLMRouter调用LLM拆解复杂任务
• prompt模板：

   将以下复杂任务拆解为可独立执行的子任务：
   任务：{complexTask}
   返回格式：[{"subTask":"...","staffType":"...","dependencies":[]}]
   如果子任务之间无依赖关系，标记为可并行执行。
   

1. 实现依赖关系分析：

• 分析子任务之间的依赖关系
• 生成DAG（有向无环图）
• 标记可并行执行的子任务组

1. 实现拆解降级：

• LLM拆解失败时，降级为串行执行
• 请求老板确认拆解方式
• 通过微信/飞书通道发送确认消息

1. 与CapabilityDispatcher集成：

• 在server/core/capability-dispatcher.js中，检测复杂任务并调用TaskDecomposer
• 复杂任务判断标准：包含"比较"、"分析"、"汇总"等关键词，或用户明确要求多步骤

1. 添加任务拆解日志：

• 记录拆解过程和结果
• 使用audit-log记录拆解事件

验证方法：

• 输入"比较供应商A/B/C报价"→ 拆解为3个子任务
• 子任务之间无依赖关系→ 标记为可并行执行
• LLM拆解失败→ 降级为串行执行，请求确认

TASK-2-07：并行调度runParallel

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-07 |

| 优先级 | P0 |

| 依赖任务 | TASK-2-06 |

| 预估工作量 | 2天 |

实现步骤：

1. 修改server/boss-scheduler/lite-scheduler.js：

• 添加runParallel(staffIds, subTasks)方法
• 使用Promise.allSettled并行执行多个子任务
• 每个子任务独立调度，互不阻塞

   async runParallel(staffIds, subTasks) {
     const promises = subTasks.map((task, i) =>
       this.runOnce(staffIds[i], task).catch(e => ({ error: e.message }))
     );
     const results = await Promise.allSettled(promises);
     return results.map((r, i) => ({
       subTask: subTasks[i],
       status: r.status,
       result: r.status === 'fulfilled' ? r.value : r.reason
     }));
   }
   

1. 实现并行任务超时控制：

• 每个子任务设置独立超时（默认60秒）
• 超时的子任务标记为failed，不影响其他子任务

1. 保持协作链兼容：

• 现有onComplete协作链继续使用串行模式
• runParallel不使用onComplete触发
• 并行任务完成后统一回调ResultAggregator

1. 添加并行调度日志：

• 记录并行调度的开始时间、子任务数、各子任务结果
• 使用audit-log记录

验证方法：

• 3个子任务并行调度→ 3个员工同时开始执行，总耗时≈单次执行耗时
• 任一子任务失败→ 其他子任务继续执行
• 现有协作链（onComplete触发）功能不受影响

TASK-2-08：结果汇总ResultAggregator

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-08 |

| 优先级 | P0 |

| 依赖任务 | TASK-2-07 |

| 预估工作量 | 2天 |

实现步骤：

1. 新建server/core/result-aggregator.js：

• 实现ResultAggregator类
• aggregate(subTaskResults)：使用SmartLLMRouter调用LLM汇总多个子任务结果
• prompt模板：

   汇总以下多个子任务的执行结果，生成综合建议：
   子任务结果：{subTaskResults}
   如果结果存在矛盾，标注矛盾点。
   返回格式：{"summary":"...","recommendation":"...","conflicts":["..."]}
   

1. 实现冲突检测与解决：

• 检测子任务结果之间的矛盾
• 矛盾结果由LLM判断或请求老板确认
• 通过微信/飞书通道发送确认消息

1. 实现部分失败汇总：

• 部分子任务失败时，基于成功结果生成部分建议
• 标注失败项和影响范围

1. 与CapabilityDispatcher集成：

• 在并行任务完成后，调用ResultAggregator汇总结果
• 汇总结果通过通道路由回传给用户

验证方法：

• 3家供应商报价结果汇总→ 生成"推荐供应商B，综合评分最高"的综合建议
• 子任务结果存在矛盾→ 标注矛盾点，由LLM判断
• 部分子任务失败→ 基于成功结果生成部分建议

TASK-2-09：互斥锁超时释放

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-09 |

| 优先级 | P0 |

| 依赖任务 | 无 |

| 预估工作量 | 1天 |

实现步骤：

1. 修改server/boss-scheduler/lite-scheduler.js中的_withStaffMutex方法：

• 添加超时释放机制（30秒）
• 使用setTimeout实现超时自动释放：

   async _withStaffMutex(staffId, fn) {
     while (this._staffMutex.has(staffId)) {
       await new Promise(r => setTimeout(r, 200));
     }
     this._staffMutex.add(staffId);

     // 超时释放
     const timeoutId = setTimeout(() => {
       if (this._staffMutex.has(staffId)) {
         console.warn(`[Scheduler] Mutex timeout for ${staffId}, auto-releasing`);
         this._staffMutex.delete(staffId);
       }
     }, 30000);

     try {
       return await fn();
     } finally {
       clearTimeout(timeoutId);
       this._staffMutex.delete(staffId);
     }
   }
   

1. 添加超时日志：

• 互斥锁超时释放时，记录警告日志
• 包含staffId、持有时间、当前任务信息

1. 添加可配置超时时间：

• 在config.yaml中添加scheduler.mutexTimeout配置项
• 默认值30000ms（30秒）

验证方法：

• 员工A任务卡死超过30秒→ 互斥锁自动释放
• 员工A可被重新调度
• 正常执行的任务不受影响（finally块正常释放锁）

TASK-2-10：死锁检测

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-10 |

| 优先级 | P1 |

| 依赖任务 | TASK-2-09 |

| 预估工作量 | 1天 |

实现步骤：

1. 在server/boss-scheduler/lite-scheduler.js中添加死锁检测：

• 维护等待图（wait-for graph）：记录"员工A等待员工B"的关系
• 定期检测循环等待（每5秒检测一次）
• 检测到死锁时，自动释放其中一个锁（选择持有时间较短的）

1. 实现等待图管理：

   _waitGraph = new Map(); // staffId -> waitingForStaffId

   _checkDeadlock() {
     const visited = new Set();
     for (const [staffId] of this._waitGraph) {
       const path = [];
       let current = staffId;
       while (current && !visited.has(current)) {
         visited.add(current);
         path.push(current);
         current = this._waitGraph.get(current);
         if (current === staffId && path.length > 1) {
           // Deadlock detected
           return path;
         }
       }
     }
     return null;
   }
   

1. 添加死锁恢复逻辑：

• 检测到死锁后，选择循环中持有锁时间最短的员工释放
• 记录死锁事件日志
• 通知相关用户任务被中断

验证方法：

• 员工A等B、B等A的循环等待→ 系统检测到死锁，自动释放其中一个锁
• 死锁检测不影响正常执行的并行任务
• 死锁事件记录在审计日志中

TASK-2-11：混元Provider接入

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-11 |

| 优先级 | P1 |

| 依赖任务 | 无 |

| 预估工作量 | 2天 |

实现步骤：

1. 修改server/digital-staff/smart-llm-router.js：

• 在providers配置中新增hunyuan provider
• 插入降级链路：DeepSeek之后、规则引擎之前（priority: 4.5）

   hunyuan: {
     baseURL: 'https://api.hunyuan.cloud.tencent.com/v1',
     apiKey: process.env.HUNYUAN_API_KEY,
     models: {
       fast: 'hunyuan-2.0-instruct-20251109',
       think: 'hunyuan-2.0-thinking-20251109',
     },
     priority: 4.5,
     enabled: !!process.env.HUNYUAN_API_KEY
   }
   

1. 实现混元API调用适配：

• 混元API兼容OpenAI格式，可直接复用现有fetch调用逻辑
• 添加HUNYUAN_API_KEY环境变量检查
• 未配置时自动跳过混元provider

1. 添加混元provider到降级链路：

• 在SmartLLMRouter的route()方法中，按priority排序时混元自动插入正确位置
• DeepSeek不可用时→ 自动降级至混元
• 混元不可用时→ 继续降级至规则引擎

1. 添加混元provider统计监控：

• 在SmartLLMRouter的统计模块中，添加混元provider的调用次数、成功率、平均响应时间

1. 更新.env.example：

• 添加HUNYUAN_API_KEY=your-hunyuan-api-key

验证方法：

• 配置HUNYUAN_API_KEY后→ 混元provider可用，支持fast和think两种模型
• DeepSeek不可用→ 自动降级至混元
• 混元不可用→ 继续降级至规则引擎
• 混元provider禁用→ 降级链路与接入前完全一致

TASK-2-12：语义级分类

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-12 |

| 优先级 | P1 |

| 依赖任务 | TASK-2-11 |

| 预估工作量 | 2天 |

实现步骤：

1. 在server/digital-staff/smart-llm-router.js中添加语义分类：

• 新增semanticClassify(userInput)方法
• 使用轻量级嵌入模型（或LLM分类调用）进行语义级分类
• 分类目标：identify/create/repair/optimize/compare/generate六大能力
• 置信度低于0.6时降级为关键词匹配

1. 实现嵌入向量分类（可选方案）：

• 使用SmartLLMRouter的fast模型进行分类
• prompt模板：

   将以下用户输入分类为六大能力之一：
   identify（识别）、create（创建）、repair（修复）、optimize（优化）、compare（比较）、generate（生成）
   用户输入：{userInput}
   返回格式：{"capability":"...","confidence":0.0-1.0}
   

1. 实现分类降级：

• 语义分类服务异常时→ 降级为关键词匹配
• 关键词匹配逻辑保持现有实现不变

1. 添加分类结果缓存：

• 相同输入的分类结果缓存5分钟
• 减少LLM调用次数

验证方法：

• 输入"帮我看看这个BOM有没有问题"→ 语义分类为"identify"能力
• 语义分类置信度低于0.6→ 降级为关键词匹配
• 语义分类服务异常→ 降级为关键词匹配，功能不受影响

TASK-2-13：动态路由

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-13 |

| 优先级 | P2 |

| 依赖任务 | TASK-2-11, TASK-2-12 |

| 预估工作量 | 1.5天 |

实现步骤：

1. 在server/digital-staff/smart-llm-router.js中添加动态路由：

• 新增dynamicRoute(capability, providers)方法
• 基于历史准确率调整模型选择策略
• 维护provider-capability准确率矩阵：

   _accuracyMatrix = {}; // { 'hunyuan': { 'identify': 0.92, 'create': 0.85 }, ... }
   

1. 实现准确率统计：

• 在SmartLLMRouter的响应处理中，记录每次调用的成功/失败
• 按provider和capability维度统计准确率
• 统计数据持久化至文件（server/data/router-stats.json）

1. 实现动态优先级调整：

• 某模型在特定能力上准确率持续高于其他模型→ 该能力优先路由至该模型
• 某模型连续5次超时→ 自动降低该模型优先级
• 优先级调整有冷却期（5分钟内不重复调整）

验证方法：

• 混元模型在BOM查询任务上准确率持续高于DeepSeek→ BOM查询任务优先路由至混元
• 某模型连续5次超时→ 自动降低该模型优先级
• 动态路由不影响降级链路的完整性

TASK-2-14：A/B测试支持

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-14 |

| 优先级 | P2 |

| 依赖任务 | TASK-2-13 |

| 预估工作量 | 1天 |

实现步骤：

1. 在server/digital-staff/smart-llm-router.js中添加A/B测试模式：

• 新增abTestMode配置项（config.yaml或环境变量）
• 开启A/B测试时，同一请求同时发送至两个模型
• 记录对比结果（响应时间、质量评分、token消耗）

1. 实现A/B测试结果记录：

• 新建server/data/ab-test-results/目录
• 每次A/B测试结果写入JSON文件
• 格式：{ requestId, modelA, modelB, resultA, resultB, timestamp }

1. 添加A/B测试统计接口：

• GET /api/llm-router/ab-stats：返回A/B测试统计结果
• 包含：各模型对比胜率、平均响应时间、质量评分

验证方法：

• 开启A/B测试模式→ 同一请求同时发送至两个模型
• A/B测试结果可查询
• A/B测试不影响生产环境的正常响应（使用后台异步对比）

TASK-2-15：小程序AI对话深度集成

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-15 |

| 优先级 | P1 |

| 依赖任务 | TASK-1-07 |

| 预估工作量 | 3天 |

实现步骤：

1. 修改bossagents-miniapp/src/pages/ai-chat/detail.vue：

• 添加语音输入按钮，调用微信语音识别API
• 使用uni.startSpeechRecognition()或微信小程序wx.startRecord()
• 语音识别结果转为文本发送至后端

1. 添加语音输入组件：

• 修改bossagents-miniapp/src/components/VoiceInput.vue（已存在）
• 实现语音录制→识别→文本转换的完整流程
• 添加录音状态UI反馈

1. 实现结构化结果展示：

• CapabilityDispatcher返回结构化结果时（如ECR创建结果），使用卡片式展示
• 修改ChatBubble组件，支持不同消息类型（文本/卡片/操作按钮）

1. 添加微信AI SDK集成（如果可用）：

• 在bossagents-miniapp中集成微信小程序AI SDK
• 支持AI辅助输入（智能补全、意图识别）
• SDK不可用时降级为纯文本模式

验证方法：

• 小程序ai-chat页面点击语音按钮→ 调用微信语音识别，转为文本发送
• 输入"帮我创建一个ECR"→ 返回结构化ECR创建结果
• 微信AI SDK不可用→ 降级为纯文本对话模式

TASK-2-16：执行进度实时推送

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-16 |

| 优先级 | P1 |

| 依赖任务 | TASK-1-07, TASK-2-15 |

| 预估工作量 | 2天 |

实现步骤：

1. 复用server/services/ws-push-service.js：

• 确认现有WebSocket推送服务的接口和消息格式
• 添加数字员工执行进度事件类型：

   { type: 'staff_progress', staffId, progress: 'querying_bom', message: '正在查询BOM...' }
   { type: 'staff_complete', staffId, result: {...} }
   

1. 在CapabilityDispatcher中添加进度推送：

• 在execute()方法的关键节点，通过ws-push-service推送进度
• 推送节点：开始执行→调用LLM→获取结果→格式化→完成

1. 在小程序中接收WebSocket消息：

• 修改bossagents-miniapp，添加WebSocket连接（复用useWebSocket.js模式）
• 在ai-chat页面实时展示执行进度
• 添加连接状态指示器

1. 添加WebSocket认证：

• 使用JWT Token进行WebSocket连接认证
• 确保只有认证用户可接收进度推送

验证方法：

• 数字员工开始执行任务→ 小程序实时显示"正在查询BOM..."进度
• 任务执行完成→ 小程序实时显示执行结果
• WebSocket断开→ 自动重连，不丢失进度信息

TASK-2-17：Dashboard画像数据对接

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-2-17 |

| 优先级 | P2 |

| 依赖任务 | TASK-1-10, TASK-2-02 |

| 预估工作量 | 1天 |

实现步骤：

1. 修改bossagents-miniapp/src/pages/index/index.vue（Dashboard页面）：

• 添加从Memory Service获取用户画像的API调用
• 调用GET /api/memory/profile获取画像数据
• 展示老板偏好摘要（常用操作、偏好供应商、审批偏好）

1. 修改bossagents-miniapp/src/pages/profile/index.vue：

• 添加用户画像详情展示
• 展示心智模型摘要（风险偏好、成本敏感度）

1. 添加画像数据缓存：

• 使用uni.setStorageSync缓存画像数据
• 缓存有效期5分钟，避免频繁请求

1. 前端构建验证：

• 在bossagents-miniapp目录执行构建，确认无编译错误

验证方法：

• Dashboard页面加载→ 展示从Memory Service获取的用户画像摘要
• 画像数据更新后→ 下次加载展示最新数据
• 画像服务不可用→ Dashboard显示默认数据，不报错

Phase 3 — 生态扩展

TASK-3-01：OpenClaw Skill封装发布

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-01 |

| 优先级 | P2 |

| 依赖任务 | TASK-0-06 |

| 预估工作量 | 2天 |

实现步骤：

1. 定义Skill接口规范：

• 新建server/skills/目录
• 为BossAgents六大能力定义Skill接口：

   // server/skills/identify-skill.js
   module.exports = {
     name: 'bossagents-identify',
     description: '识别工业对象的属性和关系',
     inputSchema: { type: 'object', properties: { itemType: { type: 'string' }, query: { type: 'string' } } },
     outputSchema: { type: 'object', properties: { result: { type: 'object' }, confidence: { type: 'number' } } },
     execute: async (input) => { /* 调用CapabilityRuntime */ }
   };
   

1. 封装六大能力为Skill：

• identify-skill.js、create-skill.js、repair-skill.js、optimize-skill.js、compare-skill.js、generate-skill.js
• 每个Skill内部调用CapabilityRuntime对应方法

1. 添加Skill注册与发现机制：

• 新建server/skills/skill-registry.js
• 实现Skill注册、发现、调用接口
• 支持OpenClaw Skill规范（如果可用）

1. 添加Skill管理API：

• GET /api/skills：列出所有已注册Skill
• POST /api/skills/{name}/execute：执行指定Skill

验证方法：

• BossAgents六大能力封装为Skill→ 可通过API调用
• OpenClaw不可用→ Skill封装暂缓，不影响BossAgents自身功能
• Skill接口定义完整，包含name、description、inputSchema、outputSchema

TASK-3-02：Skill接口标准化

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-02 |

| 优先级 | P2 |

| 依赖任务 | TASK-3-01 |

| 预估工作量 | 1天 |

实现步骤：

1. 定义标准Skill接口：

• 在server/skills/skill-schema.js中定义JSON Schema
• 包含：name、version、description、author、inputSchema、outputSchema、examples

1. 添加Skill验证：

• Skill注册时验证接口是否符合规范
• 不符合规范的Skill拒绝注册并输出错误提示

1. 添加Skill版本管理：

• 支持同一Skill的多版本共存
• 默认调用最新版本，可指定版本号

验证方法：

• Skill定义包含所有必要字段→ 注册成功
• 缺少必要字段的Skill→ 注册失败，输出错误提示
• 多版本Skill可按版本号调用

TASK-3-03：Hy-Memory插件/自建切换

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-03 |

| 优先级 | P2 |

| 依赖任务 | TASK-2-05 |

| 预估工作量 | 1天 |

实现步骤：

1. 在MemoryService中添加provider抽象层：

• 定义MemoryProvider接口：

   class MemoryProvider {
     async addFact(tenantId, fact) { throw new Error('Not implemented'); }
     async getFacts(tenantId, category) { throw new Error('Not implemented'); }
     async getProfile(tenantId) { throw new Error('Not implemented'); }
     // ... 其他方法
   }
   

• 实现SelfBuiltProvider（当前MemoryService的默认实现）
• 预留HyMemoryProvider接口（OpenClaw可用时实现）

1. 添加provider配置：

• 在config.yaml中添加：

   memory:
     provider: self-built  # self-built | hy-memory
   

• MemoryService根据配置选择provider

1. 添加数据迁移工具：

• 新建server/services/memory-migration.js
• 实现self-built→hy-memory和hy-memory→self-built的数据转换
• 切换provider时自动触发迁移

验证方法：

• 配置memory.provider=self-built→ 使用自建MemoryService
• 配置memory.provider=hy-memory→ 切换至Hy-Memory插件（如果可用）
• 切换provider后数据完整保留

TASK-3-04：Agentic RAG自评检索质量

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-04 |

| 优先级 | P1 |

| 依赖任务 | TASK-0-04, TASK-0-05 |

| 预估工作量 | 3天 |

实现步骤：

1. 新建server/core/agentic-rag.js：

• 实现AgenticRAG类
• searchWithEvaluation(query, minRelevance)：检索并自评质量
• 检索结果relevanceScore低于阈值时，自动调整查询词重新检索
• 连续2次检索质量不满足时，换用不同检索策略

1. 实现检索质量评估：

• 使用LLM评估检索结果与查询的相关性
• 评估维度：相关性、完整性、时效性
• 返回relevanceScore（0.0-1.0）

1. 实现查询词优化：

• 第一次检索质量不满足时，使用LLM优化查询词
• 添加同义词、拆分复合查询、调整关键词权重

1. 与KnowledgeSearchService集成：

• AgenticRAG调用KnowledgeSearchService进行实际检索
• 支持FTS5/LIKE/向量三种策略的自动切换

验证方法：

• 检索结果relevanceScore低于0.5→ Agent自动调整查询词重新检索
• 连续2次检索质量不满足→ Agent换用不同检索策略
• 所有策略均无结果→ 返回"未找到相关知识"提示

TASK-3-05：多策略检索自动切换

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-05 |

| 优先级 | P1 |

| 依赖任务 | TASK-3-04 |

| 预估工作量 | 2天 |

实现步骤：

1. 在server/core/agentic-rag.js中实现策略切换：

• 策略优先级：FTS5（如果可用）→ LIKE模糊匹配 → 向量语义检索（远期）
• FTS5检索无结果→ 自动切换为LIKE
• LIKE检索结果过多（>100条）→ 切换为向量检索精排（预留接口）

1. 增强server/core/knowledge-search.js：

• 添加searchWithStrategy(query, strategy, filters)方法
• strategy参数：'fts' | 'like' | 'vector'
• 向量检索预留接口（当前返回空结果）

1. 添加检索策略统计：

• 记录每次检索使用的策略和结果数量
• 统计各策略的使用频率和效果

验证方法：

• FTS5检索无结果→ 自动切换为LIKE模糊匹配
• LIKE检索结果过多→ 触发精排逻辑
• 所有策略均无结果→ 返回友好提示

TASK-3-06：角色权限定义

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-06 |

| 优先级 | P1 |

| 依赖任务 | 无 |

| 预估工作量 | 2天 |

实现步骤：

1. 定义角色权限模型：

• 新建server/core/rbac.js（Role-Based Access Control）
• 三种角色：boss（老板）、admin（管理员）、staff（普通员工）
• 权限矩阵：

   boss:   所有操作（查询、创建、审批、删除）
   admin:  配置管理、规则审批、用户管理
   staff:  查询、提交（不可审批、不可删除）
   

1. 在server/middleware/tenant-middleware.js中集成RBAC：

• 从JWT Token中提取角色信息
• 在请求处理前检查权限
• 无权限时返回403错误

1. 在CapabilityDispatcher中添加权限校验：

• 执行能力前检查当前用户角色是否有权限
• 审批类能力（如ECR审批）仅boss角色可执行

1. 添加权限配置：

• 在config.yaml中定义角色-权限映射
• 支持自定义角色和权限

验证方法：

• 普通员工尝试审批ECR→ 返回"权限不足"错误
• 老板审批ECR→ 审批成功
• 管理员配置通道→ 操作成功

TASK-3-07：团队协作链

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-07 |

| 优先级 | P1 |

| 依赖任务 | TASK-3-06, TASK-2-07 |

| 预估工作量 | 3天 |

实现步骤：

1. 新建server/core/workflow-engine.js：

• 实现跨角色协作链引擎
• 支持流程定义：员工提交→主管审核→老板审批
• 流程状态机：draft→submitted→reviewed→approved/rejected

1. 实现流程流转：

• 员工提交ECR→ 自动流转至主管审核
• 主管审核通过→ 流转至老板审批
• 主管驳回→ 流程回退至员工，附驳回原因
• 老板审批→ 流程结束

1. 与LiteScheduler集成：

• 协作链的每个节点对应一个数字员工任务
• 使用onComplete触发下一节点

1. 添加超时提醒：

• 协作链中某角色长时间未处理（可配置，默认24小时）
• 自动发送提醒通知（通过微信/飞书通道）
• 可配置自动升级或跳过

验证方法：

• 员工提交ECR→ 自动流转至主管审核
• 主管驳回→ 流程回退至员工，附驳回原因
• 超时未处理→ 发送提醒通知

TASK-3-08：权限与记忆隔离

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-08 |

| 优先级 | P1 |

| 依赖任务 | TASK-3-06, TASK-1-12 |

| 预估工作量 | 1天 |

实现步骤：

1. 在MemoryService中添加角色级隔离：

• 查询心智模型时检查当前用户角色
• 普通员工不可访问老板的心智模型
• 画像数据按角色过滤返回

1. 修改记忆API添加权限校验：

• /api/memory/mental-model：仅boss和admin角色可访问
• /api/memory/profile：所有角色可访问自己的画像
• /api/memory/intentions：仅boss角色可访问

1. 添加记忆访问日志：

• 记录所有记忆API的访问（谁访问了什么数据）
• 使用audit-log记录

验证方法：

• 普通员工查询心智模型→ 返回"无权访问"错误
• 老板查询心智模型→ 返回完整数据
• 访问日志记录所有记忆API调用

TASK-3-09：企微"大圆"对接调研

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-09 |

| 优先级 | P2 |

| 依赖任务 | TASK-1-01 |

| 预估工作量 | 1天 |

实现步骤：

1. 调研企微"大圆"（AI助手）对接可行性：

• 搜索企业微信开放平台文档中关于"大圆"的说明
• 评估与BossAgents数字员工的集成方式
• 记录结论：可行/不可行/待定

1. 评估对接工作量：

• 如果可行，估算对接所需工作量
• 评估技术风险和依赖

1. 产出调研报告：

• 新建docs/research/wecom-ai-assistant-report.md
• 包含：对接方式、工作量估算、风险评估

验证方法：

• 调研报告包含明确的结论和推荐方案
• 工作量估算合理

TASK-3-10：企微消息通道

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-10 |

| 优先级 | P2 |

| 依赖任务 | TASK-3-09, TASK-1-01 |

| 预估工作量 | 2天 |

实现步骤：

1. 在server/channels/wechat-channel.js中添加企微"大圆"支持（如果调研可行）：

• 实现企微AI助手的消息收发
• 与现有企微自建应用通道共存

1. 添加消息频率限制处理：

• 企微API对消息频率有限制
• 实现消息队列缓冲，遵守频率限制
• 使用内存级队列（单实例）

1. 添加消息格式适配：

• 企微"大圆"消息格式可能与自建应用不同
• 添加格式转换层

验证方法：

• 企微"大圆"用户发送消息→ BossAgents接收并处理
• 结果回传企微→ 用户收到回复
• 消息频率限制下功能正常

TASK-3-11：进化日志持久化

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-11 |

| 优先级 | P1 |

| 依赖任务 | 无 |

| 预估工作量 | 1天 |

实现步骤：

1. 创建进化日志数据库表：

• 在server/services/db-schema-init.js中添加：

   CREATE TABLE IF NOT EXISTS sciot_evolution_logs (
     id INTEGER PRIMARY KEY AUTOINCREMENT,
     ruleId TEXT NOT NULL,
     suggestion TEXT NOT NULL,
     status TEXT NOT NULL DEFAULT 'pending',
     createdAt TEXT NOT NULL,
     reviewedAt TEXT,
     reviewedBy TEXT,
     deployedAt TEXT,
     metadata TEXT DEFAULT '{}'
   );
   CREATE INDEX IF NOT EXISTS idx_evolution_logs_status ON sciot_evolution_logs(status);
   

1. 修改server/core/rule-evolution.js：

• 将进化日志从内存存储改为数据库持久化
• 在suggest()方法中，将建议写入sciot_evolution_logs表
• 在approve()方法中，更新status为'approved'
• 在deploy()方法中，更新status为'deployed'

1. 添加进化日志查询接口：

• GET /api/evolution/logs：查询进化日志列表
• 支持按状态筛选：pending/approved/deployed/rejected

验证方法：

• 规则进化建议生成→ sciot_evolution_logs表新增一条记录
• 服务重启后→ 进化日志完整保留
• 查询接口返回正确的进化日志列表

TASK-3-12：审批部署UI化

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-12 |

| 优先级 | P1 |

| 依赖任务 | TASK-3-11 |

| 预估工作量 | 2天 |

实现步骤：

1. 新建前端进化管理页面src/views/EvolutionManager.vue：

• 展示待审批/已审批/已部署状态的规则列表
• 支持按状态筛选
• 每条规则显示：建议内容、来源、置信度、创建时间

1. 实现审批操作：

• "审批通过"按钮→ 调用POST /api/evolution/approve/{id}
• "驳回"按钮→ 调用POST /api/evolution/reject/{id}
• "部署"按钮→ 调用POST /api/evolution/deploy/{id}

1. 实现部署逻辑：

• 审批通过后→ 规则自动部署至规则引擎（UnifiedRuleEngine）
• 部署失败→ 自动回滚，保留原规则
• 记录部署日志

1. 实现回滚操作：

• "回滚"按钮→ 调用POST /api/evolution/rollback/{id}
• 规则回退至上一版本
• 演化链记录回滚操作

1. 添加后端API：

• 在server.js中注册进化管理API路由
• GET /api/evolution/logs、POST /api/evolution/approve/{id}、POST /api/evolution/reject/{id}、POST /api/evolution/deploy/{id}、POST /api/evolution/rollback/{id}

1. 前端构建验证：

• 执行npm run build确认构建成功

验证方法：

• 管理员在前端查看进化建议列表→ 展示各状态的规则
• 管理员点击"审批通过"→ 规则自动部署，状态更新为"已部署"
• 管理员点击"回滚"→ 规则回退至上一版本
• 部署失败→ 自动回滚，原规则不受影响

TASK-3-13：演化历史可视化

| 属性 | 值 |

|------|-----|

| 需求ID | REQ-3-13 |

| 优先级 | P2 |

| 依赖任务 | TASK-3-12 |

| 预估工作量 | 1天 |

实现步骤：

1. 在src/views/EvolutionManager.vue中添加演化历史时间线：

• 以时间线形式展示规则从创建到当前的所有版本变更
• 每个节点显示：版本号、变更内容、操作人、时间
• supersedes链路用箭头连接

1. 添加演化链查询API：

• GET /api/evolution/chain/{ruleId}：查询规则的完整演化链
• 返回按时间排序的演化记录列表

1. 实现可视化组件：

• 使用CSS绘制时间线（不依赖第三方图表库）
• 支持展开/折叠详情
• 支持点击节点查看完整变更内容

1. 前端构建验证：

• 执行npm run build确认构建成功

验证方法：

• 查看某规则的演化历史→ 以时间线形式展示所有版本变更
• supersedes链路正确显示
• 点击节点可查看完整变更内容

依赖关系图

Phase 0:
  TASK-0-01 (JWT修复) ─────────────────────────────────────────→ TASK-1-05 (小程序JWT)
  TASK-0-02 (审计日志确认) ──→ TASK-0-03 (审计日志API)
  TASK-0-04 (知识库前端) ──→ TASK-0-05 (搜索降级) ──→ TASK-3-04 (Agentic RAG)
  TASK-0-06 (OpenClaw调研) ──→ TASK-1-01 (微信通道) ──→ TASK-3-09 (企微调研)

Phase 1:
  TASK-1-01 (微信接收) ──→ TASK-1-02 (微信回复) ──→ TASK-1-03 (通道路由)
  TASK-1-01 (微信接收) ──→ TASK-1-04 (企微备选)
  TASK-1-05 (小程序JWT) ──→ TASK-1-06 (微信AI) & TASK-1-07 (对话入口)
  TASK-0-02 (审计日志) ──→ TASK-1-08 (Memory框架+L1) ──→ TASK-1-09 (L2事实) ──→ TASK-1-10 (L3画像) ──→ TASK-1-11 (System1) ──→ TASK-2-06 (TaskDecomposer)
  TASK-1-10 (L3画像) + TASK-1-11 (System1) ──→ TASK-1-12 (租户隔离)
  TASK-1-13 (环境检查) ──→ TASK-1-14 (DB初始化) ──→ TASK-1-15 (Docker)

Phase 2:
  TASK-1-08 (Memory框架) ──→ TASK-2-01 (L4摘要) ──→ TASK-2-02 (L5心智) ──→ TASK-2-03 (L6意图) ──→ TASK-2-04 (System2) ──→ TASK-2-05 (演化链)
  TASK-2-06 (TaskDecomposer) ──→ TASK-2-07 (并行调度) ──→ TASK-2-08 (结果汇总)
  TASK-2-09 (互斥锁超时) ──→ TASK-2-10 (死锁检测)
  TASK-2-11 (混元接入) ──→ TASK-2-12 (语义分类) ──→ TASK-2-13 (动态路由) ──→ TASK-2-14 (A/B测试)
  TASK-1-07 (对话入口) ──→ TASK-2-15 (AI深度) ──→ TASK-2-16 (进度推送)
  TASK-1-10 (L3画像) + TASK-2-02 (L5心智) ──→ TASK-2-17 (Dashboard画像)

Phase 3:
  TASK-0-06 (调研) ──→ TASK-3-01 (Skill封装) ──→ TASK-3-02 (Skill标准化)
  TASK-2-05 (演化链) ──→ TASK-3-03 (Hy-Memory切换)
  TASK-0-05 (搜索降级) ──→ TASK-3-04 (Agentic RAG) ──→ TASK-3-05 (多策略检索)
  TASK-3-06 (角色权限) + TASK-2-07 (并行调度) ──→ TASK-3-07 (协作链)
  TASK-3-06 (角色权限) + TASK-1-12 (租户隔离) ──→ TASK-3-08 (权限记忆隔离)
  TASK-1-01 (微信通道) + TASK-3-09 (企微调研) ──→ TASK-3-10 (企微通道)
  TASK-3-11 (进化日志) ──→ TASK-3-12 (审批UI) ──→ TASK-3-13 (演化可视化)

统计摘要

| 指标 | 数值 |

|------|------|

| 任务总数 | 42 |

| P0 任务数 | 13 |

| P1 任务数 | 20 |

| P2 任务数 | 9 |

| Phase 0 任务数 | 6 |

| Phase 1 任务数 | 15 |

| Phase 2 任务数 | 17 |

| Phase 3 任务数 | 13（含3个调研/扩展任务） |

各Phase工作量估算

关键依赖链（阻塞链）

1. JWT修复链：TASK-0-01 → TASK-1-05 → TASK-1-06/TASK-1-07（阻塞小程序所有功能）
2. 审计日志链：TASK-0-02 → TASK-0-03 → TASK-1-08 → TASK-1-09 → TASK-1-10 → TASK-1-11（阻塞Memory系统全部）
3. 微信通道链：TASK-0-06 → TASK-1-01 → TASK-1-02 → TASK-1-03（阻塞微信所有功能）
4. 知识库链：TASK-0-04 → TASK-0-05 → TASK-3-04 → TASK-3-05（阻塞Agentic RAG）
5. 并行执行链：TASK-2-06 → TASK-2-07 → TASK-2-08（阻塞Multi-Agent并行）
6. 进化UI链：TASK-3-11 → TASK-3-12 → TASK-3-13（阻塞自进化闭环UI化）