@researai/deepscientist 1.5.15 → 1.5.17

package/docs/zh/15_CODEX_PROVIDER_SETUP.md

@@ -2,6 +2,8 @@
 
 DeepScientist 不会为 MiniMax、GLM、火山方舟、阿里百炼单独实现一套 provider 适配器。
 
+如果你要使用阿里百炼上的 Qwen，需要特别注意：DeepScientist 只支持 **Coding Plan** 这条路径，不支持普通百炼 / DashScope 平台的 Qwen API。
+
 它复用的是你本机已经能正常工作的 Codex CLI 配置。
 
 推荐顺序始终是：
@@ -18,7 +20,7 @@ DeepScientist 不会为 MiniMax、GLM、火山方舟、阿里百炼单独实现
 如果你的 Codex CLI 走的是标准 OpenAI 登录流，就用这一条。
 
 ```bash
-codex --login
+codex login
 ds doctor
 ds
 ```
@@ -62,7 +64,8 @@ codex:
 
 - 对 provider-backed 的 Codex profile，建议优先使用 `model: inherit`
 - 除非你非常确定该 provider 接受你要显式传入的模型名，否则不要再额外硬写一个模型
-- DeepScientist 会复用你终端里同一个 `~/.codex/config.toml` 与环境变量
+- DeepScientist 现在会在 `.ds/codex-home` 下启动一个隔离的运行时 home，但会先继承你配置的 `~/.codex` 里的 auth、config、skills、agents 与 prompts
+- 如果当前生效 provider 使用的是 `wire_api = "chat"`，DeepScientist 现在会在启动探测时自动检查所选 Codex binary 是否正好是 `0.57.0`
 
 ## Provider 一览
 
@@ -72,14 +75,14 @@ codex:
 | MiniMax | [MiniMax Codex CLI](https://platform.minimaxi.com/docs/coding-plan/codex-cli) | 否 | 使用你自己的 Codex profile，例如 `ds --codex-profile m27` |
 | GLM | [GLM Coding Plan：其他工具](https://docs.bigmodel.cn/cn/coding-plan/tool/others) | 否 | 使用一个指向 GLM coding endpoint 的 Codex profile |
 | 火山方舟 | [Ark Coding Plan 总览](https://www.volcengine.com/docs/82379/1925114?lang=zh) | 否 | 使用一个指向 Ark coding endpoint 的 Codex profile |
-| 阿里百炼 | [百炼 Coding Plan：其他工具](https://help.aliyun.com/zh/model-studio/other-tools-coding-plan) | 否 | 使用一个指向 Bailian coding endpoint 的 Codex profile |
+| 阿里百炼 | [百炼 Coding Plan：其他工具](https://help.aliyun.com/zh/model-studio/other-tools-coding-plan) | 否 | 使用一个指向 Bailian Coding Plan endpoint 的 Codex profile；不要使用普通百炼 / DashScope Qwen API |
 
 ## OpenAI
 
 ### 需要准备什么
 
 - 正常安装的 Codex CLI
-- 已成功执行过一次 `codex --login`，或者在 `codex` 交互界面里完成首次认证
+- 已成功执行过一次 `codex login`，或者在 `codex` 交互界面里完成首次认证
 
 ### DeepScientist 命令
 
@@ -109,13 +112,13 @@ MiniMax 是最典型的 profile 模式。它的官方 Codex CLI 文档直接给
 
 ### 已验证的兼容性说明
 
-按 2026-03-25 对 MiniMax 官方 Codex CLI 页面和本地兼容性测试的核对结果：
+按 2026-04-04 对 MiniMax 官方 Codex CLI 页面和本地兼容性测试的核对结果：
 
 - MiniMax 官方 Codex CLI 页面当前建议使用 `@openai/codex@0.57.0`
 - MiniMax 当前应使用的 Coding Plan endpoint 是 `https://api.minimaxi.com/v1`
 - MiniMax 官方页面示例 profile 名是 `m21`，但 profile 名本身只是本地别名；本仓库统一用 `m27` 作为示例名
 - MiniMax 官方页面当前给出的 `codex-MiniMax-*` 模型名，在本地使用你提供的 key 实测并不能稳定通过 Codex CLI
-- 本地实测能稳定跑通的组合是 `MiniMax-M2.7` + `m27` + `model: inherit` + Codex CLI `0.57.0`
+- 本地实测 DeepScientist 可稳定跑通的组合包括 `MiniMax-M2.7` + `m27` + Codex CLI `0.57.0`，以及 `MiniMax-M2.5` + `m25` + Codex CLI `0.57.0`
 - 当前最新版 `@openai/codex` 和 MiniMax 官方文档并不能稳定直接对齐
 
 如果你现在要走最稳的 DeepScientist + MiniMax 路径，建议直接使用 Codex CLI `0.57.0`。
@@ -125,7 +128,7 @@ MiniMax 是最典型的 profile 模式。它的官方 Codex CLI 文档直接给
 - 已安装 Codex CLI `0.57.0`
 - 已创建 MiniMax `Coding Plan Key`
 - 在启动 Codex 和 DeepScientist 的 shell 中可见的 `MINIMAX_API_KEY`
-- 当前 shell 已清理 `OPENAI_API_KEY` 和 `OPENAI_BASE_URL`
+- 如果你要单独在终端里验证 `codex --profile <name>`，当前 shell 需要先清理 `OPENAI_API_KEY` 和 `OPENAI_BASE_URL`
 - `~/.codex/config.toml` 中已经配置好的 Codex profile
 
 ### 安装 Codex CLI `0.57.0`
@@ -145,6 +148,8 @@ codex-cli 0.57.0
 
 如果你还想保留另一个 Codex 版本，也可以单独写一个 wrapper 脚本，再把 `runners.codex.binary` 指向那个绝对路径。
 
+现在如果 DeepScientist 在启动时检测到 MiniMax profile，但当前 `codex` 版本不是 `0.57.0`，在交互式终端里会主动提示是否自动安装 `@openai/codex@0.57.0`。
+
 ### Codex 侧配置
 
 请使用 `https://api.minimaxi.com/v1`，不要用 `https://api.minimax.io/v1`。
@@ -157,15 +162,19 @@ unset OPENAI_BASE_URL
 export MINIMAX_API_KEY="..."
 ```
 
+如果你是在终端里单独验证 `codex --profile <name>`，就按上面的方式处理。
+如果你走的是 DeepScientist 路径，那么当所选 provider 明确写了 `requires_openai_auth = false` 时，DeepScientist 现在会在 startup probe 和真实 runner 执行时自动剥离 `OPENAI_API_KEY` 和 `OPENAI_BASE_URL`。
+
 MiniMax 官方页面示例 profile 名是 `m21`。由于 profile 名只是本地别名，本仓库统一改写成 `m27`。
 
 先说明差异：
 
 - 官方页面当前展示的是 `codex-MiniMax-M2.5`
-- 但本地实测里，直接请求 MiniMax API 能稳定跑通的是 `MiniMax-M2.7`
-- 同一把 key 下，`codex-MiniMax-M2.5` / `codex-MiniMax-M2.7` 通过 Codex CLI 都会失败
+- 但本地实测里，直接请求 MiniMax API 能稳定跑通的是 `MiniMax-M2.7` 和 `MiniMax-M2.5`
+- 可复现的 DeepScientist 路径是：`MiniMax-M2.7` 配 `m27`，以及 `MiniMax-M2.5` 配 `m25`
+- 对 `m25` 这条路径，请使用 `MiniMax-M2.5`，不要写成 `codex-MiniMax-M2.5`
 
-因此，下面给的是当前 DeepScientist 推荐的可运行配置：
+因此，下面给的是当前 DeepScientist 推荐配置：
 
 ```toml
 [model_providers.minimax]
@@ -183,9 +192,20 @@ model = "MiniMax-M2.7"
 model_provider = "minimax"
 ```
 
+如果你想走同样的 DeepScientist 路径但使用 `m25`，保持上面的 provider 配置不变，再把 profile 写成：
+
+```toml
+[profiles.m25]
+model = "MiniMax-M2.5"
+model_provider = "minimax"
+```
+
 DeepScientist 现在对它的支持方式是：
 
-- 如果你使用的是这类 profile-only MiniMax 配置，再配合 Codex CLI `0.57.0`，DeepScientist 会在自己的 probe / 运行时临时 `.codex/config.toml` 里，把所选 profile 的 `model_provider` 和 `model` 自动提升到顶层
+- 如果你使用的是这类 profile-only MiniMax 配置，再配合 Codex CLI `0.57.0`，DeepScientist 会在自己的 probe / 运行时临时 `config.toml` 副本里，把所选 profile 的 `model_provider` 和 `model` 自动提升到顶层
+- 对 provider-backed 的 MiniMax profile，DeepScientist 会强制使用 `model: inherit`，避免再被硬编码的 OpenAI 模型覆盖
+- 当 `requires_openai_auth = false` 时，DeepScientist 会自动移除冲突的 `OPENAI_API_KEY` 和 `OPENAI_BASE_URL`
+- 对 MiniMax 这类 `Codex CLI 0.57.0 + wire_api = \"chat\"` 的会话，DeepScientist 现在会额外注入一个兼容约束，明确要求 Codex 把 MCP 工具调用串行化，一次只发一个 tool call，而不是把多个 tool call 打包进同一轮回复
 - 这意味着即使终端里原样执行 `codex --profile m27` 还会失败，DeepScientist 也可以先兼容跑起来
 
 如果你还希望终端里的 `codex --profile <name>` 也直接可用，请使用显式顶层兼容写法：
@@ -248,6 +268,7 @@ DeepScientist 现在会为 MiniMax 的 `0.57.0` 路径额外做两层兼容：
 
 - 当检测到旧版 Codex CLI 不支持 `xhigh` 时，自动把 `xhigh` 降级成 `high`
 - 当检测到 MiniMax 使用 profile-only 的 `model_provider` / `model` 配置形态时，在临时 DeepScientist Codex home 里自动补齐顶层字段
+- 当 provider 明确声明 `requires_openai_auth = false` 时，自动移除冲突的 `OPENAI_*` 认证环境变量
 
 ## GLM
 
@@ -334,6 +355,11 @@ codex:
 
 阿里百炼的 Coding Plan 官方文档也是 OpenAI-compatible endpoint 路径。它特别强调：必须使用 Coding Plan 专属 key 和 endpoint，而不是普通平台 endpoint。
 
+对 Qwen 这条路径，需要额外记住：
+
+- 支持：走百炼 **Coding Plan** 的 Qwen
+- 不支持：普通百炼 / DashScope 平台的 Qwen API
+
 官方文档：
 
 - <https://help.aliyun.com/zh/model-studio/other-tools-coding-plan>

package/docs/zh/19_EXTERNAL_CONTROLLER_GUIDE.md

@@ -0,0 +1,226 @@
+# 19 External Controller 指南
+
+DeepScientist 已经暴露出足够多的持久状态，因此你可以在不改 core runtime 的前提下，构建一层外部编排控制器。
+
+这篇文档说明一种最小、稳定的 external controller 模式，用来：
+
+- 检查 quest 最近状态
+- 判断当前 run 是否应该继续
+- 通过 quest mailbox 注入下一步路由消息
+- 必要时通过 `quest_control` 停止当前 run
+- 写出一份 durable report，解释为什么 guard 被触发
+
+这里刻意不引入重量级 plugin framework。
+
+## 什么时候适合用 external controller
+
+当某条规则满足下面任一条件时，适合放到外层 controller：
+
+- 明显是项目级 / 团队级规则
+- 不适合硬编码进全局 prompts 或 skills
+- 更像治理逻辑，而不是 core runtime 默认行为
+
+常见例子：
+
+- paper-facing 写作前的 publishability admission 规则
+- figure polish 在同一张图上反复 reopen 的空转
+- 某个实验室自己的 stop / branch 策略
+
+## 可以依赖的公共契约
+
+最稳妥的扩展面是现有的 durable runtime contract：
+
+- quest mailbox
+  - 排队中的用户消息位于 `.ds/user_message_queue.json`
+- 最近 quest 状态
+  - runtime state、artifact state、connector 可见输出本来就是 durable files
+- daemon quest control
+  - `POST /api/quests/<quest_id>/control`
+- connector 可见的 durable report
+  - 你可以在 quest 树下写自己的 report，供下一轮 turn 引用
+
+优先依赖这些契约，而不是 patch prompt、monkey-patch 私有实现，或者直接修改安装包文件。
+
+## 最小 controller 工作流
+
+一个 external controller 一般按下面顺序工作：
+
+1. 读取最新 durable quest state。
+2. 判断某个 guard 条件是否成立。
+3. 写 durable report，说明：
+   - 观察到了什么
+   - 这意味着什么
+   - 推荐的下一步路由是什么
+4. 如果需要干预：
+   - 可选地通过 `quest_control` 停止当前 run
+   - 往 mailbox 注入一条清晰的 routed message，供下一轮处理
+
+mailbox 里的消息应该表达结论与下一步，而不是原样转储日志。
+
+## 一个典型的控制流
+
+```text
+读取 quest 状态
+-> 识别低收益循环或路线漂移
+-> 写 durable report
+-> 必要时 stop 当前 run
+-> 往 mailbox 注入下一步 routed message
+```
+
+## `quest_control` 请求示例
+
+```bash
+curl -X POST http://127.0.0.1:20999/api/quests/<quest_id>/control \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "action": "stop",
+    "source": "external-controller"
+  }'
+```
+
+## mailbox intervention 内容示例
+
+队列文件本身由 runtime 管理，所以 controller 应该保留既有 schema，只追加一条普通的 user-style message payload。
+
+消息正文应短而可执行，例如：
+
+```text
+Hard control message from external orchestration layer: stop the current figure loop.
+Return to the main line and do one bounded route next:
+1. literature scout
+2. reference expansion
+3. manuscript body revision
+```
+
+## 可以直接照着改的 controller 例子
+
+### 例 1：publishability admission guard
+
+这类 controller 适合处理一种常见情况：quest 还没有把证据线做扎实，却已经开始往 paper-facing 写作漂移。
+
+常见输入：
+
+- 最新 verification 结论
+- 当前 draft / summary 状态
+- 最近 baseline、utility 或主实验结果
+
+常见触发条件：
+
+- 当前论文主张的支撑仍然偏弱
+- 还有一项或多项必要证据没有补齐
+
+常见干预动作：
+
+1. 写出 `reports/publishability_guard.md`，明确缺什么支撑。
+2. 通过 `quest_control` 停止当前偏写作的 run。
+3. 往 mailbox 注入一条 routed message，把下一轮明确导回 `idea`、`analysis` 或某个有边界的证据修复步骤。
+
+示例消息正文：
+
+```text
+External controller: do not continue manuscript-facing writing yet.
+Reason: the current evidence line does not pass the publishability admission gate.
+Next route: return to one bounded evidence-building step before write resumes.
+```
+
+### 例 2：figure-loop guard
+
+这类 controller 适合处理另一种常见情况：同一张图不断 reopen / polish，但对主结论已经没有实质推进。
+
+常见输入：
+
+- 最近的 figure artifact 历史
+- 重复 reopen 的事件记录
+- 最新 review 或 summary 结论
+
+常见触发条件：
+
+- 同一张图已经反复 reopen 多次，但主张没有被强化
+- 下一步更有价值的动作已经不是继续 polish，而是修证据或改正文
+
+常见干预动作：
+
+1. 写出 `reports/figure_loop_guard.md`，概括当前循环为何低收益。
+2. 必要时停止当前 figure 分支。
+3. 往 mailbox 注入一条只给出一个下一步路由的消息。
+
+示例消息正文：
+
+```text
+External controller: stop the current figure-polish loop.
+Reason: repeated reopen cycles are no longer improving the main evidence line.
+Next route: return to one bounded manuscript or analysis task.
+```
+
+## connector 定制时，通常改什么
+
+controller 本身的控制逻辑最好保持 connector-agnostic。实际适配到不同 connector 时，通常只需要改消息呈现 profile，而不需要改 stop 逻辑或 durable report 契约。
+
+例如：
+
+```yaml
+connector_profiles:
+  weixin:
+    summary_style: concise
+    max_route_options: 2
+    include_report_path: true
+  telegram:
+    summary_style: concise
+    max_route_options: 3
+    include_report_path: true
+  studio:
+    summary_style: detailed
+    max_route_options: 4
+    include_report_excerpt: true
+```
+
+controller 的核心决策始终不变：
+
+- 读取 durable state
+- 判断是否应该 stop
+- 写一份 durable report
+- 注入一条 routed mailbox message
+
+真正跟 connector 相关的，通常只是给人看的信息颗粒度和呈现方式。
+
+## durable report 建议结构
+
+report 应该尽量简单且可审计。
+
+一份好的 report 一般至少包含：
+
+- `generated_at`
+- `quest_id`
+- `status`
+- `recommended_action`
+- `blockers`
+- `evidence_summary`
+
+常见且实用的做法是：一份 Markdown 报告，外加一份 machine-readable JSON。
+
+## 不建议依赖什么
+
+避免构建依赖下面这些东西的 controller：
+
+- 私有 prompt 文本偏移或拼接细节
+- 没有文档化的临时日志
+- 直接改 `site-packages` 里的安装包文件
+- 仅前端可见、没有 durable contract 的状态
+
+如果某个 controller 必须依赖这些东西，说明契约还不够稳定。
+
+## 设计建议
+
+- 每个 controller 只回答一个清晰问题
+- 优先写可回看的报告，而不是做隐藏副作用
+- 只有当下一步路由很清楚时才 stop 当前 run
+- 领域特定或团队特定规则尽量留在 core defaults 之外
+- 把 external controller 当成可选治理层，而不是必需运行层
+
+## 最适合先做的 controller
+
+如果你想先从小处开始，优先做下面几类：
+
+- 面向 paper-mode quest 的 publishability admission guard
+- 阻止 figure reopen 循环的 figure-loop guard
+- 在证据未准备好时阻止误入 `write` 的 route-drift guard

package/docs/zh/19_LOCAL_BROWSER_AUTH.md

@@ -0,0 +1,68 @@
+# 本地浏览器密码说明
+
+DeepScientist 现在可以为本地 Web 工作区按需开启一层 16 位随机密码保护。
+
+这层保护是本地优先的：
+
+- 浏览器界面会先被拦住
+- 浏览器发出的 `/api/*` 请求也会一起受保护
+- 默认关闭；只有在你用 `ds --auth true` 启动，或配置 `ui.auth_enabled: true` 时才会开启
+
+## 启动时会发生什么
+
+当你执行 `ds --auth true` 时，终端里会打印两类关键信息：
+
+- 本地浏览器地址，例如 `http://127.0.0.1:20999`
+- 这次启动生成的本地访问密码
+
+现在浏览器地址本身不再依赖 `?token=...`。
+
+如果当前浏览器还没有通过认证，DeepScientist 会先在首页之上弹出一个密码框；在输入正确密码之前，quest 列表、设置页、文档页和工作区数据都不会继续加载。
+
+## 怎样查看密码
+
+可以用下面任一方式：
+
+```bash
+ds --status
+```
+
+然后在 JSON 输出里查看 `auth_token` 字段，或者直接回到启动 `ds` 的那个终端。
+
+## 登录态怎样持久化
+
+第一次成功输入之后：
+
+- 浏览器会保存这次本地登录态
+- 同一个浏览器后续再次访问时，通常可以直接进入
+- 但当 managed daemon 被重启或复用并触发密码轮换时，浏览器会再次要求输入
+
+## 怎样关闭
+
+如果你只想在某一次启动里开启这层本地密码保护，可以这样启动：
+
+```bash
+ds --auth true
+```
+
+开启后：
+
+- 首页会出现密码框
+- 浏览器对 `/api/*` 的请求也会要求本地密码
+
+如果你之后想在某一次启动里显式关闭它，可以这样启动：
+
+```bash
+ds --auth false
+```
+
+关闭后：
+
+- 首页不会再弹出密码框
+- 浏览器对 `/api/*` 的请求也不会再要求本地密码
+
+## 实际建议
+
+- 这不是面向公网的强认证机制，它更像是“本机浏览器入口保护”。
+- 如果这台机器会被他人接触，或者你把端口暴露到外部网络，建议保持开启。
+- 如果你需要用浏览器脚本直接请求本地 daemon，要么先完成登录，要么明确使用 `ds --auth true` 启动并复用本地登录态。

package/docs/zh/20_WORKSPACE_MODES_GUIDE.md

@@ -0,0 +1,251 @@
+# 20 工作区模式指南：Copilot 与 Autonomous
+
+这篇文档专门解释 DeepScientist 创建项目时最重要的两种模式：
+
+- `Copilot`
+- `Autonomous`
+
+适合这些场景：
+
+- 你正准备创建一个新项目
+- 你不确定该选哪种启动方式
+- 你想理解为什么有的项目会先待命，有的项目会一创建就开始推进
+
+如果你只想快速安装并跑通第一条路径，先看 [00 快速开始](./00_QUICK_START.md)。
+
+如果你想看启动表单和提交 payload 的精确字段，再看 [02 Start Research 参考](./02_START_RESEARCH_GUIDE.md)。
+
+## 1. 一句话总结
+
+- `Copilot`：安静启动、用户主导、做完当前请求单元后通常停驻
+- `Autonomous`：标准版 DeepScientist，默认继续推进 quest
+
+## 2. 你是在哪里选择它的
+
+在首页或 Projects 页面里，新建项目时会先让你选择启动方式：
+
+- `Copilot Mode`
+- `Autonomous Mode`
+
+当前 UI 里可能会看到两层文案：
+
+- 外层入口：`Start Research` 或 `Start Experiment`
+- 模式选择弹窗标题：`Choose the start style`
+
+选完之后，这两条创建路径就会分开。
+
+## 3. Copilot 模式
+
+### 3.1 它是什么
+
+Copilot 模式是“用户主导的工作区”。
+
+适合你想让 DeepScientist 主动帮忙，但又希望每个工作单元都由你来明确主导的场景，例如：
+
+- 看仓库
+- 读论文
+- 改代码
+- debug
+- 设计实验
+- 检查运行状态
+- 改写段落
+- 汇总结论
+
+它不应该默认把你的一句话理解成“现在开始完整自治科研流程”。
+
+### 3.2 创建之后会发生什么
+
+创建 Copilot 项目之后：
+
+- 项目会被创建出来
+- quest 会保持 idle / 待命
+- agent 等你发第一条真正的工作指令
+
+也就是说：
+
+- 不会因为项目存在就立刻自动开跑
+- 不会默认直接进入 baseline / experiment / write 长循环
+- 第一轮实质动作从你的第一条消息开始
+
+### 3.3 continuation 行为
+
+Copilot 模式对 continuation 是刻意保守的。
+
+在当前请求单元完成之后，DeepScientist 正常应该：
+
+- 说明这轮做了什么
+- 把上下文和结果持久化
+- 等待你下一条消息或 `/resume`
+
+它适合这些目标：
+
+- 你想强控制节奏
+- 你想按 request-by-request 方式协作
+- 你不希望后台自己扩太多
+- 你希望 handoff 点很清楚
+
+### 3.4 什么时候适合选
+
+选择 `Copilot`，通常意味着：
+
+- 你想先看、先问、先改，再决定是否启动长任务
+- 当前任务边界还不清楚
+- 你预期会频繁交互式迭代
+- 你想让 DeepScientist 更像“科研 IDE 搭子”，而不是自治 operator
+
+### 3.5 什么时候不适合选
+
+不建议在这些情况下选 `Copilot`：
+
+- 你已经明确知道这个 quest 应该持续运行好几个小时
+- 你希望 detached 实验、监控、后续路由自己接着往前推
+- 你的目标是让系统接管完整推进，而不是一小段一小段地问答协作
+
+## 4. Autonomous 模式
+
+### 4.1 它是什么
+
+Autonomous 模式就是标准版 DeepScientist 的工作方式。
+
+适用于 quest 应该自己持续推进、普通路线选择默认由系统承担的情况。
+
+典型场景包括：
+
+- baseline 建立
+- 长实验
+- analysis campaign
+- 持续写作 / finalize
+- 通过 connector 长时间回传项目进展
+
+### 4.2 创建之后会发生什么
+
+创建 Autonomous 项目之后：
+
+- quest 会被创建
+- 第一轮会立即启动
+- 系统开始把 startup contract 变成真实工作
+
+这可能包括：
+
+- 读 baseline 和参考资料
+- 检查环境和约束
+- 准备脚本
+- 决定下一条路线
+- 启动 detached `bash_exec` 长任务
+
+### 4.3 continuation 行为
+
+Autonomous 模式下，continuation 可以分成两个阶段来理解。
+
+#### A. 还没有真实长任务
+
+如果真实的外部长时间任务还没有跑起来，DeepScientist 不应该停住。
+
+它应该继续用后续 turns 去：
+
+- 准备真实任务
+- 启动真实任务
+- 或者把“下一个真实任务到底是什么”记录成耐久决策
+
+这是“准备 / 启动阶段”。
+
+#### B. 已经有真实长任务在跑
+
+一旦真实 detached 长任务已经在跑，continuation 的节奏就应该变。
+
+这时候不应该再用高频 LLM turn 去假装“持续执行”。
+
+更合理的方式是：
+
+- 真实工作继续留在 detached `bash_exec` 或它启动的运行时进程里
+- agent turn 变成低频监控 / 汇总 / 决策
+- 当前默认巡检节奏大约是每 `240` 秒一轮
+
+这是“后台长任务巡检阶段”。
+
+### 4.4 什么时候适合选
+
+选择 `Autonomous`，通常意味着：
+
+- quest 应该自己持续往前推
+- 你预期会有真实长时间实验或分析工作
+- 你希望 milestone 之后系统自动继续路由
+- 你想用标准版 DeepScientist 的完整研究操作系统行为
+
+### 4.5 什么时候不适合选
+
+不建议在这些情况下选 `Autonomous`：
+
+- 你只是想先建一个安静的项目壳
+- 你想先人工检查仓库、再决定是否启动
+- 你希望每个下一步都由你明确指令驱动
+
+## 5. 最关键的实际区别
+
+最容易记住的方式是：
+
+- `Copilot` 问的是：“我现在该帮你完成哪一个具体单元？”
+- `Autonomous` 问的是：“这个 quest 的下一个真实步骤是什么，我该怎样让它继续推进？”
+
+真正重要的是这个差异，而不是名字本身。
+
+## 6. Resume 是怎么工作的
+
+两种模式都会保留持久上下文，但 resume 方式不同。
+
+现在 auto-continue turn 里会带一个紧凑的 `resume spine`，里面可能包括：
+
+- 最近一条持久化用户消息
+- 最近一条 assistant checkpoint
+- 最近一条 run 摘要
+- 少量最近 memory cue
+- 当前 `bash_exec` 状态
+
+但 continuation policy 仍然不同：
+
+- `Copilot`：你说话了，或者显式 `/resume` 了，才继续
+- `Autonomous`：除非进入显式等待状态，否则默认继续推进
+
+## 7. 快速选择方法
+
+你可以用这个简单规则：
+
+1. 如果你想让项目先安静待命，等你说第一句明确指令，再开始干活，选 `Copilot`。
+2. 如果你想让 DeepScientist 一创建项目就开始把合同变成真实工作，选 `Autonomous`。
+3. 如果你暂时拿不准，先用 `Copilot` 更稳；路线清楚后再进入更长时间的自治推进。
+
+## 8. 常见误解
+
+### “Autonomous 就意味着必须一直高速空转”
+
+不是。
+
+Autonomous 的意思是：quest 要继续推进。
+
+如果还没有真实长任务，那推进可以表现为快速准备 / 启动。
+如果真实长任务已经在跑，那推进就应该表现为低频巡检，而不是高频模型空转。
+
+### “Copilot 就不能跑实验”
+
+也不是。
+
+Copilot 当然也能帮你启动实验、看运行状态、做分析、改写作。
+区别在于：它不该在你没明确要求的时候，自己扩成长期自治流程。
+
+### “这两个模式只是文案不同”
+
+不是。
+
+它们会影响：
+
+- 创建后的默认行为
+- continuation policy
+- quest 什么时候停驻
+- 多大程度上应该自己继续做路线推进
+
+## 9. 相关文档
+
+- [00 快速开始](./00_QUICK_START.md)
+- [02 Start Research 参考](./02_START_RESEARCH_GUIDE.md)
+- [12 引导式工作流教程](./12_GUIDED_WORKFLOW_TOUR.md)
+- [14 Prompt、Skills 与 MCP 指南](./14_PROMPT_SKILLS_AND_MCP_GUIDE.md)