拆解 OpenWrite 小说助手：把「写作 Agent」产品化，它到底在架构上做了什么

上一篇文章盘点了一圈开源的写作 Agent（InkOS、Webnovel Writer、oh-story、chinese-novelist）——它们的共同特点是：能力强，但要么要命令行、要么要懂 prompt 工程，是为「愿意折腾的人」准备的。

这次换一个样本：OpenWrite 小说助手，一款面向普通网文作者的商业客户端。它把「AI 长篇连载」做成了下载即用、点鼠标就走的桌面产品，同时还对外开放了一套可自定义的 Skill 技能系统。这篇先花一小节带过它是什么、怎么用，然后从功能的角度逆推它的架构思路——不是搬运官方文档，而是基于教程里能看到的线索（内置 novel-writer skill 的完整 prompt、FAQ 对记忆机制的自述、各个操作流程），反推它做了哪些关键设计决策。

声明：本文非 OpenWrite 官方技术文档，属「产品架构读解」。凡教程里明确写到的我标注为事实；推断处会说明理由。依据的内部源文档：《OpenWrite 小说助手 - 使用教程》（见仓库 source/）。

一、它是什么：给「作者」而不是给「程序员」的写作 Agent

一句话定位：一个集成多模型、自带 Skill 技能系统、用「文件即记忆」保证长篇连贯的开放式 AI 写作客户端。功能页上十几项能力，拆开看就是「写 + 存 + 查 + 试」四件事：

面向	功能	一句话
写	智能写作 / 项目管理	对话式创作；一本书自动分成人物库、世界观、章节等文件
存	长期记忆 / 云同步	Skill 内建「更新文档」写回记忆；WebDAV 多端同步备份
查	扫榜 / 拆解 / 联网 / 起名	番茄·起点榜单、网络小说章节拆解、同人资料检索、名称生成
试	抽卡 / 风格蒸馏 / Skill 广场	一次多回复挑最佳、蒸馏他人风格、自造并分享工作流

上手路径很「轻」，四条就够走通：

1. 配置模型 —— 三选一：套餐模型（官方 API）、公益模型（免费限流，仅体验）、自定义（填 OpenAI / Anthropic 兼容的 key 与地址）。
2. 创建小说项目 —— 对话里说「创建新小说」，AI 引导你补书名类型、主要人物、世界观；可以中途打断直接给信息。
3. 写作 —— 给详细章纲让 AI 生成正文，不满意让它改或直接重生成。
4. 保存与同步 —— 每写完一章手动保存（AI 自动保存会整章重输出一遍，慢且耗次数），再对 AI 说「更新文档」：它会补写章节摘要、同步人物库、完善世界观、记录进度。

两条写在教程里的「纪律」其实是架构暗示，后面会展开：每一章建议新开对话窗口、永远给 AI 详细章纲而不是让它自由发挥。

二、先看全景：功能很多，但背后的机制只有几种

我读教程时最大的感受是：这产品不像大多数「大模型套壳」那样一个 prompt 打天下，也不像开源项目那样把复杂度摊给用户。它把一套典型的 Agent 运行时藏进了客户端，功能是表象，落到架构上只有 5 层。

分层结构用 D2 的容器嵌套最直观（这是 D2 相对 mermaid 的表现力主场）：

对照功能表，每个功能几乎都能归到某一层、某一种机制上：

• 智能写作 / 创建新书 / 更新文档 → 都是 novel-writer 这一个 skill 的不同分支（写、初始化、同步）。
• 长期连贯 → 不是模型强，而是记忆层的文件读写在承接。
• 起名 / 拆解 / 扫榜 / 联网 / 终端 → 是挂在 Agent 上的独立工具调用，与「写作工作流」解耦。
• 抽卡 / 风格蒸馏 → 是采样策略与风格样本注入，属于生成侧技巧。
• 多模型 / 公益 / 自定义 → 全收口到一层模型抽象，业务代码只认「OpenAI / Anthropic 兼容」两种格式。

后面三到六节就挑其中**最能解释「为什么它能写长篇还不断片」**的三层展开：记忆、Skill、上下文交互。

三、记忆设计：把「记得住 200 章」落成文件系统

教程里的三条线索

1. 默认 skill 的 prompt（教程把 novel-writer 全文贴了出来）：写新章节前，按序读 小说资料/人物库.md → 世界观.md → 章节摘要.md，再看 章节内容/ 目录里最近更新的五章。
2. FAQ「开新窗口是否影响记忆」的自述最直白：每章会保存成 md 文件，说「同步文档」后，AI 会提取章节内容去补充人物库、世界观、章节摘要——所以开新窗口只要按原思路给章纲就能接着写。
3. FAQ「每本书绑定的对话和备忘录都不同」：对话、备忘录都以「书」为边界做沙箱，切换书就切一套记忆。

三条线索指向同一个结论：**它的长期记忆根本不放在对话里，而是放在「一本书 = 一个目录」的文件结构里。**我把它画成三层：

三个层级的取舍很值得抄：

• 对话窗口 = 易失的「工作内存」。写完一章就建议关掉重开，因为 AI 的注意力会被越滚越长的历史稀释——与其靠模型硬扛长上下文，不如把上下文长度当成一种要主动管理的预算，用完了就清零重开。
• 章节正文 = 持久化的「产品」。每一章一落盘就变成确定性的、可被检索的文件，不再依赖任何一次对话。手动保存优先于 AI 自动保存，本质是「确定性的写盘优先于让模型自己复述」——省 token 也省出错。
• 维护文档 = 刻意维护的「长期记忆」。人物库 / 世界观是结构化设定，章节摘要是对全书情节的压缩——教程里原话是「摘要相当于记忆，让 AI 知道前面发生了什么」。

为什么这套能扛住长篇

静态分层只能说明「文件存在」，真正让它连载不跑偏的是「写完就回写」的动作。跨窗口、跨模型、跨几天续写，全靠这一个循环。这里有时序，用 mermaid sequence 表达比 d2 更清楚：

拆开看，它其实用到了三个经典模式，只是实现得极其朴素：

• 摘要压缩（hierarchical summary）：正文无限增长，但每次只把「最新章节提炼出的要点」累加进 章节摘要.md，等于全书脉络被持续压缩成一份可以全文塞进上下文的文档。用摘要换长度。
• 局部滑窗（sliding window）：写作时只喂「最近 5 章」而不是全书——保证近期细节与文风连续，又不撑爆上下文。目录不够 5 章就全读，逻辑很干净。
• 写后回写（checkpoint / write-back）：每章结束的「更新文档」是记忆的写入点。注意它是作者触发的，而不是每轮对话自动发生——把「什么时候固化」这个决策交给最在意内容的人。这很反直觉但很实用：自动回写省心，手动回写可控、且省次数。

这套设计的精髓在于没有上向量库 / RAG——对小说这种「结构化设定 + 顺序正文」的数据，一份压缩摘要 + 一份滑窗，配合确定性文件读写，比语义检索更便宜、更可预期。工具与场景匹配，是它值得学的地方。

四、Skill 系统：把「Agent 工作流」做成用户可编辑的卡片

内置 skill 长什么样

教程里 novel-writer 的完整内容透露了 skill 的形态——本质上是一段**「何时用 + 怎么做」的结构化说明**：

# 小说写作助手
当用户要求：写小说/写新章节/续写章节/同步文档/初始化新书时使用

Step 1: 按序读取维护文档（人物库 → 世界观 → 章节摘要）
Step 2: 读取最近更新的五个章节（不足则读全部）
Step 3: 依据摘要情节点 + 人物 + 世界观 + 最近五章走向 + 用户要求创作
……同步模式：读最新章节 → 生成本章摘要 → 征求确认后更新 → 回写人物库/世界观

这和 Claude Code 的 skill / Agent SDK 的 skill 在思路上同构：一段「触发描述 + 步骤清单」成为可路由、可执行、可复用的原语。模型读它 = 拿到一份临时「操作手册」，app 读它 = 知道该在什么意图下加载哪张卡片。

对我最有信息量的不是 skill 本身，而是它暴露出的两个设计选择：

1. Skill 是用户可读、可改、可停用的。设置里能看到每个 skill 的工作流，随意编辑——等于把 Agent 的「行为代码」开放给了用户。用户不一定懂技术，但「把触发词和步骤改成人话」这个门槛低到普通作者能摸。
2. 默认内置了 skill-creator（技能创造），让 AI 自己写 skill。教程给的演示是：作者说「帮我建一个检查分段的 skill：每句一段、超过 15 字按逗号分段」——AI 就直接生成了一张新卡片，作者后续只需说 @检查分段 就能触发。

skill-creator：让 Agent 生成 Agent

这层「元能力」值得单独画一张图，因为它把 Skill 从「内置功能」升级成了可自举的生态：

这条链路对产品很重要：

• skil-creator 是自举的：skill 能生成 skill，用户表达需求的方式永远是最自然的「描述我要什么」，而不是学一套 DSL。工具链的可编程性被包装成了对话。
• 触发是显式 + 隐式双通道：既能自然说出（命中触发词），也能在输入框 @skill 强制指名——保证用户有能力绕过路由猜错，这是 Agent 类产品很关键的逃生门。
• Skill 广场 = 生态飞轮：卡片可上传分享、可下载安装，连「小说下载器」（依赖 Python 环境）这类偏门工具都在广场流通——工作流本身成了可交易的商品，平台靠 UGC 摊薄长尾需求。

五、上下文工程：把「检索」和「窗口管理」做成人能看懂的操作

如果说记忆层是「写长篇的骨架」，那这一层是「让作者能亲手控制模型注意力」的交互设计。教程里几个零散功能，凑起来是一套完整的上下文管理观：

• @skill 与 #file = 人在环路的显式检索。@ 指名让哪个 skill 干活、# 指名读哪个文件，例如「@chapter-reviewer 检查 #第一章.md 有没有问题」。这等于把 RAG 的「检索哪段」从自动变成用户可拍板——对小说这种「哪个伏笔重要」只有作者才知道的场景，显式注入往往比自动召回更准。
• 「每章新开窗口」= 主动的上下文重置。FAQ 反复强调新窗口不影响记忆，因为记忆在文件里、不在对话里。它把「清空工作内存」从一种不得已（上下文爆了）变成一种推荐操作（每章都清一次）。
• 「对话接近上限提醒压缩」= 上下文预算被当成一等公民。FAQ 甚至点名公益 deepseek 是 200K、设置里能调上下文参数——说明产品在显式管理 context 长度上限，而不是等模型自己截断。越强的模型上下文越大、越贵，这是产品明面上要优化的成本。
• 抽卡模式 = best-of-N 采样。开启骰子按钮后一次生成多份回复、从中挑一份满意的。它的一个小提示很见架构功力：抽卡前先让 AI 读完资料再抽——否则 N 个窗口会并行各读一遍资料，次数翻倍。说明这 N 路是并行发起的、共享读档的，厂商很清楚多路采样对 token 消耗的放大效应。

六、工具层：写作 Agent 的第二类能力

记忆和 Skill 管「怎么写」，工具层管「写什么、写得像谁」。教程把工具做成独立能力，挂在整个 Agent 之外，本质是几种常见外挂的拼装：

工具	本质	支撑什么
起名	批量生成器	人名/地名/功法/门派/兵器/法宝
风格蒸馏	风格样本 few-shot	「用 xx 风格写」——把他人或自己的风格固化成可复用的提示素材
小说拆解	语料检索 + 结构化提炼	搜索或导入网文、一键拆章节，快速读剧情 / 找灵感
网文扫榜	榜单数据检索	番茄/起点 30+ 榜单、五万本新书热榜，辅助选题与市场判断
联网搜索	Web 检索（套 AnySearch）	同人题材资料查询；免费额度有限，填 key 提到千次/天
终端（限 PC）	本地执行	AI 跑脚本、操作文件——进阶玩法

注意一个产品化细节：「风格蒸馏 / 小说拆解 / 联网搜索」恰好是会员才解锁的功能。这不是随意划分——这几个是最吃外部资源（要跑语料、要跑搜索）或最高价值的能力，拿来当付费墙最自然。能力分层 = 成本分层，这是商业 Agent 产品很典型的分层逻辑。

七、放在那批开源写作 Agent 的光谱里

和上一篇盘点的开源项目对照，OpenWrite 恰好站在光谱另一头：

维度	InkOS（工程派）	Webnovel Writer（一致性命门）	OpenWrite（产品派）
用户	愿意跑命令行的开发者	Claude Code 用户	不写代码的网文作者
记忆	7 个「真相文件」	RAG + 实体图谱	md 文件 + 摘要压缩 + 滑窗
工作流	多 Agent 接力管线	/webnovel-write 一条龙	Skill 卡片，用户可改
上下文控制	自动编排	自动检索	把控制权交还给作者（@/#、新窗口、手动同步）

最值得琢磨的是最后一行。开源工具倾向于把「记忆、检索、编排」做得越自动越好；OpenWrite 反其道，把几个关键控制点显式暴露给作者：什么时候固化记忆（手动同步）、每章读多宽（最近 5 章）是定死的、让模型看哪些文件（@/# 强指）、什么时候重置上下文（新开窗口）。对一个把「你负责讲故事」当产品信条的写作工具来说，这可能是比「更聪明的 Agent」更重要的设计——确定性优于智能，作者可控优于全自动。

顺带一提它的商业模式也印证了这套架构的分层：模型层卖套餐（满血模型、按次计费、一 key 通吃）、能力层卖会员（蒸馏/拆解/联网）、公益与自定义当引流入口——每一层都能单独定价，得益于一开始就把系统按这五层切开了。

可复用的设计清单（如果我要抄）：

1. 长文记忆别急着上向量库——结构化文件 + 摘要压缩 + 局部滑窗在多数场景下够用且好懂。
2. 记忆要有显式写回点，且尽量交给人触发，省次数也保正确。
3. 把 Agent 工作流做成用户可读可改的卡片，再用一个「skill-creator」让 Agent 自己产卡片，生态就长出来了。
4. 给作者留好强制指定的逃生门（@skill / #file），别把一切交给路由猜测。
5. 把上下文长度当成要管理的预算：到点提醒、可重置、开新窗不掉记忆——因为记忆不放在上下文里。

参考

• 内部共享源文档：《OpenWrite 小说助手 - 使用教程》（仓库 source/，含内置 skill 全文、功能说明、FAQ 与写作技巧）
• 教程内另附 B 站视频教程（原理详解 / 创建 skill / 工具使用 / 抽卡模式 等）与套餐·会员说明