WorkBuddy 的专家团和 CodeBuddy 的子代理是一回事吗？都是多角色，但配置方式完全不同

2026-08-16

「多个 AI 角色分工协作」这个概念，同门两个产品都有，但落地方式差得很远：

WorkBuddy：在专家中心点一下召唤专家团，团长自动拆解分配；
CodeBuddy CLI：有独立的 sub-agents 文档，还有一个专门的 delegate 权限模式。

这篇并列双方官方写明的内容。不做优劣判断——两者的形态与受众都不一样，受众到底怎么分，见WorkBuddy 和 CodeBuddy 的定位与人群差异。

依据：WorkBuddy 官方文档《专家中心》（Function-Description/Expert-Center）；CodeBuddy 官方中文文档 cli/sub-agents 与 cli/permission-modes。核对日均为 2026-08-16。我们没有安装任何一方的客户端，本文不含实测数据。

一、WorkBuddy 侧：专家与专家团

专家（官方定义）：

每位专家都拥有独立的人设、方法论和工具链，针对所在领域的典型工作场景深度打磨——召唤谁，就像真的请到了那个岗位的资深从业者。

专家团（官方定义）：

专家团是一个有团长、有分工、有协作的多 Agent 团队。您只需要描述任务，团长会自动拆解、分配给最合适的团员并行执行，最后整合交付——像一个真正的项目组在帮您干活。

用法：左侧边栏点「专家」→ 看卡片（能力介绍、擅长领域、任务示例；专家团额外展示团队成员）→ 点击召唤 → 用自然语言描述任务。

关键点：你不用自己拆任务，团长会做。

二、CodeBuddy CLI 侧：子代理与 delegate 模式

CLI 有独立的 sub-agents 文档（篇幅在整个 CLI 文档体系里属于最长的之一）。

更能说明设计取向的是权限模式那一页里的一档：

模式	官方描述的「不询问就能跑什么」	官方给的适用场景
`delegate`	仅协调类工具（如 Agent / TaskCreate / SendMessage / 团队管理），实现类工具被屏蔽	主代理只做拆派、把执行交给子代理

还有一个相关的模式：

模式	官方说明
`ignore`	仅在子代理（subagent / teammate）场景生效，表示「用主会话的模式，不要被子代理自己的 frontmatter 覆盖」；主会话用不到

从这两条能读出几件事：

CLI 的子代理有自己的 frontmatter（可以带自己的权限配置）；
主代理可以被限制成只做协调（delegate 模式屏蔽实现类工具）；
权限模式的继承关系是可控的（ignore 就是用来控制这个的）。

官方还提到 auto 模式下有一条相关的安全设计：会临时忽略「任意 Agent / Task 规则」这类过宽的 allow 规则——理由官方写得很直白：防止借子代理绕过分类器。

三、并列对照

	WorkBuddy 专家团	CodeBuddy CLI 子代理
形态	产品内置的角色库，卡片式选择	文档化的机制，可配置
怎么用	点击召唤	按 `sub-agents` 文档配置
谁来拆任务	团长自动拆解、分配、并行执行、整合交付	主代理（可用 `delegate` 模式限制成只做拆派）
角色从哪来	官方提供的专家 / 专家团	可配置（有自己的 frontmatter）
权限粒度	跟随任务的权限模式（两档）	子代理可有自己的权限配置，且有 `ignore` 模式控制继承
成本提示	官方明确：积分消耗通常为单个专家的数倍	官方在权限模式页未给积分说明

四、为什么不该画等号

一、一个是「选」，一个是「配」。 WorkBuddy 侧你看卡片挑一个团；CLI 侧你按文档配置子代理。面向的动作完全不同。

二、权限模型的位置不同。 CLI 把子代理和权限模式做了显式绑定（delegate、ignore 两档就是为这个存在的）；WorkBuddy 侧官方文档没有对应的「专家团专属权限模式」说明。

三、这套体系里同名能力两边实现不同是常态。 已确认的例子：权限模式（两档 vs 七种）、定时任务（持久 vs 会话级）、远程控制（IM 机器人 vs 本地 Gateway + Web UI）、记忆（两套独立文档）。「多角色协作」是第五个。

五、WorkBuddy 侧最该记住的一条

官方在召唤专家团时会弹的提示：

积分消耗提醒：专家团可能会调用多位专家协同执行，积分消耗通常为单个专家的数倍。请确认您已了解专家团更高的积分消耗，并确保账户积分充足。

「数倍」这个词值得认真对待——尤其考虑到积分是两个产品共用的（官方：同一账号积分共享），你在专家团上多花的，会让 CodeBuddy 那边可用的变少。

成本策略：官方给了三层选择标准——

维度	Skill	专家	专家团
怎么选	需要某种工具能力	有明确的单点问题	任务复杂，需要多角色配合

官方三句话总结：Skill 是能力；专家是能力+经验；专家团是多位专家+协作流程。

实用做法：从最便宜的那一档开始试——直接对话 → 启用对应 Skill → 召唤单个专家 → 才是专家团。反过来（先上专家团，发现单专家就够了）的浪费不可逆。

六、还有一条使用边界

官方在召唤界面除了积分提醒，还有一条使用提醒：

本专家团会为您收集和整理信息，AI 生成内容仅供参考，无法替代专业判断，不构成决策和投资建议。

「像一个真正的项目组在帮您干活」是比喻，这条提醒才是边界。

具体到日常：法律相关的条款清单可以让它做、法律意见必须律师出；财务数据整理可以做、结论和决策要人来；官方直接点名了不构成投资建议。

一条通用原则：让它做「信息整理」这一层，把「判断和担责」留给人。

七、按官方自述定位的场景归因

强调：这是按双方官方自述的定位做的归因，不是评测结论。

你要的是「一个懂行的角色按专业方法帮我做一件办公上的事」→ WorkBuddy 的专家（官方比喻：像请到了那个岗位的资深从业者）；
你要的是「这活需要好几个角色配合，我自己也不太会拆」→ WorkBuddy 的专家团（团长自动拆解分配）；
你要的是「在开发流程里让主代理只做拆派、执行交给可配置的子代理」→ CLI 的子代理 + delegate 模式，官方场景描述就是这句；
你只是要「让 AI 能做某件事」→ 那答案是 Skill，不是专家，更不是专家团。

八、我们不写的东西

不写谁的多角色能力更强——形态与受众不同，无从比较；
不做「专家团约等于子代理编排」这类等价——一个是内置角色库、一个是可配置机制；
不写 CLI 子代理的详细配置方式——以其官方 cli/sub-agents 文档为准，本文重点在并列关系；
不写具体积分消耗数值——官方只给了「数倍」这个定性描述，我们不编。

小结

WorkBuddy 专家团：产品内置的角色库，点击召唤，团长自动拆解、分配、并行执行、整合交付；卡片上能看到团队成员构成。
CodeBuddy CLI 子代理：独立的 sub-agents 文档体系；权限模式里有两档专门为它服务——delegate（主代理只做拆派，实现类工具被屏蔽）与 ignore（控制子代理是否沿用主会话模式）。
★ 不该画等号：一个是「选」，一个是「配」；权限模型的位置也不同。这套体系里同名能力实现不同已是常态（权限、定时、远程、记忆，这是第五个）。
成本：官方明确专家团的积分消耗通常为单个专家的数倍，而积分是两个产品共用的。
选择顺序：Skill（工具能力）→ 专家（单点问题）→ 专家团（需多角色配合），从最便宜那档开始试。
官方边界提醒：AI 生成内容仅供参考，无法替代专业判断，不构成决策和投资建议。

双方功能与文档表述均以各自官方为准，核对日 2026-08-16。