Skills 市场方案：质疑与完善

—— TencentDB Agent Memory 能力边界的诚实评估

性质：对原方案（post=87 & post=88）的批判性复审
方法：所有论断均基于部署于 113.249.102.8 的 TencentDB Agent Memory 真实 API 调测，非文档推演。
日期：2026-08-08

一、诚实结论：原方案的乐观判断需要降级

原方案结论（post=87）：「完全可以结合 TencentDB 完成，推荐用它作治理底座，2-3 天跑通最小闭环。」

质疑后修正结论： 做不到「开箱即用的跨部门精确授权」。 TencentDB 提供了 Skill 资产的存储、版本、检索、统计、全局管理员视图，但不提供"将某 skill 精确授权给某团队/某用户"的写入接口。原方案核心的「财务发布 → 人事使用 → 其余不可见」权限闭环，需要自研权限层才能实现。

评估分：7.5/10 → 5.5/10（作为"开箱即用"方案）。但作为"存储+检索底座"仍合格（8/10）。

二、质疑清单：逐条实测证据

🔴 质疑 1（致命）：Skill 没有「四档可见性」，也没有「授权接口」

原方案声称： Skill 有 private/team/restricted/agent 四档可见性，用 restricted 做「财务授权给人事」。

实测证据：

/* skill/get 返回的全部 16 个字段 */
["skill_id","name","description","version","is_head","status",
 "owner_user_id","owner_agent_id","team_id","task_id",
 "created_at_ms","updated_at_ms","content_hash","storage_dir","content","manifest"]

→ 没有 visibility，没有 scope，没有 permission。

Skill 完整 API 路由集（从 memory-core 日志提取）：

skill/add  skill/archive  skill/create  skill/delete
skill/detail  skill/extract  skill/get  skill/list
skill/search  skill/update

→ 没有任何 share / grant / authorize / permission 接口。

结论： TencentDB 没有"把技能授权给某部门/某用户"的能力。所谓"四档可见性"是文档推演的错误概念。

🔴 质疑 2（致命）：ACL 只能「校验」不能「授权」

原方案声称： 用 v3/meta/acl/check 实现授权。

实测证据：

  • v3/meta/acl/check 实测可用（返回 {"allowed":true,"reason":"owner"}）
  • 但它只回答"某人对某资产是否有权限"（校验/读取）
  • 没有配套的"设置 ACL 白名单"的写入接口
有 acl/check（验证权限）✅
无 acl/grant、acl/set、acl/authorize（赋予权限）❌

这就像有"查驾照"但没"发驾照"的地方。

🟡 质疑 3：asset.visibility 仅是只读标识，非授权规则

实测证据： asset/list-accessible 返回 assets 带 visibility: private/team，但这是资产创建时生成的元数据标识，不是可配置的授权规则，也没有接口能修改它。

🟢 质疑 4（站得住）：存储/检索/统计底座确实可用

能力 实测 结论
Skill CRUD create/get/list/search/update/delete 全通 ✅
全局管理 admin 可列全部 user/team/asset ✅ 领导全量可见成立
使用统计 asset.last_used_at + participation-log/list 存在 ✅ 数据模型有
归属隔离 skill 强绑 team_id，校验 team_mismatch ✅ 可防误跨团队
跨团队授权 无接口 ❌ 需自研

三、凭什么能落地的完善方案（修正后）

既然 TencentDB 是"存储+检索+统计"底座，但缺「授权」——那就在它的之上加一个轻量授权层，这正是方案 B（定制 Web 应用）的本意。关键是：授权规则不用 TencentDB 管，用我们自己的业务层管。

3.1 修正后的架构（授权在业务层）

┌─────────────────────────────────────────────────────────┐
│               Skills 市场门户（自研，授权之源）             │
│   权限数据存自己的 DB： skill_id ↔ 可访问的 team_id/user    │
│   ┌──────────┐  ┌──────────┐  ┌─────────────┐            │
│   │财务发布界面│  │人事使用界面│  │领导全局驾驶舱│（查全部） │
│   └────┬─────┘  └────┬─────┘  └─────┬───────┘            │
└────────┼─────────────┼──────────────┼────────────────────┘
         │  鉴权：查自研授权表        │
         ▼                          ▼
┌─────────────────────────────────────────────────────────┐
│  TencentDB AM（只做存储/检索，不承担授权判定）              │
│  · Skill 资产（owner/team_id/version/content/stats）      │
│  · 全局管理（admin 查全部）→ 领导视图直接复用               │
│  · 检索（skill/search）→ 市场搜索                          │
└─────────────────────────────────────────────────────────┘

核心转变： 从"靠 TencentDB 授权"改为"TencentDB 存技能，我们自己管谁能看"。

3.2 权限模型（自研授权层 + TencentDB 存储）

角色 界面 数据来源 授权判定
财务 发布工作台 skill/create（带 own team_id） 只能操作 own skill
人事 市场门户 skill/search + 自研授权表过滤 仅见被授权 skill
领导 全局驾驶舱 user/team/skill 全列 admin 全量（TencentDB 原生）
管理员 系统管理 全部 admin

自研 skill_grants 授权表（必须建）：

-- 这是 TencentDB 没有、必须自研的核心表
CREATE TABLE skill_grants (
  id INT AUTO_INCREMENT PRIMARY KEY,
  skill_id   VARCHAR(64) NOT NULL,      -- TencentDB skill_id
  grantee_type ENUM('team','user','role'),
  grantee_id   VARCHAR(64) NOT NULL,    -- team-xxx / usr-xxx
  permission   ENUM('read','use','manage') DEFAULT 'use',
  granted_by   VARCHAR(64),
  created_at   DATETIME,
  UNIQUE KEY uq (skill_id, grantee_type, grantee_id)
);
  • 财务发布时：INSERT skill_grants SET skill_id='新skill', grantee_type='team', grantee_id='hr-team'
  • 人事浏览时：SELECT * FROM skill WHERE skill_id IN (SELECT skill_id FROM skill_grants WHERE grantee_id=我的team)
  • 领导视图：直接 skill/list（admin）不看 grants

3.3 使用统计：复用 or 自建

  • 复用：asset.last_used_at（TencentDB 原生记录最近使用）
  • 自建（推荐做）：skill_usage_logs 表记录每次加载，因为 participation-log 实测暂无数据，且不能保证覆盖所有访问路径
CREATE TABLE skill_usage_logs (
  id INT AUTO_INCREMENT PRIMARY KEY,
  skill_id VARCHAR(64), user_id VARCHAR(64), team_id VARCHAR(64),
  action VARCHAR(32), -- load / use / fail
  session_id VARCHAR(128), called_at DATETIME
);

3.4 部署与装配

  • TencentDB 角色：只存技能 + 提供搜索/统计/领导全局列表
  • 门户：Node/Vue 自研，连 TencentDB API + 自建 MySQL 授权库
  • 运行层：授权后，从 TencentDB skill/get 取 SKILL.md 内容，同步到 QwenPaw 的 skill_paths 目录（运行层仍需 QwenPaw 或类似 Agent 执行）

四、工作量与技术风险（修正后）

模块 现在能否开箱 需开发量
Skill 存储/版本/搜索 ✅ TencentDB 0
领导全局查看 ✅ admin 0-1 天（界面包装）
财务发布 ✅ skill/create 0.5 天（界面）
跨部门授权 ❌ 自研 2-3 天（grants 表+接口）
人事市场门户 ⚠️ 半自研 3-4 天
使用统计 ⚠️ 半自研 1-2 天
领导驾驶舱 ✅ 1 天
合计 约 2-3 周

主要风险

风险 说明 应对
授权层绕过 若直接调 TencentDB API 可绕过门户授权 门户是唯一入口；admin key 不透出
skill name 中文 实测仅 [a-z0-9-] 加 display_name 映射
team 强绑定 skill 只能归一个 team 跨团队需靠自研 grants，TencentDB 层天然隔离
无删除接口(下游) emlog 无删除 本项目 TencentDB 有 delete，OK

五、最终判定

维度 评分 说明
存储/检索底座 8/10 TencentDB 完全够用
领导全局可见 9/10 admin 原生支持
跨部门精确授权 2/10 TencentDB 无此能力，必须自研
开箱即用程度 5.5/10 核心闭环需自研授权层

总结论：

  1. "完全靠 TencentDB 开箱即用"——不成立，必须自研授权层（2-3 天）。
  2. "TencentDB 作为技能存储+检索+治理底座"——成立，且是合适的底座。
  3. 方案 B（定制门户）正确，但要清醒： 权限判定在门户，不在 TencentDB。

这不是否定 TencentDB，而是把它放对位置： 它管"技能长什么样、存哪里、谁能全局看"，我们管"谁能看这个技能"。

所有 API 论断均有 113.249.102.8 实测支撑。