企业级 Skills 市场建设方案

—— 从「2 天跑通最小闭环」到「完整治理平台」的两条路径

版本:v2.0(合并版)|日期:2026-08-30

一句话结论:财务发布、人事使用、领导全量可见——这个诉求不需要从零自研。TencentDB Agent Memory 的 Skill 资产体系天然提供「发布、审核、授权、版本、统计、权限」整套市场治理能力,2~3 天即可跑通最小闭环;若后续需要独立门户与深度定制,再演进到自研 Marketplace API 的重方案。

一、需求背景

1.1 四大痛点

企业内部的 AI Agent 能力正在快速普及,各部门(财务、人事、行政、研发……)都开始沉淀自己的 Agent 技能(Skill)。随之而来的管理问题:

  1. 技能散落:每个 Agent 工作区各有一份技能副本,没有统一的发布渠道,优秀实践无法跨部门复用。
  2. 权限模糊:财务沉淀的「发票核验 / 报销审核」技能,需要开放给人事使用,但绝不能开放给无关人员;目前缺少按「发布者 → 使用者 → 管理者」分层的授权机制。
  3. 领导不可见:管理层需要看到「企业里到底有哪些技能、谁在用、用得怎么样」,目前没有全局视图。
  4. 无版本与审计:技能改版、下架、使用记录都无从追溯,无法满足合规要求。

1.2 目标角色(最小闭环)

角色诉求权限边界
财务(发布者)把自己的技能发布到市场,开放给人使用创建、发布自己的技能;撤销、下架;查看自己技能的使用情况
人事(使用者)在市场上浏览、申请、使用财务等部门的技能浏览市场;使用被授权的技能;查看自己已订阅的技能
领导(管理者)看到全部技能、全量使用统计、全局管控查看全部技能与使用数据;审核发布;强制下架;账号与团队管理
管理员(系统)平台运维System Admin:用户、团队、全局配置

1.3 现状盘点:我们已经具备什么

在动手之前,先盘点已经跑通的基础设施——这决定了轻路线为什么能这么快。

已具备能力当前状态在市场方案中的角色
TencentDB Agent Memory已部署可用,Team team-ovdu9w8v2f,L0~L3 四层记忆完整治理底座:技能资产库、权限、版本、审计
本地技能库8 个已沉淀技能(emlog-blog-publisher、gitea-publish、authon-sync 等)种子资产:可直接作为首批上架技能试点
自建 Gitea已运行,https://gitea.apescale.com 可访问分发渠道:替代对象存储,技能包走 Git 版本化分发
自建模型服务vLLM + New API 网关运行中(Qwen3.8-27B)AI 底座:自然语言检索、技能推荐的模型支撑
自动化发布链路emlog-blog-publisher 技能已打通 API 发布能力验证:证明「技能 → 外部系统」的 MCP 桥接模式可行

这意味着:治理中枢、分发渠道、AI 底座、种子资产四样都已就位,缺的只是「把它们串起来的装配层」。这正是轻路线能在 2~3 天跑通的原因。

二、方案选型:两条路线

同一个目标,有轻重两条实现路径。它们不是互斥关系,而是演进关系。

2.1 轻路线:复用 Agent Memory 原生治理

核心思路:不做市场,而是把 Agent Memory 的 Memory Hub 当作市场后台来用——它默认服务于团队记忆,我们把它聚焦到 Skill 资产上做企业级治理。

  • 治理层:TencentDB Agent Memory(发布、审核、版本、授权、统计、审计)
  • 运行层:QwenPaw / WorkBuddy(技能实际加载与调用)
  • 打通方式:OpenAPI / SDK / 外部技能根目录

周期:2~3 天跑通最小闭环,无需自研后端。

2.2 重路线:自研 Marketplace API

核心思路:独立建设市场服务,自主研发注册中心、权限管控、审批工作流与使用分析,数据存储落到 TencentDB MySQL。

  • 数据层:TencentDB MySQL(7 张表:部门/用户/技能/版本/权限/审批/日志)
  • 服务层:自建 Marketplace API + 对象存储
  • 接入层:自研 MCP Server(10 个工具)桥接 WorkBuddy

周期:7~12 周全量上线,可完全定制门户与流程。

2.3 对比与推荐

维度轻路线(Agent Memory 原生)重路线(自研 Marketplace)
上线周期2~3 天最小闭环7~12 周全量
开发量装配与配置为主后端 + 门户 + MCP 全栈自研
权限模型复用原生四档可见性 + ACL自定义 RBAC,可任意扩展
门户定制用 Hub 原生界面或轻量包装完全自主设计
审计能力原生记录使用次数/版本/状态自定义审计字段与报表
运维成本低(跟随开源版本升级)高(需自建团队维护)
适用阶段验证期 / 中小规模规模期 / 强定制需求

推荐策略:先轻后重。第一阶段用轻路线 2~3 天跑通「财务发布 → 人事使用 → 领导全量可见」的最小闭环,用真实使用数据验证需求;确认价值后,再按需把数据模型迁移到自建 MySQL,演进到重路线。轻路线沉淀的资产与权限设计可平滑迁移,不会浪费。

三、为什么是 TencentDB Agent Memory:能力对照

TencentDB Agent Memory(腾讯云开源,MIT 协议,可本地部署、零外部 API 依赖、框架中立)本身就是一套「团队记忆中枢」,其中 Skill 资产 与我们要建的 Skills 市场高度同构:

市场需求TencentDB Agent Memory 原生能力
技能作为独立资产管理Skill 是四大资产之一(Chat Memory / Skill / Wiki / CodeGraph),带版本、资源文件、触发边界、执行步骤、验证规则
发布者拥有技能每项资产记录 Owner,Owner 自动拥有管理权限
谁可以用四档可见性:private(仅本人)/ team(团队内可见)/ restricted(用户/角色/Agent ACL 精确授权)/ agent(定向装备给指定 Agent)
领导全量可见System Admin(全局管理员) 可管理用户、团队,并使用全部资产管理功能
审核与管控Memory Hub 提供资产的生成、审核、授权、分享、装配闭环
使用统计资产记录使用次数、使用记录、版本、状态,可追溯
跨框架复用资产与 Agent 框架解耦,可装配给 OpenClaw、QwenPaw、Claude Code、CodeBuddy 等

一句话:TencentDB Agent Memory 的 Memory Hub 就是现成的「技能市场后台」,只是它默认服务于团队记忆,而我们把它聚焦到 Skill 资产上做企业级治理。

四、总体架构

┌─────────────────────────────────────────────────────────────┐
│                    用户层(前端入口)                         │
│   财务 / 人事 / 领导 / 管理员                                 │
│   ┌──────────┐   ┌──────────┐   ┌───────────┐                │
│   │ 发布工作台 │   │ 市场门户  │   │ 管理驾驶舱 │                │
│   └────┬─────┘   └────┬─────┘   └─────┬─────┘                │
└────────┼──────────────┼───────────────┼──────────────────────┘
         ▼              ▼               ▼
┌─────────────────────────────────────────────────────────────┐
│             治理层:TencentDB Agent Memory                   │
│   Memory Hub(控制台)                                        │
│   · 团队 / 用户 / 角色管理(System Admin ↔ Team Admin/Member)│
│   · Skill 资产库(版本 / Owner / 状态 / 可见性 / ACL)         │
│   · 审核流(草稿 → 待审 → 已发布 → 已下架)                    │
│   · 使用统计与审计日志                                         │
│   MemoryCore(记忆/资产核心)  MemoryKnowledge(OpenAPI)      │
└────────────────────────┬────────────────────────────────────┘
                         ▼  OpenAPI / SDK / MCP 装配
┌─────────────────────────────────────────────────────────────┐
│             运行层:QwenPaw / WorkBuddy(多 Agent)           │
│   技能池 skill_pool / 外部技能根目录 skill_paths              │
│   ├─ 财务 Agent 工作区  ── 装载「财务发布」的技能             │
│   ├─ 人事 Agent 工作区  ── 装载「被授权」的技能               │
│   └─ 领导 Agent 工作区  ── 装载「全部只读」视图               │
└─────────────────────────────────────────────────────────────┘

三层职责:

  • 治理层(TencentDB Agent Memory):技能的「市场」本体——发布、审核、版本、授权、统计、审计都在这里完成。数据存于腾讯云数据库,本地部署保证数据不出企业。
  • 运行层(QwenPaw / WorkBuddy):技能的「运行」本体——被授权的技能以 SKILL.md 形式落到对应 Agent 工作区,Agent 在对话中实际调用。
  • 用户层(前端):可以是 Memory Hub 原生界面 + 少量定制(品牌、目录、申请流),也可以单独做轻量门户对接 OpenAPI。

4.1 职责分层(重路线视角)

层级组件职责
用户角色层发布者 / 消费者 / 管理员不同角色拥有不同操作权限
执行引擎层WorkBuddy 客户端本地技能加载、SKILL.md 解析、脚本执行、MCP 桥接
市场管理层Marketplace API技能注册中心、权限管控、审批工作流、使用分析
数据存储层TencentDB MySQL + Agent Memory结构化数据存储 + AI 智能发现

五、权限模型:角色 × 可见性 × ACL

5.1 角色映射

业务角色TencentDB AM 映射权限说明
财务(发布者)Skill 资产 Owner可创建/编辑/发布/下架自己的技能;对自有资产自动拥有管理权
人事(使用者)Team Member + restricted ACL可浏览市场;仅能使用被授权的技能(如财务开放的「发票核验」)
领导(管理者)System Admin(或跨团队 Admin)查看全部 Skill 资产、使用统计、审核流;可强制下架、调整授权
管理员System Admin用户、团队、全局配置、容量

5.2 可见性四档语义(直接复用原生能力)

  • private:技能仅财务本人可见(草稿期默认)。
  • restricted:通过 ACL 精确授权给「人事团队」或「人事角色」——这是「财务发布给人事用」的落地方式。
  • agent:定向装备——「发票核验」技能只装进人事的报销 Agent,不装进其他 Agent。
  • team:团队内共享,适合财务团队内部互用。

领导的「全量可见」由 System Admin 角色天然保证;同时可通过跨团队 Admin 或全局只读视图实现,无需额外开发。

5.3 操作权限矩阵(重路线自定义时参考)

操作PublisherConsumerAdminSuper Admin
浏览公开技能✓✓✓✓
浏览本部门技能✓✓✓✓
浏览所有技能✗✗✗✓
创建技能✓(本部门)✗✓✓
安装技能✓✓✓✓
审批技能✗✗✓(本部门)✓
设置权限✗✗✓(本部门)✓
归档/下架技能✗✗✓(本部门)✓
查看使用统计自己的技能✗✓(本部门)✓

六、数据模型

6.1 轻路线:最小表集合

腾讯云数据库(TDSQL-C / MySQL)中建议的最小表集合:

skills           技能主表:id, name, slug, owner_id, team_id,
                  category, description, version, status,
                  visibility(enum), created_at, updated_at
skill_versions   版本表:skill_id, version, file_uri(SKILL.md 存储位置),
                  changelog, created_by, created_at
acl              授权表:skill_id, grantee_type(user/role/team/agent),
                  grantee_id, perm(read/use/manage), granted_by, created_at
subscriptions    订阅/装备表:skill_id, agent_id/workspace_id,
                  install_status, installed_at, synced_at
usage_logs       使用日志:skill_id, agent_id, user_id, session_id,
                  called_at, result_status
audit_logs       审计日志:asset_id, actor, action, detail, ts

6.2 重路线:完整 DDL

-- 部门表
CREATE TABLE departments (
    id          INT PRIMARY KEY AUTO_INCREMENT,
    name        VARCHAR(100) NOT NULL,
    parent_id   INT DEFAULT NULL,
    sort_order  INT DEFAULT 0,
    created_at  TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 用户表
CREATE TABLE users (
    id          INT PRIMARY KEY AUTO_INCREMENT,
    name        VARCHAR(100) NOT NULL,
    email       VARCHAR(200) UNIQUE NOT NULL,
    dept_id     INT NOT NULL,
    role        ENUM('publisher', 'consumer', 'admin', 'super_admin') DEFAULT 'consumer',
    status      ENUM('active', 'disabled') DEFAULT 'active',
    created_at  TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (dept_id) REFERENCES departments(id)
);

-- 技能表
CREATE TABLE skills (
    id            INT PRIMARY KEY AUTO_INCREMENT,
    name          VARCHAR(100) NOT NULL,
    description   TEXT,
    category      VARCHAR(50),          -- 技能分类
    publisher_id  INT NOT NULL,         -- 发布者
    dept_id       INT NOT NULL,         -- 发布部门
    status        ENUM('draft', 'pending', 'published', 'archived', 'rejected') DEFAULT 'draft',
    current_ver   VARCHAR(20) DEFAULT '1.0.0',
    skill_pkg_url VARCHAR(500),         -- 技能包下载地址
    tags          VARCHAR(500),         -- 逗号分隔标签
    created_at    TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at    TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    FOREIGN KEY (publisher_id) REFERENCES users(id),
    FOREIGN KEY (dept_id) REFERENCES departments(id)
);

-- 技能版本表
CREATE TABLE skill_versions (
    id            INT PRIMARY KEY AUTO_INCREMENT,
    skill_id      INT NOT NULL,
    version       VARCHAR(20) NOT NULL,
    changelog     TEXT,
    pkg_url       VARCHAR(500),
    published_by  INT NOT NULL,
    published_at  TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (skill_id) REFERENCES skills(id),
    FOREIGN KEY (published_by) REFERENCES users(id)
);

-- 权限规则表
CREATE TABLE skill_permissions (
    id          INT PRIMARY KEY AUTO_INCREMENT,
    skill_id    INT NOT NULL,
    scope_type  ENUM('dept', 'role', 'user', 'public') NOT NULL,
    scope_id    INT,                    -- dept_id / role / user_id
    permission  ENUM('view', 'install', 'use') DEFAULT 'use',
    FOREIGN KEY (skill_id) REFERENCES skills(id)
);

-- 审批记录表
CREATE TABLE skill_reviews (
    id           INT PRIMARY KEY AUTO_INCREMENT,
    skill_id     INT NOT NULL,
    version      VARCHAR(20) NOT NULL,
    reviewer_id  INT NOT NULL,
    action       ENUM('approve', 'reject', 'request_changes') NOT NULL,
    comment      TEXT,
    reviewed_at  TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (skill_id) REFERENCES skills(id),
    FOREIGN KEY (reviewer_id) REFERENCES users(id)
);

-- 使用日志表
CREATE TABLE usage_logs (
    id           BIGINT PRIMARY KEY AUTO_INCREMENT,
    skill_id     INT NOT NULL,
    user_id      INT NOT NULL,
    action       ENUM('view', 'install', 'execute', 'uninstall') NOT NULL,
    metadata     JSON,                  -- 调用上下文
    created_at   TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_skill (skill_id),
    INDEX idx_user (user_id),
    INDEX idx_time (created_at)
);

七、生命周期与审批流

7.1 状态机

┌────────┐   提交审核    ┌─────────┐   审核通过    ┌───────────┐
│ Draft  │ ───────────> │ Pending │ ───────────> │ Published │
│  草稿   │              │  待审核  │              │   已发布   │
└────────┘              └─────────┘              └───────────┘
     ▲                       │                         │
     │                       │ 驳回                     │ 下架
     │                       ▼                         ▼
     │                 ┌──────────┐              ┌──────────┐
     └─────────────────│ Rejected │              │ Archived │
        修改后重新提交    │  已驳回   │              │  已归档   │
                       └──────────┘              └──────────┘
                                                        │
                                                        ▼
                                                 触发已安装端回收

每个状态切换都记录操作人、时间、原因,形成审计链。

7.2 审批工作流五步

步骤 1:技能创建(Publisher)
财务部用户在 WorkBuddy 中编写 SKILL.md 和相关脚本。本地测试通过后,通过 MCP Server 调用 POST /api/skills 提交技能到市场。技能状态为 draft。

步骤 2:提交审批(Publisher)
发布者填写技能描述、分类、目标受众、权限范围,提交审批。状态变为 pending。系统自动通知对应部门的 Admin 角色。

步骤 3:审批审核(Admin)
部门领导收到通知后,查看技能内容、测试技能功能、确认权限设置。可选择:

  • 通过:技能状态变为 published,对授权用户可见
  • 驳回:附备注返回给发布者修改,状态变为 rejected
  • 请求修改:发布者修改后重新提交

步骤 4:版本更新(Publisher)
已发布技能可提交新版本。新版本需重新审批,审批期间旧版本继续可用。审批通过后自动切换。

步骤 5:归档/下架(Admin / Super Admin)
过时或有问题的技能可归档,已安装用户收到通知。归档技能不可新安装,但已安装的可继续使用(带警告提示)。

八、运行层装配:技能如何落到 Agent 工作区

被授权后,技能以标准 SKILL.md 进入运行体系,三种路径按需选择:

  1. 外部技能根目录 skill_paths(推荐,适合共享池)
    在 QwenPaw config.json 中登记团队共享技能目录(如 /opt/team/skills),
    TencentDB AM 授权后把 SKILL.md 同步进该目录,相关工作区即可按需载入。
  2. 技能池 + 广播 / 自动同步
    将技能放入 skill_pool/,开启「自动同步」并指定关联智能体(如人事 Agent),
    池内容变更自动下发到已安装工作区——适合版本化分发。
  3. CLI 安装
    qwenpaw skills install <skill_url> --agent-id hr_agent,适合按需、一次性安装。

配合 SKILL.md 的 metadata.requires(如 env:)与 Skill Config 注入,
可以把财务技能的密钥/参数与人事工作区隔离,避免敏感配置跨部门泄露。

九、MCP Server 集成设计(重路线)

在 WorkBuddy 与 Marketplace API 之间,通过自定义 MCP Server 桥接。该 MCP Server 复用现有 tencentdb-memory MCP 的架构模式(StdioServerTransport + HTTP 转发)。

9.1 工具清单

工具名方法说明
skill_market_searchGET搜索市场技能(关键词/分类/标签)
skill_market_publishPOST提交技能到市场(含元数据和包路径)
skill_market_installPOST从市场安装技能到本地
skill_market_updatePUT更新已发布技能的新版本
skill_market_listGET列出用户可见的技能
skill_market_detailGET获取技能详情(含版本历史)
skill_market_reviewPOST审批技能(Admin 专用)
skill_market_statsGET查看使用统计(Admin 专用)
skill_market_recommendGETAI 推荐技能(Agent Memory 驱动)
skill_smart_searchGET自然语言技能搜索(Agent Memory 驱动)

9.2 配置示例

{
  "skill-marketplace": {
    "command": "node",
    "args": ["/Users/figmarlite/.workbuddy/mcp-servers/skill-marketplace/index.mjs"],
    "env": {
      "MARKETPLACE_API_URL": "https://api.apescale.com/skill-market",
      "TDB_MYSQL_HOST": "gz-cdb-xxxxx.sql.tencentcdb.com",
      "TDB_MYSQL_PORT": "63306",
      "TDB_MYSQL_DB": "skill_market",
      "TDB_MYSQL_USER": "skill_admin",
      "TDB_MYSQL_PASS": "********",
      "TDB_MEM_SERVICE_ID": "default",
      "TDB_MEM_USER_KEY": "sk-mem-xxxxx",
      "TDB_MEM_TEAM_ID": "team-xxxxx"
    },
    "disabled": false
  }
}

十、实施路径

10.1 轻路线:四阶段(约 1 周)

阶段一:部署与初始化(约 0.5~1 天,已有基础)

  • 复用已部署的 memory-core(:8420)、memory-hub(:8125/:8424)、proxy(:8096)。
  • 启动 MemoryKnowledge(:8421),获得 Knowledge OpenAPI / MCP 桥接能力。
  • 创建团队结构:Finance Team(财务)、HR Team(人事)、Leadership(领导只读)。

阶段二:Skill 资产化试点(1~2 天)

  • 选 1~2 个财务技能(如发票核验)上架,走完「草稿→审核→发布→ACL 授权→装配到人事 Agent」闭环。
  • 验证运行层三种装配路径,确定主路径(建议 skill_paths 或技能池自动同步)。

阶段三:门户定制(3~5 天,可选)

  • 用 Knowledge OpenAPI 包一层轻量市场门户(浏览、搜索、申请、我的技能、领导驾驶舱)。
  • 数据落腾讯云数据库(TDSQL-C),见 6.1 表设计。

阶段四:治理与推广

  • 固化审核 SLA、下架/回收流程、使用统计周报(自动推送给领导)。
  • 推广到更多部门,形成企业级技能资产目录。

10.2 重路线:五阶段(7~12 周)

阶段周期关键交付
Phase 1 基础设施1~2 周TencentDB MySQL 建表、Team/Agent 初始化、Marketplace API 骨架、对象存储配置
Phase 2 MCP Server1~2 周10 个工具实现、对接 MySQL 与 Agent Memory、WorkBuddy 注册
Phase 3 核心功能2~3 周发布→审批→安装全流程、权限校验与部门隔离、使用日志、管理员手册
Phase 4 AI 增强2~3 周L1 技能特征提取、自然语言搜索、上下文推荐、L3 部门画像
Phase 5 管理看板1~2 周Web 管理界面、领导全局视图、审批待办通知

十一、风险与注意事项

风险应对
财务技能含敏感规则/密钥用 SKILL.md requires.env + Skill Config 注入隔离;密钥存环境变量/密钥管理,不写入技能文件
跨部门误授权默认 private,授权走显式 ACL + 审核;定期审计授权清单
技能版本回滚利用版本表 + 技能池自动同步的变更检测,出问题可回滚到上一版本
MemoryKnowledge 未启用导致 API 缺口阶段一必须补启动,作为 OpenAPI 出口
运行层残留旧版本用「自动同步 + 指定关联智能体」精确下发,下架时同步移除
权限校验遗漏(重路线)所有请求过中间件:解析 JWT → 查 skill_permissions → 校验 dept_id → 拒绝时记审计日志

十二、典型场景

场景 A:财务发布「发票核验」→ 人事使用(轻路线)

  1. 财务在 Memory Hub 创建 Skill 资产「发票核验」(含 SKILL.md + 校验脚本),状态 private。
  2. 财务提交审核 → 领导/管理员在 Hub 通过 → 状态 published,可见性设为 restricted。
  3. 财务(或管理员)在 ACL 中把该技能授权给「人事团队 / 人事报销 Agent」。
  4. 系统通过 OpenAPI / SDK 将 SKILL.md 推送到人事 Agent 工作区(或 skill_paths 共享目录)。
  5. 人事在对话中直接使用:Agent 加载该技能,执行发票核验;财务可查看使用统计。

场景 B:领导查看全部技能

  1. 领导以 System Admin 登录 Memory Hub(或定制驾驶舱)。
  2. 资产库 → Skill → 按团队/状态/分类筛选,看到全部技能(财务、人事、其他部门)。
  3. 查看每个技能的使用次数、最近使用时间、版本、授权范围。
  4. 发现违规技能 → 一键下架,并触发运行层回收(自动同步移除)。

场景 C:自然语言发现技能(AI 增强)

  1. 人事部用户说:「我需要计算员工个税」。
  2. Agent Memory 通过 skill_smart_search 匹配 L1 层技能特征标签。
  3. 返回推荐:「找到财务部发布的『个税计算器』技能,是否安装?」
  4. 用户确认安装,MCP Server 调用 skill_market_install,技能包下载到本地,立即可用。

场景 D:AI 智能推荐的四种能力

  • 自然语言检索:基于 L1/L2 层记忆语义匹配,无需记住技能名称。
  • 上下文推荐:基于 L2 场景记忆 + L3 核心记忆,按当前任务主动推荐(如处理薪酬时推荐「个税计算器」)。
  • 跨部门发现:查询其他 Team 的公开 Block,发现可复用技能。
  • 使用模式分析:L0→L1→L2→L3 逐层提炼,形成部门级技能画像,供领导决策。

十三、总结与展望

结论:完全可以结合 TencentDB 完成,且推荐用 TencentDB Agent Memory 作为治理底座——它把「发布、审核、授权、版本、统计、权限」这些市场核心能力做成了原生能力,无需从零开发。

核心优势:

  • 角色隔离:发布者/消费者/管理员三层权限模型,满足企业管理需求
  • 审批管控:完整的技能生命周期管理,发布前需审批
  • AI 增强:自然语言搜索和智能推荐,降低技能发现门槛
  • 数据驱动:使用日志和分析看板,为管理决策提供依据
  • 无缝集成:通过 MCP Server 与 WorkBuddy 深度集成,用户体验自然

为什么推荐「先轻后重」:这是一条「用现成的开源治理中枢 + 现成的 Agent 运行框架拼装企业级 Skills 市场」的低成本路线。最小闭环(财务发布 → 人事使用 → 领导全量可见)在 2~3 天内即可跑通,用真实数据验证价值后,再按需扩展门户与治理能力,避免一开始就陷入 7~12 周的自研投入。

后续演进方向:

  • 技能评分和评论系统
  • 技能依赖管理(技能 A 依赖技能 B)
  • 跨组织技能交换(子公司间共享)
  • 技能自动化测试和合规扫描
  • 基于使用数据的技能质量评估和自动推荐排序

本文基于 TencentDB Agent Memory 公开资料与实际部署环境整理,落地时以实际版本为准。