企业级 Skills 市场建设方案 v1.1

—— TencentDB × 独立市场中枢 × QwenPaw 原生机制

承接 v1.0（post=87 / post=88 / post=89）的实测迭代版。
本版结合对 QwenPaw 源码的深度解读，收敛出「独立泛资产市场 + 双出口 + QwenPaw 原生机制复用」的最终架构，满足：独立市场、演进为 Skill/MCP/Agent 市场、抗 QwenPaw 升级。

一、背景与目标

企业需要一个跨部门的智能资产市场，核心诉求：

  • 财务发布技能（Skill）→ 授权给 人事使用
  • 领导通过统一入口查看全部资产、授权、审计
  • 资产类型从 Skill 起步，未来演进为 MCP 市场、Agent 市场
  • 方案必须不随 QwenPaw 升级而失效，可快速迭代复用

二、总体架构

Skills市场架构图

三层职责（清晰、不重叠）：

层 组件 职责
数据层 TencentDB Agent Memory 唯一权威数据源：Skill 本体、记忆、知识、对话、参与日志/统计、归属(team/owner)
治理层 独立市场（自建） RBAC 授权 + 泛资产目录 + 独立 UI + 领导驾驶舱 + 开放双出口
执行层 QwenPaw（可替换） 消费市场技能并执行，复用其原生技能池/治理/MCP 机制

三、为什么必须是「独立市场」（北极星）

参考此前讨论的决定性理由：

  1. 市场是平台本体，不是某个执行器的功能
  2. 未来要承载 Skill → MCP → Agent 的统一目录，市场必须独立演进
  3. 任何执行端（QwenPaw / 未来其他 Agent / MCP 客户端）都能接入，不被锁定
  4. 抗升级：市场核心与 QwenPaw 解耦，QwenPaw 升级只影响薄适配层

四、独立市场如何与 QwenPaw 双出口对接

市场对外提供两个稳定出口，与 QwenPaw 原生机制一一对应：

出口 协议 对应 QwenPaw 原生机制 用途
出口 A REST API market/providers/ Multi-Provider 注册为企业 Provider，QwenPaw 原生市场可搜索
出口 B MCP Server drivers/ MCP 集成 以标准 MCP 协议挂载，复用 tdai-mcp-bridge，铺路未来 MCP 市场

双出口为什么是"结合 QwenPaw 原生机制"而非"绕过"：

  • QwenPaw 自带 Multi-Provider 市场（market/providers/qwenpaw.py 即"GET 远程 skills API"）→ 我们的 REST 出口可注册为其一个 Provider
  • QwenPaw 自带 MCP 集成 → 我们的 MCP 出口可被挂载
  • QwenPaw 自带 技能池（skill_system/pool_service.py）→ 技能下载后进池执行
  • QwenPaw 自带 治理层（governance/）→ 市场 RBAC 管「谁能看」，QwenPaw 治理管「看到后怎么用」（双层）

五、TencentDB 在其中的角色（对比 v1.0 修正）

沿用 v1.0 实测结论，TencentDB 作为存储+检索+统计底座：

  • ✅ Skill CRUD / 检索 / 版本 / 归属（实测可用）
  • ✅ 全局管理（admin 看全部，领导驾驶舱直接复用）
  • ✅ 参与日志 / 固定资产统计（复用，减少自建表）
  • ❌ 跨团队授权：TencentDB 无授权接口 → 授权判定在独立市场业务层（RBAC）

关键：TencentDB 管「技能长什么样、存哪里、谁能全局看」，独立市场管「谁能看这个技能」。

六、权限模型（RBAC，在独立市场）

用户(User)        角色(Role)             权限(Permission)       资源(资产)
财务张三    →   publisher              publish/manage       Skill(自家team)
人事李四    →   hr_consumer            read/use              被授权 Skill
领导王五    →   system_viewer          audit/view_all         全资产
  • 授权判定唯一入口 = 市场业务层，admin key 不暴露前端
  • 每个 QwenPaw 持独立凭证（财务 key / 人事 key），市场据此识别身份

七、一次完整链路（财务发布 → 人事使用 → 领导监管）

① 财务在【独立市场】发布技能
    → 市场调 TencentDB skill/create，Skill 本体进 TencentDB（权威源）
    → 市场记 RBAC: skill_grants(财务→人事)
② 人事在【QwenPaw-人事】市场入口看到技能
    → QwenPaw 通过 REST Provider 或 MCP 调市场 API
    → 市场 RBAC 判定 → 返回"人事有权"的技能列表
③ 人事点"使用"
    → 技能内容从市场下发（来源 TencentDB）→ QwenPaw 本地导入技能池执行
    → QwenPaw 自带治理审计工具级使用
    → 使用计数回写 TencentDB 参与日志
④ 领导在【市场管理台】看全部
    → 市场聚合 TencentDB 全部技能 + 使用统计 → 驾驶舱

八、抗 QwenPaw 升级（防腐层设计）

市场核心(目录/RBAC/UI) ←—稳定—→ 开放API(REST+MCP) ←—薄适配—→ QwenPaw(易变)
  • 市场核心不 import 任何 qwenpaw 代码
  • QwenPaw 侧只保留薄适配层（Provider/MCP 注册，几十到上百行）
  • QwenPaw 升级 → 只排查/重写适配层（几小时），市场核心、数据、RBAC、UI 全不动
  • 用 契约测试（mock 市场 API）验证适配层在升级后是否断开

九、工作量评估（v1.1 修正）

模块 估算 说明
独立市场核心(目录/RBAC/API) 2-3 天 不含重UI
独立市场 UI(门户+领导驾驶舱) 2-3 天 必须独立建设
REST Provider 适配 0.5-1 天 照抄 qwenpaw.py 骨架
MCP Server 出口 0.5-1 天 复用 tdai-mcp-bridge
TencentDB 对接 0.5 天 已实测
契约测试 0.5-1 天 抗升级保障
合计 约 1.5-2 周

十、长期演进路线

阶段一   Skill 市场（当前）
   ↓
阶段二   接入 MCP 市场（复用出口 B + tdai-mcp-bridge）
   ↓
阶段三   Agent 市场（泛资产目录扩展 + 插件类目）

三层架构与双出口设计天然支撑以上演进，无需重构。

总结

v1.1 的关键收敛： 市场必须是独立北极星平台（满足独立市场 + 未来多资产演进 + 抗 QwenPaw 升级），通过 REST Provider + MCP Server 双出口 与 QwenPaw 原生机制结合，TencentDB 作为唯一权威数据底座。相比 v1.0，本版补齐了对执行端（QwenPaw）原生能力的深度理解，架构更通透、更易演进。

本方案基于 113.249.102.8 部署实例的 TencentDB API 实测与 agentscope-ai/QwenPaw 源码解读。