BossAgents × 微信智能体生态优化方案 v2 — 需求规格文档

版本：1.0 | 日期：2026-06-24 | 基于优化方案v2.0生成 | 格式：EARS

1. 组件定位

1.1 核心职责

本组件负责将BossAgents工业智能体生态与微信/Tencent AI Agent生态深度融合，实现安全修复、记忆系统升级、微信通道接入、多Agent并行、模型路由增强及生态扩展。

1.2 核心输入

1. 用户指令：通过微信/企微/飞书/小程序/Web Dashboard发起的业务操作请求
2. 审计日志数据：现有audit-log.js产生的两阶段日志数据
3. 知识库查询请求：前端KnowledgeService发起的搜索请求
4. LLM推理请求：CapabilityDispatcher分发的各类AI任务
5. 定时触发信号：LiteScheduler cron调度触发的心跳/分析任务
6. 微信生态事件：ClawBot/企微/小程序AI SDK推送的消息与回调

1.3 核心输出

1. 业务执行结果：数字员工处理后的结构化响应（文本/卡片/通知）
2. 记忆数据：提取的事实、画像、摘要、心智模型、前瞻意图
3. 知识检索结果：后端搜索API返回的匹配知识条目
4. 微信消息推送：通过微信通道回传的执行结果与进度通知
5. 审计与进化日志：操作审计记录与规则进化历史

1.4 职责边界

• 不负责：SCSAI agent平台底层AML数据存储与CRUD操作
• 不负责：SCIOT规则引擎的规则生成逻辑（复用现有generated/目录）
• 不负责：昇腾NPU/MTCLAW底层算力调度（仅通过SmartLLMRouter调用）
• 不负责：微信/企微官方SDK的内部实现维护
• 不负责：OpenClaw/iLink平台本身的部署与运维

2. 领域术语

SmartLLMRouter

: BossAgents的LLM统一调度器，已实现5级降级链路（MTCLAW→AscendNPU→Ollama→DeepSeek→规则引擎→simulatedThinking），含熔断机制与响应缓存。

LiteScheduler

: BossAgents的数字员工调度器，已实现协作链（onComplete触发）、Loop/Goal调度、确认挂起机制，支持串行编排。

CapabilityDispatcher

: BossAgents的能力统一分发器，负责参数归一化、审计日志、权限校验，已有source路由支持（wechat/feishu/web等）。

Hy-Memory

: 微信智能体的六层记忆架构（Atomic Traces → Atomic Facts → Identity Profile → Session Summaries → Mental Models → Forward-looking Intentions），含System 1/2双系统与演化链。

OpenClaw

: Tencent内部智能体平台生态，提供ClawBot微信插件、iLink协议、Skills市场等能力。外部项目接入路径待确认。

RuleEvolution

: BossAgents的自进化闭环框架（414行），实现规则采集→识别→建议→审批→监控的完整链路。

Agentic RAG

: Agent自主评估检索质量并决定是否重新检索或换策略的增强型知识检索模式。

互斥锁（_withStaffMutex）

: LiteScheduler中用于防止同一员工并发执行的内存级Map锁，当前无超时释放、无死锁检测、无分布式支持。

simulatedThinking

: SmartLLMRouter降级链路最末端的兜底机制，返回硬编码的思考过程。这是设计意图而非缺陷，但需增强降级数据质量。

演化链（Evolution Chain）

: 通过supersedes指针链接旧/新记忆版本的记忆管理机制，复用RuleEvolution的版本管理思路。

3. 角色与边界

3.1 核心角色

• 老板（企业决策者）：通过微信/企微/小程序向数字员工下达业务指令，接收执行结果与建议
• 系统管理员：配置微信通道、管理数字员工权限、审批规则进化建议
• 开发者：部署BossAgents系统、集成新通道与模型、调试问题

3.2 外部系统

• 微信/企微平台：消息通道与AI SDK接入
• 混元大模型API：国产合规LLM推理服务
• OpenClaw平台：智能体生态（ClawBot插件、Skills市场、iLink协议）
• SCSAI agent：PLM底座，提供工业对象模型与业务数据
• 飞书平台：现有IM通道，已实现消息收发

3.3 交互上下文

@startuml
left to right direction

rectangle "BossAgents 生态优化系统" as core {
}

actor "老板" as boss
actor "系统管理员" as admin
actor "开发者" as dev

system "微信/企微平台" as wechat
system "混元大模型API" as hunyuan
system "OpenClaw平台" as openclaw
system "SCSAI agent" as SCSAI
system "飞书平台" as feishu

boss --> core : 微信/小程序下达指令\n接收执行结果
admin --> core : 配置通道/审批规则\n管理权限
dev --> core : 部署/集成/调试

core --> wechat : 消息收发/AI SDK
core --> hunyuan : LLM推理请求
core --> openclaw : ClawBot/Skills/iLink
core --> SCSAI : 业务数据读写
core --> feishu : 消息收发(现有)

@enduml

4. DFX约束

4.1 性能

1. 微信消息响应时间：When 用户通过微信发送指令，the BossAgents系统 shall 在5秒内返回确认回执
2. 知识检索响应时间：When 前端发起知识搜索请求，the 后端搜索API shall 在2秒内返回结果
3. 记忆写入延迟：When CapabilityDispatcher完成一次执行，the Memory Service shall 在500ms内完成事实提取与写入
4. 并行任务调度：When TaskDecomposer拆解出多个子任务，the LiteScheduler shall 在1秒内完成并行调度启动

4.2 可靠性

1. 降级链路可用性：The SmartLLMRouter 5级降级链路 shall 保证99.5%的请求得到有效响应
2. 审计日志持久化：The 审计日志系统 shall 确保所有操作日志写入数据库，不丢失任何一条记录
3. 互斥锁超时释放：While 员工任务执行超过30秒，the 互斥锁 shall 自动释放，避免死锁

4.3 安全性

1. JWT密钥管理：The 系统shall禁止使用硬编码fallback密钥，JWT密钥必须从环境变量读取
2. Token持久化：The Token缓存shall使用Redis或文件持久化，禁止仅内存缓存（多实例场景）
3. 审计日志完整性：The 审计日志shall记录所有关键操作，不可被篡改或跳过

4.4 可维护性

1. 配置驱动：The 系统shall使用YAML/JSON配置驱动架构，新通道/模型接入无需修改核心代码
2. 健康检查：The 系统shall提供/api/health端点，返回各组件运行状态
3. 日志规范：The 系统shall使用结构化日志，包含traceId、tenantId、staffId等关键上下文

4.5 兼容性

1. 现有通道兼容：Where 新增微信通道，the 系统shall保持飞书/Web/小程序现有通道功能不受影响
2. 降级链路兼容：Where 新增混元模型provider，the SmartLLMRouter shall保持现有5级降级链路完整
3. 数据迁移兼容：Where 新增记忆层存储，the 系统shall支持从空状态冷启动，无需历史数据迁移

5. 核心能力

Phase 0 — 前置修复

#### 5.0.1 JWT密钥硬编码fallback修复

##### 业务规则

1. 禁止硬编码密钥：The miniapp-auth模块shall从环境变量JWT_SECRET读取密钥，当环境变量未设置时shall拒绝启动并输出明确错误提示，禁止使用change-me-in-production作为fallback

a. 验收条件：[环境变量JWT_SECRET未设置] → [服务启动失败，日志输出"JWT_SECRET environment variable is required"]

b. 验收条件：[环境变量JWT_SECRET已设置] → [服务正常启动，Token签发使用环境变量值]

1. Token缓存持久化：The Token缓存shall使用文件持久化（单实例）或Redis（多实例），禁止仅使用内存Map缓存

a. 验收条件：[服务重启后] → [已缓存的Token仍可验证，无需重新登录]

b. 验收条件：[多实例部署时] → [实例A签发的Token在实例B上可验证]

##### 异常场景

1. JWT_SECRET未设置

a. 触发条件：启动时环境变量JWT_SECRET为空或未定义

b. 系统行为：阻止服务启动，输出错误日志

c. 用户感知：启动脚本返回非零退出码，控制台显示明确配置指引

#### 5.0.2 审计日志DB写入确认与修复

##### 业务规则

1. 审计日志写入确认：The 审计日志系统shall确保audit-log.js的start/complete两阶段日志均写入数据库，audit-logs/目录空置问题shall被修复

a. 验收条件：[任意数字员工执行一次任务] → [数据库中可查询到对应的start和complete两条审计记录]

b. 验收条件：[查询audit-logs/目录] → [目录中有对应的日志文件，或确认日志仅写入DB（非文件）]

1. 审计日志查询API：The 系统shall提供/api/audit-logs查询接口，支持按时间范围、员工ID、任务类型筛选

a. 验收条件：[调用GET /api/audit-logs?staffId=xxx&from=2026-01-01] → [返回该员工指定时间范围内的审计记录列表]

##### 异常场景

1. 数据库写入失败

a. 触发条件：SQLite/MySQL写入审计日志时发生错误

b. 系统行为：将日志降级写入本地文件，并触发告警

c. 用户感知：管理界面显示"审计日志存储异常"告警

#### 5.0.3 知识库前端接入后端搜索API

##### 业务规则

1. 前端搜索API对接：The KnowledgeService shall调用后端/api/knowledge/search接口获取搜索结果，禁止使用硬编码数据

a. 验收条件：[前端知识库页面输入搜索关键词] → [发起fetch('/api/knowledge/search?q=...')请求，展示后端返回结果]

b. 验收条件：[后端知识库新增规则] → [前端搜索可立即检索到新规则，无需前端代码变更]

1. 搜索降级策略：When FTS5不可用，the 后端搜索API shall使用LIKE+简单中文分词作为降级方案

a. 验收条件：[SQLite版本不支持FTS5] → [搜索仍可正常工作，使用LIKE模糊匹配]

b. 验收条件：[搜索中文关键词"变更流程"] → [返回包含"变更流程"的知识条目]

1. 搜索结果格式统一：The 后端搜索API shall返回统一格式的JSON结果，包含id、title、content、category、relevanceScore字段

a. 验收条件：[调用搜索API] → [返回JSON数组，每条记录包含上述5个字段]

##### 异常场景

1. 后端搜索服务不可用

a. 触发条件：前端调用搜索API返回5xx错误或超时

b. 系统行为：前端显示"搜索服务暂时不可用"提示，提供重试按钮

c. 用户感知：搜索页面显示友好错误提示，不展示空白或报错

1. jieba分词编译失败

a. 触发条件：Windows/Node v22环境下jieba npm包编译失败

b. 系统行为：自动降级为简单字符级分词

c. 用户感知：搜索功能正常可用，中文分词精度略低

#### 5.0.4 OpenClaw/ClawBot接入可行性调研

##### 业务规则

1. 调研范围：The 调研shall确认以下三项内容：(a) OpenClaw CLI是否公开可用；(b) ClawBot插件是否对第三方开发者开放；(c) iLink协议接入门槛

a. 验收条件：[调研完成] → [产出调研报告，明确三项内容的结论（可行/不可行/待定）及依据]

1. 备选方案评估：When OpenClaw/ClawBot不可行，the 调研shall评估企业微信自建应用、微信公众号+客服消息接口、小程序内嵌对话三种备选方案

a. 验收条件：[OpenClaw不可行] → [调研报告包含三种备选方案的可行性评估、工作量估算、推荐排序]

1. 调研产出：The 调研shall产出书面报告，包含结论、依据、推荐方案、风险点

a. 验收条件：[调研报告交付] → [报告包含明确的"推荐方案"和"下一步行动"章节]

##### 异常场景

1. 调研信息不充分

a. 触发条件：OpenClaw/iLink文档缺失或API未公开

b. 系统行为：标注为"待定"，提供备选方案

c. 用户感知：调研报告明确标注不确定性，不影响后续开发决策

Phase 1 — 快速见效

#### 5.1.1 微信通道接入

##### 业务规则

1. 微信消息接收：When 用户通过微信发送消息，the BossAgents系统shall通过ClawBot或企微自建应用接收消息并转发至CapabilityDispatcher

a. 验收条件：[微信用户发送"查询BOM A001"] → [CapabilityDispatcher收到source='wechat'的请求并执行]

1. 微信消息回复：When 数字员工完成执行，the 系统shall将结果通过微信通道回传给用户

a. 验收条件：[数字员工返回执行结果] → [微信用户收到结果消息（文本/卡片格式）]

1. 通道路由：The CapabilityDispatcher shall根据消息来源（wechat/feishu/web/miniapp）进行路由分发，现有通道功能不受影响

a. 验收条件：[微信消息进入Dispatcher] → [按source='wechat'路由，不影响飞书/Web通道]

b. 验收条件：[飞书消息进入Dispatcher] → [按source='feishu'路由，功能与接入微信前完全一致]

1. 企微自建应用备选：Where ClawBot不可用，the 系统shall支持通过企业微信自建应用接入

a. 验收条件：[配置企微自建应用参数] → [系统可接收企微消息并回复]

##### 交互流程

@startuml
actor "微信用户" as user
participant "微信/企微平台" as wechat
participant "BossAgents\n微信Channel" as channel
participant "CapabilityDispatcher" as dispatcher
participant "数字员工" as staff

user -> wechat : 发送消息
wechat -> channel : 消息回调
channel -> dispatcher : source='wechat'
dispatcher -> staff : 执行任务
staff -> dispatcher : 返回结果
dispatcher -> channel : 格式化结果
channel -> wechat : 发送回复
wechat -> user : 收到结果
@enduml

##### 异常场景

1. 微信通道断连

a. 触发条件：微信回调URL不可达或Token验证失败

b. 系统行为：记录错误日志，触发告警，自动重试连接

c. 用户感知：微信消息无回复，管理界面显示通道异常告警

1. 消息格式不兼容

a. 触发条件：微信消息类型不支持（如视频/文件）

b. 系统行为：回复"暂不支持该消息类型"提示

c. 用户感知：收到友好的不支持提示

#### 5.1.2 小程序自动模式接入微信AI + JWT修复

##### 业务规则

1. JWT密钥修复（与Phase 0关联）：The miniapp-auth模块shall在接入微信AI前完成JWT密钥硬编码修复（见5.0.1）

a. 验收条件：[小程序登录] → [Token签发使用环境变量密钥，非硬编码fallback]

1. 自动模式接入：Where 微信开放小程序AI生态接入，the bossagents-miniapp shall支持提交审核时授权微信读取小程序源码，实现零额外开发的AI能力接入

a. 验收条件：[小程序提交审核并授权AI接入] → [微信AI可读取小程序源码并提供智能服务]

b. 验收条件：[微信AI政策确认] → [明确2026年6月8日微信开放小程序AI生态接入的具体政策与限制]

1. 小程序对话入口：The bossagents-miniapp ai-chat页面shall与后端CapabilityDispatcher对接，支持文本对话

a. 验收条件：[小程序ai-chat页面输入"帮我查BOM"] → [调用后端API，返回数字员工执行结果]

##### 异常场景

1. 微信AI政策未开放

a. 触发条件：微信小程序AI生态接入政策未对第三方开放

b. 系统行为：自动模式标记为不可用，引导使用开发模式

c. 用户感知：小程序AI功能提示"暂未开放"，提供开发模式入口

#### 5.1.3 Memory系统Layer 1-3实现

##### 业务规则

1. Layer 1 原子痕迹：The Memory Service shall复用现有audit-log.js的start/complete两阶段日志作为原子痕迹，并提供/api/memory/traces查询回放接口

a. 验收条件：[数字员工执行任务] → [Memory Service记录start/complete两阶段原子痕迹]

b. 验收条件：[调用GET /api/memory/traces?staffId=xxx] → [返回该员工的原子痕迹列表，含时间戳、操作类型、参数摘要]

1. Layer 2 原子事实提取：When CapabilityDispatcher.execute()完成一次执行，the Memory Service shall从交互中提取关键事实（老板偏好、供应商偏好、常用操作），存储至memory/facts.json

a. 验收条件：[老板说"我偏好供应商A"] → [facts.json中新增{category: "supplier_preference", value: "A", confidence: 0.9}]

b. 验收条件：[老板三次选择同一操作模式] → [facts.json中该操作模式的confidence提升]

1. Layer 3 用户画像构建：The Memory Service shall为企业/老板构建用户画像，包含企业信息、角色、常用对象类型、审批偏好，存储至memory/profiles/{tenantId}.json

a. 验收条件：[老板首次使用系统] → [自动创建基础画像profile，含tenantId、角色默认值]

b. 验收条件：[老板完成3次BOM查询] → [画像中"常用对象类型"更新为["BOM"]]

1. System 1 实时写入：The Memory Service shall在CapabilityDispatcher.execute()的finally块中实时提取事实并写入，复用现有自进化学习器的finally块模式

a. 验收条件：[任意能力执行完成] → [finally块触发事实提取，facts.json实时更新]

1. 与租户中间件集成：The Memory Service shall与tenant-middleware.js集成，确保记忆数据按租户隔离

a. 验收条件：[租户A的老板操作] → [仅更新租户A的画像和事实，不影响租户B]

##### 交互流程

@startuml
participant "CapabilityDispatcher" as dispatcher
participant "Memory Service" as memory
participant "tenant-middleware" as tenant
database "memory/facts.json" as facts
database "memory/profiles/" as profiles

dispatcher -> memory : execute() finally块触发
memory -> tenant : 获取tenantId
tenant -> memory : 返回tenantId
memory -> facts : 提取事实并写入
memory -> profiles : 更新用户画像
@enduml

##### 异常场景

1. 事实提取失败

a. 触发条件：LLM调用失败导致事实提取异常

b. 系统行为：跳过本次事实提取，记录警告日志，不影响主流程

c. 用户感知：业务操作正常完成，记忆更新延迟

1. 画像文件损坏

a. 触发条件：memory/profiles/{tenantId}.json文件格式错误

b. 系统行为：从备份恢复或重建基础画像

c. 用户感知：画像数据重置为默认值，历史偏好丢失

#### 5.1.4 一键部署包优化

##### 业务规则

1. 环境检查：When 执行start.bat，the 启动脚本shall检查Node.js版本、pnpm是否安装、.env文件是否存在

a. 验收条件：[Node.js版本低于18] → [脚本输出"Node.js 18+ required"并退出]

b. 验收条件：[pnpm未安装] → [脚本输出"pnpm not found"并提供安装指引]

c. 验收条件：[.env文件不存在] → [自动从.env.example复制并提示用户配置]

1. 自动依赖安装：When node_modules目录不存在，the 启动脚本shall自动执行pnpm install

a. 验收条件：[首次部署，node_modules不存在] → [自动执行pnpm install，安装完成后继续启动]

1. 自动DB初始化：When 数据库文件不存在，the 启动脚本shall自动调用db-schema-init.js初始化数据库

a. 验收条件：[首次启动，SQLite文件不存在] → [自动创建数据库并初始化表结构]

1. Docker单命令部署：The 系统shall支持docker run单命令启动（含Node.js + SQLite + nginx）

a. 验收条件：[执行docker run命令] → [单容器内包含完整服务栈，健康检查通过后可访问]

##### 异常场景

1. 依赖安装失败

a. 触发条件：pnpm install因网络或权限问题失败

b. 系统行为：输出详细错误信息，提供镜像源切换建议

c. 用户感知：脚本退出并显示"依赖安装失败"及修复建议

1. 端口占用

a. 触发条件：3006端口已被占用

b. 系统行为：提示端口占用，提供终止占用进程或更换端口的选项

c. 用户感知：看到明确的端口冲突提示和解决选项

Phase 2 — 深度增强

#### 5.2.1 Memory系统Layer 4-6 + System 2

##### 业务规则

1. Layer 4 会话摘要：The Memory Service shall增强ConversationManager，按"业务主题"（BOM/采购/变更）聚合会话摘要，存储至staff_session_summaries表

a. 验收条件：[完成一次BOM查询对话] → [session_summaries表新增一条BOM主题摘要，含关键决策和结果]

b. 验收条件：[查询某租户的历史会话摘要] → [按业务主题分类展示，支持时间范围筛选]

1. Layer 5 心智模型：The Memory Service shall构建老板的深度决策模型（风险偏好、成本敏感度、创新意愿），存储至memory/mental-models/{tenantId}.json，由System 2异步构建

a. 验收条件：[System 2分析30天审计日志后] → [mental-models中生成{riskPreference: "conservative", costSensitivity: "high", innovationWillingness: "low"}]

b. 验收条件：[老板连续3次选择低成本方案] → [心智模型中costSensitivity权重提升]

1. Layer 6 前瞻意图：The Memory Service shall预判老板下一步需求，存储至memory/intentions/{tenantId}.json，由心跳任务定期更新（复用LiteScheduler cron机制）

a. 验收条件：[老板刚完成BOM审批] → [intentions中新增{predicted: "采购下单", confidence: 0.7, basedOn: "历史BOM审批后90%触发采购"}]

b. 验收条件：[心跳任务每15分钟执行] → [更新前瞻意图的confidence和basedOn字段]

1. System 2 异步分析：The Memory Service shall新增cron job，在夜间分析审计日志并更新Mental Models，复用LiteScheduler的cron调度机制

a. 验收条件：[cron job每日凌晨2点执行] → [分析前一天的审计日志，更新心智模型和前瞻意图]

b. 验收条件：[System 2分析期间] → [不影响System 1的实时写入]

1. 演化链：The Memory Service shall通过supersedes指针链接旧/新记忆版本，复用RuleEvolution的版本管理思路，存储至memory/evolution-chain.json

a. 验收条件：[老板偏好从"供应商A"变为"供应商B"] → [演化链记录{oldFact: "偏好A", newFact: "偏好B", supersedes: oldFactId, timestamp: ...}]

b. 验收条件：[查询某事实的演化历史] → [返回完整的supersedes链路，从最早到最新]

##### 异常场景

1. System 2分析超时

a. 触发条件：夜间cron job执行时间超过1小时

b. 系统行为：记录超时日志，中断本次分析，保留已处理的部分结果

c. 用户感知：心智模型更新延迟，次日可正常补全

1. 演化链断裂

a. 触发条件：supersedes指针指向的记忆记录被意外删除

b. 系统行为：标记为orphan记录，从当前有效事实重新建立链路

c. 用户感知：演化历史不完整，但不影响当前记忆使用

#### 5.2.2 Multi-Agent并行执行 + 互斥锁升级

##### 业务规则

1. 任务拆解：When 老板下达复杂任务（如"比较三家供应商报价"），the TaskDecomposer shall使用LLM拆解为多个子任务

a. 验收条件：[输入"比较供应商A/B/C报价"] → [拆解为3个子任务：查询A报价、查询B报价、查询C报价]

b. 验收条件：[子任务之间无依赖关系] → [标记为可并行执行]

1. 并行调度：The LiteScheduler shall新增runParallel(staffIds[], subTasks[])方法，支持多个员工同时执行

a. 验收条件：[3个子任务并行调度] → [3个员工同时开始执行，总耗时≈单次执行耗时]

b. 验收条件：[任一子任务失败] → [其他子任务继续执行，最终汇总时标注失败项]

1. 结果汇总：The ResultAggregator shall使用LLM汇总多个子任务的执行结果，解决冲突并生成综合建议

a. 验收条件：[3家供应商报价结果汇总] → [生成"推荐供应商B，综合评分最高"的综合建议]

b. 验收条件：[子任务结果存在矛盾] → [标注矛盾点，由LLM判断或请求老板确认]

1. 互斥锁超时释放：While 员工任务执行超过30秒，the 互斥锁shall自动释放

a. 验收条件：[员工A任务卡死超过30秒] → [互斥锁自动释放，员工A可被重新调度]

1. 死锁检测：The 互斥锁系统shall实现死锁检测机制，当检测到循环等待时自动解除

a. 验收条件：[员工A等B、B等A的循环等待] → [系统检测到死锁，自动释放其中一个锁]

1. 现有协作链兼容：Where 新增并行执行能力，the LiteScheduler shall保持现有协作链（onComplete触发）功能不受影响

a. 验收条件：[使用onComplete协作链的任务] → [串行执行行为与升级前完全一致]

##### 交互流程

@startuml
actor "老板" as boss
participant "CapabilityDispatcher" as dispatcher
participant "TaskDecomposer" as decomposer
participant "LiteScheduler" as scheduler
participant "员工A" as staffA
participant "员工B" as staffB
participant "员工C" as staffC
participant "ResultAggregator" as aggregator

boss -> dispatcher : "比较三家供应商报价"
dispatcher -> decomposer : 拆解任务
decomposer -> scheduler : 3个子任务并行调度
scheduler -> staffA : 查询供应商A报价
scheduler -> staffB : 查询供应商B报价
scheduler -> staffC : 查询供应商C报价
staffA -> aggregator : 报价A结果
staffB -> aggregator : 报价B结果
staffC -> aggregator : 报价C结果
aggregator -> dispatcher : 综合建议
dispatcher -> boss : "推荐供应商B"
@enduml

##### 异常场景

1. 任务拆解失败

a. 触发条件：LLM无法理解复杂任务意图

b. 系统行为：降级为串行执行，请求老板确认拆解方式

c. 用户感知：收到"任务较复杂，建议分步执行"提示

1. 并行执行部分失败

a. 触发条件：3个并行子任务中1个失败

b. 系统行为：汇总时标注失败项，基于成功结果生成部分建议

c. 用户感知：收到"供应商C报价查询失败，基于A/B结果建议..."提示

1. 结果冲突

a. 触发条件：不同子任务返回矛盾结果

b. 系统行为：标注矛盾，由LLM判断或请求老板确认

c. 用户感知：收到"结果存在矛盾，请确认"提示

#### 5.2.3 混元大模型接入 + 语义分类

##### 业务规则

1. 混元Provider接入：The SmartLLMRouter shall新增hunyuan provider，插入降级链路中DeepSeek之后、规则引擎之前（priority: 4.5）

a. 验收条件：[DeepSeek不可用] → [自动降级至混元模型]

b. 验收条件：[混元模型不可用] → [继续降级至规则引擎]

c. 验收条件：[配置HUNYUAN_API_KEY环境变量] → [混元provider可用，支持fast和think两种模型]

1. 语义级分类：The SmartLLMRouter shall将关键词匹配升级为语义级分类（嵌入向量），提升任务分类准确率

a. 验收条件：[输入"帮我看看这个BOM有没有问题"] → [语义分类为"identify"能力，而非关键词匹配失败]

b. 验收条件：[语义分类置信度低于0.6] → [降级为关键词匹配]

1. 动态路由：The SmartLLMRouter shall基于历史准确率动态调整模型选择策略

a. 验收条件：[混元模型在BOM查询任务上准确率持续高于DeepSeek] → [BOM查询任务优先路由至混元]

b. 验收条件：[某模型连续5次超时] → [自动降低该模型优先级]

1. 现有5级降级链路保持：Where 新增混元provider和语义分类，the SmartLLMRouter shall保持现有MTCLAW→AscendNPU→Ollama→DeepSeek→规则引擎→simulatedThinking降级链路完整

a. 验收条件：[混元provider禁用时] → [降级链路与接入前完全一致]

1. A/B测试支持：The SmartLLMRouter shall支持同一任务对比不同模型效果

a. 验收条件：[开启A/B测试模式] → [同一请求同时发送至两个模型，记录对比结果]

##### 异常场景

1. 混元API不可用

a. 触发条件：HUNYUAN_API_KEY未配置或API超时

b. 系统行为：跳过混元provider，继续降级链路

c. 用户感知：请求正常响应，日志中记录混元降级事件

1. 语义分类服务异常

a. 触发条件：嵌入向量服务不可用

b. 系统行为：降级为关键词匹配

c. 用户感知：分类准确率略降，功能不受影响

#### 5.2.4 小程序开发模式深度集成

##### 业务规则

1. AI对话深度集成：The bossagents-miniapp ai-chat页面shall基于微信小程序AI SDK构建自定义集成，支持文本/语音输入

a. 验收条件：[小程序ai-chat页面点击语音按钮] → [调用微信语音识别，转为文本发送至后端]

b. 验收条件：[输入"帮我创建一个ECR"] → [调用CapabilityDispatcher，返回结构化ECR创建结果]

1. 执行进度实时推送：The bossagents-miniapp shall通过WebSocket实时展示数字员工执行进度（复用ws-push-service.js + useWebSocket.js）

a. 验收条件：[数字员工开始执行任务] → [小程序实时显示"正在查询BOM..."进度]

b. 验收条件：[任务执行完成] → [小程序实时显示执行结果]

1. Dashboard数据对接：The bossagents-miniapp Dashboard页面shall与Memory Service画像数据对接，展示老板偏好和常用操作

a. 验收条件：[Dashboard页面加载] → [展示从Memory Service获取的用户画像摘要]

##### 异常场景

1. 微信AI SDK版本不兼容

a. 触发条件：微信小程序AI SDK API变更

b. 系统行为：降级为纯文本对话模式

c. 用户感知：语音功能暂时不可用，文本对话正常

Phase 3 — 生态扩展

#### 5.3.1 OpenClaw Skill封装

##### 业务规则

1. Skill封装发布：Where OpenClaw生态可用，the BossAgents shall将核心能力封装为OpenClaw Skill格式发布

a. 验收条件：[BossAgents六大能力封装为Skill] → [可通过OpenClaw CLI安装并调用]

b. 验收条件：[OpenClaw不可用] → [Skill封装暂缓，不影响BossAgents自身功能]

1. Skill接口标准化：The Skill封装shall遵循OpenClaw Skill规范，定义标准输入输出接口

a. 验收条件：[Skill定义包含name、description、inputSchema、outputSchema] → [符合OpenClaw Skill注册要求]

##### 异常场景

1. OpenClaw生态不可用

a. 触发条件：OpenClaw平台未对第三方开放Skill发布

b. 系统行为：Skill封装暂缓，保留接口定义供未来使用

c. 用户感知：BossAgents功能不受影响，Skill发布待平台开放后进行

#### 5.3.2 Hy-Memory插件/自建替代

##### 业务规则

1. 优先自建：The 记忆系统shall优先使用自建Memory Service（Phase 1-2已实现），不依赖Hy-Memory插件

a. 验收条件：[Memory Service Layer 1-6全部实现] → [记忆功能完整可用，不依赖外部插件]

1. Hy-Memory插件兼容：Where BossAgents运行在OpenClaw上且Hy-Memory插件可用，the 系统shall支持一键切换至Hy-Memory插件

a. 验收条件：[配置memory.provider=hy-memory] → [记忆读写切换至Hy-Memory插件]

b. 验收条件：[配置memory.provider=self-built] → [记忆读写使用自建Memory Service]

##### 异常场景

1. Hy-Memory插件与自建数据格式不兼容

a. 触发条件：切换provider后数据格式不一致

b. 系统行为：提供数据迁移工具，自动转换格式

c. 用户感知：切换过程有短暂不可用，数据完整保留

#### 5.3.3 Agentic RAG知识检索

##### 业务规则

1. Agent自评检索质量：The Agentic RAG shall支持Agent自主评估检索结果质量，当质量不满足要求时自动重新检索或换策略

a. 验收条件：[检索结果relevanceScore低于0.5] → [Agent自动调整查询词重新检索]

b. 验收条件：[连续2次检索质量不满足] → [Agent换用不同检索策略（如从FTS5切换为向量检索）]

1. 多策略检索：The Agentic RAG shall支持FTS5全文检索、LIKE模糊匹配、向量语义检索三种策略的自动切换

a. 验收条件：[FTS5检索无结果] → [自动切换为LIKE模糊匹配]

b. 验收条件：[LIKE检索结果过多] → [自动切换为向量语义检索精排]

1. 前置依赖：Where 实施Agentic RAG，the 知识库前后端必须已打通（Phase 0任务0c完成）

a. 验收条件：[Phase 0任务0c未完成] → [Agentic RAG不可实施，返回前置依赖提示]

##### 异常场景

1. 所有检索策略均无结果

a. 触发条件：FTS5、LIKE、向量检索均返回空结果

b. 系统行为：返回"未找到相关知识"提示，建议用户补充知识库

c. 用户感知：收到明确的无结果提示和知识库补充建议

#### 5.3.4 团队协作链 + 角色权限

##### 业务规则

1. 角色权限定义：The 系统shall定义老板、管理员、普通员工三种角色，每种角色有不同的操作权限

a. 验收条件：[普通员工尝试审批ECR] → [返回"权限不足"错误]

b. 验收条件：[老板审批ECR] → [审批成功，流程继续]

1. 团队协作链：The 系统shall支持跨角色协作链，如员工提交→主管审核→老板审批

a. 验收条件：[员工提交ECR] → [自动流转至主管审核，主管审核后流转至老板审批]

b. 验收条件：[主管驳回] → [流程回退至员工，附驳回原因]

1. 权限与记忆隔离：The Memory Service shall按角色隔离记忆数据，普通员工不可访问老板的心智模型

a. 验收条件：[普通员工查询心智模型] → [返回"无权访问"错误]

##### 异常场景

1. 协作链中断

a. 触发条件：协作链中某角色长时间未处理

b. 系统行为：超时提醒，可配置自动升级或跳过

c. 用户感知：收到"待处理任务超时提醒"通知

#### 5.3.5 企微对接探索

##### 业务规则

1. 企微"大圆"对接调研：The 系统shall调研企业微信"大圆"（AI助手）对接可行性，评估与BossAgents数字员工的集成方式

a. 验收条件：[调研完成] → [产出调研报告，包含对接方式、工作量估算、风险评估]

1. 企微消息通道：Where 企微对接可行，the 系统shall支持通过企微消息通道收发指令

a. 验收条件：[企微用户发送消息] → [BossAgents接收并处理，结果回传企微]

##### 异常场景

1. 企微API限制

a. 触发条件：企微API对消息频率或格式有限制

b. 系统行为：实现消息队列缓冲，遵守频率限制

c. 用户感知：消息回复有短暂延迟，功能正常

#### 5.3.6 自进化闭环UI化

##### 业务规则

1. 进化日志持久化：The RuleEvolution shall将进化日志独立持久化至sciot_evolution_logs表，不再仅依赖内存

a. 验收条件：[规则进化建议生成] → [sciot_evolution_logs表新增一条记录，含建议内容、状态、时间戳]

b. 验收条件：[服务重启后] → [进化日志完整保留，可查询历史进化记录]

1. 审批部署UI化：The 系统shall提供前端管理界面，支持规则进化建议的审批、部署、回滚操作

a. 验收条件：[管理员在前端查看进化建议列表] → [展示待审批/已审批/已部署状态的规则列表]

b. 验收条件：[管理员点击"审批通过"] → [规则自动部署至规则引擎，状态更新为"已部署"]

c. 验收条件：[管理员点击"回滚"] → [规则回退至上一版本，演化链记录回滚操作]

1. 演化历史可视化：The 系统shall在前端展示规则的完整演化历史，含supersedes链路

a. 验收条件：[查看某规则的演化历史] → [以时间线形式展示从创建到当前的所有版本变更]

##### 异常场景

1. 审批部署失败

a. 触发条件：规则部署至规则引擎时发生错误

b. 系统行为：自动回滚，保留原规则，记录失败日志

c. 用户感知：前端显示"部署失败"提示，原规则不受影响

6. 数据约束

6.1 原子事实（Atomic Fact）

1. factId：唯一标识，UUID格式，必填
2. tenantId：租户标识，关联tenant-middleware，必填
3. category：事实类别（supplier_preference / operation_habit / approval_preference / other），必填
4. value：事实值，字符串，必填，最大500字
5. confidence：置信度，0.0-1.0浮点数，默认0.5
6. source：来源（interaction / inference / manual），必填
7. createdAt：创建时间，ISO8601格式，必填
8. supersededBy：被哪个新事实替代，factId或null

6.2 用户画像（Identity Profile）

1. tenantId：租户标识，唯一键，必填
2. role：老板角色（decision_maker / technical_lead / operations_manager），默认decision_maker
3. industry：行业领域，字符串
4. frequentObjectTypes：常用对象类型列表，如["BOM", "ECR", "PurchaseOrder"]
5. approvalPreference：审批偏好（conservative / moderate / aggressive），默认moderate
6. preferredSuppliers：偏好供应商列表
7. lastUpdated：最后更新时间，ISO8601格式

6.3 会话摘要（Session Summary）

1. summaryId：唯一标识，UUID格式，必填
2. tenantId：租户标识，必填
3. sessionId：会话标识，关联ConversationManager，必填
4. topic：业务主题（BOM / 采购 / 变更 / 供应商 / 其他），必填
5. keyDecisions：关键决策列表，字符串数组
6. outcome：会话结果摘要，字符串，最大1000字
7. createdAt：创建时间，ISO8601格式，必填

6.4 心智模型（Mental Model）

1. tenantId：租户标识，唯一键，必填
2. riskPreference：风险偏好（conservative / moderate / aggressive），默认moderate
3. costSensitivity：成本敏感度（low / medium / high），默认medium
4. innovationWillingness：创新意愿（low / medium / high），默认medium
5. decisionPatterns：决策模式列表，字符串数组
6. lastAnalyzedAt：最后分析时间，ISO8601格式
7. analysisVersion：分析版本号，整数，递增

6.5 前瞻意图（Forward-looking Intention）

1. intentionId：唯一标识，UUID格式，必填
2. tenantId：租户标识，必填
3. predicted：预测的下一步需求，字符串，必填
4. confidence：置信度，0.0-1.0浮点数
5. basedOn：预测依据，字符串，描述历史模式
6. triggerCondition：触发条件，字符串
7. createdAt：创建时间，ISO8601格式
8. updatedAt：最后更新时间，ISO8601格式

6.6 演化链记录（Evolution Chain Entry）

1. entryId：唯一标识，UUID格式，必填
2. type：记录类型（fact / rule / profile），必填
3. refId：关联的事实/规则/画像ID，必填
4. action：操作类型（created / updated / superseded / rolled_back），必填
5. previousValue：变更前值，JSON字符串
6. newValue：变更后值，JSON字符串
7. supersedes：被替代的entryId，或null
8. timestamp：操作时间，ISO8601格式，必填

7. 需求追踪矩阵

Phase 0 — 前置修复

Phase 1 — 快速见效

Phase 2 — 深度增强

Phase 3 — 生态扩展

8. 统计摘要

| 指标 | 数值 |

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

| 需求总数 | 42 |

| P0 需求数 | 13 |

| P1 需求数 | 20 |

| P2 需求数 | 9 |

| 功能需求 | 35 |

| 安全需求 | 5 |

| 性能需求 | 2 |

| Phase 0 需求 | 6 |

| Phase 1 需求 | 15 |

| Phase 2 需求 | 17 |

| Phase 3 需求 | 13 |

注：性能需求分布在DFX约束章节（4.1节），未单独编号为REQ-ID，上述"性能需求2"指DFX中的性能约束条目。核心需求追踪矩阵中42条均为功能/安全类型。