我把 WorkBuddy 拆开看了一遍，终于搞懂了 Agent 是怎么干活的

前面说了用AgentScope 复刻一个 WorkBuddy的专家团，这对有些同学有些难，很多同学面临的问题是：连接器、技能、专家/专家团、灵感，这几个东西到底有什么区别？

现在回头来说一说 workbuddy 里常见的容易混淆的几个功能的使用和区别，理解这一点以后，WorkBuddy 整套产品结构就比较清楚了。

1、连接器（Connector）：给 Agent 接“手脚和数据源”

连接器最好理解，大模型本身其实什么系统都访问不了，它看不到你存在腾讯文档里的数据，看不到你的邮箱收到了什么邮件，也不能直接帮你创建一个会议链接。

所以，要让 Agent 真正进入我们的工作环境，第一件事就是让它能够连接企业已有的系统、数据和服务。

这就是 Connector，目前 WorkBuddy 官方连接器页面列出的能力包括 QQ 邮箱、腾讯乐享、腾讯文档、TAPD、腾讯网盘等，同时支持自定义连接器。连接之后，Agent 才能在授权范围内查询或者操作这些外部系统。

比如我们想让 workbuddy 支持后续自动创建腾讯会议链接，我们就得把腾讯会议的连接器在workbuddy 上添加，

首次连接的时候需要安装连接器依赖，说白了就是做了三件事：

• 先是在Agent上装载内置的调用腾讯会议接口的依赖和插件。

• 再是弹出腾讯会议的登录授权，通过我们在网页的登录授权，让Agent能够支持通过我们的账号来使用腾讯会议的三方功能。

• 最后在 workbuddy这款 Agent 上转载这个工具，让 workbuddy执行我们提交的指令时携带这个链接器的描述给大模型。

这样大模型就知道自己有一个叫腾讯会议的工具可以使用，并且真使用的时候不管是接口调用还是授权都已经提前搞定了。

对我们来说，看起来就是点了一下添加连接器和扫码授权，后面这些事情都是 workbuddy 帮我们一键实现的，屏蔽了技术侧的学习操作难度。

这个时候我跟workbuddy 说：

帮我创建一个明天下午 3 点的会议，主题是周报评审，时长 1 小时

他就用我的腾讯会议的账号创建了会议，并给我提供：会议主题、会议时间、会议号、会议链接。

我们通常就可以拿着这个会议链接发送给对应的人了，当然发送的动作也可以让 workbuddy 对接其他的对话工具来实现。

这里值得再说一嘴的是，workbuddy下面其实可以勾选我们本次对话任务可能需要使用哪些工具，这里不建议所有对话都把所有工具勾选，因为工具勾选完以后其实是把工具的描述封装成提示词一起发给大模型处理。

大模型的决策依据是：把每个工具的描述（名称+参数+说明）拼进 system prompt，再基于这句话的语义去匹配最像的那个工具描述。

工具越多大模型其实可能不知道要调用哪个工具，会有选错工具和注意力稀释的风险。

比如，我们同时连接了企业微信和腾讯会议，我们运行同样的指令，2 个工具的描述都说了可以创建会议，大模型会选择哪个工具使用呢？

2、技能（Skill）：把“怎么干这件事”封装起来

如果说 Connector 是给 Agent 插上手脚，那么 Skill 就是在告诉 Agent：拿这些手脚具体怎么干活。

这里我发现部分同学有些混淆的点，有些同学会认为，我只要把skill 加载进来，就能让 agent 直接给我干活了。

这个理解也不完全对。

Skill 可以包含脚本、工作流甚至第三方 API 调用，因此有些 Skill 本身就有执行能力；但如果这个 Skill 依赖一个需要授权的外部系统，那么 Agent 还必须具备对应的接口、凭证或者连接能力。

比如我们这里创建一个本周会议整理复盘的 Skill，里面包含 6 步：

• 第一步：在腾讯会议中找到本周的会议，列出会议清单
• 第二步：在腾讯文档创建一个本周会议的在线文档，在表格中记录会议清单
• 第三步：在腾讯会议找到每个会议的逐字稿内容，每个逐字稿内容单独存放一个文件。
• 第四步：在 workbuddy 针对每一个逐字稿内容进行会议总结，形成 500 字以内的会议记录和待办事项。
• 第五步：在腾讯文档表格中记录对应会议的文字转写原文件目录位置、概要总结和待办事项。
• 第六步：在 workbuddy 生成一个本周会议总结，把会议概述、待办事项简要描述返回给用户

这里会要求它去读取已经接入 WorkBuddy 的腾讯会议和腾讯文档，那么前提就是这些外部能力已经连接并完成授权。

这是一套完整的执行方法，所以 Skill 的本质更接近：可复用的任务能力。

WorkBuddy 官方把 Skill 定义成扩展 Agent 任务能力的技能包。比如 PPT 制作、海报生成、自动化报表，都可以作为独立 Skill 被 Agent 调用。官方目前也支持内置技能、自定义 Skill，以及社区 Skill 的导入。

所以，腾讯文档连接器解决的是：agent可以读写腾讯会议、腾讯文档。而一个“会议复盘 整理Skill”解决的是：agent知道从哪里取数、怎么处理、信息存在哪里。

3、专家/专家团（Expert/Expert Team）：一个带方法论执行指令的“人”

再往上一层，就是专家，专家最容易和 Skill 混在一起，因为看起来都是：我选了一个东西，然后 WorkBuddy 干活变厉害了。

但二者描述的内容、解决的问题还是不太一样。

skill 描述的是具体怎么做，专家更多的解决的是身份的问题。

更详细的说，专家解决“以什么身份、什么视角、什么专业范式来处理这件事”。

用 NLP 思维逻辑层级模型来看，Connector 在第 1 层；Skill 主要覆盖 2～3 层；Expert 主要覆盖 3～5 层；第 6 层最终由人或组织掌控。

可以看看下面这个表做简单对应。

而专家团也很简单，当我们需要不同身份的人去完成一个复杂任务，与其要求一个 Agent 同时扮演所有角色，不如真的组织一支 AI 团队。

WorkBuddy 官方把专家团定义为一种“协作执行机制”，多位专家分工协作，由团长自动拆解任务、并行执行，最后整合交付。

这个上篇文章已经讲的很详细，就不重复描述了。

4、灵感：别人已经做出来的“成品案例”

灵感我觉得是这几个概念里面最容易理解错的，因为他不是给我们提供一种能力，说白了他不是给我们用的，是给我们抄的。

他像是：别人已经用 WorkBuddy 做出来的最佳实践案例。

比如我们打开灵感，看到产品定价对比页，觉得这个效果不错，就可以直接点击“做同款”。

这时候 WorkBuddy 会把生成这个案例对应的 Prompt、Skill、专家配置自动加载进来，我们在这个基础上修改和添加自己的内容生成自己的版本。

官方对“灵感”的描述就是：展示 WorkBuddy 或社区贡献的优质成品，用户可以收藏或者“做同款”；制作自己的版本时，相关 Prompt、Skill 和专家会被自动加载。

所以我觉得“灵感”这个产品设计其实挺有意思。

前面的 Connector、Skill、Expert、Expert Team，对于第一次使用 Agent 的普通用户来说，还是有学习成本的。

但用户其实并不关心我到底应该装哪个 Skill，他关心的是我想做一个市场分析报告，有没有别人已经做过？

效果不错的，我直接拿来改改用就好了，本质上大部分用户要的是快速解决问题，而不是像我们一样其实是想借助使用来学会一个工具。

灵感就是把技术能力重新包装成了“结果”，不用先学习 Agent 是怎么工作的，先看别人做出了什么，觉得有用就直接抄，所以灵感本质上就是一个场景模板/成品案例/最佳实践市场。

他最简单可能就是一段提示词，但是只要我们认可效果，就可以抄！

各个功能的本质和原理

理解完产品功能以后，再往下看一层，我们其实会发现，这5 个不是AI技术名词，workbuddy 其实是把 Agent 运行过程中原本混在一起的一堆东西，拆成了普通人比较容易理解和管理的产品功能。

1、Agent 到底是怎么干活的？

我们平时和大模型对话，本质是：

用户输入 → 用户输入由 Agent组合发给大模型 → 大模型输出 → Agent执行以后返回结果给用户。

前面的这些名词其实大部分都是在处理：用户输入由 Agent组合发给大模型这一部分。

连接器提供的描述是：我有什么工具？工具怎么调用？哪些数据可以访问？

skill 提供的描述是：这件事应该按照什么方法做？

专家提供的描述是：我是谁？我要怎么干？

灵感是将这些描述组合起来与场景问题对应。

这样看，WorkBuddy 的产品设计就很容易理解了。

它实际上是在把 Agent Runtime 里比较技术化的概念，重新包装成普通人可以理解的东西，最后再由 agent 组合成大模型能理解的上下文。

2、把 5 个东西串起来理解

举一个完整的例子，假设我今天刚刚跟客户开完一场 AI 项目需求沟通会，我的目标是把这次会议真正变成一个可以推进的项目，那么整条链路可能是这样的。

首先获取外部数据，我需要访问腾讯文档里的历史方案、客户资料。这里需要用到连接器。

它解决的是：Agent 能不能访问这些外部资料。

第二是把会议内容处理干净，我需要获取腾讯会议转写，把里面的废话去掉，提炼：客户目标、当前问题、核心需求、已确认事项、未确认事项、下一步计划，并且把信息存储到对应位置供后续使用。

这里就可以使用对应的：Skill。它解决的是：这件事情具体应该怎么干。

第三是判断客户真正的问题是什么，因为客户说的需求，不一定就是客户真正的问题，这时候我可以选择解决方案专家，让它按照业务咨询和解决方案的方法论，分析客户到底想解决什么问题？需求背后的业务目标是什么？现有条件怎么样？哪些问题适合 AI？哪些需求现在还不应该做。

这里解决的是：从什么角度、怎么专业地判断。

第四再形成完整项目方案，需要业务分析、产品设计、技术架构、项目实施几个角色一起工作。这时候就可以使用专家团，团长先理解目标，再把任务拆给不同专家。最后把：业务需求、AI 应用方案、技术架构、实施路径、项目计划、风险与待确认事项整合成一份完整交付物。

这里解决的是：复杂任务怎么通过多个专业角色共同完成。

第五我们还可以把这套流程整理成：“客户需求会议 → AI 项目方案”最佳实践，把对应的 Prompt、Skill、专家配置都绑定进去。以后其他人打开 WorkBuddy，看到了这个案例，只要点击：一键做同款。自己的项目材料一换，就可以直接复刻整套工作方法。

这时候它就变成了：灵感。

3、WorkBuddy 的Agent 产品化思路

从这里我们可以看到，WorkBuddy 这类 Agent正在尝试把 Agent 那套原本很工程化的东西，翻译成普通业务人员可以理解的概念。

API、OAuth、MCP 太技术了，那就叫连接器。

Workflow、Prompt、Tool Calling 混在一起太复杂，那就包装成技能。

System Prompt、Domain Knowledge、Methodology 太抽象，那就包装成专家。

Multi-Agent、Orchestration、Task 、Execution 更复杂，那就直接叫专家团。

Prompt Template、Skill Configuration、Agent Configuration、Demo Case 放在一起更没人看，那就直接告诉用户：这是别人做出来的东西，你要不要做同款？于是变成了灵感。

这个思路是正确的，对于用户来说，他应该只需要知道我想干什么，至于下面需要什么角色、什么技能、什么系统、什么工具，由 Agent 帮他组合就好了。

总结与建议

但那是对普通用户嘛，对我们来说，还是得稍微理解一下工具背后的原理。毕竟我们的目标是以后碰到新的 Agent 产品，也能够快速判断：它这个新功能到底是在解决 Agent 的哪一层问题？

所以这里再总结一下：

实际使用的时候，我自己的建议也比较简单。

如果只是一个普通用户，没必要一来就研究这些概念。

灵感里面找有别人已经做过类似的东西就直接抄就行了，抄回来以后发现某一步不满足自己的需求，就去改 Skill，发现需要访问自己的邮箱、文档、会议，再去配置 Connector，发现 AI 虽然会干，但分析问题不够专业，再去找或者自己创建 Expert，发现一件事情已经复杂到需要产品、技术、运营几个不同视角共同完成，再考虑 Expert Team。

很多人学习 Agent 最大的问题，就是一上来先研究 MCP、Skill、Multi-Agent、Context Engineering，研究了半天，最后还没真正用 Agent 完成过一件工作。

但对想深入学习 Agent 的人来说，WorkBuddy 这几个功能倒是一个非常好的观察窗口，Agent 我们可以哪个好用、易用就用哪个，但这些基本问题不会怎么变。我们得在实际使用中获得体感，慢慢就能看懂：一个 Agent，到底是怎么把模型、提示词、上下文、工具和工作流组织起来，最后变成一个普通人真的能够拿来干活的产品。

这可能就是我们要研究 WorkBuddy 的原因。

然后对 AI 深度学习感兴趣的可以点击：