WorkBuddy 扩展体系学习需求梳理报告

会话时间：2026-09-07 16:46 – 21:22
整理说明：按主题归类（非时间罗列），合并重复表述；仅复述用户原意，助手主动附加的建议已在文中明确标注，不计入用户需求。

一、需求全景与演进脉络

本次会话共提出 16 个问题，全部围绕一个中心：理解 WorkBuddy 的扩展体系（Skills / 插件 / 连接器 / MCP / 专家）。没有提出任何具体的业务交付需求。

提问呈明显的四阶段演进：

阶段	关注点	对应主题
1. 概念入门	Skills 是什么、长什么样	主题 1
2. 运行机制	怎么加载、怎么触发、占多少资源	主题 2
3. 生态关系	连接器、MCP、插件、专家如何区分和关联	主题 3、5
4. 创建与定位	怎么创建、壳与内容的关系、命名逻辑、架构位置	主题 4、6

问题归档清单

#	问题原述（摘要）	归入主题
1	什么是 Skills？包含什么样的步骤？	主题 1
2	有没有制造和发现 skills 的 skills？我装了哪些类似的？各有何特点？	主题 4
3	Skills 创建后能直接用吗？连接器是什么、与 skills 的逻辑关系？skills 和 MCP 的关系？	主题 2、3
4	MCP 服务器的表现形式是"环境 + 工具定义文件 + JS 代码"吗？腾讯连接器就是这个吗？请区分插件、MCP、应用、连接器、技能、PR（输入输出、架构、数据流转）	主题 3
5	Skills 里面是不是也有业务逻辑的代码文件？	主题 1
6	MCP 工具定义是打开应用就加载吗？MCP 越多越臃肿？Skills 只占两行、命中才调用？	主题 2
7	未启用某项技能时，对话命中语义匹配也会调用吗？	主题 2
8	创建技能和创建插件的流程差别？Codex 的插件就是 WorkBuddy 的专家吗？	主题 4、5
9	插件比 skills 多出的是声明文件和头像吗？skills 只能开源、插件可闭源？	主题 4
10	插件封装多种技能，那"壳"是什么？	主题 4
11	插件是 skills 合集？skills 整合到 agents 角色 md 上？commands、bin/dist 能出现在专家插件里吗？agent 智能体和插件的区别？	主题 4
12	"expertType 为 agent 的插件"——agent 是插件的名称吗？expertType 是 Codex 的 plugin type 吗？	主题 5
13	为什么用"专家"而不用"插件"这个术语？请重新梳理专家、技能、连接器三者在我与大模型交互时的逻辑位置	主题 6
14	专家（身份声明 md）+ 技能（接口调用、工作流）加起来就是一个插件吗？	主题 4
15	agents/ 里是什么文件？技能独立可复用是什么意思？专家的壳可以套不同技能组合吗？举例	主题 4
16	本梳理要求	—

二、主题详述

主题 1：Skills 的本质与构成

提出背景：会话起点，首次接触该概念，需要从零建立认知。
核心诉求：搞清楚 Skill 的定义、文件构成、内部步骤写法，以及代码在其中的位置。
具体问题：#1、#5
用户明确给出的约束：无（纯概念提问，未限定技术栈或范围）。
已获结论：
- Skill = 一个文件夹：必需的 SKILL.md（YAML frontmatter + 分步骤指令）+ 可选的 scripts/、references/、assets/；
- 内部步骤的惯用结构：适用范围、前置条件、分步流程、输出规范、示例、避坑提示；
- 代码是可选加速器：同一段逻辑反复重写、或需要确定性输出时才固化进 scripts/；脚本可不读入上下文直接执行；
- 本机实证：34 个已装技能中 17 个带代码，ppt-generator 含 5 个 13–17KB 的业务脚本。
待确认问题：无（本主题已闭环）。

主题 2：Skills 与 MCP 的运行机制（加载、触发、成本）

提出背景：了解构成后，自然追问"装了之后怎么生效、何时被调用、占多少资源"。
核心诉求：厘清加载与触发机制；评估多装/多开的资源代价。
具体问题：#3 前半、#6、#7
用户明确给出的前置理解（提出待验证）：
- "MCP 工具定义常驻，大模型开一个占一份，打开 WorkBuddy 时就打开了吧"；
- "Skills 只需两行文字，需要时命中名称才调用"。
已获结论（含本机实证）：
- MCP 是启用才加载，非打开应用即加载；本机 connector-states.json 中 enabled: []，当前会话常驻 23 个 MCP 工具（agent-mail 11、sheetagent 9、weixinpay 3）；
- MCP 增多的代价是上下文挤占与工具选择准确率下降，非程序卡顿；原则：只开当下要用的；
- Skills 默认开启、常驻仅两行索引、语义命中才加载全文；description 有长度上限（约 1024 字符）；
- 用户原理解"Skills 两行、命中才调用"基本正确，已确认。
待确认问题：
- munger-perspective、luoyonghao-perspective 处于关闭状态（skillOverrides: off），是否恢复待用户定夺。

主题 3：扩展生态概念辨析（连接器 / MCP / 插件 / 应用 / PR）

提出背景：Skills 之外出现一批相邻概念，边界不清，要求系统性厘清。
核心诉求：建立完整概念地图；明确要求用"输入输出 + 整体架构 + 数据流转"的机制性框架解释，而非泛泛类比。
具体问题：#3 后半、#4
用户明确给出的前置理解（提出待验证）：
- "MCP 服务器 = 运行环境（docker/Debian）+ 声明工具定义的文件 + JS 逻辑代码"；
- "腾讯连接器 = 环境 + 代码 + 工具定义的文档"。
已获结论：
- 修正：MCP 是一份 JSON-RPC 协议；服务器是可读写 stdio 的进程或 HTTP 端点，无需容器；工具定义是运行时通过 tools/list 动态返回的 JSON，不是静态文件；
- 连接器 = MCP 服务器 + OAuth 授权 + 配套 Skills 的打包开关；本机飞书连接器带 30+ 个 lark-* 技能；
- 六层架构：应用 → 技能 → 连接器 → 插件 → MCP 协议 → 进程/远端；
- 数据流：用户请求 → 模型（结合 Skill）→ MCP 工具（tools/call）→ 外部系统 → 结构化结果原路返回；
- PR 不在运行时链路上，属代码协作流程层；
- 闭源与否取决于执行位置：本地内容（SKILL.md、脚本）必然可见；远端服务（MCP/SaaS）天然闭源；license 字段仅是法律声明。
待确认问题：无。

主题 4：创建路径与形态差异（Skills vs 插件 vs 专家）

提出背景：概念清楚后转向实践关心——怎么造、造哪种、彼此如何组装。
核心诉求：掌握创建工具与流程；弄清"壳与内容"的组装关系；判断自己该用哪种形态。
具体问题：#2、#8 前半、#9、#10、#11、#14、#15
用户明确给出的前置理解（提出待验证）：
- "skills 只能开源，plugin 可以闭源"；
- "插件 = skills 合集 + 一个壳"；
- "把各种 skills 整合到一个 agents 角色 md 文档上"；
- "专家（身份 md）+ 技能 = 插件"。
已获结论：
- 制造类技能三件：skill-creator（通用六步流程）、huashu-nuwa 女娲（人物思维蒸馏，重调研、有档位）、lark-skill-maker（仅飞书 CLI 封装）；发现类两件：marketplace-skill-installer（官方市场）、find-skills（开放生态，装前应做安全审计）；
- 创建技能：一个 SKILL.md 即可，放入目录即生效；创建插件：需版本号目录 + plugin.json + 市场分发 + 启用注册；
- 修正："整合到 agents md"应为并列共存：agents/ 定身份，skills/ 给招式，可只有角色不带技能（本机 3/6 专家如此）；
- 修正：专家 md + 技能 ≠ 插件，还缺"壳"（版本目录 + 清单）；且专家启用后其内含技能会注入全局技能池（实证：document-skills 启用 → pdf/pdfkit-py 入列；未启用的专家技能不入列）；
- commands/、bin/、dist/ 技术上可出现在专家插件中，但本机 6 个专家实测均未携带（0/6）；
- 技能独立可复用：实证 fullstack-dev 同时存在于全局目录与微信小程序专家包内（副本关系）；
- 壳可套任意技能组合，组合差异即专家差异。
待确认问题：
- 是否开始创建第一个自有技能（助手多次建议以"湘建云投标材料"为首个技能，用户尚未确认——此为助手建议，非用户提出的需求）。

主题 5：跨平台概念对应（Codex / ChatGPT ↔ WorkBuddy）

提出背景：用户熟悉 Codex 生态术语，试图映射到 WorkBuddy。
核心诉求：确认术语对应关系，避免概念错位。
具体问题：#8 后半、#12
用户明确给出的前置理解（提出待验证）：
- "Codex 里面的插件就是 WorkBuddy 里面的专家"；
- "expertType 是不是 Codex 里面的 plugin type"；
- "一种插件名称叫做 agent 的插件被称为专家"。
已获结论：
- 修正：ChatGPT 插件（外部 HTTP 能力扩展）已被 GPTs 取代，演进方向是 MCP；Codex 现主要靠 MCP，无"插件"概念；
- 正确对应：MCP ↔ 连接器（给能力）、GPTs ↔ 专家（给身份）、插件 ↔ 无直接对应（打包格式）、项目指令 ↔ 技能（给方法）；
- expertType 是 WorkBuddy 自有分类字段，与 Codex 无关；本机 6 个专家取值全部为 agent，是类型值不是名称（名称是 displayName：赢单单、小台、小程达等）；
- 最准确定义："专家 = 装了 agents/ 角色定义的插件，expertType 标记为 agent，产品上称专家"。
待确认问题：无。

主题 6：命名逻辑与交互架构定位

提出背景：概念辨析完成后，追问产品命名意图与三者在大模型交互中的位置，属于体系化收尾。
核心诉求：理解"为什么叫专家不叫插件"；获得专家、技能、连接器在交互链路上的逻辑位置图。
具体问题：#13
已获结论：
- "插件"并未弃用——技术层仍在用（enabledPlugins、plugins/cache/）；"专家"是用户展示层词汇，"插件"是技术层词汇，同一事物两套命名；
- 命名规律：用户视角（能得到什么：一个专家、一个连接）优先于技术视角（怎么装进去）；
- 三者逻辑位置：专家 = 身份层（会话级，启用即全程）、技能 = 方法层（轮次级，命中才加载）、连接器 = 能力层（调用级，工具定义常驻）；
- 成本排序：专家（最高）> 连接器 > 技能（最低）。
待确认问题：无。

三、提问的演进逻辑

演进链条：

是什么（Skills 构成）
  → 怎么跑（加载/触发/成本机制）
    → 和谁有关（连接器/MCP/插件/专家的边界）
      → 怎么造（创建流程与工具）
        → 怎么装（壳与内容的组装、复用）
          → 为什么这么设计（命名逻辑、架构定位）

提问方式的三个特点（客观观察）：

先理解后动手：16 个问题全部是理解型提问，无一个"帮我做 X"的操作型请求；
用自己的话复述求证：多次以"是不是就是……""可以这么理解吗"的句式给出自建模型，要求验证——验证结果有的被确认（Skills 两行机制），有的被修正（MCP 构成、专家=md+技能）；
要求机制性解释：明确指定用"输入输出、整体架构、数据流转"框架，拒收空泛类比。