diff --git a/plans/CHANNEL_MODES_AND_SHUFFLE.md b/plans/CHANNEL_MODES_AND_SHUFFLE.md new file mode 100644 index 0000000..f05fda5 --- /dev/null +++ b/plans/CHANNEL_MODES_AND_SHUFFLE.md @@ -0,0 +1,208 @@ +# Channel Modes & Turn Shuffle 规划 + +## 背景 + +`feat/new-feat-notes` 分支中的 `NEW_FEAT.md` 提出了两项新的行为增强需求,需要整合进入 `main` 分支下的 `plans/`: + +1. **Multi-Message Mode(人类连续多消息模式)** +2. **Shuffle Mode(轮转顺序重洗牌)** + +这两项能力都与 Dirigent 当前的 turn-manager、moderator handoff、no-reply override 机制直接相关,因此应作为 turn orchestration 的功能扩展纳入规划,而不是孤立实现。 + +--- + +## 1. Multi-Message Mode + +### 1.1 目标 + +允许人类在一个 channel 中连续发送多条消息而不被 Agent 打断。 + +当用户显式进入 multi-message mode 后: +- 当前 channel 的 turn manager 暂停 +- 所有 Agent 在该 channel 中进入 no-reply 覆盖 +- moderator bot 对每条人类追加消息发送 prompt marker,提示继续输入 +- 直到人类发送 end marker 才恢复 turn manager +- 恢复后由 moderator 按现有调度机制唤醒下一位 Agent + +--- + +### 1.2 配置项 + +建议新增以下可配置项: + +- `multiMessageStartMarker`:默认 `↗️` +- `multiMessageEndMarker`:默认 `↙️` +- `multiMessagePromptMarker`:默认 `⤵️` + +这些配置应加入插件 config schema,并在运行时可被 hook/turn-manager 使用。 + +--- + +### 1.3 行为规则 + +#### 进入 multi-message mode +当 **human** 消息中包含 start marker: +- 当前 channel 进入 `multi-message` 状态 +- turn manager 暂停 +- 当前 channel 下所有 Agent 在该 channel/session 中走 no-reply override + +#### multi-message mode 中 +在该模式下: +- 人类每发一条消息 +- moderator bot 自动回复 prompt marker(例如 `⤵️`) +- Agent 不应参与正常轮转回复 + +#### 退出 multi-message mode +当 **human** 消息中包含 end marker: +- 当前 channel 退出 `multi-message` 状态 +- turn manager 恢复 +- moderator bot 发送当前调度标识(scheduling identifier)唤醒下一位 Agent + +--- + +### 1.4 状态建议 + +每个 Discord channel 维护一个 channel mode: + +- `normal` +- `multi-message` +- (后续可扩展其他模式) + +multi-message mode 应与 discussion channel / wait-for-human / no-reply 决策互相兼容,优先级需要明确。 + +建议优先级初稿: + +1. closed discussion channel +2. multi-message mode +3. waiting-for-human +4. normal turn-manager + +--- + +## 2. Shuffle Mode + +### 2.1 目标 + +在 turn-based speaking 中,为每个 Discord channel 增加可选的 turn order reshuffle 能力。 + +当 shuffle mode 开启时: +- 在一轮 turn list 的最后一位 speaker 发言完成后 +- 对 turn order 重新洗牌 +- 但必须保证:**上一轮最后一位发言者不能在新一轮中成为第一位** + +--- + +### 2.2 配置 / 控制方式 + +为每个 Discord channel 维护: + +- `shuffling: boolean` + +并新增 slash command: + +- `/turn-shuffling on` +- `/turn-shuffling off` +- `/turn-shuffling`(查看当前状态) + +该状态应与 channel 级 policy / runtime state 做清晰分工: +- 若只是运行时开关,可放 runtime memory +- 若希望重启保留,则需要落盘策略 + +--- + +### 2.3 行为规则 + +当 `shuffling = true` 时: +- 正常按 turn order 轮转 +- 当“当前 speaker 是该轮最后一位”并完成发言后 +- 进入下一轮前重洗 turn order +- 新 turn order 必须满足: + - 上一轮最后 speaker != 新 turnOrder[0] + +若无法满足(极端小集合场景),需要定义 fallback: +- 两个 Agent 时可退化为简单交换/固定顺序 +- 单 Agent 时不需要 shuffle + +--- + +## 3. 与当前系统的关系 + +这两个能力都不是独立子系统,而是 Dirigent turn orchestration 的扩展。 + +### 涉及模块 + +- `plugin/turn-manager.ts` +- `plugin/hooks/message-received.ts` +- `plugin/hooks/before-model-resolve.ts` +- `plugin/hooks/before-message-write.ts` +- `plugin/hooks/message-sent.ts` +- `plugin/commands/dirigent-command.ts` +- `plugin/index.ts` +- `plugin/openclaw.plugin.json` +- 如有必要新增 `plugin/core/channel-modes.ts` 或类似 runtime state 模块 + +--- + +## 4. 建议实现方向 + +### 4.1 Multi-Message Mode + +建议不要把 multi-message mode 直接塞进规则判断字符串里,而是做成显式 channel runtime state。 + +建议新增: +- channel mode state store +- helper: + - `enterMultiMessageMode(channelId)` + - `exitMultiMessageMode(channelId)` + - `isMultiMessageMode(channelId)` + +然后: +- `message-received` 检测 human 消息中的 start/end marker +- `before-model-resolve` 检测当前 channel 是否处于 multi-message mode,若是则直接走 no-reply override +- `message-received` 或合适的消息链路中触发 moderator prompt marker +- 退出时触发一次 scheduling handoff + +--- + +### 4.2 Shuffle Mode + +建议将 shuffle 状态与 turn order 状态放在一起,或由 turn-manager 引用单独的 channel config/state。 + +建议新增 helper: +- `setChannelShuffling(channelId, enabled)` +- `getChannelShuffling(channelId)` +- `reshuffleTurnOrder(channelId, { avoidFirstAccountId })` + +并在 turn cycle 的边界点调用重洗逻辑,而不是在任意发言后随机改顺序。 + +--- + +## 5. 风险与边界 + +### Multi-Message Mode + +- 需要防止 moderator prompt marker 自己再次触发 turn logic +- 需要明确 start/end marker 的匹配规则(全文包含、末尾匹配、独立一条指令等) +- 需要明确 multi-message mode 下 human @mention 是否还有特殊行为 +- 需要避免与 discussion closed / waiting-for-human 冲突 + +### Shuffle Mode + +- 两个 Agent 的洗牌约束需要单独处理 +- turn order 若正处于 mention override / waiting-for-human / dormant,需要明确何时允许 reshuffle +- 若 turn order 成员变化,shuffle 与 bootstrap 的先后顺序要明确 + +--- + +## 6. 结论 + +`feat/new-feat-notes` 分支中的内容可以整合为 `main` 下的一份独立规划文档,建议命名为: + +- `plans/CHANNEL_MODES_AND_SHUFFLE.md` + +其定位是: +- 汇总 multi-message mode 与 shuffle mode 的产品行为 +- 明确它们与现有 turn-manager / moderator / no-reply 机制的关系 +- 为后续代码开发和 TASKLIST 拆分提供依据 + +后续应将对应开发任务补充进 `plans/TASKLIST.md`。 \ No newline at end of file diff --git a/plans/TASKLIST.md b/plans/TASKLIST.md new file mode 100644 index 0000000..4684529 --- /dev/null +++ b/plans/TASKLIST.md @@ -0,0 +1,344 @@ +# TASKLIST - Dirigent 开发任务拆分 + +## A. CSM / Discussion Callback + +### A1. 需求与方案冻结 +- [ ] 通读并确认 `plans/CSM.md` 中的 MVP 范围、非目标和边界条件 +- [ ] 确认 CSM 第一版只新增一条对外工具:`discuss-callback` +- [ ] 确认 `discord_channel_create` 仅做参数扩展,不改变普通建频道行为 +- [ ] 确认讨论结束后的 session 级 no-reply 覆盖继续沿用现有插件机制 +- [ ] 确认 `summaryPath` 的合法范围仅限发起讨论 Agent 的 workspace +- [ ] 确认 discussion metadata 是否仅做内存态,还是需要落盘恢复 + +### A2. 模块拆分与落点确认 +- [ ] 确认 `plugin/tools/register-tools.ts` 负责: + - [ ] 扩展 `discord_channel_create` + - [ ] 注册 `discuss-callback` +- [ ] 确认 `plugin/core/` 下新增 discussion metadata 管理模块 +- [ ] 确认 `plugin/core/moderator-discord.ts` 继续负责 moderator 发消息能力 +- [ ] 确认 `plugin/turn-manager.ts` 仅负责 turn 状态与轮转,不直接承担业务文案拼接 +- [ ] 确认 discussion 业务编排逻辑应放在新模块,而不是散落到多个 hook 中 +- [ ] 确认 origin callback 与 discussion close 逻辑的调用路径 + +### A3. `plugin/tools/register-tools.ts` +#### A3.1 扩展 `discord_channel_create` +- [ ] 阅读当前 `discord_channel_create` 的参数定义与执行逻辑 +- [ ] 为 `discord_channel_create` 增加可选参数 `callbackChannelId` +- [ ] 为 `discord_channel_create` 增加可选参数 `discussGuide` +- [ ] 添加联动校验:若传 `callbackChannelId`,则必须传 `discussGuide` +- [ ] 保证不传 `callbackChannelId` 时,行为与当前版本完全一致 +- [ ] 创建成功后识别是否为 discussion 模式 channel +- [ ] 在 discussion 模式下调用 metadata 初始化逻辑 +- [ ] 在 discussion 模式下调用 moderator kickoff 发送逻辑 + +#### A3.2 注册 `discuss-callback` +- [ ] 定义 `discuss-callback` 的 parameters schema +- [ ] 注册新工具 `discuss-callback` +- [ ] 将 `discuss-callback` 执行逻辑接到 discussion service / manager +- [ ] 为工具失败场景返回可读错误信息 + +### A4. `plugin/core/` 新增 discussion metadata/service 模块 +#### A4.1 新建 metadata/state 模块 +- [ ] 新建 discussion state 类型定义文件(如 `plugin/core/discussion-state.ts`) +- [ ] 定义 discussion metadata 类型: + - [ ] `mode` + - [ ] `discussionChannelId` + - [ ] `originChannelId` + - [ ] `initiatorAgentId` + - [ ] `initiatorSessionId` + - [ ] `discussGuide` + - [ ] `status` + - [ ] `createdAt` + - [ ] `completedAt` + - [ ] `summaryPath` +- [ ] 提供按 `discussionChannelId` 查询 metadata 的方法 +- [ ] 提供创建 metadata 的方法 +- [ ] 提供更新状态的方法 +- [ ] 提供关闭 discussion channel 的状态写入方法 + +#### A4.2 新建 discussion service 模块 +- [ ] 新建 discussion service(如 `plugin/core/discussion-service.ts`) +- [ ] 封装 discussion channel 创建后的初始化逻辑 +- [ ] 封装 callback 校验逻辑 +- [ ] 封装 callback 成功后的收尾逻辑 +- [ ] 封装 origin channel moderator 通知逻辑 +- [ ] 封装“channel 已关闭,仅做留档使用”的统一回复逻辑 + +#### A4.3 workspace 路径校验 +- [ ] 新增 path 校验辅助函数 +- [ ] 校验 `summaryPath` 文件存在 +- [ ] 校验 `summaryPath` 位于 initiator workspace 下 +- [ ] 防止 `..`、绝对路径越界、软链接绕过等路径逃逸问题 + +### A5. `plugin/core/moderator-discord.ts` +- [ ] 确认当前 `sendModeratorMessage(...)` 是否已足够支撑新流程 +- [ ] 如有必要,补充统一错误日志和返回值处理 +- [ ] 确认可被 discussion service 复用发送: + - [ ] kickoff message + - [ ] idle reminder + - [ ] callback 完成通知 + - [ ] channel closed 固定回复 + +### A6. `plugin/turn-manager.ts` +#### A6.1 理解现有轮转机制 +- [ ] 梳理 `initTurnOrder` / `checkTurn` / `onNewMessage` / `onSpeakerDone` / `advanceTurn` +- [ ] 确认“轮转一圈无人发言”在现有实现中的判定条件 +- [ ] 确认 discussion 模式需要在哪个信号点插入“idle reminder” + +#### A6.2 discussion 模式的空转处理 +- [ ] 设计 discussion 模式下的 idle reminder 触发方式 +- [ ] 确定是直接改 `turn-manager.ts`,还是由上层在 `nextSpeaker === null` 时识别 discussion channel +- [ ] 确保 discussion channel 空转时 moderator 会提醒 initiator 收尾 +- [ ] 确保普通 channel 仍保持原有 dormant 行为 + +#### A6.3 关闭后禁言 +- [ ] 明确 discussion channel `closed` 后 turn-manager 是否还需要保留状态 +- [ ] 如需要,增加对 closed discussion channel 的快速短路判断 +- [ ] 避免 closed channel 再次进入正常轮转 + +### A7. Hooks 与 session 状态 +#### A7.1 `plugin/hooks/before-model-resolve.ts` +- [ ] 梳理当前 session 级 no-reply 覆盖的触发路径 +- [ ] 确认如何将 closed discussion channel 相关 session 强制落到 `noReplyProvider` / `noReplyModel` +- [ ] 确认该逻辑是通过 metadata 状态判断,还是通过额外 session 标记判断 +- [ ] 确保该覆盖只作用于指定 discussion session,不影响其他 channel/session +- [ ] 为 closed discussion channel 的覆盖路径补充调试日志 + +#### A7.2 `plugin/hooks/before-message-write.ts` +- [ ] 梳理当前 NO_REPLY / end-symbol / waitIdentifier 的处理逻辑 +- [ ] 找到 discussion channel 中“轮转一圈无人发言”后最适合触发 idle reminder 的位置 +- [ ] 如果 `nextSpeaker === null` 且当前 channel 是 active discussion channel: + - [ ] 调用 moderator idle reminder + - [ ] 不直接让流程无提示沉默结束 +- [ ] 避免重复发送 idle reminder +- [ ] closed discussion channel 下,阻止继续进入正常 handoff 流程 + +#### A7.3 `plugin/hooks/message-sent.ts` +- [ ] 确认该 hook 是否也会参与 turn 收尾,避免与 `before-message-write.ts` 重复处理 +- [ ] 检查 discussion channel 场景下是否需要同步补充 closed/idle 分支保护 +- [ ] 确保 callback 完成后的 closed channel 不会继续触发 handoff + +#### A7.4 `plugin/hooks/message-received.ts` +- [ ] 梳理 moderator bot 消息当前是否已被过滤,避免 moderator 自己再次触发讨论链路 +- [ ] 对 closed discussion channel 的新消息增加统一处理入口 +- [ ] 若 closed discussion channel 收到新消息: + - [ ] 不再唤醒任何 Agent 正常讨论 + - [ ] 由 moderator 回复“channel 已关闭,仅做留档使用” +- [ ] 避免 moderator 的 closed 提示消息反复触发自身处理 + +#### A7.5 `plugin/core/session-state.ts`(如需) +- [ ] 检查现有 session 相关缓存是否适合扩展 discussion 状态 +- [ ] 若需要,为 discussion session 增加专用标记缓存 +- [ ] 区分:普通 no-reply 决策 vs discussion close 强制 no-reply +- [ ] 确保 session 生命周期结束后相关缓存可清理 + +### A8. `plugin/core/identity.ts` / `plugin/core/channel-members.ts` / `plugin/core/turn-bootstrap.ts` +- [ ] 梳理 initiator identity 的可获取路径 +- [ ] 确认 callback 时如何稳定识别 initiator account/session +- [ ] 确认 discussion channel 创建后 turn order 是否需立即 bootstrap +- [ ] 确认 discussion participant 的成员集合获取方式是否可直接复用现有逻辑 + +### A9. `plugin/index.ts` +- [ ] 注入新增 discussion metadata/service 模块依赖 +- [ ] 将 discussion service 传入工具注册逻辑 +- [ ] 将 discussion 相关辅助能力传入需要的 hooks +- [ ] 保持插件初始化结构清晰,避免在 `index.ts` 中堆业务细节 + +### A10. moderator 消息模板整理 +#### A10.1 kickoff message +- [ ] 定稿 discussion started 模板 +- [ ] 模板中包含 `discussGuide` +- [ ] 模板中明确 initiator 结束责任 +- [ ] 模板中明确 `discuss-callback(summaryPath)` 调用要求 + +#### A10.2 idle reminder +- [ ] 定稿 discussion idle 模板 +- [ ] 模板中提醒 initiator:写总结文件并 callback +- [ ] 避免提醒文案歧义或像自动总结器 + +#### A10.3 origin callback message +- [ ] 定稿发回原工作 channel 的结果通知模板 +- [ ] 模板中包含 `summaryPath` +- [ ] 模板中包含来源 discussion channel +- [ ] 模板中明确“继续基于该总结文件推进原任务” + +#### A10.4 closed reply +- [ ] 定稿 closed channel 固定回复模板 +- [ ] 明确 channel 已关闭,仅做留档使用 + +### A11. `discuss-callback` 详细校验任务 +- [ ] 校验当前 channel 必须是 discussion channel +- [ ] 校验当前 discussion 状态必须是 `active` +- [ ] 校验调用者必须是 initiator +- [ ] 校验 `summaryPath` 非空 +- [ ] 校验 `summaryPath` 文件存在 +- [ ] 校验 `summaryPath` 路径在 initiator workspace 内 +- [ ] 校验 callback 未重复执行 +- [ ] callback 成功后写入 `completedAt` +- [ ] callback 成功后记录 `summaryPath` +- [ ] callback 成功后切换 discussion 状态为 `completed` / `closed` + +### A12. 关闭后的行为封口 +- [ ] closed discussion channel 中所有旧 session 继续使用 no-reply 覆盖 +- [ ] closed discussion channel 中任何新消息都不再进入真实讨论 +- [ ] closed discussion channel 的任何新消息统一走 moderator 固定回复 +- [ ] 防止 closed channel 中 moderator 自己的回复再次触发回环 +- [ ] 明确 archived-only 的最终行为与边界 + +### A13. 测试与文档收尾 +#### A13.1 工具层测试 +- [ ] 测试普通 `discord_channel_create` 不带新参数时行为不变 +- [ ] 测试 `discord_channel_create` 带 `callbackChannelId` 但缺 `discussGuide` 时失败 +- [ ] 测试 discussion 模式 channel 创建成功 +- [ ] 测试 `discuss-callback` 注册成功并可调用 + +#### A13.2 metadata / service 测试 +- [ ] 测试 discussion metadata 创建成功 +- [ ] 测试按 channelId 查询 metadata 成功 +- [ ] 测试状态流转 `active -> completed/closed` 成功 +- [ ] 测试重复 callback 被拒绝 + +#### A13.3 turn / hook 测试 +- [ ] 测试 discussion channel 空转后发送 idle reminder +- [ ] 测试普通 channel 空转逻辑不受影响 +- [ ] 测试 callback 成功后 discussion channel 不再 handoff +- [ ] 测试 closed discussion channel 新消息不会继续唤醒 Agent + +#### A13.4 路径校验测试 +- [ ] 测试合法 `summaryPath` 通过 +- [ ] 测试不存在文件失败 +- [ ] 测试 workspace 外路径失败 +- [ ] 测试 `..` 路径逃逸失败 +- [ ] 测试绝对路径越界失败 + +#### A13.5 回调链路测试 +- [ ] 测试 callback 成功后 moderator 在 origin channel 发出通知 +- [ ] 测试 origin channel 收到路径后能继续原工作流 +- [ ] 测试 discussion channel 后续只保留留档行为 + +#### A13.6 文档交付 +- [ ] 根据最终代码实现更新 `plans/CSM.md` +- [ ] 为 `discord_channel_create` 新增参数补文档 +- [ ] 为 `discuss-callback` 补工具说明文档 +- [ ] 补 discussion metadata 与状态机说明 +- [ ] 补开发/调试说明 +- [ ] 输出 MVP 验收清单 + +--- + +## B. Multi-Message Mode / Shuffle Mode + +### B1. 方案整理 +- [ ] 通读并确认 `plans/CHANNEL_MODES_AND_SHUFFLE.md` +- [ ] 确认 Multi-Message Mode 与 Shuffle Mode 的 MVP 范围 +- [ ] 确认两项能力是否都只做 channel 级 runtime state,不立即落盘 +- [ ] 明确它们与 discussion channel / waiting-for-human / dormant 的优先级关系 + +### B2. 配置与 schema +#### B2.1 `plugin/openclaw.plugin.json` +- [ ] 增加 `multiMessageStartMarker` +- [ ] 增加 `multiMessageEndMarker` +- [ ] 增加 `multiMessagePromptMarker` +- [ ] 为新增配置设置默认值:`↗️` / `↙️` / `⤵️` +- [ ] 评估是否需要增加 shuffle 默认配置项 + +#### B2.2 `plugin/rules.ts` / config 类型 +- [ ] 为 multi-message mode 相关配置补类型定义 +- [ ] 为 shuffle mode 相关 channel state / config 补类型定义 +- [ ] 确保运行时读取配置逻辑可访问新增字段 + +### B3. `plugin/core/` 新增 channel mode / shuffle state 模块 +- [ ] 新增 channel mode state 模块(如 `plugin/core/channel-modes.ts`) +- [ ] 定义 channel mode:`normal` / `multi-message` +- [ ] 提供 `enterMultiMessageMode(channelId)` +- [ ] 提供 `exitMultiMessageMode(channelId)` +- [ ] 提供 `isMultiMessageMode(channelId)` +- [ ] 提供 shuffle 开关状态存取方法 +- [ ] 评估 shuffle state 是否应并入 turn-manager 内部状态 + +### B4. `plugin/hooks/message-received.ts` +#### B4.1 Multi-Message Mode 入口/出口 +- [ ] 检测 human 消息中的 multi-message start marker +- [ ] start marker 命中时,将 channel 切换到 multi-message mode +- [ ] 检测 human 消息中的 multi-message end marker +- [ ] end marker 命中时,将 channel 退出 multi-message mode +- [ ] 避免 moderator 自己的 prompt marker 消息触发 mode 切换 + +#### B4.2 Multi-Message Mode 中的 moderator 提示 +- [ ] 当 channel 处于 multi-message mode 时,人类每发一条消息触发 moderator prompt marker +- [ ] prompt marker 文案/内容使用配置项 `multiMessagePromptMarker` +- [ ] 避免重复触发或回环 + +#### B4.3 与现有 mention override 的兼容 +- [ ] 明确 multi-message mode 下 human @mention 是否忽略 +- [ ] 避免 multi-message mode 与 mention override 冲突 + +### B5. `plugin/hooks/before-model-resolve.ts` +- [ ] 当 channel 处于 multi-message mode 时,强制相关 session 走 `noReplyProvider` / `noReplyModel` +- [ ] 确保 multi-message mode 的 no-reply 覆盖优先于普通 turn 决策 +- [ ] 确保退出 multi-message mode 后恢复正常 turn 逻辑 +- [ ] 补充必要调试日志 + +### B6. `plugin/turn-manager.ts` +#### B6.1 Multi-Message Mode 与 turn pause/resume +- [ ] 设计 multi-message mode 下 turn manager 的暂停语义 +- [ ] 明确 pause 是通过外层 gating,还是 turn-manager 内显式状态 +- [ ] 退出 multi-message mode 后恢复 turn manager +- [ ] 退出时确定下一位 speaker 的选择逻辑 + +#### B6.2 Shuffle Mode +- [ ] 为每个 channel 增加 `shuffling` 开关状态 +- [ ] 识别“一轮最后一位 speaker 发言完成”的边界点 +- [ ] 在进入下一轮前执行 reshuffle +- [ ] 保证上一轮最后 speaker 不会成为新一轮第一位 +- [ ] 处理单 Agent 场景 +- [ ] 处理双 Agent 场景 +- [ ] 处理 mention override / waiting-for-human / dormant 状态下的 reshape 边界 + +### B7. `plugin/commands/dirigent-command.ts` +- [ ] 新增 `/turn-shuffling` 子命令 +- [ ] 支持: + - [ ] `/turn-shuffling` + - [ ] `/turn-shuffling on` + - [ ] `/turn-shuffling off` +- [ ] 命令返回当前 channel 的 shuffling 状态 +- [ ] 命令帮助文本补充说明 + +### B8. `plugin/index.ts` +- [ ] 注入 channel mode / shuffle state 模块依赖 +- [ ] 将新状态能力传给相关 hooks / turn-manager +- [ ] 保持初始化关系清晰,避免 mode 逻辑散落 + +### B9. moderator 消息模板 +- [ ] 定义 multi-message mode 下的 prompt marker 发送规则 +- [ ] 明确是否需要 start / end 的 moderator 确认消息 +- [ ] 定义退出 multi-message mode 后的 scheduling handoff 触发格式 + +### B10. 测试 +#### B10.1 Multi-Message Mode +- [ ] 测试 human 发送 start marker 后进入 multi-message mode +- [ ] 测试 multi-message mode 中 Agent 被 no-reply 覆盖 +- [ ] 测试每条 human 追加消息都触发 prompt marker +- [ ] 测试 human 发送 end marker 后退出 multi-message mode +- [ ] 测试退出后 moderator 正确 handoff 给下一位 Agent +- [ ] 测试 moderator prompt marker 不会触发回环 + +#### B10.2 Shuffle Mode +- [ ] 测试 `/turn-shuffling on/off` 生效 +- [ ] 测试 shuffling 关闭时 turn order 不变 +- [ ] 测试 shuffling 开启时每轮结束后会 reshuffle +- [ ] 测试上一轮最后 speaker 不会成为下一轮第一位 +- [ ] 测试双 Agent 场景行为符合预期 +- [ ] 测试单 Agent 场景不会异常 + +#### B10.3 兼容性测试 +- [ ] 测试 multi-message mode 与 waiting-for-human 的边界 +- [ ] 测试 multi-message mode 与 mention override 的边界 +- [ ] 测试 shuffle mode 与 dormant 状态的边界 +- [ ] 测试 shuffle mode 与 mention override 的边界 + +### B11. 文档收尾 +- [ ] 根据最终实现更新 `plans/CHANNEL_MODES_AND_SHUFFLE.md` +- [ ] 为新增配置项补文档 +- [ ] 为 `/turn-shuffling` 补使用说明 +- [ ] 输出 Multi-Message Mode / Shuffle Mode 的验收清单