# Room 多人协作

组建团队，安排分工、交接、复核和汇总。

## 用 Room 组织一次协作

Room 适合需要多个成员共享目标、分工、复核和汇总的任务。开始前确定参与成员、各自职责和最终汇总者。

![研究、执行与复核如何通过交接形成最终交付](/images/docs/room-handoff.svg)

## 创建并启动 Room

1. 从 **聊天 → 新建群聊** 打开创建入口，填写名称并选择成员。
2. 在设置中检查成员职责；需要固定协作方法时启用合适的 Room Skill。
3. 发布一条共同目标，包含输入材料、分工、交付位置和验收标准。
4. 提及需要立即行动的成员，让它接手具体工作。
5. 检查各阶段交付，要求负责汇总的成员给出统一结果。

```text
请一起完成这份产品需求的评审。
研究成员核对用户问题，工程成员检查实现约束，复核成员列出缺口。
先各自给出结论与依据，再由工程成员汇总为 review.md。
没有依据的判断标为待确认；不要修改代码。
```

## 群主与自动接管

创建或管理 Room 时可以选择群主，并决定未提及成员的消息是否由群主接管。未使用 `@` 且没有可接管成员时，消息可能被记录但不会启动工作。

群主自动接管处理新消息；主动跟进处理安静后的单聊，两者不同。Room 还可以控制是否允许成员私信协作，以及暂停或恢复成员参与。

## 设计一份能交接的分工

以方案评审为例，先规定三个产物，避免成员各写一份相似结论。

| 成员 | 输入 | 交付 | 接手条件 |
| --- | --- | --- | --- |
| 整理成员 | 原始方案 | comparison.md 事实对照表 | 材料齐全 |
| 复核成员 | 原文和对照表 | review-notes.md 问题清单 | 对照表已保存并交接 |
| 汇总成员 | 对照表和复核意见 | final-review.md | 问题已处理或标明待确认 |

人数少时，整理成员也可负责最终汇总。关键是把独立检查安排在汇总前，而不是要求每个成员重复阅读后自由发言。

## 发布目标与交接消息

先发布共同要求，再提及实际执行者。交接消息应包含文件位置、已完成范围、未解决问题和下一位成员的任务。

```text
对照表已保存为 comparison.md。
报价口径与交付范围已整理，方案乙的验收条件仍缺少依据。
请复核成员逐项核对原文，交付 review-notes.md，不直接覆盖对照表。
```

公开消息用于共享这些状态。私下沟通形成的判断需要带回公开区，其他成员才有明确的接手依据。

## 公开消息和私下消息

公开区用于共同目标、已确认事实、阻塞、交接和最终交付。定向问题或尚未整理的中间意见可以私下沟通，但私下结果不会自动成为所有成员都知道的事实。

汇总者应把必要结论带回公开区，同时保留来源和未解决问题。交付时附上文件或结果位置，便于其他成员检查。

## 提及成员与任务分配

`@成员` 用于唤醒或交接，不会自动创建任务负责人和验收记录。临时配合可以直接沟通；需要检查任务依赖、负责人和验收状态时使用[工作图](/docs/workgraphs)。

![桌面 App 中两位 Agent 整理和复核行动清单的 Room 会话](/images/docs/room.png)

*在“网站更新评审”Room 中，文档助手整理行动清单，复核助手检查遗漏信息。图中任务使用教学材料。*

## 如何看待 Thread 中的过程

Room 公共区保留共同进展，某条回复的详细执行在对应 Thread 查看。排查“成员是否真的读了材料”时，应展开过程检查工具和结果，不仅看公共区一句完成声明。

在 Thread 继续讨论时，明确针对哪份产物修订。需要影响整个协作流程的变更，例如暂停汇总或替换原始方案，应回到公共区说明。

## 防止协作互相覆盖

同一轮只让一个成员负责写某个最终文件，其他成员提供问题清单或独立文件。共享工作区不是版本控制系统，成员分工也不提供自动冲突合并。

如果已经出现互相覆盖，先停止对冲突文件的写入，保留可用版本，再由指定成员合并。需要长期追踪负责人、依赖和验收状态时，使用工作图，`@成员` 本身不创建这些记录。

## 协作卡住时

先看被提及的成员是否仍在 Room、模型是否可用、是否等待审批，以及前置材料是否已交付。缺少材料或决定时，在原任务中补充信息后再继续。

如果大家都完成了自己的部分却没有总结果，补上汇总负责人和交付文件名。若多名成员同时修改同一文件，先划分各自负责的文件或步骤，再继续执行。

## 成员暂停或材料变更时

在房间管理中暂停成员参与，会影响后续协作，不等于删除这个 Agent。暂停前把尚未交付的部分和接手者写入公开消息；恢复后先核对当前材料，避免继续使用暂停前的旧版本。

更换方案文件时，说明哪些产物受影响。例如只更新方案乙的报价，就要求整理者修改对应行，再请复核者检查该行及相关结论。已经验证且不受影响的部分可以保留。

若没有成员被提及且群主不能接管，公开消息可能已记录却没有启动执行。先检查实际接手者，再排查模型与审批，避免通过重复发送同一任务制造多份交付。

## 结束一次协作

要求汇总者给出最终文件、验证结果和仍未解决的问题。逐一打开文件，确认复核意见已处理，缺失依据没有被写成结论。没有明确最终交付的 Room 仍可能继续讨论，应把结束标准写进共同任务或 Room Skill。

## 复用协作方法

验证成功后，可以用[Room Skill](/docs/room-skills)保存分工、公开/私下沟通和停止规则。需要复用结构化任务关系时，阅读[工作图与运行图](/docs/workgraphs)。