专家团队
📖 适合谁：YingClaw 客户端用户 / 业务团队——手里有一批反复要做、又要讲专业套路的工作(写文案、做投研、审合同、跑数据分析),想把它固化成一个"随叫随到的角色"的人
📖 阅读时长：7 分钟
📖 一句话：把"一个角色化的 AI 助手"沉淀成可复用、可安装、可发布的资产。专家 = 一个有人设+一组技能的 Agent;专家团 = 一个主理人带若干成员,主理人拆活派活,成员各按自己的人格执行。入口在 YingClaw Web 控制台侧边栏「专家团队」(路由 /expert)。
一、主要能力
| 能力 | 说明 |
|---|---|
| 创建专家 | 写一个角色化的 AI 助手:人设 + 技能集 + 开场白 + 工作流 |
| 创建专家团 | 选主理人 + 加成员,每个成员都有独立人设,主理人负责拆活派活 |
| 两种创建方式 | 表单向导(字段清晰,适合心里有数的人)或 对话创建(把需求说给 AI,它会引导你) |
| AI 引导生成 | 通过内置的 expert-manager 技能,用对话逐步问清需求,再生成专家或专家团 |
| 技能选择器 | 四个技能来源统一挑:本地 / 营域 / 腾讯 / 魔搭 |
| 工作流编排 | 把"先做什么再做什么"写成结构化步骤,运行时作为"强制执行的专家工作流"注入 |
| 团队协作 | 主理人常驻上下文,成员按需加载——主理人派活时才读成员人设,避免上下文塞满 |
| 导入导出 | 支持 ZIP 包导入导出,方便分享和备份 |
| 发布到市场 | 把调好的专家发布到专家市场,供其他人发现和安装 |
| 版本更新 | 已安装的专家有新版本时可一键升级 |
| 市场浏览 | 按"类型"(专家/专家团)和"行业"筛选,看下载量、收藏量、版本数 |
二、典型应用场景
- 固化高手套路：团队里最会写某类内容的人要离职,把他"选题→钩子→结构→合规检查"的套路做成专家,以后人人调用都是同一水准。
- 一人公司扩能力：一个人不可能同时懂投研、法务、设计,装几个现成专家等于低成本补齐能力短板。
- 多角色会审：合同要同时过"法务视角"和"业务视角",建一个专家团,主理人把合同派给两位成员分头审,再汇总成一份意见。
- 专业产出有保障：专家团的协作协议强制"成员结论为准",主理人只做编排与汇编,不能跳过派活自己代笔。
- 按行业挑现成的：需求不明确时先去市场按行业分类逛,装一个回来试,比从零写人设快得多。
- 沉淀可复用资产：好不容易调好的专家发布到市场,团队其他同事直接安装,不用每人重配一遍。
三、界面与操作
1. 入口
| 项 | 说明 |
|---|---|
| 主入口 | Web 控制台侧边栏「专家团队」(路由 /expert) |
| 页面标题 | 列表页标题为「专家」,含三个 Tab:市场 / 已安装 / 已发布 |
| 直接使用专家 | 路径 /agent?expert=<专家名>&prompt=<首问>——从详情页点「使用专家」直达 |
| 对话创建 | 路径 /agent?skill=expert-manager&prompt=...,触发语「引导我创建一个专家或专家团」 |
| 对话编辑 | 路径 /agent?skill=expert-manager&edit=<专家名>&prompt=...,触发语「帮我修改专家 {名称},完整需求已放在草稿」 |
专家与专家团目前只在 Web 控制台与对话页使用,不走微信/钉钉/飞书等 IM 渠道,也没有独立的 CLI 命令。
2. 市场页筛选
- 类型筛选:全部 / 专家 / 专家团
- 行业分类 chips:产品设计 / 工程研发 / 游戏空间 / 数据与 AI / 营销增长 / 内容创作 等
- 排序:最新 / 热度 / 收藏量
3. 表单向导字段
| 区块 | 字段 |
|---|---|
| 基础信息 | 名称、展示名、职业、简介、标签(擅长领域)、开场白 |
| 类型切换 | 专家 / 专家团 |
| 技能选择 | 四平台技能源 Tab:本地 / 营域 / 腾讯 / 魔搭 |
| 团队字段(选专家团时出现) | 主理人 + 成员(可动态增删) + 团队工作流程 |
| 人设与流程 | 人设正文、工作流步骤 |
选专家团时,会多一个"团队工作流程"字段——AI 可根据需求自动编排阶段。
4. 专家目录结构
每个专家 = 一个目录,路径 experts/<名称>/,包含:
experts/<名称>/
├── .codebuddy-plugin/plugin.json # 元数据:名称、版本、类型(agent/team)、主理人、成员列表、工作流
├── agents/<名称>.md # 人设文档(YAML 头 + Markdown 正文),运行时作为系统提示注入
├── skills/ # 该专家选中的技能副本
├── avatars/ # 头像
├── workflow.json # 工作流步骤定义
└── settings.json # 仅专家团:指向主理人
专家团在此基础上多两样:agents/ 目录里会有主理人人设和每个成员的人设;plugin.json 多一个 teamInfo 字段标明成员列表。
5. 团队是怎么协作的
| 环节 | 机制 |
|---|---|
| 谁调度 | 主理人。会话启动时只注入主理人的人设,成员人设不进主会话——避免上下文塞满 |
| 怎么派活 | 主理人用"委托"工具把子任务派给成员。派活时系统读该成员的人设作为子任务的系统提示——成员以自己的人格执行 |
| 结果怎么汇总 | 成员产出回传主理人,主理人汇总。成员之间不直接通信 |
| 有没有投票 | 没有。只有"主理人派活 → 成员产出 → 主理人汇编"这一条链 |
| 并行还是串行 | 由主理人调度决定——独立任务可并行,工作流阶段通常串行 |
协作协议里写进了 5 条铁律:主理人必须亲自发起、不得代写成员产出、成员之间不直连、成员结论为准、不得把主理人自己当成员派出去。
6. 卡片与详情
专家卡片:展示名称、展示名、职业、简介、标签。专家团额外显示团队徽标 + ·N人。卡片动作按状态变化(安装/已安装/有更新)。
详情弹窗分区
| 分区 | 内容 |
|---|---|
| About(概览) | 简介与基础信息 |
| Try Asking Me(试试这样问我) | 推荐问题,点一下直接开聊 |
| Workflow(流程编排) | 工作流步骤 |
| Specialties(擅长领域) | 标签 |
| Team Members(团队成员) | 仅专家团;列出主理人与成员,主理人带紫色「主」标签 |
| Skills(技能) | 该专家绑定的技能 |
| 版本历史 | 版本与变更日志 |
其他弹窗:更新版本、发布、导入。
别混淆:Web 里另有一组「团队」相关组件(创建团队/团队卡片/团队详情),那是技能共享团队(带团队 ID 与权限),不是专家团。两者名字像,功能不同。
四、怎么使用
| 场景 | 步骤 |
|---|---|
| 从市场装一个专家 | 专家团队 → 市场 Tab → 选类型/行业 → 点安装 |
| 表单创建一个专家 | 专家团队 → 表单创建 → 填 5 个区块字段 → 提交 |
| 对话创建一个专家 | 专家团队 → 对话创建 → 跟 AI 说需求 → AI 追问并生成 |
| 创建一个专家团 | 选「专家团」类型 → 选主理人 → 动态加成员 → 配置团队工作流 |
| 使用一个已装专家 | 详情页点「使用专家」 → 跳到对话页 → 提问题 |
| 把专家发布到市场 | 详情页 → 发布 → 填版本号和说明 → 提交 |
| 升级已安装的专家 | 已安装 Tab → 找「有更新」→ 点升级 |
五、小贴士
- 需求模糊就用「对话创建」：人设七成决定专家好不好用。心里没底时把需求讲给 AI 听,它会追问关键信息再生成,比自己在表单里瞎填快。
- 命名用 kebab-case：名称用短横线连接的小写英文;团队的主理人文件固定形如
<团队名>-team-lead;别用叠字或随机字符。 - 主理人的"职业"别写"团长"：同理,别写"主理人""Team Lead"。用调度风格的职位(投研主编 / 交付总监)——这会直接影响主理人的语气与自我定位。
- 人设按五段结构写：角色定义 → 核心能力 → 工作流程 → 输出规范 → 行为约束。只写"你是一名
{职业}"的通用人设,产出会很平庸。 - 技能只能从真实列表里选：技能选择器提供的才是可用的。不要在手写人设里编造不存在的技能名,运行时找不到会静默失效。
- 流程写工作流,不写人设正文：工作流会以"强制执行的专家工作流"注入,带状态和数据传递规则。"先干什么后干什么"写成工作流,不要塞在人设正文里。
- 团队少而精：2~3 名成员足够覆盖大多数会审场景。成员人设按需加载,人数越多主理人拆活与汇总的负担越大。
- 别让成员之间直接通信：协作协议明确成员不直接通信。如果你的流程需要"A 的产出给 B 当输入",在工作流里写清楚,由主理人中转。
- 看派活质量,不看主理人代写：主理人有没有真的派活、有没有代写,是团队成败关键。如果发现主理人自己把活干了,回头强化人设里的"成员结论为准"。
- 专家团 ≠ 技能共享团队：站内还有"团队"组件是技能共享用的(带团队 ID 与权限),不是专家团。名字像,功能不同,别混。