Inspiration
What it does
Inspiration
我是一个网文重度读者，也是一个 AI 工程师。当我第一次尝试用 LLM 写长篇小说时，发现了一个根本性矛盾：AI 擅长生成流畅的文字，但完全不擅长管理一个长篇故事。
写到第 5 章角色开始"失忆"，第 10 章伏笔被遗忘，第 15 章人物性格漂移。这不是模型能力问题——是架构问题。没有人在帮 AI "记住"故事。
然后我读到一篇网文写作方法论，提到了"三账本"：欲望账本（读者想看什么）、代价账本（主角欠了什么）、信息差账本（谁知道什么）。这是长篇网文的商业引擎，但没有任何 AI 写作工具在用它。
我想：如果把人类的写作方法论"编译"成 AI 能理解的结构化数据，再用多 agent 协作模拟一个编辑部的工作流——一个有规划、有审核、有记忆、能自我纠正的系统，能不能解决"AI 写长篇"的核心痛点？
What it does
NovelAgent 是一个多 agent 长篇小说写作系统。它不是一个"一键生成小说"的玩具，而是一个结构化的写作工作台：
- 三账本系统：用 Markdown + YAML 管理欲望、代价、信息差三个叙事引擎，每章自动追踪"读者想看什么"、"主角欠了什么"、"谁知道什么"
- 动态认知图谱：用 Neo4j 存储故事世界的状态——不仅存"世界是什么样"，还存"角色以为世界是什么样"，支持路径检索（"林默持有什么武器的副作用"）
- 三人协作管线：lead（项目经理，只协调不写）→ plan_agent（大纲）→ writer_agent（正文）→ graph_agent（图谱更新），每个角色有明确的工具边界和写路径限制
- 终稿闸门：章节写完后生成分域 action 草案，人工审阅后按顺序落盘（ledger → character card → graph），hash 不匹配就拒绝
- 评测系统：用 git worktree 隔离运行 → 收集 trace → 确定性评分（产物检查 + 指标对比）+ LLM Judge（内容质量）→ 归档，每次改动都能用分数说话
目前系统已产出 1200 章成品小说，260+ 个 commit，完整的评测管线。
How we built it
第一周：原型验证。 一个 Python 脚本、一个 REPL、三个 agent。用文件系统当账本，Neo4j 当记忆。先跑通一个完整章节的"写入→审核→落盘"流程。核心原则：先证明它能跑，再优化它跑得好。
第二周：权限模型。 发现 lead agent 既当裁判又当运动员会作弊——它会跳步、会覆盖账本。把 lead 改成纯协调者：只能读上下文、发消息、分配任务。写操作全部由固定队友执行，每个队友有明确的文件写入路径限制。这个决策是整个项目最关键的架构转折点。
第三周：终稿闸门。 agent 写完章节后直接落盘数据会出错——账本更新了但图谱没更新。设计了两阶段提交：先生成 action 草案（人工可审阅），再按顺序落盘。引入了浏览器端审阅 UI（finalization_viewer.html），支持逐条 apply/skip/edit。
第四周：评测管线。 你无法改进你无法衡量的东西。建了完整的 eval 系统：隔离运行 → 确定性评分（产物完整性、token 消耗、工具调用次数、错误率）+ LLM Judge → 基线对比。每次改动后跑一条命令就能看到分数变化。
持续迭代： 从那以后就是不断的"跑 eval → 发现问题 → 修代码 → 再跑 eval"循环。260 个 commit，绝大多数都是这个循环的产物。
Challenges we ran into
上下文窗口是稀缺资源。 写到第 10 章时，system prompt + 图谱 + 账本 + 角色卡 + 最近 3 章文本已逼近 context window 上限。设计了三层压缩策略，但 Tier 2 把 TodoWrite 也压掉了——agent 忘记自己在做什么。修复：标记"不可压缩"区域。
让 LLM 遵守规则比理解规则难 100 倍。 设计文档写清楚了"lead 不能直接写文件"，但 LLM 会绕过限制——让 teammate 代写，或用子代理委派。最终方案：把直接写入工具从 lead 的工具列表中物理移除，只暴露终稿流程的工具。
评测系统的鸡生蛋问题。 评测需要基线，基线需要稳定系统，但系统在迭代。解法：eval_baseline_capture.py 冻结基线数据，后续改动都和基线比。LLM Judge 评分不一致（同一 run 差 10 分），把 Judge 权重降到 0.5，确定性评分占 0.5。
多 agent 的"信任"问题。 lead 看不到 graph_agent 的内部操作（没有 graph_read_cypher 权限），只能问"好了吗"。如果 graph_agent 生成了错误的 action，lead 无法验证。设计了 graph_dryrun——试执行但不提交，返回报告供 lead 审核。
Python 3.9 兼容性。 多次在类型注解语法上踩坑（X | Y 是 3.10+），后来强制所有文件用 from __future__ import annotations。
Accomplishments that we're proud of
- 1200 章成品小说，不是 demo，是真正有剧情连贯性的长篇内容
- 三账本 + 认知图谱的组合，让 AI 第一次能"管理"长篇叙事而不只是"生成"文字
- 评测系统让每次改动都有量化依据，不是"感觉好了一点"
- 终稿闸门保证了数据一致性——账本、角色卡、图谱三者版本始终同步
- 权限模型让 lead 真正成为协调者，而不是一个什么都做但什么都做不好的万能 agent
- 260 个 commit 的工程实践，从原型到可用系统，踩了足够多的坑并沉淀了可复用的模式
What we learned
- LLM 的"失忆"是架构问题，不是模型问题。 结构化注入（图谱子图 + 账本摘要 + 角色卡）比 RAG 检索更可靠
- 多 agent 协作的关键不是分工，是边界。 让每个 agent 有明确的职责和工具权限，比让一个"全能 agent"做所有事更稳定
- 你无法改进你无法衡量的东西。 评测系统是最重要的基础设施，没有它所有优化都是盲人摸象
- 让 LLM 遵守规则比理解规则难 100 倍。 约束必须在代码层面强制执行，不能靠 prompt 提示
- AI 写作工具的核心价值不是"生成"，是"管理"。 管理 1200 章、20 个角色、50 条伏笔、100 个信息差——这才是需要工程化解决的问题
What's next for novel-agent
- 多模型支持：当前绑定单一模型，计划支持不同 agent 使用不同模型（writer 用创意型，graph_agent 用逻辑型）
- 协作式审阅：终稿闸门目前是单人审阅，计划支持多人批注和投票
- 更长篇验证：当前验证到 1200 章，目标是 2000章的长篇连贯性
- 开源评测基准：把评测 case 和基线数据开放出来，让社区可以贡献新的评测场景
- Web UI：把 REPL 体验搬到浏览器，让非技术用户也能用 ## How we built it
Log in or sign up for Devpost to join the conversation.