@saluzi/saluzi-edu 0.2.49 → 0.2.51

package/dist/guide/guide-data.json

@@ -1927,6 +1927,10 @@
       "name": "SALUZI_BLOCKING_LIMIT_OVERRIDE",
       "category": "other"
     },
+    {
+      "name": "SALUZI_BRIDGE_ALLOW_INSECURE_HTTP",
+      "category": "other"
+    },
     {
       "name": "SALUZI_BRIDGE_BASE_URL",
       "category": "bridge",
@@ -2967,21 +2971,36 @@
     }
   ],
   "chapters": {
-    "docs/guide/commit-workflow": {
+    "docs/guide/troubleshooting": {
       "frontmatter": {
-        "title": "查看与提交代码 - diff、commit 与 PR 工作流",
-        "description": "使用 /diff 预览改动、/commit 提交、/commit-push-pr 一条龙推送并创建 PR、/review 代码审查。",
+        "title": "排障 - 诊断安装与调整权限",
+        "description": "使用 /doctor 诊断安装、/help 查命令、/permissions 调整权限、/plan 规划模式。",
         "keywords": [
-          "diff",
-          "commit",
-          "commit-push-pr",
-          "review",
-          "提交",
-          "PR",
-          "代码审查"
+          "doctor",
+          "help",
+          "permissions",
+          "plan",
+          "排障",
+          "诊断",
+          "权限",
+          "规划模式"
         ]
       },
-      "content": "\n## 预览改动\n\n在提交前，先用 `/diff` 查看当前工作区所有未提交的改动，确认修改范围是否符合预期：\n\n```\n> /diff\n```\n\nSaluzi 会列出已暂存和未暂存的文件变更摘要，帮助你快速定位哪些文件被新增、修改或删除。\n如果发现意外改动，可以先撤销再继续。\n\n## 提交代码\n\n确认改动无误后，使用 `/commit` 提交。Saluzi 会根据 diff 内容自动生成 Conventional Commits 格式的 commit message：\n\n```\n> /commit\n```\n\n你也可以附加参数指定 message 类型或描述：\n\n```\n> /commit -m \"fix: 修复登录页的空指针问题\"\n```\n\n提交后改动保存在本地仓库，不会自动推送到远端。\n\n## 推送并创建 PR\n\n如果想一步到位——提交、推送、并在 GitHub 上创建 Pull Request，使用 `/commit-push-pr`：\n\n```\n> /commit-push-pr\n```\n\nSaluzi 会依次执行：\n1. 根据改动生成 commit message 并提交\n2. 将当前分支推送到远端\n3. 基于 commit 信息创建 PR 标题与描述\n\n适合功能分支开发完毕后一次性完成发布流程。\n\n## 代码审查\n\n使用 `/review` 对当前分支的改动或指定 PR 进行审查：\n\n```\n> /review\n```\n\n也可以指定 PR 编号：\n\n```\n> /review #42\n```\n\nSaluzi 会逐文件分析改动，指出潜在的 bug、风格问题和改进建议。\n\n## 提交模式对比\n\n| 特性 | `/commit` | `/commit-push-pr` |\n|------|-----------|-------------------|\n| 自动生成 commit message | 是 | 是 |\n| 提交到本地仓库 | 是 | 是 |\n| 推送到远端分支 | 否 | 是 |\n| 创建 Pull Request | 否 | 是 |\n| 适用场景 | 本地暂存、分批提交 | 功能完成后一步发布 |\n\n## 下一步\n\n- [上下文与项目记忆](./context-tips) — 让 AI 更懂你的项目\n- [查看消耗](./cost-usage) — 了解会话花费\n- [排障](./troubleshooting) — 常见问题与解决方案\n"
+      "content": "\n## 诊断安装\n\n遇到启动异常或功能不符预期时，先运行 `/doctor` 做全面体检：\n\n```\n> /doctor\n```\n\n该命令会依次检查：\n\n- CLI 版本是否为最新\n- Node / Bun 运行环境是否满足\n- 配置文件是否完整\n- 网络连接是否正常\n\n若有异常项，输出会给出具体的修复建议。\n\n## 查命令\n\n不确定某个命令的用法时，用 `/help` 列出所有可用命令：\n\n```\n> /help\n```\n\n查看单个命令的详细用法：\n\n```\n> /help commit\n```\n\n输出包含命令说明、参数列表和使用示例。\n\n## 调整权限\n\nSaluzi 每次调用工具前会请求权限。用 `/permissions` 查看和调整当前权限规则：\n\n```\n> /permissions\n```\n\n权限分三种策略：\n\n| 策略 | 含义 |\n|------|------|\n| Allow | 自动放行，不再询问 |\n| Deny | 直接拒绝，禁止调用 |\n| Ask | 每次弹出确认（默认） |\n\n对常用工具设置 Allow 可以减少交互打断，提升效率。\n\n## 规划模式\n\n面对复杂任务时，用 `/plan` 让 Saluzi 先制定计划再执行：\n\n```\n> /plan 重构用户模块，拆分为独立的 service 层\n```\n\n进入规划模式后，Saluzi 会：\n1. 分析需求并拆解步骤\n2. 列出待执行的操作清单\n3. 确认后再逐步实施\n\n适合在动手前理清思路，避免盲目修改。\n\n## 常见问题\n\n| 问题 | 可能原因 | 解决方法 |\n|------|---------|---------|\n| 登录失败 | Token 过期或网络异常 | 重新运行 `/login`，或检查代理设置 |\n| 工具权限被拒 | 对应工具被设为 Deny | 运行 `/permissions` 将策略改为 Allow |\n| 命令找不到 | 输入拼写有误 | 运行 `/help` 确认命令名称 |\n| 模型不可用 | 账户额度耗尽或区域限制 | 用 `/model` 切换到其他可用模型 |\n\n## 下一步\n\n- [查看与提交代码](./commit-workflow) — diff、commit 与 PR 工作流\n- [主目录与配置](./saluzi-home) — 配置文件位置与字段说明\n- [费用与用量](./cost-usage) — 了解 Token 消耗与费用控制\n- [代码图谱](./codegraph) — 用 CodeGraph 深入理解项目结构\n"
+    },
+    "docs/guide/keys-binding": {
+      "frontmatter": {
+        "title": "API Key 绑定",
+        "description": "使用 /keys 命令管理多个 API Key，绑定到模型槽位（default/max/pro/std/subagent），实现多 provider 混用与灵活切换。",
+        "keywords": [
+          "keys",
+          "API Key",
+          "绑定",
+          "provider",
+          "模型槽位"
+        ]
+      },
+      "content": "\n## 什么是 /keys\n\n`/keys` 命令管理 Saluzi 的 API Key 绑定。它采用**双栏 TUI 界面**（左栏为模型槽位，右栏为 Key 列表），支持：\n\n- 绑定多个 provider 的 Key（Anthropic、OpenAI、Gemini、Grok、Foundry、自定义等）\n- 将 Key 绑定到不同的**模型槽位**（default / max / pro / std / subagent）\n- 为每个 Key 设置名称、指定 Base URL（transit 代理场景）\n- 编辑、删除、解绑已有配置\n\n## 使用方法\n\n```\n> /keys\n```\n\n打开双栏管理面板。通过键盘快捷键操作：\n\n| 快捷键 | 操作 |\n|--------|------|\n| `a` | 添加新 Key |\n| `e` | 编辑已有 Key（名称/provider/URL/key 值） |\n| `d` | 删除 Key |\n| `b` | 绑定到模型槽位 |\n| `u` | 解绑槽位 |\n| `Esc` | 关闭面板 |\n\n添加 Key 时需要输入：\n- Key 名称（如 `anthropic-work`）\n- Provider（Anthropic Direct / Transit / OpenAI / Gemini / Grok / Foundry / Custom）\n- API Key 值\n- Base URL（Transit、Foundry、Custom 等场景需要）\n\nKey 保存在本地配置中，不会提交到 VCS。\n\n## 模型槽位\n\n`/keys` 的核心概念是**模型槽位**。每个槽位对应一个模型级别：\n\n| 槽位 | 说明 |\n|------|------|\n| `default` | 默认 Key，所有模型共用 |\n| `max` | Max 级别模型专用 Key |\n| `pro` | Pro 级别模型专用 Key |\n| `std` | Std 级别模型专用 Key |\n| `subagent` | 子 agent 专用 Key |\n\n当 `/model max` 执行时，Saluzi 优先使用 `max` 槽位的 Key；未配置时回退到 `default`。\n\n## 槽位上下文长度\n\n不同 provider 的模型上下文窗口可能不一致（例如 Anthropic 200K、Gemini 1M、某些 OpenAI 兼容端点 128K）。默认情况下，所有槽位共用全局配置的上下文上限（`SALUZI_MAX_CONTEXT_TOKENS` 或 `/login` 配置）。\n\n`/keys` 支持为每个槽位单独配置上下文长度：\n\n1. 在 Model Slots 区域选中目标槽位，按 `b` 开始绑定\n2. 选择 Key 后输入 model name（可留空使用 provider 默认）\n3. 在 **Context Limit** 步骤输入该槽位的上下文 token 数（如 `200000`、`1000000`），留空则使用全局配置\n\n配置后，切换到该槽位的模型时，状态栏与 auto-compact 阈值都会使用槽位专属的上下文长度。槽位列表会显示 `[ctx: 500k]` 标记。\n\n槽位上下文长度的解析优先级：\n\n1. `SALUZI_MAX_CONTEXT_TOKENS`（管理员全局强制覆盖，最高优先）\n2. `KEYS_{SLOT}_CONTEXT_LIMIT`（本槽位配置）\n3. `SALUZI_AUTO_COMPACT_WINDOW`（全局 auto-compact 阈值）\n4. `[1m]` 后缀 / 模型能力缓存 / 200K 默认\n\n## 环境变量\n\n可通过环境变量预设 Key 配置（CI/CD 场景常用）：\n\n```bash\nKEYS_DEFAULT_KEY=sk-xxx slz\nKEYS_MAX_KEY=sk-xxx KEYS_MAX_MODEL=claude-opus-4-7 KEYS_MAX_CONTEXT_LIMIT=1000000 slz\n```\n\n格式为 `KEYS_{SLOT}_{FIELD}`，其中 SLOT 为 `DEFAULT`/`MAX`/`PRO`/`STD`/`SUBAGENT`，FIELD 为 `KEY`/`PROVIDER`/`MODEL`/`URL`/`CONTEXT_LIMIT`。\n\n## Provider 选择\n\nSaluzi 自动选择最优 Provider。如需指定：\n- 通过环境变量（如 `ANTHROPIC_API_KEY`）指定\n- 通过 `/keys` 绑定特定 provider 的 Key 到对应槽位\n- 通过 `/model` 切换当前会话模型\n\n## 安全建议\n\n- 不要把 Key 写进代码或 commit\n- 用 `/keys` 管理而非环境变量（更安全、可切换）\n- 定期轮换 Key\n"
     },
     "docs/guide/parade": {
       "frontmatter": {
@@ -2997,6 +3016,23 @@
       },
       "content": "\n## 什么是 /parade\n\nParade 是 Saluzi 的桌面悬浮提示功能。它在桌面显示一个小型悬浮窗口（基于 Electron），实时反映：\n\n- **运行中会话数**：当前正在执行工具调用的会话\n- **等待中会话数**：等待用户输入或权限确认的会话\n- **连接状态**：WebSocket 连接状态指示灯\n\n外观示意（运行中 2 / 等待 1）：\n\n::parade-preview::\n\n## 启用 Parade\n\n```\n> /parade\n```\n\n首次启用会自动检测并安装 Electron（若未安装），然后启动悬浮窗。悬浮窗默认定位在**主显示器顶部居中**，220×130 像素，无边框始终置顶。\n\n## 关闭 Parade\n\n```\n> /parade off\n```\n\n## 多会话并行\n\n多个终端各自运行 Saluzi 会话时，所有 CLI 实例共享同一个 Parade 窗口（通过 PID 锁文件确保单例）。悬浮窗显示所有已连接会话的运行/等待计数。\n\nParade 服务器以**脱离模式**运行——即使启动它的 CLI 关闭，悬浮窗仍然存活，直到用 `/parade off` 显式关闭。\n\n## 平台支持\n\n| 平台 | 状态 | 说明 |\n|------|------|------|\n| macOS | 完全支持 | 原生 Electron |\n| Linux | 支持 | 需 X11 或 Wayland |\n| Windows | 支持 | Electron |\n| WSL | 支持 | 通过 /etc/resolv.conf 解析主机 IP |\n\n## 故障排查\n\n- **悬浮窗不显示**：检查 Electron 是否安装（`/parade` 会自动安装，支持 `ELECTRON_MIRROR` 环境变量配置镜像）\n- **Electron 安装路径**：`~/.saluzi/parade/`\n- **多显示器**：悬浮窗默认在主显示器顶部居中\n"
     },
+    "docs/guide/oms-workflow": {
+      "frontmatter": {
+        "title": "OMS 工作流 - 多角色编排与自动化任务系统",
+        "description": "OMS（Orchestra Management System）工作流命令系列：autopilot、ralplan、ralph、team、clarify、autoresearch、ultrawork、goal、orchestra、define，基于 DAG 调度与多角色 agent 协同执行复杂任务。",
+        "keywords": [
+          "OMS",
+          "工作流",
+          "autopilot",
+          "orchestra",
+          "ralph",
+          "自动化",
+          "编排",
+          "DAG"
+        ]
+      },
+      "content": "\n## 什么是 OMS\n\nOMS（Orchestra Management System）是 Saluzi 的高级任务编排系统。它将复杂任务分解为多个阶段（stage），每个阶段由专属角色的 agent 执行，通过 DAG（有向无环图）调度依赖关系，支持并行执行、质量门禁、失败重试与多轮迭代。\n\n## OMS 命令一览\n\n| 命令 | 用途 | 定位 |\n|------|------|------|\n| `/oms` | 智能路由：根据自然语言自动选择最佳工作流 | 入口 |\n| `/oms-autopilot` | 全自动 6 阶段流水线：需求→规划→实现→QA→验证→报告 | 全链路 |\n| `/oms-ralplan` | 共识规划：Planner→Architect→Critic 三轮审议 | 规划 |\n| `/oms-ralph` | PRD 驱动的持久循环：逐个用户故事实现并验证 | 执行 |\n| `/oms-team` | N 并行 worker：任务分解→并行实现→集成验证 | 并行执行 |\n| `/oms-clarify` | 苏格拉底式深度访谈：通过问答降低需求模糊度 | 需求澄清 |\n| `/oms-autoresearch` | 评估器驱动的迭代改进：实验→评估→决策→迭代 | 研究 |\n| `/oms-ultrawork` | 3 层并行执行：按复杂度路由到 std/pro/max 模型 | 轻量并行 |\n| `/oms-goal` | 多目标工作流：Oracle 门控 + 角色分工执行 | 目标管理 |\n| `/oms-orchestra` | 运行自定义 YAML 工作流 | 自定义 |\n| `/oms-define` | 定义自定义 agent 或工作流（生成 YAML） | 定义工具 |\n\n## Prompt 模式与 Program 模式\n\n多数 OMS 工作流支持两种执行模式：\n\n### Program 模式（默认）\n\nWorkflowEngine 直接执行 DAG——创建 Orchestrator，加载 22 种内置 agent 角色，按拓扑序调度各阶段，管理 worker 并发。无需 LLM 参与调度，速度快、确定性强。\n\n```\n> /oms-autopilot 实现用户登录功能\n```\n\nProgram 模式失败时会自动降级到 Prompt 模式重试。\n\n### Prompt 模式（`--prompt`）\n\nLLM 作为编排层，通过 Agent 工具逐阶段派生子 agent 执行。更灵活（可适应异常情况），但速度较慢。\n\n```\n> /oms-autopilot --prompt 实现用户登录功能\n```\n\n适用于需要 LLM 判断力的场景（如需求模糊、需动态调整执行路径）。\n\n### 仅 Prompt 模式的工作流\n\n以下工作流只支持 Prompt 模式：\n\n| 工作流 | 原因 |\n|--------|------|\n| `/oms-clarify` | 苏格拉底式访谈依赖 AskUserQuestion 多轮对话，Program 模式无法支持 |\n| `/oms-goal` | Oracle 门控 + 多目标状态管理需要 LLM 判断 |\n| `/oms`（路由器） | 纯分类分发，无 DAG 执行 |\n| `/oms-define` | 纯 YAML 生成，无 DAG 执行 |\n\n## 典型用法：组合使用 /oms-define 与 /oms-orchestra\n\n除了内置工作流，OMS 支持定义和运行**自定义工作流**。\n\n### 第一步：定义自定义 agent 或工作流\n\n`/oms-define` 根据自然语言描述生成 YAML 定义文件：\n\n```\n> /oms-define 我需要一个安全审计 agent，只读代码，用 max 模型\n```\n\nSaluzi 会在 `.orchestra/agents/` 下生成 YAML：\n\n```yaml\nname: security-auditor\nrole: reviewer\ndescription: \"Security-focused code review.\"\nmodel: max\ntools: [Read, Glob, Grep]\ndisallowed_tools: [Write, Edit, Bash]\n```\n\n定义自定义工作流：\n\n```\n> /oms-define 创建一个代码审查工作流，先探索、再审查、再验证\n```\n\n生成 `.orchestra/workflows/code-review.yaml`：\n\n```yaml\nname: code-review\ndescription: \"Multi-stage code review\"\nstages:\n  explore:\n    agent: explorer\n    workers: 3\n  review:\n    agent: reviewer\n    depends_on: [explore]\n  verify:\n    agent: verifier\n    depends_on: [review]\n    gate: true\n    on_failure: retry\n    max_retries: 2\n```\n\n### 第二步：运行自定义工作流\n\n```\n> /oms-orchestra code-review \"检查最近提交的认证模块改动\"\n```\n\n`/oms-orchestra` 加载 `.orchestra/workflows/` 下的 YAML 定义，构建 DAG 并按拓扑序执行各阶段。\n\n## 各工作流 DAG 详解\n\n每个内置工作流都是一个 DAG（有向无环图）。阶段之间通过 `depends_on` 声明依赖，引擎按拓扑序调度，无依赖的阶段可并行执行。\n\n### /oms-autopilot — 全自动 6 阶段流水线\n\n```\nexpansion → planning → execution → qa → ┬─ validation-functional ─┐\n                                        ├─ validation-security  ──┼→ cleanup\n                                        └─ validation-quality  ───┘\n```\n\n| 阶段 | Agent | 说明 |\n|------|-------|------|\n| expansion | Analyst | 将想法转为技术规格（需求、架构、风险） |\n| planning | Planner | 创建实现计划（任务分解、并行策略、测试方案） |\n| execution | Executor | 按计划并行实现（自动/标准/高复杂度三级路由） |\n| qa | Verifier [gate] | build + lint + test 循环，最多重试 5 次 |\n| validation-* | 3 个并行 reviewer [gate] | 功能验证、安全审查、代码质量审查 |\n| cleanup | Writer | 生成最终报告 |\n\n特点：如果已存在 ralplan 计划（`.oms/plans/ralplan-*.md`），自动跳过 expansion 和 planning，直接从 execution 开始。\n\n### /oms-ralplan — 共识规划\n\n```\nplan → architect_review → critic_review → revision\n                          ↑                      ↓ (ITERATE)\n                          └── 重新执行整个 DAG ──┘ (最多 5 轮)\n```\n\n| 阶段 | Agent | 说明 |\n|------|-------|------|\n| plan | Planner | RALPLAN-DR 结构化审议（原则→驱动因素→选项→推荐） |\n| architect_review | Architect | 反方论证、权衡分析、风险评级 |\n| critic_review | Critic [gate] | 9 维度评分，输出 APPROVE / ITERATE / REJECT |\n| revision | Planner | 逐条回应 Critic 问题，更新计划 |\n\n特点：Critic 输出 ITERATE 时，引擎重新执行整个 DAG（最多 5 轮）。APPROVE 后提示选择执行路径（team 或 ralph）。支持 `--interactive` 模式在关键节点暂停确认。\n\n### /oms-ralph — PRD 驱动的持久循环\n\n```\nanalyze → implement [loop ≤50] → verify [gate] → review [gate, retry ≤10] → deslop → regression_verify [gate, retry ≤3] → debug_fix [retry ≤3]\n```\n\n| 阶段 | Agent | 说明 |\n|------|-------|------|\n| analyze | Analyst | 生成 PRD（用户故事 + 验收标准） |\n| implement | Executor | 逐个实现用户故事，循环直到所有故事通过 |\n| verify | Verifier [gate] | 全量重新验证所有故事 |\n| review | CodeSimplifier [gate] | 代码审查，最多重试 10 次 |\n| deslop | CodeSimplifier | 去除不必要的复杂度 |\n| regression_verify | Verifier [gate] | deslop 后回归测试 |\n| debug_fix | Debugger | 诊断修复剩余问题 |\n\n### /oms-team — N 并行 worker\n\n```\nplan → prd → exec (N workers) → verify [gate] → fix [retry ≤3]\n                                     ↑              ↓\n                                     └──────────────┘ (loop until PASS)\n```\n\n| 阶段 | Agent | 说明 |\n|------|-------|------|\n| plan | Planner | 将任务分解为 N 个独立子任务 |\n| prd | Analyst | 为每个子任务定义验收标准（任务 >5 个子任务时） |\n| exec | Executor | N 个 worker 并行实现（N>20 自动启用 Ant-Colony 模式） |\n| verify | Verifier [gate] | 验证所有子任务 + 集成检查 |\n| fix | Debugger | 诊断修复失败项，最多 3 轮 |\n\n### /oms-clarify — 苏格拉底式深度访谈（交互式）\n\n```\nexplore → interview [loop ≤20] → ┬─ challenge-contrarian (模糊度>0.4) ─┐\n                                  ├─ challenge-simplifier (模糊度>0.3) ─┼→ crystallize → bridge\n                                  └─ challenge-ontologist (模糊度>0.5) ─┘\n```\n\n| 阶段 | Agent | 说明 |\n|------|-------|------|\n| explore | Explorer | 检测项目类型（brownfield/greenfield），映射代码区域 |\n| interview | Analyst | 逐轮提问，每轮计算模糊度评分（目标/约束/标准/上下文） |\n| challenge-* | 3 个条件 agent | 反方论证、简化探测、本体论重构（按模糊度阈值激活） |\n| crystallize | Writer | 综合所有分析，生成规格文档 |\n| bridge | Planner | 推荐执行模式并跳转 |\n\n特点：模糊度降至 ≤20% 自动进入下一阶段。支持 `--quick`（阈值 30%，5 轮）和 `--deep`（阈值 10%，30 轮）。\n\n### /oms-autoresearch — 评估器驱动的迭代改进\n\n```\nconfirm-mission → initialize-run → experiment → evaluate [gate] → decide → iterate [loop ≤50] → finalize\n                                                                          ↑          ↓ (CONTINUE/PIVOT)\n                                                                          └──────────┘\n```\n\n特点：通过外部评估器（如测试套件、benchmark）量化每轮改进，决策引擎输出 CONTINUE / PIVOT / COMPLETE / ABORT。\n\n### /oms-ultrawork — 3 层并行执行\n\n```\nground → classify → ┬─ execute-simple   (LOW, std 模型) ─┐\n                    ├─ execute-standard  (MED, pro 模型) ─┼→ verify [gate] → report\n                    └─ execute-complex   (HIGH, max 模型) ─┘\n```\n\n特点：按复杂度将子任务路由到不同模型层级，独立任务并行执行。\n\n### /oms-goal — 多目标工作流\n\nOracle 门控 + 结构化 intake + 角色分工执行（Scout/Worker/Judge），通过文件系统持久化状态（`.oms/ultragoal/`），支持中断恢复。\n\n## 3 阶段流水线：ralplan → autopilot\n\n工作流之间可以串联。典型的全链路开发流程：\n\n```\n1. /oms-ralplan \"实现用户认证模块\"     → 生成共识计划\n2. Critic APPROVE 后选择执行路径       → team 或 ralph\n3. 执行完毕 → 验证通过 → 完成\n```\n\n`/oms-autopilot` 检测到已有的 ralplan 计划时，自动跳过 expansion + planning，直接从 execution 阶段开始。\n\n## 与普通对话的区别\n\n| 普通对话 | OMS 工作流 |\n|---------|-----------|\n| 单轮 request-response | 多阶段 DAG 调度 |\n| AI 自主决策 | 角色化分工 + 质量门禁 |\n| 适合小任务 | 适合复杂任务（5+ 文件） |\n| 上下文单一 | 多 agent 并行上下文 |\n\n## 何时用 OMS\n\n- 任务涉及 5+ 文件改动\n- 需要架构设计 + 实现 + 测试多阶段\n- 需要多个专业角色（如安全审查 + 性能优化）\n- 需求不明确，需要深度澄清（clarify）\n- 需要多 worker 并行执行（team）\n- 希望自动化长链任务\n"
+    },
     "docs/guide/codegraph": {
       "frontmatter": {
         "title": "CodeGraph - 本地代码智能与调用链分析",
@@ -3012,49 +3048,6 @@
       },
       "content": "\n## 什么是 CodeGraph\n\nCodeGraph 是 Saluzi 的本地优先（local-first）代码智能系统。它将整个代码库解析为 SQLite 知识图谱（每个符号、边、文件都有记录），提供亚毫秒级的结构化查询。\n\n## 7 个工具\n\n| 工具 | 用途 |\n|------|------|\n| `codegraph_explore` | 自然语言查询，返回相关符号源码 + 调用路径 + 影响范围 |\n| `codegraph_search` | 关键词搜索符号 |\n| `codegraph_node` | 查询单个符号的详细信息 |\n| `codegraph_callers` | 查找谁调用了某个符号 |\n| `codegraph_callees` | 查找某个符号调用了谁 |\n| `codegraph_impact` | 分析修改某符号的影响范围 |\n| `codegraph_files` | 按文件查询符号 |\n\n## 启用 CodeGraph\n\nCodeGraph **不会自动生成索引**。首次使用需要在 `/codegraph` 卡片中手动初始化：\n\n```\n> /codegraph          # 打开管理面板\n```\n\n面板包含三个区域：\n\n1. **索引状态**：显示索引统计数据，或提供初始化按钮。点击后**异步**构建索引（不阻塞当前会话），大项目可能需要 1-2 分钟\n2. **模式切换**：explore / half / full / off（详见下文）\n3. **可用工具列表**：根据当前模式显示已启用的工具\n\n索引构建完成后，后续通过文件监听自动保持同步（写入后约 1 秒）。\n\n## 4 种可见模式\n\nCodeGraph 有 4 种工具可见模式，控制 AI 能使用哪些 CodeGraph 工具：\n\n| 模式 | 可见工具数 | 工具列表 | 适用场景 |\n|------|-----------|---------|---------|\n| **explore**（默认） | 1 | `codegraph_explore` | 日常使用，一个工具覆盖大多数场景 |\n| **half** | 4 | explore + node + search + callers | 需要更精确的符号级查询 |\n| **full** | 7 | 全部 7 个工具 | 深度代码分析、重构评估 |\n| **off** | 0 | 全部禁用 | 不需要 CodeGraph 时节省 token |\n\n**默认行为**：如果项目已有 CodeGraph 索引（`.codegraph/` 目录），默认使用 `explore` 模式；如果没有索引，默认为 `off`。\n\n模式存储在 `.saluzi-edu/settings.json` 中，按项目独立配置。\n\n## 典型场景\n\n### 理解陌生代码\n\n```\n> 这个函数是怎么启动 HTTP 服务器的\n```\n\nSaluzi 调用 `codegraph_explore`，返回相关函数的源码、调用路径与依赖它的文件。\n\n### 评估改动影响\n\n```\n> 改这个函数会影响哪些地方\n```\n\nSaluzi 调用 `codegraph_impact`，返回所有调用该函数的位置，帮助评估重构风险。\n\n### 追踪调用链\n\n```\n> 从入口到这个工具的完整调用路径\n```\n\nSaluzi 通过 `codegraph_explore` 的 flow 查询追踪完整路径，包括动态分派（回调、JSX children）。\n\n## 与 grep 的区别\n\n| grep | CodeGraph |\n|------|-----------|\n| 字符串匹配 | AST 解析 |\n| 无调用关系 | 完整调用图 |\n| 跨文件需手动追踪 | 自动追踪 |\n| 无影响分析 | 提供影响范围 |\n| 快但浅 | 稍慢但深 |\n\n## 性能与限制\n\n- 索引大小：约为代码库的 2-3 倍（SQLite 压缩）\n- 索引滞后：文件写入后约 1 秒同步\n- 跨文件解析：基于名称匹配，模糊调用可能返回多候选\n- 不验证正确性：仍需编译器/测试套件确认\n"
     },
-    "docs/guide/cost-usage": {
-      "frontmatter": {
-        "title": "查看消耗 - 会话花费与历史统计",
-        "description": "使用 /cost、/stats 查看当前会话花费与历史统计。",
-        "keywords": [
-          "cost",
-          "stats",
-          "消耗",
-          "统计"
-        ]
-      },
-      "content": "\n## 当前会话花费\n\n`/cost` 显示本次会话的 token 消耗与费用明细。适合在长对话中随时检查开销：\n\n```\n> /cost\n```\n\n输出包含输入 token、输出 token 以及折算后的费用。会话结束后计数清零，下次对话重新累计。\n\n## 历史统计\n\n`/stats` 展示跨会话的累计数据，包括总对话次数、总 token 消耗等：\n\n```\n> /stats\n```\n\n与 `/cost` 的区别在于：`/cost` 只看当前会话，`/stats` 汇总所有历史记录。\n\n## 命令速查\n\n| 命令 | 作用范围 | 用途 |\n|------|---------|------|\n| `/cost` | 当前会话 | 本次对话的 token 与费用 |\n| `/stats` | 全部历史 | 累计消耗与会话统计 |\n\n## 下一步\n\n- [故障排查](./troubleshooting) — 常见问题与解决方案\n- [代码图谱](./codegraph) — 用 CodeGraph 探索项目结构\n- [模型选择与切换](./model-selection) — 调整模型以控制成本\n"
-    },
-    "docs/guide/getting-started": {
-      "frontmatter": {
-        "title": "新手入门 - 安装、登录与首次对话",
-        "description": "从零开始使用 Saluzi：安装 CLI、登录账户、添加项目目录、第一次提问与代码提交工作流。",
-        "keywords": [
-          "新手入门",
-          "安装",
-          "登录",
-          "首次对话",
-          "commit"
-        ]
-      },
-      "content": "\n## 安装 Saluzi CLI\n\nSaluzi 是终端原生的 agentic coding system，通过 npm 全局安装：\n\n```bash\nnpm install -g @saluzi/saluzi-edu\n```\n\n安装后验证：\n\n```bash\nslz --version\n```\n\n## 首次登录\n\n启动 CLI 后输入 `/login` 命令：\n\n```\nslz\n> /login\n```\n\n弹出 `Login` 对话框，首先提示 `Select login method:`，共 6 个 Provider 选项。按 `↑/↓` 选择，`Enter` 确认：\n\n| # | 选项 | 副标题 | 适用场景 |\n|---|------|--------|---------|\n| 1 | Anthropic Compatible | Configure your own API endpoint | 自建/代理的 Anthropic 格式端点（如反代、中转） |\n| 2 | OpenAI Compatible | Ollama, DeepSeek, vLLM, One API, etc. | OpenAI Chat Completions 格式的本地或第三方模型 |\n| 3 | Gemini API | Google Gemini native REST/SSE | Google 原生 Gemini 接口 |\n| 4 | Saluzi account with subscription | Pro, Max, Team, or Enterprise | 订阅账户（个人/团队最常用） |\n| 5 | Anthropic Console account | API usage billing | Anthropic Console 按 API 用量计费 |\n| 6 | 3rd-party platform | Amazon Bedrock, Microsoft Foundry, or Vertex AI | 云厂商托管入口 |\n\n> 如果已设置 `ANTHROPIC_API_KEY` 环境变量，Saluzi 会自动检测并跳过登录，`/login` 此时显示为 \"Switch Saluzi accounts\"。\n\n### 选项 1-3：API 表单登录\n\n选择前三个选项（Anthropic / OpenAI / Gemini Compatible）后进入对应的字段表单。三者字段完全一致，只是写入的环境变量不同：\n\n| 字段 | 标签 | 说明 | 是否必填 |\n|------|------|------|---------|\n| baseUrl | Base URL | API 端点地址，需含协议（如 `https://api.example.com`） | 否（留空走默认） |\n| apiKey | API Key | 密钥，输入时掩码显示 | 否 |\n| stdModel | Std | standard 模型名（如 `claude-sonnet-4-5`） | 否 |\n| proModel | Pro | pro 模型名 | 否 |\n| maxModel | Max | max 模型名 | 否 |\n| maxOutputTokens | Out Tok | 单次响应最大 token 数 | 否 |\n| autoCompactWindow | AC Win | 自动压缩上下文的窗口大小 | 否 |\n| autoCompactPctOverride | AC Pct% | 自动压缩触发阈值百分比 | 否 |\n\n操作方式：`↑/↓` 或 `Tab` 切换字段，`Enter` 在最后一个字段提交保存，`Esc` 返回选项菜单。保存后表单中的值会写入 `~/.saluzi/settings.json` 的 `env` 段（对应 `ANTHROPIC_BASE_URL`/`OPENAI_BASE_URL`/`GEMINI_BASE_URL` 等环境变量），下次启动自动加载。\n\n### 选项 4-5：OAuth 浏览器登录\n\n选择 Saluzi 账户或 Anthropic Console 后进入 OAuth 流程：\n\n1. 终端显示 `Opening browser to sign in…`（带加载图标），自动打开浏览器\n2. 在浏览器完成账户登录与授权\n3. 浏览器返回一串授权码，复制后回到终端\n4. 终端提示 `Paste code here if prompted >`（掩码输入），粘贴授权码并 `Enter`\n5. 终端显示 `Creating API key for Saluzi…`，完成后提示 `Login successful. Press Enter to continue…`\n\n如果浏览器没有自动打开，终端会展示 URL 和复制提示，按 `c` 可复制 URL 手动打开。\n\n### 选项 6：第三方平台\n\n选择 3rd-party platform 后只显示提示信息：Saluzi 支持 Amazon Bedrock、Microsoft Foundry、Vertex AI，需要先设置对应的环境变量再重启 Saluzi。按 `Enter` 返回选项菜单，不在 CLI 内直接配置。企业用户需联系管理员获取配置参数。\n\n### 登录后\n\n登录成功后 Saluzi 会自动刷新策略配额、GrowthBook 特性开关、远程受管设置，并为本机注册 trusted device（用于 Remote Control）。无需额外操作，直接开始对话即可。\n\n## 添加项目目录\n\n进入项目后用 `/add-dir` 挂载工作目录：\n\n```\n> /add-dir\n```\n\nSaluzi 会扫描目录结构，后续对话即可基于代码上下文回答。\n\n## 第一次对话\n\n直接输入需求：\n\n```\n> 帮我看看这个项目的目录结构，有没有潜在问题\n```\n\nSaluzi 会：\n1. 调用 `Read`、`Glob`、`Grep` 工具探索代码\n2. 分析后给出建议\n3. 若需修改，会请求权限后调用 `Edit`、`Write` 工具\n\n每次工具调用前会弹出权限确认（除非已 Allow）。\n\n## 提交代码工作流\n\n完成修改后：\n\n```\n> /diff          # 预览改动\n> /commit        # 提交（自动生成 commit message）\n> /commit-push-pr # 一条龙：提交 + 推送 + 创建 PR\n```\n\n## 下一步\n\n- [模型选择与切换](./model-selection) — 了解 `/model`、`/effort`、`/mom`\n- [对话基础](./conversation-basics) — 多轮对话与流式输出\n- [上下文管理](./context-tips) — 让 AI 更好理解你的项目\n- [主目录与配置](./saluzi-home) — 配置文件位置与字段说明\n"
-    },
-    "docs/guide/model-selection": {
-      "frontmatter": {
-        "title": "模型选择与切换 - Max/Pro/Std 与推理深度",
-        "description": "使用 /model 切换模型，/effort 调节推理深度，/mom 配置混合模型。",
-        "keywords": [
-          "model",
-          "effort",
-          "Max",
-          "Pro",
-          "Std",
-          "模型切换",
-          "推理深度"
-        ]
-      },
-      "content": "\n## 模型选择\n\nSaluzi 支持多个模型，按能力与成本分级：\n\n| 模型 | 能力 | 速度 | 成本 | 适用场景 |\n|------|------|------|------|---------|\n| Max | 最强 | 慢 | 高 | 复杂架构、深度推理 |\n| Pro | 均衡 | 中 | 中 | 日常开发（默认） |\n| Std | 快 | 快 | 低 | 简单任务、快速验证 |\n\n## /model 切换\n\n```\n> /model\n```\n\n打开模型选择面板，可切换当前会话的模型。也可直接指定：\n\n```\n> /model max\n> /model pro\n> /model std\n```\n\n支持模型别名：`best`、`max[1m]`（1M 上下文）、`pro[1m]`、`maxplan` 等。\n\n## /effort 推理深度\n\n`/effort` 调节推理链长度（仅支持推理模型的 extended thinking）：\n\n```\n> /effort low     # 快速响应\n> /effort medium  # 中等（默认）\n> /effort high    # 深度推理\n> /effort xhigh   # 极深度推理\n> /effort max     # 最大推理深度\n> /effort auto    # 清除手动设置，使用自动\n```\n\n也可通过环境变量设置：`SALUZI_EFFORT_LEVEL=high slz`\n\n深度推理适合：\n\n- 复杂 bug 分析\n- 架构设计\n- 多步骤规划\n- 代码审查\n\n## /mom 混合模型\n\n见 [MOM 混合模型章节](./mom-mixed-models)。MOM 允许多模型协同：主机 + 顾问。\n\n- `/mom` 打开配置面板\n- `/mom \"内容\"` 执行一次性 MOM 回合\n- `/mom-<mode> \"内容\"` 使用特定 MOM 模式（如 `/mom-avg`）\n\n## /poor 节约模式\n\n```\n> /poor\n```\n\n切换节约模式，关闭**记忆提取**（extract_memories）和**提示建议**（prompt_suggestion），减少 token 消耗。\n\n## Provider 选择\n\nSaluzi 自动选择最优 Provider。如需指定：\n- 通过环境变量（如 `ANTHROPIC_API_KEY`）指定\n- 通过 `/keys` 绑定特定 provider 的 Key\n- 通过 `/model` 切换当前会话模型\n\n## 推荐配置\n\n| 场景 | 推荐 |\n|------|------|\n| 日常开发 | Pro + medium effort |\n| 复杂重构 | Max + high effort |\n| 快速原型 | Std + low effort |\n| 关键决策 | MOM（Pro 主机 + Max 顾问） |\n| 节约模式 | `/poor`（关闭记忆提取与提示建议） |\n\n## 成本监控\n\n用 `/cost` 查看当前会话消耗，`/stats` 查看历史统计。\n\n## 下一步\n\n- [MOM 混合模型](./mom-mixed-models) — 多模型协同：主机 + 顾问\n- [查看消耗](./cost-usage) — `/cost` 与 `/stats` 详解\n- [对话基础](./conversation-basics) — 多轮对话与流式输出\n- [API Key 绑定](./keys-binding) — `/keys` 多 Key 调度\n"
-    },
     "docs/guide/mom-mixed-models": {
       "frontmatter": {
         "title": "MOM 混合模型 - 多模型协同决策与成本优化",
@@ -3071,7 +3064,7 @@
           "成本优化"
         ]
       },
-      "content": "\n## 为什么需要 MOM\n\n单模型对话有几类常见痛点，MOM 正是为解决它们而生：\n\n| 痛点 | 单模型表现 | MOM 解决方式 |\n|------|-----------|-------------|\n| 重要决策缺第二意见 | 一个模型说了算，错了也只能事后发现 | 多顾问并行给方案，主机综合后行动 |\n| 简单任务烧钱 | 用 Max 处理「重命名变量」大材小用 | 弱模型先试，简单任务不消耗强模型 token |\n| 复杂任务欠深度 | Std/Pro 推理深度不够，硬上又怕漏 | 强模型带完整工具循环兜底 |\n| 单一模型有盲区 | 不同模型擅长不同领域，只能赌一个 | 多 provider 顾问互补（如 Claude + Gemini + Grok） |\n| 关键改动无人审查 | 自己写自己改，bug 容易溜过去 | 顾问作为「审查者」给出反对意见 |\n\n一句话：**MOM 不是为了「更强」，而是为了「更稳 + 更省」**。它让简单任务便宜跑、关键决策有交叉验证、不同 provider 的模型互补盲区。\n\n## MOM 的两种内置模式\n\nMOM 是一个统称，下面注册了多个具名模式。每个模式 ID 同时也是虚拟模型名（可以直接 `/model mom-avg` 切换）和一次性命令名（`/mom-avg \"...\"`）。\n\n### mom-avg：并行顾问 + 主机综合\n\n工作流：\n\n```\n用户输入\n   │\n   ├──► 顾问 1（只读，text-only）──┐\n   ├──► 顾问 2（只读，text-only）──┤\n   ├──► 顾问 N（只读，text-only）──┤\n   │                              │\n   ▼                              ▼\n  主机模型 ◄──综合所有顾问建议──┘\n   │\n   ▼\n最终输出（带工具调用、文件编辑等完整能力）\n```\n\n关键点：\n\n- **顾问只读**：顾问不携带工具，只看对话历史给出建议文本，不能改文件、不能跑命令。这意味着顾问调用很快、很便宜（一次 text completion）。\n- **主机有完整能力**：主机收到所有顾问的建议后，作为「主持人」综合并执行——它可以读文件、改代码、跑测试，和普通对话完全一样。\n- **fanout 控制频率**：顾问不需要每轮都跑。默认 `user_turn`（每个用户消息跑一次，后续工具迭代复用同一份建议），也可设 `per_iteration`（每轮都跑，成本高）或 `every_n:N`（每 N 轮跑一次）。\n\n适合：**关键决策**——架构设计、安全审查、复杂 bug 方案选型。需要多角度意见时。\n\n### mom-stair：阶梯式弱→强升级\n\n工作流：\n\n```\n用户输入\n   │\n   ▼\n弱模型（带只读工具：Read/Grep/Glob）\n   │ 自评置信度 0-1\n   ├── 置信度 ≥ 阈值（默认 0.7）──► 直接交付答案，跳过强模型\n   │\n   └── 置信度 < 阈值 ──► 升级到下一阶段\n                          │\n                          ▼\n                      强模型（完整工具循环）\n                      接收弱模型的发现作为引导\n                          │\n                          ▼\n                      最终输出\n```\n\n关键点：\n\n- **弱模型先试**：用 Std 或轻量模型尝试回答，可用只读工具（读文件、搜索代码）做基础调研。\n- **自评置信度**：弱模型给出答案时附带一个 0~1 的自评分。高于阈值就直接交付，**不调用强模型**——简单任务省一大笔 token。\n- **升级时传递发现**：弱模型调研得到的关键发现（key findings）和草稿答案会作为引导传给强模型，避免强模型从零开始重新探索。\n\n适合：**日常开发**——大部分任务用弱模型就能搞定，遇到真复杂的才升级到强模型。成本优化首选。\n\n## 三种使用方式\n\n### 1. 一次性 MOM 回合\n\n```bash\n# 用默认 MOM 模式跑一次，结束后自动恢复原模型\n> /mom 帮我设计一个端口冲突处理策略\n\n# 指定具体模式\n> /mom-avg 这段并发代码有什么竞态风险？\n> /mom-stair 重构这个 800 行的函数\n```\n\n特点：**不修改全局配置**，仅本次消息走 MOM 流程，下一条消息自动回到之前的模型。适合偶尔在关键节点用一下。\n\n### 2. 切换会话到 MOM 模式\n\n```bash\n> /model mom-avg\n```\n\n把当前会话的模型切到 `mom-avg`，后续所有消息都走 MOM 流程，直到再次 `/model` 切回。和切普通模型完全一样——MOM 模式 ID 在 `/model` 选择器里就能看到。\n\n### 3. 设为默认模式\n\n在 `/mom` 配置卡里把某个模式（如 `mom-stair`）设为 default，所有新会话默认走该模式。适合希望日常开发都享受成本优化的用户。\n\n## 配置 MOM\n\n```bash\n> /mom\n```\n\n打开 MOM 配置卡。这是一个多页 Ink 卡片：\n\n- **首页**：总开关、隐私过滤模式、模式列表（mom-avg / mom-stair）、模型池、默认模式\n- **每个模式一页**：顾问槽位、主机槽位、参数（fanout、超时、温度等）\n\n操作键：`Tab` 切页、`j/k` 上下导航、`←/→` 切区域、`Enter` 确认、`s` 保存、`Esc` 关闭。每个模式下都有底部快捷键提示，只显示当前可用的操作。\n\n### 模型池（modelPool）\n\n模型池是 MOM 可用的所有模型清单。每个条目有三种来源：\n\n| 类型 | 说明 | 适合场景 |\n|------|------|---------|\n| `preset` | 预设别名：`max`、`pro`、`std`、`subagent` | 最简，开箱即用 |\n| `key` | 引用 `/keys` 里绑定的 API Key（可指定该 Key 下的具体 modelName） | 多 provider 混搭，如一个 Claude Key + 一个 Gemini Key |\n| `custom` | 自定义 provider + baseUrl + apiKey + model | 接入自部署模型、第三方兼容端点 |\n\n顾问和主机都从池里引用。配一个 `preset:std` 和一个 `key:my-gemini-key` 进池，就能让 mom-avg 的两个顾问分别是 Saluzi Std 和 Gemini。\n\n### 关键参数\n\n| 参数 | 作用 | 推荐值 |\n|------|------|--------|\n| `fanout` | 顾问调用频率：`user_turn` / `per_iteration` / `every_n:N` | `user_turn`（默认，省钱）；只有真正需要每轮都参考意见时才用 `per_iteration` |\n| `privacyFilter` | 顾问输出脱敏：`off` / `display`（仅显示脱敏）/ `full`（连主机也看不到原话） | `off`（默认）；处理敏感代码时用 `display` 或 `full` |\n| `degradedReferencePolicy` | 顾问失败时：`loud`（报错）/ `silent`（静默忽略） | `loud`（默认，能发现问题）；成本敏感且可容忍漏掉顾问时用 `silent` |\n| `referenceMaxTokens` | 单个顾问最大输出 token | 2000~4000，避免顾问长篇大论 |\n| `referenceTimeout` | 顾问调用超时（秒） | 30~60，慢 provider 别拖死整个回合 |\n| `temperature` | 顾问采样温度 | 0.3~0.5（建议更有条理）；想多角度发散可调高 |\n| `hostTemperature` | 主机采样温度 | 默认即可，主机需要稳定执行 |\n| `confidenceThreshold` | 仅 mom-stair：弱模型自评分低于此值则升级 | 0.7（默认）；任务对准确度要求高可调到 0.8，省钱可调到 0.5 |\n\n## 推荐配置场景\n\n### 场景 1：日常开发（成本优先）\n\n```yaml\n默认模式: mom-stair\n弱模型: preset:std\n强模型: preset:pro\n置信度阈值: 0.6  # 稍低，更多任务用弱模型搞定\n```\n\n效果：80% 的简单任务由 Std 处理（便宜），剩下 20% 升级到 Pro。整体成本比纯 Pro 低 40~60%。\n\n### 场景 2：架构设计（质量优先）\n\n```yaml\n一次性调用: /mom-avg 帮我设计这个微服务拆分方案\n主机: preset:pro\n顾问 1: preset:max  # 深度推理\n顾问 2: key:my-gemini-key  # 不同视角\nfanout: user_turn\nreferenceMaxTokens: 4000\n```\n\n效果：Max 给出深思熟虑的方案，Gemini 提供不同训练集带来的视角差异，Pro 综合后执行。一次性使用，不污染日常对话。\n\n### 场景 3：安全审查（严格交叉验证）\n\n```yaml\n一次性调用: /mom-avg 审查这段处理用户输入的代码\n主机: preset:max\n顾问 1: preset:pro\n顾问 2: preset:pro  # 两个 Pro 独立审查\nprivacyFilter: display  # 显示时脱敏，避免敏感数据被多个 provider 看到\ndegradedReferencePolicy: loud  # 任何一个顾问失败都要提示\n```\n\n效果：多个模型独立审查同一份代码，主机汇总所有发现。任何模型漏掉的漏洞都有可能被另一个发现。\n\n### 场景 4：复杂 bug（深度+广度）\n\n```yaml\n会话切换: /model mom-stair\n弱模型: preset:std  # 先快速定位\n强模型: preset:max  # 升级时用 Max 深度推理\n置信度阈值: 0.8  # 严格，避免弱模型误判\n```\n\n效果：Std 先用只读工具快速探索代码、给出初步判断。如果是简单 bug（如拼写错误），Std 直接修复；如果是涉及多模块的复杂 bug，升级到 Max 带完整工具循环深挖。\n\n## 成本控制要点\n\nMOM 用得不好可能比单模型还贵。几个原则：\n\n- **简单任务不要用 mom-avg**：mom-avg 至少调用 N+1 次模型（N 个顾问 + 1 个主机）。改个变量名用 mom-avg 是浪费。\n- **日常用 mom-stair 而非 mom-avg**：stair 只在弱模型搞不定时才升级，平均成本远低于 avg 的「每次都全员上场」。\n- **设 referenceMaxTokens**：顾问容易啰嗦，限制输出长度能直接省钱。\n- **fanout 用 user_turn**：除非真的需要每轮都参考意见，否则别用 `per_iteration`。\n- **关键决策用一次性 `/mom-avg`**：而不是把整个会话切到 mom-avg 模式。\n- **用 `/cost` 监控**：MOM 开启后会看到顾问调用的 token 消耗，发现异常及时调整。\n- **`/poor` 节约模式不影响 MOM**：`/poor` 只关记忆提取和提示建议，MOM 仍按配置运行。要省 MOM 的钱得调 `referenceMaxTokens` 和 `fanout`。\n\n## 与普通对话的对比\n\n| 维度 | 普通对话 | mom-stair | mom-avg |\n|------|---------|-----------|---------|\n| 模型调用次数 | 1 次 / 轮 | 1 次（简单）或 2+ 次（复杂） | N+1 次 / 用户回合 |\n| 简单任务成本 | 基准 | 低 30~50% | 高 2~5 倍 |\n| 复杂任务成本 | 基准 | 接近基准 | 高 2~5 倍 |\n| 决策质量 | 单模型 | 弱模型搞定时一般；升级后接近强模型 | 多角度交叉验证 |\n| 响应速度 | 最快 | 简单任务快；复杂任务稍慢 | 最慢（要等所有顾问） |\n| 适合场景 | 日常常规 | 日常开发 + 偶尔复杂 | 关键决策、安全审查 |\n\n## 常见误区\n\n**误区 1：MOM 一定比单模型好**\n不是。MOM 的并行调用本身有成本，简单任务用单模型更快更便宜。MOM 的价值在「关键决策有第二意见」和「简单任务不烧强模型」。\n\n**误区 2：顾问越多越好**\n顾问越多 token 越贵，且主机综合成本也上升。2~3 个互补顾问（如不同 provider、不同规模）通常比 5 个同质顾问效果好。\n\n**误区 3：把整个会话切到 mom-avg 就高枕无忧**\n会让每条消息都跑多顾问，成本爆炸。mom-avg 更适合用 `/mom-avg \"...\"` 一次性调用。\n\n**误区 4：mom-stair 的弱模型能解决一切**\n弱模型只有只读工具，不能改文件。它判定「我能搞定」时只是给出答案文本，真正的执行还得主机接力。所以 stair 的省钱逻辑是「简单咨询类问题」，不是「简单执行类问题」。\n\n**误区 5：自定义 provider 任何模型都能接**\ncustom entry 需要映射到 openai/anthropic/gemini/grok 之一的 SDK。Bedrock/Vertex 等需要专属 SDK 的 provider 暂时不能作为 MOM 主机（可作为顾问，但仍受相同限制）。\n\n## 下一步\n\n- [模型选择与切换](./model-selection) — `/model`、`/effort` 与 MOM 的关系\n- [查看消耗](./cost-usage) — `/cost` 监控 MOM 的顾问开销\n- [API Key 绑定](./keys-binding) — `/keys` 多 Key 调度，给 MOM 配多 provider 顾问\n- [对话基础](./conversation-basics) — 多轮对话与流式输出\n"
+      "content": "\n## 为什么需要 MOM\n\n单模型对话有几类常见痛点，MOM 正是为解决它们而生：\n\n| 痛点 | 单模型表现 | MOM 解决方式 |\n|------|-----------|-------------|\n| 重要决策缺第二意见 | 一个模型说了算，错了也只能事后发现 | 多顾问并行给方案，主机综合后行动 |\n| 简单任务烧钱 | 用 Max 处理「重命名变量」大材小用 | 弱模型先试，简单任务不消耗强模型 token |\n| 复杂任务欠深度 | Std/Pro 推理深度不够，硬上又怕漏 | 强模型带完整工具循环兜底 |\n| 单一模型有盲区 | 不同模型擅长不同领域，只能赌一个 | 多 provider 顾问互补（如 Claude + Gemini + Grok） |\n| 关键改动无人审查 | 自己写自己改，bug 容易溜过去 | 顾问作为「审查者」给出反对意见 |\n\n一句话：**MOM 不是为了「更强」，而是为了「更稳 + 更省」**。它让简单任务便宜跑、关键决策有交叉验证、不同 provider 的模型互补盲区。\n\n## MOM 的两种内置模式\n\nMOM 是一个统称，下面注册了多个具名模式。每个模式 ID 同时也是虚拟模型名（可以直接 `/model mom-avg` 切换）和一次性命令名（`/mom-avg \"...\"`）。\n\n### mom-avg：并行顾问 + 主机综合\n\n工作流：\n\n```\n用户输入\n   │\n   ├──► 顾问 1（只读，text-only）──┐\n   ├──► 顾问 2（只读，text-only）──┤\n   ├──► 顾问 N（只读，text-only）──┤\n   │                              │\n   ▼                              ▼\n  主机模型 ◄──综合所有顾问建议──┘\n   │\n   ▼\n最终输出（带工具调用、文件编辑等完整能力）\n```\n\n关键点：\n\n- **顾问只读**：顾问不携带工具，只看对话历史给出建议文本，不能改文件、不能跑命令。这意味着顾问调用很快、很便宜（一次 text completion）。\n- **主机有完整能力**：主机收到所有顾问的建议后，作为「主持人」综合并执行——它可以读文件、改代码、跑测试，和普通对话完全一样。\n- **fanout 控制频率**：顾问不需要每轮都跑。默认 `user_turn`（每个用户消息跑一次，后续工具迭代复用同一份建议），也可设 `per_iteration`（每轮都跑，成本高）或 `every_n:N`（每 N 轮跑一次）。\n\n适合：**关键决策**——架构设计、安全审查、复杂 bug 方案选型。需要多角度意见时。\n\n### mom-stair：阶梯式弱→强升级\n\n工作流：\n\n```\n用户输入\n   │\n   ▼\n弱模型（带只读工具：Read/Grep/Glob）\n   │ 可选末尾输出 CONFIDENCE: 0-1\n   │\n   ├── 答案充实且接地 ──► 直接交付答案，跳过强模型\n   │    （置信度 ≥ 阈值时可额外确认，非必须）\n   │\n   └── 答案过短 / 用了工具但无接地发现\n       │ 或显式低置信度\n       ──► 升级到下一阶段\n              │\n              ▼\n          强模型（完整工具循环）\n          接收弱模型的草稿 + 发现作为引导\n          但**不接收**置信度/推理（自评不可靠）\n              │\n              ▼\n          最终输出\n```\n\n关键点：\n\n- **弱模型先试**：用 Std 或轻量模型尝试回答，可用只读工具（读文件、搜索代码）做基础调研。\n- **简化协议**：弱模型可在答案末尾输出一行 `CONFIDENCE: 0.7`（0-1 数字，也支持 `high`/`medium`/`low` 等词），无需 JSON/XML 嵌套格式——格式遵从率大幅提升。\n- **置信度是软信号**：模型未输出置信度时**不视为失败**——升级决策基于客观信号（答案厚度、工具接地）。解析失败也不再标记为 failed，弱模型产出始终保留。\n- **多因素门控**：升级决策综合考量：置信度（如有）、答案是否过短、以及（当使用了工具时）是否有接地发现（file:line 引用）。这弥补了低等模型自评分方差的不足。\n- **自评不传递**：置信度/推理仅在内部用于门控，**不传递给强模型**。强模型只接收草稿答案 + 接地发现，避免被不可靠的自评分误导。\n- **不丢弃弱模型产出**：弱模型的原始文本始终作为草稿传递给强模型，避免重复劳动。\n\n适合：**日常开发**——大部分任务用弱模型就能搞定，遇到真复杂的才升级到强模型。成本优化首选。\n\n## 三种使用方式\n\n### 1. 一次性 MOM 回合\n\n```bash\n# 用默认 MOM 模式跑一次，结束后自动恢复原模型\n> /mom 帮我设计一个端口冲突处理策略\n\n# 指定具体模式\n> /mom-avg 这段并发代码有什么竞态风险？\n> /mom-stair 重构这个 800 行的函数\n```\n\n特点：**不修改全局配置**，仅本次消息走 MOM 流程，下一条消息自动回到之前的模型。适合偶尔在关键节点用一下。\n\n### 2. 切换会话到 MOM 模式\n\n```bash\n> /model mom-avg\n```\n\n把当前会话的模型切到 `mom-avg`，后续所有消息都走 MOM 流程，直到再次 `/model` 切回。和切普通模型完全一样——MOM 模式 ID 在 `/model` 选择器里就能看到。\n\n### 3. 设为默认模式\n\n在 `/mom` 配置卡里把某个模式（如 `mom-stair`）设为 default，所有新会话默认走该模式。适合希望日常开发都享受成本优化的用户。\n\n## 配置 MOM\n\n```bash\n> /mom\n```\n\n打开 MOM 配置卡。这是一个多页 Ink 卡片：\n\n- **首页**：总开关、隐私过滤模式、模式列表（mom-avg / mom-stair）、模型池、默认模式\n- **每个模式一页**：顾问槽位、主机槽位、参数（fanout、超时、温度等）\n\n操作键：`Tab` 切页、`j/k` 上下导航、`←/→` 切区域、`Enter` 确认、`s` 保存、`Esc` 关闭。每个模式下都有底部快捷键提示，只显示当前可用的操作。\n\n### 模型池（modelPool）\n\n模型池是 MOM 可用的所有模型清单。每个条目有三种来源：\n\n| 类型 | 说明 | 适合场景 |\n|------|------|---------|\n| `preset` | 预设别名：`max`、`pro`、`std`、`subagent` | 最简，开箱即用 |\n| `key` | 引用 `/keys` 里绑定的 API Key（可指定该 Key 下的具体 modelName） | 多 provider 混搭，如一个 Claude Key + 一个 Gemini Key |\n| `custom` | 自定义 provider + baseUrl + apiKey + model | 接入自部署模型、第三方兼容端点 |\n\n顾问和主机都从池里引用。配一个 `preset:std` 和一个 `key:my-gemini-key` 进池，就能让 mom-avg 的两个顾问分别是 Saluzi Std 和 Gemini。\n\n### 关键参数\n\n| 参数 | 作用 | 推荐值 |\n|------|------|--------|\n| `fanout` | 顾问调用频率：`user_turn` / `per_iteration` / `every_n:N` | `user_turn`（默认，省钱）；只有真正需要每轮都参考意见时才用 `per_iteration` |\n| `privacyFilter` | 顾问输出脱敏：`off` / `display`（仅显示脱敏）/ `full`（连主机也看不到原话） | `off`（默认）；处理敏感代码时用 `display` 或 `full` |\n| `degradedReferencePolicy` | 顾问失败时：`loud`（报错）/ `silent`（静默忽略） | `loud`（默认，能发现问题）；成本敏感且可容忍漏掉顾问时用 `silent` |\n| `referenceMaxTokens` | 单个顾问最大输出 token | 2000~4000，避免顾问长篇大论 |\n| `referenceTimeout` | 顾问调用超时（秒） | 30~60，慢 provider 别拖死整个回合 |\n| `temperature` | 顾问采样温度 | 0.3~0.5（建议更有条理）；想多角度发散可调高 |\n| `hostTemperature` | 主机采样温度 | 默认即可，主机需要稳定执行 |\n| `confidenceThreshold` | 仅 mom-stair：弱模型自评分低于此值则升级 | 0.7（默认）；任务对准确度要求高可调到 0.8，省钱可调到 0.5 |\n\n## 推荐配置场景\n\n### 场景 1：日常开发（成本优先）\n\n```yaml\n默认模式: mom-stair\n弱模型: preset:std\n强模型: preset:pro\n置信度阈值: 0.6  # 稍低，更多任务用弱模型搞定\n```\n\n效果：80% 的简单任务由 Std 处理（便宜），剩下 20% 升级到 Pro。整体成本比纯 Pro 低 40~60%。\n\n### 场景 2：架构设计（质量优先）\n\n```yaml\n一次性调用: /mom-avg 帮我设计这个微服务拆分方案\n主机: preset:pro\n顾问 1: preset:max  # 深度推理\n顾问 2: key:my-gemini-key  # 不同视角\nfanout: user_turn\nreferenceMaxTokens: 4000\n```\n\n效果：Max 给出深思熟虑的方案，Gemini 提供不同训练集带来的视角差异，Pro 综合后执行。一次性使用，不污染日常对话。\n\n### 场景 3：安全审查（严格交叉验证）\n\n```yaml\n一次性调用: /mom-avg 审查这段处理用户输入的代码\n主机: preset:max\n顾问 1: preset:pro\n顾问 2: preset:pro  # 两个 Pro 独立审查\nprivacyFilter: display  # 显示时脱敏，避免敏感数据被多个 provider 看到\ndegradedReferencePolicy: loud  # 任何一个顾问失败都要提示\n```\n\n效果：多个模型独立审查同一份代码，主机汇总所有发现。任何模型漏掉的漏洞都有可能被另一个发现。\n\n### 场景 4：复杂 bug（深度+广度）\n\n```yaml\n会话切换: /model mom-stair\n弱模型: preset:std  # 先快速定位\n强模型: preset:max  # 升级时用 Max 深度推理\n置信度阈值: 0.8  # 严格，避免弱模型误判\n```\n\n效果：Std 先用只读工具快速探索代码、给出初步判断。如果是简单 bug（如拼写错误），Std 直接修复；如果是涉及多模块的复杂 bug，升级到 Max 带完整工具循环深挖。\n\n## 成本控制要点\n\nMOM 用得不好可能比单模型还贵。几个原则：\n\n- **简单任务不要用 mom-avg**：mom-avg 至少调用 N+1 次模型（N 个顾问 + 1 个主机）。改个变量名用 mom-avg 是浪费。\n- **日常用 mom-stair 而非 mom-avg**：stair 只在弱模型搞不定时才升级，平均成本远低于 avg 的「每次都全员上场」。\n- **设 referenceMaxTokens**：顾问容易啰嗦，限制输出长度能直接省钱。\n- **fanout 用 user_turn**：除非真的需要每轮都参考意见，否则别用 `per_iteration`。\n- **关键决策用一次性 `/mom-avg`**：而不是把整个会话切到 mom-avg 模式。\n- **用 `/cost` 监控**：MOM 开启后会看到顾问调用的 token 消耗，发现异常及时调整。\n- **`/poor` 节约模式不影响 MOM**：`/poor` 只关记忆提取和提示建议，MOM 仍按配置运行。要省 MOM 的钱得调 `referenceMaxTokens` 和 `fanout`。\n\n## 与普通对话的对比\n\n| 维度 | 普通对话 | mom-stair | mom-avg |\n|------|---------|-----------|---------|\n| 模型调用次数 | 1 次 / 轮 | 1 次（简单）或 2+ 次（复杂） | N+1 次 / 用户回合 |\n| 简单任务成本 | 基准 | 低 30~50% | 高 2~5 倍 |\n| 复杂任务成本 | 基准 | 接近基准 | 高 2~5 倍 |\n| 决策质量 | 单模型 | 弱模型搞定时一般；升级后接近强模型 | 多角度交叉验证 |\n| 响应速度 | 最快 | 简单任务快；复杂任务稍慢 | 最慢（要等所有顾问） |\n| 适合场景 | 日常常规 | 日常开发 + 偶尔复杂 | 关键决策、安全审查 |\n\n## 常见误区\n\n**误区 1：MOM 一定比单模型好**\n不是。MOM 的并行调用本身有成本，简单任务用单模型更快更便宜。MOM 的价值在「关键决策有第二意见」和「简单任务不烧强模型」。\n\n**误区 2：顾问越多越好**\n顾问越多 token 越贵，且主机综合成本也上升。2~3 个互补顾问（如不同 provider、不同规模）通常比 5 个同质顾问效果好。\n\n**误区 3：把整个会话切到 mom-avg 就高枕无忧**\n会让每条消息都跑多顾问，成本爆炸。mom-avg 更适合用 `/mom-avg \"...\"` 一次性调用。\n\n**误区 4：mom-stair 的弱模型能解决一切**\n弱模型只有只读工具，不能改文件。它判定「我能搞定」时只是给出答案文本，真正的执行还得主机接力。所以 stair 的省钱逻辑是「简单咨询类问题」，不是「简单执行类问题」。\n\n**误区 5：自定义 provider 任何模型都能接**\ncustom entry 需要映射到 openai/anthropic/gemini/grok 之一的 SDK。Bedrock/Vertex 等需要专属 SDK 的 provider 暂时不能作为 MOM 主机（可作为顾问，但仍受相同限制）。\n\n## 下一步\n\n- [模型选择与切换](./model-selection) — `/model`、`/effort` 与 MOM 的关系\n- [查看消耗](./cost-usage) — `/cost` 监控 MOM 的顾问开销\n- [API Key 绑定](./keys-binding) — `/keys` 多 Key 调度，给 MOM 配多 provider 顾问\n- [对话基础](./conversation-basics) — 多轮对话与流式输出\n"
     },
     "docs/guide/saluzi-home": {
       "frontmatter": {
@@ -3088,19 +3081,47 @@
       },
       "content": "\n## 主目录位置\n\nSaluzi 把所有用户数据集中放在主目录下的 `~/.saluzi-edu` 文件夹。路径由 `getSaluziConfigHomeDir()` 统一决定：\n\n- **Linux / macOS**：`~/.saluzi-edu`\n- **Windows**：`%USERPROFILE%\\.saluzi-edu`（即 `C:\\Users\\<你>\\.saluzi-edu`）\n\n可通过环境变量 `SALUZI_CONFIG_DIR` 覆盖到任意位置（支持 `~` 展开），适合多套配置切换或放在加密分区。\n\n> 注意：企业受管配置 `managed-settings.json` **不在此目录**，而是放在系统级路径——macOS 为 `/Library/Application Support/SaluziCode`，Windows 为 `C:\\Program Files\\SaluziCode`，Linux 为 `/etc/saluzi-edu`。普通用户一般不需要动它。\n\n## 子目录与文件清单\n\n启动后 `~/.saluzi-edu` 下会按需出现以下条目。各子目录在首次写入时自动 `mkdir -p`，不需要手动创建。\n\n### 配置与凭证\n\n| 路径 | 作用 | 删除影响 |\n|------|------|---------|\n| `settings.json` | 用户全局设置（env、权限、模型、hooks 等）。详见下文 | 重置为默认配置 |\n| `settings.local.json` | 项目级本地设置（gitignored）。仅在 `<cwd>/.saluzi-edu/` 下生效 | 丢失本地覆盖 |\n| `.credentials.json` | OAuth 登录凭证 | 需重新 `/login` |\n| `.config.json` | 内部运行配置，不要手编 | 自动重建 |\n| `keybindings.json` | 自定义快捷键 | 恢复默认按键 |\n| `SALUZI.md` | 用户级记忆（跨项目的个人偏好） | 丢失用户记忆 |\n| `rules/` | 用户级规则文件 | 丢失规则 |\n\n### 项目数据（按 cwd 隔离）\n\n| 路径 | 作用 |\n|------|------|\n| `projects/<sanitized-cwd>/` | 每个工作目录一个子目录，存放该项目专属的会话与记忆 |\n| `projects/<cwd>/memory/` | 自动记忆：`MEMORY.md` + `logs/YYYY/MM/` 日志 |\n| `projects/<cwd>/*.jsonl` | 该项目的会话转录 |\n\n项目子目录名是 cwd 路径的 sanitized 形式（特殊字符替换），所以同时多个项目互不干扰。\n\n### 扩展与自定义\n\n| 路径 | 作用 |\n|------|------|\n| `skills/` | 用户技能（由 `/skill-learning` 自动生成或手写） |\n| `commands/` | 用户自定义 slash 命令 |\n| `agents/` | 用户自定义 agent（Markdown 文件） |\n| `teams/` | 团队配置 |\n| `templates/` | 任务模板 |\n| `plugins/` | 插件安装目录（由 `/plugin` 管理） |\n| `plugin-options/` | 插件运行时选项 |\n\n### 运行时状态\n\n| 路径 | 作用 |\n|------|------|\n| `sessions/` | 并发会话状态 |\n| `jobs/` | 后台任务状态 |\n| `tasks/` | 任务数据 |\n| `plans/` | plan 文件 |\n| `daemon/` | daemon 进程状态（`<name>.json`） |\n| `shell-snapshots/` | Shell 环境快照（`!` 命令用） |\n| `history.jsonl` | 全局命令历史 |\n| `stats-cache.json` | 使用统计缓存 |\n| `usage-data/` | `/insights` 用量数据 |\n| `pr-subscriptions.json` | PR 订阅列表 |\n| `file-history/` | 文件修改历史 |\n| `session-env/` | 会话环境变量 |\n| `uploads/<sessionId>/` | 入站附件 |\n\n### 缓存与日志\n\n| 路径 | 作用 |\n|------|------|\n| `cache/model-capabilities.json` | 模型能力缓存 |\n| `backups/` | 配置文件备份 |\n| `debug/<sessionId>.txt` | 调试日志 |\n| `traces/` | Perfetto 性能追踪 |\n| `startup-perf/` | 启动性能分析 |\n| `.update.lock` | 自动更新锁文件 |\n\n### IDE 与集成\n\n| 路径 | 作用 |\n|------|------|\n| `ide/` | IDE 集成数据 |\n| `local/` | 本地安装文件 |\n| `magic-docs/prompt.md` | MagicDocs prompt |\n| `skill-learning/` | 技能学习上下文 |\n| `autonomy/` | 自治运行记录（`runs.json`、`flows.json`） |\n\n所有缓存与运行时状态目录都可安全删除——Saluzi 会按需重建。配置类（`settings.json`、`SALUZI.md`、`keybindings.json`）删除会丢失个人定制，需要重新配置。\n\n## settings.json 配置\n\n`~/.saluzi-edu/settings.json` 是用户全局配置文件，JSON 格式，所有字段均可选。下面按主题分组说明。完整 JSON Schema 发布在 `https://json.schemastore.org/saluzi-edu-settings.json`，编辑器开启 JSON Schema 支持后可自动补全。\n\n### 来源与优先级\n\nSaluzi 合并 5 个来源的配置，后者覆盖前者：\n\n| 优先级 | 来源 | 路径 | 可编辑 |\n|--------|------|------|--------|\n| 1（低） | userSettings | `~/.saluzi-edu/settings.json` | 是 |\n| 2 | projectSettings | `<cwd>/.saluzi-edu/settings.json` | 是（共享，入 git） |\n| 3 | localSettings | `<cwd>/.saluzi-edu/settings.local.json` | 是（gitignored） |\n| 4 | flagSettings | `--settings <path>` CLI 参数 | 否 |\n| 5（高） | policySettings | 系统级 managed-settings.json | 否 |\n\n合并规则：标量高优先级直接覆盖；对象深度合并；数组拼接去重。policySettings 内部还按 remote > MDM (HKLM/plist) > managed-settings.json > HKCU 排序。\n\n### 1. 模型与推理\n\n| 字段 | 类型 | 默认 | 说明 |\n|------|------|------|------|\n| `modelType` | enum | `anthropic` | API 提供商：`anthropic`/`openai`/`gemini`/`grok` |\n| `model` | string | - | 覆盖默认模型 ID |\n| `availableModels` | string[] | - | 企业模型白名单（通常 managed） |\n| `modelOverrides` | Record<string,string> | - | 模型 ID 映射（如 Bedrock ARN） |\n| `effortLevel` | enum | `medium` | `low`/`medium`/`high`/`xhigh`/`max` |\n| `alwaysThinkingEnabled` | boolean | true | 是否启用 thinking |\n| `fastMode` | boolean | false | 启用 fast 模式 |\n| `fastModePerSessionOptIn` | boolean | false | fast 不跨会话持久化 |\n| `advisorModel` | string | - | 服务端 advisor 工具模型 |\n| `mom` | object | - | Mixture of Model 配置，见 [MOM 章节](./mom-mixed-models) |\n\n### 2. 环境变量\n\n`env` 是 `Record<string, string>`，写入后会注入到会话进程的环境变量。常用于配置 API Key 和端点：\n\n```json\n{\n  \"env\": {\n    \"ANTHROPIC_API_KEY\": \"sk-ant-...\",\n    \"ANTHROPIC_BASE_URL\": \"https://api.anthropic.com\",\n    \"SALUZI_EFFORT_LEVEL\": \"high\"\n  }\n}\n```\n\n常用键：\n\n| 键 | 作用 |\n|----|------|\n| `ANTHROPIC_API_KEY` | Anthropic API Key（设置后免 `/login`） |\n| `ANTHROPIC_BASE_URL` | Anthropic 端点（自建反代用） |\n| `OPENAI_API_KEY` / `OPENAI_BASE_URL` / `OPENAI_MODEL` | OpenAI 兼容 |\n| `GEMINI_API_KEY` / `GEMINI_BASE_URL` | Gemini |\n| `GROK_API_KEY` / `GROK_BASE_URL` / `GROK_MODEL` | Grok/xAI |\n| `SALUZI_EFFORT_LEVEL` | 推理深度（覆盖 effortLevel） |\n| `SALUZI_MAX_CONTEXT_TOKENS` | 最大上下文 token |\n| `SALUZI_DISABLE_1M_CONTEXT` | 禁用 1M 上下文 |\n| `SALUZI_CLIENT_CERT` / `SALUZI_CLIENT_KEY` | mTLS 证书 |\n\n### 3. 权限\n\n`permissions` 控制工具调用的授权策略：\n\n```json\n{\n  \"permissions\": {\n    \"defaultMode\": \"default\",\n    \"allow\": [\"Bash(npm test:*)\", \"Read(./src/**)\"],\n    \"deny\": [\"Bash(rm -rf:*)\"],\n    \"ask\": [\"Write(**)\"],\n    \"additionalDirectories\": [\"../other-project\"]\n  }\n}\n```\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `defaultMode` | enum | `default`/`acceptEdits`/`bypassPermissions`/`dontAsk`/`plan`/`auto` |\n| `allow` | string[] | 自动放行的工具规则 |\n| `deny` | string[] | 直接拒绝的规则 |\n| `ask` | string[] | 总是弹出确认的规则 |\n| `additionalDirectories` | string[] | 额外允许访问的目录 |\n| `disableBypassPermissionsMode` | `\"disable\"` | 禁用 bypass 模式 |\n\n规则语法如 `Bash(npm test:*)`、`Read(./src/**)`，可用 `*` 通配。\n\n### 4. Hooks\n\n`hooks` 在工具执行前后触发自定义命令。事件类型有 25+ 种，常用的：\n\n| 事件 | 触发时机 |\n|------|---------|\n| `PreToolUse` | 工具调用前 |\n| `PostToolUse` | 工具调用后 |\n| `UserPromptSubmit` | 用户提交输入时 |\n| `SessionStart` / `SessionEnd` | 会话开始/结束 |\n| `Stop` / `StopFailure` | 主循环停止 |\n| `Notification` | 通知发送时 |\n| `PreCompact` / `PostCompact` | 上下文压缩前后 |\n| `PermissionRequest` / `PermissionDenied` | 权限请求/拒绝时 |\n\n每个 hook 是 `{ matcher?: string, hooks: HookCommand[] }`，HookCommand 有四种类型：\n\n```json\n{\n  \"hooks\": {\n    \"PreToolUse\": [\n      {\n        \"matcher\": \"Bash\",\n        \"hooks\": [\n          { \"type\": \"command\", \"command\": \"echo 'running bash'\", \"shell\": \"bash\" },\n          { \"type\": \"prompt\", \"prompt\": \"检查这个命令是否安全\" },\n          { \"type\": \"http\", \"url\": \"https://audit.example.com/hook\", \"headers\": {} },\n          { \"type\": \"agent\", \"prompt\": \"评估风险\", \"model\": \"pro\" }\n        ]\n      }\n    ]\n  }\n}\n```\n\n| 字段 | 适用类型 | 说明 |\n|------|---------|------|\n| `command` / `shell` / `timeout` | command | 执行 shell 命令 |\n| `prompt` / `model` | prompt / agent | 让模型评估 |\n| `url` / `headers` / `allowedEnvVars` | http | HTTP 回调 |\n| `statusMessage` / `once` / `async` / `if` | 全部 | 通用控制 |\n\n`disableAllHooks: true` 可一键禁用所有 hooks 和 statusLine。\n\n### 5. 沙箱\n\n`sandbox` 控制工具执行的隔离边界：\n\n```json\n{\n  \"sandbox\": {\n    \"enabled\": true,\n    \"failIfUnavailable\": false,\n    \"autoAllowBashIfSandboxed\": true,\n    \"network\": {\n      \"allowedDomains\": [\"api.anthropic.com\", \"registry.npmjs.org\"]\n    },\n    \"filesystem\": {\n      \"allowWrite\": [\"./src\", \"./tests\"],\n      \"denyWrite\": [\".env\", \".git\"]\n    }\n  }\n}\n```\n\n| 字段 | 说明 |\n|------|------|\n| `enabled` | 启用沙箱 |\n| `failIfUnavailable` | 沙箱不可用时直接失败（通常 managed） |\n| `autoAllowBashIfSandboxed` | 沙箱内自动放行 Bash |\n| `allowUnsandboxedCommands` | 允许未沙箱化的命令 |\n| `network.allowedDomains` | 允许访问的域名 |\n| `network.allowManagedDomainsOnly` | 仅用 managed 域名白名单 |\n| `filesystem.allowWrite` / `denyWrite` | 读写路径规则 |\n| `excludedCommands` | 排除沙箱的命令 |\n\n### 6. UI 与输出\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `outputStyle` | string | 响应输出样式 |\n| `language` | string | 首选语言（如 `chinese`、`japanese`） |\n| `theme` | string | 主题名 |\n| `prefersReducedMotion` | boolean | 减少动画 |\n| `syntaxHighlightingDisabled` | boolean | 禁用 diff 语法高亮 |\n| `terminalTitleFromRename` | boolean | `/rename` 同步终端标题 |\n| `spinnerTipsEnabled` | boolean | spinner 显示提示 |\n| `spinnerVerbs` | object | 自定义 spinner 动词 |\n| `spinnerTipsOverride` | object | 覆盖 spinner tips |\n| `statusLine` | object | 自定义状态行（`{ type: \"command\", command, padding? }`） |\n\n### 7. MCP 服务器\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `enableAllProjectMcpServers` | boolean | 自动批准项目所有 MCP 服务器 |\n| `enabledMcpjsonServers` | string[] | 已批准的 .mcp.json 服务器 |\n| `disabledMcpjsonServers` | string[] | 已拒绝的 .mcp.json 服务器 |\n| `allowedMcpServers` | array | 企业 MCP 白名单 |\n| `deniedMcpServers` | array | 企业 MCP 黑名单（优先于白名单） |\n\n### 8. 插件\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `enabledPlugins` | Record<string, string[]\\|boolean> | 已启用插件（plugin-id@marketplace-id） |\n| `extraKnownMarketplaces` | Record<string, object> | 额外插件市场源 |\n| `pluginConfigs` | Record<string, {mcpServers?, options?}> | 每插件配置 |\n| `strictPluginOnlyCustomization` | boolean\\|enum[] | 阻止非插件自定义（surfaces: `skills`/`agents`/`hooks`/`mcp`） |\n\n### 9. 记忆与技能\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `autoMemoryEnabled` | boolean | 项目自动记忆开关 |\n| `autoMemoryDirectory` | string | 自动记忆存储目录（projectSettings 中忽略） |\n| `autoDreamEnabled` | boolean | 后台记忆整合 |\n| `memoryV2Enabled` | boolean | Memory V2 总开关 |\n| `memoryV2` | object | V2 子特性（gatedWrites、hybridStorage、smartRetrieval 等） |\n| `skillSearchEnabled` | boolean | 技能搜索预取 |\n| `skillLearningEnabled` | boolean | 自动技能学习 |\n| `skillImprovementEnabled` | boolean | 自动技能改进 |\n\n### 10. 自动更新与启动\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `autoUpdatesChannel` | enum | `latest`/`stable` |\n| `minimumVersion` | string | 最低版本（防降级） |\n| `cleanupPeriodDays` | number | 聊天转录保留天数（默认 30，0=禁用持久化） |\n| `includeGitInstructions` | boolean | 系统提示是否含 git 工作流（默认 true） |\n| `respectGitignore` | boolean | 文件选择器是否尊重 .gitignore（默认 true） |\n| `skipWebFetchPreflight` | boolean | 跳过 WebFetch 黑名单检查 |\n\n### 11. 登录与认证\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `forceLoginMethod` | enum | `claudeai`/`console` 强制登录方式 |\n| `forceLoginOrgUUID` | string | OAuth 组织 UUID |\n| `apiKeyHelper` | string | 输出认证值的脚本路径 |\n| `awsCredentialExport` / `awsAuthRefresh` | string | AWS 凭证脚本 |\n| `gcpAuthRefresh` | string | GCP 认证刷新命令 |\n| `otelHeadersHelper` | string | OpenTelemetry headers 脚本 |\n\n### 12. 提交与归属\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `attribution` | object | 提交/PR 归属文本（`{ commit, pr }`） |\n| `includeCoAuthoredBy` | boolean | 已弃用，改用 attribution |\n\n### 13. API Key 绑定\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `keys` | KeyEntry[] | API key 条目（`/keys` 命令） |\n| `keyBindings` | object | 模型 slot→key 索引（`{ default?, max?, pro?, std?, subagent? }`） |\n| `keyModelNames` | Record<string,string> | slot→模型名映射 |\n\n详见 [API Key 绑定章节](./keys-binding)。\n\n### 14. 企业受管字段\n\n以下字段设计上只从 managed-settings.json 读取，普通 settings.json 中写会被忽略：\n\n- `allowManagedHooksOnly` — 仅运行 managed 的 hooks\n- `allowManagedPermissionRulesOnly` — 仅用 managed 的权限规则\n- `allowManagedMcpServersOnly` — 仅从 managed 读 MCP 白名单\n- `strictPluginOnlyCustomization` — 阻止非插件自定义\n- `strictKnownMarketplaces` / `blockedMarketplaces` — 插件市场白/黑名单\n- `pluginTrustMessage` — 插件信任警告附加消息\n- `sandbox.failIfUnavailable` — 沙箱不可用即失败\n- `sandbox.network.allowManagedDomainsOnly` — 仅用 managed 域名\n- `sandbox.filesystem.allowManagedReadPathsOnly` — 仅用 managed 读路径\n\n### 15. 其他\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `defaultShell` | enum | `bash`/`powershell`，`!` 命令默认 shell |\n| `worktree` | object | git worktree 配置（`symlinkDirectories`, `sparsePaths`） |\n| `plansDirectory` | string | plan 文件自定义目录 |\n| `feedbackSurveyRate` | number(0-1) | 会话反馈调查出现概率 |\n| `channelsEnabled` | boolean | 团队/企业频道通知 opt-in |\n| `showClearContextOnPlanAccept` | boolean | plan 批准对话框显示 clear context |\n| `saluziMdExcludes` | string[] | 排除加载 SALUZI.md 的 glob 模式 |\n| `remote.defaultEnvironmentId` | string | 远程会话默认环境 |\n| `sshConfigs` | array | SSH 远程配置（`{ id, name, sshHost, sshPort?, sshIdentityFile?, startDirectory? }`） |\n\n## 编辑建议\n\n- **优先用 userSettings**：`~/.saluzi-edu/settings.json` 放跨项目偏好（主题、模型、env）\n- **项目共享配置用 projectSettings**：`<cwd>/.saluzi-edu/settings.json`，入 git 团队共享\n- **个人项目覆盖用 localSettings**：`<cwd>/.saluzi-edu/settings.local.json`，gitignored\n- **不要手编 .config.json / .credentials.json**：用 `/login` 等命令让 Saluzi 自己写\n- **删除前备份**：`settings.json`、`SALUZI.md`、`keybindings.json` 删了不可恢复\n\n## 下一步\n\n- [排障](./troubleshooting) — `/doctor` 全面体检配置\n- [上下文管理](./context-tips) — SALUZI.md 项目记忆机制\n- [API Key 绑定](./keys-binding) — `/keys` 多 Key 调度\n"
     },
-    "docs/guide/keys-binding": {
+    "docs/guide/weixin-login": {
       "frontmatter": {
-        "title": "API Key 绑定",
-        "description": "使用 /keys 命令管理多个 API Key，绑定到模型槽位（default/max/pro/std/subagent），实现多 provider 混用与灵活切换。",
+        "title": "微信控制 - 通过微信远程操控 Saluzi",
+        "description": "微信作为 Saluzi 的会话控制渠道：接收微信消息作为指令，回复执行结果到微信，实现远程操控。",
         "keywords": [
-          "keys",
-          "API Key",
-          "绑定",
-          "provider",
-          "模型槽位"
+          "微信控制",
+          "weixin",
+          "远程操控",
+          "WeChat",
+          "消息渠道"
         ]
       },
-      "content": "\n## 什么是 /keys\n\n`/keys` 命令管理 Saluzi 的 API Key 绑定。它采用**双栏 TUI 界面**（左栏为模型槽位，右栏为 Key 列表），支持：\n\n- 绑定多个 provider 的 Key（Anthropic、OpenAI、Gemini、Grok、Foundry、自定义等）\n- 将 Key 绑定到不同的**模型槽位**（default / max / pro / std / subagent）\n- 为每个 Key 设置名称、指定 Base URL（transit 代理场景）\n- 编辑、删除、解绑已有配置\n\n## 使用方法\n\n```\n> /keys\n```\n\n打开双栏管理面板。通过键盘快捷键操作：\n\n| 快捷键 | 操作 |\n|--------|------|\n| `a` | 添加新 Key |\n| `e` | 编辑已有 Key（名称/provider/URL/key 值） |\n| `d` | 删除 Key |\n| `b` | 绑定到模型槽位 |\n| `u` | 解绑槽位 |\n| `Esc` | 关闭面板 |\n\n添加 Key 时需要输入：\n- Key 名称（如 `anthropic-work`）\n- Provider（Anthropic Direct / Transit / OpenAI / Gemini / Grok / Foundry / Custom）\n- API Key 值\n- Base URL（Transit、Foundry、Custom 等场景需要）\n\nKey 保存在本地配置中，不会提交到 VCS。\n\n## 模型槽位\n\n`/keys` 的核心概念是**模型槽位**。每个槽位对应一个模型级别：\n\n| 槽位 | 说明 |\n|------|------|\n| `default` | 默认 Key，所有模型共用 |\n| `max` | Max 级别模型专用 Key |\n| `pro` | Pro 级别模型专用 Key |\n| `std` | Std 级别模型专用 Key |\n| `subagent` | 子 agent 专用 Key |\n\n当 `/model max` 执行时，Saluzi 优先使用 `max` 槽位的 Key；未配置时回退到 `default`。\n\n## 槽位上下文长度\n\n不同 provider 的模型上下文窗口可能不一致（例如 Anthropic 200K、Gemini 1M、某些 OpenAI 兼容端点 128K）。默认情况下，所有槽位共用全局配置的上下文上限（`SALUZI_MAX_CONTEXT_TOKENS` 或 `/login` 配置）。\n\n`/keys` 支持为每个槽位单独配置上下文长度：\n\n1. 在 Model Slots 区域选中目标槽位，按 `b` 开始绑定\n2. 选择 Key 后输入 model name（可留空使用 provider 默认）\n3. 在 **Context Limit** 步骤输入该槽位的上下文 token 数（如 `200000`、`1000000`），留空则使用全局配置\n\n配置后，切换到该槽位的模型时，状态栏与 auto-compact 阈值都会使用槽位专属的上下文长度。槽位列表会显示 `[ctx: 500k]` 标记。\n\n槽位上下文长度的解析优先级：\n\n1. `SALUZI_MAX_CONTEXT_TOKENS`（管理员全局强制覆盖，最高优先）\n2. `KEYS_{SLOT}_CONTEXT_LIMIT`（本槽位配置）\n3. `SALUZI_AUTO_COMPACT_WINDOW`（全局 auto-compact 阈值）\n4. `[1m]` 后缀 / 模型能力缓存 / 200K 默认\n\n## 环境变量\n\n可通过环境变量预设 Key 配置（CI/CD 场景常用）：\n\n```bash\nKEYS_DEFAULT_KEY=sk-xxx slz\nKEYS_MAX_KEY=sk-xxx KEYS_MAX_MODEL=claude-opus-4-7 KEYS_MAX_CONTEXT_LIMIT=1000000 slz\n```\n\n格式为 `KEYS_{SLOT}_{FIELD}`，其中 SLOT 为 `DEFAULT`/`MAX`/`PRO`/`STD`/`SUBAGENT`，FIELD 为 `KEY`/`PROVIDER`/`MODEL`/`URL`/`CONTEXT_LIMIT`。\n\n## Provider 选择\n\nSaluzi 自动选择最优 Provider。如需指定：\n- 通过环境变量（如 `ANTHROPIC_API_KEY`）指定\n- 通过 `/keys` 绑定特定 provider 的 Key 到对应槽位\n- 通过 `/model` 切换当前会话模型\n\n## 安全建议\n\n- 不要把 Key 写进代码或 commit\n- 用 `/keys` 管理而非环境变量（更安全、可切换）\n- 定期轮换 Key\n"
+      "content": "\n## 什么是微信控制\n\n微信控制是 Saluzi 的会话控制渠道之一。启用后，你可以通过微信向 Saluzi 发送消息指令，Saluzi 执行后会通过微信回复结果。这让你无需在终端前，也能远程操控 Saluzi 会话。\n\n微信控制**不是登录手段**——它不负责身份认证，而是在你已登录 Saluzi 后，提供一种远程消息渠道。\n\n## 启用微信控制\n\n### 第一步：扫码绑定\n\n使用 `weixin login` 子命令完成微信绑定：\n\n```bash\nslz weixin login\n```\n\n终端会显示一个二维码，用微信扫码后，微信账号与 Saluzi 绑定。登录凭证保存在 `~/.saluzi-edu/channels/weixin/account.json`。\n\n如需解除绑定：\n\n```bash\nslz weixin login clear\n```\n\n### 第二步：启动带微信渠道的会话\n\n绑定后，启动 Saluzi 时通过 `--channels` 参数接入微信消息：\n\n```bash\nslz --channels plugin:weixin@builtin\n```\n\nSaluzi 会在后台持续监听微信消息。收到消息后，消息会作为对话轮次注入当前会话，AI 处理后可通过微信回复结果。\n\n### 第三步：配对授权\n\n首次有人通过微信向你的 Saluzi 发消息时，系统会返回一个 6 位配对码。在终端中运行：\n\n```bash\nslz weixin access pair <配对码>\n```\n\n配对成功后，该微信用户被加入允许列表，后续消息直接转发到 Saluzi 会话。\n\n## 通过微信操控会话\n\n配对完成后，通过微信发送的消息会被注入 Saluzi 会话。AI 会像处理终端输入一样处理微信消息——读取文件、修改代码、运行命令，然后通过微信回复执行结果。\n\n### 权限审批\n\n当 Saluzi 需要工具调用权限时（例如执行命令、修改文件），审批提示会发送到微信。你可以直接在微信中回复：\n\n- `yes <请求ID>` — 批准\n- `no <请求ID>` — 拒绝\n\n这样即使不在终端前，也能批准或拒绝 Saluzi 的操作请求。\n\n### 文件附件\n\nSaluzi 可以通过微信回复时附带文件（使用绝对路径）。你也可以通过微信发送图片、语音、文件等附件给 Saluzi——语音消息会自动转录为文本。\n\n## 典型场景\n\n- **外出时远程操控**：离开电脑后，通过微信发消息让 Saluzi 继续执行任务\n- **移动审批**：长任务运行时，通过微信批准权限请求，无需守在终端前\n- **移动监控**：随时通过微信查看任务状态或调整指令\n\n## 故障排查\n\n- **二维码不显示**：确认终端支持 UTF-8 与 256 色，尝试 `/theme` 切换主题\n- **扫码超时**：重新运行 `slz weixin login`，二维码有效期约 60 秒\n- **消息不同步**：检查网络连接，确认 Saluzi 进程仍在运行\n- **配对码无效**：确认 6 位码未过期，重新触发消息获取新的配对码\n"
+    },
+    "docs/guide/cost-usage": {
+      "frontmatter": {
+        "title": "查看消耗 - 会话花费与历史统计",
+        "description": "使用 /cost、/stats 查看当前会话花费与历史统计。",
+        "keywords": [
+          "cost",
+          "stats",
+          "消耗",
+          "统计"
+        ]
+      },
+      "content": "\n## 当前会话花费\n\n`/cost` 显示本次会话的 token 消耗与费用明细。适合在长对话中随时检查开销：\n\n```\n> /cost\n```\n\n输出包含输入 token、输出 token 以及折算后的费用。会话结束后计数清零，下次对话重新累计。\n\n## 历史统计\n\n`/stats` 展示跨会话的累计数据，包括总对话次数、总 token 消耗等：\n\n```\n> /stats\n```\n\n与 `/cost` 的区别在于：`/cost` 只看当前会话，`/stats` 汇总所有历史记录。\n\n## 命令速查\n\n| 命令 | 作用范围 | 用途 |\n|------|---------|------|\n| `/cost` | 当前会话 | 本次对话的 token 与费用 |\n| `/stats` | 全部历史 | 累计消耗与会话统计 |\n\n## 下一步\n\n- [故障排查](./troubleshooting) — 常见问题与解决方案\n- [代码图谱](./codegraph) — 用 CodeGraph 探索项目结构\n- [模型选择与切换](./model-selection) — 调整模型以控制成本\n"
+    },
+    "docs/guide/context-tips": {
+      "frontmatter": {
+        "title": "上下文管理 - 让 AI 更好理解你的项目",
+        "description": "通过挂载目录、SALUZI.md 项目记忆、个人偏好配置，让 Saluzi 更精准地理解你的项目与习惯。",
+        "keywords": [
+          "上下文",
+          "add-dir",
+          "SALUZI.md",
+          "memory",
+          "项目记忆",
+          "compact"
+        ]
+      },
+      "content": "\n## 让 AI 理解项目\n\nSaluzi 的回答质量取决于它对项目的理解程度。本章介绍三种方式，让 AI 快速进入状态。\n\n### 挂载工作目录\n\n```\n> /add-dir\n```\n\n挂载目录后，Saluzi 会扫描结构并将该目录纳入工具的文件访问范围，后续对话可基于代码上下文回答。\n\n可以挂载多个目录，适合跨仓库协作场景：\n\n```\n> /add-dir ~/projects/frontend\n> /add-dir ~/projects/backend\n```\n\n### 何时挂载\n\n- 开始新项目时\n- 需要跨多个仓库工作时\n- AI 对项目结构不熟时\n\n> **Tip** 可用 `/codegraph` 查看或启用代码智能索引。索引基于项目根目录（而非挂载目录），需要手动开启。\n\n## 项目记忆：SALUZI.md\n\n在项目根目录创建 `SALUZI.md`，写入项目约定。Saluzi 每次对话都会读取它，相当于给 AI 一份\"项目手册\"。\n\n### 示例\n\n```markdown\n# 项目约定\n\n## 技术栈\n- 前端：React 19 + Vite + Tailwind v4\n- 后端：Hono + Node.js\n\n## 代码风格\n- 用 npm，不用 yarn\n- TypeScript strict 模式\n- 提交前跑 `npm run lint`\n\n## 架构原则\n- 命令目录结构遵循项目约定\n- 不要在 prod 代码里用 as any\n```\n\n### SALUZI.md 写什么\n\n| 类别 | 示例 |\n|------|------|\n| 技术栈与版本 | React 19、Node 22、PostgreSQL 16 |\n| 代码风格规范 | 用 pnpm 而非 yarn，2 空格缩进 |\n| 项目架构原则 | 命令目录结构、模块边界 |\n| 常用命令 | `npm run lint`、`npm run test`、`npm run build` |\n| 禁忌事项 | 不要加 docstring，不要 `as any` |\n\n> **Tip** `SALUZI.md` 应纳入版本控制，让整个团队共享同一份约定。\n\n## 个人偏好：/memory\n\n`/memory` 用于记录跨项目的个人习惯，与 `SALUZI.md` 互补：\n\n```\n> /memory\n```\n\n打开记忆面板，可添加、编辑、删除条目。例如：\n\n- \"我喜欢用 conventional commits\"\n- \"代码注释用中文\"\n- \"不要加 docstring，除非逻辑非显然\"\n\n记忆保存在 `~/.saluzi-edu/` 下，跨项目、跨会话生效。\n\n### SALUZI.md vs /memory\n\n| 维度 | SALUZI.md | /memory |\n|------|-----------|---------|\n| 作用范围 | 单个项目 | 所有项目 |\n| 存储位置 | 项目根目录 | `~/.saluzi-edu/` |\n| 共享方式 | Git 版本控制 | 仅本人可见 |\n| 适合内容 | 项目约定、团队规范 | 个人习惯、偏好 |\n\n## 上下文压缩\n\n长对话会接近模型的 token 上限，Saluzi 通过压缩策略保持对话可用。\n\n### 何时压缩\n\n- 对话超过 token 上限时，自动压缩早期内容\n- 手动输入 `/compact` 主动压缩\n- 输入 `/context` 查看当前上下文占用情况\n\n### 压缩策略\n\n- 保留关键决策与代码改动\n- 丢弃冗余的探索过程\n- 保留最近若干轮原文，确保连贯性\n\n### 清理会话\n\n需要从头开始时，直接清理：\n\n```\n> /clear          # 完全重置，清空当前会话上下文\n```\n\n## 让 AI 记住更多\n\n### 用 /resume 恢复历史会话\n\n```\n> /resume\n```\n\n列出历史会话列表，选择一个恢复，之前的上下文即可继续使用。适合中断后接着做。\n\n### 用 /rewind 回退\n\n```\n> /rewind\n```\n\n回退到对话历史中的某一步，丢弃之后的所有内容。适合\"走错方向、想重来\"的场景。\n\n## 实用技巧\n\n### 分阶段工作\n\n大任务拆成多步，避免上下文过载：\n\n1. 先 `/plan` 让 AI 规划方案\n2. 确认方案后退出 plan mode\n3. 分批执行，每批完成后 `/compact` 压缩上下文\n4. 最后 `/commit` 提交\n\n### 跨项目切换\n\n切到另一个项目前，先 `/clear` 清空上下文，避免前一个项目的信息干扰当前对话。\n\n### 给 AI 明确指令\n\n在提问时带上具体路径和期望行为，比泛泛而问效果更好：\n\n```\n# 好\n> 看一下 login.ts，把 validateToken 函数改成 async，错误抛 AuthError\n\n# 差\n> 改一下登录那里\n```\n\n## 下一步\n\n- [对话基础](./conversation-basics) — 多轮对话与流式输出\n- [新手入门](./getting-started) — 安装与首次登录\n- [模型选择](./model-selection) — 切换 Max/Pro/Std\n"
     },
     "docs/guide/token-saving-modes": {
       "frontmatter": {
@@ -3119,47 +3140,7 @@
           "省 token"
         ]
       },
-      "content": "\n## 为什么需要 Token 节约模式\n\nSaluzi 默认开启大量「让 AI 更聪明」的后台机制：自动记忆提取、提示建议、会话记忆整合、验证 Agent、相关记忆预取、Agent 摘要……这些机制各自只消耗少量 token，但叠在一起会让每次对话的「隐性开销」相当可观。\n\n当你处于以下场景时，这些开销就是纯浪费：\n\n- **API Key 按量计费**，想压到最低\n- **弱模型 / 小上下文窗口**，每一段 prompt 都很贵\n- **一次性脚本任务**，不需要长期记忆\n- **清晰的单文件修改**，不需要多角度验证\n\n两种节约模式就是为这些场景设计的开关，按「砍多少」分档：\n\n| 模式 | 砍掉的范围 | 工具集 | System Prompt | 适合 |\n|------|-----------|--------|--------------|------|\n| **Poor** | 5 项后台副作用 | 全部保留 | 完整 | 日常开发省 token |\n| **SA** | 全部后台 + 工具收敛 | 仅 4 核心 | ~20 行极简 | 极限省 token / 弱模型 |\n\nSA 是 Poor 的**严格超集**——Poor 关掉的一切，SA 也关掉；SA 还额外砍掉工具和 prompt。两者的关系类似「省电模式」与「飞行模式」。\n\n## Poor 节约模式\n\n### 是什么\n\n`/poor` 切换 Poor 模式。开启后 Saluzi 跳过 5 类后台副作用任务，并对若干辅助模型调用降级。**主对话的工具集与 system prompt 完全不变**——你只是少了一些「后台 whisper」。\n\n### 关闭了什么\n\n| 被关闭的子系统 | 位置 | 原本做什么 |\n|---------------|------|-----------|\n| extract_memories | Stop hook | 每轮结束后从对话提取记忆写入 MEMORY.md |\n| prompt_suggestion | Stop hook | 给用户猜测「下一步可能想问什么」 |\n| autoDream | Stop hook | 后台整合/蒸馏历史记忆 |\n| AgentSummary | 后台 | 给子 Agent 生成摘要 |\n| 验证 Agent | System prompt | 非平凡改动后强制独立审查 |\n\n同时这些**辅助模型调用降级**（不影响主模型）：\n\n| 调用点 | 原模型 | Poor 后 |\n|--------|--------|---------|\n| autoMode critique | MainLoop | SmallFast |\n| permission explainer | MainLoop | SmallFast |\n| universal classifier | MainLoop | DefaultPro |\n| yolo classifier | MainLoop | DefaultPro |\n\n降级意味着权限分类、自动模式批评等「辅助判断」用更便宜的模型跑，质量略降但成本显著下降。主对话模型不变。\n\n### 优势\n\n- **工具集完整**：Read/Edit/Write/Bash/Glob/Grep/WebFetch/Task/MCP……全部照常\n- **System prompt 完整**：项目记忆、CodeGraph、技能、SALUZI.md 仍然注入\n- **可逆且持久**：`/poor` 再按一次关闭；状态写入 `settings.json` 的 `poorMode` 字段，重启后保留\n- **粒度温和**：只砍「后台 whisper」，主循环质量基本无损\n\n### 劣势\n\n- **不再自动积累记忆**：MEMORY.md 不会自动更新，需要手动 `/memory` 编辑\n- **无提示建议**：终端不再显示「你可能想问……」的快捷建议\n- **无验证 Agent**：复杂改动后没有独立审查兜底，需要自己跑测试\n- **辅助分类降级**：权限判断、自动模式批评的精度略降\n\n## SA 极简模式\n\n### 是什么\n\n`/sa` 切换 SA 模式（极简风格 minimal harness）。开启后 Saluzi 收敛到「最小可用 harness」：\n\n- **System prompt 收缩到 ~20 行**：只有角色定义 + 4 个工具说明 + 基本准则 + cwd + 日期。没有动态段落、没有项目记忆、没有 CodeGraph、没有 MCP 说明、没有会话指导。\n- **工具收敛到 4 个核心**：Read / Edit / Write / Bash。其余工具（Glob、Grep、WebFetch、Task、TodoWrite、MCP、Skill……）全部移除。\n- **所有后台副作用归零**：Poor 关掉的 5 项 + 会话记忆 + 相关记忆预取，全部跳过。\n\n这是「把 Saluzi 当成一个极简的 Read/Edit/Write/Bash 编码助手」的开关——类似极简 harness 的体验。\n\n### SA 的 System Prompt 长什么样\n\n完整内容就这些：\n\n```\nYou are an expert coding assistant operating inside Saluzi, a coding agent harness.\nYou help users by reading files, executing commands, editing code, and writing new files.\n\nAvailable tools:\n- Read: Read file contents from the filesystem\n- Edit: Make targeted edits to existing files\n- Write: Create new files or overwrite existing files\n- Bash: Execute shell commands\n\nGuidelines:\n- Be concise in your responses\n- Show file paths clearly when working with files\n- Use file_path:line_number format when referencing code locations\n- Do not use a colon before tool calls\n- Ask the user before making significant architectural decisions\n\nCurrent working directory: <cwd>\nDate: <date>\n```\n\n对比默认 prompt 的数千字（项目记忆 + CodeGraph + 技能 + 会话指导 + 工具说明 + 安全规则……），SA prompt 几乎是零开销。\n\n### 关闭了什么\n\nSA 关闭 = Poor 的全部 + 以下额外项：\n\n| 额外关闭项 | 位置 | 原本做什么 |\n|-----------|------|-----------|\n| 会话记忆提取 | sessionMemory | 跨会话蒸馏项目级记忆 |\n| 相关记忆预取 | attachments | 每轮用户消息后 side-query 检索相关记忆 |\n| 全部工具（除 4 核心） | tools | Glob/Grep/Task/WebFetch/MCP/Skill 等 |\n| 完整 system prompt | prompts | 替换为 20 行极简版 |\n\n### 优势\n\n- **极限省 token**：prompt 从数千字降到 ~20 行，每轮省下大量输入 token\n- **弱模型友好**：小上下文窗口 / 弱模型不会被巨型 prompt 挤占空间\n- **响应快**：没有后台 side-query 拖慢首字节\n- **行为可预测**：AI 只有 4 个工具，不会偷偷跑 WebFetch / Task / MCP，调试简单\n- **可逆且持久**：`/sa` 再按一次关闭；状态写入 `settings.json` 的 `saMode` 字段\n\n### 劣势\n\n- **没有 Glob/Grep**：AI 找文件只能用 `Bash(ls/find)` + `Read`，搜索效率低\n- **没有 Task/TodoWrite**：无法拆分多步任务、不能 spawn 子 Agent\n- **没有 WebFetch/WebSearch**：不能查文档、不能上网\n- **没有 MCP/Skill**：所有 MCP 服务器工具、自定义技能全部不可用\n- **没有项目记忆**：SALUZI.md、MEMORY.md、CodeGraph 知识都不注入，AI 对项目「无记忆」\n- **没有验证 Agent**：同 Poor\n- **AI 不知道自己的完整能力**：极简 prompt 不说明权限模式、安全规则、提交规范等，复杂工作流需要你手动提示\n\n> 简言之：SA 模式适合「我就让 AI 改这一个文件」「跑个脚本看看」这类窄任务，不适合复杂架构重构或需要项目上下文的工作。\n\n## 两种模式的完整对比\n\n| 维度 | 默认 | Poor | SA |\n|------|------|------|-----|\n| System prompt | 数千字（完整动态） | 数千字（完整动态） | ~20 行（极简） |\n| 工具集 | 全部 | 全部 | 4 核心（Read/Edit/Write/Bash） |\n| extract_memories | ✅ | ❌ | ❌ |\n| prompt_suggestion | ✅ | ❌ | ❌ |\n| autoDream | ✅ | ❌ | ❌ |\n| AgentSummary | ✅ | ❌ | ❌ |\n| 验证 Agent | ✅ | ❌ | ❌ |\n| 会话记忆提取 | ✅ | ✅ | ❌ |\n| 相关记忆预取 | ✅ | ✅ | ❌ |\n| 项目记忆注入 (SALUZI.md) | ✅ | ✅ | ❌ |\n| CodeGraph | ✅ | ✅ | ❌ |\n| MCP 工具 | ✅ | ✅ | ❌ |\n| Skill 工具 | ✅ | ✅ | ❌ |\n| Glob/Grep/WebFetch/Task | ✅ | ✅ | ❌ |\n| 辅助分类模型 | MainLoop | Pro/SmallFast | Pro/SmallFast |\n| 主对话模型 | 不变 | 不变 | 不变 |\n| 输入 token / 轮 | 基准 | 略低（少后台 side-query） | 显著低（prompt 极小） |\n| 适合场景 | 日常全功能 | 日常省 token | 极限省 / 弱模型 / 窄任务 |\n\n## 与其他功能的兼容性\n\n这是最关键的部分——开了节约模式后，你常用的那些 Saluzi 特色还能不能用。\n\n### MOM 混合模型\n\n| 模式 | 兼容性 | 说明 |\n|------|--------|------|\n| Poor | ✅ 完全兼容 | Poor 不触碰 MOM 配置，顾问与主机按 `/mom` 设置正常运行 |\n| SA | ⚠️ 受限兼容 | MOM 仍可运行，但**主机只有 4 个工具**（Read/Edit/Write/Bash）；顾问本就是 text-only 不受影响 |\n\n> 如果在 SA 模式下用 mom-stair，弱模型顾问（text-only）正常工作；升级到主机后主机也只能用 4 工具执行——不能 Glob/Grep/WebFetch。建议 SA + MOM 时把主机任务限定在文件读写 + 命令执行。\n\n### CodeGraph 代码智能\n\n| 模式 | 兼容性 | 说明 |\n|------|--------|------|\n| Poor | ✅ 完全兼容 | CodeGraph 工具与 prompt 段落照常注入 |\n| SA | ❌ 不可用 | 工具被收敛到 4 核心（无 CodeGraph 工具），prompt 也不含 CodeGraph 段落 |\n\n### 记忆系统 (Memory V2 / SALUZI.md)\n\n| 模式 | 兼容性 | 说明 |\n|------|--------|------|\n| Poor | ⚠️ 只读不写 | 已有记忆仍注入 prompt；但 extract_memories/autoDream 关闭，不再自动积累新记忆 |\n| SA | ❌ 完全隔离 | 既不注入（极简 prompt 无记忆段），也不提取（session memory 关闭） |\n\n### 验证 Agent (Verification Agent)\n\n| 模式 | 兼容性 |\n|------|--------|\n| Poor | ❌ 跳过 |\n| SA | ❌ 跳过 |\n\n两种模式都跳过验证 Agent。需要独立审查时请关闭节约模式后再跑，或手动 spawn 子 Agent（SA 模式下无 Task 工具，需先关 SA）。\n\n### Plan 模式 / Sandbox / Hooks\n\n| 模式 | Plan | Sandbox | Hooks |\n|------|------|---------|-------|\n| Poor | ✅ | ✅ | ✅ |\n| SA | ✅ | ✅ | ✅ |\n\n权限模式、沙箱、hooks 都是工具执行层机制，与节约模式正交，完全不受影响。\n\n### MCP 服务器 / Skill\n\n| 模式 | MCP | Skill |\n|------|-----|-------|\n| Poor | ✅ | ✅ |\n| SA | ❌ 工具被移除 | ❌ 工具被移除 |\n\nSA 模式下 MCP 服务器仍可连接（连接层不变），但 MCP 提供的工具不在 4 核心之列，不会被注入工具列表。\n\n### Auto Mode (/auto)\n\n| 模式 | 兼容性 | 说明 |\n|------|--------|------|\n| Poor | ⚠️ 降级 | autoMode 仍运行，但 critique 步骤用 SmallFast 模型 |\n| SA | ⚠️ 降级 | 同 Poor；且主机工具受限 |\n\n### Buddy 伴侣 / Proactive 主动助手\n\n| 模式 | 兼容性 |\n|------|--------|\n| Poor | ✅ Buddy/Proactive 不在 Poor 的关闭清单内 |\n| SA | ⚠️ SA 的设计哲学是「零后台副作用」，建议关闭 Buddy/Proactive 以获得最纯净体验 |\n\n## 权限模式与安全风险\n\n> 用户最关心的问题：**开了节约模式，AI 会不会偷偷执行 `rm -rf /`、`drop database` 这类删库命令？**\n>\n> 简短回答：**节约模式本身不改变权限策略，不会让危险命令「更容易跑」**。真正的风险来自你选的**权限模式**（`default` / `acceptEdits` / `bypassPermissions` / `auto`），而不是 Poor/SA。但 Poor/SA 会把权限分类器降级到更便宜的模型，在 `bypassPermissions`/`auto` 模式下**理论上**误判概率略升。下面逐层拆解。\n\n### 权限模式与节约模式正交\n\n权限模式由 `/permissions` 或 `settings.json` 的 `permissions.defaultMode` 控制，**与 Poor/SA 完全独立**。开 Poor 或 SA 不会切换你的权限模式：\n\n| 权限模式 | Bash 危险命令会怎样 | Poor/SA 影响 |\n|---------|---------------------|-------------|\n| `default` | 每条命令弹确认，`rm -rf` 类必问你 | 无——该问还是问 |\n| `acceptEdits` | 只自动放行文件编辑，**Bash 仍逐条问** | 无——Bash 仍问 |\n| `plan` | 只读，不能执行任何写操作 | 无——根本跑不了 |\n| `bypassPermissions` | 分类器自动判断，不问你 | ⚠️ 分类器降级（见下） |\n| `auto` | autoMode 分类器自动判断 | ⚠️ 分类器降级（见下） |\n\n**结论**：在 `default` / `acceptEdits` / `plan` 这三种模式下，无论开不开 Poor/SA，危险命令都必须经过你手动确认——**不存在「开了 SA 就自动删库」的情况**。\n\n### SA 模式仍执行 deny 规则\n\nSA 模式收敛工具集时调用的是 `filterToolsByDenyRules`——也就是说你在 `settings.json` 里配的 `permissions.deny` 规则**在 SA 模式下照常生效**：\n\n```json\n{\n  \"permissions\": {\n    \"deny\": [\n      \"Bash(rm -rf:*)\",\n      \"Bash(rm -rf /*:*)\",\n      \"Bash(drop database:*)\",\n      \"Bash(git push --force:*)\",\n      \"Bash(:(){ :|:& };:)\",\n      \"Bash(mkfs*:*)\"\n    ]\n  }\n}\n```\n\n这些规则会在工具列表阶段就**直接屏蔽**匹配的命令——AI 根本看不到这些工具能跑这类命令，分类器也不会被调用。这是比分类器更硬的防线，且**不受 Poor/SA 影响**。\n\n> 强烈建议：无论用不用节约模式，都把 `rm -rf /`、`drop database`、`mkfs`、fork 炸弹等不可逆命令写进 `deny`。这是「物理隔离」级别的一刀切。\n\n### 分类器降级：风险有多大\n\n在 `bypassPermissions` 或 `auto` 模式下，命令是否自动放行由**分类器**（yoloClassifier / universalClassifier）决定。Saluzi 的分类器 prompt 明确把以下列为 **Irreversible Local Destruction（不可逆本地破坏）**：\n\n- `rm -rf` 递归强制删除非平凡路径\n- `Remove-Item -Recurse -Force`（PowerShell 等价物）\n- `> file` 截断已有文件为空\n- `drop database` 删库\n- `git push --force`（视上下文）\n\nPoor/SA 模式下分类器模型降级：\n\n| 模式 | 分类器模型 | 影响 |\n|------|-----------|------|\n| 默认 | MainLoop（如 Max/Pro 主模型） | 精度最高 |\n| Poor/SA | DefaultPro | 略低，但仍是 Pro 级模型 |\n\n**关键点**：\n\n- 分类器**仍然运行**——Poor/SA 没有关闭分类器，只是让它用更便宜的模型跑。\n- Pro 级模型对 `rm -rf /` 这种明显的破坏性命令识别能力依然很强——这不是「盲放」。\n- 降级影响的是**边界模糊**的命令（如 `rm -rf ./build` 这种有歧义的）的判断精度，不是放行 `rm -rf /`。\n\n**所以「删库」风险的真实情况**：\n\n1. `default` / `acceptEdits` / `plan` 模式：**零风险**，必须你确认。\n2. `bypassPermissions` / `auto` + 默认：**低风险**，分类器（MainLoop）会拦。\n3. `bypassPermissions` / `auto` + Poor/SA：**略升的边界风险**，分类器（Pro）对明显破坏命令仍拦，但对模糊命令误判概率略高。\n4. 任何模式 + 配了 `deny` 规则：**零风险**，物理屏蔽。\n\n### SA 模式的特殊风险面\n\nSA 模式只保留 4 个工具（Read/Edit/Write/Bash），这反而**缩小**了攻击面：\n\n- **没有 WebFetch/WebSearch**：AI 不能下载并执行远程脚本。\n- **没有 Task**：不能 spawn 子 Agent 绕过主循环审查。\n- **没有 MCP 工具**：外部 MCP 服务器不能注入未审查的工具。\n- **没有 Skill**：自定义技能不会被执行。\n\n但 **Bash 仍在**——这是 SA 模式下唯一的「能干坏事」的入口。只要 Bash 的权限策略到位（`default` 模式或 `deny` 规则），SA 模式的整体风险面比默认模式**更小**，不是更大。\n\n### 安全使用建议\n\n| 建议 | 原因 |\n|------|------|\n| 默认用 `default` 或 `acceptEdits` 权限模式 | Bash 逐条确认，物理安全 |\n| 在 `settings.json` 配 `permissions.deny` 屏蔽 `rm -rf /`、`drop database`、`mkfs`、fork 炸弹 | 一刀切物理隔离，不受任何模式影响 |\n| 开启沙箱（`sandbox.enabled: true`）| 限制写入路径与网络访问，`rm -rf /` 直接失败 |\n| 避免 `bypassPermissions` + Poor/SA 组合 | 分类器降级 + 不问你 = 信任分类器，边界命令风险略升 |\n| SA 模式下尤其盯紧 Bash 输出 | 没有验证 Agent 兜底，需要你自己看命令 |\n| 用 `/permissions` 临时切 `plan` 模式做危险探索 | 只读，根本不能执行写操作 |\n\n### 一句话总结\n\n**Poor/SA 不会让 Saluzi「更敢删库」**——它们只砍后台副作用和工具数量，不动权限策略与 deny 规则。真正的删库风险来自 `bypassPermissions`/`auto` 权限模式本身；要彻底消除风险，配 `deny` 规则 + 开沙箱 + 用 `default` 模式，这三道防线与节约模式正交，同时开启完全安全。\n\n## 如何开启 / 关闭\n\n### 命令切换\n\n```\n> /poor        # 切换 Poor 模式（开↔关）\n> /sa          # 切换 SA 模式（开↔关）\n```\n\n输出会确认当前状态，例如：\n\n```\nSA mode ON — minimal prompt, 4 tools (Read/Edit/Write/Bash), all background tasks disabled\n```\n\n### 配置面板\n\n`/config` → 找到 `SA mode (minimal harness)` 与 `poor mode` 开关，`Enter` 切换。\n\n### settings.json\n\n直接编辑 `~/.saluzi-edu/settings.json`：\n\n```json\n{\n  \"poorMode\": true,\n  \"saMode\": true\n}\n```\n\n两个字段都可选，`true` 开启、省略或 `false` 关闭。重启 Saluzi 后生效。\n\n> **不要同时开 Poor 和 SA**。SA 是 Poor 的严格超集，同时开启只是冗余——工具集与 prompt 都按 SA 走，Poor 的标志位不起额外作用。需要极限省 token 就直接开 SA；需要保留全部工具就开 Poor。\n\n## 何时该用哪个\n\n| 你的情况 | 推荐 |\n|---------|------|\n| 日常开发，想省点 token，但还要用 Glob/Grep/MOM/CodeGraph | **Poor** |\n| API Key 按量计费，想压到最低 | **Poor**（日常）或 **SA**（窄任务） |\n| 用弱模型 / 小上下文窗口 | **SA** |\n| 一次性脚本：改一个文件、跑个命令 | **SA** |\n| 复杂架构重构、需要项目记忆与多步任务 | **关闭**（用默认） |\n| 需要 MOM 多顾问交叉验证 | **Poor**（保留工具）或 **关闭** |\n| 调试时想要「AI 不要偷偷干别的」 | **SA** |\n| 长期挂着的会话，不想后台烧 token | **Poor** |\n\n## 节约效果怎么看\n\n开启后用 `/cost` 观察单轮 token：\n\n```\n> /cost\n```\n\n重点看**输入 token**——SA 模式下每轮输入 token 会显著下降（因为 prompt 从数千字缩到 ~20 行）。后台 side-query 的输出 token 也归零。多轮对比即可看到差异。\n\n## 下一步\n\n- [MOM 混合模型](./mom-mixed-models) — 节约模式下 MOM 如何运行\n- [模型选择与切换](./model-selection) — `/poor` 命令的简述与模型降级\n- [查看消耗](./cost-usage) — `/cost` 监控节约效果\n- [记忆系统](./memory-system) — Poor/SA 对记忆的影响\n"
-    },
-    "docs/guide/assistant-proactive": {
-      "frontmatter": {
-        "title": "Kairos 与自动助手",
-        "description": "Saluzi 的自动助手功能：/assistant 激活 Kairos 面板与守护进程、/proactive 自治模式、/summary 会话摘要，让 AI 从被动应答变为主动协作。",
-        "keywords": [
-          "assistant",
-          "proactive",
-          "Kairos",
-          "自动助手",
-          "自治模式",
-          "daemon"
-        ]
-      },
-      "content": "\n## 自动助手概览\n\nSaluzi 的自动助手功能让 AI 从\"被动应答\"升级为\"主动协作\"，包含以下能力：\n\n| 功能 | 命令 | 说明 |\n|------|------|------|\n| 助手面板 | `/assistant` | 激活 Kairos 面板与守护进程 |\n| 自治模式 | `/proactive` | 切换自治模式，AI 可主动执行低风险操作 |\n| 会话摘要 | `/summary` | 手动提取当前会话记忆 |\n| 简报 | `/brief` | Kairos 定时简报 |\n\n## /assistant 助手面板\n\n```\n> /assistant\n```\n\n首次运行时，`/assistant` 会：\n1. 激活 Kairos 模式（设置 `kairosActive = true`）\n2. 显示助手面板\n3. 若未检测到已配置的守护进程，启动**安装向导**（安装 assistant daemon 到项目目录）\n\n后续调用切换面板可见性。\n\n助手面板激活后，AI 会基于当前上下文主动建议下一步操作、潜在风险、可优化的代码点。\n\n## /proactive 自治模式\n\n```\n> /proactive\n```\n\n切换自治模式（默认关闭，二元开关）。开启后：\n\n- AI 通过定时 tick 主动检查项目状态\n- 可自动执行**低风险**操作（如读文件、运行测试）\n- 中高风险操作仍需确认（如写文件、提交代码）\n\n适用场景：\n\n- 长时间监控项目（如等 CI、看日志）\n- 自动化日常维护（如依赖更新、lint 修复）\n- 持续重构与优化\n\n## /summary 会话摘要\n\n```\n> /summary\n```\n\n手动触发会话记忆提取——将当前会话的关键决策、代码改动、上下文要点提取为结构化摘要。\n\n## Kairos 守护进程\n\nKairos 是 Saluzi 的后台守护进程系统，提供：\n\n- **定时简报**：定期生成项目状态摘要\n- **PR 订阅**：通过 GitHub webhook 监控 PR 事件（`/subscribe-pr`）\n- **定时任务**：通过 cron 调度器执行定期工作\n- **推送通知**：将事件通知发送到终端外部\n\nKairos 功能需要通过 entitlement 验证（订阅/授权），且需首次调用 `/assistant` 手动激活。\n\n## 与普通模式的区别\n\n| 普通模式 | 自动助手模式 |\n|---------|------------|\n| 用户问，AI 答 | AI 主动建议 |\n| 单轮交互 | 持续监控 |\n| 等待指令 | 主动执行低风险 |\n\n## 风险与控制\n\n自治模式有风险，建议：\n\n- 用 `/permissions` 限制可自动执行的工具\n- 定期查看 `/cost` 监控消耗\n- 重要操作前关闭 `/proactive`\n"
-    },
-    "docs/guide/conversation-basics": {
-      "frontmatter": {
-        "title": "对话基础 - 如何与 Saluzi 交互",
-        "description": "从第一次提问到多轮对话、流式输出、上下文压缩与导出恢复，掌握 Saluzi 对话的核心使用方式。",
-        "keywords": ""
-      },
-      "content": "\n## 开始对话\n\n直接输入需求即可。例如：\n\n```\n> 帮我看看这个项目的目录结构\n```\n\nSaluzi 会调用工具（读文件、搜索代码）探索代码后给出回答。\n\n## 多轮对话\n\n- **追加需求**：直接继续输入，Saluzi 记得前文\n- **纠正理解**：如果 AI 理解错了，直接说\"不对，我要的是 X\"\n- **切换话题**：可以随时切换，但建议用 `/clear` 清理后再切换大话题\n\n## 流式输出\n\n- AI 输出是实时的，你可以看到逐字生成\n- 按 `Esc` 打断当前输出\n- 打断后可以补充指令或换方向\n\n## 对话太长时\n\n长对话会消耗 token，Saluzi 提供几个管理工具：\n\n| 命令 | 用途 |\n|------|------|\n| `/context` | 查看当前 token 占用 |\n| `/compact` | 压缩对话历史（保留要点，丢弃冗余） |\n| `/clear` | 重置会话（清空所有历史） |\n| `/summary` | 生成当前会话摘要 |\n\n> **Tip** 当 `/context` 显示超过 80% 时，建议执行 `/compact` 压缩上下文。\n\n## 导出与恢复\n\n| 命令 | 用途 |\n|------|------|\n| `/export` | 导出当前对话为 markdown |\n| `/resume` | 恢复历史会话（列出可选） |\n| `/rewind` | 回退到某一步（可回到之前的任意消息） |\n| `/session` | 管理多个会话 |\n\n## 实用技巧\n\n### 引用文件\n\n直接在消息里写文件路径，Saluzi 会自动读取：\n\n```\n> 改一下 app.tsx 里的样式\n```\n\nAI 会先读取文件内容再进行修改。\n\n### 引用命令输出\n\n用 `!` 前缀运行命令，输出直接进对话：\n\n```\n> !npm test\n```\n\nAI 看到测试输出后可以帮你修失败的测试。\n\n### 拖入文件\n\n终端支持拖入文件路径（取决于终端模拟器），路径会自动粘贴到输入框。\n\n## 下一步\n\n- [上下文管理](./context-tips) — 让 AI 更好理解你的项目\n- [新手入门](./getting-started) — 安装与首次登录\n- [模型选择](./model-selection) — 切换 Max/Pro/Std\n- [查看消耗](./cost-usage) — `/cost` 与 `/stats` 详解\n"
-    },
-    "docs/guide/oms-workflow": {
-      "frontmatter": {
-        "title": "OMS 工作流 - 多角色编排与自动化任务系统",
-        "description": "OMS（Orchestra Management System）工作流命令系列：autopilot、ralplan、ralph、team、clarify、autoresearch、ultrawork、goal、orchestra、define，基于 DAG 调度与多角色 agent 协同执行复杂任务。",
-        "keywords": [
-          "OMS",
-          "工作流",
-          "autopilot",
-          "orchestra",
-          "ralph",
-          "自动化",
-          "编排",
-          "DAG"
-        ]
-      },
-      "content": "\n## 什么是 OMS\n\nOMS（Orchestra Management System）是 Saluzi 的高级任务编排系统。它将复杂任务分解为多个阶段（stage），每个阶段由专属角色的 agent 执行，通过 DAG（有向无环图）调度依赖关系，支持并行执行、质量门禁、失败重试与多轮迭代。\n\n## OMS 命令一览\n\n| 命令 | 用途 | 定位 |\n|------|------|------|\n| `/oms` | 智能路由：根据自然语言自动选择最佳工作流 | 入口 |\n| `/oms-autopilot` | 全自动 6 阶段流水线：需求→规划→实现→QA→验证→报告 | 全链路 |\n| `/oms-ralplan` | 共识规划：Planner→Architect→Critic 三轮审议 | 规划 |\n| `/oms-ralph` | PRD 驱动的持久循环：逐个用户故事实现并验证 | 执行 |\n| `/oms-team` | N 并行 worker：任务分解→并行实现→集成验证 | 并行执行 |\n| `/oms-clarify` | 苏格拉底式深度访谈：通过问答降低需求模糊度 | 需求澄清 |\n| `/oms-autoresearch` | 评估器驱动的迭代改进：实验→评估→决策→迭代 | 研究 |\n| `/oms-ultrawork` | 3 层并行执行：按复杂度路由到 std/pro/max 模型 | 轻量并行 |\n| `/oms-goal` | 多目标工作流：Oracle 门控 + 角色分工执行 | 目标管理 |\n| `/oms-orchestra` | 运行自定义 YAML 工作流 | 自定义 |\n| `/oms-define` | 定义自定义 agent 或工作流（生成 YAML） | 定义工具 |\n\n## Prompt 模式与 Program 模式\n\n多数 OMS 工作流支持两种执行模式：\n\n### Program 模式（默认）\n\nWorkflowEngine 直接执行 DAG——创建 Orchestrator，加载 22 种内置 agent 角色，按拓扑序调度各阶段，管理 worker 并发。无需 LLM 参与调度，速度快、确定性强。\n\n```\n> /oms-autopilot 实现用户登录功能\n```\n\nProgram 模式失败时会自动降级到 Prompt 模式重试。\n\n### Prompt 模式（`--prompt`）\n\nLLM 作为编排层，通过 Agent 工具逐阶段派生子 agent 执行。更灵活（可适应异常情况），但速度较慢。\n\n```\n> /oms-autopilot --prompt 实现用户登录功能\n```\n\n适用于需要 LLM 判断力的场景（如需求模糊、需动态调整执行路径）。\n\n### 仅 Prompt 模式的工作流\n\n以下工作流只支持 Prompt 模式：\n\n| 工作流 | 原因 |\n|--------|------|\n| `/oms-clarify` | 苏格拉底式访谈依赖 AskUserQuestion 多轮对话，Program 模式无法支持 |\n| `/oms-goal` | Oracle 门控 + 多目标状态管理需要 LLM 判断 |\n| `/oms`（路由器） | 纯分类分发，无 DAG 执行 |\n| `/oms-define` | 纯 YAML 生成，无 DAG 执行 |\n\n## 典型用法：组合使用 /oms-define 与 /oms-orchestra\n\n除了内置工作流，OMS 支持定义和运行**自定义工作流**。\n\n### 第一步：定义自定义 agent 或工作流\n\n`/oms-define` 根据自然语言描述生成 YAML 定义文件：\n\n```\n> /oms-define 我需要一个安全审计 agent，只读代码，用 max 模型\n```\n\nSaluzi 会在 `.orchestra/agents/` 下生成 YAML：\n\n```yaml\nname: security-auditor\nrole: reviewer\ndescription: \"Security-focused code review.\"\nmodel: max\ntools: [Read, Glob, Grep]\ndisallowed_tools: [Write, Edit, Bash]\n```\n\n定义自定义工作流：\n\n```\n> /oms-define 创建一个代码审查工作流，先探索、再审查、再验证\n```\n\n生成 `.orchestra/workflows/code-review.yaml`：\n\n```yaml\nname: code-review\ndescription: \"Multi-stage code review\"\nstages:\n  explore:\n    agent: explorer\n    workers: 3\n  review:\n    agent: reviewer\n    depends_on: [explore]\n  verify:\n    agent: verifier\n    depends_on: [review]\n    gate: true\n    on_failure: retry\n    max_retries: 2\n```\n\n### 第二步：运行自定义工作流\n\n```\n> /oms-orchestra code-review \"检查最近提交的认证模块改动\"\n```\n\n`/oms-orchestra` 加载 `.orchestra/workflows/` 下的 YAML 定义，构建 DAG 并按拓扑序执行各阶段。\n\n## 各工作流 DAG 详解\n\n每个内置工作流都是一个 DAG（有向无环图）。阶段之间通过 `depends_on` 声明依赖，引擎按拓扑序调度，无依赖的阶段可并行执行。\n\n### /oms-autopilot — 全自动 6 阶段流水线\n\n```\nexpansion → planning → execution → qa → ┬─ validation-functional ─┐\n                                        ├─ validation-security  ──┼→ cleanup\n                                        └─ validation-quality  ───┘\n```\n\n| 阶段 | Agent | 说明 |\n|------|-------|------|\n| expansion | Analyst | 将想法转为技术规格（需求、架构、风险） |\n| planning | Planner | 创建实现计划（任务分解、并行策略、测试方案） |\n| execution | Executor | 按计划并行实现（自动/标准/高复杂度三级路由） |\n| qa | Verifier [gate] | build + lint + test 循环，最多重试 5 次 |\n| validation-* | 3 个并行 reviewer [gate] | 功能验证、安全审查、代码质量审查 |\n| cleanup | Writer | 生成最终报告 |\n\n特点：如果已存在 ralplan 计划（`.oms/plans/ralplan-*.md`），自动跳过 expansion 和 planning，直接从 execution 开始。\n\n### /oms-ralplan — 共识规划\n\n```\nplan → architect_review → critic_review → revision\n                          ↑                      ↓ (ITERATE)\n                          └── 重新执行整个 DAG ──┘ (最多 5 轮)\n```\n\n| 阶段 | Agent | 说明 |\n|------|-------|------|\n| plan | Planner | RALPLAN-DR 结构化审议（原则→驱动因素→选项→推荐） |\n| architect_review | Architect | 反方论证、权衡分析、风险评级 |\n| critic_review | Critic [gate] | 9 维度评分，输出 APPROVE / ITERATE / REJECT |\n| revision | Planner | 逐条回应 Critic 问题，更新计划 |\n\n特点：Critic 输出 ITERATE 时，引擎重新执行整个 DAG（最多 5 轮）。APPROVE 后提示选择执行路径（team 或 ralph）。支持 `--interactive` 模式在关键节点暂停确认。\n\n### /oms-ralph — PRD 驱动的持久循环\n\n```\nanalyze → implement [loop ≤50] → verify [gate] → review [gate, retry ≤10] → deslop → regression_verify [gate, retry ≤3] → debug_fix [retry ≤3]\n```\n\n| 阶段 | Agent | 说明 |\n|------|-------|------|\n| analyze | Analyst | 生成 PRD（用户故事 + 验收标准） |\n| implement | Executor | 逐个实现用户故事，循环直到所有故事通过 |\n| verify | Verifier [gate] | 全量重新验证所有故事 |\n| review | CodeSimplifier [gate] | 代码审查，最多重试 10 次 |\n| deslop | CodeSimplifier | 去除不必要的复杂度 |\n| regression_verify | Verifier [gate] | deslop 后回归测试 |\n| debug_fix | Debugger | 诊断修复剩余问题 |\n\n### /oms-team — N 并行 worker\n\n```\nplan → prd → exec (N workers) → verify [gate] → fix [retry ≤3]\n                                     ↑              ↓\n                                     └──────────────┘ (loop until PASS)\n```\n\n| 阶段 | Agent | 说明 |\n|------|-------|------|\n| plan | Planner | 将任务分解为 N 个独立子任务 |\n| prd | Analyst | 为每个子任务定义验收标准（任务 >5 个子任务时） |\n| exec | Executor | N 个 worker 并行实现（N>20 自动启用 Ant-Colony 模式） |\n| verify | Verifier [gate] | 验证所有子任务 + 集成检查 |\n| fix | Debugger | 诊断修复失败项，最多 3 轮 |\n\n### /oms-clarify — 苏格拉底式深度访谈（交互式）\n\n```\nexplore → interview [loop ≤20] → ┬─ challenge-contrarian (模糊度>0.4) ─┐\n                                  ├─ challenge-simplifier (模糊度>0.3) ─┼→ crystallize → bridge\n                                  └─ challenge-ontologist (模糊度>0.5) ─┘\n```\n\n| 阶段 | Agent | 说明 |\n|------|-------|------|\n| explore | Explorer | 检测项目类型（brownfield/greenfield），映射代码区域 |\n| interview | Analyst | 逐轮提问，每轮计算模糊度评分（目标/约束/标准/上下文） |\n| challenge-* | 3 个条件 agent | 反方论证、简化探测、本体论重构（按模糊度阈值激活） |\n| crystallize | Writer | 综合所有分析，生成规格文档 |\n| bridge | Planner | 推荐执行模式并跳转 |\n\n特点：模糊度降至 ≤20% 自动进入下一阶段。支持 `--quick`（阈值 30%，5 轮）和 `--deep`（阈值 10%，30 轮）。\n\n### /oms-autoresearch — 评估器驱动的迭代改进\n\n```\nconfirm-mission → initialize-run → experiment → evaluate [gate] → decide → iterate [loop ≤50] → finalize\n                                                                          ↑          ↓ (CONTINUE/PIVOT)\n                                                                          └──────────┘\n```\n\n特点：通过外部评估器（如测试套件、benchmark）量化每轮改进，决策引擎输出 CONTINUE / PIVOT / COMPLETE / ABORT。\n\n### /oms-ultrawork — 3 层并行执行\n\n```\nground → classify → ┬─ execute-simple   (LOW, std 模型) ─┐\n                    ├─ execute-standard  (MED, pro 模型) ─┼→ verify [gate] → report\n                    └─ execute-complex   (HIGH, max 模型) ─┘\n```\n\n特点：按复杂度将子任务路由到不同模型层级，独立任务并行执行。\n\n### /oms-goal — 多目标工作流\n\nOracle 门控 + 结构化 intake + 角色分工执行（Scout/Worker/Judge），通过文件系统持久化状态（`.oms/ultragoal/`），支持中断恢复。\n\n## 3 阶段流水线：ralplan → autopilot\n\n工作流之间可以串联。典型的全链路开发流程：\n\n```\n1. /oms-ralplan \"实现用户认证模块\"     → 生成共识计划\n2. Critic APPROVE 后选择执行路径       → team 或 ralph\n3. 执行完毕 → 验证通过 → 完成\n```\n\n`/oms-autopilot` 检测到已有的 ralplan 计划时，自动跳过 expansion + planning，直接从 execution 阶段开始。\n\n## 与普通对话的区别\n\n| 普通对话 | OMS 工作流 |\n|---------|-----------|\n| 单轮 request-response | 多阶段 DAG 调度 |\n| AI 自主决策 | 角色化分工 + 质量门禁 |\n| 适合小任务 | 适合复杂任务（5+ 文件） |\n| 上下文单一 | 多 agent 并行上下文 |\n\n## 何时用 OMS\n\n- 任务涉及 5+ 文件改动\n- 需要架构设计 + 实现 + 测试多阶段\n- 需要多个专业角色（如安全审查 + 性能优化）\n- 需求不明确，需要深度澄清（clarify）\n- 需要多 worker 并行执行（team）\n- 希望自动化长链任务\n"
+      "content": "\n## 为什么需要 Token 节约模式\n\nSaluzi 默认开启大量「让 AI 更聪明」的后台机制：自动记忆提取、提示建议、会话记忆整合、验证 Agent、相关记忆预取、Agent 摘要……这些机制各自只消耗少量 token，但叠在一起会让每次对话的「隐性开销」相当可观。\n\n当你处于以下场景时，这些开销就是纯浪费：\n\n- **API Key 按量计费**，想压到最低\n- **弱模型 / 小上下文窗口**，每一段 prompt 都很贵\n- **一次性脚本任务**，不需要长期记忆\n- **清晰的单文件修改**，不需要多角度验证\n\n两种节约模式就是为这些场景设计的开关，按「砍多少」分档：\n\n| 模式 | 砍掉的范围 | 工具集 | System Prompt | 适合 |\n|------|-----------|--------|--------------|------|\n| **Poor** | 5 项后台副作用 | 全部保留 | 完整 | 日常开发省 token |\n| **SA** | 全部后台 + 工具收敛 | 仅 4 核心 | ~20 行极简 | 极限省 token / 弱模型 |\n\nSA 是 Poor 的**严格超集**——Poor 关掉的一切，SA 也关掉；SA 还额外砍掉工具和 prompt。两者的关系类似「省电模式」与「飞行模式」。\n\n## Poor 节约模式\n\n### 是什么\n\n`/poor` 切换 Poor 模式。开启后 Saluzi 跳过 5 类后台副作用任务，并对若干辅助模型调用降级。**主对话的工具集与 system prompt 完全不变**——你只是少了一些「后台 whisper」。\n\n### 关闭了什么\n\n| 被关闭的子系统 | 位置 | 原本做什么 |\n|---------------|------|-----------|\n| extract_memories | Stop hook | 每轮结束后从对话提取记忆写入 MEMORY.md |\n| prompt_suggestion | Stop hook | 给用户猜测「下一步可能想问什么」 |\n| autoDream | Stop hook | 后台整合/蒸馏历史记忆 |\n| AgentSummary | 后台 | 给子 Agent 生成摘要 |\n| 验证 Agent | System prompt | 非平凡改动后强制独立审查 |\n\n同时这些**辅助模型调用降级**（不影响主模型）：\n\n| 调用点 | 原模型 | Poor 后 |\n|--------|--------|---------|\n| autoMode critique | MainLoop | SmallFast |\n| permission explainer | MainLoop | SmallFast |\n| universal classifier | MainLoop | DefaultPro |\n| yolo classifier | MainLoop | DefaultPro |\n\n降级意味着权限分类、自动模式批评等「辅助判断」用更便宜的模型跑，质量略降但成本显著下降。主对话模型不变。\n\n### 优势\n\n- **工具集完整**：Read/Edit/Write/Bash/Glob/Grep/WebFetch/Task/MCP……全部照常\n- **System prompt 完整**：项目记忆、CodeGraph、技能、SALUZI.md 仍然注入\n- **可逆且持久**：`/poor` 再按一次关闭；状态写入 `settings.json` 的 `poorMode` 字段，重启后保留\n- **粒度温和**：只砍「后台 whisper」，主循环质量基本无损\n\n### 劣势\n\n- **不再自动积累记忆**：MEMORY.md 不会自动更新，需要手动 `/memory` 编辑\n- **无提示建议**：终端不再显示「你可能想问……」的快捷建议\n- **无验证 Agent**：复杂改动后没有独立审查兜底，需要自己跑测试\n- **辅助分类降级**：权限判断、自动模式批评的精度略降\n\n## SA 极简模式\n\n### 是什么\n\n`/sa` 切换 SA 模式（极简风格 minimal harness）。开启后 Saluzi 收敛到「最小可用 harness」：\n\n- **System prompt 收缩到 ~20 行**：只有角色定义 + 4 个工具说明 + 基本准则 + cwd + 日期。没有动态段落、没有项目记忆、没有 CodeGraph、没有 MCP 说明、没有会话指导。\n- **工具收敛到 4 个核心**：Read / Edit / Write / Bash。其余工具（Glob、Grep、WebFetch、Task、TodoWrite、MCP、Skill……）全部移除。\n- **所有后台副作用归零**：Poor 关掉的 5 项 + 会话记忆 + 相关记忆预取，全部跳过。\n\n这是「把 Saluzi 当成一个极简的 Read/Edit/Write/Bash 编码助手」的开关——类似极简 harness 的体验。\n\n### SA 的 System Prompt 长什么样\n\n完整内容就这些：\n\n```\nYou are an expert coding assistant operating inside Saluzi, a coding agent harness.\nYou help users by reading files, executing commands, editing code, and writing new files.\n\nAvailable tools:\n- Read: Read file contents from the filesystem\n- Edit: Make targeted edits to existing files\n- Write: Create new files or overwrite existing files\n- Bash: Execute shell commands\n\nGuidelines:\n- Be concise in your responses\n- Show file paths clearly when working with files\n- Use file_path:line_number format when referencing code locations\n- Do not use a colon before tool calls\n- Ask the user before making significant architectural decisions\n\nCurrent working directory: <cwd>\nDate: <date>\n```\n\n对比默认 prompt 的数千字（项目记忆 + CodeGraph + 技能 + 会话指导 + 工具说明 + 安全规则……），SA prompt 几乎是零开销。\n\n### 关闭了什么\n\nSA 关闭 = Poor 的全部 + 以下额外项：\n\n| 额外关闭项 | 位置 | 原本做什么 |\n|-----------|------|-----------|\n| 会话记忆提取 | sessionMemory | 跨会话蒸馏项目级记忆 |\n| 相关记忆预取 | attachments | 每轮用户消息后 side-query 检索相关记忆 |\n| 全部工具（除 4 核心） | tools | Glob/Grep/Task/WebFetch/MCP/Skill 等 |\n| 完整 system prompt | prompts | 替换为 20 行极简版 |\n\n### 优势\n\n- **极限省 token**：prompt 从数千字降到 ~20 行，每轮省下大量输入 token\n- **弱模型友好**：小上下文窗口 / 弱模型不会被巨型 prompt 挤占空间\n- **响应快**：没有后台 side-query 拖慢首字节\n- **行为可预测**：AI 只有 4 个工具，不会偷偷跑 WebFetch / Task / MCP，调试简单\n- **可逆且持久**：`/sa` 再按一次关闭；状态写入 `settings.json` 的 `saMode` 字段\n\n### 劣势\n\n- **没有 Glob/Grep**：AI 找文件只能用 `Bash(ls/find)` + `Read`，搜索效率低\n- **没有 Task/TodoWrite**：无法拆分多步任务、不能 spawn 子 Agent\n- **没有 WebFetch/WebSearch**：不能查文档、不能上网\n- **没有 MCP/Skill**：所有 MCP 服务器工具、自定义技能全部不可用\n- **没有项目记忆**：SALUZI.md、MEMORY.md、CodeGraph 知识都不注入，AI 对项目「无记忆」\n- **没有验证 Agent**：同 Poor\n- **AI 不知道自己的完整能力**：极简 prompt 不说明权限模式、安全规则、提交规范等，复杂工作流需要你手动提示\n\n> 简言之：SA 模式适合「我就让 AI 改这一个文件」「跑个脚本看看」这类窄任务，不适合复杂架构重构或需要项目上下文的工作。\n\n## 两种模式的完整对比\n\n| 维度 | 默认 | Poor | SA |\n|------|------|------|-----|\n| System prompt | 数千字（完整动态） | 数千字（完整动态） | ~20 行（极简） |\n| 工具集 | 全部 | 全部 | 4 核心（Read/Edit/Write/Bash） |\n| extract_memories | ✅ | ❌ | ❌ |\n| prompt_suggestion | ✅ | ❌ | ❌ |\n| autoDream | ✅ | ❌ | ❌ |\n| AgentSummary | ✅ | ❌ | ❌ |\n| 验证 Agent | ✅ | ❌ | ❌ |\n| 会话记忆提取 | ✅ | ✅ | ❌ |\n| 相关记忆预取 | ✅ | ✅ | ❌ |\n| 项目记忆注入 (SALUZI.md) | ✅ | ✅ | ❌ |\n| CodeGraph | ✅ | ✅ | ❌ |\n| MCP 工具 | ✅ | ✅ | ❌ |\n| Skill 工具 | ✅ | ✅ | ❌ |\n| Glob/Grep/WebFetch/Task | ✅ | ✅ | ❌ |\n| 辅助分类模型 | MainLoop | Pro/SmallFast | Pro/SmallFast |\n| 主对话模型 | 不变 | 不变 | 不变 |\n| 输入 token / 轮 | 基准 | 略低（少后台 side-query） | 显著低（prompt 极小） |\n| 适合场景 | 日常全功能 | 日常省 token | 极限省 / 弱模型 / 窄任务 |\n\n## 与其他功能的兼容性\n\n这是最关键的部分——开了节约模式后，你常用的那些 Saluzi 特色还能不能用。\n\n### MOM 混合模型\n\n| 模式 | 兼容性 | 说明 |\n|------|--------|------|\n| Poor | ✅ 完全兼容 | Poor 不触碰 MOM 配置，顾问与主机按 `/mom` 设置正常运行 |\n| SA | ⚠️ 受限兼容 | MOM 仍可运行，但**主机只有 4 个工具**（Read/Edit/Write/Bash）；顾问本就是 text-only 不受影响 |\n\n> 如果在 SA 模式下用 mom-stair，弱模型顾问（text-only）正常工作；升级到主机后主机也只能用 4 工具执行——不能 Glob/Grep/WebFetch。建议 SA + MOM 时把主机任务限定在文件读写 + 命令执行。\n\n### CodeGraph 代码智能\n\n| 模式 | 兼容性 | 说明 |\n|------|--------|------|\n| Poor | ✅ 完全兼容 | CodeGraph 工具与 prompt 段落照常注入 |\n| SA | ❌ 不可用 | 工具被收敛到 4 核心（无 CodeGraph 工具），prompt 也不含 CodeGraph 段落 |\n\n### 记忆系统 (Memory V2 / SALUZI.md)\n\n| 模式 | 兼容性 | 说明 |\n|------|--------|------|\n| Poor | ⚠️ 只读不写 | 已有记忆仍注入 prompt；但 extract_memories/autoDream 关闭，不再自动积累新记忆 |\n| SA | ❌ 完全隔离 | 既不注入（极简 prompt 无记忆段），也不提取（session memory 关闭） |\n\n### 验证 Agent (Verification Agent)\n\n| 模式 | 兼容性 |\n|------|--------|\n| Poor | ❌ 跳过 |\n| SA | ❌ 跳过 |\n\n两种模式都跳过验证 Agent。需要独立审查时请关闭节约模式后再跑，或手动 spawn 子 Agent（SA 模式下无 Task 工具，需先关 SA）。\n\n### Plan 模式 / Sandbox / Hooks\n\n| 模式 | Plan | Sandbox | Hooks |\n|------|------|---------|-------|\n| Poor | ✅ | ✅ | ✅ |\n| SA | ✅ | ✅ | ✅ |\n\n权限模式、沙箱、hooks 都是工具执行层机制，与节约模式正交，完全不受影响。\n\n### MCP 服务器 / Skill\n\n| 模式 | MCP | Skill |\n|------|-----|-------|\n| Poor | ✅ | ✅ |\n| SA | ❌ 工具被移除 | ❌ 工具被移除 |\n\nSA 模式下 MCP 服务器仍可连接（连接层不变），但 MCP 提供的工具不在 4 核心之列，不会被注入工具列表。\n\n### Auto Mode (/auto)\n\n| 模式 | 兼容性 | 说明 |\n|------|--------|------|\n| Poor | ⚠️ 降级 | autoMode 仍运行，但 critique 步骤用 SmallFast 模型 |\n| SA | ⚠️ 降级 | 同 Poor；且主机工具受限 |\n\n## 权限模式与安全风险\n\n> 用户最关心的问题：**开了节约模式，AI 会不会偷偷执行 `rm -rf /`、`drop database` 这类删库命令？**\n>\n> 简短回答：**节约模式本身不改变权限策略，不会让危险命令「更容易跑」**。真正的风险来自你选的**权限模式**（`default` / `acceptEdits` / `bypassPermissions` / `auto`），而不是 Poor/SA。但 Poor/SA 会把权限分类器降级到更便宜的模型，在 `bypassPermissions`/`auto` 模式下**理论上**误判概率略升。下面逐层拆解。\n\n### 权限模式与节约模式正交\n\n权限模式由 `/permissions` 或 `settings.json` 的 `permissions.defaultMode` 控制，**与 Poor/SA 完全独立**。开 Poor 或 SA 不会切换你的权限模式：\n\n| 权限模式 | Bash 危险命令会怎样 | Poor/SA 影响 |\n|---------|---------------------|-------------|\n| `default` | 每条命令弹确认，`rm -rf` 类必问你 | 无——该问还是问 |\n| `acceptEdits` | 只自动放行文件编辑，**Bash 仍逐条问** | 无——Bash 仍问 |\n| `plan` | 只读，不能执行任何写操作 | 无——根本跑不了 |\n| `bypassPermissions` | 分类器自动判断，不问你 | ⚠️ 分类器降级（见下） |\n| `auto` | autoMode 分类器自动判断 | ⚠️ 分类器降级（见下） |\n\n**结论**：在 `default` / `acceptEdits` / `plan` 这三种模式下，无论开不开 Poor/SA，危险命令都必须经过你手动确认——**不存在「开了 SA 就自动删库」的情况**。\n\n### SA 模式仍执行 deny 规则\n\nSA 模式收敛工具集时调用的是 `filterToolsByDenyRules`——也就是说你在 `settings.json` 里配的 `permissions.deny` 规则**在 SA 模式下照常生效**：\n\n```json\n{\n  \"permissions\": {\n    \"deny\": [\n      \"Bash(rm -rf:*)\",\n      \"Bash(rm -rf /*:*)\",\n      \"Bash(drop database:*)\",\n      \"Bash(git push --force:*)\",\n      \"Bash(:(){ :|:& };:)\",\n      \"Bash(mkfs*:*)\"\n    ]\n  }\n}\n```\n\n这些规则会在工具列表阶段就**直接屏蔽**匹配的命令——AI 根本看不到这些工具能跑这类命令，分类器也不会被调用。这是比分类器更硬的防线，且**不受 Poor/SA 影响**。\n\n> 强烈建议：无论用不用节约模式，都把 `rm -rf /`、`drop database`、`mkfs`、fork 炸弹等不可逆命令写进 `deny`。这是「物理隔离」级别的一刀切。\n\n### 分类器降级：风险有多大\n\n在 `bypassPermissions` 或 `auto` 模式下，命令是否自动放行由**分类器**（yoloClassifier / universalClassifier）决定。Saluzi 的分类器 prompt 明确把以下列为 **Irreversible Local Destruction（不可逆本地破坏）**：\n\n- `rm -rf` 递归强制删除非平凡路径\n- `Remove-Item -Recurse -Force`（PowerShell 等价物）\n- `> file` 截断已有文件为空\n- `drop database` 删库\n- `git push --force`（视上下文）\n\nPoor/SA 模式下分类器模型降级：\n\n| 模式 | 分类器模型 | 影响 |\n|------|-----------|------|\n| 默认 | MainLoop（如 Max/Pro 主模型） | 精度最高 |\n| Poor/SA | DefaultPro | 略低，但仍是 Pro 级模型 |\n\n**关键点**：\n\n- 分类器**仍然运行**——Poor/SA 没有关闭分类器，只是让它用更便宜的模型跑。\n- Pro 级模型对 `rm -rf /` 这种明显的破坏性命令识别能力依然很强——这不是「盲放」。\n- 降级影响的是**边界模糊**的命令（如 `rm -rf ./build` 这种有歧义的）的判断精度，不是放行 `rm -rf /`。\n\n**所以「删库」风险的真实情况**：\n\n1. `default` / `acceptEdits` / `plan` 模式：**零风险**，必须你确认。\n2. `bypassPermissions` / `auto` + 默认：**低风险**，分类器（MainLoop）会拦。\n3. `bypassPermissions` / `auto` + Poor/SA：**略升的边界风险**，分类器（Pro）对明显破坏命令仍拦，但对模糊命令误判概率略高。\n4. 任何模式 + 配了 `deny` 规则：**零风险**，物理屏蔽。\n\n### SA 模式的特殊风险面\n\nSA 模式只保留 4 个工具（Read/Edit/Write/Bash），这反而**缩小**了攻击面：\n\n- **没有 WebFetch/WebSearch**：AI 不能下载并执行远程脚本。\n- **没有 Task**：不能 spawn 子 Agent 绕过主循环审查。\n- **没有 MCP 工具**：外部 MCP 服务器不能注入未审查的工具。\n- **没有 Skill**：自定义技能不会被执行。\n\n但 **Bash 仍在**——这是 SA 模式下唯一的「能干坏事」的入口。只要 Bash 的权限策略到位（`default` 模式或 `deny` 规则），SA 模式的整体风险面比默认模式**更小**，不是更大。\n\n### 安全使用建议\n\n| 建议 | 原因 |\n|------|------|\n| 默认用 `default` 或 `acceptEdits` 权限模式 | Bash 逐条确认，物理安全 |\n| 在 `settings.json` 配 `permissions.deny` 屏蔽 `rm -rf /`、`drop database`、`mkfs`、fork 炸弹 | 一刀切物理隔离，不受任何模式影响 |\n| 开启沙箱（`sandbox.enabled: true`）| 限制写入路径与网络访问，`rm -rf /` 直接失败 |\n| 避免 `bypassPermissions` + Poor/SA 组合 | 分类器降级 + 不问你 = 信任分类器，边界命令风险略升 |\n| SA 模式下尤其盯紧 Bash 输出 | 没有验证 Agent 兜底，需要你自己看命令 |\n| 用 `/permissions` 临时切 `plan` 模式做危险探索 | 只读，根本不能执行写操作 |\n\n### 一句话总结\n\n**Poor/SA 不会让 Saluzi「更敢删库」**——它们只砍后台副作用和工具数量，不动权限策略与 deny 规则。真正的删库风险来自 `bypassPermissions`/`auto` 权限模式本身；要彻底消除风险，配 `deny` 规则 + 开沙箱 + 用 `default` 模式，这三道防线与节约模式正交，同时开启完全安全。\n\n## 如何开启 / 关闭\n\n### 命令切换\n\n```\n> /poor        # 切换 Poor 模式（开↔关）\n> /sa          # 切换 SA 模式（开↔关）\n```\n\n输出会确认当前状态，例如：\n\n```\nSA mode ON — minimal prompt, 4 tools (Read/Edit/Write/Bash), all background tasks disabled\n```\n\n### 配置面板\n\n`/config` → 找到 `SA mode (minimal harness)` 与 `poor mode` 开关，`Enter` 切换。\n\n### settings.json\n\n直接编辑 `~/.saluzi-edu/settings.json`：\n\n```json\n{\n  \"poorMode\": true,\n  \"saMode\": true\n}\n```\n\n两个字段都可选，`true` 开启、省略或 `false` 关闭。重启 Saluzi 后生效。\n\n> **不要同时开 Poor 和 SA**。SA 是 Poor 的严格超集，同时开启只是冗余——工具集与 prompt 都按 SA 走，Poor 的标志位不起额外作用。需要极限省 token 就直接开 SA；需要保留全部工具就开 Poor。\n\n## 何时该用哪个\n\n| 你的情况 | 推荐 |\n|---------|------|\n| 日常开发，想省点 token，但还要用 Glob/Grep/MOM/CodeGraph | **Poor** |\n| API Key 按量计费，想压到最低 | **Poor**（日常）或 **SA**（窄任务） |\n| 用弱模型 / 小上下文窗口 | **SA** |\n| 一次性脚本：改一个文件、跑个命令 | **SA** |\n| 复杂架构重构、需要项目记忆与多步任务 | **关闭**（用默认） |\n| 需要 MOM 多顾问交叉验证 | **Poor**（保留工具）或 **关闭** |\n| 调试时想要「AI 不要偷偷干别的」 | **SA** |\n| 长期挂着的会话，不想后台烧 token | **Poor** |\n\n## 节约效果怎么看\n\n开启后用 `/cost` 观察单轮 token：\n\n```\n> /cost\n```\n\n重点看**输入 token**——SA 模式下每轮输入 token 会显著下降（因为 prompt 从数千字缩到 ~20 行）。后台 side-query 的输出 token 也归零。多轮对比即可看到差异。\n\n## 下一步\n\n- [MOM 混合模型](./mom-mixed-models) — 节约模式下 MOM 如何运行\n- [模型选择与切换](./model-selection) — `/poor` 命令的简述与模型降级\n- [查看消耗](./cost-usage) — `/cost` 监控节约效果\n- [记忆系统](./memory-system) — Poor/SA 对记忆的影响\n"
     },
     "docs/guide/memory-system": {
       "frontmatter": {
@@ -3177,37 +3158,6 @@
       },
       "content": "\n## 为什么需要记忆系统\n\n普通的 AI 对话每次都从零开始。Saluzi 的记忆系统让 AI 在跨会话、跨项目之间持续积累关于你的认知：你的角色、你的偏好、你给过的反馈、项目正在做的事、外部系统的入口。\n\n记忆系统完全在本地运行，所有数据存储在 `~/.saluzi-edu/` 下，不会上传到云端。你可以随时查看、编辑、删除任何一条记忆。\n\n## 记忆目录在哪\n\n每个项目独立维护一份记忆，按 git 仓库根目录隔离（同一个仓库的多个 worktree 共享一份记忆）。\n\n默认路径：\n\n```\n~/.saluzi-edu/projects/<sanitized-cwd>/memory/\n```\n\n- Linux / macOS：`~/.saluzi-edu/projects/<sanitized-cwd>/memory/`\n- Windows：`%USERPROFILE%\\.saluzi-edu\\projects\\<sanitized-cwd>\\memory\\`\n- `<sanitized-cwd>` 是当前工作目录路径的安全化形式（特殊字符替换为 `-`）\n\n如果想把记忆放到其他位置（例如加密分区或 NAS），有两种覆盖方式：\n\n- **环境变量**：`SALUZI_COWORK_MEMORY_PATH_OVERRIDE` 指向完整路径\n- **settings.json**：在 `~/.saluzi-edu/settings.json` 或 `<cwd>/.saluzi-edu/settings.local.json` 中设置 `autoMemoryDirectory`（支持 `~/` 展开）\n\n> **Tip** 出于安全考虑，`autoMemoryDirectory` 只接受 user/local/policy 三种来源，projectSettings（提交到仓库的 `.saluzi-edu/settings.json`）中的同名字段会被忽略——避免恶意仓库把记忆目录指向敏感路径。\n\n## 子目录与文件作用\n\n进入你的记忆目录后，会看到以下结构：\n\n```\nmemory/\n├── MEMORY.md              # 入口索引：列出所有记忆条目\n├── persona.md             # 用户画像：从 user 记忆自动合成\n├── memory.db              # SQLite 索引（FTS 全文检索 + confidence 衰减追踪）\n├── .last-governance       # 上次治理运行的时间戳\n├── episodic/              # L1 会话级记忆\n├── feedback/              # L2 方法反馈\n├── reference/             # L2 外部引用\n├── procedural/            # L3 流程性模式（自动从 feedback 提升）\n└── logs/YYYY/MM/DD.md     # 每日工作日志（Kairos 助手模式）\n```\n\n### 入口与索引\n\n| 路径 | 作用 |\n|------|------|\n| `MEMORY.md` | 主索引，按类型分组列出所有记忆条目（名称 + 一句话描述 + 链接）。每次治理后自动重新生成 |\n| `persona.md` | 从所有 `user` 类型记忆合成出的用户画像。AI 每次对话开始时读取，用于调整沟通风格 |\n| `memory.db` | SQLite 数据库，提供全文检索、confidence 衰减追踪、访问计数。删除后会自动重建 |\n| `.last-governance` | JSON 文件，记录上次治理运行的时间，AutoDream 据此判断下次何时触发 |\n\n### 四个层级子目录\n\n记忆按生命周期分四层，对应四个子目录：\n\n| 子目录 | 层级 | 作用 | 命名约定 |\n|--------|------|------|---------|\n| `episodic/` | L1 | 会话级摘要，每个会话一份。值得保留的会自动提升到 L2 | `<日期>_<sessionId>-general.md`、`-error.md`、`-turn_summary.md` |\n| `feedback/` | L2 | 你给过的方法反馈（纠正 + 确认）。**默认写入位置** | `feedback_<主题描述>.md` |\n| `reference/` | L2 | 外部系统入口指针（Linear 项目、Grafana 看板、Slack 频道等） | `reference_<主题描述>.md` |\n| `procedural/` | L3 | 从一组相关 feedback 自动综合出的流程性模式 | `procedural_<模式描述>.md` |\n\n> **Note** 你可能会在根目录看到一些 `feedback_*.md` 散落文件，这是早期版本的遗留格式。新的记忆会按类型进入对应子目录。`/dream` 整合时会清理这些遗留文件。\n\n### 四种记忆类型\n\n每条记忆文件的 frontmatter 中声明 `type` 字段，取值之一：\n\n| 类型 | 写什么 | 触发时机 |\n|------|--------|---------|\n| `user` | 用户角色、技能、偏好、知识背景 | 你透露职业、经验、习惯时 |\n| `feedback` | 你给的方法反馈，**包括纠正和确认**两种 | 你说\"不要 X\"或\"对，就这样做\"时 |\n| `project` | 项目正在做的工作、决策、deadline、责任人 | 你提到进展、计划、阻塞时 |\n| `reference` | 外部系统入口（Linear、Grafana、Slack 等） | 你提到外部资源位置时 |\n\n### 不该写入的内容\n\n以下内容**不会**被记忆系统保存，因为它们可以从其他来源派生：\n\n- 代码模式、架构、文件路径——读代码即可得知\n- git 历史、谁改了什么——`git log` / `git blame` 是权威\n- 调试方案——修复在代码里，上下文在 commit message 里\n- 已在 `SALUZI.md` 中记录的内容\n- 临时任务状态、当前对话上下文\n\n即使你明确说\"记住这周的 PR 列表\"，AI 也会反问\"哪部分是*出乎意料*或*非显然*的\"——只保留那部分。\n\n## 如何写入记忆\n\n### 方式一：对话中自然告诉 AI\n\n最自然的方式。直接说：\n\n```\n> 记住我喜欢用 conventional commits\n> 这是我的偏好：测试失败时先 git stash + rerun，再判断是不是我的改动引起的\n> 我们团队的 pipeline bug 都在 Linear 的 INGEST 项目里跟踪\n```\n\nAI 会自动调用记忆工具，在对应子目录创建一个 frontmatter + markdown 的 `.md` 文件。`feedback` 和 `project` 类型会按\"规则 + **Why:** + **How to apply:**\"结构组织正文。\n\n### 方式二：用 /memory 命令编辑\n\n```\n> /memory\n```\n\n弹出文件选择器，列出所有现有记忆文件 + \"新建\"选项。选择后会用 `$EDITOR`（或 `$VISUAL`）打开该文件编辑。\n\n```\n> /memory health\n```\n\n查看记忆系统的健康报告，输出包含：\n\n- 总条目数、平均 confidence、低 confidence（<0.3）条目数\n- 平均年龄（天）\n- 按类型统计（user / feedback / project / reference）\n- 按层级统计（episodic / semantic / procedural）\n- 容量使用率与容量层级\n- 上次治理周期的衰减、过期、冲突数\n- 上次治理运行时间\n\n### 方式三：直接编辑文件\n\n记忆文件就是普通的 markdown + frontmatter，可以直接用任何编辑器修改：\n\n```markdown\n---\nname: prefers-conventional-commits\ndescription: 用户偏好 conventional commits 格式\ntype: feedback\nconfidence: 0.8\ncreated: 2026-08-10T09:14:04.465Z\nsource: direct-write\n---\n\n提交信息使用 conventional commits 格式（feat / fix / docs / chore / refactor）。\n\n**Why:** 用户在 2026-08-10 明确表示偏好，团队未强制但个人习惯。\n**How to apply:** 调用 /commit 或 /commit-push-pr 时，自动套用该格式。\n```\n\nfrontmatter 关键字段：\n\n| 字段 | 必填 | 作用 |\n|------|------|------|\n| `name` | 是 | 唯一标识，kebab-case |\n| `description` | 是 | 一句话描述，用于检索时判断相关性 |\n| `type` | 是 | `user` / `feedback` / `project` / `reference` 之一 |\n| `confidence` | 否 | 0~1 的置信度，默认 0.5，治理时会衰减 |\n| `created` | 否 | ISO 时间戳，留空自动填 |\n| `source` | 否 | 来源标记（`direct-write` / `extract` / `dream` 等） |\n\n## 如何修改记忆\n\n三种方式都适用：\n\n- **对话中**：说\"更新关于 X 的记忆，改成 Y\"或\"那条关于 conventional commits 的偏好改成包括 scope\"。AI 会打开对应文件并 Edit。\n- **/memory 命令**：选择要修改的文件，在编辑器中改。\n- **直接编辑**：用编辑器打开 `feedback/feedback_xxx.md` 改正文或 frontmatter。\n\n修改后下一次对话即可生效。SQLite 索引会在文件保存后约 1 秒内自动同步。\n\n## 如何删除记忆\n\n- **对话中**：说\"忘记关于 X 的记忆\"或\"删除那条 conventional commits 的偏好\"。AI 会删除对应文件。\n- **/memory 命令**：选择文件后删除（取决于编辑器集成）。\n- **直接删除文件**：`rm feedback/feedback_xxx.md`，索引会自动清理。\n- **清空所有记忆**：删除整个 `memory/` 目录。下次启动 Saluzi 会自动重建空目录与 `MEMORY.md`。\n\n> **Tip** 如果只是想让 AI 在某次对话中\"忽略\"记忆（不删除），直接说\"这次对话忽略记忆\"，AI 会按 `MEMORY.md` 为空的方式工作，不引用、不比较、不提及记忆内容。\n\n## 记忆治理周期\n\n记忆不是只增不减的日志。Saluzi 有一套自动治理机制，保持记忆新鲜、相关、不冲突。\n\n### AutoDream：后台自动整合\n\n默认每 **24 小时** + **5 个新会话**后自动触发一次整合（两个条件都满足才触发）。整合时：\n\n1. 扫描自上次治理以来的所有会话转录\n2. 启动一个 forked subagent，Bash 限制为只读\n3. 提取值得保留的事实、合并重复条目\n4. 修剪过时内容、识别矛盾\n5. 重新生成 `MEMORY.md` 索引\n\nAutoDream 在会话停止的间隙运行，不打断你的工作。完成后会在主对话中显示一条系统消息，告知整合了哪些文件。\n\n### /dream：手动触发整合\n\n```\n> /dream\n```\n\n任何时候想立即整合记忆，可以手动触发。`/dream` 做的事和 AutoDream 一样，但立刻执行。适合以下场景：\n\n- 刚做了大量偏好调整，想立即固化\n- 感觉 AI 的回答\"似是而非\"，怀疑记忆有冲突\n- 即将切换到另一个项目，想先收尾\n- AutoDream 还没到触发阈值，但你想看当前记忆的整理结果\n\n### DecayEngine：confidence 衰减\n\n每条记忆有 `confidence` 字段（0~1）。每次治理周期：\n\n- 长时间未访问的记忆 confidence 衰减\n- 衰减到阈值后标记为 `decayed`\n- 进一步降低到 `expired` 后从索引移除（文件保留以便恢复）\n\n这保证了\"半年前用一次的偏好\"不会永远占据检索顶部。\n\n### ConflictDetector：冲突检测\n\n当两条 `feedback` 记忆相互矛盾时（例如\"我喜欢详细注释\" vs \"不要加注释\"），治理周期会检测到并标记。下次 `/memory health` 报告中会显示 `conflicts: N`，提示你手动解决。\n\n### PromotionEngine：层级提升\n\n治理周期会自动判断哪些记忆值得\"升级\"：\n\n| 提升路径 | 触发条件 | 结果 |\n|---------|---------|------|\n| L1 episodic → L2 semantic | 会话摘要包含值得长期保留的事实 | 提取为 `feedback/` 或 `reference/` 下的主题文件 |\n| L2 feedback → L3 procedural | 多条相关 feedback 形成模式 | 综合为 `procedural/procedural_*.md` 流程文件 |\n\nL3 procedural 记忆是最高层级，代表\"反复出现的工作模式\"，AI 在合适场景会自动调用。\n\n### 容量管理\n\n记忆目录有容量上限（默认按文件数计）。`/memory health` 中的 `Capacity` 行显示：\n\n```\nCapacity: 47/200 (23.5%) [healthy]\n```\n\n容量层级：\n\n- `healthy` — 使用率 < 70%\n- `near-full` — 70% ~ 90%\n- `full` — > 90%，新写入会被治理周期优先修剪\n\n达到 `full` 时，AutoDream 会优先清理最低 confidence、最长未访问、已 expired 的条目。\n\n### /remember：审视与晋升\n\n```\n> /remember\n```\n\n审视所有自动记忆条目，提出晋升建议：哪些应该写入 `SALUZI.md`（项目级共享记忆）、`SALUZI.local.md`（项目级个人记忆）、或共享记忆。同时检测过时、冲突、重复条目。\n\n适合定期执行，把\"经过验证的个人偏好\"沉淀为团队共享规范。\n\n## 治理周期一览\n\n| 机制 | 触发方式 | 频率 | 作用 |\n|------|---------|------|------|\n| AutoDream | 自动（时间 + 会话数双门） | 24h / 5 sessions | 后台整合、提取、修剪 |\n| /dream | 手动 | 按需 | 立即整合 |\n| DecayEngine | 治理周期内自动 | 同 AutoDream | confidence 衰减 |\n| ConflictDetector | 治理周期内自动 | 同 AutoDream | 检测矛盾 |\n| PromotionEngine | 治理周期内自动 | 同 AutoDream | 层级提升 |\n| /memory health | 手动 | 按需 | 查看健康报告 |\n| /remember | 手动 | 按需 | 审视 + 晋升建议 |\n\n## 实用建议\n\n### 定期体检\n\n每周执行一次 `/memory health`，关注：\n\n- 平均 confidence 是否持续下降（说明记忆整体在老化）\n- 低 confidence 条目是否增多\n- 是否有 conflicts\n- 容量层级是否接近 `near-full`\n\n### 主动固化偏好\n\n每次你纠正 AI 后，留意是否被自动写入。如果几天后 `/memory health` 显示该条 confidence 仍低（< 0.3），可以手动编辑文件把 confidence 调到 0.8+，避免被衰减掉。\n\n### 跨项目共享\n\n`user` 和 `feedback` 中跨项目的偏好，可以用 `/remember` 晋升到 `~/.saluzi-edu/SALUZI.md`（用户级，所有项目共享）。项目相关的偏好留在 `memory/` 目录即可。\n\n### 关闭自动记忆\n\n如果不想用自动记忆，在 `~/.saluzi-edu/settings.json` 中设置：\n\n```json\n{\n  \"autoMemoryEnabled\": false\n}\n```\n\n或环境变量 `SALUZI_DISABLE_AUTO_MEMORY=1`。已有的记忆文件不会被删除，但 AI 不再读取也不再写入。\n\n## 下一步\n\n- [上下文管理](./context-tips) — SALUZI.md 项目记忆与 /memory 命令的关系\n- [主目录与 settings.json](./saluzi-home) — `autoMemoryEnabled` 等配置字段\n- [Kairos 与自动助手](./assistant-proactive) — 助手模式下记忆如何驱动主动行为\n"
     },
-    "docs/guide/troubleshooting": {
-      "frontmatter": {
-        "title": "排障 - 诊断安装与调整权限",
-        "description": "使用 /doctor 诊断安装、/help 查命令、/permissions 调整权限、/plan 规划模式。",
-        "keywords": [
-          "doctor",
-          "help",
-          "permissions",
-          "plan",
-          "排障",
-          "诊断",
-          "权限",
-          "规划模式"
-        ]
-      },
-      "content": "\n## 诊断安装\n\n遇到启动异常或功能不符预期时，先运行 `/doctor` 做全面体检：\n\n```\n> /doctor\n```\n\n该命令会依次检查：\n\n- CLI 版本是否为最新\n- Node / Bun 运行环境是否满足\n- 配置文件是否完整\n- 网络连接是否正常\n\n若有异常项，输出会给出具体的修复建议。\n\n## 查命令\n\n不确定某个命令的用法时，用 `/help` 列出所有可用命令：\n\n```\n> /help\n```\n\n查看单个命令的详细用法：\n\n```\n> /help commit\n```\n\n输出包含命令说明、参数列表和使用示例。\n\n## 调整权限\n\nSaluzi 每次调用工具前会请求权限。用 `/permissions` 查看和调整当前权限规则：\n\n```\n> /permissions\n```\n\n权限分三种策略：\n\n| 策略 | 含义 |\n|------|------|\n| Allow | 自动放行，不再询问 |\n| Deny | 直接拒绝，禁止调用 |\n| Ask | 每次弹出确认（默认） |\n\n对常用工具设置 Allow 可以减少交互打断，提升效率。\n\n## 规划模式\n\n面对复杂任务时，用 `/plan` 让 Saluzi 先制定计划再执行：\n\n```\n> /plan 重构用户模块，拆分为独立的 service 层\n```\n\n进入规划模式后，Saluzi 会：\n1. 分析需求并拆解步骤\n2. 列出待执行的操作清单\n3. 确认后再逐步实施\n\n适合在动手前理清思路，避免盲目修改。\n\n## 常见问题\n\n| 问题 | 可能原因 | 解决方法 |\n|------|---------|---------|\n| 登录失败 | Token 过期或网络异常 | 重新运行 `/login`，或检查代理设置 |\n| 工具权限被拒 | 对应工具被设为 Deny | 运行 `/permissions` 将策略改为 Allow |\n| 命令找不到 | 输入拼写有误 | 运行 `/help` 确认命令名称 |\n| 模型不可用 | 账户额度耗尽或区域限制 | 用 `/model` 切换到其他可用模型 |\n\n## 下一步\n\n- [查看与提交代码](./commit-workflow) — diff、commit 与 PR 工作流\n- [主目录与配置](./saluzi-home) — 配置文件位置与字段说明\n- [费用与用量](./cost-usage) — 了解 Token 消耗与费用控制\n- [代码图谱](./codegraph) — 用 CodeGraph 深入理解项目结构\n"
-    },
-    "docs/guide/weixin-login": {
-      "frontmatter": {
-        "title": "微信控制 - 通过微信远程操控 Saluzi",
-        "description": "微信作为 Saluzi 的会话控制渠道：接收微信消息作为指令，回复执行结果到微信，实现远程操控。",
-        "keywords": [
-          "微信控制",
-          "weixin",
-          "远程操控",
-          "WeChat",
-          "消息渠道"
-        ]
-      },
-      "content": "\n## 什么是微信控制\n\n微信控制是 Saluzi 的会话控制渠道之一。启用后，你可以通过微信向 Saluzi 发送消息指令，Saluzi 执行后会通过微信回复结果。这让你无需在终端前，也能远程操控 Saluzi 会话。\n\n微信控制**不是登录手段**——它不负责身份认证，而是在你已登录 Saluzi 后，提供一种远程消息渠道。\n\n## 启用微信控制\n\n### 第一步：扫码绑定\n\n使用 `weixin login` 子命令完成微信绑定：\n\n```bash\nslz weixin login\n```\n\n终端会显示一个二维码，用微信扫码后，微信账号与 Saluzi 绑定。登录凭证保存在 `~/.saluzi-edu/channels/weixin/account.json`。\n\n如需解除绑定：\n\n```bash\nslz weixin login clear\n```\n\n### 第二步：启动带微信渠道的会话\n\n绑定后，启动 Saluzi 时通过 `--channels` 参数接入微信消息：\n\n```bash\nslz --channels plugin:weixin@builtin\n```\n\nSaluzi 会在后台持续监听微信消息。收到消息后，消息会作为对话轮次注入当前会话，AI 处理后可通过微信回复结果。\n\n### 第三步：配对授权\n\n首次有人通过微信向你的 Saluzi 发消息时，系统会返回一个 6 位配对码。在终端中运行：\n\n```bash\nslz weixin access pair <配对码>\n```\n\n配对成功后，该微信用户被加入允许列表，后续消息直接转发到 Saluzi 会话。\n\n## 通过微信操控会话\n\n配对完成后，通过微信发送的消息会被注入 Saluzi 会话。AI 会像处理终端输入一样处理微信消息——读取文件、修改代码、运行命令，然后通过微信回复执行结果。\n\n### 权限审批\n\n当 Saluzi 需要工具调用权限时（例如执行命令、修改文件），审批提示会发送到微信。你可以直接在微信中回复：\n\n- `yes <请求ID>` — 批准\n- `no <请求ID>` — 拒绝\n\n这样即使不在终端前，也能批准或拒绝 Saluzi 的操作请求。\n\n### 文件附件\n\nSaluzi 可以通过微信回复时附带文件（使用绝对路径）。你也可以通过微信发送图片、语音、文件等附件给 Saluzi——语音消息会自动转录为文本。\n\n## 典型场景\n\n- **外出时远程操控**：离开电脑后，通过微信发消息让 Saluzi 继续执行任务\n- **移动审批**：长任务运行时，通过微信批准权限请求，无需守在终端前\n- **移动监控**：随时通过微信查看任务状态或调整指令\n\n## 故障排查\n\n- **二维码不显示**：确认终端支持 UTF-8 与 256 色，尝试 `/theme` 切换主题\n- **扫码超时**：重新运行 `slz weixin login`，二维码有效期约 60 秒\n- **消息不同步**：检查网络连接，确认 Saluzi 进程仍在运行\n- **配对码无效**：确认 6 位码未过期，重新触发消息获取新的配对码\n"
-    },
     "docs/guide/remote-control-acp": {
       "frontmatter": {
         "title": "Remote Control 与 ACP - 让团队共享 Agent",
@@ -3226,22 +3176,76 @@
           "可见域"
         ]
       },
-      "content": "\n## Remote Control Server (RCS)\n\nRCS 是 Saluzi 的自托管远程控制服务器，提供 Web UI 和会话管理。启动后，团队成员通过浏览器访问 Web UI，登录后即可创建会话、查看 worker 状态、与 agent 交互。\n\n## 启动 RCS\n\n```bash\n# 设置 API Key（管理员密码，也是 worker 连接 token）\nexport RCS_API_KEYS=sk-your-key\n\n# 启动（在 Saluzi CLI 中运行）\n> /rcs\n```\n\n也可通过 CLI 子命令直接启动：\n\n```bash\nslz rcs\n```\n\n默认端口 3000，Web UI 在 `http://localhost:3000/code/`。\n\n## RCS Web UI 使用\n\nWeb UI 是团队成员日常使用的控制面板：登录后可创建会话、查看 worker、审批权限、管理团队与环境。下面按首次部署到日常使用的顺序介绍。\n\n### 管理员初始化（首次访问）\n\n第一次打开 Web UI 时，系统没有任何用户。第一个登录的账号会成为系统管理员（role=admin），流程如下：\n\n1. 浏览器打开 `http://localhost:3000/code/`，自动跳转到 Setup 页面\n2. 填写表单：\n   - **API Key**：必须与 RCS 启动时设置的 `RCS_API_KEYS` 中的某个 key 完全一致\n   - **用户名**：登录用，后续不可改\n   - **密码**：至少 8 位\n   - **确认密码**\n3. 提交后第一个用户即成为 admin，进入管理面板\n\n后续访问的用户分两种：\n\n- **自注册**：如果 `RCS_ALLOW_REGISTRATION` 未设为 `false`（默认开放），新访问者可在登录页注册账户（用户名 + 密码）。密码以 argon2id 加密存储，登录有速率限制（5 次失败后锁定 5 分钟）。\n- **邀请制**：将 `RCS_ALLOW_REGISTRATION=false` 后，只有管理员预先创建的账户或通过团队邀请链接加入的用户能登录。\n\n管理员 API Key 拥有系统级权限，可直接访问所有 API（不通过 Web UI 登录流程）。\n\n登录后浏览器会保存 session cookie（`rcs_access`），后续请求自动认证。\n\n### 团队与角色\n\nRCS 用「团队」组织成员、环境和会话。每个登录用户都有一个「个人空间」（无需创建），可被加入一个或多个团队。\n\n**系统级角色**（`users.role`）：\n\n| 角色 | 能力 |\n|------|------|\n| `admin` | 看到所有会话（含无主孤儿）、管理所有团队、转移任意环境；通常由 Setup 流程产生 |\n| 普通用户 | 仅看到自己拥有的、所属团队可见的、显式共享给自己的会话 |\n| `guest` | 不能创建团队；通常对应被降级的账户 |\n\n**团队级角色**（`team_members.role`）：\n\n| 角色 | 团队内能力 |\n|------|-----------|\n| `owner` | 修改团队信息、删除团队、加/减成员、改成员角色、创建/撤销邀请、转移或解绑环境 |\n| `admin` | 加成员、创建/撤销邀请，但不能改 owner/admin 的角色，也不能删团队 |\n| `member` | 只能自退团队，看不到团队级管理按钮 |\n\n团队至少要保留一个 owner — 系统禁止降级或移除最后一个 owner。系统 admin 在任何团队中都视为 owner。\n\n**邀请加入**：团队 owner/admin 可在「团队详情 → 邀请」页面创建邀请链接，链接形如 `/join/<inv_xxx>`，可设置：\n\n- 角色：新成员加入后的角色（仅 `admin` 或 `member`，不能邀请为 owner）\n- 过期时间（默认 24 小时）\n- 最大使用次数（默认 1）\n\n也可以「添加已有用户」：通过用户名或用户 ID 搜索已注册账户，直接加入团队。\n\n### 环境管理\n\n「环境」（environment）是 worker 向 RCS 注册后产生的实体，代表一台正在提供 agent 服务的工作机。每个环境有：\n\n- 拥有者（owner_user_id，可能为空 → 需要认领）\n- 关联团队（可选，关联后团队内成员可见该环境及其会话）\n- worker 类型（slz CLI / ACP agent）、容量、心跳\n\n**环境的归属**：\n\n- 启动 worker 时通过 `--user-id` / `--team-id` 指定 → 直接归属到该用户或团队\n- 未指定且使用共享 API Key → 生成 `claim_token`，进入待认领状态（见下文 claim 机制）\n\n**环境与团队的关联**：\n\n- 在「团队详情 → 环境」页面可把个人环境链接到团队，或把团队环境解绑回个人\n- 环境可在团队之间转移（需要源团队和目标团队的 owner/admin 权限）\n- 转移环境时，该环境下的所有会话归属随之转移到目标团队\n\n### Claim 机制（环境认领）\n\n当 worker 使用共享 API Key 启动、且未指定 `--user-id` / `--team-id` 时，RCS 不会把环境直接归属给任何人，而是生成一个 `claim_token`（形如 `clm_xxxxxxxx`）并打印认领 URL：\n\n```\n/code/claim/clm_xxxxxxxx\n```\n\n**认领流程**：\n\n1. worker 启动后在终端看到认领 URL\n2. 把这个 URL 发给任意已登录用户\n3. 该用户在浏览器打开 URL → 自动调用 `/environments/claim` 接口\n4. 该环境的 `owner_user_id` 写入此用户，`claim_token` 清空\n5. 该环境下已经创建的会话也会一并 backfill 到该用户名下（否则会成为无主孤儿会话）\n\n`claim_token` 有过期时间（`claim_expires_at`），过期后无法认领。已被认领的环境再次访问会返回 409。\n\n这个机制让团队成员用共享 API Key 启动 worker 后，再由具体的人认领，避免环境长期处于无主状态。\n\n### 会话可见域\n\n每个会话有 `visibility` 字段，控制谁能看到它：\n\n| 可见域 | 谁能看到 |\n|--------|---------|\n| `private` | 仅会话的 user owner |\n| `team` | 会话所属团队的所有成员 |\n| `public` | 所有登录用户 |\n\n实际的可见规则综合考虑了 ownership、visibility 和显式共享：\n\n1. 系统 admin 能看到所有会话（含无主孤儿会话）\n2. 用户作为 user owner 拥有的会话\n3. 用户所属团队作为 team owner 拥有、且 visibility 为 `team` 或 `public` 的会话\n4. 通过 `session_shares` 显式共享给该用户的会话（未过期）\n5. 通过 `session_shares` 显式共享给该用户所属团队的会话（未过期）\n6. visibility=`public` 的会话\n7. 无主孤儿会话：仅 admin 可见\n\n**会话转移**：会话 owner（或团队 admin）可把会话从个人空间转到团队（visibility 自动变 `team`），或从团队转回个人（visibility 自动变 `private`）。转移时需要目标是该团队的 owner/admin。\n\n**会话分享**：会话 owner 可生成分享链接，授予指定用户或团队「只读」或「读写」权限，可设置过期时间。被分享者会在自己的会话列表里看到该会话。\n\n### 权限审批\n\nRCS Web UI 在 agent 请求工具调用时弹出审批面板。权限模式（permissionMode）有 6 种，决定 agent 是否需要等待人工确认：\n\n| 模式 | 行为 |\n|------|------|\n| `default` | 每次工具调用都请求确认 |\n| `auto` | agent 自动判断是否需要确认 |\n| `acceptEdits` | 自动接受文件编辑，其他工具仍需确认 |\n| `plan` | 规划模式，仅制定计划不执行 |\n| `dontAsk` | 不询问，直接执行 |\n| `bypassPermissions` | 绕过所有权限检查（仅 sandbox 环境可用，非 root） |\n\n权限模式可在创建会话时指定，也可在会话进行中切换。fallback 顺序：客户端传值 > acp-link 启动时的 `ACP_PERMISSION_MODE` 环境变量。\n\n**三种审批面板**：\n\n- **工具调用审批**：显示工具名、参数和描述，提供 Approve / Reject 按钮\n- **多问题面板**（AskUserQuestion）：agent 一次提多个问题，用户在标签页中切换回答，每题可选预设选项或填写「Other」自定义文本\n- **计划审批**：显示 plan 内容，提供「Yes, auto-accept edits」「Yes, manually approve edits」「No, keep planning」三个选项，选 No 时可附反馈让 agent 重新规划\n\n### Worker 状态\n\nWeb UI 显示所有已连接的 worker（包括 slz CLI worker 和 acp-link agent）：\n\n- **在线状态**：worker 当前是否可接受会话\n- **最大并发**：worker 配置的 `--capacity`\n- **最后活动时间**：最近一次心跳\n\n## RCS 服务器配置\n\n| 环境变量 | 默认 | 说明 |\n|---------|------|------|\n| `RCS_PORT` | 3000 | HTTP 端口 |\n| `RCS_HOST` | 0.0.0.0 | 监听地址 |\n| `RCS_API_KEYS` | — | 逗号分隔的 API Key（管理员权限，也是 worker 连接 token） |\n| `RCS_ALLOW_REGISTRATION` | true | 是否允许开放注册（设为 false 改为邀请制） |\n| `RCS_BASE_URL` | — | 外部访问 URL（反代时设置） |\n| `RCS_DB_PATH` | — | SQLite 数据库路径（默认内存，生产环境建议持久化） |\n| `RCS_WEB_CORS_ORIGINS` | — | Web UI CORS 允许的源（逗号分隔） |\n| `RCS_JWT_EXPIRES_IN` | 3600 | JWT 有效期（秒） |\n| `RCS_DISCONNECT_TIMEOUT` | 300 | 断开连接超时（秒） |\n| `RCS_WS_CLIENT_INACTIVITY_TIMEOUT` | 300 | WebSocket 客户端无活动超时（秒） |\n\n## Worker 接入\n\nWorker 是连接到 RCS 的 Saluzi CLI 实例，执行来自 Web UI 或其他客户端的会话。\n\n### 前置：设置环境变量\n\n**所有 worker 启动方式都需要先设置以下两个环境变量**：\n\n```bash\nexport SALUZI_BRIDGE_BASE_URL=http://rcs-host:3000\nexport SALUZI_BRIDGE_OAUTH_TOKEN=sk-your-key\n```\n\n- `SALUZI_BRIDGE_BASE_URL`：RCS 服务器地址\n- `SALUZI_BRIDGE_OAUTH_TOKEN`：必须与 RCS 启动时设置的 `RCS_API_KEYS` 中的某个 key 一致\n\n两个变量必须**同时设置**才生效。只设置一个会进入\"部分配置\"状态，启动时会提示补全。\n\n可选环境变量（用于归属和团队关联）：\n\n| 环境变量 | 说明 |\n|---------|------|\n| `SALUZI_BRIDGE_USERNAME` | 归属用户名（发送为 `X-Username` 头，RCS 自动认领 env 到该用户） |\n| `SALUZI_BRIDGE_USER_ID` | 归属用户 ID（绕过自动认领，直接绑定到该用户） |\n| `SALUZI_BRIDGE_TEAM_ID` | 关联团队 ID（env 注册到指定团队） |\n| `SALUZI_ENVIRONMENT_KIND` | 设为 `bridge` 标记会话来源为 remote-control |\n| `SALUZI_USE_CCR_V2` | 启用 CCR v2 传输协议 |\n\n如果不设置 `SALUZI_BRIDGE_USERNAME`/`SALUZI_BRIDGE_USER_ID`/`SALUZI_BRIDGE_TEAM_ID`，且 token 是共享的管理员 API Key，RCS 会生成 `claim_token` 并打印认领 URL，worker 终端会显示该 URL 供用户认领（详见上文「Claim 机制」）。\n\n### 启动方式\n\n设置好环境变量后，推荐直接运行：\n\n```bash\nslz rc\n```\n\n`slz rc` 是最简的启动方式，默认配置即可作为 worker 连接到 RCS。它是 `slz remote-control` 的简写，也接受 `slz remote`、`slz sync`、`slz bridge` 作为别名。\n\n其他可选方式：\n\n```bash\n# 交互式会话 + worker（既可本地用，也接受远程请求）\nslz --remote-control\n\n# 普通会话自动连接（设置好环境变量后直接运行）\nslz\n```\n\n### 高级参数\n\n需要调整 worker 行为时，`slz rc` 支持以下参数：\n\n| 参数 | 说明 | 示例 |\n|------|------|------|\n| `--spawn <mode>` | Spawn 模式：`same-dir`、`worktree`、`session` | `--spawn=worktree` |\n| `--capacity <N>` | 最大并发会话数（仅 worktree/session 模式） | `--capacity=5` |\n| `--create-session-in-dir` | 启动时在当前目录预创建会话（默认开启） | `--no-create-session-in-dir` 禁用 |\n| `--session-id <id>` | 恢复指定会话 | `--session-id=abc123` |\n| `--continue` | 恢复最近会话 | — |\n| `--name <name>` | 会话名称（也用于 RCS 显示） | `--name=\"我的会话\"` |\n| `--username <name>` | 归属用户名（对应 `SALUZI_BRIDGE_USERNAME`） | `--username=alice` |\n| `--user-id <id>` | 归属用户 ID（对应 `SALUZI_BRIDGE_USER_ID`） | `--user-id=u-123` |\n| `--team-id <id>` | 关联团队 ID（对应 `SALUZI_BRIDGE_TEAM_ID`） | `--team-id=team-abc` |\n\n### Spawn 模式\n\n| 模式 | 说明 | 适用场景 |\n|------|------|---------|\n| `same-dir`（默认） | 所有会话在同一工作目录创建 | 单项目快速响应 |\n| `worktree` | 每个会话在独立 git worktree 中创建 | 多项目隔离，避免文件冲突 |\n| `session` | 单会话模式（容量固定为 1） | 简单场景，不需要并发 |\n\n## Worker 与 RCS 的关系\n\n```\n┌─────────────────┐\n│   RCS Server    │  ← 运行 slz rcs\n│  (Web UI + API) │\n└────────┬────────┘\n         │ Bridge 协议\n         │\n    ┌────┴────┐\n    │         │\n┌───▼──┐  ┌──▼───┐\n│Worker│  │Worker│  ← slz rc / slz --remote-control / slz\n│  1   │  │  2   │\n└──────┘  └──────┘\n```\n\n- **RCS**：中央服务器，管理会话、用户、权限\n- **Worker**：通过 bridge 协议连接，从 RCS 获取任务，汇报状态\n- **Web UI**：通过浏览器访问 RCS，创建/查看会话\n\n## ACP 协议\n\nACP（Agent Control Protocol）让**外部 agent**（非 slz CLI，如 Claude Code、其他 ACP 兼容 agent）接入 RCS 的会话系统。slz CLI 自身使用 bridge 协议，不走 ACP。\n\n`acp-link` 是 ACP 桥接工具，随 `@saluzi/saluzi-edu` 一起安装，无需单独安装。\n\n### 连接 slz 到 RCS\n\n如果要让 slz CLI 作为 ACP agent 接入 RCS（而非 bridge worker），使用 `acp-link` 桥接：\n\n#### 1. 设置环境变量\n\n```bash\nexport ACP_RCS_URL=http://rcs-host:3000\nexport ACP_RCS_TOKEN=sk-your-key\n```\n\n- `ACP_RCS_URL`：RCS 服务器地址\n- `ACP_RCS_TOKEN`：必须与 RCS 的 `RCS_API_KEYS` 中的某个 key 一致\n\n可选环境变量：\n\n| 环境变量 | 说明 |\n|---------|------|\n| `ACP_RCS_GROUP` | Channel group ID（字母、数字、下划线、连字符） |\n| `ACP_RCS_USERNAME` | 归属用户名（自动认领 env 到该用户） |\n| `ACP_RCS_USER_ID` | 归属用户 ID（绕过自动认领） |\n| `ACP_RCS_TEAM_ID` | 关联团队 ID |\n| `ACP_AUTH_TOKEN` | 本地 WS 认证 token（不设则自动生成） |\n| `ACP_PERMISSION_MODE` | 默认权限模式 |\n\n#### 2. 启动 acp-link\n\n```bash\nacp-link slz -- --acp\n```\n\n`acp-link` 会启动 slz 作为子进程，通过 ACP 协议代理它与 RCS 之间的通信。slz 会出现在 RCS Web UI 的 agent 列表中，可接受会话请求。\n\n`--` 之后是传递给 slz 的参数（`--acp` 让 slz 进入 ACP 兼容模式）。\n\n### 连接 Claude Code 到 RCS\n\n`acp-link` 支持任何遵循 ACP 协议的 agent。Claude Code 通过专用的 ACP 适配包 `@agentclientprotocol/claude-agent-acp` 接入，接入命令是 `acp-link claude-agent-acp`（**不是** `acp-link claude`，因为 Claude Code 本身不直接说 ACP 协议，需要先装适配包）。\n\n#### 1. 安装 claude-agent-acp\n\nClaude Code 的 ACP 适配包需要单独安装：\n\n```bash\nnpm install -g @agentclientprotocol/claude-agent-acp\n```\n\n安装后会注册 `claude-agent-acp` 命令。\n\n#### 2. 设置环境变量\n\n```bash\nexport ACP_RCS_URL=http://rcs-host:3000\nexport ACP_RCS_TOKEN=sk-your-key\n```\n\n#### 3. 启动 acp-link 桥接\n\n```bash\nacp-link claude-agent-acp\n```\n\n`acp-link` 的第一个参数是 agent 的可执行命令名（这里是 `claude-agent-acp`）。`claude-agent-acp` 本身不需要额外参数，因此不需要 `--`。\n\n连接成功后，Claude Code 会作为 ACP agent 出现在 RCS Web UI 中，与 slz agent 并列，团队成员可在 Web UI 中选择它创建会话。\n\n其他 ACP 兼容 agent 的接入方式类似：安装对应的 ACP 适配包，然后用 `acp-link <命令名>` 启动。可在 npm 官网搜索 `@agentclientprotocol/*` 查找已适配的 agent。\n\n## 团队协作场景\n\n### 共享会话\n\n在 RCS Web UI 中创建会话，分享链接给队友（需登录才能查看），他们可查看或加入对话。也可通过 `session_shares` 显式授予指定用户或团队「只读」/「读写」权限，并设置过期时间。\n\n### 多 Worker 协作\n\n团队多个成员各自启动 worker，连接到同一 RCS：\n\n```bash\n# 成员 A：默认配置\nslz rc\n\n# 成员 B：worktree 隔离，5 并发\nslz rc --spawn=worktree --capacity=5\n```\n\nWeb UI 显示所有 worker 状态，会话与权限集中管理。\n\n### 外部 Agent 接入\n\n用 ACP 让非 slz 的 agent 接入 RCS。Claude Code 通过 `claude-agent-acp` 适配包接入：\n\n```bash\n# 先装适配包（仅一次）\nnpm install -g @agentclientprotocol/claude-agent-acp\n\n# 设置 RCS 连接\nexport ACP_RCS_URL=http://rcs-host:3000\nexport ACP_RCS_TOKEN=sk-your-key\n\n# 启动桥接\nacp-link claude-agent-acp\n```\n\n接入后所有 agent 在 Web UI 中统一管理，团队成员可选择任意 agent 创建会话。\n\n## 安全建议\n\n- RCS 默认监听 0.0.0.0，生产环境建议用反代 + HTTPS\n- 用强 API Key，定期轮换\n- 生产环境关闭 `RCS_ALLOW_REGISTRATION` 改为邀请制\n- 使用 `RCS_WEB_CORS_ORIGINS` 限制 Web UI 访问来源\n- 设置 `RCS_DB_PATH` 持久化 SQLite 数据库\n- 限制 worker 的权限（`/permissions` 配置）\n- `bypassPermissions` 模式仅在 sandbox 环境中启用，避免在主机直接放行所有工具调用\n\n## 故障排查\n\n| 问题 | 排查 |\n|------|------|\n| Worker 无法连接 | 检查 `SALUZI_BRIDGE_BASE_URL` 和 `SALUZI_BRIDGE_OAUTH_TOKEN` 是否同时设置；确认 token 与 RCS 的 `RCS_API_KEYS` 匹配 |\n| Web UI 登录失败 | 检查用户名密码；5 次失败后锁定 5 分钟 |\n| Web UI 401 | 确认使用 `RCS_API_KEYS` 中的 key 或有效的 session token |\n| 看不到某个会话 | 检查会话 visibility（private/team/public）；确认是否在所属团队的成员列表里；admin 可看所有 |\n| 环境显示「待认领」 | worker 没指定 `--user-id`/`--team-id`，找到终端里的 `/code/claim/clm_xxx` URL，已登录用户打开即可认领 |\n| acp-link 无法连接 RCS | 检查 `ACP_RCS_URL` 和 `ACP_RCS_TOKEN` 是否设置 |\n| Agent 不出现在 Web UI | 确认 acp-link 已启动且 `ACP_RCS_TOKEN` 与 `RCS_API_KEYS` 匹配 |\n| 邀请链接失效 | 邀请 token 可能过期或达到 max_uses 上限；让团队 owner/admin 重新创建 |\n| 会话超时 | 调整 `RCS_DISCONNECT_TIMEOUT` 和 `RCS_WS_CLIENT_INACTIVITY_TIMEOUT` |\n"
+      "content": "\n## Remote Control Server (RCS)\n\nRCS 是 Saluzi 的自托管远程控制服务器，提供 Web UI 和会话管理。启动后，团队成员通过浏览器访问 Web UI，登录后即可创建会话、查看 worker 状态、与 agent 交互。\n\n## 启动 RCS\n\n```bash\n# 设置 API Key（管理员密码，也是 worker 连接 token）\nexport RCS_API_KEYS=sk-your-key\n\n# 启动（在 Saluzi CLI 中运行）\n> /rcs\n```\n\n也可通过 CLI 子命令直接启动：\n\n```bash\nslz rcs\n```\n\n默认端口 3000，Web UI 在 `http://localhost:3000/code/`。\n\n## RCS Web UI 使用\n\nWeb UI 是团队成员日常使用的控制面板：登录后可创建会话、查看 worker、审批权限、管理团队与环境。下面按首次部署到日常使用的顺序介绍。\n\n### 管理员初始化（首次访问）\n\n第一次打开 Web UI 时，系统没有任何用户。第一个登录的账号会成为系统管理员（role=admin），流程如下：\n\n1. 浏览器打开 `http://localhost:3000/code/`，自动跳转到 Setup 页面\n2. 填写表单：\n   - **API Key**：必须与 RCS 启动时设置的 `RCS_API_KEYS` 中的某个 key 完全一致\n   - **用户名**：登录用，后续不可改\n   - **密码**：至少 8 位\n   - **确认密码**\n3. 提交后第一个用户即成为 admin，进入管理面板\n\n后续访问的用户分两种：\n\n- **自注册**：如果 `RCS_ALLOW_REGISTRATION` 未设为 `false`（默认开放），新访问者可在登录页注册账户（用户名 + 密码）。密码以 argon2id 加密存储，登录有速率限制（5 次失败后锁定 5 分钟）。\n- **邀请制**：将 `RCS_ALLOW_REGISTRATION=false` 后，只有管理员预先创建的账户或通过团队邀请链接加入的用户能登录。\n\n管理员 API Key 拥有系统级权限，可直接访问所有 API（不通过 Web UI 登录流程）。\n\n登录后浏览器会保存 session cookie（`rcs_access`），后续请求自动认证。\n\n### 团队与角色\n\nRCS 用「团队」组织成员、环境和会话。每个登录用户都有一个「个人空间」（无需创建），可被加入一个或多个团队。\n\n**系统级角色**（`users.role`）：\n\n| 角色 | 能力 |\n|------|------|\n| `admin` | 看到所有会话（含无主孤儿）、管理所有团队、转移任意环境；通常由 Setup 流程产生 |\n| 普通用户 | 仅看到自己拥有的、所属团队可见的、显式共享给自己的会话 |\n| `guest` | 不能创建团队；通常对应被降级的账户 |\n\n**团队级角色**（`team_members.role`）：\n\n| 角色 | 团队内能力 |\n|------|-----------|\n| `owner` | 修改团队信息、删除团队、加/减成员、改成员角色、创建/撤销邀请、转移或解绑环境 |\n| `admin` | 加成员、创建/撤销邀请，但不能改 owner/admin 的角色，也不能删团队 |\n| `member` | 只能自退团队，看不到团队级管理按钮 |\n\n团队至少要保留一个 owner — 系统禁止降级或移除最后一个 owner。系统 admin 在任何团队中都视为 owner。\n\n**邀请加入**：团队 owner/admin 可在「团队详情 → 邀请」页面创建邀请链接，链接形如 `/join/<inv_xxx>`，可设置：\n\n- 角色：新成员加入后的角色（仅 `admin` 或 `member`，不能邀请为 owner）\n- 过期时间（默认 24 小时）\n- 最大使用次数（默认 1）\n\n也可以「添加已有用户」：通过用户名或用户 ID 搜索已注册账户，直接加入团队。\n\n### 环境管理\n\n「环境」（environment）是 worker 向 RCS 注册后产生的实体，代表一台正在提供 agent 服务的工作机。每个环境有：\n\n- 拥有者（owner_user_id，可能为空 → 需要认领）\n- 关联团队（可选，关联后团队内成员可见该环境及其会话）\n- worker 类型（slz CLI / ACP agent）、容量、心跳\n\n**环境的归属**：\n\n- 启动 worker 时通过 `--user-id` / `--team-id` 指定 → 直接归属到该用户或团队\n- 未指定且使用共享 API Key → 生成 `claim_token`，进入待认领状态（见下文 claim 机制）\n\n**环境与团队的关联**：\n\n- 在「团队详情 → 环境」页面可把个人环境链接到团队，或把团队环境解绑回个人\n- 环境可在团队之间转移（需要源团队和目标团队的 owner/admin 权限）\n- 转移环境时，该环境下的所有会话归属随之转移到目标团队\n\n### Claim 机制（环境认领）\n\n当 worker 使用共享 API Key 启动、且未指定 `--user-id` / `--team-id` 时，RCS 不会把环境直接归属给任何人，而是生成一个 `claim_token`（形如 `clm_xxxxxxxx`）并打印认领 URL：\n\n```\n/code/claim/clm_xxxxxxxx\n```\n\n**认领流程**：\n\n1. worker 启动后在终端看到认领 URL\n2. 把这个 URL 发给任意已登录用户\n3. 该用户在浏览器打开 URL → 自动调用 `/environments/claim` 接口\n4. 该环境的 `owner_user_id` 写入此用户，`claim_token` 清空\n5. 该环境下已经创建的会话也会一并 backfill 到该用户名下（否则会成为无主孤儿会话）\n\n`claim_token` 有过期时间（`claim_expires_at`），过期后无法认领。已被认领的环境再次访问会返回 409。\n\n这个机制让团队成员用共享 API Key 启动 worker 后，再由具体的人认领，避免环境长期处于无主状态。\n\n### 会话可见域\n\n每个会话有 `visibility` 字段，控制谁能看到它：\n\n| 可见域 | 谁能看到 |\n|--------|---------|\n| `private` | 仅会话的 user owner |\n| `team` | 会话所属团队的所有成员 |\n| `public` | 所有登录用户 |\n\n实际的可见规则综合考虑了 ownership、visibility 和显式共享：\n\n1. 系统 admin 能看到所有会话（含无主孤儿会话）\n2. 用户作为 user owner 拥有的会话\n3. 用户所属团队作为 team owner 拥有、且 visibility 为 `team` 或 `public` 的会话\n4. 通过 `session_shares` 显式共享给该用户的会话（未过期）\n5. 通过 `session_shares` 显式共享给该用户所属团队的会话（未过期）\n6. visibility=`public` 的会话\n7. 无主孤儿会话：仅 admin 可见\n\n**会话转移**：会话 owner（或团队 admin）可把会话从个人空间转到团队（visibility 自动变 `team`），或从团队转回个人（visibility 自动变 `private`）。转移时需要目标是该团队的 owner/admin。\n\n**会话分享**：会话 owner 可生成分享链接，授予指定用户或团队「只读」或「读写」权限，可设置过期时间。被分享者会在自己的会话列表里看到该会话。\n\n### 权限审批\n\nRCS Web UI 在 agent 请求工具调用时弹出审批面板。权限模式（permissionMode）有 6 种，决定 agent 是否需要等待人工确认：\n\n| 模式 | 行为 |\n|------|------|\n| `default` | 每次工具调用都请求确认 |\n| `auto` | agent 自动判断是否需要确认 |\n| `acceptEdits` | 自动接受文件编辑，其他工具仍需确认 |\n| `plan` | 规划模式，仅制定计划不执行 |\n| `dontAsk` | 不询问，直接执行 |\n| `bypassPermissions` | 绕过所有权限检查（仅 sandbox 环境可用，非 root） |\n\n权限模式可在创建会话时指定，也可在会话进行中切换。fallback 顺序：客户端传值 > acp-link 启动时的 `ACP_PERMISSION_MODE` 环境变量。\n\n**三种审批面板**：\n\n- **工具调用审批**：显示工具名、参数和描述，提供 Approve / Reject 按钮\n- **多问题面板**（AskUserQuestion）：agent 一次提多个问题，用户在标签页中切换回答，每题可选预设选项或填写「Other」自定义文本\n- **计划审批**：显示 plan 内容，提供「Yes, auto-accept edits」「Yes, manually approve edits」「No, keep planning」三个选项，选 No 时可附反馈让 agent 重新规划\n\n### Worker 状态\n\nWeb UI 显示所有已连接的 worker（包括 slz CLI worker 和 acp-link agent）：\n\n- **在线状态**：worker 当前是否可接受会话\n- **最大并发**：worker 配置的 `--capacity`\n- **最后活动时间**：最近一次心跳\n\n## RCS 服务器配置\n\n| 环境变量 | 默认 | 说明 |\n|---------|------|------|\n| `RCS_PORT` | 3000 | HTTP 端口 |\n| `RCS_HOST` | 0.0.0.0 | 监听地址 |\n| `RCS_API_KEYS` | — | 逗号分隔的 API Key（管理员权限，也是 worker 连接 token） |\n| `RCS_ALLOW_REGISTRATION` | true | 是否允许开放注册（设为 false 改为邀请制） |\n| `RCS_BASE_URL` | — | 外部访问 URL（反代时设置） |\n| `RCS_DB_PATH` | — | SQLite 数据库路径（默认内存，生产环境建议持久化） |\n| `RCS_WEB_CORS_ORIGINS` | — | Web UI CORS 允许的源（逗号分隔） |\n| `RCS_JWT_EXPIRES_IN` | 3600 | JWT 有效期（秒） |\n| `RCS_DISCONNECT_TIMEOUT` | 300 | 断开连接超时（秒） |\n| `RCS_WS_CLIENT_INACTIVITY_TIMEOUT` | 300 | WebSocket 客户端无活动超时（秒） |\n\n## Worker 接入\n\nWorker 是连接到 RCS 的 Saluzi CLI 实例，执行来自 Web UI 或其他客户端的会话。\n\n### 前置：设置环境变量\n\n**所有 worker 启动方式都需要先设置以下两个环境变量**：\n\n```bash\nexport SALUZI_BRIDGE_BASE_URL=http://rcs-host:3000\nexport SALUZI_BRIDGE_OAUTH_TOKEN=sk-your-key\n```\n\n- `SALUZI_BRIDGE_BASE_URL`：RCS 服务器地址\n- `SALUZI_BRIDGE_OAUTH_TOKEN`：必须与 RCS 启动时设置的 `RCS_API_KEYS` 中的某个 key 一致\n\n两个变量必须**同时设置**才生效。只设置一个会进入\"部分配置\"状态，启动时会提示补全。\n\n可选环境变量（用于归属和团队关联）：\n\n| 环境变量 | 说明 |\n|---------|------|\n| `SALUZI_BRIDGE_USERNAME` | 归属用户名（发送为 `X-Username` 头，RCS 自动认领 env 到该用户） |\n| `SALUZI_BRIDGE_USER_ID` | 归属用户 ID（绕过自动认领，直接绑定到该用户） |\n| `SALUZI_BRIDGE_TEAM_ID` | 关联团队 ID（env 注册到指定团队） |\n| `SALUZI_ENVIRONMENT_KIND` | 设为 `bridge` 标记会话来源为 remote-control |\n| `SALUZI_USE_CCR_V2` | 启用 CCR v2 传输协议 |\n| `SALUZI_BRIDGE_ALLOW_INSECURE_HTTP` | 设为 `1` 允许非 localhost 的 HTTP 连接（自托管内网场景，见下文） |\n\n**关于 HTTP 连接**：默认情况下，`SALUZI_BRIDGE_BASE_URL` 如果是 `http://` 且不是 `localhost`/`127.0.0.1`，worker 会拒绝启动——这是为了防止 credentials 明文传输。如果远程 RCS 部署在可信内网（例如 TLS 由上游反代终止、或网络已加密），可设置 `SALUZI_BRIDGE_ALLOW_INSECURE_HTTP=1` 放开此限制。生产环境建议优先用 HTTPS 或 SSH 隧道转发到 localhost。\n\n如果不设置 `SALUZI_BRIDGE_USERNAME`/`SALUZI_BRIDGE_USER_ID`/`SALUZI_BRIDGE_TEAM_ID`，且 token 是共享的管理员 API Key，RCS 会生成 `claim_token` 并打印认领 URL，worker 终端会显示该 URL 供用户认领（详见上文「Claim 机制」）。\n\n### 启动方式\n\n设置好环境变量后，推荐直接运行：\n\n```bash\nslz rc\n```\n\n`slz rc` 是最简的启动方式，默认配置即可作为 worker 连接到 RCS。它是 `slz remote-control` 的简写，也接受 `slz remote`、`slz sync`、`slz bridge` 作为别名。\n\n其他可选方式：\n\n```bash\n# 交互式会话 + worker（既可本地用，也接受远程请求）\nslz --remote-control\n\n# 普通会话自动连接（设置好环境变量后直接运行）\nslz\n```\n\n### 高级参数\n\n需要调整 worker 行为时，`slz rc` 支持以下参数：\n\n| 参数 | 说明 | 示例 |\n|------|------|------|\n| `--spawn <mode>` | Spawn 模式：`same-dir`、`worktree`、`session` | `--spawn=worktree` |\n| `--capacity <N>` | 最大并发会话数（仅 worktree/session 模式） | `--capacity=5` |\n| `--create-session-in-dir` | 启动时在当前目录预创建会话（默认开启） | `--no-create-session-in-dir` 禁用 |\n| `--session-id <id>` | 恢复指定会话 | `--session-id=abc123` |\n| `--continue` | 恢复最近会话 | — |\n| `--name <name>` | 会话名称（也用于 RCS 显示） | `--name=\"我的会话\"` |\n| `--username <name>` | 归属用户名（对应 `SALUZI_BRIDGE_USERNAME`） | `--username=alice` |\n| `--user-id <id>` | 归属用户 ID（对应 `SALUZI_BRIDGE_USER_ID`） | `--user-id=u-123` |\n| `--team-id <id>` | 关联团队 ID（对应 `SALUZI_BRIDGE_TEAM_ID`） | `--team-id=team-abc` |\n\n### Spawn 模式\n\n| 模式 | 说明 | 适用场景 |\n|------|------|---------|\n| `same-dir`（默认） | 所有会话在同一工作目录创建 | 单项目快速响应 |\n| `worktree` | 每个会话在独立 git worktree 中创建 | 多项目隔离，避免文件冲突 |\n| `session` | 单会话模式（容量固定为 1） | 简单场景，不需要并发 |\n\n## Worker 与 RCS 的关系\n\n```\n┌─────────────────┐\n│   RCS Server    │  ← 运行 slz rcs\n│  (Web UI + API) │\n└────────┬────────┘\n         │ Bridge 协议\n         │\n    ┌────┴────┐\n    │         │\n┌───▼──┐  ┌──▼───┐\n│Worker│  │Worker│  ← slz rc / slz --remote-control / slz\n│  1   │  │  2   │\n└──────┘  └──────┘\n```\n\n- **RCS**：中央服务器，管理会话、用户、权限\n- **Worker**：通过 bridge 协议连接，从 RCS 获取任务，汇报状态\n- **Web UI**：通过浏览器访问 RCS，创建/查看会话\n\n## ACP 协议\n\nACP（Agent Control Protocol）让**外部 agent**（非 slz CLI，如 Claude Code、其他 ACP 兼容 agent）接入 RCS 的会话系统。slz CLI 自身使用 bridge 协议，不走 ACP。\n\n`acp-link` 是 ACP 桥接工具，随 `@saluzi/saluzi-edu` 一起安装，无需单独安装。\n\n### 连接 slz 到 RCS\n\n如果要让 slz CLI 作为 ACP agent 接入 RCS（而非 bridge worker），使用 `acp-link` 桥接：\n\n#### 1. 设置环境变量\n\n```bash\nexport ACP_RCS_URL=http://rcs-host:3000\nexport ACP_RCS_TOKEN=sk-your-key\n```\n\n- `ACP_RCS_URL`：RCS 服务器地址\n- `ACP_RCS_TOKEN`：必须与 RCS 的 `RCS_API_KEYS` 中的某个 key 一致\n\n可选环境变量：\n\n| 环境变量 | 说明 |\n|---------|------|\n| `ACP_RCS_GROUP` | Channel group ID（字母、数字、下划线、连字符） |\n| `ACP_RCS_USERNAME` | 归属用户名（自动认领 env 到该用户） |\n| `ACP_RCS_USER_ID` | 归属用户 ID（绕过自动认领） |\n| `ACP_RCS_TEAM_ID` | 关联团队 ID |\n| `ACP_AUTH_TOKEN` | 本地 WS 认证 token（不设则自动生成） |\n| `ACP_PERMISSION_MODE` | 默认权限模式 |\n\n#### 2. 启动 acp-link\n\n```bash\nacp-link slz -- --acp\n```\n\n`acp-link` 会启动 slz 作为子进程，通过 ACP 协议代理它与 RCS 之间的通信。slz 会出现在 RCS Web UI 的 agent 列表中，可接受会话请求。\n\n`--` 之后是传递给 slz 的参数（`--acp` 让 slz 进入 ACP 兼容模式）。\n\n### 连接 Claude Code 到 RCS\n\n`acp-link` 支持任何遵循 ACP 协议的 agent。Claude Code 通过专用的 ACP 适配包 `@agentclientprotocol/claude-agent-acp` 接入，接入命令是 `acp-link claude-agent-acp`（**不是** `acp-link claude`，因为 Claude Code 本身不直接说 ACP 协议，需要先装适配包）。\n\n#### 1. 安装 claude-agent-acp\n\nClaude Code 的 ACP 适配包需要单独安装：\n\n```bash\nnpm install -g @agentclientprotocol/claude-agent-acp\n```\n\n安装后会注册 `claude-agent-acp` 命令。\n\n#### 2. 设置环境变量\n\n```bash\nexport ACP_RCS_URL=http://rcs-host:3000\nexport ACP_RCS_TOKEN=sk-your-key\n```\n\n#### 3. 启动 acp-link 桥接\n\n```bash\nacp-link claude-agent-acp\n```\n\n`acp-link` 的第一个参数是 agent 的可执行命令名（这里是 `claude-agent-acp`）。`claude-agent-acp` 本身不需要额外参数，因此不需要 `--`。\n\n连接成功后，Claude Code 会作为 ACP agent 出现在 RCS Web UI 中，与 slz agent 并列，团队成员可在 Web UI 中选择它创建会话。\n\n其他 ACP 兼容 agent 的接入方式类似：安装对应的 ACP 适配包，然后用 `acp-link <命令名>` 启动。可在 npm 官网搜索 `@agentclientprotocol/*` 查找已适配的 agent。\n\n## 团队协作场景\n\n### 共享会话\n\n在 RCS Web UI 中创建会话，分享链接给队友（需登录才能查看），他们可查看或加入对话。也可通过 `session_shares` 显式授予指定用户或团队「只读」/「读写」权限，并设置过期时间。\n\n### 多 Worker 协作\n\n团队多个成员各自启动 worker，连接到同一 RCS：\n\n```bash\n# 成员 A：默认配置\nslz rc\n\n# 成员 B：worktree 隔离，5 并发\nslz rc --spawn=worktree --capacity=5\n```\n\nWeb UI 显示所有 worker 状态，会话与权限集中管理。\n\n### 外部 Agent 接入\n\n用 ACP 让非 slz 的 agent 接入 RCS。Claude Code 通过 `claude-agent-acp` 适配包接入：\n\n```bash\n# 先装适配包（仅一次）\nnpm install -g @agentclientprotocol/claude-agent-acp\n\n# 设置 RCS 连接\nexport ACP_RCS_URL=http://rcs-host:3000\nexport ACP_RCS_TOKEN=sk-your-key\n\n# 启动桥接\nacp-link claude-agent-acp\n```\n\n接入后所有 agent 在 Web UI 中统一管理，团队成员可选择任意 agent 创建会话。\n\n## 安全建议\n\n- RCS 默认监听 0.0.0.0，生产环境建议用反代 + HTTPS\n- 用强 API Key，定期轮换\n- 生产环境关闭 `RCS_ALLOW_REGISTRATION` 改为邀请制\n- 使用 `RCS_WEB_CORS_ORIGINS` 限制 Web UI 访问来源\n- 设置 `RCS_DB_PATH` 持久化 SQLite 数据库\n- 限制 worker 的权限（`/permissions` 配置）\n- `bypassPermissions` 模式仅在 sandbox 环境中启用，避免在主机直接放行所有工具调用\n\n## 故障排查\n\n| 问题 | 排查 |\n|------|------|\n| Worker 无法连接 | 检查 `SALUZI_BRIDGE_BASE_URL` 和 `SALUZI_BRIDGE_OAUTH_TOKEN` 是否同时设置；确认 token 与 RCS 的 `RCS_API_KEYS` 匹配 |\n| `Only HTTPS or localhost HTTP is allowed` | 远程 RCS 用 HTTP 被拒。优先用 HTTPS；或 SSH 隧道转发到 localhost；可信内网可设 `SALUZI_BRIDGE_ALLOW_INSECURE_HTTP=1` |\n| Web UI 登录失败 | 检查用户名密码；5 次失败后锁定 5 分钟 |\n| Web UI 401 | 确认使用 `RCS_API_KEYS` 中的 key 或有效的 session token |\n| 看不到某个会话 | 检查会话 visibility（private/team/public）；确认是否在所属团队的成员列表里；admin 可看所有 |\n| 环境显示「待认领」 | worker 没指定 `--user-id`/`--team-id`，找到终端里的 `/code/claim/clm_xxx` URL，已登录用户打开即可认领 |\n| acp-link 无法连接 RCS | 检查 `ACP_RCS_URL` 和 `ACP_RCS_TOKEN` 是否设置 |\n| Agent 不出现在 Web UI | 确认 acp-link 已启动且 `ACP_RCS_TOKEN` 与 `RCS_API_KEYS` 匹配 |\n| 邀请链接失效 | 邀请 token 可能过期或达到 max_uses 上限；让团队 owner/admin 重新创建 |\n| 会话超时 | 调整 `RCS_DISCONNECT_TIMEOUT` 和 `RCS_WS_CLIENT_INACTIVITY_TIMEOUT` |\n"
     },
-    "docs/guide/context-tips": {
+    "docs/guide/conversation-basics": {
       "frontmatter": {
-        "title": "上下文管理 - 让 AI 更好理解你的项目",
-        "description": "通过挂载目录、SALUZI.md 项目记忆、个人偏好配置，让 Saluzi 更精准地理解你的项目与习惯。",
+        "title": "对话基础 - 如何与 Saluzi 交互",
+        "description": "从第一次提问到多轮对话、流式输出、上下文压缩与导出恢复，掌握 Saluzi 对话的核心使用方式。",
+        "keywords": ""
+      },
+      "content": "\n## 开始对话\n\n直接输入需求即可。例如：\n\n```\n> 帮我看看这个项目的目录结构\n```\n\nSaluzi 会调用工具（读文件、搜索代码）探索代码后给出回答。\n\n## 多轮对话\n\n- **追加需求**：直接继续输入，Saluzi 记得前文\n- **纠正理解**：如果 AI 理解错了，直接说\"不对，我要的是 X\"\n- **切换话题**：可以随时切换，但建议用 `/clear` 清理后再切换大话题\n\n## 流式输出\n\n- AI 输出是实时的，你可以看到逐字生成\n- 按 `Esc` 打断当前输出\n- 打断后可以补充指令或换方向\n\n## 对话太长时\n\n长对话会消耗 token，Saluzi 提供几个管理工具：\n\n| 命令 | 用途 |\n|------|------|\n| `/context` | 查看当前 token 占用 |\n| `/compact` | 压缩对话历史（保留要点，丢弃冗余） |\n| `/clear` | 重置会话（清空所有历史） |\n| `/summary` | 生成当前会话摘要 |\n\n> **Tip** 当 `/context` 显示超过 80% 时，建议执行 `/compact` 压缩上下文。\n\n## 导出与恢复\n\n| 命令 | 用途 |\n|------|------|\n| `/export` | 导出当前对话为 markdown |\n| `/resume` | 恢复历史会话（列出可选） |\n| `/rewind` | 回退到某一步（可回到之前的任意消息） |\n| `/session` | 管理多个会话 |\n\n## 实用技巧\n\n### 引用文件\n\n直接在消息里写文件路径，Saluzi 会自动读取：\n\n```\n> 改一下 app.tsx 里的样式\n```\n\nAI 会先读取文件内容再进行修改。\n\n### 引用命令输出\n\n用 `!` 前缀运行命令，输出直接进对话：\n\n```\n> !npm test\n```\n\nAI 看到测试输出后可以帮你修失败的测试。\n\n### 拖入文件\n\n终端支持拖入文件路径（取决于终端模拟器），路径会自动粘贴到输入框。\n\n## 下一步\n\n- [上下文管理](./context-tips) — 让 AI 更好理解你的项目\n- [新手入门](./getting-started) — 安装与首次登录\n- [模型选择](./model-selection) — 切换 Max/Pro/Std\n- [查看消耗](./cost-usage) — `/cost` 与 `/stats` 详解\n"
+    },
+    "docs/guide/model-selection": {
+      "frontmatter": {
+        "title": "模型选择与切换 - Max/Pro/Std 与推理深度",
+        "description": "使用 /model 切换模型，/effort 调节推理深度，/mom 配置混合模型。",
         "keywords": [
-          "上下文",
-          "add-dir",
-          "SALUZI.md",
-          "memory",
-          "项目记忆",
-          "compact"
+          "model",
+          "effort",
+          "Max",
+          "Pro",
+          "Std",
+          "模型切换",
+          "推理深度"
         ]
       },
-      "content": "\n## 让 AI 理解项目\n\nSaluzi 的回答质量取决于它对项目的理解程度。本章介绍三种方式，让 AI 快速进入状态。\n\n### 挂载工作目录\n\n```\n> /add-dir\n```\n\n挂载目录后，Saluzi 会扫描结构并将该目录纳入工具的文件访问范围，后续对话可基于代码上下文回答。\n\n可以挂载多个目录，适合跨仓库协作场景：\n\n```\n> /add-dir ~/projects/frontend\n> /add-dir ~/projects/backend\n```\n\n### 何时挂载\n\n- 开始新项目时\n- 需要跨多个仓库工作时\n- AI 对项目结构不熟时\n\n> **Tip** 可用 `/codegraph` 查看或启用代码智能索引。索引基于项目根目录（而非挂载目录），需要手动开启。\n\n## 项目记忆：SALUZI.md\n\n在项目根目录创建 `SALUZI.md`，写入项目约定。Saluzi 每次对话都会读取它，相当于给 AI 一份\"项目手册\"。\n\n### 示例\n\n```markdown\n# 项目约定\n\n## 技术栈\n- 前端：React 19 + Vite + Tailwind v4\n- 后端：Hono + Node.js\n\n## 代码风格\n- 用 npm，不用 yarn\n- TypeScript strict 模式\n- 提交前跑 `npm run lint`\n\n## 架构原则\n- 命令目录结构遵循项目约定\n- 不要在 prod 代码里用 as any\n```\n\n### SALUZI.md 写什么\n\n| 类别 | 示例 |\n|------|------|\n| 技术栈与版本 | React 19、Node 22、PostgreSQL 16 |\n| 代码风格规范 | 用 pnpm 而非 yarn，2 空格缩进 |\n| 项目架构原则 | 命令目录结构、模块边界 |\n| 常用命令 | `npm run lint`、`npm run test`、`npm run build` |\n| 禁忌事项 | 不要加 docstring，不要 `as any` |\n\n> **Tip** `SALUZI.md` 应纳入版本控制，让整个团队共享同一份约定。\n\n## 个人偏好：/memory\n\n`/memory` 用于记录跨项目的个人习惯，与 `SALUZI.md` 互补：\n\n```\n> /memory\n```\n\n打开记忆面板，可添加、编辑、删除条目。例如：\n\n- \"我喜欢用 conventional commits\"\n- \"代码注释用中文\"\n- \"不要加 docstring，除非逻辑非显然\"\n\n记忆保存在 `~/.saluzi-edu/` 下，跨项目、跨会话生效。\n\n### SALUZI.md vs /memory\n\n| 维度 | SALUZI.md | /memory |\n|------|-----------|---------|\n| 作用范围 | 单个项目 | 所有项目 |\n| 存储位置 | 项目根目录 | `~/.saluzi-edu/` |\n| 共享方式 | Git 版本控制 | 仅本人可见 |\n| 适合内容 | 项目约定、团队规范 | 个人习惯、偏好 |\n\n## 上下文压缩\n\n长对话会接近模型的 token 上限，Saluzi 通过压缩策略保持对话可用。\n\n### 何时压缩\n\n- 对话超过 token 上限时，自动压缩早期内容\n- 手动输入 `/compact` 主动压缩\n- 输入 `/context` 查看当前上下文占用情况\n\n### 压缩策略\n\n- 保留关键决策与代码改动\n- 丢弃冗余的探索过程\n- 保留最近若干轮原文，确保连贯性\n\n### 清理会话\n\n需要从头开始时，直接清理：\n\n```\n> /clear          # 完全重置，清空当前会话上下文\n```\n\n## 让 AI 记住更多\n\n### 用 /resume 恢复历史会话\n\n```\n> /resume\n```\n\n列出历史会话列表，选择一个恢复，之前的上下文即可继续使用。适合中断后接着做。\n\n### 用 /rewind 回退\n\n```\n> /rewind\n```\n\n回退到对话历史中的某一步，丢弃之后的所有内容。适合\"走错方向、想重来\"的场景。\n\n## 实用技巧\n\n### 分阶段工作\n\n大任务拆成多步，避免上下文过载：\n\n1. 先 `/plan` 让 AI 规划方案\n2. 确认方案后退出 plan mode\n3. 分批执行，每批完成后 `/compact` 压缩上下文\n4. 最后 `/commit` 提交\n\n### 跨项目切换\n\n切到另一个项目前，先 `/clear` 清空上下文，避免前一个项目的信息干扰当前对话。\n\n### 给 AI 明确指令\n\n在提问时带上具体路径和期望行为，比泛泛而问效果更好：\n\n```\n# 好\n> 看一下 login.ts，把 validateToken 函数改成 async，错误抛 AuthError\n\n# 差\n> 改一下登录那里\n```\n\n## 下一步\n\n- [对话基础](./conversation-basics) — 多轮对话与流式输出\n- [新手入门](./getting-started) — 安装与首次登录\n- [模型选择](./model-selection) — 切换 Max/Pro/Std\n"
+      "content": "\n## 模型选择\n\nSaluzi 支持多个模型，按能力与成本分级：\n\n| 模型 | 能力 | 速度 | 成本 | 适用场景 |\n|------|------|------|------|---------|\n| Max | 最强 | 慢 | 高 | 复杂架构、深度推理 |\n| Pro | 均衡 | 中 | 中 | 日常开发（默认） |\n| Std | 快 | 快 | 低 | 简单任务、快速验证 |\n\n## /model 切换\n\n```\n> /model\n```\n\n打开模型选择面板，可切换当前会话的模型。也可直接指定：\n\n```\n> /model max\n> /model pro\n> /model std\n```\n\n支持模型别名：`best`、`max[1m]`（1M 上下文）、`pro[1m]`、`maxplan` 等。\n\n## /effort 推理深度\n\n`/effort` 调节推理链长度（仅支持推理模型的 extended thinking）：\n\n```\n> /effort low     # 快速响应\n> /effort medium  # 中等（默认）\n> /effort high    # 深度推理\n> /effort xhigh   # 极深度推理\n> /effort max     # 最大推理深度\n> /effort auto    # 清除手动设置，使用自动\n```\n\n也可通过环境变量设置：`SALUZI_EFFORT_LEVEL=high slz`\n\n深度推理适合：\n\n- 复杂 bug 分析\n- 架构设计\n- 多步骤规划\n- 代码审查\n\n## /mom 混合模型\n\n见 [MOM 混合模型章节](./mom-mixed-models)。MOM 允许多模型协同：主机 + 顾问。\n\n- `/mom` 打开配置面板\n- `/mom \"内容\"` 执行一次性 MOM 回合\n- `/mom-<mode> \"内容\"` 使用特定 MOM 模式（如 `/mom-avg`）\n\n## /poor 节约模式\n\n```\n> /poor\n```\n\n切换节约模式，关闭**记忆提取**（extract_memories）和**提示建议**（prompt_suggestion），减少 token 消耗。\n\n## Provider 选择\n\nSaluzi 自动选择最优 Provider。如需指定：\n- 通过环境变量（如 `ANTHROPIC_API_KEY`）指定\n- 通过 `/keys` 绑定特定 provider 的 Key\n- 通过 `/model` 切换当前会话模型\n\n## 推荐配置\n\n| 场景 | 推荐 |\n|------|------|\n| 日常开发 | Pro + medium effort |\n| 复杂重构 | Max + high effort |\n| 快速原型 | Std + low effort |\n| 关键决策 | MOM（Pro 主机 + Max 顾问） |\n| 节约模式 | `/poor`（关闭记忆提取与提示建议） |\n\n## 成本监控\n\n用 `/cost` 查看当前会话消耗，`/stats` 查看历史统计。\n\n## 下一步\n\n- [MOM 混合模型](./mom-mixed-models) — 多模型协同：主机 + 顾问\n- [查看消耗](./cost-usage) — `/cost` 与 `/stats` 详解\n- [对话基础](./conversation-basics) — 多轮对话与流式输出\n- [API Key 绑定](./keys-binding) — `/keys` 多 Key 调度\n"
+    },
+    "docs/guide/getting-started": {
+      "frontmatter": {
+        "title": "新手入门 - 安装、登录与首次对话",
+        "description": "从零开始使用 Saluzi：安装 CLI、登录账户、添加项目目录、第一次提问与代码提交工作流。",
+        "keywords": [
+          "新手入门",
+          "安装",
+          "登录",
+          "首次对话",
+          "commit"
+        ]
+      },
+      "content": "\n## 安装 Saluzi CLI\n\nSaluzi 是终端原生的 agentic coding system，通过 npm 全局安装：\n\n```bash\nnpm install -g @saluzi/saluzi-edu\n```\n\n安装后验证：\n\n```bash\nslz --version\n```\n\n## 首次登录\n\n启动 CLI 后输入 `/login` 命令：\n\n```\nslz\n> /login\n```\n\n弹出 `Login` 对话框，首先提示 `Select login method:`，共 6 个 Provider 选项。按 `↑/↓` 选择，`Enter` 确认：\n\n| # | 选项 | 副标题 | 适用场景 |\n|---|------|--------|---------|\n| 1 | Anthropic Compatible | Configure your own API endpoint | 自建/代理的 Anthropic 格式端点（如反代、中转） |\n| 2 | OpenAI Compatible | Ollama, DeepSeek, vLLM, One API, etc. | OpenAI Chat Completions 格式的本地或第三方模型 |\n| 3 | Gemini API | Google Gemini native REST/SSE | Google 原生 Gemini 接口 |\n| 4 | Saluzi account with subscription | Pro, Max, Team, or Enterprise | 订阅账户（个人/团队最常用） |\n| 5 | Anthropic Console account | API usage billing | Anthropic Console 按 API 用量计费 |\n| 6 | 3rd-party platform | Amazon Bedrock, Microsoft Foundry, or Vertex AI | 云厂商托管入口 |\n\n> 如果已设置 `ANTHROPIC_API_KEY` 环境变量，Saluzi 会自动检测并跳过登录，`/login` 此时显示为 \"Switch Saluzi accounts\"。\n\n### 选项 1-3：API 表单登录\n\n选择前三个选项（Anthropic / OpenAI / Gemini Compatible）后进入对应的字段表单。三者字段完全一致，只是写入的环境变量不同：\n\n| 字段 | 标签 | 说明 | 是否必填 |\n|------|------|------|---------|\n| baseUrl | Base URL | API 端点地址，需含协议（如 `https://api.example.com`） | 否（留空走默认） |\n| apiKey | API Key | 密钥，输入时掩码显示 | 否 |\n| stdModel | Std | standard 模型名（如 `claude-sonnet-4-5`） | 否 |\n| proModel | Pro | pro 模型名 | 否 |\n| maxModel | Max | max 模型名 | 否 |\n| maxOutputTokens | Out Tok | 单次响应最大 token 数 | 否 |\n| autoCompactWindow | AC Win | 自动压缩上下文的窗口大小 | 否 |\n| autoCompactPctOverride | AC Pct% | 自动压缩触发阈值百分比 | 否 |\n\n操作方式：`↑/↓` 或 `Tab` 切换字段，`Enter` 在最后一个字段提交保存，`Esc` 返回选项菜单。保存后表单中的值会写入 `~/.saluzi/settings.json` 的 `env` 段（对应 `ANTHROPIC_BASE_URL`/`OPENAI_BASE_URL`/`GEMINI_BASE_URL` 等环境变量），下次启动自动加载。\n\n### 选项 4-5：OAuth 浏览器登录\n\n选择 Saluzi 账户或 Anthropic Console 后进入 OAuth 流程：\n\n1. 终端显示 `Opening browser to sign in…`（带加载图标），自动打开浏览器\n2. 在浏览器完成账户登录与授权\n3. 浏览器返回一串授权码，复制后回到终端\n4. 终端提示 `Paste code here if prompted >`（掩码输入），粘贴授权码并 `Enter`\n5. 终端显示 `Creating API key for Saluzi…`，完成后提示 `Login successful. Press Enter to continue…`\n\n如果浏览器没有自动打开，终端会展示 URL 和复制提示，按 `c` 可复制 URL 手动打开。\n\n### 选项 6：第三方平台\n\n选择 3rd-party platform 后只显示提示信息：Saluzi 支持 Amazon Bedrock、Microsoft Foundry、Vertex AI，需要先设置对应的环境变量再重启 Saluzi。按 `Enter` 返回选项菜单，不在 CLI 内直接配置。企业用户需联系管理员获取配置参数。\n\n### 登录后\n\n登录成功后 Saluzi 会自动刷新策略配额、GrowthBook 特性开关、远程受管设置，并为本机注册 trusted device（用于 Remote Control）。无需额外操作，直接开始对话即可。\n\n## 添加项目目录\n\n进入项目后用 `/add-dir` 挂载工作目录：\n\n```\n> /add-dir\n```\n\nSaluzi 会扫描目录结构，后续对话即可基于代码上下文回答。\n\n## 第一次对话\n\n直接输入需求：\n\n```\n> 帮我看看这个项目的目录结构，有没有潜在问题\n```\n\nSaluzi 会：\n1. 调用 `Read`、`Glob`、`Grep` 工具探索代码\n2. 分析后给出建议\n3. 若需修改，会请求权限后调用 `Edit`、`Write` 工具\n\n每次工具调用前会弹出权限确认（除非已 Allow）。\n\n## 提交代码工作流\n\n完成修改后：\n\n```\n> /diff          # 预览改动\n> /commit        # 提交（自动生成 commit message）\n> /commit-push-pr # 一条龙：提交 + 推送 + 创建 PR\n```\n\n## 下一步\n\n- [模型选择与切换](./model-selection) — 了解 `/model`、`/effort`、`/mom`\n- [对话基础](./conversation-basics) — 多轮对话与流式输出\n- [上下文管理](./context-tips) — 让 AI 更好理解你的项目\n- [主目录与配置](./saluzi-home) — 配置文件位置与字段说明\n"
+    },
+    "docs/guide/assistant-proactive": {
+      "frontmatter": {
+        "title": "Kairos 与自动助手",
+        "description": "Saluzi 的自动助手功能：/assistant 激活 Kairos 面板与守护进程、/proactive 自治模式、/summary 会话摘要，让 AI 从被动应答变为主动协作。",
+        "keywords": [
+          "assistant",
+          "proactive",
+          "Kairos",
+          "自动助手",
+          "自治模式",
+          "daemon"
+        ]
+      },
+      "content": "\n## 自动助手概览\n\nSaluzi 的自动助手功能让 AI 从\"被动应答\"升级为\"主动协作\"，包含以下能力：\n\n| 功能 | 命令 | 说明 |\n|------|------|------|\n| 助手面板 | `/assistant` | 激活 Kairos 面板与守护进程 |\n| 自治模式 | `/proactive` | 切换自治模式，AI 可主动执行低风险操作 |\n| 会话摘要 | `/summary` | 手动提取当前会话记忆 |\n| 简报 | `/brief` | Kairos 定时简报 |\n\n## /assistant 助手面板\n\n```\n> /assistant\n```\n\n首次运行时，`/assistant` 会：\n1. 激活 Kairos 模式（设置 `kairosActive = true`）\n2. 显示助手面板\n3. 若未检测到已配置的守护进程，启动**安装向导**（安装 assistant daemon 到项目目录）\n\n后续调用切换面板可见性。\n\n助手面板激活后，AI 会基于当前上下文主动建议下一步操作、潜在风险、可优化的代码点。\n\n## /proactive 自治模式\n\n```\n> /proactive\n```\n\n切换自治模式（默认关闭，二元开关）。开启后：\n\n- AI 通过定时 tick 主动检查项目状态\n- 可自动执行**低风险**操作（如读文件、运行测试）\n- 中高风险操作仍需确认（如写文件、提交代码）\n\n适用场景：\n\n- 长时间监控项目（如等 CI、看日志）\n- 自动化日常维护（如依赖更新、lint 修复）\n- 持续重构与优化\n\n## /summary 会话摘要\n\n```\n> /summary\n```\n\n手动触发会话记忆提取——将当前会话的关键决策、代码改动、上下文要点提取为结构化摘要。\n\n## Kairos 守护进程\n\nKairos 是 Saluzi 的后台守护进程系统，提供：\n\n- **定时简报**：定期生成项目状态摘要\n- **PR 订阅**：通过 GitHub webhook 监控 PR 事件（`/subscribe-pr`）\n- **定时任务**：通过 cron 调度器执行定期工作\n- **推送通知**：将事件通知发送到终端外部\n\nKairos 功能需要通过 entitlement 验证（订阅/授权），且需首次调用 `/assistant` 手动激活。\n\n## 与普通模式的区别\n\n| 普通模式 | 自动助手模式 |\n|---------|------------|\n| 用户问，AI 答 | AI 主动建议 |\n| 单轮交互 | 持续监控 |\n| 等待指令 | 主动执行低风险 |\n\n## 风险与控制\n\n自治模式有风险，建议：\n\n- 用 `/permissions` 限制可自动执行的工具\n- 定期查看 `/cost` 监控消耗\n- 重要操作前关闭 `/proactive`\n"
+    },
+    "docs/guide/commit-workflow": {
+      "frontmatter": {
+        "title": "查看与提交代码 - diff、commit 与 PR 工作流",
+        "description": "使用 /diff 预览改动、/commit 提交、/commit-push-pr 一条龙推送并创建 PR、/review 代码审查。",
+        "keywords": [
+          "diff",
+          "commit",
+          "commit-push-pr",
+          "review",
+          "提交",
+          "PR",
+          "代码审查"
+        ]
+      },
+      "content": "\n## 预览改动\n\n在提交前，先用 `/diff` 查看当前工作区所有未提交的改动，确认修改范围是否符合预期：\n\n```\n> /diff\n```\n\nSaluzi 会列出已暂存和未暂存的文件变更摘要，帮助你快速定位哪些文件被新增、修改或删除。\n如果发现意外改动，可以先撤销再继续。\n\n## 提交代码\n\n确认改动无误后，使用 `/commit` 提交。Saluzi 会根据 diff 内容自动生成 Conventional Commits 格式的 commit message：\n\n```\n> /commit\n```\n\n你也可以附加参数指定 message 类型或描述：\n\n```\n> /commit -m \"fix: 修复登录页的空指针问题\"\n```\n\n提交后改动保存在本地仓库，不会自动推送到远端。\n\n## 推送并创建 PR\n\n如果想一步到位——提交、推送、并在 GitHub 上创建 Pull Request，使用 `/commit-push-pr`：\n\n```\n> /commit-push-pr\n```\n\nSaluzi 会依次执行：\n1. 根据改动生成 commit message 并提交\n2. 将当前分支推送到远端\n3. 基于 commit 信息创建 PR 标题与描述\n\n适合功能分支开发完毕后一次性完成发布流程。\n\n## 代码审查\n\n使用 `/review` 对当前分支的改动或指定 PR 进行审查：\n\n```\n> /review\n```\n\n也可以指定 PR 编号：\n\n```\n> /review #42\n```\n\nSaluzi 会逐文件分析改动，指出潜在的 bug、风格问题和改进建议。\n\n## 提交模式对比\n\n| 特性 | `/commit` | `/commit-push-pr` |\n|------|-----------|-------------------|\n| 自动生成 commit message | 是 | 是 |\n| 提交到本地仓库 | 是 | 是 |\n| 推送到远端分支 | 否 | 是 |\n| 创建 Pull Request | 否 | 是 |\n| 适用场景 | 本地暂存、分批提交 | 功能完成后一步发布 |\n\n## 下一步\n\n- [上下文与项目记忆](./context-tips) — 让 AI 更懂你的项目\n- [查看消耗](./cost-usage) — 了解会话花费\n- [排障](./troubleshooting) — 常见问题与解决方案\n"
     }
   }
 }