Novel Studio 是 AI 驱动的网文连载工作台，也是典型的 multi-agent 系统：用户像导演一样定方向与拍板，背后由 Chat Agent、确定性编排器与多个 LLM Worker（规划 / 写作 / QA / 摘要）分工执行。世界观、人物卡、时间线、伏笔线程等以正典（Canon）存储为单一事实源，章节经蓝图 → 写作 → QA → 正典化闭环入库。检索侧以故事状态 RAG为长期目标：MVP 用 L0 精确召回，验证后再叠 L1 语义层，整体为 hybrid RAG 演进路线（见下文「RAG 两层计划」）。
仓库：https://github.com/songzhiyuan98/Novel-Studio （GitHub 公开仓库：A Multi-Agent System for Long-Form Fiction Generation）
基础链路已跑通；部分能力仍在迭代。下表与 README 对齐。
| 能力 | 状态 |
|---|---|
| 与 AI 对话（闲聊、脑暴、意图分类） | 已完成 |
| 章节流水线：方向 → 蓝图 → 写作 → QA → 正典化 | 已完成 |
| 正典记忆：人物、规则、时间线、线程自动追踪 | 已完成 |
| 人物卡分层（core / important / episodic）可编辑 | 已完成 |
| 世界观设定、章节阅读器（场景标记 + 摘要） | 已完成 |
| 多模型：DeepSeek（写作/QA）+ GPT-4o-mini（规划/对话） | 已完成 |
| 成本追踪、编排 Trace（各 Agent 行为可见） | 已完成 |
| 项目模板预设 | 已完成 |
| 按场景重写（Per-scene rewriting） | 后端完成 / 前端待接 |
| 流式输出展示 | 后端完成 / 前端部分 |
| 设定变更的影响分析（Impact analysis） | 计划中 |
与仓库权威一致：docs/superpowers/specs/2026-03-24-core-architecture-design.md（完整设计规范）。下表为站内浓缩版。
RAG 分两层介绍：L0 与 MVP 同交付；L1 在 MVP 验证通过后再引入。当前仓库中另有实验性草案（如
rag-optimization-strategy.md）讨论更细的工程优化，但产品口径以 L0 / L1 两层为准。
| 层级 | 名称 | 阶段 | 一句话 |
|---|---|---|---|
| L0 | 结构化正典召回 | MVP，第一天 | 无向量 / 无嵌入；已确认正典的结构化存储 + 场景卡元数据驱动的精确 ID/键查询 |
| L1 | 语义检索 | MVP 之后 | 基于 embedding 的搜索，补「键匹配找不到」的概念关联；与 L0 并存，只补充、不替代 |
不是通用向量 RAG。正典（Canon）以结构化 JSON 存在于 Canon Store；场景卡（scene
cards）上的结构化注释（characters、locations、threads、callbacks
等）作为数据库查询键，由 Packet Compiler 发起查询，取回匹配的人物状态、世界规则、线程状态等，再按 token 预算装入各 Worker 的 packet。
每次 Worker 调用有固定上下文预算；Packet Compiler 按优先级填充直至用尽：
P0 — Hard constraints（必须包含：当前场景卡、章目标、风格约束、输出契约等） P1 — Current state（几乎总是包含：本章涉及人物/关系状态、活跃线程等） P2 — Recent context（重要：近 3 章摘要 L0、当前卷摘要 L1、近期时间线等） P3 — Distant reference（按需：历史卷摘要、完整世界规则、历史关系变化） P4 — Supplementary（有余量再填：发展链、历史 QA 共性问题等）
各工人类型的字段细分以设计规范与 docs/api-spec.md 为准。
规范中的关键洞察：靠分层摘要 + 状态表，而不是靠 MVP 阶段上向量。
示例（第 350 章、Writer packet 量级示意）：
卷 1–3 卷摘要（Layer 1） 各约 1500 字 近 3 章章摘要（Layer 0） 合计约 1500 字 相关人物状态（实时层） 约 1000 字 活跃线程等 约 500 字 ──────────────────────────────────── 合计约 8000 字 ≈ 约 12K tokens 量级的正典语境
即用约 12K token 量级的正典上下文覆盖极长连载历史；场景卡注释提供了「检索什么」的信号，在 MVP 中替代语义搜索的职责。
增加基于 embedding 的搜索，发现精确键匹配无法覆盖的概念关联。
在以下条件满足前不启动 L1 实现，避免在管线未稳时堆复杂度：
L1 补充 L0，不取代 L0。Packet Compiler 流水线约定为：
1. L0：按场景卡键做结构化查询（始终执行） 2. L1：用语义搜索填充「剩余预算内」的补充语境 3. 合并与去重 4. 在总 token 预算内截断并写入最终 packet
上线 L1 后，若工程上再叠加关键词重排、QA 触发的窄域二次查询等，均视为L1 层内的实现细节，不改变「先 L0、后 L1、再合并」的产品两层口径。
| 角色 | 检索 | 说明 |
|---|---|---|
| Chat Agent | 不直接使用 RAG | 从 Canon Store 取项目摘要等轻量视图，用于对话与意图分类 |
| Planner | L0（+ 未来 L1） | 下一章规划：依赖、callbacks、未解决线程、发展链节点等 |
| Writer | L0（+ 未来 L1） | 当前场景相关正典与近期故事状态；侧重场景内人物状态、关系状态、活跃线程 |
| QA | L0（+ 未来 L1） | 为潜在冲突拉取证据来源；将稿面主张与已确认正典条目对照 |
| Summarizer | 不使用检索 | 输入为完整章文本（+ 规范中要求的角色列表等），由 LLM 压缩并结构化输出 |
核心规范明确：MVP 不包含嵌入 / 向量检索（即不含产品意义上的 L1）；包含 L0 场景卡驱动召回、章级摘要管线、制品版本与状态机等。验收要求包括：第 5 章的上下文 packet 能正确引用第 1 章起已确认设定，且草稿与拒稿不得进入后续 packet。
本站「进行中」指：主线已实现 L0 链路；L1 与更复杂的工程化检索在通过上述门禁后推进，与仓库实现进度以 docs/mvp-todolist.md 为准。
| 平面 | 职责摘要 |
|---|---|
| UX | 对话与选项按钮、编排 Trace、确认/拒绝、制品编辑、状态展示（业务规则不放 UI） |
| Control | Chat Agent（LLM，唯一对用户说话）+ Orchestrator（纯代码：状态机、packet、派发、正典门闸） |
| Knowledge | PostgreSQL：项目、多版本制品、Canon Store（仅已确认：规则、人物状态、关系、章/卷摘要、时间线、线程、发展链等） |
| Generation | Planner / Writer / QA / Summarizer（均为无状态单次调用）；Vercel AI SDK 多提供商；prompt + Zod 输出契约 |
Knowledge 平面以 Canon Store 为中心；MVP 仅启用 L0 结构化召回，L1 语义检索在规范门禁通过后再叠加，见上文「RAG 两层计划」。
User ↔ Chat Agent (GPT-4o-mini) → Orchestrator（确定性代码）
├── Planner (GPT-4o-mini)
├── Writer (DeepSeek)
├── QA (DeepSeek)
└── Summarizer (DeepSeek)
↕
Knowledge：PostgreSQL + Canon Store
关键设计：Orchestrator 是可测试的确定性代码，不是 LLM。工作流路由、状态迁移、packet 组装由代码保证；Worker 不读完整聊天记录、不互相派发，调用链恒为：用户 → Chat → Orchestrator → Worker → 返回。
用户创建项目（标题、类型、基调、梗概等）→ 建库、初始 brief、ProjectTemplate 格式参数、初始 open issues。
可行性评估 → 生成世界规则草案、分层人物卡、关系图、高层大纲、发展链等 → 用户编辑/拒绝/确认 → 写入正典投影。
不确定性可走：编排器内部解析、经 Chat 向用户 1–3 个精准问题、或带「临时假设」继续（非正典直至确认）。设定中途变更可走影响分级（绿/黄/红）与用户确认（规格见设计文档）。
各 Worker 收到不同、紧凑、任务专用的 packet，由 Packet Compiler 在预算内按优先级填充；格式参数（章长、卷规模、风格基线等）一律来自
ProjectTemplate，不在编译逻辑里写死默认值。本节与上文 RAG 两层计划 中的 P0–P4 及 L0→L1 合并策略一致。
P0 — 硬约束（蓝图/场景、目标、输出契约） P1 — 当前状态（人物卡与状态、关系、活跃线程） P2 — 近上下文（近 3 章摘要、当前卷摘要） P3 — 远参考（历史卷摘要、完整世界规则等） P4 — 补充（发展链、历史 QA 等）
Planner / Writer / QA / Summarizer 各有一组约定字段（如 Writer 含绑定蓝图、分场人物状态、style_profile 等）；输出契约统一见仓库 docs/api-spec.md。
向用户追问时遵循最少问题集：一次至多约三个高信息问题，优先可选项/卡片形式。
QA 是叙事一致性的发布门，不是润色装饰：无状态 Worker，输入为编译后的章稿 + 正典相关片段，输出结构化报告。
中高强度问题须带证据引用：source_type、source_id、原文摘录等。
pass / pass_with_notes → 对用户展示 → 可确认正典化revise → 展示问题与建议修复；用户点「修订」视为新一次用户动作（重置任务计数）后回写或 QA 再审block → 阻断直至用户明确处理或大改规划MAX_TASKS_PER_USER_ACTION = 5，MAX_TOKENS_PER_TASK = 50,000，MAX_TOTAL_TOKENS_PER_ACTION = 150,000；典型一章 Plan+Write+QA 为 3 次任务，修订由新动作重置计数，避免无界循环。| 层级 | 选型 |
|---|---|
| Runtime | Node.js + TypeScript |
| LLM | Vercel AI SDK（OpenAI + DeepSeek） |
| 数据库 | PostgreSQL + Drizzle ORM |
| API | Hono |
| 前端 | Next.js 15 + Tailwind CSS |
| Monorepo | pnpm workspace |
| 容器 | Docker Compose |
apps/ api/ # Hono，端口 3001 web/ # Next.js，端口 3002 packages/ core/ # 共享类型 orchestrator/ # 工作流引擎、packet 编译、护栏、正典投影 prompts/ # Prompt 模板 + Zod 输出 schema llm-adapter/ # Vercel AI SDK 封装、多提供商、计 token docs/ # 设计规格、计划、架构
git clone https://github.com/songzhiyuan98/Novel-Studio.git cd Novel-Studio cp .env.example .env # 填写 OPENAI_API_KEY、DEEPSEEK_API_KEY 等 docker compose up -d # PostgreSQL :5432 · API :3001 · Web :3002 # 首次：安装依赖并初始化库表与种子数据 pnpm install cd apps/api DATABASE_URL=postgresql://novel_studio:novel_studio_dev@localhost:5432/novel_studio npx drizzle-kit push DATABASE_URL=postgresql://novel_studio:novel_studio_dev@localhost:5432/novel_studio npx tsx src/db/seed.ts # 浏览器打开 open http://localhost:3002
docker compose up postgres -d cd apps/api && pnpm dev # :3001 cd apps/web && pnpm dev # :3002
| 路径 | 内容 |
|---|---|
docs/superpowers/specs/2026-03-25-design-v2.md |
完整设计 v2（23 条决策） |
docs/mvp-todolist.md |
实现进度 |
docs/data-models.md |
库表 schema（约 17 张表） |
docs/agents.md |
Agent 职责 |
docs/workflow.md |
章节生产工作流 |
docs/api-spec.md |
API 与内部契约 |
本页为个人项目说明摘录，便于展示架构与路线；以仓库内 Markdown 与代码为准。生成内容不构成任何专业建议；使用第三方 LLM 须遵守其服务条款与数据政策。