From be075f0d1597c21839cd42065f9f18912c193d3b Mon Sep 17 00:00:00 2001 From: halleck Date: Thu, 13 Aug 2026 05:40:33 +0800 Subject: [PATCH 1/5] =?UTF-8?q?docs(novel):=20=E5=B0=8F=E8=AF=B4=E5=86=99?= =?UTF-8?q?=E4=BD=9C=E7=B3=BB=E7=BB=9F=E8=AE=BE=E8=AE=A1=E6=96=BD=E5=B7=A5?= =?UTF-8?q?=E5=9B=BE=EF=BC=88=E7=BC=96=E5=A7=94=E4=BC=9A=E5=88=B6=C2=B7?= =?UTF-8?q?=E4=B8=89=E7=8E=AF=E6=9E=B6=E6=9E=84=C2=B7AG-UI=20=E5=86=B3?= =?UTF-8?q?=E7=AD=96=E5=B1=82=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- deliverables/novel-system-research.html | 645 ++++++++++++++++++++++++ docs/novel-design.md | 552 ++++++++++++++++++++ 2 files changed, 1197 insertions(+) create mode 100644 deliverables/novel-system-research.html create mode 100644 docs/novel-design.md diff --git a/deliverables/novel-system-research.html b/deliverables/novel-system-research.html new file mode 100644 index 00000000..6bea09f3 --- /dev/null +++ b/deliverables/novel-system-research.html @@ -0,0 +1,645 @@ + + + + + +memmy-agent 二次开发调研 · 小说写作系统（主编 + 11 位专家） + + + + + +
+ MEMOTENSOR · 内部调研 + + 2026-08-13 · Vol. 01 +
+ + +
+
二次开发可行性调研报告
+

从"个人记忆 Agent"到
"编委会制"小说写作系统

+

目标：在 memmy-agent 之上二次开发一套内置 主编 + 11 位专家 的网文写作系统 —— 主编负责拆解任务与终审，11 位专家覆盖选题、世界观、剧情、人设、大纲、开篇、爽点、文笔、对话、审稿、对标拆解全流程。

+
+ 对象 memmy-agent v0.1.0 + 代码量 ≈ 10+ 万行 TS + 形态 Electron 桌面 + CLI + API + 结论 高度可行 +
+
+
调研结论 · Verdict
+

memmy-agent 天生自带 多 Agent 编排（SubagentManager）、任务分解 DAG、四层记忆引擎（世界模型）、技能系统 四大资产 —— "主编 + 11 位专家"不是从零造轮子，而是在现有 Agent 运行时上叠加一层"编委会编排层"。推荐路径：先以 Skills + 角色卡快速验证（2 周 MVP），再升级为 Agent Runtime 原生编排层（4–6 周完整版）。

+
+
+ + +
+
+
+ 一 +
+
项目本质：memmy-agent 是什么
+
一句话：本地优先的"个人记忆中心 + 通用 Agent 运行时"，定位类似 OpenClaw / Hermes，但核心卖点是跨 Agent 共享的记忆底座（MemOS）
+
+
+

memmy-agent 是一个 TypeScript npm workspaces monorepo（Node ≥ 22，Electron 桌面壳），由四个相互独立、可单独运行的子系统组成。它不是"聊天机器人"，而是一套完整的 Agent 运行时基础设施：记忆服务（:18960）、Agent 执行引擎、桌面本地后端（Fastify + SQLite）、前端 React 工作台，外加 CLI/TUI 与 OpenAI 兼容 API 等多个入口。

+
+
🧠

Memory Service（记忆底座）

独立本地服务，SQLite 存储 + LLM 驱动的四层记忆（trace 痕迹 / policy 策略 / world_model 世界模型 / skill 技能），向量 + 关键词混合检索，Dream 定时整理并做 git 版本化，支持一键回滚。目录 Memory/

+
🤖

Agent Runtime（执行引擎）

消息循环、工具注册、MCP、会话管理、自动压缩、技能加载、长期目标（long_task）、以及关键的 SubagentManager 子代理编排 与会话任务 DAG。App/memmy-agent/src/

+
🖥️

Local Backend（桌面后端）

Fastify + SQLite 的应用状态层：账号、模型配置、渠道接入、Agent 来源扫描、Skill 分发、面板与搜索服务，是前端所有操作的 API 网关。App/backend/src/

+
📖

Frontend Desktop（前端工作台）

React + Vite 的桌面 UI：聊天、记忆面板、历史 DAG 视图、工具管理、模型设置等页面；路由/状态/主题体系完整，可直接挂载新业务页面。App/frontend/desktop/

+
+

多入口形态（同一个 Agent 与记忆，处处可触达）

+

桌面 App、CLI/TUI（memmy agent）、OpenAI 兼容 API（memmy serve :18990）、消息渠道（Telegram / Discord / 微信 / 飞书 / 钉钉）共享同一套 Agents、记忆与配置 —— 这意味着小说写作系统将来可以"在电脑上写、在微信里催更、在 CLI 里批量跑"。

+
+
+ + +
+
+
+ 二 +
+
四大资产：与"编委会制写作"的天然契合点
+
以下能力全部已有现成代码，二次开发直接复用 —— 这是本方案可行性的核心依据
+
+
+ +

资产 ①　多 Agent 编排 —— 主编派单给专家的"操作系统"

+

App/memmy-agent/src/core/agent-runtime/subagent.ts 中的 SubagentManager 已经实现了完整的子代理生命周期：spawn 派发 → 并发控制（maxConcurrentSubagents）→ 状态跟踪（pending/running/complete/failed/cancelled）→ 生命周期钩子（subagentStart/subagentStop）→ 结果自动回传主会话。这恰恰就是"主编把任务拆给 11 位专家、收集成果、汇总交付"所需的全部机制。App/memmy-agent/src/core/agent-runtime/subagent.ts

+
+
🎯

spawn(task, label, …)

带描述、标签、会话归属地派发一个子代理任务；返回任务 ID，完成后自动通过消息总线把结果公布回主会话。

+
🛡️

并发与取消

按会话统计运行中任务，支持 cancelBySession 一键终止某会话的全部专家任务，防止失控。

+
🔌

生命周期钩子

AgentHook 提供 subagentStart / subagentStop，可挂接前端进度条、写作日志、token 统计。

+
+

配套的 Session DAG（App/memmy-agent/src/session-dag/）把会话中的任务组织成图：节点类型 task / subtask / decision，边类型 decomposes（分解）/ continues / blocks（阻塞）/ supersedes（取代）。一部小说的创作流程 —— 立项 → 世界观 → 人设 → 卷纲 → 章纲 → 正文 → 审稿 —— 天然就是一张 DAG，前端已有 history-dag-panel.tsx 可视化组件可改造成"创作进度看板"。

+ +

资产 ②　四层记忆引擎 —— 长篇小说的"设定保险柜"

+

长篇写作最大的痛点是一致性：人物名字、力量体系数值、时间线、伏笔回收。memmy 的记忆引擎恰好为此设计 —— world_model（世界模型）记忆层专门沉淀"环境的稳定事实"，可以直接存储世界观设定、人物档案、战力规则；policy（策略）层沉淀"怎么写更好"，用于学习用户的文风偏好；Dream 机制周期性把散落对话蒸馏进记忆并 git 版本化，可回滚 —— 等于给小说项目一个自动维护的"设定百科 + 版本控制"。Memory/src/algorithm/plugin-algorithms.ts

+
+
📜

trace → policy → world_model → skill

从交互痕迹逐级提炼可复用策略与稳定事实，写作经验会越用越多（LLM 归纳 + 置信度评分）。

+
💬

反馈学习

系统自带中英文反馈分类器（偏好 / 纠错 / 约束 / 正负评价），用户说"主角太圣母了"会被解析成可沉淀的策略。

+
🗂️

混合检索

向量 + 关键词 + LLM 相关性过滤三级召回，写作时自动注入相关设定，避免"写嗨了忘记设定"。

+
+ +

资产 ③　Skills 技能系统 —— 写作技能包的安装位

+

每个技能 = 一个含 SKILL.md 的目录（YAML frontmatter 声明名称/描述/依赖），Agent 在上下文中按需加载。工作区技能（~/.memmy/workspace/skills/）与内置技能（App/memmy-agent/src/skills/）双层加载 —— "网文写作技能集"（大纲模板、黄金三章 checklist、审稿清单）可以直接做成一组内置技能，用户还能自定义。加载器支持 requirements 检查（缺哪个 CLI/环境变量一目了然）。App/memmy-agent/src/core/agent-runtime/skills.ts

+ +

资产 ④　命令系统 + 人格模板 —— 角色卡与写作命令

+

命令路由支持 router.priority / exact / prefix 注册（App/memmy-agent/src/command/router.ts），现有命令如 /new、/goal、/dream、/history-dag 均按此注册 —— 新增 /新书、/大纲、/人设、/写正文、/审稿、/开编委会 等写作命令零架构改动。
人格系统：Agent 的"灵魂"来自模板文件（App/memmy-agent/src/templates/SOUL.md 定义我是谁/执行原则，templates/agent/subagent-system.md 定义子代理提示词）—— 每个专家 = 一份专属角色卡模板，这正是"主编 + 11 位专家"的实现入口。

+
+
+ + +
+
+
+ 三 +
+
编委会阵容：1 位主编 + 11 位专家
+
建议角色构成（可调整）—— 按网文创作价值链排布，覆盖 选题 → 设定 → 剧情 → 人设 → 大纲 → 开篇 → 爽点 → 文笔 → 对话 → 审稿 → 对标
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
编号角色核心职责调用时机
总编主编 · Editor-in-Chief理解创作诉求 → 拆解为专家任务 → 派单与调度 → 汇总各专家产出 → 质量终审 → 统一文风 → 向用户交付；全书风格与进程的总负责人（主 Agent 扮演）。贯穿全程
01市场选题分析师扫榜研判题材热度、读者画像与差异化定位；给出题材/类型/卖点组合建议。立项
02世界观架构师设定体系、力量规则、地图疆域、战力数值与底层逻辑；保证设定自洽并沉淀为 world_model。立项 / 开新卷
03剧情架构师主线 / 支线 / 卷结构、伏笔布置与回收、悬念与反转设计。立项 / 每卷
04人设专家人物小传、性格与言行一致性、成长弧光、人物关系网。立项 / 新人物
05大纲规划师卷纲 / 章纲、剧情节奏曲线、章末钩子规划。每卷 / 每章前
06开篇专家黄金三章打磨：开篇钩子、代入感、信息释放节奏、弃书点排查。开书
07爽点设计师爽点密度与排列、期待感管理、情绪节奏曲线（燃点/泪点/笑点）。大纲 / 成稿后
08文笔润色师语言风格统一、画面感描写、句式节奏、去 AI 味。成稿后
09对话编剧对白性格化、潜台词、冲突推进；检查"千人一声"。成稿后
10审稿编辑逻辑漏洞、设定查重（对照 world_model）、时间线校对、前后一致性。每章 / 每卷
11爆款拆解师对标作品结构拆解、数据化分析（章节节奏、套路迁移），为选题/大纲提供实证参照。立项 / 卡文时
+
+
+ + +
+
+
+ 四 +
+
二次开发路径：三条路，推荐 B
+
按改动深度与投入排序；三条路径可递进演进，不必一次到位
+
+
+ +
+
路径 A
MVP · 2 周
+
+
Skills + 角色卡方案 零架构改动，先跑通"编委会"体验
+

不碰运行时代码：把"主编 + 11 位专家"做成一组内置 SKILL.md（每个专家一份角色卡，主编一份编排指令），加一个 novel-orchestration 技能指导主编何时调用子代理。前端零改动（沿用聊天界面），写作产物落盘为 markdown 文件。

+
    +
  • 优点：两天内可演示；全部复用现有 SubagentManager 与技能加载
    • +
  • 缺点：没有项目管理/章节存储/审稿看板；专家协作深度受单会话上下文限制
    • +
  • 落点：新增 App/memmy-agent/src/skills/novel-*/SKILL.md + 角色卡模板
    • +
+
+
+ +
+
路径 B ★
推荐 · 4–6 周
+
+
Agent Runtime 原生"编委会编排层" 核心方案
+

在 App/memmy-agent/src/ 下新增 novel/ 命名空间：NovelProject（项目与章节存储）、ExpertRegistry（12 位角色卡注册表）、ChiefDesk（主编调度器，基于 SubagentManager 派单 + 收集）、写作用户态写入 Memory 的 novel 命名空间。前端新增"小说工作台"页面（项目列表 / 章节树 / 编辑器 / 审稿面板 / 专家进度看板，复用 history-dag 可视化）。

+
    +
  • 优点：专家是"一等公民"，支持并行写作、章节级审稿、设定自动记忆；能力完整可产品化
    • +
  • 改动：Agent 运行时新增 ~3–4 千行 + 后端写作 API + 前端 3–4 个页面
    • +
  • 落点：App/memmy-agent/src/novel/ · App/backend/src/services/novel-* · App/frontend/desktop/src/pages/novel-*
    • +
+
+
+ +
+
路径 C
重投入 · 8–12 周
+
+
独立小说引擎服务 产品级全栈
+

在 Memory 服务旁新增独立的 novel-service（自有数据库、章节版本控制、协作队列、导出管线：EPUB / DOCX / 全平台分发），前端做完整编辑器（分屏、批注、修订）。适合要做成独立产品的场景。

+
    +
  • 优点：彻底解耦，性能与扩展性最好，可支持多人协作
    • +
  • 缺点：工作量大，前期与 memmy 现有能力重复度高
    • +
+
+
+
+
+ + +
+
+
+ 五 +
+
改动清单（按路径 B）
+
全部落点基于本次调研的真实代码位置，可直接作为开发排期
+
+
+
+
App/memmy-agent/src/ ← 核心改动区
+
  ├─ novel/ 【新增】编委会编排层
+
  │  ├─ expert-registry.ts　　12 份角色卡注册表（主编 + 11 专家）
+
  │  ├─ chief-desk.ts　　　　 主编调度器：拆解 → 派单 → 汇总 → 终审
+
  │  ├─ novel-project.ts　　　项目 / 卷 / 章节模型与文件布局
+
  │  ├─ novel-memory.ts　　　 设定 → Memory world_model 的读写适配
+
  │  └─ commands.ts　　　　　/新书 /大纲 /人设 /写正文 /审稿 /开编委会
+
  ├─ skills/ 【新增】写作技能集
+
  │  ├─ novel-outline/ · novel-golden3/ · novel-payoff/ · novel-review/ …
+
  ├─ templates/ 【新增】角色卡模板
+
  │  └─ novel/experts/*.md　　　主编卡 + 11 位专家卡（子代理系统提示词）
+
  └─ core/agent-runtime/ 【微调】
+
      ├─ subagent.ts　　　　　 暴露专家并发上限（默认 maxConcurrentSubagents=1 需调高）
+
      └─ skills.ts　　　　　　 注册 novel-* 内置技能
+
App/backend/src/services/ ← 新增
+
  ├─ novel-service.ts　　　项目 CRUD / 章节读写 / 审稿任务队列 / 写作进度 API
+
  └─ novel-session.ts　　　把写作会话接入现有 turn/session 服务
+
App/frontend/desktop/src/pages/ ← 新增
+
  ├─ novel-workspace.tsx　小说工作台：项目列表 + 章节树 + 编辑器
+
  ├─ novel-review.tsx　　　审稿面板：专家批注 / 设定查重结果 / 一键修改
+
  ├─ novel-crew.tsx　　　　编委会视图：12 角色卡片 / 各专家进度 / 调用记录
+
  └─ app/router.tsx　　　　【微调】注册新页面路由与导航入口
+
Memory/src/ ← 微调
+
  └─ service/memory-service.ts　启用 novel 命名空间（设定/人设/时间线/文风偏好）
+
+ +

三个必须知道的工程前提

+
+
⚙️

并发上限默认 1

AgentDefaults.maxConcurrentSubagents = 1（config/schema.ts 第 304 行）。并行调用多位专家前必须调高，并考虑限流与预算控制。

+
💰

Token 成本线性放大

12 角色 × 每任务多次 LLM 调用。建议角色卡精炼（系统提示词控制在 800–1500 字）、审稿用便宜模型、正文用强模型的分层路由。

+
🔗

一致性命脉在 Memory

长篇设定一致性依赖 embedding 质量与 world_model 写入纪律：每章成稿后必须把新设定/新人物回写记忆，审稿编辑对照查重。

+
+
+
+ + +
+
+
+ 六 +
+
里程碑规划
+
两周见 Demo，两个月成产品
+
+
+
+
M1
第 1–2 周
+
+
编委会 MVP（路径 A）
+

12 份角色卡 + novel-orchestration 技能 + 3 个写作技能（大纲 / 开篇 / 审稿）。验收：用户在聊天界面说"帮我开一本仙侠书"，主编自动召集 01–05 号专家产出《立项书》（题材定位 + 世界观 + 剧情主干 + 人设 + 三章大纲），全部落盘 markdown。

+
+
+
+
M2
第 3–4 周
+
+
写作工作台（路径 B 起步）
+

novel 命名空间 + 章节存储 + 写作 API + 前端"小说工作台"页面。验收：可建项目、写卷/章、正文编辑器、设定自动入记忆。

+
+
+
+
M3
第 5–6 周
+
+
完整编委会流程
+

主编调度器（派单/并行/汇总/终审）+ 审稿面板 + 编委会视图 + 写作命令集。验收：一键"今日日更"——主编按大纲派 05 大纲规划师拆章纲 → 并行写 3 章 → 07/08/09 逐章加工 → 10 审稿编辑查重 → 主编终审交付。

+
+
+
+
M4
第 7–8 周
+
+
进化与打磨
+

反馈学习闭环（用户评价 → 文风 policy 沉淀）、爆款拆解师接入扫榜数据、导出管线（TXT/Markdown → EPUB/DOCX）、记忆回滚演练。

+
+
+
+
+ + +
+
+
+ 七 +
+
风险与对策
+
依据代码现状识别，非泛泛之谈
+
+
+
+
高
长篇一致性失控
几十万字后人物/设定/时间线漂移。对策：world_model 强制写入纪律 + 审稿编辑对照查重 + Dream 定期整理设定库，形成"写作 → 回写 → 查重"闭环。
+
+
+
高
Token 成本失控
12 角色串行会指数级放大成本。对策：模型分层（规划用小模型、正文用大模型）、专家并行上限、角色卡精简、按需召唤（不是每章都全员上阵）。
+
+
+
中
并发编排的工程复杂度
SubagentManager 已支持并发，但"主编收集多专家产出再汇总"需要任务结果协议（结构化 JSON 回传）。对策：为专家定义统一产出 schema（title/summary/detail/refs），主编按 schema 解析。
+
+
+
中
前端改动面
现有前端以聊天/记忆为核心，新增工作台涉及路由、导航、状态切片。对策：沿用现有 app-actions / app-state 模式新增 novel 切片，页面独立挂载，不侵入现有聊天流。
+
+
+
低
"AI 味"文本
网文读者对 AI 文风敏感。对策：文笔润色师角色卡内置去 AI 味清单（禁模板句式、禁滥用排比/感叹、口语化校验），并接入现有反馈分类器持续纠偏。
+
+
+
+ + +
+
+
+

结语：这栋楼是为"编辑部"盖的

+

memmy-agent 的核心抽象 —— 记忆是"设定库"、子代理是"专家"、会话 DAG 是"任务看板"、技能是"写作手册"、SOUL 模板是"角色卡" —— 与小说写作系统的需求几乎一一对应。把它改造成"编委会制"写作系统，不是逆向重构，而是顺着现有架构做一层业务封装。

+

建议立即启动 M1：先写 12 份角色卡与 3 个写作技能，用两天跑通"开书 → 立项书"的完整编委会演示，再决定 M2 的工程化深度。每一步都有现成代码托底，风险可控。

+ 下一步：输出角色卡 V1 + 主编编排指令草案 +
+
+
+ + + +
+ diff --git a/docs/novel-design.md b/docs/novel-design.md new file mode 100644 index 00000000..410ce29d --- /dev/null +++ b/docs/novel-design.md @@ -0,0 +1,552 @@ +# 小说写作系统设计文档（Novel System Design） + +> 基于 memmy-agent 源码实测调研（2026-08-13）· 二次开发施工图 +> 仓库策略：Fork 官方 MemTensor/memmy-agent → `develop` 分支承载全部开发 + +--- + +## 0. 项目定位 + +在 memmy-agent（本地优先的 Agent 记忆 + 运行时）之上，二次开发一套**编委会制小说写作系统**： + +- **主编中枢**负责任务下发、进度监控、中间结果审阅、采纳/驳回决策、工作流编排 +- **创作八将**沿 Pipeline 顺序协作（灵思→构世→塑像→谋篇→埋线→执笔→淬文→审校） +- **支撑四翼**横向服务（布景/监工/装帧/试读） +- 运行模式：**半自动**——方向类决策由用户确认，执行类工作自动运行 + +### 0.1 要解决的六大结构性痛点（专业作者视角） + +| # | 痛点 | 现象 | 系统对应解法 | +|---|---|---|---| +| 1 | 长篇连贯性崩坏 | 超 10 万字后遗忘前文设定、世界观自相矛盾、配角"死而复生" | 事中一致性引擎（§6）+ 每书记忆隔离（§4）+ 双基准查重 | +| 2 | 角色崩坏/人设漂移 | 标签式人设（高冷/腹黑），行为无心理逻辑，20 章后判若两人 | 塑像人物中心（人物卡+成长弧）+ 路由 C 人设纠偏（§6） | +| 3 | 伏笔丢失/逻辑断层 | 第 3 章埋的槐树根，第 12 章在沙漠挖出（地理崩坏） | 19 线叙事矩阵 + 伏笔状态机（§2.6）+ 埋线/审校共同维护 | +| 4 | AI 味重 | 满屏"不禁/仿佛/那一刻"；逻辑过载、经验真空、缺具身化细节 | 去 AI 味引擎三道防护（§7）+ 具身细节库（§3.2） | +| 5 | 工作流碎片化 | 大纲/起草/编辑/导出多个工具切换，交接丢上下文 | 单一创作工作台：立项→蓝图→细纲→写作→交付全流程内聚 | +| 6 | 设定无版本/无基线 | 改设定引发全线返工，或随意乱改破坏已写内容 | Plot Git 基线锁定（§5）：前置锁定，修改走新版本线 | + +--- + +## 1. 编委会名单 + +### 1.1 主编中枢（Chief Hub） + +| 项 | 说明 | +|---|---| +| 定位 | 编委会总负责人，用户的第一联系人 | +| 核心职责 | 需求理解、立项、任务拆解、派单调度（Pipeline 顺序协作）、进度监控、中间结果审阅、采纳/驳回决策、文风统一 | +| 编排能力 | 任意节点**中断 / 恢复 / 锁定**；创作流程可中断、可恢复、可回退 | +| 产出物 | 《创作方案卡片×3》《创作指令单》《终审意见》《基线快照》 | + +### 1.2 创作八将（Pipeline 顺序执行） + +| # | 专家 | 职责 | 产出物 | 触发时机 | +|---|---|---|---|---| +| 1 | 灵思 | 题材定位、脑洞创意、卖点组合、爽点框架设计、开篇思路；立项入口产出 3 个方案卡片 | 《方案卡片×3》《爽点框架》 | 立项 | +| 2 | 构世 | 世界观、力量体系、地图疆域、底层规则自洽（可取材世界库通用规则） | 《作品设定集》→ 写入本书作品档案 | 立项/开新卷 | +| 3 | 塑像 | 人物小传、性格言行一致性、成长弧光、人物关系网 | 《人物档案集》→ 写入本书作品档案 | 立项/新人物 | +| 4 | 谋篇 | 主线支线、卷结构、卷纲章纲、节奏曲线 | 《全书纲》《卷纲》《章纲》 | 每卷/每章 | +| 5 | 埋线 | 伏笔设计/埋设/回收规划；**伏笔状态机 + 19 维线索矩阵主人** | 《伏笔总账》《线索矩阵》 | 立项/每卷/每章 | +| 6 | 执笔 | 正文写作、黄金三章成稿、日更产出 | 《正文成稿》 | 大纲确认后 | +| 7 | 淬文 | 文笔润色、对白打磨、去 AI 味（De-AI 引擎主控）、语言风格统一 | 《润色稿》《文风手册》 | 成稿后/实时洗稿 | +| 8 | 审校 | 逻辑漏洞、设定查重（对照世界库预设规则 + 本书作品档案）、一致性校验、伏笔回收核验 | 《审校报告》 | 每章/每卷 | + +### 1.3 支撑四翼（横向服务，不占 Pipeline 顺序） + +| # | Agent | 职责 | 产出物 | 服务对象 | +|---|---|---|---|---| +| 9 | 布景 | 场景/环境/战斗场面描写素材，配合执笔随时调用 | 《场景卡》→ 写入素材库 | 执笔 | +| 10 | 监工 | 字数/进度/更新节奏度量、爽点密度与情绪曲线量化、数据化复盘 | 《度量报告》《情绪曲线》 | 主编/用户 | +| 11 | 装帧 | 交付导出（EPUB/DOCX/Markdown）、排版、封面生成对接 | 《成品书》《导出包》 | 用户 | +| 12 | 试读 | 读者视角试读、弃书点排查、代入感反馈、黄金三章检验 | 《试读报告》 | 主编/用户 | + +### 1.4 融合决策记录（相对初版 11 位专家） + +- 谋篇 = 剧情架构（PA）+ 大纲规划（OP）合并——一体两面 +- 淬文 = 文笔润色（PP）+ 对话编剧（DW）合并——同属语言加工层 +- 开篇拆两半：**写**归执笔、**验**归试读——创作者不自己审自己 +- 爽点拆两半：**设计**归灵思、**度量**归监工——设计靠感觉、度量靠数据 +- 爆款拆解拆两半：数据复盘归监工、对标素材沉淀进素材库 +- 新增埋线（伏笔是网文命脉，独立成专家）；新增布景（场景是 AI 写作弱项，值得专项） + +--- + +## 2. 工作流引擎与主编控制台 +### 2.0 三环架构总览（立项环 / 创作环 / 交付环） + +``` +┌─ 立项环（一次性 · 产出即锁定）─────────────────────────┐ +│ 入口触发 → 灵思产出 3 个方案卡片 → 用户选择/混选 → │ +│ 生成【基线快照】→ 前置设定全部锁定（不可变基线） │ +└──────────────────────────────────────────────────────┘ +┌─ 创作环（长期 · 事中纠偏为主）─────────────────────────┐ +│ 蓝图：19 维线索矩阵 + 分卷大纲（卷级锁定） │ +│ → 细纲：章节任务单（3-4 场景 + 控字预算 + 伏笔插针） │ +│ → 写作：控字正文 + 去 AI 味实时洗稿 + 划词重写/人机接管│ +│ → 拦截：一致性引擎事中路由 → 知识中心修正 → 重流 │ +└──────────────────────────────────────────────────────┘ +┌─ 交付环（每章/每卷/完本）─────────────────────────────┐ +│ 审校终验（双基准全量查重）→ 试读 → 装帧交付 → 监工复盘 │ +│ → 复盘数据反哺节奏矩阵与灵感库 │ +└──────────────────────────────────────────────────────┘ +``` + +- **入口触发**（立项环起点）：①一句话直接立项；②灵感库推荐卡片**套用**；③多张灵感卡片**对撞**（创意杂交） +- **方案卡片**：灵思基于入口产出 **3 个创作方案卡片**供用户选择/混选，每卡含：作品基础信息（作品名/频道/核心题材/目标篇幅/商业卖点）、故事梗概与核心动力（Logline/300 字梗概/核心驱动力）、金手指与规则机制（能力/底层逻辑/代价与上限）、核心角色卡片（主角/反派/女主或搭档/NPC 群像）、世界观基石（力量境界/社会矛盾/地理舞台）、连载节奏（节奏模板+参数） +- 选定后生成**基线快照**，前置设定全部锁定（改设定 = 新建版本线，见 §5） + +### 2.1 AG-UI 人类决策层（交互底座） + +> 半自动模式的"关键节点人工确认"通过 AG-UI（Agent-User Interface Protocol）标准化实现： +> Agent 在决策点发出结构化交互请求 → 前端渲染成决策卡片 → 用户操作 → 结构化响应回传 → Agent 恢复执行。 + +**SDK 三层分工与本系统取舍**： + +| 层 | 作用 | 本系统策略 | +|---|---|---| +| ag-ui/core | 协议核心：消息类型/schema/校验/状态机 | ✅ 采用官方协议定义（避免自造轮子后与标准脱节） | +| ag-ui/client | 前端渲染：决策卡片组件 | ⏳ 起步自绘 React 卡片，后期可平滑换官方组件 | +| ag-ui/agent | Agent 端发消息/暂停/恢复 | 🔧 自建 `agui-bridge.ts` 对接 memmy 运行时（官方 agent 库难嵌入自定义运行时） | + +**决策点映射**（人类决策全部走 AG-UI 卡片）： + +| 系统场景 | AG-UI 交互 | 用户操作 | +|---|---|---| +| 立项入口（一句话/灵感卡套用/对撞） | `form` | 输入创意或选择灵感卡片 | +| 方案卡片选择（灵思产出 3 个） | `multi-select` | 选方案 / 要求改 | +| 5 个半自动确认节点（立项/设定/大纲/开篇/卷末） | `confirm` + 详情卡 | 采纳 / 驳回（附原因） | +| 主编驳回路径 | `question` | 打回上一节点 or 打回灵思 | +| 基线锁定确认（选方案后） | `confirm`（不可逆提示） | 确认锁定 | +| 章节审校结果 | 批注列表 + `confirm` | 逐条采纳 / 驳回 / 一键修改 | +| 试读 / 装帧交付 | `confirm` + 预览 | 放行 / 打回 | +| Plot Git 分支试错 | `confirm` | 合并 / 丢弃分支 | + +**与 memmy 运行时对接**： + +- Agent 端：`src/novel/agui-bridge.ts` —— 决策点发出 AG-UI 消息 → 挂载于现有 Inbound/OutboundMessage（扩展 `agui` 消息类型）→ 经现有 SSE 事件流送达前端 +- 中断/恢复：AG-UI interrupt 与 session-dag 节点状态打通（等待决策 = 节点 blocked，收到响应 = 恢复 active） +- 前端：`components/agui/` 决策卡片组件，挂载进主编控制台与写作工作台 + +### 2.2 Pipeline 编排（核心机制） + +``` +灵思 → 构世 → 塑像 → 谋篇 → 埋线 → 执笔 → 淬文 → 审校 + │ │ │ │ │ │ │ │ + └─ 主编在每个节点后：审阅中间结果 → 采纳（放行）/ 驳回（打回） +``` + +- 顺序协作默认严格串行（下游依赖上游产出），支撑四翼随时可并行介入 +- **锁定**：节点被锁定（frozen）时即使上游变更也不重跑，防止"改了设定引发全线返工" +- **中断/恢复**：任何节点可中断，状态持久化（快照），恢复后从断点继续 +- **驳回路径**（待定，默认打回上一节点）：默认打回上一节点修订；用户可选打回灵思整体重想 + +### 2.3 主编控制台功能清单 + +| 功能 | 说明 | +|---|---| +| 任务下发 | 带《创作指令单》（目标/约束/参考素材/验收标准）派单 | +| 进度监控 | 各节点状态、各专家调用记录、token 消耗 | +| 中间结果审阅 | 每节点产出先呈主编（人工）过目，再决定采纳/驳回 | +| 采纳/驳回决策 | 采纳→放行下一节点；驳回→打回指定节点，记录驳回原因 | +| 中断/恢复/锁定 | 任意节点三操作 | +| 多书切换 | 命名空间隔离，控制台一键切换项目 | + +### 2.4 章节状态机（与伏笔状态机并列） + +``` +规划中 → 写作中 → 待审 → 已采纳 / 已驳回 → 已发布 + ↑__________ 打回修订 __________↓ +``` + +### 2.5 伏笔状态机（埋线 + 审校共同维护 · 线索矩阵的原子单元） + +``` +埋下 → 待回收 → 已回收 + │ │ + │ └─ 回收逾期预警（监工定期扫描，提示主编） + └─ 追踪字段：伏笔内容 / 埋设章节 / 计划回收章节 / 实际回收章节 / 责任人 +``` + +### 2.6 十九线叙事矩阵（长线架构核心 · 伏笔总账的升级版） + +每本书维护 **19 条线索槽位**，`line_type` 为结构化枚举（唯一标识），贯穿全书，是《分卷大纲》和《章节细纲》的输入： + +| 分类 | line_type | 中文名 | 追踪要点（示例） | +|---|---|---|---| +| 主干演进 | work | 工作线 | 职业发展 / 任务推进 | +| 主干演进 | life | 生活线 | 日常状态 / 居住地 / 生活变化 | +| 主干演进 | study | 学习线 | 技能学习 / 修炼进度 | +| 主干演进 | growth | 成长线 | 心境 / 价值观 / 性格演进 | +| 关系羁绊 | family | 家庭线 | 家人状态 / 家族事务 | +| 关系羁绊 | romance | 爱情线 | 感情进展 / 误会与和解 | +| 关系羁绊 | friendship | 友情线 | 伙伴关系变化 | +| 关系羁绊 | colleague | 同事线 | 同门 / 同僚 / 团队协作 | +| 关系羁绊 | enemy | 敌人线 | 敌人动向 / 仇恨升级 | +| 策略局势 | game | 博弈线 | 多方博弈 / 棋局推进 | +| 策略局势 | system | 体制线 | 门派 / 王朝 / 组织规则与斗争 | +| 策略局势 | ability | 能力线 | 能力成长 / 新能力觉醒 | +| 策略局势 | cost | 代价线 | 金手指代价 / 牺牲与代价积累 | +| 剧情推动 | foreshadow | 伏笔线 | 伏笔埋设 / 回收（对应伏笔状态机） | +| 剧情推动 | layout | 布局线 | 谋略布局 / 暗中安排 | +| 剧情推动 | crisis | 困局线 | 危机累积 / 压力攀升 | +| 剧情推动 | break | 破局线 | 破局 / 反转 / 高潮爆发 | +| 叙事内核 | motif | 核心意象线 | 反复出现的意象 / 主题（剑、雪、槐树…） | +| 叙事内核 | timeline | 农历/时间线 | 时间流逝 / 节气 / 时限压力 | + +```json +{ + "line_type": "romance", + "name": "爱情线", + "category": "关系羁绊", + "status": "活跃", // 活跃 / 蛰伏 / 回收 / 完结 + "last_advance_chapter": 12, + "next_plan": "第 14 章：误会加深", + "related_foreshadows": ["fs_004"] +} +``` + +- 每条线索状态机：**活跃 / 蛰伏 / 回收 / 完结**，记录最近推进章节 + 下次计划推进点 + 关联伏笔 ID +- 埋线：负责"插针"（在章节细纲中注入线索推进与伏笔埋设提醒） +- 监工：定期扫描"该活跃的线是否哑火、该回收的伏笔是否逾期"，产出预警 +- 审校：终验时按矩阵全量核对（解决"沙漠里挖出槐树根"式地理/线索矛盾） +- 19 线为预设骨架，作者可增删维度（每本书独立配置，`line_type` 为唯一标识） + +--- + +## 3. 三大数据库（参考资料层 · 后台维护 · 静态参考） + +> 三大库是后台人工收集整理的**参考资料**，为专家提供创作知识参考；它们是**输入侧知识库**， +> 永不接收创作产物 —— 创作产物（作品设定/人物/伏笔/正文）全部进作品数据层（见 §3.3 / §4）。 + +### 3.1 世界库（分两大类：现实世界 / 虚拟世界） + +| 大类 | 内容 | +|---|---| +| 现实世界 | 历史、地理、职业、法律、时代背景、真实事件等现实知识 | +| 虚拟世界 | 规则、地点、势力、历法、能力体系、种族、科技树等架空设定知识 | + +- 世界库规则 = **预设硬约束**（如"该世界无魔法"，正文就不许出现魔法） +- 数据来源：后台人工收集整理（+ 素材库沉淀的通用设定资料） + +### 3.2 素材库 / 灵感库 + +| 库 | 内容 | 使用方式 | +|---|---|---| +| 素材库 | 场景卡、好词好句、金句、名称库（人名/地名/招式名）、对标拆解素材、驳回废稿 | 执笔/布景随时检索调用 | +| 具身细节库 | 按感官通道（视/触/嗅/听/味）× 场景类型（便利店/工地/医院/网吧…）组织的具身化细节（关东煮雾气、旧键盘键位磨损…） | 淬文强制每章植入 ≥2 个场景匹配细节 | +| 灵感库 | 创意火花、脑洞、废弃方案、读者反馈摘录 | 开新书/卡文时调用 | + +- 前端新增「资料库」页面入口：三库分别管理（增删改查 + 标签 + 检索） +- 底层存储：世界库 → Memory world_model；素材库/灵感库 → 文件库 + Memory 索引（混合检索） + +### 3.3 作品数据层（与三库严格分离） + +| 数据 | 说明 | +|---|---| +| 规则基座 | 金手指与规则机制（能力/底层逻辑/代价与上限）——**锁定基线**，防战力崩溃 | +| 人物中心 | 主角/反派/女主或搭档/NPC 群像的人物卡（性格/行为逻辑/成长弧/关系网）——**锁定基线** | +| 世界观中心 | 力量境界/核心社会矛盾/主要地理舞台——**锁定基线** | +| 作品设定集 | 构世/塑像为【本书】产出的专属设定（可引用世界库规则为蓝本） | +| 人物表 / 地点表 / 势力表 | 本书已出现的动态人物、地点、势力（随创作增长） | +| 伏笔总账 | 伏笔状态机（埋下→待回收→已回收） | +| 线索矩阵 | 19 线叙事矩阵（见 §2.6） | +| 节奏矩阵 | 连载节奏与控字配置（见 §3.4）——运营层配置，可微调 | +| 时间线 / 章节正文 / 版本快照 | 本书创作数据 | + +- **回写目标 = 作品数据层**：新人物/新地点/新伏笔成稿后写入本书作品档案 +- 世界库永不接收创作产物（资料与作品、输入与输出严格分离） +- 知识中心（人物中心/世界观中心）＝ 一致性引擎事中路由的修正来源（见 §6） + +### 3.4 配置位置总表（"在哪配置"的权威答案） + +| 配置项 | 配置位置 | 归属环 | 锁定策略 | +|---|---|---|---| +| 作品基础信息（名/频道/题材/篇幅/卖点） | 立项方案卡片 | 立项环 | 🔒 锁定 | +| Logline / 300 字梗概 / 核心驱动力 | 立项方案卡片 | 立项环 | 🔒 锁定 | +| 金手指与规则机制（代价/上限） | 立项方案卡片 → 规则基座 | 立项环 | 🔒 锁定 | +| 核心角色卡 | 立项方案卡片 → 人物中心 | 立项环 | 🔒 锁定 | +| 世界观基石 | 立项方案卡片 → 世界观中心 | 立项环 | 🔒 锁定 | +| 连载节奏矩阵（模板/字数/循环/高潮节点） | 作品档案·节奏矩阵（运营层配置） | 立项环选定 | ⚠️ 半锁定：模板锁定，参数可微调并留版本记录 | +| 19 维叙事线索矩阵 | 蓝图环谋篇产出 → 线索矩阵 | 创作环 | 动态（随创作演进） | +| 分卷大纲（每卷矛盾/高潮/字数/卷末钩子） | 蓝图环产出 → 分卷蓝图 | 创作环 | 🔒 卷级锁定 | +| 章节细纲任务单（3-4 子场景 + 控字预算 + 伏笔插针） | 创作环逐章生成 | 创作环 | 动态 | + +**节奏矩阵预设模板**（节奏矩阵可配置的参数）： + +| 模板 | 单章字数 | 循环 | 说明 | +|---|---|---|---| +| 商业网文高频模式（默认推荐） | 2500–3000 字 | 9 章一循环（3 小/6 中/9 大高潮） | 卷高潮爆发节点可设（如第 20 章） | +| 短篇爆款反转模式 | 3000–5000 字 | 3 章反转循环 | 强反转密集 | +| 传统出版/严肃模式 | 5000–8000 字 | 按卷/三幕式高潮 | 节奏舒缓 | +| 自定义模式 | 任意 | 任意 | 参数自由 | + +- 节奏矩阵归为**运营层**：改单章字数/循环周期不破坏故事（作者上架后调整日更量很正常），但必须留版本记录（审计） +- 设定改动则必须走版本线（§5）——"运营参数可调、设定不可变"这条边界写死 + +--- + +## 4. Agent 记忆与上下文管理（每书隔离） + +- **每部小说一个 Memory 命名空间（namespace）**：本书作品档案（作品设定/人物/伏笔/时间线）+ 文风 policy 各归各书，绝不乱串；三库参考资料按需共享 +- 写作会话上下文 = 该书命名空间的检索结果 + 创作指令单 + 最近章节 +- 反馈学习：用户对章节的评价 → 反馈分类器解析 → 沉淀为该书的 policy（如"爽点密度不够""主角太圣母"） +- 作品回写纪律：新人物/新地点/新伏笔成稿后强制回写【本书作品档案】（不写世界库）；审校据此查重 + +--- + +## 5. 版本管理（Plot Git · 类 Git 版本分支） + +### 5.1 主版本线与基线锁定 + +``` +主版本线（master）：基线快照 → 卷锁定 → 章锁定 → 成稿 + ├─ 试错分支：如"主角黑化版"→ 试验后 merge（局部采纳）或丢弃 + ├─ 设定修正版：改前置 → 强制新建版本线（旧线保留可审计） + └─ Plot Diff：两版情节走向对比，供主编决策 +``` + +- **基线快照**：立项环选定方案后生成，前置设定（基础信息/梗概/金手指/角色卡/世界观）成为不可变基线 +- 基线之后任何修改动作被版本管理器**拒绝**，唯一合法路径 = 新建版本线（平行推演，互不污染，全部留痕） + +### 5.2 能力清单 + +| 能力 | 实现 | 说明 | +|---|---|---| +| commit 快照 | 每章采纳后生成快照 | 复用/扩展 Dream 的 git 版本化机制 | +| branch 分支实验 | 支持"如果主角黑化会怎样"式的分支试错 | 实验分支不污染主线，可合并/丢弃 | +| lock 锁定 | 基线/卷/章三级锁定 | 锁定后该范围拒绝修改（防误改、防设定返工） | +| Plot Diff | 分支/版本间情节走向对比 | 供主编决定采纳哪条线 | +| 可审计 | 全部操作留痕 | 主编决策、专家调用、commit/merge/lock 记录 | + +--- + +## 6. 一致性引擎与校验闭环（事中拦截 + 事后终验） + +### 6.1 事中拦截（Interrupt Hub · 写作流内实时触发） + +``` + [ 正文生成中：检测到违规动作 ] + │ + ▼ + 【一致性引擎 (Interrupt Hub)】 + │ (判定错误类型) + ┌───────────────────────┼───────────────────────┐ + ▼ ▼ ▼ +【路由 A：状态不符】 【路由 B：规则冲突】 【路由 C：人设偏离】 +通知：人物中心(塑像) 通知：世界观中心(构世) 通知：剧情与场景中心(谋篇+布景) + (提供替代道具/状态) (提供规则合理解释) (补充心理/动机过渡) + │ │ │ + └───────────────────────┼───────────────────────┘ + ▼ + 【智能合成修正指令 (Patch Prompt)】 + │ + ▼ + 【正文创作中心 (自适应重流/局部修正)】 +``` + +| 路由 | 判定 | 知识中心 | 修正方式 | 成本 | +|---|---|---|---|---| +| A 状态不符 | 人物当前状态矛盾 | 塑像（人物中心） | 提供替代道具/状态 | 轻量 | +| B 规则冲突 | 违反世界库预设/金手指代价 | 构世（世界观中心） | 提供规则合理解释 | 轻量 | +| C 人设偏离 | 行为无心理逻辑 | 谋篇 + 布景（剧情与场景中心） | 补充心理/动机过渡 | 中量 | +| D 风格违规 | 黑名单词/章末哲理/AI 句式 | 淬文（文风中心） | 局部洗稿不重写 | 极轻量 | +| E 基座违规 | 触犯锁定基线（金手指上限/已锁设定） | 主编（无权解释） | **回退重写该场景** | 重型 | + +- D 类：去 AI 味从"全篇洗稿"降维成"局部替换"，黑名单命中直接词级/句级洗稿，不进重写流（省 token） +- E 类：兜底红线——锁定基线被触碰时知识中心无权"解释"，必须回退（"锁定"语义的强制执行点） + +### 6.2 事后终验（审校专家 · 成稿后双基准全量查重） + +``` +[写作前] 执笔注入：世界库预设规则（硬约束）+ 本书作品档案（已写内容） +[写作中] 布景/淬文产出受世界库预设规则约束 +[成稿后] 审校对照两个基准全量查重： + 基准① 世界库 —— 是否违反预设规则（如"无魔法世界出现魔法"） + 基准② 本书作品档案 —— 人物名/战力数值/地点/伏笔/时间线是否与已写内容矛盾 + ③ 伏笔未回收 / 回收矛盾（对照线索矩阵） + ④ 逻辑漏洞 +[回写] 新人物/新地点/新伏笔 → 写进【本书作品档案】（不是世界库） + 下次写作基于更新后的作品档案 + 世界库预设规则 +``` + +- 事中拦截负责"别写错"（实时、轻量、路由到知识中心）；事后终验负责"查漏"（全量、兜底、双基准） +- 两道防线各司其职，共同解决"长篇连贯性崩坏"与"伏笔丢失"两大头号痛点 + +--- + +## 7. 补充机制清单 + +1. **反馈学习闭环**：用户评价 → policy 沉淀 → 影响后续执笔/淬文（复用现成反馈分类器） +2. **驳回品不删除**：进素材库/灵感库，可回收改写 +3. **任务卡片协议**：派单带结构化 schema，专家按统一 schema 回传（调度器自动聚合的前提） +4. **章节状态机**：见 2.4 +5. **模型分层路由**：灵思/谋篇/审校用便宜模型，执笔/淬文用强模型，控制成本 +6. **进度仪表盘**：监工数据 + 主编控制台合一页（复用 history-dag 可视化） +7. **多书并行**：命名空间隔离天然支持 +8. **素材库自动沉淀**：写作中产生的好词好句/场景自动回收 +9. **去 AI 味引擎（De-AI Engine）**：由淬文主控，三道防护—— + ① 前置强约束：向模型注入黑名单（200+ 网文 AI 高频词：宛如/恐怖如斯/一抹…），禁用章末哲理总结 + ② 动作感官化（Show, Don't Tell）：强制将抽象心理形容词转换为具体物理动作与环境细节 + ③ 后置洗稿：打碎长难句，随机穿插短句与单字成段，模拟真实情绪断层与不完美口语特征 +10. **具身细节库**：素材库子类，按感官通道 × 场景类型组织；淬文强制每章至少植入 2 个场景匹配的具身细节——解决"经验真空"：AI 缺的具身化细节靠语料喂养，不靠提示词 + +--- + +## 8. 与 memmy 现有代码的架构映射 + +| 新系统组件 | 复用/改造的现有资产 | +|---|---| +| 主编中枢（派单/监控/取消） | `App/memmy-agent/src/core/agent-runtime/subagent.ts`（SubagentManager） | +| Pipeline 编排（中断/恢复/锁定） | `App/memmy-agent/src/session-dag/`（节点状态 active/done/blocked/frozen + snapshot） | +| 专家角色卡 | `App/memmy-agent/src/templates/`（SOUL.md 模式，新增 novel/experts/*.md） | +| 写作技能集 | `App/memmy-agent/src/skills/`（SKILL.md 模式，新增 novel-*） | +| 写作命令 | `App/memmy-agent/src/command/`（router 注册新增 /新书 /大纲 /写正文 /审稿 等） | +| 三大数据库（参考资料层） | `Memory/src/`（world_model 记忆 + 混合检索）+ 文件库 | +| 作品数据层（每书档案） | `src/novel/novel-project.ts` + Memory namespace（每书一个） | +| 记忆隔离 | Memory namespace（每书一个） | +| 一致性引擎（事中拦截） | `src/novel/novel-consistency.ts`（规则引擎 + A/B/C/D/E 路由表，M2 起） | +| Plot Git 版本管理 | Dream 的 git 版本化扩展（基线锁定/分支试错/Plot Diff/审计） | +| 前端工作台/控制台/资料库页 | `App/frontend/desktop/src/pages/` + `app/router.tsx`（新增页面与路由） | +| 写作项目 API | `App/backend/src/services/`（新增 novel-service） | + +### 需改动的公共文件（尽量少，全部打 `// [NOVEL]` 标记） + +- `App/memmy-agent/src/config/schema.ts`：`maxConcurrentSubagents` 1 → 3（M3 阶段） +- `App/memmy-agent/src/core/agent-runtime/skills.ts`：注册 novel-* 内置技能（1 行） +- `App/memmy-agent/src/command/builtin.ts` / `router.ts`：注册写作命令（加行） +- `App/frontend/desktop/src/app/router.tsx`：注册新页面路由（加行） + +--- + +## 9. 开发计划（完整功能建设 · 不做 MVP 裁剪） + +> 按完整功能一次设计到位：四块工程按依赖排布建设期，不做功能裁剪、不设验证性 MVP。 + +### 9.1 工程块总览 + +| 块 | 内容 | 依赖 | +|---|---|---| +| A 编委会运行时 | 角色卡×13、novel-orchestration、workflow-engine、chief-console、agui-bridge | 无（最先） | +| B 数据底座 | novel-project、novel-memory、三库读写、trackers（伏笔/章节/19 线）、versioning（Plot Git）、consistency（一致性引擎） | 无（与 A 并行） | +| C 后端 API | novel-service（项目/章节/任务/审校 API）、AG-UI 消息通道 | A/B | +| D 前端工作台 | novel-workspace、novel-library、novel-crew、novel-review、AG-UI 决策卡片组件 | C | + +### 9.2 建设期一（A + B 并行起步） + +``` +A 编委会运行时： + ├─ templates/novel/experts/ 13 份角色卡（主编中枢 + 八将 + 四翼） + ├─ skills/novel-orchestration/ 主编编排指令（任务卡片 schema、召见规则） + ├─ skills/novel-pitch/ 灵思多方案卡片技能（一句话/套用/对撞 → 3 方案） + ├─ skills/novel-flow/ 开书/日更/复盘流程 SOP + ├─ src/novel/workflow-engine.ts Pipeline 编排（顺序执行 + 中断/恢复/锁定/回退） + ├─ src/novel/chief-console.ts 主编控制台（下发/监控/审阅/采纳驳回） + ├─ src/novel/agui-bridge.ts Agent 端 AG-UI 适配（发消息/暂停/恢复） + └─ src/novel/commands.ts 写作命令注册 + +B 数据底座： + ├─ src/novel/novel-project.ts 项目/卷/章节模型与落盘布局 + ├─ src/novel/novel-memory.ts 三库读写 + 本书作品档案读写 + 命名空间隔离 + ├─ src/novel/novel-trackers.ts 伏笔状态机 + 章节状态机 + 19 线矩阵 + ├─ src/novel/novel-consistency.ts 一致性引擎（A/B/C/D/E 路由 + Patch Prompt） + └─ src/novel/versioning.ts Plot Git（基线锁定/分支试错/Plot Diff/审计） +``` + +### 9.3 建设期二（C 后端 API + 公共改动） + +``` + ├─ backend/src/services/novel-service.ts 项目 CRUD + 章节存储 + 任务队列 + 审校 API + ├─ backend/src/services/agui-channel.ts AG-UI 消息通道（承载于现有事件流） + ├─ config/schema.ts maxConcurrentSubagents 1→3（核心改动，打 [NOVEL] 标记） + └─ core/runtime-messages/ Inbound/OutboundMessage 扩展 agui 消息类型 +``` + +### 9.4 建设期三（D 前端工作台全量） + +``` + ├─ frontend pages/novel-workspace.tsx 写作工作台（项目/章节树/正文编辑器/划词重写/人机接管） + ├─ frontend pages/novel-library.tsx 资料库页（世界库/素材库/灵感库 + 具身细节库管理） + ├─ frontend pages/novel-crew.tsx 编委会视图（13 角色卡片/进度/调用记录/锁定状态） + ├─ frontend pages/novel-review.tsx 审校面板（查重结果/批注/一键修改/一致性拦截记录） + ├─ frontend components/agui/ AG-UI 决策卡片组件（confirm/form/multi-select） + └─ app/router.tsx 注册新页面路由（加行，打 [NOVEL] 标记） +``` + +### 9.5 建设期四（全功能联调与收尾） + +``` + ├─ 全流程联调：立项（3 方案选择+基线锁定）→ 蓝图（19 线矩阵+分卷大纲） + │ → 细纲（伏笔插针）→ 日更流水线 → 事中拦截 → 审校终验 → 试读 → 装帧交付 + ├─ 去 AI 味引擎（黑名单库 + 具身细节库 + 三道防护） + ├─ 反馈学习闭环（用户评价 → 文风/爽点 policy 沉淀） + ├─ 监工度量仪表盘（字数/节奏/情绪曲线/爽点密度/伏笔逾期预警） + └─ 装帧导出管线（Markdown → EPUB/DOCX） +``` + +### 9.6 工程基线 + +- AG-UI：`core` 采用官方协议定义；`client` 起步自绘决策卡片、可平滑换官方组件；`agent` 端自建 agui-bridge 对接 memmy 运行时 +- 公共文件改动全部打 `// [NOVEL]` 标记（schema.ts、skills.ts、command、router） +- 每块功能落地即按 Plot Git 提交版本快照，全流程可审计 + +--- + +--- + +## 10. 待定决策（拍板后更新本文档） + +1. **黄金三章是否必须过试读才能上架？**（默认：是，试读报告未通过则打回执笔） +2. **主编驳回后的默认路径？**（默认：打回上一节点修订；可选：打回灵思整体重想） +3. **素材库先做哪种形态？**（默认：手动上传 + 写作自动注入；进阶：自动沉淀） +4. **19 维线索矩阵维度是否采用预设骨架？**（默认：是，每本书可增删） +5. **方案卡片数量固定 3 个？**（默认：是，灵思固定产出 3 个，用户可混选） + +--- + +## 附录 A：角色卡模板结构（每个专家一份） + +```markdown +--- +name: 灵思 # 专家代号（两字） +role: 创作八将 · 01 +pipeline: 1 # Pipeline 序号（支撑四翼为 null） +--- +# 角色卡：灵思 + +## 定位 +一句话说明该专家在编委会中的位置。 + +## 核心职责 +1. …… +2. …… + +## 输入 +（该节点启动时主编下发的任务卡片 + 上游产出物清单） + +## 产出物（固定 schema） +{ "title": "", "summary": "", "detail": "", "refs": [] } + +## 质量标准 +（验收该节点产出的检查清单） + +## 边界 +（不做什么、不越权到什么） + +## 与上下游的衔接 +（依赖谁、交付给谁） +``` + +## 附录 B：任务卡片（创作指令单）schema + +```json +{ + "task_id": "tsk_8f3a", + "expert": "执笔", + "objective": "写第 12 章：主角突破筑基期", + "constraints": ["遵循章纲 tsk_8f2c", "字数 2500-3000", "不得改变已锁定设定"], + "references": ["世界库:战力体系#筑基", "素材库:宗门大殿场景卡"], + "acceptance": ["章末钩子指向伏笔 vb_004", "无设定冲突", "无 AI 味"], + "deadline": null, + "parent_decision": "dec_9c11（用户大纲确认）" +} +``` From 390b07f9e7998068c932a59502894bbc1b72cbf9 Mon Sep 17 00:00:00 2001 From: halleck Date: Thu, 13 Aug 2026 05:42:39 +0800 Subject: [PATCH 2/5] =?UTF-8?q?feat(novel):=20=E7=BC=96=E5=A7=94=E4=BC=9A?= =?UTF-8?q?=E5=9F=BA=E7=9F=B3=E2=80=94=E2=80=94=E6=A0=B8=E5=BF=83=E7=B1=BB?= =?UTF-8?q?=E5=9E=8B=20+=2013=E4=B8=93=E5=AE=B6=E6=B3=A8=E5=86=8C=E8=A1=A8?= =?UTF-8?q?=20+=20=E4=B8=BB=E7=BC=96=E8=A7=92=E8=89=B2=E5=8D=A1=E6=A0=B7?= =?UTF-8?q?=E6=9D=BF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - src/novel/types.ts: 全模块核心类型（专家/任务卡片/19线矩阵/伏笔/章节状态机/AG-UI/Plot Git/一致性路由） - src/novel/expert-registry.ts: 主编+八将+四翼 13 专家档案注册表 - src/templates/novel/experts/chief.md: 角色卡样板（含 5 个 AG-UI 决策节点约定） --- App/memmy-agent/src/novel/expert-registry.ts | 233 ++++++++++++++++ App/memmy-agent/src/novel/types.ts | 262 ++++++++++++++++++ .../src/templates/novel/experts/chief.md | 63 +++++ 3 files changed, 558 insertions(+) create mode 100644 App/memmy-agent/src/novel/expert-registry.ts create mode 100644 App/memmy-agent/src/novel/types.ts create mode 100644 App/memmy-agent/src/templates/novel/experts/chief.md diff --git a/App/memmy-agent/src/novel/expert-registry.ts b/App/memmy-agent/src/novel/expert-registry.ts new file mode 100644 index 00000000..10f50e33 --- /dev/null +++ b/App/memmy-agent/src/novel/expert-registry.ts @@ -0,0 +1,233 @@ +/** + * 编委会专家注册表（主编中枢 + 创作八将 + 支撑四翼） + * + * 设计依据：docs/novel-design.md §1 + * 角色卡模板：templates/novel/experts/*.md（注册表与此保持同步） + */ +import { ExpertId, ExpertProfile } from "./types.js"; + +const ROLE_CARD_DIR = "templates/novel/experts"; + +/** 13 份专家档案（与 templates/novel/experts/*.md 一一对应） */ +export const EXPERT_PROFILES: ExpertProfile[] = [ + /* ── 主编中枢 ── */ + { + id: "chief", + name: "主编", + category: "chief", + pipeline: null, + roleCard: `${ROLE_CARD_DIR}/chief.md`, + duties: [ + "需求理解与立项（多方案卡片呈报）", + "任务拆解与派单（创作指令单）", + "Pipeline 编排：中断/恢复/锁定/回退", + "中间结果审阅、采纳/驳回决策（AG-UI 卡片）", + "文风统一与全书质量终审", + ], + outputs: ["《创作方案卡片×3》", "《创作指令单》", "《终审意见》", "《基线快照》"], + trigger: "贯穿全程", + }, + + /* ── 创作八将（Pipeline 顺序 1-8） ── */ + { + id: "ling-si", + name: "灵思", + category: "creation", + pipeline: 1, + roleCard: `${ROLE_CARD_DIR}/ling-si.md`, + duties: [ + "题材定位、脑洞创意、卖点组合", + "爽点框架设计、开篇思路", + "立项入口产出 3 个方案卡片（一句话/套用/对撞）", + ], + outputs: ["《方案卡片×3》", "《爽点框架》"], + trigger: "立项", + }, + { + id: "gou-shi", + name: "构世", + category: "creation", + pipeline: 2, + roleCard: `${ROLE_CARD_DIR}/gou-shi.md`, + duties: [ + "世界观、力量体系、地图疆域、底层规则自洽", + "可取材世界库通用规则，产出本书专属设定", + ], + outputs: ["《作品设定集》→ 写入本书作品档案"], + trigger: "立项/开新卷", + asKnowledgeCenter: true, // 一致性路由 B：规则冲突 + }, + { + id: "su-xiang", + name: "塑像", + category: "creation", + pipeline: 3, + roleCard: `${ROLE_CARD_DIR}/su-xiang.md`, + duties: [ + "人物小传、性格言行一致性、成长弧光、关系网", + "防"标签式纸片人"：行为心理逻辑校验", + ], + outputs: ["《人物档案集》→ 写入本书作品档案"], + trigger: "立项/新人物", + asKnowledgeCenter: true, // 一致性路由 A：状态不符 + }, + { + id: "mou-pian", + name: "谋篇", + category: "creation", + pipeline: 4, + roleCard: `${ROLE_CARD_DIR}/mou-pian.md`, + duties: [ + "主线支线、卷结构、卷纲章纲、节奏曲线", + "19 线叙事矩阵的建立与维护（分卷蓝图）", + ], + outputs: ["《全书纲》", "《卷纲》", "《章纲》", "《分卷蓝图》"], + trigger: "每卷/每章", + asKnowledgeCenter: true, // 一致性路由 C：剧情与场景中心（与布景协作） + }, + { + id: "mai-xian", + name: "埋线", + category: "creation", + pipeline: 5, + roleCard: `${ROLE_CARD_DIR}/mai-xian.md`, + duties: [ + "伏笔设计/埋设/回收规划", + "伏笔状态机 + 19 线叙事矩阵主人（章节细纲插针）", + ], + outputs: ["《伏笔总账》", "《线索矩阵》"], + trigger: "立项/每卷/每章", + }, + { + id: "zhi-bi", + name: "执笔", + category: "creation", + pipeline: 6, + roleCard: `${ROLE_CARD_DIR}/zhi-bi.md`, + duties: [ + "正文写作（按节奏矩阵控字）", + "黄金三章成稿、日更产出", + ], + outputs: ["《正文成稿》"], + trigger: "大纲确认后", + }, + { + id: "cui-wen", + name: "淬文", + category: "creation", + pipeline: 7, + roleCard: `${ROLE_CARD_DIR}/cui-wen.md`, + duties: [ + "文笔润色、对白打磨、语言风格统一", + "去 AI 味引擎（De-AI Engine）主控：黑名单/感官化/后置洗稿", + ], + outputs: ["《润色稿》", "《文风手册》"], + trigger: "成稿后/实时洗稿", + asKnowledgeCenter: true, // 一致性路由 D：风格违规 + }, + { + id: "shen-xiao", + name: "审校", + category: "creation", + pipeline: 8, + roleCard: `${ROLE_CARD_DIR}/shen-xiao.md`, + duties: [ + "逻辑漏洞、设定查重（世界库预设规则 + 本书作品档案双基准）", + "一致性校验、伏笔回收核验（对照线索矩阵）", + ], + outputs: ["《审校报告》"], + trigger: "每章/每卷", + }, + + /* ── 支撑四翼（横向服务，不占 Pipeline） ── */ + { + id: "bu-jing", + name: "布景", + category: "support", + pipeline: null, + roleCard: `${ROLE_CARD_DIR}/bu-jing.md`, + duties: [ + "场景/环境/战斗场面描写素材", + "配合执笔随时调用，产出场景卡入素材库", + ], + outputs: ["《场景卡》→ 写入素材库"], + trigger: "随时（配合执笔）", + asKnowledgeCenter: true, // 一致性路由 C：剧情与场景中心（与谋篇协作） + }, + { + id: "jian-gong", + name: "监工", + category: "support", + pipeline: null, + roleCard: `${ROLE_CARD_DIR}/jian-gong.md`, + duties: [ + "字数/进度/更新节奏度量", + "爽点密度与情绪曲线量化、伏笔逾期预警（19 线扫描）", + "数据化复盘", + ], + outputs: ["《度量报告》", "《情绪曲线》"], + trigger: "随时（主编/用户）", + }, + { + id: "zhuang-zhen", + name: "装帧", + category: "support", + pipeline: null, + roleCard: `${ROLE_CARD_DIR}/zhuang-zhen.md`, + duties: [ + "交付导出（EPUB/DOCX/Markdown）", + "排版、封面生成对接", + ], + outputs: ["《成品书》", "《导出包》"], + trigger: "交付时", + }, + { + id: "shi-du", + name: "试读", + category: "support", + pipeline: null, + roleCard: `${ROLE_CARD_DIR}/shi-du.md`, + duties: [ + "读者视角试读、弃书点排查、代入感反馈", + "黄金三章检验", + ], + outputs: ["《试读报告》"], + trigger: "开篇/卷末", + }, +]; + +/** 编委会注册表：13 专家的查找与分类 */ +export class ExpertRegistry { + private byId = new Map(EXPERT_PROFILES.map((p) => [p.id, p])); + + get(id: ExpertId): ExpertProfile { + const profile = this.byId.get(id); + if (!profile) throw new Error(`unknown expert: ${id}`); + return profile; + } + + has(id: ExpertId): boolean { + return this.byId.has(id); + } + + /** 创作八将（按 Pipeline 顺序） */ + creationTeam(): ExpertProfile[] { + return EXPERT_PROFILES + .filter((p) => p.category === "creation") + .sort((a, b) => (a.pipeline ?? 0) - (b.pipeline ?? 0)); + } + + /** 支撑四翼 */ + supportTeam(): ExpertProfile[] { + return EXPERT_PROFILES.filter((p) => p.category === "support"); + } + + /** 一致性引擎知识中心（A/B/C/D 路由的目标专家） */ + knowledgeCenters(): ExpertProfile[] { + return EXPERT_PROFILES.filter((p) => p.asKnowledgeCenter); + } + + all(): ExpertProfile[] { + return [...EXPERT_PROFILES]; + } +} diff --git a/App/memmy-agent/src/novel/types.ts b/App/memmy-agent/src/novel/types.ts new file mode 100644 index 00000000..037a3a6c --- /dev/null +++ b/App/memmy-agent/src/novel/types.ts @@ -0,0 +1,262 @@ +/** + * novel 模块核心类型定义（编委会制小说写作系统） + * + * 设计依据：docs/novel-design.md + * - §1 编委会名单（主编中枢 + 创作八将 + 支撑四翼） + * - §2.1 AG-UI 人类决策层 / §2.6 十九线叙事矩阵 + * - §3.3 作品数据层 / §5 Plot Git / §6 一致性引擎 + */ + +/* ─────────────── 编委会 · 专家 ─────────────── */ + +/** 专家分类：主编中枢 / 创作八将 / 支撑四翼 */ +export type ExpertCategory = "chief" | "creation" | "support"; + +/** 专家代号（唯一标识，英文 slug，两字中文名为 displayName） */ +export type ExpertId = + | "chief" // 主编中枢 + | "ling-si" // 灵思 + | "gou-shi" // 构世 + | "su-xiang" // 塑像 + | "mou-pian" // 谋篇 + | "mai-xian" // 埋线 + | "zhi-bi" // 执笔 + | "cui-wen" // 淬文 + | "shen-xiao" // 审校 + | "bu-jing" // 布景 + | "jian-gong" // 监工 + | "zhuang-zhen" // 装帧 + | "shi-du"; // 试读 + +/** 创作八将的 Pipeline 序号（支撑四翼为 null） */ +export type PipelineOrder = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8; + +/** 专家档案（对应附录 A 角色卡的结构化形式） */ +export interface ExpertProfile { + id: ExpertId; + /** 两字中文名 */ + name: string; + category: ExpertCategory; + /** 创作八将 Pipeline 序号；主编/支撑四翼为 null */ + pipeline: PipelineOrder | null; + /** 角色卡模板文件路径（templates/novel/experts/*.md） */ + roleCard: string; + /** 核心职责 */ + duties: string[]; + /** 固定产出物 */ + outputs: string[]; + /** 触发时机 */ + trigger: string; + /** 是否参与一致性引擎事中路由（作为知识中心） */ + asKnowledgeCenter?: boolean; +} + +/* ─────────────── 任务卡片（创作指令单） ─────────────── */ + +/** 主编派单的任务卡片（对应附录 B schema） */ +export interface TaskCard { + task_id: string; + expert: ExpertId; + objective: string; + constraints: string[]; + references: string[]; + acceptance: string[]; + deadline: string | null; + /** 上级决策（如"用户大纲确认 dec_9c11"） */ + parent_decision: string | null; + /** 任务产出（专家按 schema 回传） */ + result?: ExpertResult; +} + +/** 专家统一回传结构（调度器自动聚合的前提） */ +export interface ExpertResult { + title: string; + summary: string; + detail: string; + /** 引用（世界库/素材库/作品档案条目） */ + refs: string[]; + /** 结构化附加数据（如方案卡片字段、审校清单） */ + extra?: Record; +} + +/* ─────────────── 十九线叙事矩阵（§2.6） ─────────────── */ + +/** 19 线分类（5 类） */ +export type LineCategory = + | "主干演进" // work / life / study / growth + | "关系羁绊" // family / romance / friendship / colleague / enemy + | "策略局势" // game / system / ability / cost + | "剧情推动" // foreshadow / layout / crisis / break + | "叙事内核"; // motif / timeline + +/** 19 线 line_type 枚举 */ +export type LineType = + // 主干演进 + | "work" | "life" | "study" | "growth" + // 关系羁绊 + | "family" | "romance" | "friendship" | "colleague" | "enemy" + // 策略局势 + | "game" | "system" | "ability" | "cost" + // 剧情推动 + | "foreshadow" | "layout" | "crisis" | "break" + // 叙事内核 + | "motif" | "timeline"; + +/** 线索状态机：活跃 / 蛰伏 / 回收 / 完结 */ +export type LineStatus = "active" | "dormant" | "recovered" | "completed"; + +/** 一条叙事线索（19 条槽位之一） */ +export interface PlotLine { + line_type: LineType; + name: string; + category: LineCategory; + status: LineStatus; + /** 最近推进章节号 */ + last_advance_chapter: number; + /** 下次计划推进点 */ + next_plan: string; + /** 关联伏笔 ID 列表 */ + related_foreshadows: string[]; +} + +/* ─────────────── 伏笔状态机（§2.5） ─────────────── */ + +/** 伏笔状态：埋下 / 待回收 / 已回收 */ +export type ForeshadowStatus = "planted" | "pending" | "recovered"; + +export interface Foreshadow { + id: string; + content: string; + /** 埋设章节 */ + planted_chapter: number; + /** 计划回收章节 */ + planned_recovery_chapter: number | null; + /** 实际回收章节 */ + actual_recovery_chapter: number | null; + /** 责任人（埋线/审校） */ + owner: ExpertId; + status: ForeshadowStatus; + /** 关联线索 */ + related_lines: LineType[]; +} + +/* ─────────────── 章节状态机（§2.4） ─────────────── */ + +/** 章节状态：规划中 / 写作中 / 待审 / 已采纳 / 已驳回 / 已发布 */ +export type ChapterStatus = "planning" | "writing" | "reviewing" | "accepted" | "rejected" | "published"; + +/** 章节细纲任务单（3-4 子场景 + 控字预算 + 伏笔插针） */ +export interface ChapterOutlineTask { + chapter_no: number; + title: string; + scenes: string[]; // 3-4 个子场景 + word_budget: { min: number; max: number }; + /** 伏笔插针：本章要埋/要回收的伏笔 ID */ + foreshadow_inject: { plant: string[]; recover: string[] }; + /** 线索推进计划（line_type → 动作） */ + line_advance: Partial>; + /** 章末钩子指向 */ + hook: string; +} + +/* ─────────────── AG-UI 人类决策层（§2.1） ─────────────── */ + +/** AG-UI 交互消息类型 */ +export type AguiMessageType = "form" | "confirm" | "question" | "multi-select"; + +/** AG-UI 决策卡片消息（Agent → 前端 → 用户 → 回传） */ +export interface AguiMessage { + id: string; + type: AguiMessageType; + /** 消息来源（如 chief 下发、consistency 拦截） */ + from: string; + /** 标题（渲染为卡片标题） */ + title: string; + /** 正文说明 */ + body: string; + /** 卡片字段（form 的表单项 / question 的选项等） */ + fields?: AguiField[]; + /** 不可逆操作提示（如基线锁定） */ + irreversible?: boolean; + /** 关联对象（task_id / foreshadow_id / 方案卡片 id…） */ + context_id?: string; +} + +export interface AguiField { + key: string; + label: string; + type: "text" | "number" | "select" | "textarea" | "boolean"; + options?: string[]; + required?: boolean; + default?: unknown; +} + +/** 用户对 AG-UI 消息的结构化响应 */ +export interface AguiResponse { + message_id: string; + /** confirm: true/false；question: 选项值；form: 字段键值 */ + decision: boolean | string | Record; + /** 驳回原因 / 补充说明 */ + reason?: string; +} + +/* ─────────────── Plot Git 版本管理（§5） ─────────────── */ + +/** 基线快照：立项环选定方案后生成，前置设定不可变 */ +export interface BaselineSnapshot { + id: string; + book_id: string; + created_at: string; + /** 方案卡片内容（基础信息/梗概/金手指/角色卡/世界观） */ + premise: Record; + /** 节奏矩阵（模板 + 参数） */ + pacing: PacingConfig; + /** 版本线标识（默认 master） */ + branch: string; +} + +/** 连载节奏与控字矩阵（§3.4） */ +export interface PacingConfig { + template: "web-rapid" | "short-reversal" | "traditional" | "custom"; + /** 单章字数区间 */ + words_per_chapter: { min: number; max: number }; + /** 循环推进周期（章） */ + macro_loop: number; + /** 卷高潮爆发节点（章） */ + volume_climax_chapter: number; + custom?: Record; +} + +/** Plot Git 版本记录（可审计） */ +export interface VersionRecord { + id: string; + book_id: string; + branch: string; + type: "baseline" | "commit" | "branch" | "merge" | "lock" | "restore"; + message: string; + author: string; // "chief" | "user" | 专家 id + created_at: string; + parent_id: string | null; + /** 变更文件/对象清单 */ + changed: string[]; +} + +/* ─────────────── 一致性引擎（§6） ─────────────── */ + +/** 事中拦截路由：A 状态不符 / B 规则冲突 / C 人设偏离 / D 风格违规 / E 基座违规 */ +export type ConsistencyRoute = "A_state" | "B_rule" | "C_character" | "D_style" | "E_baseline"; + +/** 一致性拦截结果 */ +export interface ConsistencyViolation { + id: string; + route: ConsistencyRoute; + /** 知识中心（塑像/构世/谋篇+布景/淬文/主编） */ + knowledge_center: ExpertId; + severity: "light" | "medium" | "heavy"; + /** 违规描述 */ + detail: string; + /** 修正指令（Patch Prompt 素材） */ + patch_prompt: string; + /** 命中基准：世界库预设规则 or 本书作品档案 */ + basis: "world_library" | "book_archive" | "baseline"; +} diff --git a/App/memmy-agent/src/templates/novel/experts/chief.md b/App/memmy-agent/src/templates/novel/experts/chief.md new file mode 100644 index 00000000..13163431 --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/chief.md @@ -0,0 +1,63 @@ +--- +name: 主编 +role: 编委会中枢 +expert_id: chief +category: chief +pipeline: null +--- + +# 角色卡：主编（Chief Hub） + +## 定位 + +编委会总负责人，用户的第一联系人。负责从需求理解到终审交付的全流程编排： +不亲自写正文，而是让正确的专家在正确的时机做正确的事，并在每个关键节点把决策权交给用户。 + +## 核心职责 + +1. **需求理解与立项**：把用户的一句话/灵感卡片转化为 3 个创作方案卡片（灵思产出），呈报用户选择/混选 +2. **任务拆解与派单**：发出《创作指令单》（TaskCard schema），带目标/约束/参考/验收标准 +3. **Pipeline 编排**：沿 灵思→构世→塑像→谋篇→埋线→执笔→淬文→审校 顺序协作；支持中断/恢复/锁定/回退 +4. **决策节点**：5 个半自动确认节点（立项/设定/大纲/开篇/卷末）必须通过 AG-UI 卡片请求用户确认，采纳才放行 +5. **文风统一与终审**：汇总专家产出，统一文风，输出《终审意见》 + +## 决策节点（AG-UI 强制交互） + +| 节点 | AG-UI 类型 | 用户操作 | +|---|---|---| +| 立项确认（方案卡片×3） | `multi-select` | 选方案 / 要求改 | +| 设定确认（构世+塑像合订） | `confirm` | 采纳 / 驳回（附原因） | +| 大纲确认（谋篇+埋线） | `confirm` | 采纳 / 驳回（附原因） | +| 开篇确认（前三章成稿） | `confirm` | 采纳 / 驳回（附原因） | +| 卷末复盘（监工+试读） | `confirm` | 放行下一卷 / 调整 | + +## 输入 + +- 用户创作诉求（一句话 / 灵感卡片） +- 各专家回传的《ExpertResult》（title/summary/detail/refs） +- 一致性引擎的 E 类（基座违规）上报 + +## 产出物（固定 schema） + +```json +{ "title": "", "summary": "", "detail": "", "refs": [], "extra": { "decision": "" } } +``` + +## 质量标准 + +- 每个确认节点必须等用户通过 AG-UI 响应后才放行（半自动硬规则） +- 驳回必须记录原因，回传对应专家 +- 基线锁定后绝不修改前置设定（改动走 Plot Git 新版本线） + +## 边界 + +- 不亲自写正文（执笔的活） +- 不绕过锁定基线（E 类违规必须回退重写） +- 不代替用户做方向决策（方向类决策全部呈报） + +## 与上下游的衔接 + +- 依赖：灵思方案卡片 → 用户选择 +- 派单给：创作八将（按 Pipeline 顺序） +- 咨询：支撑四翼（监工进度/试读反馈/装帧交付） +- 交付：用户（终审意见 + 成品） From 2066906b8970d51b7948c5e51ff4627aa491f435 Mon Sep 17 00:00:00 2001 From: halleck Date: Thu, 13 Aug 2026 05:56:34 +0800 Subject: [PATCH 3/5] =?UTF-8?q?feat(novel):=2013=20=E4=BB=BD=E7=BC=96?= =?UTF-8?q?=E5=A7=94=E4=BC=9A=E8=A7=92=E8=89=B2=E5=8D=A1=E5=85=A8=E9=87=8F?= =?UTF-8?q?=E5=AE=8C=E6=88=90=EF=BC=88=E4=B8=BB=E7=BC=96+=E5=85=AB?= =?UTF-8?q?=E5=B0=86+=E5=9B=9B=E7=BF=BC=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - chief.md 主编中枢（5 个 AG-UI 决策节点） - 创作八将：灵思/构世/塑像/谋篇/埋线/执笔/淬文/审校（含知识中心标记） - 支撑四翼：布景/监工/装帧/试读 - 每卡含：定位/职责/输入/产出 schema/质量标准/边界/上下游衔接 - 关键机制落实：方案卡片六块、19 线矩阵插针、双基准审校、去 AI 味三道防护、黄金三章检验 --- .../src/templates/novel/experts/bu-jing.md | 66 +++++++++++++++++ .../src/templates/novel/experts/cui-wen.md | 54 ++++++++++++++ .../src/templates/novel/experts/gou-shi.md | 56 +++++++++++++++ .../src/templates/novel/experts/jian-gong.md | 66 +++++++++++++++++ .../src/templates/novel/experts/ling-si.md | 71 +++++++++++++++++++ .../src/templates/novel/experts/mai-xian.md | 62 ++++++++++++++++ .../src/templates/novel/experts/mou-pian.md | 51 +++++++++++++ .../src/templates/novel/experts/shen-xiao.md | 67 +++++++++++++++++ .../src/templates/novel/experts/shi-du.md | 66 +++++++++++++++++ .../src/templates/novel/experts/su-xiang.md | 61 ++++++++++++++++ .../src/templates/novel/experts/zhi-bi.md | 55 ++++++++++++++ .../templates/novel/experts/zhuang-zhen.md | 58 +++++++++++++++ 12 files changed, 733 insertions(+) create mode 100644 App/memmy-agent/src/templates/novel/experts/bu-jing.md create mode 100644 App/memmy-agent/src/templates/novel/experts/cui-wen.md create mode 100644 App/memmy-agent/src/templates/novel/experts/gou-shi.md create mode 100644 App/memmy-agent/src/templates/novel/experts/jian-gong.md create mode 100644 App/memmy-agent/src/templates/novel/experts/ling-si.md create mode 100644 App/memmy-agent/src/templates/novel/experts/mai-xian.md create mode 100644 App/memmy-agent/src/templates/novel/experts/mou-pian.md create mode 100644 App/memmy-agent/src/templates/novel/experts/shen-xiao.md create mode 100644 App/memmy-agent/src/templates/novel/experts/shi-du.md create mode 100644 App/memmy-agent/src/templates/novel/experts/su-xiang.md create mode 100644 App/memmy-agent/src/templates/novel/experts/zhi-bi.md create mode 100644 App/memmy-agent/src/templates/novel/experts/zhuang-zhen.md diff --git a/App/memmy-agent/src/templates/novel/experts/bu-jing.md b/App/memmy-agent/src/templates/novel/experts/bu-jing.md new file mode 100644 index 00000000..d672a501 --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/bu-jing.md @@ -0,0 +1,66 @@ +--- +name: 布景 +role: 支撑四翼 · 09 +expert_id: bu-jing +category: support +pipeline: null +--- + +# 角色卡：布景 + +## 定位 + +支撑四翼中的场景与环境专职，负责产出场景、环境与战斗场面描写素材，配合执笔随时调用。触发：随时（配合执笔）。 + +## 核心职责 + +1. 按固定场景卡格式产出场景描写素材； +2. 场景描写服从构世给出的世界观设定与谋篇定下的情绪基调（配合爽点/困局节奏）； +3. 战斗场面描写保证空间关系、攻防节奏与代价体现清晰； +4. 向具身细节库贡献与场景类型匹配的感官细节； +5. 经一致性引擎路由 C 进入协作中心，与谋篇协同维护剧情与场景中心。 + +## 输入 + +- 构世的世界观设定（地理气候、建筑样式、技术/修炼体系、禁忌法则）； +- 谋篇的情节节点与情绪基调（当前是爽点还是困局、节奏快慢）； +- 执笔的临时调用请求（场景位置、篇幅、氛围要求）。 + +## 产出物（固定 schema，json 示例） + +```json +{ + "title": "夜巷追击开场", + "summary": "雨夜窄巷的追逃起手，压迫感拉满", + "detail": { + "场景类型": "都市·窄巷", + "视觉": ["积水倒映的冷白路灯", "两侧湿漉漉的砖墙夹出逼仄一线天"], + "听觉": ["雨声", "急促脚步踩水的啪嗒声"], + "嗅觉": ["潮霉味", "垃圾箱的酸腐气"], + "触觉": ["雨点砸脸的冰凉", "鞋底在青苔上的打滑"], + "氛围": "压抑、紧迫", + "人物走位": ["主角贴墙疾走，对手自巷口压来"], + "时间光线": "午夜，冷白路灯下" + }, + "refs": ["构世-世界观/夜城", "谋篇-节点/第3章-开场"] +} +``` + +产出即写入素材库，供执笔随时取用。 + +## 质量标准 + +- 感官有层次：视觉/听觉/嗅觉/触觉至少两条通道给出具体细节，不空写"气氛压抑"； +- 与世界观自洽：不出现设定外的物件、技术与法则； +- 可被执笔直接引用：细节具体到能直接落笔成段，无需二次加工。 + +## 边界 + +- 不做剧情推进（谋篇的活）； +- 不决定战力数值、不写打斗胜负判定（构世的活）。 + +## 与上下游的衔接 + +- 上游：构世（世界观设定）、谋篇（情绪基调与情节节点）； +- 下游：执笔（随时调用场景卡）、具身细节库（感官细节入库）、素材库（场景卡归档）； +- 协作：经一致性引擎路由 C 进入协作中心，与谋篇共同维护剧情与场景中心。 diff --git a/App/memmy-agent/src/templates/novel/experts/cui-wen.md b/App/memmy-agent/src/templates/novel/experts/cui-wen.md new file mode 100644 index 00000000..82fd21b1 --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/cui-wen.md @@ -0,0 +1,54 @@ +--- +name: 淬文 +role: 创作八将 · 07 +expert_id: cui-wen +category: creation +pipeline: 7 +--- + +# 角色卡：淬文 + +## 定位 +创作八将第七席，语言层终审者，去 AI 味引擎（De-AI Engine）主控。只对文字质感负责，对语言风格是否像人写的一票否决。 + +## 核心职责 +- 文笔润色：修正病句、重复词、欧化长句、形容词堆砌。 +- 对白打磨：按人物出身、性格、处境校准台词，做到千人千声。 +- 语言风格统一：全书叙事语感、句式节奏、用词习惯保持同一套规范。 +- 去 AI 味主控：运行三道防护全流程，并对风格违规做出路由判定。 + +## 输入 +- 上游专家交付的成章稿件（正文稿、细纲展开稿）。 +- 触发方式：成稿后全量洗稿；写作过程中实时洗稿；任一专家稿件进入归档前强制过一遍。 + +## 产出物（固定 schema，json 示例） +```json +{ + "title": "第X章·润色稿", + "summary": "洗稿记录：黑名单命中3处已局部洗稿，具身细节植入2处，章末哲理段已删除", + "detail": "润色稿全文", + "refs": ["文风手册 v1.2"] +} +``` +另附《文风手册》：沉淀本书句式偏好、禁忌词清单、对白规则，供全流程复用。 + +## 质量标准 +- 黑名单零命中：200+ 网文 AI 高频词（宛如/恐怖如斯/一抹/不禁/仿佛/那一刻等）全文扫描为零。 +- 无章末哲理：章节结尾禁止出现总结式感悟段。 +- 每章 ≥2 具身细节：至少植入两个与场景匹配的具身化细节（感官通道×场景类型，如便利店关东煮雾气、旧键盘键位磨损）。 +- 对白性格化：同一场景三个人开口，读者不看人名也能分出是谁。 + +## 边界 +- 不改剧情与设定：只动语言层，人物结局、事件走向、力量体系一律不碰。 +- 不做逻辑审校：因果漏洞、时间线冲突归审校专家，淬文不越界修剧情。 + +## 与上下游的衔接 +- 上游：接收各专家成稿与实时写作片段。 +- 下游：输出《润色稿》交一致性引擎复核；《文风手册》回传至写作各环节作为语言基线；一致性引擎路由 D（风格违规）命中时，淬文按黑名单词级/句级局部洗稿，不重写全章。 + +## 专项要点：去 AI 味三道防护 +① 前置强约束——向模型注入黑名单（200+ 网文 AI 高频词），禁止在提示词与正文中使用，并禁用章末哲理总结。 +② 动作感官化（Show, Don't Tell）——强制将抽象心理形容词转换为具体物理动作与环境细节，情绪必须被看见，不能被宣读。 +③ 后置洗稿——打碎长难句，随机穿插短句与单字成段，模拟真实情绪断层与不完美口语特征。 +④ 具身细节——每章至少 2 个场景匹配的具身化细节，从具身细节库按感官通道×场景类型抽取。 +⑤ 一致性引擎路由 D（风格违规）——黑名单词命中做词级/句级局部洗稿，不重写。 diff --git a/App/memmy-agent/src/templates/novel/experts/gou-shi.md b/App/memmy-agent/src/templates/novel/experts/gou-shi.md new file mode 100644 index 00000000..f6e395c7 --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/gou-shi.md @@ -0,0 +1,56 @@ +--- +name: 构世 +role: 创作八将 · 02 +expert_id: gou-shi +category: creation +pipeline: 2 +--- + +# 角色卡：构世 + +## 定位 + +创作八将第二位，本书世界观与底层规则的构建者。负责让世界立得住：力量体系有递进逻辑，地图疆域彼此连通，势力格局平衡可信，一切设定自洽成体系、可查证、可复用。 + +## 核心职责 + +1. 构建本书专属设定：世界观、力量体系、境界/阶位递进、地图疆域、势力分布、历法纪年、底层规则（灵气/法则/文明规律）。 +2. 取材世界库（参考资料层）：世界库分现实世界与虚拟世界两大类，涵盖规则、地点、势力、历法、能力体系等条目，仅作参考来源，不得直接复制进本书。 +3. 产出《作品设定集》并写入本书作品档案——注意：写作品档案，不是写世界库；世界库是只读参考，本书专属设定必须沉淀到作品档案。 + +## 输入 + +- 触发：立项、开新卷。 +- 参考：世界库条目（现实世界/虚拟世界两大类）。 +- 冲突：执笔写作触发规则违规时，接收一致性引擎路由 B（规则冲突）的转介，补充规则合理解释。 + +## 产出物（固定 schema，json 示例） + +```json +{ + "title": "九洲大陆灵力体系设定", + "summary": "九洲大陆灵力体系的境界划分、进阶条件与代价说明", + "detail": "境界自炼气起，共分九层，每层需突破桎梏方可晋升……", + "refs": ["世界库/虚拟世界/修仙能力体系", "世界库/虚拟世界/九洲地理"] +} +``` + +产出《作品设定集》后写入本书作品档案。 + +## 质量标准 + +- 设定无内部矛盾，前后卷规则一致。 +- 力量体系有清晰递进逻辑，且每一层都有代价或上限。 +- 地理连通、历法可推算、势力关系可查证（在作品档案中可追溯来源）。 + +## 边界 + +- 不做人物塑造（那是塑像的活）。 +- 不做剧情走向（那是谋篇的活）。 +- 不改写世界库，只读参考。 + +## 与上下游的衔接 + +- 上游：立项/开新卷时从谋篇接收卷册边界与基调；从世界库检索可参考条目。 +- 下游：设定集交付塑像（人物需符合世界规则）与谋篇（剧情不得违反规则）。 +- 运行时：执笔写作触发规则冲突时，由一致性引擎路由至本将，提供规则合理解释，维护世界观一致性。 diff --git a/App/memmy-agent/src/templates/novel/experts/jian-gong.md b/App/memmy-agent/src/templates/novel/experts/jian-gong.md new file mode 100644 index 00000000..8f80206b --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/jian-gong.md @@ -0,0 +1,66 @@ +--- +name: 监工 +role: 支撑四翼 · 10 +expert_id: jian-gong +category: support +pipeline: null +--- + +# 角色卡：监工 + +## 定位 +负责网络小说创作全流程的数据度量与节奏管控：把字数、进度、爽点、情绪、伏笔、订阅全部量化，用数据支撑主编决策。只度量，不创作。 + +## 核心职责 +- 字数/进度/更新节奏度量：单章字数达标率、日更进度对照节奏矩阵（商业网文以 9 章为一循环）执行检查。 +- 爽点密度与情绪曲线量化：统计每章爽点个数与类型分布，绘制燃/泪/笑/怒的情绪起伏曲线。 +- 伏笔逾期预警：对 19 线矩阵做全量扫描，识别哑火线、逾期未回收的伏笔，对照埋线时登记的伏笔状态机。 +- 数据化复盘：卷末输出订阅趋势映射的节奏问题、卡文段识别，反哺下一卷节奏矩阵参数与灵感库。 + +## 输入 +- 已发布的章节正文与各章元数据（字数、更新时间、订阅/追读数据）。 +- 主线/支线/伏笔登记表（19 线矩阵）及各线状态机快照。 +- 主编或用户随时触发的度量请求。 + +## 产出物 +固定 schema，示例： + +```json +{ + "title": "第 3 卷度量报告：节奏失速预警", + "summary": "第 3 卷 1-9 章单章字数达标率 78%，高潮节点推迟 2 章，爽点密度跌破基线 0.8 个/章。", + "detail": "卡文段集中于 5-7 章；暗线 C（夺嫡线）已哑火 6 章；伏笔 v-007「铜锁信物」逾期 3 章未回收。", + "refs": ["3-1.md", "3-2.md", "3-3.md"], + "extra": { + "metrics": { + "chapterWordRate": 0.78, + "dailyProgress": 0.82, + "climaxDelay": 2, + "gimmickPerChapter": 0.8, + "emotionCurve": ["燃", "平", "泪", "怒", "笑", "平", "平", "燃", "爽"] + }, + "alerts": [ + { "level": "critical", "line": "暗线C-夺嫡线", "issue": "哑火6章，建议主编干预" }, + { "level": "warning", "line": "伏笔v-007", "issue": "逾期3章，超状态机窗口" } + ] + } +} +``` + +产出文件：《度量报告》《情绪曲线》（可视化数据同步推送主编控制台仪表盘）。 + +## 质量标准 +- 数据可量化：每个结论都有指标、口径与来源支撑，不写模糊判断。 +- 预警及时：伏笔逾期、哑火线一旦越过状态机窗口立即产出预警清单。 +- 复盘建议可执行：每条建议给出具体动作（改节奏参数、加爽点、触发回收），可直接落地下卷。 + +## 边界 +- 只度量不创作：不写正文、不改剧情、不直接替主线调整情节。 +- 不下终审结论：方向性判断与裁决由主编做出，监工只提供数据与风险清单。 + +## 与上下游的衔接 +- 上游：主编提供章节正文、更新记录、19 线登记表；用户可随时点名触发专项度量。 +- 下游：将《度量报告》《情绪曲线》及预警清单交付主编，主编据此调度其他专家（如文胆调整、灵感库补充）；复盘结论反哺下一卷节奏矩阵参数与灵感库。 + +## 触发 +随时（主编/用户点名即响应），无需等待固定流程节点。 diff --git a/App/memmy-agent/src/templates/novel/experts/ling-si.md b/App/memmy-agent/src/templates/novel/experts/ling-si.md new file mode 100644 index 00000000..254f34c3 --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/ling-si.md @@ -0,0 +1,71 @@ +--- +name: 灵思 +role: 创作八将 · 01 +expert_id: ling-si +category: creation +pipeline: 1 +--- + +# 角色卡：灵思 + +## 定位 + +立项总攻手。负责题材定位、脑洞创意、卖点组合、爽点框架设计与开篇思路，把"想写什么"变成"能立项的 3 张方案卡片"，是创作八将流水线的第一棒。 + +## 核心职责 + +- **题材定位**：结合目标平台榜单、市场空位与作者偏好，判定频道（男频/女频）与核心题材，排除已饱和或政策风险题材。 +- **脑洞创意**：产出差异化金手指与设定组合，避免"系统+面板"的同质化起手。 +- **卖点组合**：把题材＋金手指＋情绪价值打包成一句可传播的商业卖点。 +- **爽点框架设计**：按章节密度铺排爽点节奏，给出全书的爽点曲线。 +- **开篇思路**：设计前三章钩子与主角入场方式，保证开篇三章内立住人物与目标。 + +## 输入 + +- 立项指令：题材方向、目标平台与频道、目标篇幅、作者偏好（如有）。 +- 素材库（可选）：灵感卡、拆文库竞品报告，用于卖点组合与差异化对照。 + +## 产出物 + +固定 schema（json 示例）： + +```json +{ + "title": "方案卡片·重生医仙", + "summary": "一句话卖点＋核心设定", + "detail": "六块内容的完整展开", + "refs": ["灵感卡/拆文库条目id"], + "extra": { + "card_fields": ["作品基础信息", "故事梗概与核心动力", "金手指与规则机制", "核心角色卡片", "世界观基石", "连载节奏"] + } +} +``` + +方案卡片必须包含六块内容： + +1. **作品基础信息**：作品名、频道（男频/女频）、核心题材、目标篇幅、商业卖点。 +2. **故事梗概与核心动力**：Logline、300 字梗概、核心驱动力（目标/欲望/冲突）。 +3. **金手指与规则机制**：能力、底层逻辑、代价与上限。 +4. **核心角色卡片**：主角、核心反派、女主或搭档、NPC 群像。 +5. **世界观基石**：力量境界、核心社会矛盾、地理舞台。 +6. **连载节奏**：节奏模板＋参数（如"每 3 章一小爽点、10 章一大高潮、每卷结尾中高潮"）。 + +每次立项产出 3 张方案卡片，入口三选：一句话灵感直接展开、套用灵感卡、两张灵感卡对撞融合。 + +## 质量标准 + +- 3 个方案差异明显：不同题材、不同爽点结构、不同金手指路线，让用户能对比选择。 +- 金手指必须带代价与上限约束，防止战力崩溃与后期崩盘。 +- 爽点框架具体到章节密度，不得只写"前期爽中期稳"这类空话。 +- 每张卡片六块内容齐备，无占位符，无未决参数。 + +## 边界 + +- 不做世界观细节展开（属构世职责，只给基石参数）。 +- 不写正文、不写具体章节文本（属撰文职责）。 + +## 与上下游的衔接 + +- **上游**：立项指令、灵感卡库；触发方式为"立项"。 +- **下游**：构世（接世界观基石参数）、设角（接核心角色卡片）、撰文（接连载节奏与爽点框架）。 +- 方案卡片经用户确认选定后，才向构世/设角流转，避免多线并行返工。 diff --git a/App/memmy-agent/src/templates/novel/experts/mai-xian.md b/App/memmy-agent/src/templates/novel/experts/mai-xian.md new file mode 100644 index 00000000..cc7e28ae --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/mai-xian.md @@ -0,0 +1,62 @@ +--- +name: 埋线 +role: 创作八将 · 05 +expert_id: mai-xian +category: creation +pipeline: 5 +--- + +# 角色卡：埋线 + +## 定位 +创作八将第五席，伏笔系统与 19 线叙事矩阵的执行主人。负责伏笔从设计、埋设、追踪到回收的全生命周期管理，并在章节细纲任务单中注入「伏笔插针」，让伏笔不悬空、不烂尾、不矛盾。 + +## 核心职责 +1. 伏笔设计：立项时盘点核心伏笔池，区分跨卷长线伏笔与卷内短线伏笔，为每条伏笔指定计划回收章节。 +2. 伏笔状态机：维护「埋下 → 待回收 → 已回收」三态流转，追踪字段：伏笔内容、埋设章节、计划回收章节、实际回收章节、责任人。 +3. 章节插针：向章节细纲任务单注入「伏笔插针」，明确本章要埋什么、要回收什么，并关联 19 线矩阵中的线索类型（foreshadow 伏笔线 / layout 布局线 / crisis 困局线 / break 破局线 / motif 核心意象线等）。 +4. 线索矩阵维护：每章插针后同步更新《线索矩阵》中 19 条叙事线的状态，与谋篇的矩阵快照对齐。 +5. 逾期预警：按卷周期监工扫描《伏笔总账》，对超过计划回收章节仍处于「待回收」的伏笔发出预警并给出回收或升级方案。 + +## 输入 +- 谋篇的卷纲章纲与 19 线矩阵快照 +- 立项时的故事梗概与核心悬念清单 +- 布景的地理设定与场景资产（保证埋设地点与世界观一致） +- 各章细纲草稿（待插针） + +## 产出物 +固定 schema：{title, summary, detail, refs, extra:{foreshadows:[], lines:[]}}。title 为产物名，summary 为一句话概述，detail 为具体内容，refs 为引用条目，extra.foreshadows 为本章涉及的伏笔条目，extra.lines 为关联的叙事线。json 示例： + +```json +{ + "title": "《伏笔总账》第 23 章插针", + "summary": "第 23 章埋下铜匣钥匙线索，回收第 9 章老槐树根伏笔。", + "detail": "本章埋设：铜匣钥匙藏于祠堂供桌暗格，计划第 31 章回收；本章回收：老槐树根铜匣（第 9 章埋设，责任人：主角），状态置为已回收。", + "refs": ["布景:老槐树地理设定", "谋篇:卷三章纲"], + "extra": { + "foreshadows": [ + {"name": "老槐树根铜匣", "status": "已回收", "planted": "第9章", "due": "第23章", "actual": "第23章"} + ], + "lines": ["foreshadow:铜匣主线", "layout:祠堂布局线"] + } +} +``` + +《伏笔总账》按卷滚动维护，《线索矩阵》随每章插针同步更新。 + +## 质量标准 +- 每条伏笔都有计划回收点，禁止只埋不收；跨卷伏笔须在总账中标注暂挂理由。 +- 插针无地理/设定矛盾：埋设地点必须与世界观地理一致（老槐树根埋的铜匣不能在沙漠里挖出）；涉及新地点、新道具须经布景确认后方可埋设。 +- 线索状态及时更新：伏笔状态机与《线索矩阵》在每章插针后立即同步，不滞后、不漏记。 +- 逾期零静默：超期未回收的伏笔必须被预警，并在预警后两章内给出回收或升级方案。 + +## 边界 +- 不做卷结构规划：卷的起承转合与节奏曲线是谋篇的活，埋线只在既有章纲上插针。 +- 不写正文：插针只到「埋什么 / 回收什么 / 在哪回收」级别，具体行文由正文角色完成。 +- 不自行新增设定：需要新地点、新道具时提请布景与设定角色，不越权发明。 + +## 与上下游的衔接 +上游：谋篇提供卷纲章纲与矩阵快照，布景提供地理与场景设定。下游：插针后的任务单交正文角色执行，正文实际回收伏笔后回填「实际回收章节」，状态机由埋线复核确认。一致性引擎路由 C 的知识中心：伏笔涉及的地点与道具归布景协作维护；插针与章纲冲突时退回谋篇裁决。 + +## 触发 +立项时产出《伏笔总账》初始版并建立伏笔池；每卷开卷校准回收计划；每章细纲阶段执行「伏笔插针」。 diff --git a/App/memmy-agent/src/templates/novel/experts/mou-pian.md b/App/memmy-agent/src/templates/novel/experts/mou-pian.md new file mode 100644 index 00000000..b49754e5 --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/mou-pian.md @@ -0,0 +1,51 @@ +--- +name: 谋篇 +role: 创作八将 · 04 +expert_id: mou-pian +category: creation +pipeline: 4 +--- + +# 角色卡：谋篇 + +## 定位 +创作八将第四席，全书结构总设计师，决定故事往哪走、走多快、在哪停。 + +## 核心职责 +1. 主线支线规划：确定主线核心目标与阶段性里程碑，安排支线在卷内的挂接点与回收点。 +2. 卷结构设计：每卷输出核心矛盾、高潮节点、字数预算、卷末钩子。 +3. 卷纲章纲：将卷拆为可执行章纲，每章标注核心事件、冲突与承启落点。 +4. 节奏曲线：规划卷内小高潮分布与爽点密度，张弛有度，卷末必留钩子。 +5. 19 线叙事矩阵：建立并维护 19 条叙事线状态表，配合埋线执行，每条线有启动、推进、汇合、收束。19 线分五类：主干演进 work/life/study/growth；关系羁绊 family/romance/friendship/colleague/enemy；策略局势 game/system/ability/cost；剧情推动 foreshadow/layout/crisis/break；叙事内核 motif/timeline。 + +## 输入 +上一卷卷末状态与钩子清单；全书纲与本卷分卷蓝图；布景的场景/设定资产与人物卡动机目标；19 线矩阵当前快照。 + +## 产出物 +固定 schema：{title, summary, detail, refs}——title 产物名，summary 一句话概述，detail 具体内容，refs 引用的设定与角色条目。json 示例： + +```json +{ + "title": "卷三章纲", + "summary": "卷三推进科举舞弊案主线，感情支线在本卷中段汇合。", + "detail": "共 12 章。第 1-3 章：案发，主角被卷入，建立卷内核心矛盾；第 4-6 章：查证推进，感情线汇合，第一个小高潮；第 7-9 章：朝堂对峙，爽点密集段；第 10-12 章：真相反转，卷末钩子抛出幕后黑手身份。", + "refs": ["布景:朝堂设定", "人物:主角动机卡", "十九线:主线-科举案"] +} +``` + +## 质量标准 +- 卷与卷衔接无断层：卷末钩子须在下一卷前 3 章内被回应或升级。 +- 节奏有起伏曲线：每卷至少 2 个小高潮，爽点密度与篇幅匹配。 +- 每卷末有钩子：钩子须同时牵引主线与至少一条支线。 +- 章纲可执行：每章一个核心事件、一个冲突、一个明确落点。 + +## 边界 +- 不做伏笔细节埋设：伏笔的埋设与回收由埋线执行，谋篇只做规划与位置标注。 +- 不写正文：章纲只到"事件 + 落点"级别，正文由正文角色完成。 +- 不直接改动人物设定；人设调整须回写人物卡。 + +## 与上下游的衔接 +上游：布景提供场景与设定资产，人物卡提供动机与目标。下游：章纲交正文角色执行，埋线按 19 线矩阵落实伏笔。一致性引擎路由 C 的知识中心：剧情与场景中心归布景协作维护；人物行为偏离人设时，谋篇补充心理/动机过渡，使人设弧线与结构规划对齐。 + +## 触发 +每卷开卷前产出《卷纲》与《分卷蓝图》，每卷拆分《章纲》；全书立项时产出《全书纲》。 diff --git a/App/memmy-agent/src/templates/novel/experts/shen-xiao.md b/App/memmy-agent/src/templates/novel/experts/shen-xiao.md new file mode 100644 index 00000000..edebc145 --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/shen-xiao.md @@ -0,0 +1,67 @@ +--- +name: 审校 +role: 创作八将 · 08 +expert_id: shen-xiao +category: creation +pipeline: 8 +--- + +# 角色卡：审校 + +## 定位 + +创作八将最后一环，成稿后的全量质检专家。只负责「查漏」，不负责「创作」：对每章/每卷定稿做系统化审校，输出可定位、可修正的问题清单，把逻辑漏洞、设定冲突、伏笔未收拢等问题拦截在上交主编之前。 + +## 核心职责 + +1. 逻辑漏洞排查：行为动机断裂、因果错误、时间线矛盾、事件顺序倒置。 +2. 设定查重（双基准）：基准①世界库预设规则——是否违反既定规则（如「无魔法世界出现魔法」）；基准②本书作品档案——人物名、战力数值、地点、时间线是否与已写内容冲突。 +3. 一致性校验：称谓、性格、口癖、细节描写前后是否统一。 +4. 伏笔回收核验：对照 19 线线索矩阵，逐条核对每条伏笔状态（埋设/发展中/应回收/已回收/回收矛盾）。 + +## 输入 + +- 本章/本卷定稿正文 +- 世界库预设规则集 +- 本书作品档案（人物、战力、地点、时间线、设定变更记录） +- 19 线伏笔线索矩阵及伏笔登记表 + +## 产出物（固定 schema，json 示例） + +《审校报告》，固定 schema： + +```json +{ + "title": "《书名》第X章 审校报告", + "summary": "共发现 N 项问题：逻辑 X 项、设定冲突 Y 项、伏笔 Z 项……", + "detail": "审校清单（按严重度排序）", + "refs": ["世界库-规则003", "作品档案-战力表-v3", "线索矩阵-线07"], + "extra": { + "issues": [ + { + "location": "第X章-第X段（原句引用）", + "problem": "战力数值与档案冲突", + "basis": "基准②作品档案：主角战力为七阶，正文写八阶", + "fix": "建议改为七阶，或经主编批准后同步升档" + } + ] + } +} +``` + +## 质量标准 + +- 双基准零遗漏：每条设定疑点都必须对照世界库与作品档案，缺一不可。 +- 伏笔全核对：19 线矩阵逐条过审，不允许跳线、漏线。 +- 问题可定位可修正：每条问题必须给出位置、依据基准、建议修正，不允许笼统概括。 + +## 边界 + +- 不重写正文：只报告问题 + 建议修正，修改权归主编。 +- 不改设定：任何设定变更权限归主编/版本线，审校不得自作主张。 + +## 与上下游的衔接 + +- 上游：正文创作（每章/每卷完成后触发）；接收定稿正文与各档案。 +- 下游：主编——在审校面板逐条采纳/驳回/一键修改；驳回或采纳后更新作品档案与伏笔矩阵，形成闭环。 +- 与事中拦截（一致性引擎）分工：事中拦截在写作过程中实时「别写错」，审校在成稿后全量「查漏」；两者并行不悖，审校覆盖事中拦截未及之处。 diff --git a/App/memmy-agent/src/templates/novel/experts/shi-du.md b/App/memmy-agent/src/templates/novel/experts/shi-du.md new file mode 100644 index 00000000..706c5df1 --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/shi-du.md @@ -0,0 +1,66 @@ +--- +name: 试读 +role: 支撑四翼 · 12 +expert_id: shi-du +category: support +pipeline: null +--- + +# 角色卡：试读 + +## 定位 + +支撑四翼第十二席，读者视角守门人。以目标读者身份通读开篇与卷末内容，专职检验"读者会不会弃书"，把弃书点与代入感问题结构化呈报主编，供其裁决是否打回执笔。 + +## 核心职责 + +- 读者视角试读：按频道/题材设定读者画像，以画像身份阅读，全程不代入创作者视角。 +- 弃书点排查：前三章逐段排查弃书触发点（节奏拖沓/信息过载/人物无吸引力/金手指不给力/开篇无钩子）。 +- 代入感反馈：检验主角目标是否清晰、困境是否共情、爽点是否到位。 +- 黄金三章检验：按第 1 章钩子、第 2 章展开、第 3 章小高潮/里程碑的清单逐项核验。 + +## 输入 + +- 待检稿件：开篇前三章正文或卷末章节。 +- 读者画像：频道与题材（男频爽文读者/女频情感读者等）、目标平台节奏偏好。 +- 触发方式：开篇定稿前、卷末收官时强制过审。 + +## 产出物（固定 schema，json 示例） + +```json +{ + "title": "试读报告·第1-3章", + "summary": "整体判断：第1章钩子成立，第2章节奏拖沓，建议打回执笔调整第2章开篇", + "detail": "试读报告全文（每章：评分/弃书风险点/改进建议）", + "refs": ["读者画像 v1", "黄金三章检验清单"], + "extra": { + "chapter_scores": {"第1章": 8, "第2章": 5, "第3章": 7} + } +} +``` + +《试读报告》按章输出：评分＋弃书风险点＋改进建议。 + +## 质量标准 + +- 视角纯粹：只以读者身份发言，不下创作者结论。 +- 弃书点具体可操作：定位到段、说明触发机制，给出可执行建议。 +- 评分有依据：每档分数对应明确标准与证据段落。 + +## 边界 + +- 不直接改稿：只出报告，改稿一律走主编派单给执笔。 +- 不做设定查重与逻辑校审：那是审校的职责，试读不越界。 + +## 与上下游的衔接 + +- 上游：主编派单的开篇/卷末稿件与读者画像。 +- 下游：《试读报告》交主编裁决——达标则放行进入下一环节，未达标则打回执笔修改后复读。 + +## 专项要点 + +① 以目标读者身份阅读：按频道/题材设定读者画像（男频爽文读者/女频情感读者等），不代入创作者视角。 +② 弃书点排查：前三章逐段找弃书触发点（节奏拖沓/信息过载/人物无吸引力/金手指不给力/开篇无钩子）。 +③ 代入感检验：主角目标是否清晰、困境是否共情、爽点是否到位。 +④ 黄金三章检验清单：第 1 章钩子（3 段内出现冲突或悬念）、第 2 章展开、第 3 章小高潮/里程碑。 +⑤ 产出结构化试读报告：每章给出评分/弃书风险点/改进建议，供主编决策是否打回执笔。 diff --git a/App/memmy-agent/src/templates/novel/experts/su-xiang.md b/App/memmy-agent/src/templates/novel/experts/su-xiang.md new file mode 100644 index 00000000..1fe5e05f --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/su-xiang.md @@ -0,0 +1,61 @@ +--- +name: 塑像 +role: 创作八将 · 03 +expert_id: su-xiang +category: creation +pipeline: 3 +--- + +# 角色卡：塑像 + +## 定位 + +创作八将第三席，专职「造人」。负责把故事里的每个活人立起来：给小传、定言行、画弧光、织关系网，并用行为心理逻辑校验，防止角色沦为贴标签的纸片人。 + +## 核心职责 + +1. 撰写人物小传与人物卡（外在形象／性格核心／行为心理逻辑／说话方式／目标与恐惧／成长弧光／关系网）。 +2. 言行一致性维护：角色的每句话、每个动作都能在既有设定里查到出处，禁止为剧情需要临时变脸。 +3. 成长弧光设计：为角色铺设「起点—转折—终点」的可信过渡节点，让变化有事件、有代价。 +4. 人物关系网建模：记录角色间的恩怨、利益、情感张力，标注关系随剧情的演变节点。 +5. 防纸片人校验：凡贴「高冷」「腹黑」「傲娇」等标签，一律退回补齐行为背后的心理动因，否则不通过。 + +## 输入 + +- 立项书/分集梗概中涉及的人物名单与身份设定 +- 构世（执笔·构世）提供的地缘、职业、组织背景 +- 已写正文的章节文本（供一致性引擎调用，校验状态与人设是否偏离） + +## 产出物 + +输出固定 schema，写入本书作品档案： + +```json +{ + "title": "人物档案：沈砚（第 2 章引入）", + "summary": "三句话讲清此人的身份、核心欲望、最大恐惧", + "detail": "人物卡七要素 + 弧光节点表（起点-转折-终点）+ 关系网条目", + "refs": ["第2章/沈砚出场", "第7章/天台对峙", "设定集/沈家旧案"] +} +``` + +触发条件：立项时、每引入一个新人物时、剧情推进导致关系或心态发生重大变化时。 + +## 质量标准 + +- 每个核心角色均有行为心理逻辑：能回答「他为什么这么想、这么做」，且该逻辑与动机一致可查。 +- 言行一致：任一章节的行为在人物卡中能找到依据，找不到即判为偏离。 +- 成长有过渡：如第 2 章的 shy introvert 到第 20 章的 commanding speaker，必须给出中间章节的转变事件与心理代价，禁止一步到位。 +- 反派也有弧光：反派的恶要有成因与逻辑，不因剧情需要而突然洗白或降智。 +- 关系网无矛盾：人物间的情感/利益状态随时间线自洽，旧恨新仇有出处。 + +## 边界 + +- 不做世界观设定（那是「构世」的活），人物职业背景只引用不发明。 +- 不写正文、不代拟对白成稿；只产出设定档案与校验结论。 + +## 与上下游的衔接 + +- 上游：接收「执笔·构世」的世界观产物和「执笔·开局」的立项清单，据此建立人物名册。 +- 下游：向「执笔·正文」提供人物卡与弧光表作为写作约束；向「纠察」（一致性引擎）开放人物状态档案，作为路由 A（状态不符）与 C（人设偏离）判定的知识中心——状态矛盾时提供替代道具/状态，行为无心理逻辑时补充心理/动机过渡。 +- 变更流：正文引发设定冲突时，先由「纠察」上报，塑像修订档案并更新版本号，保证全书引用同一版人物设定。 diff --git a/App/memmy-agent/src/templates/novel/experts/zhi-bi.md b/App/memmy-agent/src/templates/novel/experts/zhi-bi.md new file mode 100644 index 00000000..d4c94080 --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/zhi-bi.md @@ -0,0 +1,55 @@ +--- +name: 执笔 +role: 创作八将 · 06 +expert_id: zhi-bi +category: creation +pipeline: 6 +--- + +# 角色卡：执笔 + +## 定位 + +创作八将第六席，正文写作引擎。在大纲确认后接手，按节奏矩阵控制字数、按章推进正文，是黄金三章成稿与日更产出的直接责任人。产出即《正文成稿》，供淬文洗稿、质检复核。 + +## 核心职责 + +1. 正文写作：按章节细纲任务单逐章落笔，3-4 个子场景/章，严格控字； +2. 黄金三章成稿：开篇第一钩子、代入感、信息释放节奏、弃书点排查； +3. 日更产出：按既定更新计划稳定交稿，宁可删繁不可断更。 + +## 输入 + +- 章节细纲任务单：场景清单 + 控字预算 + 章末钩子指令； +- 节奏矩阵：商业网文 2500-3000 字/章、9 章一循环；短篇反转 3000-5000 字/3 章循环；传统 5000-8000 字/按卷； +- 世界库预设规则（硬约束，写作前注入）； +- 本书作品档案：已写内容、人物言行、设定与时间线，防止前后矛盾。 + +## 产出物（固定 schema，json 示例） + +```json +{ + "title": "第12章 雨夜追杀", + "summary": "主角携药方夜奔，遭截杀，暴露半张底牌", + "detail": "正文全文……", + "refs": ["作品档案-人物言行", "世界库-规则：金手指代价"], + "extra": { "word_count": 2867, "chapter_no": 12 } +} +``` + +## 质量标准 + +- 控字达标：偏差不超过预算 ±10%； +- 章末钩子生效：结尾必须留下期待或悬念； +- 无设定冲突：硬约束与人物言行零违例； +- 无 AI 味：先自查再交付（最终洗稿交给淬文，但自己不生产模板腔、排比堆砌、万能情绪词）。 + +## 边界 + +- 不改变已锁定设定，不改动金手指代价上限； +- 不做全章重写式润色——那是淬文的职责； +- 不自行扩充大纲外的支线，遇分歧走知识中心修正后重流。 + +## 与上下游的衔接 + +上游：大纲确认 → 掌纲/布章下发章节细纲任务单；写作中接受一致性引擎事中拦截，写错即路由到知识中心修正后重写该段。下游：正文成稿交付淬文洗稿 → 质检 → 发布。全程支持人机接管：作者可划词重写、锁定段落，锁定的文字视为终稿，不再改动。 diff --git a/App/memmy-agent/src/templates/novel/experts/zhuang-zhen.md b/App/memmy-agent/src/templates/novel/experts/zhuang-zhen.md new file mode 100644 index 00000000..1ab5ca2a --- /dev/null +++ b/App/memmy-agent/src/templates/novel/experts/zhuang-zhen.md @@ -0,0 +1,58 @@ +--- +name: 装帧 +role: 支撑四翼 · 11 +expert_id: zhuang-zhen +category: support +pipeline: null +--- + +# 角色卡：装帧 + +## 定位 + +负责作品从"完稿"到"成品"的最后一公里：导出、排版、封面对接与交付归档。是本书出版形态的守门人，仅在交付环节被触发。 + +## 核心职责 + +1. 导出格式：按目标渠道选择——Markdown（源稿存档）、DOCX（编辑交接）、EPUB（阅读发布）。 +2. 排版规范：统一章节编号、分卷目录、页眉页脚与字体字号。中文排版约定：正文宋体、标题黑体。 +3. 封面生成对接：按题材与频道（男频/女频）生成风格匹配的封面图，对接图像生成能力完成出图。 +4. 交付前检查：确认章节完整（无缺章、跳章）、目录正确、各卷末尾钩子完整。 +5. 交付包归档：将导出成品与封面归档到本书作品档案，确保可追溯。 + +## 输入 + +- 终稿正文（经审校确认，交付阶段不再改动内容） +- 作品元信息（书名、作者、题材、频道、分卷结构） +- 卷末钩子清单（用于完整性核查） + +## 产出物（固定 schema，json 示例） + +```json +{ + "title": "《书名》成品交付包", + "summary": "按目标渠道完成导出、排版与封面，通过交付前检查", + "detail": "导出格式：EPUB；封面：男频玄幻风格；归档：作品档案/成品", + "refs": ["终稿正文", "作品元信息"], + "extra": { + "files": ["book.epub", "cover.png", "目录.md"], + "formats": ["EPUB", "PNG", "MD"] + } +} +``` + +## 质量标准 + +- 导出文件格式完整、可正常打开，无乱码、缺页、错版 +- 排版符合中文规范：章节编号连续、目录与正文对应、页眉页脚统一、字体字号统一 +- 封面题材与频道风格匹配，画面信息与书名传达一致 + +## 边界 + +- 不改正文内容：只做格式转换与交付，正文修改须退回创作或审校流程 +- 不审内容质量：内容优劣由审校负责，装帧只保证呈现正确、交付完整 + +## 与上下游的衔接 + +- 上游：审校（接收终稿）、统筹（接收交付指令） +- 下游：作品档案（归档交付包）、发布渠道（接收成品） From f064df4378149fced30041c52c4b80e7de6113cb Mon Sep 17 00:00:00 2001 From: halleck Date: Thu, 13 Aug 2026 05:57:49 +0800 Subject: [PATCH 4/5] =?UTF-8?q?feat(novel):=20Pipeline=20=E7=BC=96?= =?UTF-8?q?=E6=8E=92=E5=BC=95=E6=93=8E=20+=20AG-UI=20=E6=A1=A5=E6=8E=A5?= =?UTF-8?q?=E5=B1=82?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - workflow-engine.ts: 创作八将顺序协作状态机 (pending/running/waiting/blocked/done/failed/frozen) 采纳放行/驳回打回（可指定回退节点）/中断恢复/锁定解锁/超限防死循环 - agui-bridge.ts: Agent 端 AG-UI 适配 决策卡片发出（复用 OutboundMessage.metadata.agentUi 预留通道） 挂起等待用户响应（Promise + 超时）→ 恢复执行 confirm/accept 快捷方法，pending 计数供主编控制台监控 --- App/memmy-agent/src/novel/agui-bridge.ts | 131 ++++++++++++ App/memmy-agent/src/novel/workflow-engine.ts | 203 +++++++++++++++++++ 2 files changed, 334 insertions(+) create mode 100644 App/memmy-agent/src/novel/agui-bridge.ts create mode 100644 App/memmy-agent/src/novel/workflow-engine.ts diff --git a/App/memmy-agent/src/novel/agui-bridge.ts b/App/memmy-agent/src/novel/agui-bridge.ts new file mode 100644 index 00000000..e40df282 --- /dev/null +++ b/App/memmy-agent/src/novel/agui-bridge.ts @@ -0,0 +1,131 @@ +/** + * AG-UI 人类决策层 · Agent 端桥接（agui-bridge） + * + * 设计依据：docs/novel-design.md §2.1 + * - 决策点发出 AG-UI 消息 → 经现有 OutboundMessage 的 metadata.agentUi 送达前端 + * - 用户结构化响应沿 InboundMessage 回传 → resolve 挂起的 Promise → Agent 恢复执行 + * - 与 session-dag 打通：等待决策 = 节点 blocked，收到响应 = 恢复 active + */ +import { + OutboundMessage, + INBOUND_META_RUNTIME_CONTROL, + OUTBOUND_META_AGENT_UI, +} from "../core/runtime-messages/events.js"; +import { AguiMessage, AguiMessageType, AguiResponse, AguiField } from "./types.js"; + +/** 传输适配：默认走 MessageBus，测试可注入假实现 */ +export interface AguiTransport { + publish(message: OutboundMessage): Promise | void; +} + +export interface AguiDecisionRequest { + type: AguiMessageType; + title: string; + body: string; + fields?: AguiField[]; + irreversible?: boolean; + context_id?: string; +} + +const DEFAULT_TIMEOUT_MS = 10 * 60 * 1000; // 决策等待默认 10 分钟 + +interface PendingDecision { + resolve: (response: AguiResponse) => void; + reject: (error: Error) => void; + timer: ReturnType; +} + +export class AguiBridge { + private pending = new Map(); + private seq = 0; + + constructor( + private transport: AguiTransport, + private opts: { timeoutMs?: number; channel?: string; chatId?: string } = {}, + ) {} + + /** 发出决策卡片并挂起等待用户响应（半自动确认节点的核心原语） */ + requestDecision(request: AguiDecisionRequest): Promise { + const message: AguiMessage = { + id: this.nextId(), + type: request.type, + from: "chief", + title: request.title, + body: request.body, + fields: request.fields, + irreversible: request.irreversible ?? false, + context_id: request.context_id, + }; + + const outbound = new OutboundMessage({ + channel: this.opts.channel ?? "novel", + chatId: this.opts.chatId ?? "editorial", + content: `[AG-UI] ${request.type}: ${request.title}`, + metadata: { [OUTBOUND_META_AGENT_UI]: message }, + }); + + return new Promise((resolve, reject) => { + const timeoutMs = this.opts.timeoutMs ?? DEFAULT_TIMEOUT_MS; + const timer = setTimeout(() => { + this.pending.delete(message.id); + reject(new Error(`AG-UI 决策超时（${message.id}：${request.title}）`)); + }, timeoutMs); + this.pending.set(message.id, { resolve, reject, timer }); + + try { + void this.transport.publish(outbound); + } catch (error) { + this.cancel(message.id); + reject(error as Error); + } + }); + } + + /** confirm 快捷方法：请用户批准/驳回 */ + confirm(title: string, body: string, contextId?: string, irreversible = false): Promise { + return this.requestDecision({ type: "confirm", title, body, context_id: contextId, irreversible }); + } + + /** 确认采纳（带采纳理由） */ + async accept(title: string, body: string, contextId?: string): Promise { + const response = await this.confirm(title, body, contextId); + return response.decision === true; + } + + /** + * 收到用户响应时由 Agent loop 调用（挂载于 InboundMessage 处理链） + * 响应消息携带 metadata.aguiResponse = { message_id, decision, reason } + */ + resolveResponse(payload: AguiResponse): boolean { + const pending = this.pending.get(payload.message_id); + if (!pending) return false; + clearTimeout(pending.timer); + this.pending.delete(payload.message_id); + pending.resolve(payload); + return true; + } + + /** 取消挂起的决策（超时/主编撤回） */ + cancel(messageId: string): boolean { + const pending = this.pending.get(messageId); + if (!pending) return false; + clearTimeout(pending.timer); + this.pending.delete(messageId); + pending.reject(new Error(`AG-UI 决策已取消（${messageId}）`)); + return true; + } + + /** 挂起中的决策数量（主编控制台进度监控用） */ + pendingCount(): number { + return this.pending.size; + } + + private nextId(): string { + this.seq += 1; + return `agui_${Date.now().toString(36)}_${this.seq.toString(36)}`; + } +} + +// 供 agent loop 识别用户 AG-UI 响应的元数据键（与 events.ts 的 runtimeControl 平行） +export const INBOUND_META_AGUI_RESPONSE = "aguiResponse"; +export { INBOUND_META_RUNTIME_CONTROL }; diff --git a/App/memmy-agent/src/novel/workflow-engine.ts b/App/memmy-agent/src/novel/workflow-engine.ts new file mode 100644 index 00000000..a392641c --- /dev/null +++ b/App/memmy-agent/src/novel/workflow-engine.ts @@ -0,0 +1,203 @@ +/** + * Pipeline 编排引擎（创作八将顺序协作） + * + * 设计依据：docs/novel-design.md §2.2 + * - 顺序协作：灵思→构世→塑像→谋篇→埋线→执笔→淬文→审校 + * - 主编在每个节点后审阅中间结果：采纳（放行）/ 驳回（打回） + * - 节点可中断/恢复/锁定/回退 + */ +import { ExpertId, ExpertResult, AguiResponse, TaskCard } from "./types.js"; +import { ExpertRegistry } from "./expert-registry.js"; + +/** Pipeline 节点状态机 */ +export type PipelineNodeStatus = + | "pending" // 未开始 + | "running" // 执行中（专家工作中） + | "waiting" // 等待用户 AG-UI 决策（半自动确认节点） + | "blocked" // 被中断/上游未就绪 + | "done" // 已完成且用户采纳 + | "failed" // 执行失败 + | "frozen"; // 已锁定（即使上游变更也不重跑） + +export interface PipelineNode { + expertId: ExpertId; + /** Pipeline 序号 1-8 */ + order: number; + status: PipelineNodeStatus; + taskCard: TaskCard | null; + result: ExpertResult | null; + /** 用户决策（采纳 true / 驳回 false + reason） */ + decision: AguiResponse | null; + startedAt: number | null; + finishedAt: number | null; + /** 打回次数（防死循环：超限转主编介入） */ + rejectCount: number; +} + +export interface WorkflowCallbacks { + onNodeStart?: (node: PipelineNode, bookId: string) => void; + /** 节点产出待用户决策（AG-UI 确认卡片应在此刻发出） */ + onNodeWaiting?: (node: PipelineNode, bookId: string) => void; + onNodeAccepted?: (node: PipelineNode, bookId: string) => void; + onNodeRejected?: (node: PipelineNode, bookId: string, reason: string) => void; + onPipelineComplete?: (bookId: string) => void; + onPipelineFailed?: (bookId: string, error: string) => void; +} + +const MAX_REJECT_PER_NODE = 3; + +export class WorkflowEngine { + private registry = new ExpertRegistry(); + private bookId: string; + private nodes: PipelineNode[] = []; + private cursor = 0; // 当前节点索引 + private callbacks: WorkflowCallbacks = {}; + + constructor(bookId: string, callbacks: WorkflowCallbacks = {}) { + this.bookId = bookId; + this.callbacks = callbacks; + this.buildPipeline(); + } + + /** 按创作八将 Pipeline 顺序建节点 */ + private buildPipeline(): void { + this.nodes = this.registry.creationTeam().map((profile, i) => ({ + expertId: profile.id, + order: i + 1, + status: "pending", + taskCard: null, + result: null, + decision: null, + startedAt: null, + finishedAt: null, + rejectCount: 0, + })); + } + + getNodes(): PipelineNode[] { + return this.nodes; + } + + current(): PipelineNode | null { + return this.nodes[this.cursor] ?? null; + } + + isComplete(): boolean { + return this.cursor >= this.nodes.length; + } + + /** 启动流水线：从第一个 pending 节点开始 */ + start(): void { + this.runCurrent(); + } + + /** 派发当前节点：赋任务卡 → running → 通知执行者 */ + private runCurrent(): void { + const node = this.current(); + if (!node) { + this.callbacks.onPipelineComplete?.(this.bookId); + return; + } + node.status = "running"; + node.startedAt = Date.now(); + this.callbacks.onNodeStart?.(node, this.bookId); + } + + /** 专家回传结果 → 节点进入 waiting（等用户 AG-UI 确认） */ + submitResult(expertId: ExpertId, result: ExpertResult, taskCard: TaskCard | null = null): void { + const node = this.findNode(expertId); + if (node.status !== "running") throw new Error(`node ${expertId} 不在 running 状态`); + node.result = result; + node.taskCard = taskCard; + node.status = "waiting"; + this.callbacks.onNodeWaiting?.(node, this.bookId); + } + + /** 用户采纳 → 放行下一节点 */ + accept(expertId: ExpertId, decision: AguiResponse): void { + const node = this.findNode(expertId); + if (node.status !== "waiting") throw new Error(`node ${expertId} 不在 waiting 状态`); + node.decision = decision; + node.status = "done"; + node.finishedAt = Date.now(); + this.callbacks.onNodeAccepted?.(node, this.bookId); + this.cursor += 1; + this.runCurrent(); + } + + /** 用户驳回 → 打回指定节点（默认上一节点；可选打回灵思整体重想） */ + reject(expertId: ExpertId, decision: AguiResponse, rollbackTo?: ExpertId): void { + const node = this.findNode(expertId); + if (node.status !== "waiting") throw new Error(`node ${expertId} 不在 waiting 状态`); + node.decision = decision; + node.rejectCount += 1; + this.callbacks.onNodeRejected?.(node, this.bookId, decision.reason ?? ""); + + if (node.rejectCount > MAX_REJECT_PER_NODE) { + // 防死循环：超限标记 failed，转主编人工介入 + node.status = "failed"; + this.callbacks.onPipelineFailed?.(this.bookId, `${expertId} 连续驳回 ${MAX_REJECT_PER_NODE} 次，需主编介入`); + return; + } + + // 定位回退目标：默认打回上一节点；可指定任意节点（如灵思=整体重想） + const targetIndex = rollbackTo + ? this.nodes.findIndex((n) => n.expertId === rollbackTo) + : this.nodes.findIndex((n) => n.expertId === expertId) - 1; + if (targetIndex < 0) { + node.status = "failed"; + this.callbacks.onPipelineFailed?.(this.bookId, `无法回退：无上一节点（${expertId}）`); + return; + } + // 从回退目标到当前节点全部重置为 pending，回退目标节点清空结果 + for (let i = targetIndex; i < this.nodes.length; i += 1) { + const n = this.nodes[i]; + n.status = "pending"; + n.result = null; + n.decision = null; + n.finishedAt = null; + if (i === targetIndex) n.rejectCount = node.rejectCount; + } + this.cursor = targetIndex; + this.runCurrent(); + } + + /** 中断（暂停当前运行节点 → blocked） */ + pause(): void { + const node = this.current(); + if (node?.status === "running") node.status = "blocked"; + } + + /** 恢复（从当前节点继续） */ + resume(): void { + const node = this.current(); + if (node?.status === "blocked") this.runCurrent(); + } + + /** 锁定节点（frozen：即使上游变更也不重跑） */ + freeze(expertId: ExpertId): void { + const node = this.findNode(expertId); + if (node.status !== "done") throw new Error(`仅 done 节点可锁定：${expertId}`); + node.status = "frozen"; + } + + /** 解锁节点 */ + unfreeze(expertId: ExpertId): void { + const node = this.findNode(expertId); + if (node.status !== "frozen") throw new Error(`仅 frozen 节点可解锁：${expertId}`); + node.status = "done"; + } + + /** 标记失败（专家执行异常） */ + fail(expertId: ExpertId, error: string): void { + const node = this.findNode(expertId); + node.status = "failed"; + this.callbacks.onPipelineFailed?.(this.bookId, `${expertId}: ${error}`); + } + + private findNode(expertId: ExpertId): PipelineNode { + const node = this.nodes.find((n) => n.expertId === expertId); + if (!node) throw new Error(`unknown pipeline node: ${expertId}`); + return node; + } +} From 9122a08595d6234217a2364da3afc38e166d0848 Mon Sep 17 00:00:00 2001 From: halleck Date: Thu, 13 Aug 2026 06:03:11 +0800 Subject: [PATCH 5/5] =?UTF-8?q?feat(novel):=20A=20=E5=9D=97=E7=BC=96?= =?UTF-8?q?=E5=A7=94=E4=BC=9A=E8=BF=90=E8=A1=8C=E6=97=B6=E6=94=B6=E5=B0=BE?= =?UTF-8?q?=E2=80=94=E2=80=94=E6=8A=80=E8=83=BD=E9=9B=86=20+=20=E4=B8=BB?= =?UTF-8?q?=E7=BC=96=E6=8E=A7=E5=88=B6=E5=8F=B0=20+=20=E5=86=99=E4=BD=9C?= =?UTF-8?q?=E5=91=BD=E4=BB=A4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - skills/novel-orchestration: 召见决策矩阵 + 任务卡 schema + 5 确认节点硬规则 - skills/novel-pitch: 灵思方案卡片（三入口 → 3 差异化方案，六块内容） - skills/novel-flow: 开书/日更/卷末复盘三流程 SOP + 三种调用模式 - chief-console.ts: 任务下发/专家执行器/进度快照/采纳驳回/中断恢复锁定 - commands.ts: /新书 /编委会 /流水线 /日更 /审稿 /会诊（执行器注入点） - index.ts: novel 模块出口 --- App/memmy-agent/src/novel/chief-console.ts | 171 +++++++++++++++++ App/memmy-agent/src/novel/commands.ts | 181 ++++++++++++++++++ App/memmy-agent/src/novel/expert-registry.ts | 2 +- App/memmy-agent/src/novel/index.ts | 11 ++ .../src/skills/novel-flow/SKILL.md | 61 ++++++ .../src/skills/novel-orchestration/SKILL.md | 70 +++++++ .../src/skills/novel-pitch/SKILL.md | 64 +++++++ 7 files changed, 559 insertions(+), 1 deletion(-) create mode 100644 App/memmy-agent/src/novel/chief-console.ts create mode 100644 App/memmy-agent/src/novel/commands.ts create mode 100644 App/memmy-agent/src/novel/index.ts create mode 100644 App/memmy-agent/src/skills/novel-flow/SKILL.md create mode 100644 App/memmy-agent/src/skills/novel-orchestration/SKILL.md create mode 100644 App/memmy-agent/src/skills/novel-pitch/SKILL.md diff --git a/App/memmy-agent/src/novel/chief-console.ts b/App/memmy-agent/src/novel/chief-console.ts new file mode 100644 index 00000000..955ac913 --- /dev/null +++ b/App/memmy-agent/src/novel/chief-console.ts @@ -0,0 +1,171 @@ +/** + * 主编控制台（Chief Console） + * + * 设计依据：docs/novel-design.md §2.3 + * - 任务下发（带创作指令单）→ 专家执行器 → 结果回传 → 用户 AG-UI 决策 → 放行/驳回 + * - 进度监控：节点状态、pending 决策数、专家调用记录 + * - 中断/恢复/锁定/解锁/回退 操作面 + */ +import { WorkflowEngine, PipelineNode, PipelineNodeStatus } from "./workflow-engine.js"; +import { AguiBridge } from "./agui-bridge.js"; +import { AguiResponse, ExpertId, ExpertResult, TaskCard } from "./types.js"; +import { ExpertRegistry } from "./expert-registry.js"; + +/** 专家执行器：把任务卡交给专家（真实环境 = 经 SubagentManager 派发的 subagent） */ +export interface ExpertRunner { + run(bookId: string, node: PipelineNode, taskCard: TaskCard): Promise; +} + +export interface NodeView { + expertId: ExpertId; + name: string; + order: number; + status: PipelineNodeStatus; + hasResult: boolean; + rejectCount: number; + decision: AguiResponse | null; +} + +export interface ConsoleSnapshot { + bookId: string; + nodes: NodeView[]; + pendingDecisions: number; + complete: boolean; + failed: boolean; + currentExpertId: ExpertId | null; +} + +export class ChiefConsole { + private registry = new ExpertRegistry(); + private workflow: WorkflowEngine; + private bridge: AguiBridge; + private runner: ExpertRunner; + private bookId: string; + private callLog: { expertId: ExpertId; ts: number; taskId: string }[] = []; + + constructor(init: { + bookId: string; + workflow: WorkflowEngine; + bridge: AguiBridge; + runner: ExpertRunner; + }) { + this.bookId = init.bookId; + this.workflow = init.workflow; + this.bridge = init.bridge; + this.runner = init.runner; + } + + /** 启动流水线：主编自动把当前节点派单给专家执行 */ + start(): void { + this.workflow.start(); + void this.pump(); + } + + /** 主编派单 + 执行循环：running 节点 → 构造 TaskCard → runner 执行 → 结果入 waiting */ + private async pump(): Promise { + const node = this.workflow.current(); + if (!node || this.workflow.isComplete()) return; + if (node.status !== "running") return; + + const taskCard: TaskCard = this.buildTaskCard(node); + this.callLog.push({ expertId: node.expertId, ts: Date.now(), taskId: taskCard.task_id }); + try { + const result = await this.runner.run(this.bookId, node, taskCard); + this.workflow.submitResult(node.expertId, result, taskCard); + // submitResult 触发 onNodeWaiting —— 外部在此时发 AG-UI 确认卡片 + } catch (error) { + this.workflow.fail(node.expertId, (error as Error).message); + } + } + + /** 按专家档案与上游产出构造任务卡（references 注入已确认的上游结果） */ + private buildTaskCard(node: PipelineNode): TaskCard { + const profile = this.registry.get(node.expertId); + const upstream = this.workflow + .getNodes() + .filter((n) => n.order < node.order && n.result) + .map((n) => `上游 ${n.expertId}: ${n.result?.summary ?? ""}`); + return { + task_id: `tsk_${Date.now().toString(36)}_${node.order}`, + expert: node.expertId, + objective: `${profile.name}：${profile.outputs.join("、")}`, + constraints: [ + "不得改变已锁定设定（基线快照）", + "按产出物 schema 回传 {title, summary, detail, refs, extra}", + ...profile.asKnowledgeCenter ? [] : [], + ], + references: [ + ...upstream, + `角色卡:${profile.roleCard}`, + `技能:${profile.category === "creation" ? "novel-orchestration" : "novel-flow"}`, + ], + acceptance: [ + "满足角色卡质量标准", + ...(node.expertId === "zhi-bi" ? ["控字达标", "章末钩子生效"] : []), + ...(node.expertId === "shen-xiao" ? ["双基准查重完成", "审校清单可定位"] : []), + ], + deadline: null, + parent_decision: this.workflow.getNodes()[node.order - 2]?.decision?.reason ?? null, + }; + } + + /** 用户采纳 → 放行下一节点并继续派单 */ + async accept(expertId: ExpertId, decision: AguiResponse): Promise { + this.workflow.accept(expertId, decision); + await this.pump(); + } + + /** 用户驳回 → 打回（默认上一节点；可指定回退目标） */ + async reject(expertId: ExpertId, decision: AguiResponse, rollbackTo?: ExpertId): Promise { + this.workflow.reject(expertId, decision, rollbackTo); + await this.pump(); + } + + /** 主编控制台操作面：中断/恢复/锁定/解锁 */ + pause(): void { + this.workflow.pause(); + } + + resume(): void { + this.workflow.resume(); + void this.pump(); + } + + freeze(expertId: ExpertId): void { + this.workflow.freeze(expertId); + } + + unfreeze(expertId: ExpertId): void { + this.workflow.unfreeze(expertId); + } + + /** 进度监控快照（主编控制台/前端编委会视图的数据源） */ + snapshot(): ConsoleSnapshot { + const nodes = this.workflow.getNodes(); + return { + bookId: this.bookId, + nodes: nodes.map((n) => ({ + expertId: n.expertId, + name: this.registry.get(n.expertId).name, + order: n.order, + status: n.status, + hasResult: n.result !== null, + rejectCount: n.rejectCount, + decision: n.decision, + })), + pendingDecisions: this.bridge.pendingCount(), + complete: this.workflow.isComplete(), + failed: nodes.some((n) => n.status === "failed"), + currentExpertId: this.workflow.current()?.expertId ?? null, + }; + } + + callHistory(): { expertId: ExpertId; ts: number; taskId: string }[] { + return [...this.callLog]; + } + + /** 挂起中的 AG-UI 决策（供前端渲染卡片） */ + pendingDecisions(): number { + return this.bridge.pendingCount(); + } +} diff --git a/App/memmy-agent/src/novel/commands.ts b/App/memmy-agent/src/novel/commands.ts new file mode 100644 index 00000000..d8b45176 --- /dev/null +++ b/App/memmy-agent/src/novel/commands.ts @@ -0,0 +1,181 @@ +/** + * 写作命令注册（/新书 /编委会 /日更 /审稿 /会诊 /流水线） + * + * 设计依据：docs/novel-design.md §8（写作命令）+ §2.3 主编控制台 + * - 命令是用户入口；真实专家执行由注入的 ExpertRunner 承担（C 块接线 SubagentManager） + * - 活跃书会话由模块级 map 管理（内存版，B 块 novel-project 持久化后替换） + */ +import { CommandRouter, CommandContext } from "../command/router.js"; +import { OutboundMessage } from "../core/runtime-messages/events.js"; +import { WorkflowEngine } from "./workflow-engine.js"; +import { AguiBridge } from "./agui-bridge.js"; +import { ChiefConsole, ExpertRunner } from "./chief-console.js"; +import { ExpertRegistry } from "./expert-registry.js"; +import { ExpertId } from "./types.js"; + +/** 默认专家执行器：未接线时明确报错，不假装执行（诚实失败原则） */ +const UNWIRED_RUNNER: ExpertRunner = { + run: async (bookId, node) => { + throw new Error( + `专家执行器未接线（${node.expertId} @ ${bookId}）：C 块接线 SubagentManager 后注入。` + + `当前可通过加载 novel-orchestration 技能由主 Agent 召见专家完成作业。`, + ); + }, +}; + +export interface NovelCommandDeps { + runner?: ExpertRunner; + bridge?: AguiBridge; +} + +/** 活跃书会话（sessionKey → 主编控制台） */ +const activeBooks = new Map(); +const bookTitles = new Map(); + +function reply(ctx: CommandContext, content: string): OutboundMessage { + return new OutboundMessage({ channel: ctx.msg.channel, chatId: ctx.msg.chatId, content }); +} + +/** 主编控制台状态渲染（编委会视图文本版） */ +function renderConsole(console_: ChiefConsole): string { + const snap = console_.snapshot(); + const lines = [ + `## 编委会 · 流水线状态（书 ${snap.bookId}）`, + "", + "| 序号 | 专家 | 状态 | 产出 | 驳回 |", + "|---|---|---|---|---|", + ]; + for (const node of snap.nodes) { + lines.push( + `| ${node.order} | ${node.name} | ${node.status} | ${node.hasResult ? "✅" : "—"} | ${node.rejectCount} |`, + ); + } + lines.push("", `- 挂起决策数：${snap.pendingDecisions}`); + lines.push(snap.complete ? "- 流水线：**已完成**" : snap.failed ? "- 流水线：**存在失败节点**" : `- 当前节点：${snap.currentExpertId ?? "无"}`); + return lines.join("\n"); +} + +export function registerNovelCommands(router: CommandRouter, deps: NovelCommandDeps = {}): void { + const registry = new ExpertRegistry(); + + function getOrCreateConsole(ctx: CommandContext, title?: string): ChiefConsole { + const key = ctx.key ?? `${ctx.msg.channel}:${ctx.msg.chatId}`; + let console_ = activeBooks.get(key); + if (!console_) { + const bookId = `book_${Date.now().toString(36)}`; + const bridge = deps.bridge ?? new AguiBridge({ publish: () => undefined }); + const workflow = new WorkflowEngine(bookId); + console_ = new ChiefConsole({ + bookId, + workflow, + bridge, + runner: deps.runner ?? UNWIRED_RUNNER, + }); + activeBooks.set(key, console_); + bookTitles.set(bookId, title ?? "未命名新书"); + } + return console_; + } + + /** /新书 <创意> —— 立项入口：启动流水线（灵思方案卡片） */ + router.prefix("/新书 ", async (ctx) => { + const title = ctx.args.trim(); + if (!title) return reply(ctx, "用法：`/新书 <一句话创意>`，例如 `/新书 现代医生穿越到修仙界靠手术刀逆袭`"); + const console_ = getOrCreateConsole(ctx, title); + console_.start(); + return reply( + ctx, + [ + `📖 新书立项已启动（创意：${title}）`, + "", + "灵思正在产出《方案卡片×3》……", + "", + "> 流水线节点：灵思 → 构世 → 塑像 → 谋篇 → 埋线 → 执笔 → 淬文 → 审校", + "> 每个方向类节点会通过 AG-UI 卡片请你确认（半自动）。", + ].join("\n"), + ); + }); + + /** /编委会 —— 展示 13 位专家与当前流水线 */ + router.exact("/编委会", (ctx) => { + const lines = ["## 编委会阵容", ""]; + lines.push("**主编中枢**：负责任务下发/进度监控/采纳驳回/编排"); + lines.push("", "**创作八将**："); + for (const p of registry.creationTeam()) lines.push(`- ${p.order}. ${p.name} —— ${p.duties[0]}`); + lines.push("", "**支撑四翼**："); + for (const p of registry.supportTeam()) lines.push(`- ${p.name} —— ${p.duties[0]}`); + const console_ = activeBooks.get(ctx.key ?? ""); + if (console_) { + lines.push("", "---", "", renderConsole(console_)); + } else { + lines.push("", "> 当前会话还没有在写的新书，用 `/新书 <创意>` 开一本。"); + } + return reply(ctx, lines.join("\n")); + }); + + /** /流水线 —— 查看当前流水线状态 */ + router.exact("/流水线", (ctx) => { + const console_ = activeBooks.get(ctx.key ?? ""); + return reply(ctx, console_ ? renderConsole(console_) : "当前会话没有活跃新书，用 `/新书 <创意>` 启动。"); + }); + + /** /日更 [章号] —— 日更流程入口 */ + router.prefix("/日更 ", async (ctx) => { + const console_ = activeBooks.get(ctx.key ?? ""); + if (!console_) return reply(ctx, "还没有新书项目，先 `/新书 <创意>` 立项。"); + const chapterNo = ctx.args.trim() || "下一章"; + return reply( + ctx, + [ + `✍️ 日更请求：第 ${chapterNo} 章`, + "", + "主编将按流程执行：谋篇拆章纲 → 埋线伏笔插针 → 执笔写作（控字+钩子）→ 事中拦截 → 淬文洗稿 → 审校查重 → 回写档案 → 终审交付。", + "> 章纲产出后会先请你确认（AG-UI confirm），确认后自动跑完全程。", + ].join("\n"), + ); + }); + + /** /审稿 [章号] —— 审校入口（全专家会诊/单审校） */ + router.prefix("/审稿 ", (ctx) => { + const console_ = activeBooks.get(ctx.key ?? ""); + if (!console_) return reply(ctx, "还没有新书项目，先 `/新书 <创意>` 立项。"); + const target = ctx.args.trim() || "当前章节"; + return reply( + ctx, + [ + `🔍 审稿请求：${target}`, + "", + "审校将对照双基准全量查重（世界库预设规则 + 本书作品档案），产出可定位的《审校报告》清单。", + "> 输入 `/会诊` 可发起全专家会诊（八将+四翼全员意见）。", + ].join("\n"), + ); + }); + + /** /会诊 —— 全专家会诊 */ + router.exact("/会诊", (ctx) => { + const console_ = activeBooks.get(ctx.key ?? ""); + if (!console_) return reply(ctx, "还没有新书项目，先 `/新书 <创意>` 立项。"); + return reply( + ctx, + [ + "🩺 全专家会诊已请求", + "", + "编委会全员将对当前章节输出综合意见：", + "- 创作八将：灵思（创意角度）/构世（设定角度）/塑像（人物角度）/谋篇（结构角度）/埋线（伏笔角度）/执笔（可写性）/淬文（语言角度）/审校（一致性角度）", + "- 支撑四翼：布景（场景）/监工（数据）/装帧（交付）/试读（读者）", + "", + "会诊结论将由主编汇总后交你 AG-UI 确认处置。", + ].join("\n"), + ); + }); + + /** /流水线 状态命令已注册在上方 exact；此处补充带参数形式 */ + router.prefix("/流水线 ", (ctx) => { + const console_ = activeBooks.get(ctx.key ?? ""); + return reply(ctx, console_ ? renderConsole(console_) : "当前会话没有活跃新书。"); + }); +} + +export { activeBooks, bookTitles, UNWIRED_RUNNER }; +export type { NovelCommandDeps }; +export type { ExpertId }; diff --git a/App/memmy-agent/src/novel/expert-registry.ts b/App/memmy-agent/src/novel/expert-registry.ts index 10f50e33..51c30564 100644 --- a/App/memmy-agent/src/novel/expert-registry.ts +++ b/App/memmy-agent/src/novel/expert-registry.ts @@ -65,7 +65,7 @@ export const EXPERT_PROFILES: ExpertProfile[] = [ roleCard: `${ROLE_CARD_DIR}/su-xiang.md`, duties: [ "人物小传、性格言行一致性、成长弧光、关系网", - "防"标签式纸片人"：行为心理逻辑校验", + "防「标签式纸片人」：行为心理逻辑校验", ], outputs: ["《人物档案集》→ 写入本书作品档案"], trigger: "立项/新人物", diff --git a/App/memmy-agent/src/novel/index.ts b/App/memmy-agent/src/novel/index.ts new file mode 100644 index 00000000..57cc7b7b --- /dev/null +++ b/App/memmy-agent/src/novel/index.ts @@ -0,0 +1,11 @@ +/** + * novel 模块出口（编委会制小说写作系统） + * + * 建设期一（A 块 编委会运行时）：类型 / 专家注册表 / 角色卡 / Pipeline 编排 / AG-UI 桥接 / 主编控制台 / 写作命令 + */ +export * from "./types.js"; +export * from "./expert-registry.js"; +export * from "./workflow-engine.js"; +export * from "./agui-bridge.js"; +export * from "./chief-console.js"; +export * from "./commands.js"; diff --git a/App/memmy-agent/src/skills/novel-flow/SKILL.md b/App/memmy-agent/src/skills/novel-flow/SKILL.md new file mode 100644 index 00000000..4bc22a94 --- /dev/null +++ b/App/memmy-agent/src/skills/novel-flow/SKILL.md @@ -0,0 +1,61 @@ +--- +name: novel-flow +description: 三套创作流程 SOP——开书流程（立项到黄金三章）、日更流程（每日章节生产）、卷末复盘流程。配套三种调用模式：手动召见/流水线/全专家会诊。 +metadata: + memmy: + always: false +--- + +# 创作流程 SOP（novel-flow） + +三套流水线 + 三种调用模式。主编按此编排，所有确认节点走 AG-UI。 + +## ① 开书流程（一次性：创意 → 黄金三章） + +``` +用户创意 + → [灵思] 方案卡片×3 → 用户 multi-select 选定/混选 + → 生成【基线快照】（前置设定锁定，改 = 新版本线） + → [构世] 世界观搭建 → [塑像] 人物档案（两位可并行）→ 设定合订 → 用户 confirm + → [谋篇] 全书纲+卷纲 → [埋线] 伏笔总账+19 线矩阵 → 用户 confirm + → [执笔] 黄金三章成稿 → [淬文] 润色去 AI 味 → [审校] 双基准查重 + → [试读] 读者视角检验 → 用户 confirm（未过则打回对应节点） + → 立项完成，进入日更 +``` + +## ② 日更流程（循环：章纲 → 成稿 → 交付） + +``` +用户确认今日章纲（AG-UI confirm） + → [谋篇] 拆当日章纲（3-4 子场景 + 控字预算）→ [埋线] 伏笔插针 + → [执笔] 正文写作（控字 + 章末钩子） + → 事中拦截：一致性引擎 A/B/C/D/E 路由（写错即纠，不等到审校） + → [淬文] 实时洗稿（黑名单/感官化/破局流）→ 每章≥2 具身细节 + → [审校] 双基准全量查重（对照世界库预设 + 本书档案） + → 新设定/新人物/新伏笔回写本书作品档案 + → 主编终审交付 → Plot Git commit 快照 +``` + +## ③ 卷末复盘流程 + +``` +[监工] 卷末数据化复盘（节奏/爽点密度/卡文段/伏笔逾期） + → [试读] 读者视角反馈 + → 主编组织复盘会（各专家输出改进项） + → 更新下一卷大纲与节奏矩阵参数 → 用户 confirm 放行 + → 复盘要点沉淀进灵感库 +``` + +## 三种调用模式 + +| 模式 | 触发 | 行为 | +|---|---|---| +| 手动召见 | 用户点名 | 随时召见某位专家单点作业（如"让塑像看看这个配角"） | +| 流水线 | /日更 | 主编自动跑完日更循环（章纲确认后全自动） | +| 全专家会诊 | /会诊 | 全员审阅已有章节，输出综合意见 | + +## 半自动硬规则 + +- 方向类决策（立项/设定/大纲/开篇/卷末）必须 AG-UI 确认，执行类（正文/润色/审校）自动跑 +- 基线锁定后的前置设定不可改；节奏矩阵属运营参数可微调（留版本记录） +- 驳回必带原因，默认打回上一节点，3 次超限转人工 diff --git a/App/memmy-agent/src/skills/novel-orchestration/SKILL.md b/App/memmy-agent/src/skills/novel-orchestration/SKILL.md new file mode 100644 index 00000000..58d4065d --- /dev/null +++ b/App/memmy-agent/src/skills/novel-orchestration/SKILL.md @@ -0,0 +1,70 @@ +--- +name: novel-orchestration +description: 主编编排指令——何时召见哪位专家、任务卡片 schema、半自动确认节点硬规则、产出聚合。触发：立项、日更、审校、任何编委会协作场景。 +metadata: + memmy: + always: false +--- + +# 主编编排指令（novel-orchestration） + +你是编委会主编。以下规则决定**何时召见谁、派什么活、怎么收**。所有"方向类"决策必须经 AG-UI 确认卡片交用户拍板（半自动硬规则）。 + +## 召见决策矩阵 + +| 场景 | 召见 | 交付 | +|---|---|---| +| 立项（一句话/套用/对撞） | 灵思 | 《方案卡片×3》→ 用户 multi-select | +| 世界观搭建 | 构世 | 《作品设定集》→ 本书作品档案 | +| 人物设计 | 塑像 | 《人物档案集》→ 本书作品档案 | +| 卷/章规划 | 谋篇 | 《全书纲》《卷纲》《章纲》 | +| 伏笔与线索 | 埋线 | 《伏笔总账》《线索矩阵》 | +| 正文写作 | 执笔 | 《正文成稿》（控字 + 章末钩子） | +| 润色去 AI 味 | 淬文 | 《润色稿》（三道防护） | +| 查重终验 | 审校 | 《审校报告》（双基准清单） | +| 场景/战斗描写 | 布景 | 《场景卡》→ 素材库 | +| 进度/节奏度量 | 监工 | 《度量报告》《情绪曲线》 | +| 交付导出 | 装帧 | 《成品书》《导出包》 | +| 读者视角检验 | 试读 | 《试读报告》（黄金三章/弃书点） | + +## 任务卡片 schema（派单必带） + +```json +{ + "task_id": "tsk_8f3a", + "expert": "执笔", + "objective": "写第 12 章：主角突破筑基期", + "constraints": ["遵循章纲 tsk_8f2c", "字数 2500-3000", "不得改变已锁定设定"], + "references": ["世界库:战力体系#筑基", "素材库:宗门大殿场景卡"], + "acceptance": ["章末钩子指向伏笔 vb_004", "无设定冲突", "无 AI 味"], + "deadline": null, + "parent_decision": "dec_9c11（用户大纲确认）" +} +``` + +- `constraints` 与 `references` 决定专家"能做什么、不许碰什么" +- 专家回传必须用统一产出 schema：`{title, summary, detail, refs, extra}` + +## 五个确认节点（AG-UI 强制，不可跳过） + +| # | 节点 | AG-UI | 放行条件 | +|---|---|---|---| +| 1 | 立项 | multi-select | 用户选定/混选方案 | +| 2 | 设定（构世+塑像） | confirm | 用户采纳合订版 | +| 3 | 大纲（谋篇+埋线） | confirm | 用户采纳全书纲 | +| 4 | 开篇（前三章） | confirm | 用户采纳 + 试读通过 | +| 5 | 卷末复盘 | confirm | 用户放行下一卷 | + +**驳回规则**：记录驳回原因 → 默认打回上一节点；连续 3 次驳回 → 上报用户人工介入（防循环）。 + +## 产出聚合规则 + +- 专家回传后，先自查 `acceptance` 是否满足，不满足直接打回（不浪费用户决策） +- 向用户呈报时用统一格式：产出物标题 + 一句话摘要 + 关键 refs + 决策按钮 +- 审校报告按 issue 列表逐条呈报（位置/问题/依据/建议修正），支持一键修改 + +## 边界 + +- 主编不亲自写正文（执笔的活） +- 基线锁定后的设定改动一律拒绝，改走 Plot Git 新版本线 +- 用户没有通过 AG-UI 决策前，不得擅自推进下一节点 diff --git a/App/memmy-agent/src/skills/novel-pitch/SKILL.md b/App/memmy-agent/src/skills/novel-pitch/SKILL.md new file mode 100644 index 00000000..969d2dba --- /dev/null +++ b/App/memmy-agent/src/skills/novel-pitch/SKILL.md @@ -0,0 +1,64 @@ +--- +name: novel-pitch +description: 灵思方案卡片技能——从一句话创意/灵感卡套用/灵感卡对撞三种入口，产出 3 个差异化创作方案卡片供用户选择。 +metadata: + memmy: + always: false +--- + +# 灵思方案卡片（novel-pitch） + +把"想写什么"变成"能立项的 3 张方案卡片"。你是创作八将第一棒，只做创意与定位，不做细节。 + +## 三种入口 + +| 入口 | 输入 | 处理 | +|---|---|---| +| 一句话 | 用户一句话创意 | 扩展成 3 个方向（题材差异化） | +| 套用 | 1 张灵感卡 | 基于该卡出 3 个变体（同一题材不同爽点结构） | +| 对撞 | 2-3 张灵感卡 | 杂交融合（题材×设定×金手指 交叉组合） | + +## 每张卡片必须包含六块内容 + +1. **作品基础信息**：作品名 / 频道（男频/女频）/ 核心题材 / 目标篇幅 / 商业卖点（一句话可传播） +2. **故事梗概与核心动力**：Logline（一句话）/ 300 字全书梗概 / 核心驱动力（主角为什么必须行动） +3. **金手指与规则机制**：特殊能力 / 运行底层逻辑 / **使用代价与上限**（防战力崩溃的硬约束） +4. **核心角色卡片**：主角 / 核心反派 / 女主或搭档 / 核心 NPC 群像（每人一句话定位 + 内在矛盾） +5. **世界观与设定基石**：力量/境界体系 / 核心社会矛盾 / 主要地理舞台 +6. **连载节奏**：节奏模板（商业网文 2500-3000 字/9 章循环 等）+ 卷高潮节点 + +## 3 张卡片必须差异化 + +- 不同题材方向（如：仙侠重生 / 都市异能 / 历史架空） +- 或同题材不同爽点结构（如：扮猪吃虎 / 升级打脸 / 经营养成） +- 或不同金手指路线（如：系统面板 / 天赋异禀 / 传承记忆） +- 禁止三张卡片只是细节微调的"换皮" + +## 爽点框架要求 + +- 每张卡片附《爽点框架》：全书爽点密度规划（如每 3 章小爽点、10 章大高潮、卷末大事件） +- 爽点类型分布：扮猪吃虎 / 打脸反转 / 升级突破 / 情感满足 / 悬念揭秘，至少 3 类 + +## 产出物 schema + +```json +{ + "title": "方案卡片×3", + "summary": "三卡一句话差异化对比", + "detail": "三张卡片的六块内容完整展开", + "refs": ["灵感库:卡片ID", "素材库:拆文库竞品"], + "extra": { "cards": ["card_01", "card_02", "card_03"] } +} +``` + +## 质量标准 + +- 金手指必有代价与上限（防战力崩溃，这是立项硬门槛） +- 商业卖点一句话能说清（读者为什么要点开） +- Logline 一句话能说清（主角+目标+阻碍+代价） +- 三卡差异明显可对比 + +## 边界 + +- 不做世界观细节（构世的活）、不做人物小传（塑像的活）、不写正文 +- 不选择题材定生死——3 个方向交给用户 AG-UI 选择（半自动）