Narratium 角色扮演客户端配置

先说结论:Narratium 要的三个值

Narratium 的模型连接就是标准的 OpenAI 兼容三件套,填在它的 API 设置里:一个 Base URL、一个 API Key、一个模型名。对着 kkaiapi 就是 https://api.kkaiapi.com/v1、你的 sk- 开头密钥,以及目录里任意一个 ID,日常起步用 deepseek-v4-flash 就够。项目 README 推荐的正是这一类连接:直接接 OpenAI 格式 API、接一个多模型统一端点求个模型多样性,或者用 Ollama、LM Studio 跑本地模型,配置界面是同一套。 不同版本和 Web 构建里具体字段标签会有出入,标签宽松对待就好,数值要精确:URL 到 /v1 为止,Key 粘贴时不带空格,模型 ID 和目录字符串一字不差。

Base URL:  https://api.kkaiapi.com/v1
API Key:   sk-你的kkaiapi密钥
模型:      deepseek-v4-flash   (精确填写,目录里任意 ID 都行)

Narratium 是什么,现状如实说

Narratium(GitHub 上的 Narratium/Narratium.ai)自我定位是"角色扮演界的 VSCode":一个开源的 AI 叙事、世界观构建、长篇互动小说客户端,支持酒馆(SillyTavern)格式角色卡、记忆持久化、插件系统。代码用 AGPL 协议开源,很快聚起一批真实用户,至今仍是这个赛道里比较有意思的开源客户端之一。 现在说多数配置教程会略过的部分:GitHub 仓库已经归档、只读(归档日期显示为 2026 年 3 月 30 日)。归档不等于不能用,代码照样跑得和被冻结那天一样好,但意味着没有维护者再推送修复、依赖更新或安全补丁,和这个项目关联的托管实例应该被当作"尽力而为"看待。如果你今天决定继续用 Narratium,靠谱的做法是从源码或某个 release 自己部署,现实的预期是一个功能不再变化的冻结版本。 这个现状恰好让 API 建议变得更明确:一个客户端不会再动了,这正是你希望模型这一侧保持灵活的时刻。Narratium 没法再接入新的厂商集成,但它已经会说的 OpenAI 兼容协议,能持续服务这个端点背后新出现的任何模型。网关模式相当于给一个不再迭代的客户端续了命。

接入步骤

排查思路遵循通用模式:先用 curl 验证这三个值,如果 curl 成功而应用失败,常见原因是 URL 多了段路径、Key 里带了空格,或者 Web 构建被浏览器 CORS 拦了,能在开发者控制台里看到。既然没有维护者会再修客户端侧的怪癖,curl 优先的习惯在这里格外重要:它能立刻告诉你哪一侧是你还能真正动手解决的。

• 先把 Narratium 跑起来:从 GitHub 源码或某个 release 自建(仓库只读但完全可以克隆),或者用一个你信任的、仍在运行的托管实例
• 打开设置,找到 API / LLM 配置区域
• 连接类型选 OpenAI 格式而不是 Ollama,因为你要连的是一个托管端点
• 填入 Base URL https://api.kkaiapi.com/v1,粘贴你的 Key
• 精确填写模型 ID:起步用 deepseek-v4-flash
• 保存,在一个新故事里发一条短消息确认链路走通

角色卡、世界观,以及离开时能带走什么

Narratium 支持酒馆兼容的角色卡格式,这是关于它最重要的一条兼容性事实。你的角色是可移植的产物:别处写的卡能导入进来,花在人设和世界书上的功夫不会锁死在一个已经停止开发的客户端里。如果以后要迁移,SillyTavern、RisuAI、Wyvern 都说同一套卡片谱系,后面链接的配置页各自覆盖。 同样的可移植逻辑也适用于模型这一侧。因为 Narratium 说的是通用的 /v1 端点,你的供应商配置和 Narratium 本身没有任何绑定:同一个 Key 和 Base URL 原封不动地丢进任何其它前端都能用。角色卡可移植加上端点可移植,整套栈的迁移成本几乎为零,这也是对待任何一个你还在用、但已经归档的项目应有的姿态。

给 Narratium 长篇叙事风格选模型

Narratium 的设计核心是长篇分支叙事,这让模型选择更看重长程一致性而不是单次爆发力。deepseek-v4-flash 用目录里最低的价格撑住日常会话,对话质量被角色扮演社区公认超过它的价位。glm-5 和 kimi-k2.6 用来换换口味,detail 密集的章节值得用 kimi-k2.6 的长程指令遵循能力换一点推理延迟。claude-sonnet-4-6 是普通向文笔的安全上限,留给真正配得上的章节。 因为前端每一轮都会重发故事上下文,输入 token 主导成本,一个刻意收窄的工作窗口比一个拉满的窗口更划算,下面的价格表里能看到具体数字。内容政策这件事不受任何配置影响:模型自身的政策和相关平台条款照常适用,这也是本文一直强调如实说明的地方。

主力模型价格

价格按 kkaiapi 中文区实时价格计算,单位 ¥/1M tokens(输入/输出)。

一个归档项目到底值不值得继续用

既然这页无论如何都是配置教程,不妨算一笔诚实的账。支持的一面:代码开源,界面对结构化长篇叙事确实好用,角色卡进出都可移植,通用端点让模型这一侧永远保持最新。反对的一面:没有安全补丁,没有 bug 修复,依赖会原地老化,任何托管实例都是在借来的时间上运行。对于本地跑、接一个按量计费 Key 的个人爱好场景,这个风险画像多数人能接受;对于有其他用户或涉及敏感数据的场景,就不行。 折中路线正是这页一直在讲的那条:自己部署,把投入沉淀在可移植的层面(角色卡、世界书、端点)上,把客户端本身当成可替换的一层。这个赛道里的前端来来去去,靠可移植角色卡和一个稳定 /v1 端点撑起的故事,能活得比任何一个前端都久。

常见问题