> For the complete documentation index, see [llms.txt](https://docs.convai.com/api-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.convai.com/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/running-the-room/how-a-turn-works.md).

# 轮次如何运作

了解为什么聊天体验房间一次只回复一条消息、轮次标题统计什么，以及为什么某个角色可能保持沉默。

聊天体验房间一次只回答一条消息，并把每条消息的结果报告在触发它的那条消息下方。那份报告就是线程里每个“等待”、每个计数以及每条“保持沉默”说明的来源。了解一次轮次是如何计量的，就能知道房间还在等待什么、它已经放弃了什么，以及哪些角色选择了沉默。

### 一次只处理一条消息

一条消息及其引出的回复构成一次轮次，房间一次只运行一个轮次。轮次会经历三个状态，而消息框会告诉你当前处于哪一个：

```mermaid
stateDiagram-v2
    [*] --> 开放
    开放 --> 回答中：你发送了一条消息
    回答中 --> 回答中：一条回复到达
    回答中 --> 结束中：最后一条回复到达
    结束中 --> 开放：说明和任何静默备注都已就位
```

发送消息会锁定消息框。角色开始回复时锁会一直保持，直到最后一条回复到达后再过一会儿；然后消息框解锁并接收下一条消息。消息框锁定时你不能输入，轮次一结束焦点就会回到它上。

原因在于，回复属于触发它的那条消息。每条回复、每个计数以及每条备注都会归在你的某条消息名下，而线程读起来就像一份记录，记着每条消息产生了什么。若在轮次进行到一半时又接受第二条消息，原本属于第一条消息的回复就会出现在它下面。

### 轮次说明会报告什么

你自己的消息下方的说明由两部分组成：轮次要求了什么，以及返回了什么。两者之间用中点分隔；在有两个或更多角色的房间里，后半部分最多可带三个计数，每个计数之间也用中点分隔。

房间默认以默认模式打开，其标签为 `自动 · 由房间简介决定`。在一个保留了四个角色的房间里，说明可以写成：

`自动 · 由房间简报决定 · 4人中有2人已回复 · 1人仍在等待 · 1人未回答`

前半部分写明该轮次所用的模式。后面的计数如下：

| 计数          | 它统计什么                    |
| ----------- | ------------------------ |
| `4人中有2人已回复` | 你发送消息时房间里有多少角色，其中有多少已经回复 |
| `1人仍在等待`    | 尚未回复且房间尚未报告其未能回答的角色      |
| `1人未回答`     | 房间报告为未作答且尚未回复的角色         |

只会打印适用的计数。所有人都回答的轮次会写成 `自动 · 由房间简报决定 · 4人中有4人已回复` 并到此为止。第一个计数并不是整段说明：后面还能跟上的两个计数会改变它的含义。

`仍在等待` “仍在等待”在轮次落定时会改变含义。房间仍在回答时，仍在等待的角色是指尚未回答的角色。一旦轮次结束，仍在等待的角色就是选择保持沉默的角色；而如果房间会报告那些角色是谁，回复下方的备注会把他们列出来。

说明描述的是消息发送时房间当时的状态，因此之后再让角色就座或移除，不会改变你先前说明中的计数。参见 [在对话中途添加或移除角色](/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/running-the-room/add-or-remove-characters.md).

这三个计数只属于自动模式。其他响应模式会用各自的话报告： **所有人都必须回复**，而对于标记了两个或更多角色的轮次，则统计 `已回复` 而不是 `已回应`，与该轮次要求的数量相对照； **任何人都可回应** 会列出已回复的角色，而不是对它们计数，并添加 `⟨n⟩ 跳过` 每种说明格式都列在 [回复模式参考](/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/running-the-room/respond-modes-reference.md).

保存的记录报告的信息比实时房间少：其说明只包含回复计数。参见 [查看过往会话](/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/sessions-and-transcripts/review-a-past-session.md).

### 角色为何可能保持沉默

角色在被点名时会回应，否则就保持沉默。收到一条并未明确指向任何人的消息的房间，可能根本不会产生任何回复。

当角色保持沉默时，房间会在回复下方的备注中写出它，而措辞会随该轮次所用模式而变化。在自动模式下，备注会说该角色按简报要求保持沉默，并邀请你标记它。在 **任何人都可回应** 备注会说该角色没有要补充的内容，并已跳过。在要求它们所指向的每个角色都必须作答的三种模式下，备注更短，只列出这些角色的名字。 [回复模式参考](/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/running-the-room/respond-modes-reference.md) 会完整列出每种措辞，而保存在记录中的备注还要更短——参见 [查看过往会话](/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/sessions-and-transcripts/review-a-past-session.md).

沉默角色如何计入也同样取决于模式：

| 轮次所用的模式     | 沉默角色计入何处                                               |
| ----------- | ------------------------------------------------------ |
| 自动          | 在 `仍在等待`，永远不计入 `未回答`。二者是不同的结果：无话可说的角色并不等同于房间报告其未能回答的角色 |
| **任何人都可回应** | 在 `⟨n⟩ 跳过`。这段说明不包含任何 `仍在等待` 计数，也不包含任何 `未回答` 计数         |

{% hint style="info" %}
若想让静默备注中点名的角色作出回应，就再发送一条标记它的消息。被标记的角色必须回复。参见 [选择由谁回复](/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/running-the-room/choose-who-replies.md).
{% endhint %}

### 单角色房间会报告什么

无论响应模式设为何值，容纳一个角色的房间都有自己的一段说明。它写的是该角色而不是模式，因为没有其他对象可在其间路由。说明以 `发送给 ⟨name⟩`，而名字后面的内容会报告该轮次：

| 名字后面的内容 | 含义           |
| ------- | ------------ |
| `已回复`   | 该角色已回应       |
| `等待中`   | 房间仍在回答这条消息   |
| 无       | 轮次已结束，没有任何回复 |

在只有一个角色就座时发送的消息，之后仍会保留这段说明，即使你后来又让更多角色就座。

### 房间正在回答时，消息框显示什么

消息框会用等待信息取代平时的提示，而措辞会随着轮次推进而变化。在仍有回复未到时，它会显示 `正在等待 4 人中的 2 人……`，其中第一个数字表示还有多少角色待答，第二个数字表示该轮次要求了多少角色。等最后一条回复到达、房间开始结束该轮次时，它会显示 `正在结束轮次……`。轮次结束时，消息框会解锁。

你已经开始输入的消息——已输入的文本，或已附加但尚未发送的文件——会遮住提示，因此等待信息会改显示在消息框下方的一行。

锁定消息框的不只是轮次，而且消息框总会说明适用的原因。 [你无法发送消息](/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/troubleshooting/composer-is-locked.md) 会逐一读取它们，并告诉你什么能解除它们。

### 相关页面

你选择的模式决定了说明报告的大部分内容，消息框告诉你轮次进行到哪一步，而已完成的对话则把两者都留成更短的记录。

{% content-ref url="/pages/74590cb5e120e705f258bba7fb72a88ca6dd0bff" %}
[选择谁来回复](/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/running-the-room/choose-who-replies.md)
{% endcontent-ref %}

{% content-ref url="/pages/7eeb66a9ac5bb80ce7d065a4b723f69d026f387e" %}
[回复模式参考](/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/running-the-room/respond-modes-reference.md)
{% endcontent-ref %}

{% content-ref url="/pages/7cc57a2b494366f09283fa8158dccdad2665c0c2" %}
[无法发送消息](/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/troubleshooting/composer-is-locked.md)
{% endcontent-ref %}

{% content-ref url="/pages/3891ccc0535444943ba47b4ffa0609cbcbe6ec1c" %}
[回顾过去的会话](/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/sessions-and-transcripts/review-a-past-session.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.convai.com/api-docs/zh/wu-dai-ma-ti-yan/chat-experiences/running-the-room/how-a-turn-works.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.