用队伍协作组织多会话任务

队伍适合什么任务#

队伍（Team） 由一个负责人会话和多个真实成员会话组成。负责人拆分工作、维护共同约定，成员独立执行并回报；你可以打开成员会话继续查看和介入。

开始前检查入口、Skill 和工具#

在普通项目会话的输入框输入 @，在扩展能力中选择队伍（Team）。该标签表示“组建一支协作会话队伍，共同完成任务”；选中后仍需补充要求并发送。

看到 @Team 标签，不等于已经安装了 team Skill。不同用户环境可能通过项目、用户 Skill 或插件提供它。若找不到，先核对Skills和插件中的已安装内容；再从已确认的官方来源或团队管理员取得与当前版本匹配的内容，检查后继续。无法确认匹配来源时，先使用普通 Agent 工作流，暂不启动队伍。

不需要把“Claude CLI → Agent Teams”当作这条流程的总开关。 该开关控制上游实验能力；本页使用的 create_session、会话通信和报告工具属于 Onevium 的 Sessions 工具组。打开 CLI 开关不能补齐缺失的 Skill 或会话工具。

第一次：让两名成员准备演示文档#

先选择 @Team，再发送这个范围完整的小任务：

先确认当前会话能加载 team Skill，并能使用创建子会话和队伍报告工具。
在当前项目创建一支两人队伍，依据现有 README 准备两份演示文档：
成员1只写 team-demo/quickstart.md：整理项目已经记载的启动步骤。
成员2只写 team-demo/faq.md：整理缺失条件和常见问题。
两名成员都可读 README，但不能修改它或对方负责的文件。
命令没有依据时写“未记录”，不猜测。
允许生成队伍计划、成员任务书和报告；不要安装依赖、提交、推送或部署。
先展示成员分工、共同格式、验收条件、模型和用量估算，等我确认后再启动。
同名演示文件已存在时先说明，不覆盖。

当前 Team 工作协议会先提交方案，再等待确认。确认的应是具体成员、文件范围、交付和预估，而不是一句“可以开始吗”。方案合适后，可回复：

按这份方案开始。逐个创建并启动两名真实子会话。
保持上述文件边界；完成后先汇报文件差异和验收结果。

负责人会先记录计划和任务书，再逐个创建成员。创建会话与首条任务送达是两步；如果显示首条消息未送达，应处理这次投递，而不是再创建一个同名成员。

共同目标和文件分工保存在哪里#

队伍使用项目内的 .claude/sdd/team-<slug>/ 保存工作约定：

让成员按上下文边界分工。同一文件在同一阶段只交给一名写入者；共享文件归一个成员管理，其他成员读取它。前后端只有在接口约定明确、文件不重叠时才适合分别实施，不能仅按职位名称把同一件事拆成多人来回交接。

这里的“共享任务”通过共同目标、任务书和验收清单管理。驾驶舱显示成员状态，不提供自由认领任务的按钮。

文件归属会进入成员指令和负责人审查流程，不是文件系统硬隔离。仍要检查最终差异。

成员怎样沟通和回报#

当前 Team 协议采用负责人汇总的方式：成员把需要协作的信息交给负责人，再由负责人安排下一步，不要求成员彼此组成自由聊天网络。

Onevium 的会话通信使用 send_to_session 等会话工具。目标空闲时可开始新一轮；忙碌时尝试送入当前轮，无法插入时排队。查看实际投递状态，避免反复发送“收到了吗”。上游原生 SendMessage 不能直接替代这条 Onevium 跨会话通道。

成员完成后应使用 report_team_result，报告以下内容：

报告会尝试写入文件并向负责人发送摘要；负责人需要核对报告、文件差异和未完成项，再标记 verified。工具返回“已报告”本身不是文件已写入、消息已处理或任务已验收的证明。

没有结构化回报时，委派任务结束后的自动报告可帮助找回结果，但应先按“已报告、待核实”处理。

查看队伍驾驶舱#

成员建立后，负责人对话中的创建活动旁会出现队伍卡片。它结合真实子会话状态和 team.md，显示成员角色、负责文件、模型及验证进度。点击已有成员行可进入对应会话；尚未建立或已删除的会话不能打开。

卡片若显示费用信息，它来自计划中的估算，不是实时账单。阶段指示只表达已经到达的阶段，不表示未来任务都已执行。

打开成员、补充信息和接续#

你可以从队伍卡片或会话树进入成员会话，阅读工具记录，并像普通会话一样补充要求。更改交付范围时同步告知负责人，避免任务书与实际工作不一致。

直接发送给成员的普通用户消息，不保证自动把这次结果回传负责人。需要回传时，明确要求成员结构化汇报，或把有用结果带回负责人会话。

返回负责人会话后，可以这样接续：

继续当前队伍，不创建重复成员。
先核对 team.md、实际子会话和成员报告。
列出已验证、待输入和未完成项，再给出下一步安排。

当前协议要求阶段结束先汇总并等待下一阶段确认。不要把关闭主会话、卡片停止变化或成员空闲理解为所有后台工作都已结束。

怎样确认完成#

在演示任务中，检查两份文档确实存在、都依据 README、成员没有改动对方文件，并抽查报告中的一项结论。负责人应检查每份差异后更新验证状态，再给出整体总结。

“2/2 已验证”说明队伍记录的验证进度；是否测试了真实应用、是否提交或上线，仍以具体操作记录为准。完成或终止后保留报告和未完成事项，后续可以复查。

当前边界#

• 一个父会话最多有 8 个未删除的子会话，层级保持一层；同一父会话的多支队伍会共享这个额度。
• 新成员默认继承创建者的模型、提供商、权限和思考设置。可以明确指定模型和较低或相同的权限；提高到超过创建者的权限会被拒绝。创建时不会自动选择更便宜的模型。
• 当前 team Skill 的工作规约以少量成员、最多三阶段和负责人集中协调来组织任务；它与父会话的子会话额度不同，也不会建立文件系统隔离。
• 每个真实成员会话会运行模型任务，跨会话消息也可能启动新一轮。实际用量由成员数、模型和轮数决定，短任务通常直接用 Agent 更合适。
• 从普通桌面项目会话开始，保持应用运行。首次用演示任务确认真实成员、文件和报告，再扩大到业务工作。

常见问题#

下一步#

用扩展概览选择合适方式，了解普通 Agents，或先核对 Skills是否已正确安装和加载。