我倾向于认可这个判断WorkBuddy 的“专家团”并非简单的专家人设 Prompt 集合，而是一套面向办公场景封装的多 Agent 工作流系统。本文从公开资料、产品形态、技术架构等维度深入分析，论证其本质是“专家化包装的多 Agent 工作流系统”，并探讨其底层架构、技术难点与产品价值。

目录

WorkBuddy 的“专家团”不是简单的专家人设 Prompt 集合，更像一套面向办公场景封装好的多 Agent 工作流系统。

更准确地说，它大概率是下面几层能力的组合：

  1. 专家注册表：每个专家有领域、人设、方法论、可用工具、输入输出规范和典型任务模板。
  2. 任务规划器：把用户一句话需求拆成多步任务，判断需要哪些专家参与。
  3. 多 Agent 执行器：并行或串行调用多个专家 Agent，各自处理子任务。
  4. 共享上下文/工件层：专家之间不是简单对话，而是围绕文档、表格、网页、PPT、代码、数据结果等工件协作。
  5. 工具与 Skills 层：通过 MCP、自定义 Skills、网页搜索、文件读写、办公软件接口等执行真实操作。
  6. 汇总与验收层：将多个专家结果合并成最终报告、方案、PPT、表格或代码，并做一致性检查。

所以“专家团”的关键不在于“多几个系统提示词”，而在于：腾讯把常见办公任务的专家分工、执行顺序、工具调用、产物格式和交付标准预置为可调用的业务工作流。

核心观点

  • 核心判断：WorkBuddy 的"专家团"本质上是"专家化包装的多 Agent 工作流系统"，而非简单的专家人设 Prompt 集合。其底层由任务规划器、多 Agent 执行器、共享工件层和验收层构成，通过预置的专家分工与执行顺序实现稳定交付。
  • 技术本质：每个"专家"对应一个结构化的 Agent Profile（含人设、方法论、工具权限、输出 Schema），而非一段自然语言 Prompt；"专家团"则是一套可复用的 DAG（有向无环图），由 Planner 根据用户需求动态编排专家节点。
  • 产品价值：专家团将技术复杂度（Agent Workflow、MCP、Skills、DAG）包装为"请一个团队一起干活"的直观体验，降低用户理解成本，同时便于企业级权限控制、商业化扩展和场景化售卖。
  • 潜在风险：多专家协作可能放大幻觉（未经验证的信息被层层包装）、专家沦为"高级话术"（缺乏真实工具绑定）、办公场景的权限与审计风险高于 C 端聊天，需要配套来源追踪、交叉验证和人工确认机制。

1. 公开资料能确认什么

1.1 官方产品页的能力表达

WorkBuddy 官方页面的核心表达包括：

  • “AI 专家团 全场景办公”
  • “WorkBuddy 是全能 AI 工作台，一人指挥、全行业专家执行，从策略到交付一站搞定”
  • “免部署、安装即用”
  • “多专家、多模型协同”
  • “桌面 / 主流 IM / 小程序”
  • “100+ 领域专家组成你的虚拟团队，运营、设计、数据、开发等全角色场景覆盖”
  • “一句话指令自主规划并交付完整结果”
  • “多专家并行协作，一个人顶一支团队”
  • “MCP 生态 + 自定义 Skills，能力无限扩展”

这些信息来自 WorkBuddy 官网前端资源中的可见文案。它至少说明官方对外强调的不是单 ChatBot，而是“专家角色 + 自主规划 + 多 Agent 并行 + 工具生态 + 交付工件”。

官方入口：

  • https://copilot.tencent.com/work/
  • https://www.codebuddy.cn/docs/workbuddy/
  • https://www.codebuddy.cn/docs/workbuddymini/features/Expert

1.2 专家中心的公开描述

搜索结果中的官方文档摘要提到：

  • 专家中心可为 WorkBuddy 配置专业角色。
  • 专家能在特定领域以更明确的方法和视角完成任务。
  • 支持按专家名称、职称、简介或行业分类浏览专家。
  • 每位专家拥有独立人设、方法论和工具链。
  • 面向所在领域的典型工作场景深度打磨。

这组描述很关键。因为“人设 + 方法论 + 工具链 + 典型工作场景”已经超出了普通 Prompt 模板，更接近可复用的 Agent Skill / Workflow Template。

1.3 场景页暴露出的工作流形态

官网脚本里列出了几个典型场景：

  • OPC 一人公司：运营、设计、财务、法务、开发等核心岗位，多专家并行协作，从策略到交付全程自主完成。
  • 软件开发团队：产品经理定需求、架构师设计和拆任务、工程师批量实现代码、QA 验证质量。
  • 内容创作团队：多模态内容生产，覆盖视频生成、图文创作、智能剪辑和跨语言素材改编。
  • 外部信息调研与内容生成：自动搜集和分析信息，生成调研报告或 PPT。
  • 业务数据洞察与自动化响应：分析反馈、评论、CRM 数据，输出洞察和策略。

这些场景有明显的“流水线”特征：

输入需求
  -> 识别任务类型
  -> 选择专家组合
  -> 拆分子任务
  -> 调用工具采集/处理数据
  -> 生成中间工件
  -> 专家间合并和校验
  -> 输出最终可验收结果

这就是典型的工作流系统，而不是纯聊天产品。

2. 为什么“专家团”更像内部集成工作流

判断一个 AI 产品到底是“角色 Prompt”还是“工作流”，可以看 5 个指标。

2.1 是否有明确的任务分解

普通角色 Prompt：

你是一个资深产品经理，请帮我写 PRD。

工作流系统：

识别需求 -> 追问缺失信息 -> 用户画像 -> 场景拆解 -> 功能列表 -> 优先级 -> 验收标准 -> 风险 -> 输出 PRD

WorkBuddy 官方强调“一句话指令自主规划并交付完整结果”。这里的“规划”意味着它至少存在一个 planner，负责把自然语言需求转成可执行步骤。

2.2 是否有多个专家之间的依赖关系

如果只是 Prompt 集合，专家之间通常没有稳定关系。用户点哪个专家，就哪个专家单独回答。

但 WorkBuddy 的“软件开发团队”场景里，角色顺序天然带依赖：

产品经理定需求
  -> 架构师设计和拆任务
  -> 工程师实现代码
  -> QA 验证质量

这是一条工程工作流。产品经理输出需求，架构师消费需求并输出设计，工程师消费设计并产出代码，QA 消费代码和验收标准并输出测试结论。

这种依赖很难只靠“多开几个聊天窗口”稳定完成，通常需要一个共享状态和调度器。

2.3 是否有工具链绑定

专家中心公开描述中提到“独立人设、方法论和工具链”。官网又提到“MCP 生态 + 自定义 Skills”。

这说明专家不是只改变回答口吻，而是可能绑定不同工具：

  • 调研专家：网页搜索、网页抓取、资料引用、报告生成。
  • 数据专家：表格读取、数据清洗、统计分析、图表生成。
  • 开发专家：代码读取、编辑、测试、Git diff。
  • PPT 专家：大纲生成、版式组织、素材处理。
  • 运营专家：用户反馈分类、竞品拆解、营销文案生成。

“专家 = 角色 + 工具权限 + 输出协议”比“专家 = Prompt”更合理。

2.4 是否以工件交付为中心

普通 ChatBot 的交付物是回答文本。

WorkBuddy 的产品文案强调调研报告、PPT、代码、视频/图文素材、数据洞察报告、销售策略和完整结果。这些是结构化工件。

工件型交付通常需要：

  • 文件系统或对象存储
  • 版本化中间产物
  • 专家之间引用同一份材料
  • 最终汇总器
  • 格式化导出

这进一步指向工作流。

2.5 是否支持并行

“多专家并行协作”是关键证据。

并行意味着系统不是一个模型顺序扮演多个角色，而更可能是：

planner
  -> expert_A_task
  -> expert_B_task
  -> expert_C_task
  -> reducer / synthesizer

这种模式在工程上就是 DAG 或任务队列。每个专家处理独立子任务，最后由汇总节点合并。

3. 一个可能的底层架构

下面是我对 WorkBuddy 专家团的技术架构推断。

用户入口
  - 桌面端
  - 企业微信 / 飞书 / 钉钉 / 微信等 IM
  - 小程序

任务理解层
  - 意图识别
  - 任务类型分类
  - 缺失信息检测
  - 风险分级

规划层 Planner
  - 生成任务 DAG
  - 选择专家组合
  - 决定串行/并行
  - 分配工具权限
  - 设定输出格式

专家层 Experts
  - 产品经理专家
  - 架构师专家
  - 开发工程师专家
  - QA 专家
  - 数据分析专家
  - 运营专家
  - 设计专家
  - 法务/财务等垂直专家

工具层 Tools / MCP / Skills
  - 搜索和网页读取
  - 文件读写
  - 表格处理
  - PPT 生成
  - 代码编辑和测试
  - IM 消息收发
  - 企业内部系统连接器
  - 自定义 Skills

状态层 State / Artifacts
  - 会话记忆
  - 项目上下文
  - 中间产物
  - 专家输出
  - 引用来源
  - 用户确认点

验收层 Evaluator
  - 格式检查
  - 事实一致性检查
  - 风险提示
  - 多专家冲突合并
  - 最终交付

这套架构和当前主流 Agent 框架的范式是相通的：

  • LangGraph 常见做法是用 graph/state 表达多 Agent 流程，supervisor 决定下一步交给哪个 agent。
  • AutoGen/CrewAI 一类框架强调多角色 Agent 协作，通过对话、任务和工具完成复杂目标。
  • MCP 解决的是模型与外部工具/数据源连接的标准化问题。
  • Skills 则像是本地可安装的能力包，把 prompt、脚本、模板、工具约束和领域流程固化下来。

WorkBuddy 的优势在于它不是把框架裸露给用户，而是把这些能力产品化成“专家团”。

4. “专家”的技术本质：不是一个 Prompt，而是一个 Agent Profile

一个成熟的专家定义，大概率包含以下字段：

{
  "id": "product_manager",
  "name": "产品经理",
  "domain": ["需求分析", "PRD", "用户故事"],
  "persona": "资深 B 端产品经理",
  "methodology": [
    "先澄清目标和用户",
    "再拆业务流程",
    "最后输出功能列表和验收标准"
  ],
  "tools": [
    "web_search",
    "document_reader",
    "prd_template_writer"
  ],
  "output_schema": {
    "prd": "markdown",
    "open_questions": "array",
    "risk_list": "array"
  },
  "guardrails": [
    "不编造用户数据",
    "缺少业务背景时先列假设",
    "涉及法务或财务时转交对应专家"
  ]
}

这类结构的价值是：每个专家都能被 planner 稳定调用、被 evaluator 检查、被其他专家消费。

如果只有自然语言 Prompt，就很难做到稳定编排。

5. “专家团”的技术本质：一套可复用 DAG

以“生成一份竞品调研 PPT”为例，专家团可能不是这样运行：

让一个模型扮演调研专家，直接写 PPT

更可能是：

用户：帮我做 XX 产品的竞品分析 PPT

Planner:
  - 判断任务类型：外部调研 + PPT 生成
  - 选择专家：行业研究、竞品分析、数据整理、PPT 策划、设计排版
  - 生成任务图

Research Expert:
  - 搜索公开资料
  - 提取公司/产品/价格/功能/用户评价
  - 输出引用来源和摘要

Analysis Expert:
  - 归纳竞品维度
  - 做 SWOT / 功能矩阵 / 差异化判断

Content Expert:
  - 把分析结果转成 PPT 叙事结构

Design Expert:
  - 选择页面结构和视觉风格

Synthesizer:
  - 合并结果
  - 输出 PPT 大纲、页面文案和图表建议

Evaluator:
  - 检查引用是否缺失
  - 检查结论是否过度推断
  - 检查页面是否覆盖用户目标

这就是“内部集成的工作流”。

专家团只是用户看到的产品形态；底层真正有价值的是任务图和专家节点。

6. 为什么腾讯会选择“专家团”这种产品表达

6.1 降低用户理解成本

“Agent Workflow / DAG / Tool Calling / MCP / Skills”对普通办公用户太抽象。

但“请一个产品经理、架构师、设计师、数据分析师一起干活”非常直观。

专家团是对技术复杂度的产品化包装。

6.2 更符合企业组织心智

企业工作本来就是角色协作：

  • 需求给产品
  • 方案给架构
  • 实现给开发
  • 验证给 QA
  • 传播给运营
  • 风险给法务

WorkBuddy 把 AI 能力映射到企业组织结构，用户自然知道该怎么用。

6.3 便于售卖和扩展

专家比“Prompt 模板”更容易被包装成资产：

  • 100+ 专家
  • 行业专家包
  • 企业私有专家
  • 自定义专家
  • 内部知识库专家
  • 部门级工作流

这也更适合企业商业化。

6.4 便于做权限和审计

不同专家可以绑定不同工具权限。

例如：

  • 法务专家只能读合同模板，不能发外部消息。
  • 财务专家可以读表格，但不能改原始账目。
  • 开发专家可以读代码，但提交前需要人工确认。

在企业环境里，这比一个全能 Agent 到处乱跑更可控。

7. 技术实现的难点

7.1 Planner 稳定性

用户一句话往往很模糊。Planner 要判断：

  • 这是调研、写作、开发、数据分析，还是混合任务？
  • 是否需要追问？
  • 能不能直接执行？
  • 哪些步骤可以并行？
  • 哪些步骤必须等待用户确认？

Planner 一旦拆错，后面专家再强也会跑偏。

7.2 上下文共享和冲突处理

多专家并行会带来冲突：

  • 调研专家说 A 产品主打低价。
  • 数据专家发现价格其实比竞品高。
  • PPT 专家为了表达好看，把结论写得过满。

系统需要一个 reducer / synthesizer 处理冲突，而不是简单拼接。

7.3 工具调用的可靠性

办公任务不是纯文本生成。它需要读网页、读文件、处理表格、生成 PPT、调用 IM、调用内部系统。

真实工具调用会遇到：

  • 登录态失效
  • 页面结构变化
  • 文件权限不足
  • 网络失败
  • API 限流
  • 数据格式异常

所以 WorkBuddy 如果要稳定交付，必须有重试、降级、错误归因和用户确认机制。

7.4 事实和来源治理

专家团越像团队，越容易让用户相信它“已经核实过”。

因此必须处理：

  • 哪些结论来自公开资料？
  • 哪些是模型推断？
  • 哪些需要人工确认？
  • 哪些来源过期？
  • 多个来源冲突时如何处理？

硬核一点说，专家团产品真正的壁垒不只是多 Agent，而是 citation、provenance、artifact lineage。

也就是：每个结论从哪里来，经过哪个专家处理，最后如何进入交付物。

7.5 成本和延迟

多专家并行听起来很美，但成本会增加：

  • 多模型调用成本
  • 搜索/工具调用成本
  • 中间产物 token 成本
  • 汇总和校验成本
  • 长任务等待时间

所以产品上很可能会做任务分级：

  • 快速模式：少量专家，轻规划，低成本。
  • 标准模式：多专家协作，完整交付。
  • 深度模式：更多搜索、更多校验、更多中间工件。

官网场景里提到“小需求支持快速模式”，这个也印证了它可能存在不同执行策略。

8. 和传统办公自动化的区别

传统 RPA / 自动化工作流：

固定触发器 -> 固定流程 -> 固定动作

专家团式 Agent 工作流：

自然语言目标 -> 动态规划 -> 选择专家 -> 调用工具 -> 生成工件 -> 自检交付

区别在于：

  • RPA 强在确定性，弱在理解模糊目标。
  • Agent 工作流强在开放任务，弱在稳定性和可控性。
  • WorkBuddy 的专家团看起来是在中间取平衡：用预置专家和场景工作流约束 Agent 的自由度。

这是比较务实的路线。

完全开放的 Auto Agent 容易跑飞；完全固定的 RPA 又不够智能。专家团通过“专家角色 + 场景模板 + 工具权限 + 工作流编排”把问题压到一个可产品化的范围。

9. 如果我们复刻一个“专家团”，最小可行架构怎么做

不需要一上来做 100 个专家。最小可行版本可以是 5 个核心组件。

9.1 Expert Registry

定义专家元数据：

  • 专家名称
  • 擅长任务
  • 系统提示词
  • 方法论
  • 工具白名单
  • 输出 schema
  • 失败处理策略

9.2 Planner

输入用户需求，输出任务图：

{
  "goal": "生成竞品分析报告",
  "experts": ["researcher", "analyst", "writer", "reviewer"],
  "tasks": [
    {"id": "collect", "expert": "researcher", "parallel": true},
    {"id": "analyze", "expert": "analyst", "depends_on": ["collect"]},
    {"id": "write", "expert": "writer", "depends_on": ["analyze"]},
    {"id": "review", "expert": "reviewer", "depends_on": ["write"]}
  ]
}

9.3 Shared Artifact Store

保存中间结果：

  • 搜索结果
  • 原始资料
  • 表格
  • 草稿
  • 版本 diff
  • 专家评审意见

9.4 Executor

根据 DAG 执行任务：

  • 可并行的任务并行跑。
  • 有依赖的任务等待上游。
  • 工具调用失败时重试或降级。
  • 高风险动作需要人工确认。

9.5 Synthesizer / Evaluator

最终汇总：

  • 去重
  • 统一口径
  • 标注假设
  • 标注来源
  • 检查格式
  • 生成最终文件

这就是专家团的骨架。

10. 对 WorkBuddy 的产品判断

10.1 它的真正卖点不是“专家很多”

“100+ 专家”本身不难做。难的是：

  • 哪些专家组合适合哪些任务？
  • 专家之间如何交接？
  • 输出如何合并？
  • 工具权限怎么控制？
  • 交付物怎么验收？

如果这些没做好，专家越多越混乱。

WorkBuddy 真正要验证的是“专家团是否能稳定交付完整工件”。

10.2 它可能是腾讯云 CodeBuddy / OpenClaw 能力的办公化包装

公开资料里提到 CodeBuddy、MCP、自定义 Skills、多 Agents、桌面端和主流 IM。

这说明 WorkBuddy 很可能不是从零做一个办公聊天机器人，而是把已有的 Agent runtime、工具系统、技能系统、桌面控制和 IM 入口组合起来，面向办公场景重新包装。

从工程角度，这是合理路线：

  • CodeBuddy 提供代码/开发 Agent 经验。
  • OpenClaw 类 runtime 提供长任务、工具、Skills、会话、定时等能力。
  • MCP 提供外部工具连接标准。
  • WorkBuddy 提供办公用户入口和专家团产品形态。

10.3 用户看到的是专家，系统运行的是工作流

这是最关键的一句话。

用户感知：

我叫来了一个专家团。

系统实现：

Planner 选择了一组专家节点，按 DAG 调度工具调用和中间工件，最后由 Synthesizer 汇总交付。

“专家团”是产品语言，“工作流”是工程语言。

11. 风险和局限

11.1 专家可能变成“高级话术”

如果某些专家只是换了个系统提示词，没有真实工具和输出 schema，那它的价值会很有限。

判断方式：

  • 是否能处理真实文件？
  • 是否能稳定输出结构化结果？
  • 是否能引用来源？
  • 是否能接入用户业务系统？
  • 是否能把工作交给下一个专家继续处理？

11.2 多专家可能增加幻觉

多 Agent 不自动等于更可靠。

如果每个专家都在生成未经验证的信息，最后汇总只会把幻觉包装得更像真的。

所以专家团必须配套：

  • 来源追踪
  • 反事实检查
  • 交叉验证
  • 人工确认点
  • 高风险动作拦截

11.3 办公场景的权限风险比 C 端聊天更高

办公 Agent 一旦能读文件、发消息、改表格、调用系统，就必须处理：

  • 权限最小化
  • 操作审计
  • 敏感数据脱敏
  • 外发确认
  • 企业策略控制

否则“专家团”会变成一个权限过大的自动化入口。

12. 最终判断

WorkBuddy 的专家团，本质上应该看成：

预置专家角色
  + 领域方法论
  + 工具权限
  + MCP / Skills 扩展
  + 多 Agent 调度
  + 场景化工作流模板
  + 工件交付和验收

它不是单纯的“专家 Prompt 商店”，也不是完全自由的 Auto Agent。

更像是腾讯把办公场景中常见的团队协作流程，抽象成一个个可调度的 AI 专家节点，再用工作流引擎把它们串起来。

所以你的判断“内部集成的工作流”是有技术依据的。

但要更精确一点：它应该是“专家化包装的多 Agent 工作流系统”。

这个方向的长期壁垒不在于模型本身，而在于：

  • 专家定义质量
  • 工作流模板沉淀
  • 工具和企业系统连接
  • 中间工件管理
  • 权限与审计
  • 事实来源治理
  • 最终交付可验收性

如果 WorkBuddy 能把这些做好，它就不是“更会聊天的 AI 助手”，而是一个真正能进入办公生产链路的 Agent 操作系统雏形。

参考资料

  • WorkBuddy 官网：https://copilot.tencent.com/work/
  • WorkBuddy 文档入口：https://www.codebuddy.cn/docs/workbuddy/
  • WorkBuddy 小程序专家中心文档：https://www.codebuddy.cn/docs/workbuddymini/features/Expert
  • 腾讯云开发者社区 WorkBuddy 相关文章：https://cloud.tencent.com/developer/article/2642946
  • 腾讯云开发者社区 WorkBuddy 自动化实践：https://cloud.tencent.com/developer/article/2663996
  • 掘金 WorkBuddy 专家团实测文章：https://juejin.cn/post/7638529212292907059
  • Model Context Protocol：https://modelcontextprotocol.io/
  • LangGraph 多 Agent / Graph 思路：https://docs.langchain.com/
  • Microsoft AutoGen 多 Agent 思路：https://microsoft.github.io/autogen/
  • CrewAI Agent / Task / Crew 思路：https://docs.crewai.com/

我是 Koen / 任我坤，7 年 Java 后端，正在做全栈和独立开发。
长期分享 Java 源码、后端架构、AI 工程化和个人工具产品。
个人主站：https://koen.songyuankun.top
工具箱：https://tools.songyuankun.top

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

我做了一个 AI 原生安全测试 Skill：让 Claude Code/Cursor 直接进入安全工程模式

avatar 亚马逊云科技技术品牌专区

2026年AI编程工具排行榜：10款主流产品深度横评，谁才是真正的提效之王

三个月实测10款AI编程工具，从代码生成质量、Agent能力、过程可控性、性价比、IDE兼容性五个维度打分排名。文心快码以SPEC规范驱动+Multi-Agent矩阵在可控性上拉满，附完整对比表和选型建议。

avatar 亚马逊云科技技术品牌专区
cover

深入理解 AI Agent · MCP 子系列 #02：MCP Server 开发实战—从工具注册到无状态新规范

avatar 亚马逊云科技技术品牌专区