专家团最佳实践

专家团适合需要多个专业视角、存在明确交接步骤的任务。要得到稳定的结果，先定义交付目标，再安排成员分工，最后由主控复核并形成一份完整交付物。

本文提供三个可照着配置的案例，每个包含 1 位主控和 4 位成员。这些是配置与任务示例，实际结论和执行结果以本次使用的资料、能力及验证记录为准。

如果还没有创建过专家团，先阅读 专家团，完成基础操作后再使用下面的配置。

先把分工写清楚

主控负责理解目标、选择成员、传递上下文、复核和汇总。成员只处理主控分配的专业任务，并把结果返回主控；成员之间不会直接通信，也不会自行调用其他成员。

因此，工作安排应明确三件事：

1. 什么时候调用谁：根据任务和职责选择必要成员，不要求每次全员参与。
2. 前一步交给后一步什么：主控传递相关资料、前置结果和待解决问题，不能假设成员看过其他成员的对话。
3. 什么才算完成：每个成员都有可检查的产出，主控按统一标准验收。

独立任务可以并行，依赖前置结论的任务按顺序执行。画布上的连线和节点位置只表达协调关系；需要遵守的先后顺序必须写进“主控工作安排”。

下面的三种安排分别适合不同任务：

把案例配置到 POCO

下面的步骤用于专业模式中的私有专家团。办公模式可以选择已安装的公共专家团，创建和调整编排需切换到专业模式。

1. 在“场景专家”中准备四个已启用的单个 Agent。优先使用已有专家；缺少对应专家时，再创建并配置其指令和必要能力。同一个 Agent 不能在团队里重复添加，也不能把另一个专家团作为成员。
2. 进入“专家团”，点击“新建专家团”，把四个 Agent 加入画布。
3. 在“团队设置”中填写名称，以及“这个团队负责什么”。这一项说明服务对象、任务范围和交付结果；具体步骤写入主控工作安排。
4. 编辑成员节点，将案例表格中的角色填入“团队内称呼”，将职责填入“在这个团队里主要负责什么”。分工说明只影响当前专家团，不会替成员增加原本没有的能力。
5. 编辑主控节点，将案例中的安排填入“主控工作安排”。引用具体成员时，在编辑器中输入 @，从列表选择实际成员；文中的角色名称用于说明分工，需要对应到你已加入的成员。
6. 检查成员能否访问所需文件、数据源或仓库，并完成连接器授权。模型和连接器账号在原专家中设置；修改指令、技能或能力后，重新保存团队编排。
7. 点击“保存并试运行”，提交案例中的任务输入。也可把任务输入保存为“提问示例”，供以后复用；点击提问示例只会填入输入框，需要补齐本次资料后再发送。

每次委派任务时，主控至少应传递以下内容：

本次目标：需要解决什么问题。
子任务：本成员负责的范围，以及不需要处理的内容。
输入资料：文件位置、相关数据或可访问的来源。
前置结果：已确认的结论、关键依据和仍未解决的问题。
约束条件：时间范围、统计口径、修改范围或其他限制。
返回要求：结论、证据、交付文件、风险和待确认项。

成员有数据查询、网页访问或文件生成任务时，应在原 Agent 中配置相应能力。仅修改角色名称或职责，不会让成员获得这些能力。

案例一：行业调研与竞品分析

适用任务与输入

适合产品负责人评估新方向、梳理行业趋势或比较竞品。准备目标用户、研究问题、竞品名单、时间范围及可使用的资料；需要补充在线资料时，给研究与核查成员配置网页访问能力。

团队名称：行业与竞品研究团。

这个团队负责什么：帮助产品团队研究指定行业和竞品，以可追溯的资料形成对比报告和产品建议，区分事实、推断与待验证事项。

四位成员的职责

以下职责可分别填入成员的分工输入框。

主控工作安排

你负责交付一份能支持产品决策的行业与竞品报告。

1. 先确认研究问题、目标用户、竞品名单、时间范围和可用资料。
   影响比较口径的关键信息缺失时，先向用户确认。
2. 将同一份背景和比较口径分别交给行业研究员、竞品分析师。
   两项研究互不依赖时并行进行，每位成员返回结论、来源、日期和待确认项。
3. 收齐研究结果后，将关键结论、引用和有冲突的内容交给事实核查员。
   对价格注明币种、计费周期及查询日期；无法确认的内容保留为待验证项。
4. 根据核查意见，请相关研究成员修正具体问题。
   将核查后的材料交给报告编辑，不要求编辑自行补充未核实事实。
5. 复核报告是否回答用户的问题，并统一交付结论、证据、建议和资料局限。
   建议应说明适用前提，不将市场推断写成确定结果。

这里的并行只发生在行业研究和竞品分析之间，事实核查必须等相关材料完成，报告编辑必须使用经过核查的结果。

可直接使用的任务输入

发送前，将产品 A、B、C 替换为实际名称或链接，并附上内部产品介绍。

我们计划面向 20–100 人的电商团队提供智能客服产品。
请基于附件中的产品介绍，以及产品 A、产品 B、产品 C 的公开资料，
研究最近 12 个月的客户需求与产品变化。

比较维度：目标用户、核心功能、价格、接入方式和使用门槛。
价格请注明查询日期、币种和计费周期。
资料无法确认时标注待验证，不推算市场份额。

请交付一份 Markdown 报告，包含：
1. 面向负责人阅读的结论摘要。
2. 行业变化及对应来源。
3. 三个竞品的统一维度对比。
4. 三条优先考虑的产品建议及理由。
5. 信息缺口和下一步验证事项。

验收标准

• 关键结论、数字和价格都有对应来源与日期，引用能支持相关表述。
• 三个竞品使用相同的比较口径，缺失信息明确标注。
• 报告能说明每条建议来自哪些观察，以及仍需要验证什么。
• 事实核查发现的问题已修正，无法核实的内容保留不确定性。

案例二：经营数据复盘

适用任务与输入

适合月度经营复盘、转化变化分析或活动效果总结。准备两个可比周期的数据、指标定义和业务事件记录；使用数据库时，给需要查询的成员配置对应连接器与账号。

团队名称：经营复盘与行动建议团。

这个团队负责什么：帮助运营负责人核验经营数据，解释指标变化，形成有依据且可验证的行动建议，不把相关性当作因果结论。

四位成员的职责

主控工作安排

你负责交付可复算的经营复盘和可执行的行动建议。

1. 确认复盘周期、对比周期、业务目标和指标定义。
   先请数据核验员检查资料，返回口径、问题和可用范围。
2. 数据问题会影响核心结论时，先向用户确认处理方式。
   不让其他成员基于未经核验的数据给出确定结论。
3. 将可用数据、已确认口径和数据质量说明交给指标分析师。
   要求保留公式与计算明细，明确百分比变化和百分点变化的区别。
4. 将指标结果与业务事件记录交给业务诊断员。
   原因判断必须区分已证实事实、原因假设和需要继续验证的内容。
5. 将诊断结果及证据强度交给行动规划员。
   资料不足的方向可以提出验证计划，但不能写成已确认的改进措施。
6. 请数据核验员复核最终报告中的关键口径和数字。
   由你统一交付变化摘要、原因分析、行动清单及未验证事项。

本案例按前置依赖推进。分析、诊断和规划都需要接收前一步的结果，不能为了同时调用成员而跳过数据核验。

可直接使用的任务输入

请复盘 2026 年 6 月的经营情况，与 2026 年 5 月对比。
附件包含两个周期的订单明细、渠道流量、指标定义和活动记录。

收入按指标定义中的实收口径统计，退款单独列示；
转化率分母使用同期渠道访客数，不把订单数当作购买人数。
如附件中的字段不足以计算某个指标，请指出缺少什么，不自行补值。

重点回答：
1. 收入、订单量、客单价和转化率分别怎样变化？
2. 哪些渠道或商品对变化贡献最大？
3. 可能原因有哪些，哪些已经有证据支持？
4. 下个月优先验证或执行哪三项行动？

请交付 Markdown 复盘报告和关键指标计算明细。
每项行动写明建议负责人、执行步骤、验证指标和前提条件。
本次只做分析与建议，不修改源数据或业务配置。

验收标准

• 报告写清两个周期的数据范围、指标公式和质量问题，关键数字可复算。
• 同比、环比、百分比与百分点的表达与计算一致。
• 原因假设能关联到数据或业务记录，未证实的原因明确标注。
• 三项行动都有验证指标和适用前提，源数据与业务配置保持原状。

案例三：软件需求交付

适用任务与输入

适合跨前后端的小型功能开发。准备需求描述、仓库位置、现有接口、界面约束和允许执行的检查命令，并确保开发与审查成员能访问对应文件和工具。

团队名称：软件需求交付团。

这个团队负责什么：帮助研发团队把明确需求转化为范围受控的代码变更，由成员完成需求梳理、前后端实现和质量审查，交付实际变更及验证说明。

四位成员的职责

主控工作安排

你负责在用户授权的范围内交付功能变更和验证说明。

1. 先请需求分析师阅读需求与相关代码，明确验收标准、接口契约和改动范围。
   关键歧义或项目规定需要确认时，先向用户确认，再进入实现。
2. 将相同的接口契约和验收标准交给前端开发者与后端开发者。
   为双方划定文件范围；共享文件由你指定一位成员负责。
3. 契约已确认且文件范围互不冲突时，可以并行开发。
   前端依赖尚未明确的后端行为时，先完成相关后端定义再安排前端。
4. 每位开发者返回实际修改文件、实现要点和已有检查结果。
   不允许未经协调同时修改同一文件，也不扩大需求范围。
5. 将需求、最终契约和实际变更交给质量审查员。
   发现问题时，把具体位置和修正要求交回负责成员，修正后复核相关问题。
6. 汇总完成内容、修改文件、执行过的验证和未验证事项。
   未获得对应授权时，不提交、推送或发布。

前后端并行的前提是接口约定清楚、修改范围互不冲突。主控需要主动传递接口变化与实现结果，成员不会自动接收其他成员的讨论。

可直接使用的任务输入

发送前，补齐仓库路径、真实接口和状态取值，并确认允许执行的检查命令。

请为现有任务列表增加按状态筛选，仓库位置为【填写路径】。
现有列表接口为【填写接口】，状态取值使用项目现有定义。

要求：
1. 默认展示全部状态，选择某个状态后只展示对应任务。
2. 切换筛选时回到第一页，并保留当前搜索词。
3. 后端按状态过滤后，再按现有规则返回分页数据与总数。
4. 前端复用现有控件、主题变量和翻译方式，覆盖加载、空结果和错误状态。
5. 不调整其他列表功能，不增加依赖。

请先阅读相关实现，给出接口契约、修改文件和验收标准，
待我确认后再实现。实现后运行【填写允许执行的已有检查命令】，
不得新增或修改测试代码，不启动开发服务，不使用浏览器验证。
本次不提交、不推送、不发布。

交付时说明实际变更、检查结果，以及尚未完成的人工验证。

验收标准

• 筛选参数、状态取值、分页总数与前后端实现保持一致。
• 切换状态保留搜索词并重置页码，已有列表行为不受影响。
• 变更仅覆盖确认的范围，共享文件没有相互覆盖的修改。
• 已执行检查记录真实结果；未验证的交互、接口联调和移动端体验明确列出。

让专家团稳定复用

先试运行，再固定工作方式

首次试运行时，检查成员是否收到必要资料、前置结果是否传给后续成员，以及最终产出是否满足验收标准。只针对暴露的问题调整职责或主控安排，再重新保存编排。

例如，报告编辑缺少来源，主控应在交接时附上引用；分析师给出错误口径，先检查数据核验结果与委派内容。调整具体交接要求，比给所有成员重复添加笼统指令更有效。

按任务选择成员

上述完整任务会用到四位成员，但追问某个指标公式或修改已核查报告的表达时，只需调用职责相关的成员。简单问题也可以由主控直接回答。成员数量应服务于交付需要，不以全员参与作为完成标准。

更新配置后使用新的编排

团队保存的是成员、职责和能力快照。修改原专家的指令或能力后，需要重新保存编排；成员模型和对应连接器账号在每次运行前读取，已开始的运行不会中途切换配置。

更新团队后，从新的团队配置发起新会话。已有会话继续使用创建时的团队快照，不应通过续聊验证新编排。

将经营复盘沉淀为 定时任务 时，先确认每次运行都能取得当期资料。定时任务保留保存时的成员与能力快照；需要采用更新后的团队时，在任务编辑页勾选“保存时采用当前专家团配置”。

常见问题与调整方法

更多关于成员配置、授权、模型和团队快照的操作，请阅读 专家团。