WorkBuddy 里的"连接器、技能、专家、专家团、灵感"，第一次看确实很容易混在一起。
其实不用把它们想得太复杂。用一句话概括： 连接器负责"接工具"，技能负责"教方法"，专家负责"定角色"，专家团负责"多人协作"，灵感负责"抄成熟方案"。
理解了这句话，WorkBuddy 整套产品结构基本就清楚了。
一、连接器：让 AI 能访问你的工具和数据
大模型虽然很聪明，但它默认并不知道你邮箱里有什么邮件，也看不到腾讯文档里的资料，更不能直接用你的账号创建腾讯会议。
所以，如果希望 AI 真正帮你办公，第一步就是让它能够连接你平时使用的系统。
这就是"连接器（Connector）"。
比如 WorkBuddy 可以连接 QQ 邮箱、腾讯文档、腾讯会议、TAPD、腾讯网盘等，也支持添加自定义连接器。
你可以把连接器理解成：给 AI 装上"手和脚"。
比如你对 WorkBuddy 说：
帮我创建一个明天下午 3 点的腾讯会议，主题是周报评审，时长 1 小时。
如果没有连接腾讯会议，AI 最多只能告诉你"怎么创建会议"。
但连接并授权腾讯会议以后，它就可以真正调用腾讯会议，帮你创建会议，然后把会议号和链接返回给你。
从技术上来说，添加一个连接器通常包含几件事：
- 给 Agent 准备好调用腾讯会议的接口和工具；
- 让你登录并授权，允许 Agent 使用你的账号；
- 告诉大模型："你现在拥有一个腾讯会议工具，需要的时候可以调用。"
这些事情在技术上并不简单，但 WorkBuddy 把它们封装了起来。用户看到的通常就是"添加连接器 → 登录授权"，剩下的事情平台自动完成。
这里还有一个使用技巧：工具不是越多越好。
因为 Agent 通常需要把可用工具的名称、用途、参数等信息告诉大模型，然后由模型判断该调用哪个工具。
一次给模型太多相似工具，反而可能让它选错。
比如企业微信和腾讯会议都提供了"创建会议"的能力，那么用户说"帮我创建一个会议"时，模型就需要判断到底该用哪一个。
所以，更合适的做法是：根据当前任务，只启用真正可能用到的连接器。
二、技能：告诉 AI"这件事应该怎么做"
如果连接器解决的是"AI 能不能做"，那么技能（Skill）解决的就是"AI 应该怎么做"。
可以把它理解成一份可以重复使用的"标准操作流程"。
例如，我们创建一个"本周会议复盘"的 Skill，规定 AI 按照下面的流程工作：
- 找出腾讯会议中本周参加过的会议；
- 在腾讯文档建立一份本周会议清单；
- 获取每场会议的文字转写；
- 分别总结会议内容，并提取待办事项；
- 把原始记录、会议摘要和待办事项整理进腾讯文档；
- 最后生成一份本周会议总览。
以后再做会议复盘，就不用每次重新给 AI 解释这一整套流程。
这就是 Skill 的价值：把"怎么做一件事"保存下来，让 Agent 可以反复调用。
不过这里很容易产生一个误区：
"有了 Skill，是不是 Agent 就什么都能干了？"
不一定。
Skill 可以包含脚本、工作流甚至 API，因此有些 Skill 自己就有执行能力。但如果 Skill 需要访问外部系统，仍然要解决系统访问和账号授权问题。
比如上面的会议复盘 Skill 需要读取腾讯会议，还需要写入腾讯文档，那么 Agent 就必须拥有相应的连接能力。
因此可以这样理解：
连接器解决"能不能访问腾讯会议和腾讯文档"。
Skill 解决"拿到这些数据以后，具体按照什么步骤处理"。
一个负责提供工具，一个负责提供方法。
三、专家：让 AI 按某种专业角色思考
专家（Expert）又比 Skill 高一层。
它最容易和 Skill 搞混，因为使用起来看上去很像：选择一个东西以后，AI 好像突然"更专业"了。
但二者解决的问题并不一样。
Skill 关注的是：
"这件事情具体应该怎么做？"
Expert 关注的是：
"应该站在什么专业角色和视角看这件事？"
例如客户提出：
"我们公司想做一个 AI 知识库。"
如果只使用一个整理需求的 Skill，AI 可以按照固定流程把客户需求整理得很清楚。
但如果启用一个"AI 解决方案专家"，它考虑的问题可能会变成：
- 客户真正想解决的业务问题是什么？
- 现有资料适不适合建设知识库？
- 哪些场景适合使用 RAG？
- 权限体系怎么设计？
客户说的需求中，哪些应该做，哪些暂时不应该做？
这时候，AI 不只是"按照步骤干活"，而是在用某个专业角色的方法论进行判断。
所以可以记住： Skill 更像"操作手册"。Expert 更像"专业人士"。
四、专家团：一件事太复杂，就让多个 AI 专家一起做
一个专家适合解决一个专业领域的问题。
但现实中的复杂工作，往往不是一个角色能够独立完成的。
例如你要做一套完整的 AI 项目方案，可能同时需要：
产品经理分析需求，解决方案专家设计业务方案，技术架构师设计系统架构，项目经理制定实施计划。
这时候，与其要求一个 AI 同时扮演所有角色，不如让几个不同的 AI 专家分工合作。
这就是专家团（Expert Team）。
WorkBuddy 中的专家团，本质上是一种多 Agent 协作机制。
通常由一个负责人先理解任务并进行拆解，然后把不同任务交给相应的专家，各自完成以后，再把结果整合起来。
所以：
专家解决"让谁来做"。
专家团解决"这么复杂的事情，让哪些人一起做，以及如何分工协作"。
五、灵感：别人做好的方案，直接拿来改
"灵感"其实是最适合普通用户使用的功能。
因为普通用户通常并不关心 Connector、Skill、Prompt、Agent 到底是什么。
他真正关心的可能只是：
"我想做一份市场分析报告，有没有别人已经做过？"
如果有，而且效果还不错，最简单的办法就是： 直接拿来改。
这就是 WorkBuddy 的"灵感"。
你可以把它理解成一个"优秀案例和模板市场"。
例如你在灵感页面看到一个不错的"产品定价对比页"，点击"做同款"，WorkBuddy 就会把这个案例背后用到的 Prompt、Skill、专家等配置自动加载进来。
然后，你只需要换成自己的产品和资料，就可以生成自己的版本。
所以灵感本身不一定是一种新的 AI 能力。
它更像是把前面各种能力组合好以后，包装成一个可以直接复用的成品。
这也是一个很聪明的产品思路。
普通人没必要先学习什么叫 Agent、Skill、MCP、Prompt Engineering，再开始工作。
完全可以倒过来：
先找到一个想要的效果 → 点击做同款 → 不满意的地方再修改。
先解决问题，再慢慢理解背后的原理。
六、把五个概念放在一起，就很好理解了
可以用一个简单的比喻来理解。
假设你开了一家公司：
- 连接器，就像给员工配电脑、邮箱、企业微信以及各种业务系统，让他"有工具可以用"。
- 技能，就像公司的 SOP 和操作手册，告诉员工"具体应该怎么干"。
- 专家，就像招聘一个产品经理、律师、程序员或者财务专家，让专业的人"按照专业方法思考"。
- 专家团，就像组建一个项目组，让产品、技术、运营等多个专业角色"一起完成复杂项目"。
- 灵感，则像公司的优秀项目案例库。看到别人做过类似项目，直接复制一套，再根据自己的情况修改。
所以这五个概念并不是五种完全独立的东西，而是 Agent 工作过程中的不同层次。
七、用一个完整例子把它们串起来
假设今天刚和客户开完一场"AI 项目需求沟通会"，现在需要把会议内容真正变成一个可以落地推进的项目。
第一步，需要读取腾讯会议的会议记录、腾讯文档里的客户资料和历史方案。
这里使用的是连接器。
它解决的是：
"AI 能不能拿到这些数据？"
第二步，需要整理会议记录。
例如删除无关内容，提取客户目标、核心需求、确认事项、未确认事项和下一步计划，并按照固定格式保存。
这里使用的是 Skill。
它解决的是：
"拿到数据以后，具体应该怎么处理？"
第三步，需要判断客户真正的问题。
因为客户嘴里说出来的"需求"，并不一定就是应该实施的解决方案。
这时候可以让一个"AI 解决方案专家"参与，让它从业务咨询和解决方案的角度判断：
客户真正的业务目标是什么？
哪些问题适合用 AI？
哪些需求现在没有必要做？
这里使用的是 Expert。
它解决的是：
"应该用什么专业视角进行判断？"
第四步，需要输出一份完整的项目方案。
这可能涉及业务分析、产品设计、技术架构和项目实施等多个专业领域。
于是可以建立专家团，让不同专家分别负责不同部分，最后统一整理成完整方案。
这里解决的是：
"复杂任务怎么让多个专业角色协同完成？"
第五步，如果发现这套流程非常好用，就可以把它保存成一个：
"客户需求会议 → AI 项目方案"
的最佳实践案例。
把其中用到的 Prompt、Skill、专家等配置组合起来，让其他用户以后直接点击"做同款"。
这就变成了"灵感"。
这样一条完整链路就形成了：
连接器拿数据 → Skill 按流程处理 → Expert 专业判断 → Expert Team 协同完成复杂任务 → 灵感把整套方案保存下来给别人复用。
八、WorkBuddy 真正做的，其实是把复杂技术"翻译成人话"
理解到这里，就会发现一个很有意思的地方：
连接器、技能、专家、专家团和灵感，其实都不是什么新的 AI 技术名词。
它们更像是 WorkBuddy 把 Agent 背后一堆复杂的工程概念，重新包装成普通用户容易理解的产品功能。
比如：
- API、OAuth、MCP 太技术化，就包装成"连接器"。
- Workflow、Prompt、Tool Calling 太复杂，就包装成"技能"。
- System Prompt、专业知识、方法论比较抽象，就包装成"专家"。
- Multi-Agent、任务编排、协同执行更难理解，就包装成"专家团"。
Prompt Template、Skill 配置、Agent 配置、Demo Case 混在一起就更复杂，那干脆直接展示最终效果，告诉用户：
- "别人已经做出来了，你要不要做同款？"
- 这就变成了"灵感"。
- 背后的技术依然复杂，但用户不用先理解技术才能开始工作。
这其实就是 Agent 产品化很重要的一步：把"技术怎么实现"，转换成"用户想完成什么"。
九、普通用户到底应该怎么用？
如果只是想用 WorkBuddy 提高工作效率，其实完全没必要一上来就研究这些概念。
最简单的使用顺序是：
- 先去"灵感"里找有没有别人做过类似的东西，有就直接做同款。
- 拿回来以后，发现执行流程不符合自己的需求，再修改 Skill。
- 发现需要读取自己的邮件、文档或者会议记录，再添加 Connector。
- 发现 AI 虽然能做，但分析得不够专业，再增加合适的 Expert。
如果任务复杂到一个角色已经搞不定，需要产品、技术、运营等多个视角共同完成，再使用 Expert Team。
这比一开始就研究 MCP、Skill、Multi-Agent、Context Engineering 更容易真正把 Agent 用起来。
而如果你本身就在研究 Agent 产品，那么 WorkBuddy 这几个概念也值得观察。
因为未来不管换成哪一种 Agent 产品，底层绕不开的通常还是几个基本问题：
- AI 能使用什么工具？
- AI 能访问什么数据？
- 任务应该按照什么流程执行？
- 应该用什么专业角色和方法思考？
- 复杂任务怎么拆解和协作？
- 一套成功的方法怎么保存、分享和复用？
产品名称会变，技术方案也会变，但这些核心问题不会轻易改变。
最后用一句话记住 WorkBuddy 的五个概念：
- 连接器 = 给 AI 工具和数据。
- 技能 = 教 AI 怎么干活。
- 专家 = 告诉 AI 以什么专业身份干活。
- 专家团 = 让多个 AI 专家分工合作。
- 灵感 = 把别人验证过的整套方案拿来直接复用。
理解了这五句话，也就基本理解了 WorkBuddy 是怎么把模型、工具、提示词、工作流和多 Agent 协作，最终包装成一个普通人能够直接使用的 AI 产品。