
过去两年,我观察到团队里用 AI 有个共同习惯:一个人,问一句,等一句,再问一句。
这种"单点问答"在写摘要、润色段落、翻译这类事上够用。但一旦任务稍微复杂一点,它就卡住了。典型场景是这样:
要出一份季度复盘材料,你得先汇总销售数据,再找出异常波动,然后写成对外口径,最后配视觉。这四件事分属数据、分析、文案、设计四个领域。你要么指望一个 AI 角色全干(它多半每样都沾一点,但都不深),要么自己在四个对话之间来回切换,把同一段背景解释四遍。
问题不在 AI 能力不够,而在于我们一直在用"单人"的姿势使用它。
WorkBuddy 专家中心提供的「专家团」,本质上就是把这个姿势换掉:不再叫一个人干活,而是组织一支分工明确的 AI 团队,由团长自动拆解任务、并行执行、最后整合成完整交付物(官方定义)。下面我把它的定位、适用场景、实战流程和效果衡量完整拆一遍。

这是官方文档给出的划分,也是我理解这套体系最关键的一层:
维度 | Skill | 专家(Agent 型) | 专家团(Team 型) |
|---|---|---|---|
定位 | 工具能力:让 AI 能做某件事 | AI 顾问:懂某个领域的 AI 角色 | AI 协作团队:自动拆解、并行执行、完整交付 |
组成关系 | 执行能力 | 基于能力与经验解决特定问题 | 组织多个专家协作完成复杂任务 |
何时选 | 需要 AI 具备某种工具能力 | 有一个明确的单点问题 | 任务复杂,需要多角色配合 |
一句话记忆:Skill 是手,专家是脑,专家团是班底。
我自己的判断是:大多数人一开始会用错层次——遇到任何问题都想装 Skill,或者只想找一个"万能专家"。实际上八成以上的日常任务,用单专家就够了;只有当任务需要多个专业视角同时在场时,才值得动用专家团。

专家是「角色切换」机制,官方定义是"人设 + 方法论 + 工具链"三者合一。人设解决"以谁的身份思考",方法论解决"按什么流程做",工具链解决"能调用什么"。这三者不齐,专家就是个空壳。
专家团是「协作执行」机制:多位专家分工协作,由团长自动拆解、并行执行并整合交付。这里面最有价值的一点是并行——四个角色同时干活,而不是串行排队。
官方文档写得很明确:专家本身不主动获取系统权限,仅处理你主动提供的对话与上传文件;只有当配备了 Skill 或 MCP 时,才会在你的授权下间接访问文件或外部服务。
这条边界很重要。它意味着两件事:一是敏感材料的主动权仍在你自己手里,是否上传由你决定;二是如果某个专家需要连外部服务,任务会明确提示你授权,而不是静默发生。这个设计我认为是专业的。
把四种模式并排放,差异会非常直观:
普通对话 | 单个专家 | 专家团 | 真人团队 | |
|---|---|---|---|---|
任务拆解 | 你全想好了,它只执行 | 你想清楚,专家补专业 | 团长自动拆解 | 有人天生会拆 |
执行方式 | 串行 | 串行 | 并行 | 并行 |
视角数 | 1(通用) | 1(单一专业) | 多(跨领域) | 多 |
交付形态 | 片段 | 单项成果 | 整合后的完整交付物 | 完整交付物 |
上下文成本 | 每次重讲 | 讲一次 | 团内共享 | 靠会议 |
稳定性 | 随机性大 | 较稳定 | 角色分工明确 | 视人员而定 |
最核心的差别是第四行和第五行。 单点问答的产出永远是"片段",你需要自己动手拼;专家团的产出目标是"整合后的完整交付物",拼接这一步由团长完成。而多视角带来的好处不只是"更全",更重要的是避免了单一角色的盲区——一个文案专家不会发现你的数据口径有问题,一个数据分析专家也不会注意到对外表述里有法律风险。
代价也很实在:专家团会并行调用多位专家、涉及多轮模型交互,积分消耗通常为单专家的 3–5 倍(官方数据,以实际任务为准)。这个账后面我会再细算。
场景:做一份年度业务复盘。数据要从系统里捞、异常要能解释、结论要写得让管理层看得懂、还要配图。
单角色的表现:让一个"数据分析专家"硬上,它会把数据部分做得不错,但文案和视觉只能给你通用模板。
专家团的解法:拆成数据分析、内容撰写、视觉设计三个角色并行,最后由团长整合成一份完整材料。关键在于每个环节都有人管质量,而不是指望一个角色两头兼顾。
场景:同一件事你要在对话里问五轮,每轮都得重新交代背景、单位口径、禁用词。
专家团的解法:多角色在同一个任务下工作,背景信息共享一次即可。而且官方提供了两个提效细节:对话中点击专家入口可展开「最近使用」下拉列表,支持搜索与置顶;置顶结果会持久保存,下次打开排在列表前部,不用反复翻找。
场景:你上周用 AI 出的周报格式,这周想复用,结果格式全变。
单专家的问题:单次对话的稳定性依赖你这次怎么描述。
专家团的解法:把方法固化下来——通过「我的专家」把角色定位、工作流程、输出格式写成配置,之后每次召唤同一专家,行为就可预期了。这才是从"用 AI"到"用一套流程"的转折点。
场景:接到一个"把这份调研材料做成可对外的方案",你盯着屏幕不知道第一步该干什么。
专家团的解法:团长负责拆解。你只需要说清目标和交付形式,不需要自己设计工序。
官方文档的"创建专家"章节里有一句话我认为同样适用于专家团:如果只是临时完成一次简单任务,直接使用普通对话即可,无需创建专家。
同理:一次性、无跨领域需求、输出很短的任务,用专家团纯属浪费 3–5 倍积分。判断标准很简单——这个任务是否真的需要两个以上专业角色同时在场。 如果答案是否,就别用。

专家团再强,也救不了一段含糊的需求。我自己稳定在用的描述模板:
【目标】我要的最终交付物是什么(格式 + 用途 + 给谁看)
【背景】必要的业务背景,控制在能说清边界即可
【输入材料】已上传的附件清单,或明确"暂无"
【约束】必须遵守的规则(口径、禁用词、字数、时限)
【验收标准】什么样算完成实测下来,加了"验收标准"这一行的产出可用率明显更高——因为它逼着团长在拆解时就朝着可验收的方向去。
部分专家执行任务时会依赖 MCP 或连接器(如在线文档、项目管理类服务)。当任务真正需要某个尚未连接的服务时,WorkBuddy 会在输入框上方展示连接引导卡片,显示服务名称和头像。
点击卡片上的连接,按提示完成授权后,会自动继续当前任务,无需重新发起对话。这里有个设计细节值得注意:连接引导只在任务实际用到该服务时才出现,不会在会话开始时一次性罗列全部依赖。
想让团队长期稳定用,光召唤内置专家团不够——把你的方法沉淀成「我的专家」。官方给了四条配置要点,我认为是这份文档里最实用的部分:
配置项 | 该怎么写 | 别这么写 |
|---|---|---|
头像与显示名称 | 用短角色名,便于识别和召唤,如"文档评审官""专家1" | 无指向的名称 |
人设身份 | 写"是谁 + 有什么背景",如"有 10 年经验的后端工程师,熟悉 Go 与 Java" | 写成任务本身,如"帮我写代码" |
擅长领域 | 写清边界,同时说明"做什么"和"不做什么" | "什么都行" |
提示词 | 写工作流程、输出格式与约束,能举例最好 | 只写"您是一个专家" |
"不做什么"这一栏是官方特意点出来的,我认为是新手最容易漏、又最影响效果的一栏。 边界不清的专家,产出就会往你最不希望的方向溢出。
几个必须知道的注意事项:
在专家团会话中搜索召唤其他专家时,会提示"当前会话已使用专家团,切换其他专家需要开启新对话"。确认后会先回到新对话态再完成召唤,新专家不会回绑到当前专家团会话。
这意味着:一个专家团会话只服务一个任务。 规划任务时别指望在一个会话里连做三件事。
场景一 · 对外材料:目标=可对外的方案文档;角色构成=数据分析 + 内容撰写 + 视觉设计;验收标准=口径统一、无内部信息、可直接提交评审。
场景二 · 定期报告:把稳定流程固化成自定义专家,每次召唤同一套口径;角色构成=按报告类型配置 2–3 个即可,不必堆多。
场景三 · 复杂调研:目标=竞品或行业分析;角色构成=信息检索 + 数据分析 + 结构化撰写;这里最省事的是让团长自己拆,你只补背景和边界。
三个场景的共性:目标清晰、材料齐备、验收标准明确。 满足这三条,专家团才发挥得出来。
很多人评估 AI 好不好用,只问"快不快"。这个指标太粗。我现在固定看四个:
指标 | 怎么测 | 说明 |
|---|---|---|
首轮可用率 | 首轮产出可直接进入下一环节的比例 | 比速度更能反映质量 |
返工轮次 | 从首次产出到定稿的对话轮数 | 反映方法是否已固化 |
任务周期 | 从接到任务到交付的自然时长 | 同类任务横向比,别跨任务比 |
单次产出成本 | 积分消耗 ÷ 合格产出数 | 专家团 3–5 倍成本必须计入 |
建议做法是同任务对照:选 3–5 个真实任务,分别用"单专家"和"专家团"各做一遍,记录上表四项,填自己的数:
任务 | 模式 | 首轮可用率 | 返工轮次 | 周期 | 积分消耗 |
|---|---|---|---|---|---|
待填 | 单专家 | 待填 | 待填 | 待填 | 待填 |
待填 | 专家团 | 待填 | 待填 | 待填 | 待填 |
我不给行业均值,因为这类均值几乎没有可信度。 你自己的对照数据才是决策依据。
一个反直觉的经验:单专家和专家团的差距,往往在返工轮次上体现得最明显——专家团首轮未必比单专家惊艳,但定稿往往更快,因为不用你手动拼接和反复补背景。
官方文档有几条免责声明,我认为该认真对待:
我自己的补充四条:
回到开头那个问题:用错 AI 方式,本质上是把"团队协作"这件事当成了"一个人的事"来做。
专家团的意义不是多叫几个 AI 出来围观,而是把拆解、并行、整合这三件原本压在一个人头上的事,交给一个机制去做。你从"既是需求方又是执行者",变成"提出要求 + 验收标准 + 把关事实"——这才是抽得出手的岗位状态。
如果给一个上手顺序,我的建议是三步:
最后说个展望:官方文档提到,专家包可按规范打包提交、供更多用户召唤。这意味着角色配置有机会从"我一个人调好的参数"变成"团队乃至更大人群可复用的资产"。当组织内部沉淀出足够多的高质量角色配置时,AI 办公的竞争点会从"谁会用工具",转向"谁的方法论被沉淀得更完整"——方法论,才是最后那道壁垒。
如果你也踩过专家团的坑,或者跑出了不一样的数据,欢迎在评论区聊聊。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。