Hermes Agent 配置 Kimi (Moonshot)：128K-1M 长上下文专用

为什么用 Kimi

Kimi 由 Moonshot AI 开发，是国内最早把长上下文能力做成卖点的大模型。对 Hermes Agent 用户来说，它的价值场景非常清晰：当 GLM-4 / Claude 的 128K-200K 窗口被塞满之后，Kimi-1M 接力。

• 🪟 1M tokens 上下文：相当于一次塞进 ~75 万汉字（约 6 本《三体》）。能放下一个完整中型代码库（10-15 万行）或者 200 页 PDF。
• 🔍 长上下文召回准确率：实测 Kimi-1M 在 500K-1M token 范围的「针刺草堆」（needle-in-haystack）测试中召回准确率 > 95%，明显优于其他国产模型的「128K 名义但 60K 后明显衰减」。
• 🇨🇳 国内访问稳：moonshot.cn 域名直连，北上深首 token 延迟约 400-500ms。和 GLM 一样不需要代理。
• ⚡ Streaming 友好：长输出场景下 Kimi 的流式响应稳定（少抖动、少断流），适合 Hermes Gateway 实时回显场景。

Kimi 不是 GLM 的替代品，而是补充。建议：日常用 GLM-4-Plus，遇到 60K+ 上下文任务切到 Kimi。Hermes 支持多 Provider 同时配置，按需切换。

申请 Moonshot API Key

Moonshot 开放平台和智谱流程相似，5 分钟内可以走完。

1. 1. 注册 Moonshot 开放平台

   访问 https://platform.moonshot.cn → 手机号注册 → 完成实名认证。企业用户走「企业认证」可拿更高的 RPM 上限。

2. 2. 生成并复制 API Key

   登录后 → 账户设置 → API Key 管理 → 新建 API Key。复制 Key（形如 sk-xxxxxx）到密码管理器，Key 仅出现一次。

3. 3. 充值（可选）

   新用户送 15 元免费额度。Kimi-128k 输入约 0.060 元/千 tokens，免费额度大约够 25 万 tokens（约一个中型 PDF）。继续用需要在「财务中心」充值，最低 10 元起。

建议先用试用额度跑一两个长上下文任务感受效果，再决定是否充值。

配置 Hermes 使用 Kimi

Hermes 内置 moonshot 适配器，走官方 OpenAI 兼容接口。3 条命令搞定。

hermes config set provider.moonshot.api_key "你的_KIMI_KEY"

1. 1. 写入 API Key

   上面那条命令一跑，Key 就加密落盘，不会出现在 git diff 里。多 Provider 并存的场景下 Kimi 和 GLM 的 Key 可以同时配置、互不干扰。

2. 2. 选默认模型

   hermes config set provider.moonshot.model moonshot-v1-128k（推荐：128K 上下文 + 性价比最佳）。如果偶尔需要超长场景再切到 moonshot-v1-1m。

3. 3. 切到 Kimi 或保持多 Provider

   想全局切到 Kimi：hermes config set provider moonshot。想保留 GLM 默认、仅在长上下文场景临时用 Kimi：在 Skill 的 meta.yaml 里加 provider_override: moonshot（详见 /skills）。

配置完跑 hermes doctor --provider 自检，5 秒内看到 ✅ 表示通路正常。

模型选择（8k / 32k / 128k / 1M）

Moonshot 当前对外开放 4 档模型，按上下文窗口和价格区分。表面看都是 Kimi，性能与价位差异巨大，选错档可能多花 10 倍钱。

• moonshot-v1-8k：8K 上下文，输入约 0.012 元/千 tokens，输出 0.012。适合短对话、简单分类、原型验证。日常对话场景成本最低。
• moonshot-v1-32k：32K 上下文，输入约 0.024 元/千 tokens。适合中等长度文档摘要、几个文件的 RAG 召回。
• moonshot-v1-128k：128K 上下文，输入约 0.060 元/千 tokens。Hermes Agent 长上下文默认选择，性价比最佳。能塞下一个 5-8 万字的项目文档。
• moonshot-v1-1m（kimi-1m）：1M 上下文，输入约 0.20 元/千 tokens。专用模型，慢且贵但能力强。适合一次性吃下整个代码库或厚合同。需要在控制台「服务开通」页申请开通。
• kimi-k1.5（推理增强版）：偶尔有限时开放，专门处理复杂推理任务，按使用按量计费。

选型建议：默认 moonshot-v1-128k；只有遇到「单次必须 > 80K」的明确场景才升到 1M。最新价格请以 Moonshot 平台「计费说明」页为准 → https://platform.moonshot.cn/docs/pricing 。

长上下文 5 大使用场景

把 Kimi 接入 Hermes 之后，下面 5 类任务是它真正发挥优势的地方。每条都对应一个 Hermes Agent 内置 / 推荐 Skill。

• 场景 1 — 大型代码库整体审计：Skill code-audit + Kimi-1M，一次性把 ~10 万行的项目代码全塞进上下文，让 Agent 找架构问题、循环依赖、安全隐患。GLM-4 这种 60K 后衰减的模型在这种场景下表现不稳定。
• 场景 2 — 长合同 / 法律文档摘要：Skill doc-summarize 配合 Kimi-128k，把 200 页 PDF（约 30 万字）丢进去，输出按章节的摘要 + 关键条款风险点。比分段切片再合并的传统 RAG 准确率高得多。
• 场景 3 — 研究文档多轮对话：Skill research-chat + Kimi-128k，导入一组论文（10-20 篇）后保持多轮对话，Agent 能跨论文交叉引用、保持上下文一致性。Hermes Memory 模块可以把这种长会话压缩到 5K 内重新加载。
• 场景 4 — Skill 串联多文件：Hermes Gateway 在 Kimi 上跑「读 50 个 yaml 配置 → 生成对比表 → 写迁移脚本」这种链式任务时，Kimi-128k 不需要在中间步骤切片，整条链路一次完成。
• 场景 5 — 多轮长对话不丢上下文：Hermes Chat 模式下连续 200+ 轮的对话，Kimi 的 128K 配合 Hermes 自动上下文管理，比 GLM-4 / GPT-4o 在 30 轮之后开始遗忘的体验好得多。

如果你的日常任务都在 60K tokens 以下，没必要切 Kimi——GLM-4-Plus 更便宜、更快。只在「明确需要长上下文」时拉 Kimi 出来用。

常见报错

Kimi 日常使用 4 类报错最常见。挨个排查即可。

• context_length_exceeded / 上下文超长

  原因 / Cause: 当前对话或单次请求的 token 数超过了选定模型的窗口。比如选了 moonshot-v1-8k 但塞进去 12K 的内容。

  修复 / Fix: 两个选择：(a) 升档：hermes config set provider.moonshot.model moonshot-v1-128k；(b) 压缩：hermes context summarize 把历史会话压缩。如果确实需要 > 128K，切到 moonshot-v1-1m。

• Model not found / 模型不可用

  原因 / Cause: 账号没有开通该模型的访问权限。moonshot-v1-1m 默认是「申请制」开通。

  修复 / Fix: Moonshot 控制台 → 服务开通 → 申请开通 1M 模型。审核通常 1-2 个工作日。如果是 128k 之类的常规模型，确认账号已实名认证。

• 401 Invalid API key

  原因 / Cause: Key 复制错误、过期、或者在其他账号下生成。

  修复 / Fix: 重新到控制台生成 Key，跑 hermes config set provider.moonshot.api_key "新KEY"。注意 Moonshot Key 前缀是 sk-，不要漏掉。

• 429 Rate limit / TPM exceeded

  原因 / Cause: Moonshot 按 TPM（tokens per minute）限流，而不只是 RPM。长上下文请求一次就消耗大量 TPM，更容易撞墙。

  修复 / Fix: 到控制台「账户中心」→「速率限制」查看当前 TPM 上限并申请提升。临时方案：hermes config set llm.moonshot.concurrent 1 串行化请求，等业务量上来再付费提额。