> 内容来源：Onevium 官方文档
> 文章: 用队伍协作组织多会话任务
> 原文: https://onevium.com/zh/docs/teams
> 语言：简体中文
> 更新于: 2026-09-09
> 适用版本: 1.1.23+

---

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

从 @Team 方案开始，确认 Skill 与会话工具，按文件边界建立成员会话，查看驾驶舱并核对报告和完成状态。

## 队伍适合什么任务

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

| 方式                       | 适合什么情况                                                                  |
| ------------------------ | ----------------------------------------------------------------------- |
| 普通 subagent / Agent 工具   | 当前一轮中的短小并行调查或审查，结果回到主会话                                                 |
| Onevium 队伍               | 有清楚边界、需要独立会话持续工作的多项任务                                                   |
| 渠道中的 Team / 机器人分组        | 把飞书、钉钉等渠道机器人组织到同一工作空间，另见[渠道](https://onevium.com/zh/docs/team-channels) |
| Claude CLI 的 Agent Teams | 上游运行时的实验团队功能，不等同于这里的 Onevium 会话队伍                                       |

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

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

| 条件           | 怎么检查                                                         |
| ------------ | ------------------------------------------------------------ |
| Team 入口      | 确认 @ 菜单中出现 Team                                              |
| `team` Skill | 在当前项目/用户的 Skills 中核对来源和作用域，并确认本会话能实际加载 `team`                |
| Sessions 工具组 | **设置 → 工具 → 会话（Sessions）**；它默认启用，但要以当前设置为准。启用后发送下一条消息，确认工具可用 |
| 模型与项目        | 先验证普通聊天和所需文件工具；选小项目，确认已有修改和允许写入的范围                           |

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

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

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

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

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

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

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

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

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

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

| 内容                   | 用途                           |
| -------------------- | ---------------------------- |
| `team.md`            | 负责人会话、成员清单、阶段、文件归属、共同约定和验收条件 |
| `member-N-brief.md`  | 第 N 名成员的完整任务书                |
| `member-N-report.md` | 成员结构化报告的预期位置；仍需确认实际文件存在      |

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

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

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

## 成员怎样沟通和回报

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

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

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

| 字段                 | 内容                                   |
| ------------------ | ------------------------------------ |
| `outcome`          | `succeeded`、`failed` 或 `needs_input` |
| `summary`          | 做了什么、结论依据                            |
| `files_modified`   | 实际改动文件                               |
| `unmet_acceptance` | 尚未满足的验收项                             |
| `followups`        | 需要负责人安排的后续事项                         |
| `error`            | 失败或需要输入时，可选的具体原因                     |

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

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

## 查看队伍驾驶舱

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

| 你看到的情况                 | 如何理解               |
| ---------------------- | ------------------ |
| 成员在运行                  | 对应会话仍在执行           |
| 等待输入/权限                | 打开成员会话处理实际问题或审批    |
| 会话已空闲                  | 这一轮停下了，不等于负责人已验收   |
| `reported`             | 已有回报，仍需检查          |
| `verified` / “已验证”计数增加 | 负责人已在队伍记录中给出验证结论   |
| 错误、失败或已删除              | 检查报告和剩余工作；不要把它计入通过 |

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

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

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

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

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

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

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

## 怎样确认完成

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

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

## 当前边界

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

## 常见问题

| 现象                  | 下一步                                              |
| ------------------- | ------------------------------------------------ |
| 看得到 Team，加载不到 Skill | 核对当前项目/用户的 Skill 来源和作用域，取得匹配内容后再开始               |
| 创建或报告工具缺失           | 检查 Sessions 工具组，新建会话重新加载；不要只切 CLI Agent Teams 开关 |
| 新建成功但成员没开始          | 检查首条消息投递结果和成员会话，不重复创建                            |
| 成员空闲但验证数不增加         | 负责人检查报告、差异和 `team.md` 的验证结论                      |
| 卡片缺成员或一直 pending    | 核对真实子会话与团队清单的会话关联，优先修正原记录                        |
| 需要终止整个任务            | 让负责人停止后续派发，并逐个检查活动成员会话的停止状态；卡片没有统一停止按钮           |

## 下一步

用[扩展概览](https://onevium.com/zh/docs/skills-and-agents)选择合适方式，了解普通 [Agents](https://onevium.com/zh/docs/agents)，或先核对 [Skills](https://onevium.com/zh/docs/skills)是否已正确安装和加载。