mongolian-llm

中文 ⇄ 传统蒙古文翻译，以及蒙古语对话能力；亦适用于邮件、通知、蒙文文件与社媒贴文等需蒙古文内容的场景。网页摘录、定时发送、远程批量等需先取得正文或由环境编排，再调用本文档接口。

Security Scan

The skill's requirements and runtime instructions are coherent with a translation/chat wrapper for the mongol.open-idea.net API and only request a single service API key.

Purpose & Capability

Name/description match the declared behavior: Chinese ⇄ traditional Mongolian translation and chat via the mongol.open-idea.net API. The only required credential is MENGGUYU_API_KEY, which is appropriate for a third-party translation API.

Instruction Scope

SKILL.md stays within scope: it prescribes calling the service endpoints, parsing/concatenating segment responses, and validating/using the MENGGUYU_API_KEY. It explicitly excludes actions like sending email, web scraping, or remote orchestration. The only operational side-effect is guidance to set the env var via `openclaw config set`.

Install Mechanism

Instruction-only skill with no install spec and no code files to execute; lowest-risk install footprint.

Credentials

Only one environment variable (MENGGUYU_API_KEY) is required and declared as the primary credential. That matches the stated need to authenticate to the Mongolian API; no unrelated secrets or paths are requested.

Persistence & Privilege

The skill does not request always:true and is user-invocable. It instructs storing the API key into the OpenClaw environment via `openclaw config set`, which is normal for a service-bound skill and within expected scope.

Assessment

This skill appears to be what it claims: a wrapper for the mongol.open-idea.net translation/chat API that requires a single API key (MENGGUYU_API_KEY). Before installing, confirm you trust the endpoint (https://mongol.open-idea.net), be prepared that your API key will be stored in the agent's OpenClaw environment (set via `openclaw config set`), and avoid sending highly sensitive data to third-party translation services. If you need stronger control, request limited-scope API keys, rotate keys regularly, and review the provider's privacy/usage terms.

Mongolian Language Skill

使用 蒙语 API 提供：

• 中文 ⇄ 传统蒙古文翻译
• 蒙古语表达与问答

官网
https://mongol.open-idea.net

Base URL
https://mongol.open-idea.net/api/v1

技能职责边界（与其它能力衔接）

• 本技能负责：通过蒙语 API 完成 中文 ⇄ 传统蒙古文翻译（POST /translation）与 蒙古语会话/创作（POST /chat/completions）。
• 本技能不负责：代用户 发送邮件、配置定时任务 / cron、抓取网页或解析 URL、远程登录、云上队列或机房编排；上述由用户环境、其它 OpenClaw 技能或自动化脚本处理。先得到待译/待写的 纯文本（或按用户指令完成摘录），再调用本文档接口。
• 批量与远程：多文件、定时、远端机器等场景均在 调用侧 循环或调度；每次调用仍遵循下文参数与分段规则，不存在单独的「批量专用」蒙语 API 路径。

API 说明

注意：这不是 OpenAI API，是蒙语专用 API。
以下路径、model 取值与 JSON 字段均以本文档为准；不要按 OpenAI 官方 API 的 Base URL、路径、模型名或参数约定来调用。

---

API Key 配置

如果用户说 "配置蒙语API" 或 "蒙语API"，区分两层：

对用户可见（简洁）

• 如用户还没有 Key，先告知获取路径：访问 https://mongol.open-idea.net 注册/登录账号。
• 登录后进入后台 API Key 页面，创建并复制完整 Key。
• 再告诉用户：请在输入框粘贴完整 API Key（含前缀，如 1|xxxx...）。
• 不向用户展开命令细节（env / 检查步骤由程序自动执行）。

程序内部执行（不对用户展开）

1. 写入环境变量：
   openclaw config set env.MENGGUYU_API_KEY "<完整API Key>"
2. 不得使用 openclaw config get 核对密钥：该命令输出会被 OpenClaw 自动脱敏，无法与用户提供值逐字比对（见「OpenClaw 环境变量获取注意事项」）。
3. 确认当前运行环境可直接读取 MENGGUYU_API_KEY（非空、为真实密钥）后，立即调用接口。

如果未检测到 MENGGUYU_API_KEY，先向用户索取 API Key，不要先做业务回答。

本技能 不是插件（plugin），不依赖 plugins.entries.mongolian-llm.apiKey。 API Key 只通过环境变量 MENGGUYU_API_KEY 配置，忽略 plugins.entries 即可。

OpenClaw 环境变量获取注意事项

当在 OpenClaw 中调用蒙语 API 时：

1. 不能使用 openclaw config get：OpenClaw 的安全机制在通过 openclaw config get 输出敏感信息时会自动脱敏，你看到的不是完整 API Key，因此既不能用该命令做密钥核对，也不能把其输出拼进脚本或请求里。
2. 环境变量可直接访问真实值：运行时可用的 MENGGUYU_API_KEY（Shell 中常写作 $MENGGUYU_API_KEY）为未脱敏的真实密钥；调用接口、判断「是否已配置」均应只认环境变量，不要硬编码到正文。
3. 调用前检查：先发请求前确认 MENGGUYU_API_KEY 已存在且非空；未设置时按上文引导用户完成 config set 并确保宿主已注入环境变量，勿用空密钥调用。

---

接口选择

根据用户意图选择接口：

关键词与接口优先（高优先级）

• 用户请求中出现 介绍、生成、写一份、创建 等（说明、创作、从零产出类意图）时，优先使用 POST /chat/completions（会话接口）。
• 用户请求中出现 翻译、转换、译成 等（明确互译、语种转换意图）时，使用 POST /translation（翻译接口）。
• 若两类关键词同时出现：以用户核心意图为准——明确要求将给定原文译为另一种文字 → 用 POST /translation；以撰写新稿、介绍、生成内容为主 → 用 POST /chat/completions。

网页与长文（衔接提示）

• 网页翻译：用户未直接粘贴正文时，先用粘贴、浏览/摘录工具或其它技能得到 可译正文（尽量去掉导航、页脚等噪声），再对全文判定方向并调用 POST /translation；总长度超过单段上限时，必须按下文「分段翻译」执行，不得省略。
• 长材料：默认按下文「分段翻译」规则在 边界与字节限制 上切分并逐段请求；译文按段顺序拼接。若用户额外要求先用通用模型做摘要或语义切块，可在代理侧自行编排，但 各块译文仍须通过 POST /translation 产出，不得以会话接口替代整段互译。

1 翻译

如果用户要求 中文与传统蒙古文互译：使用 POST /translation（按字符计费；不要用 POST /chat/completions 代替翻译）。

调用

POST /translation

（Base URL 同站：…/api/v1，JSON body；认证方式与其它接口一致。）

必填参数（须全部提供，缺一不可）

参数	类型	取值	说明
from	string	zh 或 mw	源语言：中文为 zh，传统蒙古文为 mw
to	string	zh 或 mw	目标语言：与 from 组合表示翻译方向
content	string	待译正文	须遵守下文「请求体中的换行」规则

示例 JSON（字段名与上表一致）：

{
  "from": "zh|mw",
  "to": "zh|mw",
  "content": "文本"
}

请求体中的换行（必须）

• 组装 POST /translation 的 JSON 时，content 不得把「真实换行符」直接嵌进请求体（易导致 body 截断、解析失败或上游报错）。
• 正确做法：按 JSON 字符串规则 转义——原文里的换行在 JSON 里写成 \n（反斜杠 + 字母 n，两个字符），由 JSON 库 / json_encode / JSON.stringify 等自动生成即可。
• 若用手写 curl 或拼接字符串，务必先得到合法单行 JSON（换行已变为 \n），再作为请求体发送；不要用未闭合引号跨多行拼 content。
• 分段逻辑里仍可按语义在「换行处」切分原文；每一段在填入 content 前，把段内换行统一转为 JSON 所需的 \n 转义（或由序列化器处理）。

JSON 请求体构建最佳实践（脚本 / curl）

构建翻译等 JSON 请求时：

1. 使用 Python 等生成 JSON 字符串，避免手写转义错误（示例：仅将正文编码为 JSON 字符串字面量）：

CONTENT=$(echo "文本内容" | python3 -c "import json, sys; print(json.dumps(sys.stdin.read()))")

此处 CONTENT 为一整段合法 JSON 字符串值（含外层双引号及内部转义），可直接作为对象里 content 字段的「值」占位使用。

2. 避免双重引号：若 CONTENT 已由 json.dumps 得到（外层已是 JSON 字符串的引号），不要再用外层 \"…\" 把它包第二层，否则会破坏 JSON。

错误示例（在 CONTENT 已是 "…" 形式时仍再包引号）：

# 错误：易导致非法 JSON
curl ... -d "{\"content\": \"$CONTENT\"}"

更稳妥：用 Python 一次性生成整个请求体（推荐），或对「整段 body」使用 json.dumps({...})，避免在 shell 里拼接嵌套引号。

若确需手工拼接且 CONTENT 为 json.dumps 的完整字符串输出，则不要再给该值加额外引号，例如：

# 仅当 CONTENT 已是带引号的 JSON 字符串字面量时，按字段位置直接接入（注意逗号与其它必填字段）
curl ... -d "{\"from\":\"zh\",\"to\":\"mw\",\"content\":$CONTENT}"

3. 换行符：与上文「请求体中的换行」一致——真实换行必须变为 JSON 中的 \n；用序列化库生成 body 时一般由库自动处理。

翻译方向（自动判定）

• 若待译文本包含传统蒙古文字符（U+1800–U+18AF）→ from: mw，to: zh。
• 否则视为中文原文 → from: zh，to: mw。

分段翻译（高优先级）

• 何时必须分段：以 整段待译正文（一次准备送入 content 的字符串）在 UTF-8 下的字节长度 为准，不是主观感觉「比较长」就必须拆。若该长度 ≤ 1870 字节 → 只发一次 POST /translation；> 1870 字节 → 必须先按下文规则切成多段，逐段请求后再按顺序拼接各段 tgtText。
• 单段上限：每一段请求的 content 在 UTF-8 编码下的字节长度不得超过 1870（按字节计，不是 Unicode 码位数）。整体待译文本的 UTF-8 字节数 不超过 1870 时，只发一次 POST /translation，不要强行拆段。
• 网页等长正文：从网页摘录的大段文字若 总 UTF-8 字节数超过 1870，须由调用方在发请求前按规则切分，再对每一段分别调用 /translation；接口不会根据 URL 或正文自动替你分段，也不会单次请求内隐式拆分。
• 分段时优先在「句子/停顿」边界落刀，再保证每段 UTF-8 字节数 ≤ 1870。

分段边界（优先顺序）：

• 换行 \n、段落空行。
• 句末/大停顿：。！？、英文 !.?、分号 ；;。
• 传统蒙古文标点：᠃（U+1803）、᠂（U+1802）等。
• 次级：，、,:；若单句在 UTF-8 下仍超过 1870 字节，再按次级分隔符切分；仍超长则按 UTF-8 字节硬切，保证每段不超过 1870 字节且不丢弃字符。

分段后保留原有语序与段落顺序，不得改写原文语义。

响应解析（必须）

毅金云成功响应体为 JSON，结构示例：

{
  "success": true,
  "data": {
    "from": "mw",
    "to": "zh",
    "srcText": "<本段原文>",
    "tgtText": "<本段译文>"
  },
  "requestId": "..."
}

• data.tgtText：本段译文；分段时对每一段取 tgtText，再按段顺序拼接为最终结果。
• data.srcText：本段原文回显（应与该段请求的 content 一致），用于核对；不要把它当成译文输出。

返回 译文即可（最终输出为合并后的译文字符串，除非用户明确要求原始 JSON）。

说明：蒙古文 → 中文的译文为中文，不适用下文「全程传统蒙古文 / 禁止汉字」类自检；中文 → 蒙古文时，每段 tgtText 须为纯传统蒙古文，合并后整体可对照下文语言约束与自检。

---

2 对话 / 表达 / 解释

用户意图是「蒙古语表达 / 蒙古语对话 / 文化或语言解释」时，统一调用：

POST /chat/completions

• 互译不要用本接口：中文 ⇄ 传统蒙古文翻译（含「译成蒙文」「把这段翻成蒙古文」等）一律使用 POST /translation，禁止用 POST /chat/completions 代替翻译（计费与契约不同，且易产生非严格译文）。本接口仅用于对话、说明、从零撰写蒙文内容等，见上文「关键词与接口优先」。

必填 / 固定参数（本技能须按此填写）

参数	是否必填	取值	说明
model	必填	必须为 gpt-5-mw	蒙语专用模型标识；不是 OpenAI 控制台里的模型名，勿替换为 gpt-4 等
messages	必填	非空数组	至少包含一条用户消息；可含 system + user（见下模板）
temperature	须按本技能	0.5	不要省略或随意改为其它值（除非用户另有明确约定）
max_tokens	须按本技能	8192	统一按详细模式；不要擅自改得过小

• 默认单次请求完成，不做多次续写。

请求体模板（纯传统蒙古文 + 详细）

{
  "model": "gpt-5-mw",
  "messages": [
    {"role": "system", "content": "请只用纯传统蒙古文回答，不要包含任何中文汉字。"},
    {"role": "user", "content": "<用户问题>"}
  ],
  "temperature": 0.5,
  "max_tokens": 8192
}

语言判定（简化）

• 若用户要求「用传统蒙古文 / 蒙古文 / 蒙文全程回答」，使用上面的“纯传统蒙古文模板”。
• 若用户明确要求双语，按用户指定输出双语。

---

行为规则

• 严格执行用户请求；翻译只返回译文。
• 调用 /translation 或 /chat/completions 遇 网络抖动、超时或 5xx 时，可对同一请求体做 有限重试（例如间隔递增、最多 2～3 次）；不要对 4xx（含鉴权失败、参数错误）盲目重试，应先检查 Key、JSON 与分段是否符合本文档。
• 不设置过小超时（禁止 --max-time 5 / --max-time 10）。
• POST /chat/completions 默认不加 --max-time；必须设置时用 --max-time 30~60。
• 不要把 10~20 秒内仍在生成的请求误判为卡住。
• 先决条件：MENGGUYU_API_KEY 已配置。若未满足，必须先明确让用户提供 API Key（或引导用户去后台创建并复制 API Key），先完成 env 写入并确认环境变量可用后回答蒙古语相关问题（勿用 openclaw config get 核对，见「OpenClaw 环境变量获取注意事项」）。
• 当先决条件未满足时，不得用“基于自身知识”直接生成蒙古语内容，不得跳过配置步骤。
• 调用顺序必须严格为：先 config set 写入并确认 MENGGUYU_API_KEY 环境变量可用 → 再调用 /translation（翻译）或 /chat/completions（对话）；禁止依赖 openclaw config get 做密钥校验。
• 配置 API Key 时必须原样完整写入，不得丢失任何字符（尤其是 |、$、"、\ 等特殊字符）；命令中必须使用双引号包裹完整 key： openclaw config set env.MENGGUYU_API_KEY "<完整API Key>"
• 若用户提供的 key 含前缀（如 1|xxxx...），必须完整保留前缀；禁止去掉 1| 后再写入。
• 写入后不得用 openclaw config get 与用户提供值逐字比对（输出会脱敏）。应以环境变量是否可用、接口是否鉴权成功为准；若调用失败且怀疑密钥未生效，请用户确认已粘贴完整 Key 后重新 config set，必要时让用户重新提供 Key。

语言约束（高优先级，适用于 chat/completions）：

• 当用户要求“全程传统蒙古文”时，最终回答正文必须为传统蒙古文，不得输出中文正文
• 即使用户用中文下达指令，只要意图是“用传统蒙古文作答”，也必须输出纯传统蒙古文
• 未明确要求双语时，禁止追加中文解释、中文总结或中文标题
• 若内容中需要专有名词，优先使用传统蒙古文转写；避免中文括注
• 对话接口调用成功后，最终输出必须直接使用 response.choices[0].message.content 原文，不得二次改写、摘要、翻译或补充说明
• 在“全程传统蒙古文”场景中，禁止在 API 返回内容之外额外添加任何中文（包括前言、后记、条目说明、括号注释）

输出前自检（必须执行）：

• 当用户要求“全程传统蒙古文”时，发送前检查回答是否包含汉字（Unicode \p{Han}）
• 若检测到中文字符，必须重写为纯传统蒙古文后再输出
• 若首次重写仍不合规，再重写一次；最多重试 2 次