dominds 0.6.2 → 0.6.4

package/dist/docs/fbr.zh.md

@@ -1,204 +1,209 @@
-# 扪心自问（FBR）——设计文档（增强版 `@self`）
+# 扪心自问（FBR）——机制规格
 
 英文版：[English](./fbr.md)
 
-## 摘要
+> 本文是 **FBR 规范**（以本文为准）。实现细节见：[`fbr-implementation.zh.md`](./fbr-implementation.zh.md)。
 
-扪心自问（FBR）是 Dominds 的常用工作模式：智能体向自己发起自诉请（`!?@self`），创建一个短生命周期的支线对话，让“初心版本的自己”围绕一个边界清晰的子问题做推理，再把结论回贴给诉请者。
+## 1. 这是什么
 
-本文档定义对 `@self` 发起的 FBR 做专项增强：
+**扪心自问（FBR, Fresh Boots Reasoning）** 是 Dominds 的一种工作机制：在主线对话推进过程中，智能体可以把一个边界清晰的子问题“拆出去”，以 **更干净的上下文** 重新推理一次，然后把结论回贴到主线对话中。
 
-1. **无工具 FBR 支线对话**：由 `!?@self` 产生的 FBR 支线对话必须是“无工具”的，不得拥有任何工具/工具集。系统提示 / 工具提示必须明确说明：被诉请者**没有工具**，只能基于诉请正文做推理与总结。
-2. **可配置的 FBR 并发**：在 `.minds/team.yaml` 增加 `fbr-effort`（默认 `3`；“三个臭皮匠，顶个诸葛亮”）：
-   - `0` 禁用该队友的 `!?@self` FBR
-   - `1..100` 表示每次 `!?@self` 会并发创建这么多个 FBR 支线对话
-   - `> 100` 视为配置错误（直接报错）
-3. **FBR 专用模型参数覆盖**：在 `.minds/team.yaml` 增加 `fbr_model_params`，其格式与 `model_params` 完全相同（参考 `dominds/main/llm/defaults.yaml` 的 `model_param_options`）。目的：FBR 时可使用不同的模型参数（例如更高的 `temperature`），而不影响主线对话。
-   - 注：通用的 `max_tokens` 允许写成顶层 `max_tokens`，也允许写成 `general.max_tokens`（与 `model_param_options` 的分组一致）；二选一即可，禁止同时设置。
+在 Dominds 里，FBR 通过 **诉请（Tellask）语法** 触发，其中 `@self` 只是入口语法（“对当前对话自身发起诉请”）；FBR 的核心是运行时对这条支线对话施加的一组强制约束与并发语义。
 
-## 目标
+## 2. 设计原则与取舍（为什么这样做）
 
-- 通过移除工具能力并要求诉请正文自给自足，让 `!?@self` FBR 更安全、更可预期。
-- 支持“多样本推理”：通过并发创建多个 FBR 支线对话（`fbr-effort`）提升决策质量。
-- 允许只在 FBR 场景调整模型参数，而不影响主线对话的整体行为风格。
+### 2.1 可预期优先：FBR 必须“无工具”
 
-## 非目标
+FBR 的价值来自“把推理拉回文本”：让被诉请者只围绕诉请正文进行独立推理，而不是在工具、环境、副作用里游走。为此，FBR 支线对话必须满足：
 
-- 不新增全新的用户语法：仍然只使用现有 `!?@self` / `!?@self !tellaskSession ...`。
-- 不为 FBR 支线对话提供工具（本文档的核心就是“无工具”）。
-- 不改写通用的队友诉请分类法（详见 [`dialog-system.zh.md`](./dialog-system.zh.md)）；本文档仅约束 `@self` FBR。
+- **技术上 0 工具**（不是“提示词里说别用工具”）
+- **上下文以诉请正文为权威**（不是“默认继承主线历史”）
 
-## 定义
+这两点让 FBR 更像一个可控的“推理试算器”，而不是另一个会自行探索环境的智能体。
 
-- **扪心自问（FBR）**：从第一性原理出发，不依赖既有对话历史的推理方式。
-- **诉请（Tellask）**：以 `!?@...` 形式对某个对话参与方（包括 `@self`）发起的结构化请求。
-- **诉请者 / 被诉请者**：一次诉请中的请求方 / 应答方。
-- **主线对话 / 支线对话**：对外用语，用于描述承载主要推进的对话线程及其临时工作线程。
-  （实现语境中可能出现 `root/main/subdialog` 等术语；不要把这些实现术语写进用户可见提示词/示例。）
+### 2.2 不搞隐式魔法：禁用就要明确失败
 
-## 运行时行为：无工具 `!?@self` FBR
+如果团队配置禁用了 FBR（例如 `fbr-effort: 0`），运行时必须 **对用户可见且清晰地拒绝** `!?@self`，避免“看起来发了诉请、实际上被静默忽略”的隐性失败。
 
-### 触发：哪些诉请算作 FBR
+### 2.3 多样本推理，而不是“多代理协作”
 
-以下语法都视为 `@self` FBR：
+`fbr-effort` 的并发语义并不是让多条支线相互对话或协作，而是 **并行产生多个互相独立的推理样本**，由主线对话负责综合提炼。
 
-- 默认（瞬态）：`!?@self`
-- 少用（可恢复）：`!?@self !tellaskSession <tellaskSession>`（该支线对话会携带自身既有的 `tellaskSession` 历史）
+## 3. 用户语法（`@self` 只是入口）
 
-本文档对两者一视同仁：**任何 `@self` FBR 支线对话都必须是无工具的**。
+### 3.1 触发语法
 
-### 隔离约束
+以下两种语法都触发 FBR：
 
-运行时在驱动由 `!?@self` 创建的 FBR 支线对话时，必须强制满足：
+- **默认（瞬态）**：`!?@self`
+- **少用（可恢复）**：`!?@self !tellaskSession <tellaskSession>`
 
-- **无工具**：
-  - 不提供任何函数工具
-  - 不提供任何 MCP 工具
-  - 不允许发起任何队友诉请（包括 `!?@human`）；唯一例外：`!?@tellasker`（仅支线对话可用，用于回问上游诉请者对话），且当且仅当你需要澄清关键缺失上下文时才允许
-- **不依赖诉请者线程上下文**：
+说明：
+
+- `@self` 表示“对当前对话自身（同一 agentId）发起诉请”。它是 **自诉请的显式语法**，用于避免把 `@teammate` 的引用/回声误判成“自己给自己诉请”。
+- FBR 的“可恢复”能力来自 `!tellaskSession`（Tellask 会话寻址），而不是来自 `@self` 本身。
+
+### 3.2 作用域
+
+本文档只定义 **FBR 机制**，并说明其通过 `!?@self` 触发的行为契约。一般的队友诉请（`!?@<teammate>`）仍按 [`dialog-system.zh.md`](./dialog-system.zh.md) 的 Tellask 分类与能力模型执行。
+
+如果你需要“同人设但可用工具”的支线对话，不要用 `@self`；请使用一个明确的队友身份并授予其相应工具集（或用显式 `@<agentId>` 的一般诉请机制）。
+
+## 4. 运行时契约（必须做到什么）
+
+本节使用“必须/不得/应/可”描述运行时的强制要求。
+
+### 4.1 隔离与上下文
+
+当运行时驱动由 `!?@self` 创建的 FBR 支线对话时，必须强制满足：
+
+- **不依赖诉请者对话上下文**：
   - 被诉请者不得假设能访问诉请者的主线/支线对话历史
   - 被诉请者必须把诉请正文当作主要且权威的任务上下文
-  - 若使用 `!tellaskSession`（可恢复）形式，被诉请者可以使用**自身**既有的 `tellaskSession` 历史作为显式上下文
-  - 被诉请者不得通过工具去读文件/浏览/跑命令，或获取 Memory / rtws（运行时工作区）状态
+  - 若使用 `!tellaskSession`（可恢复）形式，被诉请者可以使用 **自身** 的 `tellaskSession` 历史作为显式上下文
+- **不得通过工具补上下文**：
+  - 不得读文件/跑命令/浏览
+  - 不得读取 Memory 或 rtws（运行时工作区）状态
 
-直觉上，可以把被诉请者理解为“相对诉请者线程是回到初心的”：它不会继承诉请者累积的对话历史；但它仍可能接收一些无条件注入的基础上下文（人设/系统规则/安全规范/格式规范/只读 Memory 摘要等）。当使用 `!tellaskSession` 形式时，该支线对话还会包含自身的会话历史。
+直觉上：FBR 的“初心”不是“忘掉一切系统规则”，而是“相对诉请者对话不继承历史”。运行时仍可能无条件注入基础规则（安全、格式、少量只读摘要等），但 **推理依据必须以诉请正文为主**（可恢复形式除外：可使用自身历史）。
 
-### 提示词契约（系统提示 + 工具提示）
+### 4.2 无工具（提示词 + 技术强制）
 
-运行时必须让“无工具”约束在提示词中明确且无歧义。
+FBR 的无工具约束必须同时满足两类要求：
 
-### API / 传输层契约（强制禁用工具）
+1. **提示词契约**：运行时必须把“无工具”约束表达得明确无歧义。
+2. **API/传输层契约**：运行时必须在技术上强制执行“0 工具”。
 
-“无工具”不仅是提示词写法，运行时必须在技术上强制执行：
+#### 4.2.1 system prompt 的要求（不得包含工具说明）
 
-- 发起 `@self` FBR 支线对话的 LLM 请求必须做到 **0 个可用工具**：
-  - 请求 payload 中不得包含任何 tool/function 定义（有效工具列表必须为空）
-  - 不得启用提供方支持的任何“工具调用模式 / 工具选择 / 函数调用 开关”
-- 即便提供方 SDK 默认会接受工具调用，运行时也必须拒绝 FBR 中模型发出的任何工具调用企图。
+FBR 支线对话的 system prompt 必须明确包含（措辞可不同，但语义必须到位）：
 
-#### system prompt 的最低要求
+- 这是一次 FBR 支线对话，诉请正文是主要任务上下文
+- 不要假设能访问诉请者对话历史
+- 若诉请正文缺少关键上下文，需要列出缺失信息与阻塞原因
+- 仅当必须澄清关键缺失上下文时，允许 `!?@tellasker` 回问诉请者；除此之外不要发起任何诉请
 
-FBR 支线对话的 system prompt 必须明确包含：
+同时，**system prompt 本体不得包含任何工具说明**（不得出现“有哪些工具/如何用工具/例子命令/白名单”等）。
 
-- 你**没有任何工具**，不能调用工具。
-- 你不能直接访问 rtws（运行时工作区） / 文件 / 浏览器 / shell（工具调用已禁用）。
-- 诉请正文是**主要任务上下文**；不要假设你能访问诉请者线程历史。
-- 若这是可恢复的 `!tellaskSession` FBR，你可以使用**自身**既有的 `tellaskSession` 历史作为显式上下文。
-- 若诉请正文缺少关键上下文，你需要列出缺失信息及其阻塞原因。
-- 仅当你必须澄清关键缺失上下文时，允许 `!?@tellasker` 回问诉请者；除此之外不要发起任何诉请。
+#### 4.2.2 附加“无工具提示”（唯一允许的工具相关文本）
 
-#### 工具提示的要求（如适用）
+关于工具可用性的所有表达必须收敛到单独附加的一段“无工具提示”，并且：
 
-如果某个提供方集成通常会注入工具提示（或工具结构），那么对 `@self` FBR 必须二选一：
+- 该提示必须 **简短、固定、不可扩展**
+- 必须明确声明：
+  - 没有任何工具，不能调用工具
+  - 不能访问 rtws / 文件 / 浏览器 / shell
+- 不得包含任何工具清单、允许列表、示例命令或执行指导
+
+如果提供方集成通常会注入工具提示（或工具结构），那么对 FBR 必须二选一：
 
 - 完全不注入工具提示，或
-- 注入一个明确声明“没有工具可用/工具调用已禁用”的工具提示
+- 仅注入与“无工具提示”**完全一致**的文本
 
 无论如何，FBR 支线对话都不应看到任何工具定义。
 
-### 输出契约
+#### 4.2.3 LLM 请求必须是“0 工具”
 
-FBR 支线对话应产出一份便于诉请者整合的简明推理结果。推荐结构（不强制）：
+发起 `@self` FBR 支线对话的 LLM 请求必须做到 **0 个可用工具**：
 
-1. **结论 / 建议**
-2. **推理过程**（基于诉请正文；若是可恢复形式，可结合自身 `tellaskSession` 历史）
-3. **前提假设**（应明确标注来源：诉请正文/会话历史）
-4. **未知项 / 缺失上下文**
-5. **下一步**（由诉请者在主线对话中执行；主线对话可能具备工具）
-
-### 执行与错误处理
+- 请求 payload 中不得包含任何 tool/function 定义（有效工具列表必须为空）
+- 不得启用提供方支持的任何“工具调用模式 / 工具选择 / 函数调用”开关
 
-- 如果 FBR 支线对话尝试发出工具调用，运行时必须将其视为硬错误，并将清晰的错误信息回贴给诉请者（不得静默忽略）。
-- 错误应当“响亮且可调试”（例如在日志/事件中携带明确的错误原因标识）。
+并且：如果模型仍尝试发出 tool/function call，运行时必须视为违规并硬拒绝（见 4.5）。
 
-## 配置：`.minds/team.yaml` 新增字段
+### 4.3 诉请限制：仅允许 `!?@tellasker`
 
-两个新增字段都是**按队友**配置的；也可以放在 `member_defaults` 下作为全局默认。
+FBR 支线对话不得发起任何队友诉请（包括 `!?@human`）。唯一例外是 `!?@tellasker`：
 
-### `fbr-effort`（默认：`3`）
+- 仅支线对话可用，用于回问上游诉请者对话
+- 仅当必须澄清关键缺失上下文时才允许
+- 允许“回问”，不鼓励“把任务推回去”
 
-`fbr-effort` 控制每次 `!?@self` 诉请要并发创建多少条无工具 FBR 支线对话。
+### 4.4 输出契约（便于主线综合）
 
-规则：
+FBR 支线对话应产出一份便于诉请者整合的简明推理结果。推荐结构（不强制）：
 
-- 类型：整数
-- 默认：`3`（“三个臭皮匠，顶个诸葛亮”）
-- `0`：禁用该队友的 `!?@self` FBR
-- `1..100`：每次 `!?@self` 并发创建 N 条 FBR 支线对话
-- `> 100`：配置错误（直接报错；不得自动截断）
-- `< 0` 或非整数：配置错误
+1. **结论 / 建议**
+2. **推理过程**（基于诉请正文；若为可恢复形式，可结合自身 `tellaskSession` 历史）
+3. **前提假设**（明确标注来源：诉请正文/会话历史）
+4. **未知与缺口**（如果有）
+5. **给主线的下一步**（主线可能有工具/队友，可在主线执行）
 
-**禁用行为（`fbr-effort: 0`）**：
+### 4.5 违规与报错（必须“响亮可调试”）
 
-- 运行时必须拒绝该队友发起的 `!?@self`（对用户可见且清晰），避免“静默失效”。
+- 若 FBR 支线对话尝试发起违规诉请（非 `@tellasker`）或尝试 tool/function call，运行时必须硬拒绝该次驱动。
+- 反馈必须 **对用户可见、语义清晰**，并且日志/事件中应包含可检索的错误原因字符串，避免静默吞掉。
 
-### 并发语义（`fbr-effort > 1`）
+## 5. 并发语义：`fbr-effort`
 
-当 `fbr-effort` 为 `N` 时：
+`fbr-effort` 是 **按队友成员（member）配置** 的整数参数，也可以放在 `member_defaults` 里作为 rtws 默认值。
 
-- 运行时将一条 `!?@self` 扩展为 **N 条并行的无工具 FBR 支线对话**。
-- 每条支线对话收到相同的诉请正文（以及相同的无工具系统提示 / 工具提示约束）。
-- 运行时会把所有 N 条回贴注入回诉请者；**不要依赖任何固定顺序**（可能按完成先后顺序混合注入）。
-- 对可恢复的 `!?@self !tellaskSession <tellaskSession>` 形式，若 `N > 1`，运行时必须派生出**不同的**
-  会话 key，以确保每条并行支线对话的历史互不污染（推荐方案：`<tellaskSession>.fbr<i>`）。
+- 类型：整数
+- 默认：`3`
+- `0`：禁用该成员的 `!?@self` FBR（必须明确报错拒绝）
+- `1..100`：每次 `!?@self` 并发创建 N 条 FBR 支线对话
+- `> 100` / 非整数 / 负数：配置错误（直接报错，不做 clamp）
 
-该设计的意图是让诉请者（主线）能够综合多条独立推理轨迹，提炼共识并做出更稳健的决策。
+当 `fbr-effort = N`：
 
-### `fbr_model_params`（可选）
+- 运行时必须把一条 `!?@self` 扩展为 **N 条并行的无工具 FBR 支线对话**
+- 每条支线接收相同的诉请正文与相同的 FBR 提示词约束
+- 主线必须接收全部 N 条回贴；**不应依赖固定顺序**（可按完成顺序回贴）
 
-`fbr_model_params` 用于只在 `@self` FBR 支线对话驱动 LLM 时覆盖模型参数。
+对可恢复的 `!?@self !tellaskSession <tellaskSession>` 形式，若 `N > 1`，运行时必须派生出 **不同的**
+会话键，使并行支线互不共享历史（推荐：`<tellaskSession>.fbr-<i>`）。
 
-- 结构：与 `model_params` 完全一致（参考 `dominds/main/llm/defaults.yaml` 的 `model_param_options`）
-- 作用域：仅对 `!?@self` FBR 支线对话生效
-- 非 FBR 场景仍使用正常的 `model_params`
+## 6. 模型参数覆盖：`fbr_model_params`
 
-**合并规则（推荐）**：
+`fbr_model_params` 用于只在驱动 FBR 支线对话时覆盖模型参数：
 
-- 先按常规规则计算队友的有效 `model_params`（defaults + overrides）。
-- 仅在 `@self` FBR 场景下，把 `fbr_model_params` 深合并覆盖到其上（例如只覆盖 `temperature`）。
+- 结构：与 `model_params` 完全一致（参考 `dominds/main/llm/defaults.yaml` 的 `model_param_options`）
+- 作用域：仅对 `!?@self` FBR 生效
+- 合并：建议在成员的有效 `model_params` 之上做深合并覆盖（便于只改少数字段，如 `temperature`）
+- `max_tokens` 允许写成顶层 `max_tokens`，也允许写成 `general.max_tokens`；二选一，禁止同时设置
 
-## 示例
+## 7. 配置示例
 
-### 无工具 FBR：诉请正文必须自给自足
+### 7.1 诉请正文必须自给自足
 
-反例（依赖外部上下文与工具）：
+坏例（依赖外部上下文与工具）：
 
 ```text
 !?@self
-帮我找 bug 并修掉。
+把 bug 找出来并修掉。
 ```
 
-正例（上下文自足）：
+好例（把关键上下文写进正文）：
 
 ```text
 !?@self
-你在做无工具的扪心自问（FBR）。只能使用下面这些文字作为上下文。
+你正在做无工具的 FBR。请只使用下方文本推理。
 
-目标：解释最可能的根因，并给出 2~3 个修复方案。
+目标：判断最可能的根因，并给出 2–3 个可行修复方向。
 
 现象：
-- 点击 “Run” 有时会让 UI 卡住 ~10 秒。
+- 点击 “Run” 偶发卡死 ~10 秒。
 
 约束：
 - 不能改后端协议。
 
-相关片段：
-<把关键日志 / 代码 / 栈追踪粘贴在这里>
+线索（日志/片段）：
+<粘贴相关日志或代码片段>
 ```
 
-### `.minds/team.yaml` 配置示例
+### 7.2 `.minds/team.yaml`
 
 ```yaml
 member_defaults:
-  # 默认每次 `!?@self` 并发创建 3 条无工具 FBR 支线对话（“三个臭皮匠，顶个诸葛亮”）。
+  # 默认每次 `!?@self` 并发创建 3 条无工具 FBR 支线对话。
   fbr-effort: 3
 
 members:
   ux:
-    # 每次 `!?@self` 并发创建 5 条独立的 FBR 支线对话。
+    # 每次 `!?@self` 并发创建 5 条独立推理样本。
     fbr-effort: 5
 
-    # 让 FBR 更“发散”，但不影响主线对话。
+    # 让 FBR 更“发散”，但不影响主线风格。
     fbr_model_params:
       codex:
         temperature: 0.9
@@ -207,15 +212,16 @@ members:
         max_tokens: 1200
 ```
 
-## 兼容性说明
+## 8. 与一般支线对话的关系（避免混用）
 
-- 本规范刻意让 `!?@self` 与一般的瞬态支线对话行为不同：
-  普通 `!?@<队友>` 的支线对话仍然是“全能力”的（可拥有工具/工具集），其行为以 [`dialog-system.zh.md`](./dialog-system.zh.md) 为准。
-- 若你需要“同人设但可用工具”的“回到初心”的支线对话，应使用一个明确的队友身份并为其授予相应工具集，而不是使用 `@self`。
+- `!?@self` 的 FBR 支线对话是 **特例**：无工具、正文优先、诉请受限、可并发扩展。
+- 一般的 `!?@<teammate>` 支线对话仍是“完整能力”的（可按配置拥有工具与工具集）。
+- 若你需要“同人设 + 可用工具”的支线，不要用 `@self`；请显式配置一个队友身份来承载这类工作线程。
 
-## 验收标准（实现检查清单）
+## 9. 验收清单（实现检查点）
 
-- `!?@self` 创建的 FBR 支线对话在技术上不提供任何工具，且系统提示 / 工具提示明确声明“无工具 + 诉请正文为主上下文”。
-- `fbr-effort` 默认 `3`；允许 `0..100`；`>100` 与非整数应报错。
-- `fbr-effort: 0` 时 `!?@self` 必须清晰失败（不可静默忽略）。
-- `fbr_model_params` 仅对 `@self` FBR 生效，且结构与 `model_params` 一致。
+- `!?@self` 触发 FBR：支线对话必须无工具，并且在 API 层确认为“0 工具”请求。
+- system prompt 本体不含工具说明；工具相关文本只能来自独立、固定的“无工具提示”。
+- FBR 支线对话不得发起队友诉请；仅允许必要时 `!?@tellasker` 回问。
+- `fbr-effort` 默认 `3`，接受 `0..100`，禁用时明确报错拒绝。
+- `fbr_model_params` 仅对 FBR 生效，且与 `model_params` 同结构、按深合并覆盖。

package/dist/docs/keep-going.zh.md

@@ -0,0 +1,162 @@
+# Keep-Going（鞭策）— 设计文档
+
+## 概述
+
+Dominds 根对话旨在长期运行。根对话"停止"（变为空闲）通常不是操作员想要的：他们希望智能体持续推进，直到：
+
+- 合法地暂停等待人类决策（Q4H），或
+- 合法地暂停等待子对话（tellask/backfill）。
+
+本文档指定了一个运行时机制（"keep-going"），仅针对**根/主对话**，防止对话停止：每当驱动程序即将停止时，它会自动发送一个简短的鞭策语（渲染为正常的用户气泡）并继续生成，除非对话处于合法暂停状态（Q4H 或待处理的子对话）。
+
+## 目标
+
+- 防止根对话停止，除非处于合法暂停状态（Q4H / 子对话）。
+- 保持行为可预测和有界（无无限循环）。
+- 使鞭策语文本可按工作区（rtws）和语言配置。
+- 提供清晰的用户控制的"禁用"机制。
+
+## 非目标
+
+- 自动完成/自动将对话标记为完成。
+- 将此行为应用于子对话（子对话保持范围，应向其调用者报告）。
+
+## 定义
+
+- **根/主对话**：`RootDialog`（`dlg.id.rootId === dlg.id.selfId`），主要对话线程。
+- **子对话**：`SubDialog`，为 tellask / 作用域工作创建。
+- **Q4H**："Questions for Human"，通过 `!?@human` 发起，暂停对话进度直到人类响应。
+
+## 预期的"正常"完成路径（推荐）
+
+当智能体需要人类决策来结束时（例如，确认选择或决定是否将对话标记为完成），正确的路径是：
+
+1. 智能体发出 Q4H（`!?@human`）并提供必要的上下文和明确的决策请求。
+2. WebUI 清楚地呈现 Q4H。
+3. 人类决定并：
+   - 手动将根对话标记为"完成"，或
+   - 提供请求的信息以便对话继续。
+
+这是"受控收敛"路径。keep-going 机制不应覆盖合法的暂停状态。
+
+## Keep-Going 行为（"自动继续"回退）
+
+### 触发条件（必须全部满足）
+
+- 对话是**根/主对话**（绝不会是子对话）。
+- 对话**未暂停**：
+  - 没有待处理的 Q4H，并且
+  - 没有待处理的子对话（等待回填）。
+- 驱动程序即将停止生成循环（即没有工具/函数输出需要另一次迭代）。
+
+### 操作
+
+运行时自动发送一个鞭策语（渲染为正常的用户气泡）并运行另一次生成迭代。
+
+### 有界性
+
+为避免无限循环，keep-going 有一个按对话的预算（每个成员的 `diligence-push-max`），控制对于给定对话在运行时强制 Q4H 暂停之前可以注入多少个自动继续的鞭策语。
+
+- 默认值：**3**
+- 如果 `< 1`，则该成员的 keep-going 有效禁用
+- 可通过 `.minds/team.yaml` 中的 `diligence-push-max` 按成员配置
+
+### Q4H 时重置
+
+当对话因待处理的 Q4H（Questions for Human）而暂停时，keep-going 注入计数器会被重置。这确保在人类回答 Q4H 并恢复对话后，对话会获得新的 keep-going 预算。
+
+### 预算耗尽 → 强制 Q4H
+
+当 keep-going 预算耗尽时，运行时会创建一个 Q4H 条目，询问人类是否继续或停止。这将"有界性"转换为合法的暂停点，并避免无限自动继续循环。
+
+### 禁用开关
+
+可以通过以下任一方式按 rtws 禁用 keep-going：
+
+- 如果选中的鞭策语文件存在但其内容为空/仅空白，则禁用 keep-going（不注入）。
+
+可以通过以下任一方式按成员禁用 keep-going：
+
+- 如果 `diligence-push-max < 1`，则该成员的 keep-going 被禁用（不注入）。
+
+## 鞭策语解析
+
+让 `<rtws>` 为当前运行时工作区（即 `process.cwd()`）。
+
+解析顺序：
+
+1. `<rtws>/.minds/diligence.<work-lang-id>.md`（例如，`diligence.zh.md`）
+2. `<rtws>/.minds/diligence.md`（语言无关的回退）
+3. 内置回退文本（硬编码的 i18n；`zh` 是规范的并嵌入在源代码中）
+
+如果上述顺序中第一个存在的文件具有空/空白内容，则**禁用** keep-going。
+
+注意：鞭策语文件中的 YAML frontmatter 会被运行时忽略。如果存在，它被视为非内容元数据并从提示正文中剥离。
+
+### 团队成员上限：`diligence-push-max`
+
+每个团队成员可以选择通过 `.minds/team.yaml` 限制 keep-going：
+
+```yaml
+members:
+  alice:
+    diligence-push-max: 10
+```
+
+规则：
+
+- 如果缺失，`diligence-push-max` 对于该成员默认为 **3**。
+- 如果 `diligence-push-max < 1`，则该成员的 keep-going 被禁用（不注入），即使鞭策语文件存在。
+- 内置影子成员 `fuxi` 和 `pangu` 默认为 `diligence-push-max: 0`，除非在 team.yaml 中显式覆盖。
+
+## UX 备注
+
+- Keep-going 是一个仅运行时的提示，但它应该是**可见的**：鞭策语渲染为正常的用户消息气泡（由运行时自动发送），以便操作员理解为什么会出现额外的迭代。
+- 用户应该观察到智能体在仅工具操作后继续简短的跟进。
+- 当智能体真正需要用户干预时，它应该使用 Q4H。Keep-going 不应试图"假装"完成。
+
+## 实现（后端）
+
+### 位置
+
+在 LLM 驱动程序循环中实现（`dominds/main/llm/driver.ts`），作为迭代后的小检查：
+
+1. 如果 `suspendForHuman` 为 true，则停止（Q4H / 子对话待处理）。
+2. 如果有任何工具反馈，则正常继续。
+3. 否则（仅限根），尝试 keep-going 自动继续：
+   - 如果禁用 → 正常停止。
+   - 如果预算耗尽 → 创建 Q4H 并停止。
+   - 否则 → 自动发送鞭策语并继续。
+
+### 消息类型
+
+我们将鞭策语作为自动发送的用户消息注入：
+
+- 类型为 `prompting_msg`、角色为 `'user'` 的 `ChatMessage`
+
+这确保了：
+
+- 它存在于模型上下文中
+- 它作为人类消息记录持久化
+- 它在聊天时间线中渲染为正常的用户气泡（像任何其他用户消息一样）
+
+## 可观察性
+
+建议的后续步骤（初始实现不需要）：
+
+- 当触发 keep-going 时添加结构化日志行，包括：
+  - 对话 id
+  - 语言
+  - 使用的鞭策语来源（语言特定/通用/内置/禁用）
+- 为"keep-going 触发"和"keep-going 因空文件禁用"添加可选的指标计数器。
+
+## 测试
+
+回归测试应覆盖：
+
+- 根对话：仅工具输出 → 鞭策语注入 → 继续响应
+- 根对话：空助手输出 → 鞭策语注入 → 继续响应
+- 子对话：无鞭策语注入
+- 工作区配置：
+  - 当语言特定文件缺失时，`.minds/diligence.md` 被遵守
+  - 空的鞭策语文件禁用 keep-going