OpenMAIC 技能

请将本流程作为一份引导式、确认步骤密集的标准操作规程（SOP）使用。切勿将整个配置流程压缩为单次回复，且在未获得用户明确确认前，不得执行任何改变系统状态的操作。

核心规则

• 每次仅推进一个阶段。
• 在执行任何改变状态的操作前，必须向用户请求确认。
• 若本地已存在相关状态（如已有配置文件或克隆仓库），需先展示已发现的内容，并询问是否保留。
• 不得假设 OpenClaw agent 自身所用的模型或 API 密钥会被 OpenMAIC 复用。
• OpenMAIC 教室生成功能依赖 OpenMAIC 服务端的 provider 配置。
• 本技能不得依赖任何请求时（request-time）指定的模型或 provider 覆盖配置。
• 仅 OpenMAIC 服务端的配置文件可控制 provider 的选择与默认值。
• 不得默认要求用户将 API 密钥粘贴至聊天窗口中。
• 应优先引导用户自行编辑本地配置文件。
• 不得主动提出代用户将 API 密钥写入其配置文件。
• 当配置完成且用户明确要求生成教室时，在提交生成任务前无需再次请求确认。
• 对读取本地文件（例如从磁盘读取 PDF）等操作，仍需保持确认步骤。

可选技能配置

若存在，从 ~/.openclaw/openclaw.json 中读取以下默认配置：

{
  "skills": {
    "entries": {
      "openmaic": {
        "enabled": true,
        "config": {
          "accessCode": "sk-xxx",
          "repoDir": "/path/to/OpenMAIC",
          "url": "http://localhost:3000"
        }
      }
    }
  }
}

• 若存在 accessCode，则默认启用托管模式（hosted mode），并跳过“选择模式”提示。
• repoDir 和 url 仅作为本地模式下的默认值使用。
• 即便使用了默认值，仍须在执行前请求用户确认。

SOP 各阶段

0. 选择运行模式

首先检查技能配置中是否存在 accessCode。若存在，告知用户已检测到已保存的访问码，并直接进入托管模式（加载 references/hosted-mode.md，跳过第 1–4 阶段）。不得再次要求用户粘贴该访问码。

若配置中无 accessCode，请向用户询问其希望如何使用 OpenMAIC：

1. 使用托管版 OpenMAIC（推荐快速启动）——需从 open.maic.chat 获取访问码，无需本地配置。
2. 本地运行——克隆代码仓库、配置 provider 密钥，并在本地机器上启动服务。

若用户选择托管模式，请加载 references/hosted-mode.md 并跳过第 1–4 阶段； 若用户选择本地模式，则按常规流程进入第 1 阶段。

1. 克隆或复用现有仓库

加载 references/clone.md。

当用户尚未安装 OpenMAIC，或需要确认应使用哪个本地代码仓库时，使用此步骤。

2. 选择启动模式

加载 references/startup-modes.md。

在确认仓库路径后使用本步骤。列出所有可用的启动模式，推荐其中一种，并等待用户选择。

3. 配置 Provider 密钥

加载 references/provider-keys.md。

在启动教室生成前执行本步骤。推荐一条 provider 配置路径，并明确告知用户需自行编辑的具体配置文件。若后续生成失败（原因包括 provider / 模型 / 认证问题），应回退至此阶段，并指导用户更新相同的服务器端配置文件。

在完成核心大语言模型（LLM）密钥配置后，询问用户是否启用可选功能（网络搜索、图像生成、视频生成、TTS）。每项功能均需独立的 provider 密钥——详见 provider-keys.md 中的“Optional Features”章节。

4. 启动并验证 OpenMAIC

在用户选定启动模式并完成密钥配置后，使用所选方式启动 OpenMAIC，然后通过 GET {url}/api/health 接口验证服务健康状态。

5. 生成教室

加载 references/generate-flow.md。

仅当服务处于健康状态时才执行本步骤。读取本地 PDF 前需请求确认。若用户已明确要求生成教室，则在提交生成任务前无需二次确认；随后进入轮询循环，直至任务成功或失败。生成请求中仅发送受支持的内容字段。对于长时间运行的任务，建议采用稀疏轮询（sparse polling），并在当前对话轮次结束前尚未完成时，提示用户稍后返回查看结果。

回复风格

• 每步操作描述应简明、明确。
• 当用户需做选择时，优先提供 2–3 个具体选项。
• 始终将推荐选项列于首位，并用一句话说明推荐理由。
• 某一步骤完成后，需说明发生了哪些变化，以及下一步需要确认的内容是什么。
• 返回教室链接时，将原始绝对 URL 单独成行输出，不加粗、不使用 Markdown 链接语法、不加代码块格式、不放入表格中。