摘要： 本文系统讲清腾讯 WorkBuddy 开放平台中 Skill、Expert、Connector 与 MCP 的职责边界、目录结构、接入步骤和组合方式。核心结论是：Skill 负责告诉 AI“怎样做”，Expert 负责提供稳定角色与任务编排，Connector 负责产品化分发外部能力，MCP 则是 Connector 最值得优先采用的标准工具协议。适合独立开发者、SaaS 厂商、企业技术团队和 AI 自动化搭建者阅读。若已经拥有稳定 API，建议现在从“远程 MCP + Skill”开始试点；涉及写入、发送、删除和审批等动作时，必须加入最小权限、参数校验、人工确认与审计。
核心结论
腾讯 WorkBuddy 的正确接入思路不是在 Skill、Expert、Connector 和 MCP 中四选一，而是把它们分成“方法、角色、入口、协议”四层：用 Skill 固化操作方法，用 Expert 封装专业角色，用 Connector 交付第三方服务入口，再用 MCP 把真实工具和数据标准化地提供给 AI。
- 最推荐的起点： 已有 Web API 或能开发服务端的团队，优先使用“Connector（MCP + Skill）”；官方开发文档明确将其列为推荐方案。
- Skill 不等于工具： Skill 主要是 Markdown 指令及其参考资料、脚本和模板，用于约束 AI 的步骤、输入、输出和安全规则；它可以不连接外部系统。
- Expert 不等于一段提示词： Expert 是可进入市场、可被用户“召唤”的 Agent 产品，包含
plugin.json、Agent 定义、头像、展示信息，也可声明 Skill、MCP 和已有 Connector 依赖。 - Connector 是分发包装，MCP 是连接协议： Connector 让用户安装后以自然语言调用第三方服务；MCP Server 则暴露工具、参数与返回结果。官方还支持 CLI + Skill，但只适合已有成熟跨平台 CLI 的产品。
- 先做最小闭环再提交： 建议先实现查询类工具，再增加写入类工具；远程 MCP 使用 HTTPS，单次请求尽量在 30 秒内返回，凭证不得硬编码，高风险操作必须二次确认。
背景与主要变化
WorkBuddy 是腾讯面向办公场景推出的 AI Agent 工作台。2026 年 9 月 2 日，WorkBuddy 开放平台正式上线，开放平台首页显示首期开放五类生态能力：Buddy 应用、专家、Skill、连接器和硬件。对普通开发者而言，最直接的开放对象是 Skill、Expert 与 Connector；其中 Connector 文档给出了 MCP + Skill 和 CLI + Skill 两条标准路径。
这次开放值得关注的原因，不只是“又多了一个 Agent 市场”，而是开发者可以把三类过去容易混在一起的资产分别产品化：行业经验可以写成 Skill，专业角色可以封装成 Expert，已有 SaaS、数据库或内部系统可以包装成 Connector。它们还能组合为完整的 Buddy 应用或行业工作台。
官方首页目前展示“100+ 家共创伙伴”等平台数据，但这属于官方展示口径，并不等同于独立第三方审计结果。开放平台的支付能力、分发规则、审核周期和商业结算细则仍可能继续调整；准备商业化之前，应以开发者后台和最新服务协议为准。
| 概念 | 主要解决的问题 | 核心文件/接口 | 是否直接连接外部系统 | 适合先做什么 |
|---|---|---|---|---|
| Skill | 告诉 AI 何时做、怎样做、输出什么 | SKILL.md，可带 references/scripts/templates | 不一定 | 固化报告、审核、内容生产流程 |
| Expert | 封装稳定的专业 Agent 或 Agent Team | .codebuddy-plugin/plugin.json、agents/*.md | 可声明依赖 | 行业顾问、运营专家、审核专家 |
| Connector | 将第三方能力包装成可安装资产 | connector-meta.json、mcp.json 或 cli.json | 是 | CRM、工单、文档、数据库接入 |
| MCP | 标准化暴露工具、参数、结果和上下文 | MCP Server + transport + tool schema | 是 | 查询、创建、更新、通知类工具 |
| Buddy 应用 | 打包完整行业场景与品牌化工作台 | 多类资产组合 | 视组合而定 | 成熟方案的最终交付形态 |
如果你还在梳理 MCP 的通用结构，可先阅读 AI Stack Nav 的 MCP 教程与案例；如果希望把接入过程做成自动化项目，也可参考 AI Agent 工作流教程。
核心功能拆解
Skill：把 Know-How 变成 AI 可执行的方法
WorkBuddy Skill 的最低可用结构只有一个 SKILL.md。官方文档给出的完整结构允许加入 references/、scripts/ 和 templates/：参考资料用于提供字段定义和领域知识，脚本负责确定性计算或 API 调用，模板用于稳定输出格式。
skills/
└── compliance-report/
├── SKILL.md
├── references/
│ └── field-rules.md
├── scripts/
│ └── validate.js
└── templates/
└── report.md一个合格的 Skill 不应只写“帮我生成报告”，而应明确触发条件、输入校验、执行步骤、允许使用的工具、异常处理和最终输出。下面是简化示例：
---
name: compliance-report
description: 检查业务记录并生成合规审查报告；当用户提到合规检查、记录审查或风险报告时使用
description_zh: 生成带证据与风险等级的合规审查报告
description_en: Generate evidence-based compliance review reports
allowed-tools: Read, Grep, Bash
version: 1.0.0
author: YOUR_ORGANIZATION
---
## 执行规则
1. 确认数据范围、时间范围和输出对象。
2. 按 `@references/field-rules.md` 校验必填字段。
3. 只读取本次任务授权的目录或数据源。
4. 将事实、推断和建议分别列出；证据不足时标记“待人工确认”。
5. 涉及提交、删除或外发时停止执行并请求用户确认。官方文档列出的关键字段包括 description、中英文描述、version、author，以及可选的 allowed-tools、disable-model-invocation 和 user-invocable。其中 description 直接影响模型能否在正确场景触发 Skill，应该写“用途 + 触发语义 + 边界”，而不是品牌口号。
Expert：把角色、记忆方式与工作流封装成 Agent
Expert 的核心是插件目录。官方基础结构包含 .codebuddy-plugin/plugin.json、agents/、avatars/ 和 README。plugin.json 决定市场展示、Agent 入口、类型和依赖；Agent Markdown 文件则用 YAML frontmatter 加系统指令定义角色。
{
"name": "compliance-expert",
"version": "1.0.0",
"description": "Reviews records and produces compliance reports",
"author": {
"name": "YOUR_ORGANIZATION",
"email": "YOUR_EMAIL"
},
"agents": ["./agents/compliance-expert.md"],
"expertType": "agent",
"agentName": "compliance-expert",
"displayName": {"zh": "合规审查专家", "en": "Compliance Reviewer"},
"profession": {"zh": "业务合规审查", "en": "Business Compliance Review"},
"displayDescription": {
"zh": "读取授权业务记录，识别字段缺失与流程风险，输出证据、等级和整改建议。",
"en": "Reviews authorized records and reports evidence, risk levels, and actions."
},
"avatar": "avatars/expert.png",
"categoryId": "YOUR_CATEGORY_ID",
"defaultInitPrompt": {"zh": "审查这批业务记录", "en": "Review these business records"},
"plugin": "compliance-expert",
"tags": [
{"zh": "合规", "en": "Compliance"},
{"zh": "审查", "en": "Review"},
{"zh": "报告", "en": "Report"}
],
"quickPrompts": [
{"zh": "审查这批业务记录", "en": "Review these business records"},
{"zh": "生成风险清单", "en": "Generate a risk list"},
{"zh": "生成整改建议", "en": "Generate remediation actions"}
]
}这里有三个容易踩坑的点。第一，expertType 可为 agent 或 team；团队型还要配置主理人与成员。第二，官方文档要求市场标签和快捷提示词固定为三项，并规定展示描述等字段格式，提交前应逐项校验。第三，开发者不能在 Agent 定义中任意添加系统工具，工具权限由平台统一分配；若必须使用外部系统，应声明 MCP 或 Connector 依赖。
Connector 与 MCP：把真实系统能力交给 AI
Connector 是 WorkBuddy 的能力扩展接口。用户安装后，可以用自然语言调用第三方服务。官方提供两种互斥方案：
- MCP + Skill： 适合已有 API 或可开发 MCP Server 的服务，远程服务优先使用 HTTPS 的 SSE 或 Streamable HTTP。
- CLI + Skill： 适合已经拥有成熟、稳定、跨平台 CLI 的产品，由 CLI 自行管理登录态和凭证。
一个 Connector 只能选择一种方案，不能把 MCP 与 CLI 混在同一连接器中。网络 API 场景优先 MCP；CLI 方案只有在命令行产品已经成熟时才值得采用，因为它还要处理安装、跨平台运行时、认证、状态检测、登出和重启后的凭证恢复。
MCP 连接器的基础目录如下：
your-connector/
├── connector-meta.json
├── mcp.json
├── icon.svg
└── skills/
└── connector-usage/
└── SKILL.mdconnector-meta.json 负责注册和展示，mcp.json 负责连接，Skill 负责告诉 AI 如何正确调用工具。即使 MCP 已提供工具描述，复杂业务仍建议附带 Skill，用于补充前置条件、参数选择、高风险确认和错误恢复。
适用人群与使用场景
独立开发者与内容创作者
最适合从 Skill 开始。比如把“选题研究—事实核验—文章生成—SEO 检查”固化成 Skill，先验证方法是否稳定，再决定是否包装 Expert。若只是读取本地文件、生成文档，不需要为了“技术含量”额外开发 MCP。
SaaS 与工具厂商
优先做 Connector。把 CRM、项目管理、会议、文档、客服或数据分析 API 暴露为少量语义清晰的 MCP Tools，再通过 Skill 提供业务用法。如果产品需要统一人格、持续追问与交付模板，可在 Connector 之上增加 Expert。
企业技术团队
适合“私有 MCP + 内部 Skill + 专用 Expert”的组合：MCP 连接内部系统，Skill 固化标准操作程序，Expert 面向业务人员提供统一入口。查询与写入应拆成不同工具，生产写入使用独立权限，并保留调用人、参数摘要、审批结果和执行结果。
行业解决方案商
当单个专家无法覆盖完整流程时，可进一步构建 Expert Team 或 Buddy 应用。例如一个环保巡查场景可拆为资料检索专家、问题分类专家、整改建议专家和报告生成专家；但自动上报、外发通知或修改业务记录仍应经过人工审批。
安装、配置或使用步骤
下面以“企业知识查询与工单创建 Connector”为例，演示推荐的 MCP + Skill 路径。示例只展示结构，提交前仍需使用真实服务完成联调。
- 完成开发者认证。 进入 WorkBuddy 开放平台，按入驻指南完成个人或企业认证。官方当前支持个人认证和三类企业认证路径；证件与主体范围以页面实时规则为准。
- 定义最小工具集。 第一版只设计
search_knowledge、get_ticket和create_ticket三个工具。不要把所有 REST API 原样映射给 AI。 - 开发 MCP Server。 为每个工具提供清晰名称、描述、JSON Schema、可读错误码和结构化返回。远程生产服务使用 HTTPS，并设置身份认证、限流和超时。
- 创建连接器目录。 准备
connector-meta.json、mcp.json、图标以及可选 Skill；一个连接器只绑定一个 MCP Server。 - 配置认证。 有完整 OAuth 能力时使用 OAuth 2.1 + PKCE；只有 API Key 或私有地址时，使用用户自填 Token 模式，且客户端最低版本需满足官方要求。
- 本地和项目级验证。 先在测试账号验证安装、连接、工具发现、参数错误、凭证过期、超时、重复请求和断网恢复。
- 增加高风险确认。
create_ticket在写入前回显标题、项目、优先级和附件，要求用户确认；为重试请求增加幂等键。 - 打包并提交审核。 检查目录、版本、图标、双语说明、示例、HTTPS、凭证占位符和异常路径后，将目录打包提交。
远程 MCP 配置示例
{
"mcpServers": {
"enterprise-service": {
"type": "streamableHttp",
"url": "https://YOUR_DOMAIN/mcp",
"headers": {
"Authorization": "Bearer ${SERVICE_TOKEN}"
},
"timeout": 30000,
"disabledTools": ["delete_ticket"]
}
}
}官方连接器文档指出，远程类型可使用 sse 或 streamableHttp，本地进程可使用 stdio；disabledTools 自 WorkBuddy 4.22.15 起支持，使用它时要在元信息中声明相应的 minWorkbuddyVersion。上例主动隐藏删除工具，是更稳妥的默认策略。
连接器元信息示例
{
"name": "Enterprise Service",
"name_zh": "企业知识与工单",
"name_en": "Enterprise Knowledge and Tickets",
"description": "Search enterprise knowledge and manage authorized tickets.",
"description_zh": "查询企业知识，并在用户确认后创建授权范围内的工单。",
"description_en": "Search enterprise knowledge and create authorized tickets after confirmation.",
"source": "enterprise-service",
"type": "mcp",
"version": "1.0.0",
"minWorkbuddyVersion": "4.23.0",
"auth_mode": "token",
"examples_zh": ["查询退款流程", "确认后创建一条高优先级工单"],
"examples_en": ["Search the refund process", "Create a high-priority ticket after confirmation"]
}用户自填 Token 表单
当第三方服务没有 OAuth，仅提供 Access Token 或 API Key 时，可增加 token-schema.json。WorkBuddy 官方文档称，该模式中的凭证保存在用户本机并在连接时注入，不经过云端；但开发者仍应避免把完整凭证写入日志。
{
"title": "企业服务连接配置",
"description": "凭证仅用于连接已授权的企业服务，请使用最小权限 Token。",
"docUrl": "https://YOUR_DOMAIN/docs/token",
"docLabel": "如何获取 Token？",
"fields": [
{
"key": "SERVICE_TOKEN",
"label": "Access Token",
"type": "password",
"required": true,
"placeholder": "YOUR_TOKEN"
}
]
}实际工作流示例
假设用户输入：“查找公司退款制度，根据客户材料生成工单草稿，确认后提交并通知项目群。”合理的执行闭环如下：
- Expert 判断任务属于售后合规流程并加载对应 Skill。
- Skill 要求先确认客户、订单与授权范围，不允许直接写入。
- MCP 调用
search_knowledge，返回制度条款、版本和来源标识。 - Expert 根据证据生成工单草稿，并明确区分制度原文、模型归纳和待补信息。
- 用户确认标题、优先级、处理组和通知对象。
- MCP 调用
create_ticket，携带幂等键，返回工单 ID。 - 再调用通知工具发送不含敏感数据的摘要；记录调用结果与审计信息。
这个流程中，Expert 负责持续对话与任务编排，Skill 负责业务规则，Connector 负责安装、认证和分发，MCP Tool 执行真实动作。若缺少任何一层，也可以运行，但产品体验、可维护性或安全性会相应下降。
对比与选型建议
| 你的现状 | 推荐方案 | 原因 | 暂不建议 |
|---|---|---|---|
| 只有一套成熟方法论 | Skill | 成本最低，可快速验证触发与输出 | 直接开发复杂 MCP |
| 需要一个固定专业角色 | Expert + Skill | 角色、市场展示和工作流程更完整 | 用 Connector 代替角色设计 |
| 已有稳定 Web API | Connector（MCP + Skill） | 标准工具描述，适合远程服务 | 为接入而重写 CLI |
| 已有成熟跨平台 CLI | Connector（CLI + Skill） | 可复用安装和认证能力 | 同一连接器混用 MCP 与 CLI |
| 需要多角色协作 | Expert Team + Skills + Connectors | 主理人可拆解并协调成员 | 第一版就堆叠大量 Agent |
| 要交付完整行业工作台 | Buddy 应用 | 可组合场景、数据和专业能力 | 在业务未验证前大规模开发 |
编辑判断：多数团队的最优路线是“Skill → 单 Expert → MCP Connector → Expert Team/Buddy 应用”。这是实施建议，不是腾讯规定的发布顺序。这样做的好处是，每一阶段都能用真实任务验证价值，避免在工具定义尚不稳定时过早投入市场包装。
如果服务只有少量只读接口，甚至可以先做自用 MCP，再决定是否提交 Connector 市场。反之，如果你已经有大量用户依赖的 CLI，则应优先补齐非交互安装、auth、status、unAuth、结构化输出和跨平台测试，而不是强行改造成远程 MCP。
风险、限制与注意事项
版本兼容不是可选项
WorkBuddy 不同版本支持的字段不同。例如连接器文档标注：auth_mode: token 与 token-schema.json 要求最低 4.23.0，disabledTools 要求 4.22.15，MCP 的 runtime、staticEnv、staticHeaders 等字段从 5.0.0 起支持。只要用了新字段，就应声明对应的 minWorkbuddyVersion。
不要把凭证写进安装包
真实 Token、API Key、Webhook 和 Cookie 不得出现在 connector-meta.json、mcp.json、cli.json、Skill、README 或示例代码中。远程 MCP 使用 HTTPS，敏感字段使用密码类型，并对日志做脱敏。服务端应区分租户与用户，不能只依赖模型传入的用户 ID。
MCP Tool 必须比普通 API 更严格
模型可能选错工具、填错参数或被 Prompt Injection 诱导。服务端必须重新验证枚举、长度、权限、资源归属和业务状态；对删除、付款、发信、发布、修改权限和生产写入增加人工审批。不要把“模型已确认”当成真实用户授权。
重试、超时和幂等要成套设计
官方建议 MCP 单次请求在 30 秒内响应。耗时任务应返回任务 ID，再提供查询状态工具，不要让连接长期阻塞。写入工具接受幂等键，避免客户端重试造成重复工单、重复消息或重复扣费；错误返回应可读、可分类、可恢复。
平台市场信息仍可能变化
开放平台刚上线，审核、商业结算、支付、分发、版本同步和地区可用性都可能调整。官方连接器文档称更新重新审核后“通常在 10～15 分钟内同步生效”，但这不是所有情况下的服务等级保证。正式交付前，应在目标账号和目标客户端版本上复测。
事实依据与来源
- 官方已确认事实： WorkBuddy 开放平台首页列出 Buddy 应用、专家、Skill、连接器和硬件五类生态能力；开发文档提供 Skill、Expert 与 Connector 的目录、字段和提交规则。
- 官方文档数据： Connector 支持 MCP + Skill 与 CLI + Skill；网络 API 优先 MCP；一个 Connector 只能选一种方案；远程 MCP 使用 HTTPS，支持 SSE 或 Streamable HTTP，本地可用 stdio。
- 官方版本信息：
auth_mode: token、disabledTools、运行时托管等字段存在明确最低客户端版本，本文按 2026 年 9 月 3 日文档记录。 - 第三方信息： 本文没有使用第三方 Benchmark、性能测试或用户规模推算。媒体报道仅用于交叉核对开放平台上线事件，核心技术结论以官方文档为准。
- 编辑判断： “Skill → Expert → Connector → 完整应用”的渐进路线，以及先只读后写入的开发顺序，是基于工程风险的建议，不代表官方强制流程。
- 实施建议： 工具拆分、幂等键、人工审批、审计字段和长任务异步化需要根据真实系统验证；官方当前未公开统一的 Connector 调用价格或开发者收益规则，具体以控制台和协议为准。
FAQ
WorkBuddy 开放平台现在是否免费？
注册、认证、资产提交、客户端套餐和能力调用是否收费，不能简单用一个“免费”概括。官方公开页面当前没有给出覆盖 Skill、Expert、Connector 发布和所有 MCP 调用的统一价格表；模型积分、第三方 API、服务器和 SaaS 订阅仍可能产生成本。开发前应分别核对 WorkBuddy 套餐、你的 MCP 托管成本和第三方服务计费。
Skill、Expert 和 Connector 最核心的区别是什么？
Skill 是可执行方法说明，Expert 是具有角色与任务流程的 Agent 产品，Connector 是第三方系统能力的安装与分发入口。MCP 是 Connector 可采用的标准协议之一。一个完整方案可以同时包含三者，不需要四选一。
WorkBuddy Connector 必须使用 MCP 吗？
不是。官方支持 MCP + Skill 和 CLI + Skill 两种方案，但一个连接器只能选择一种。已有网络 API 或能开发 MCP Server 时优先 MCP；已有成熟、稳定、跨平台 CLI 时才选择 CLI 方案。
MCP 可以使用哪些传输方式？
官方连接器文档列出远程服务可使用 SSE 或 Streamable HTTP，生产环境必须使用 HTTPS；本地进程可以使用 stdio。新项目更适合优先采用 Streamable HTTP，同时根据目标客户端版本声明兼容要求。
Expert 能否直接添加任意工具？
不能。官方 Expert 文档说明，开发者不可自行在 Agent 中添加系统 tools，工具权限由平台统一分配。需要外部能力时，应在 plugin.json 中声明 MCP 服务或已有 Connector 依赖，让用户先完成连接授权。
API Key 应该写在哪里？
不能写入代码包或示例。没有 OAuth 时，应使用 auth_mode: "token" 和 token-schema.json 收集用户凭证，再通过 ${VAR_NAME} 注入 headers 或 env。敏感输入使用 password 类型，日志只保留脱敏标识。
为什么 MCP 已有工具描述，还要写 Skill？
工具描述通常只解释单个 Tool 的功能和参数，无法完整表达跨工具顺序、业务前置条件、审批规则和异常恢复。简单 MCP 可不带 Skill，但业务复杂、工具较多或含写入动作时，Skill 能显著降低误调用风险。
Connector 调用失败应先检查什么？
先检查客户端版本与 minWorkbuddyVersion，再检查 JSON 格式、HTTPS 可达性、认证状态、变量名大小写、工具 schema、30 秒超时和服务端日志。红色连接状态通常意味着配置、命令环境或地址异常；不要通过输出完整 Token 来排错。
是否值得现在接入 WorkBuddy 开放平台？
如果你已有明确办公场景、稳定 API 或可复用行业 Know-How，值得用一个只读或低风险场景开始验证。如果商业模式依赖尚未公开的支付和分发细则，则不宜一次性重投入；先完成自用闭环和真实用户测试更稳妥。
参考来源
- 腾讯 WorkBuddy 开放平台官网
- WorkBuddy 开放平台入驻指南
- WorkBuddy Skill 开发文档
- WorkBuddy Expert 开发文档
- WorkBuddy Connector 开发文档
- WorkBuddy MCP 使用指南
- Model Context Protocol 官方规范
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
WorkBuddy开放平台Agent开发完整资料包
覆盖 WorkBuddy Skill、专家 Agent、MCP + Skill 连接器、Token/OAuth、Open API、n8n、Docker、测试与安全治理，提供企业知识问答与工单助手完整案例。 适合人群
下载完整资料包