fictionforge（GitHub）

📌 工具简介

FictionForge 是 GitHub 开源的多智能体小说写作框架，核心主张是“别人给你一个写作工具，FictionForge 给你一支演员剧组”。它把传统 AI 写作中“一个模型面对全部设定”的模式，拆解为多个角色 Agent 各自持有独立记忆、信念和世界视角，再由叙事合成器（Narrator）将各 Agent 与世界模拟器的输出合并为章节规格，最后经过质量门禁（Quality Gate）自动校验和重写后才产出正文。每个角色都有自己的“脑子”，配角在你看不见的地方也在过日子，跨章节的状态一致性由引擎层负责维持，而非依赖模型自身的记忆。项目同时发布了 CanonBench——一个长程一致性基准，用零 LLM 的确定性判定器检测“第 2 章死掉的人会不会在第 4 章端着水走过来”这类问题，把“模型能力”和“工程管线”的贡献分开衡量。它不是一个开箱即用的写作 APP，而是一套需要配置和调试的工程化框架，适合愿意投入技术成本换取长篇叙事控制力的创作者和研究者。

⚡ 主要功能

• 多智能体角色模拟：每个角色（主角和重要配角）都是一个独立 Agent，各自拥有记忆、信念和个性化世界视角。Tier1 角色（戏份重）可自行编写 Agent 实现记忆与信念修正逻辑，Tier2 配角直接使用框架内置的轻量 Agent，无需写代码
• 叙事合成与章节规格：Narrator 将各 Agent 的输出与世界模拟器、环境状态合并，生成结构化的章节规格（TickResult），再由生成管线消费并产出正文，避免单一模型在同一上下文中处理全部角色时产生的视角混乱和信息泄漏
• 质量门禁与自动重写：每一章生成后经过质量门禁校验，检查反 AI 词、比喻上限、禁止词、篇幅、人称一致性等指标，不通过则自动重写，直到满足配置标准后才输出最终正文，把“可读性基线”交给工程而非模型自觉
• CanonBench 长程一致性基准：把“长篇一致性”做成可自动判定的基准，判定器零 LLM、可审计，输入由确定性合成宇宙生成器产出，跑批带三档 harness 消融，量化“模型能力”与“工程管线”各自贡献了多少一致性提升。首期结果显示裸写最弱的模型从上下文工程中受益最大
• Bible 注入与世界观蒸馏：通过 bible/ 目录下的写作法则.md、世界观.md、人设.md、人物锚点.md 等文件，把写作技法、世界规则和人物设定注入生成模型的 system prompt，world_summary 和 world_core_principle 用于引擎的世界模拟注入
• 弧配置与时间线管理：arcs/*.md 以 YAML frontmatter 定义故事弧，vault/ 目录维护角色状态、章节状态和时间线，让多章节推进有可追溯的结构化状态，而不是依赖模型在对话历史中“记住”
• 私有内容包分离：小说内容默认放在 novels/<你的小说>/ 目录，但私有不公开的连载可通过 novel_dir 指向仓库外的独立目录，实现引擎代码公开、内容私有的两套 Git 管理，避免版权内容进入公共仓库
• 单章生成与引擎测试：python scripts/gen.py novels/<你的小说>/specs/ch1.json 即可跑通单章生成；框架单元测试和判定器自检提供离线验证能力，clone 后零 token、零网络即可重算报表和榜单，逐字节核对 prompt hash

💰 价格信息

FictionForge 本身完全开源免费，仓库代码可自由克隆、修改和自托管，不收取软件授权费、订阅费或点数费用。实际成本主要来自两个方面：一是运行框架所需的本地计算资源（Python 环境、依赖安装、可能的本地模型推理硬件）；二是生成正文时调用大模型的 API 费用，具体取决于所选模型供应商和 Token 消耗量。CanonBench 的离线复算和判定器自检不消耗任何 Token，clone 后即可零成本验证基准结果。对于有技术能力自行部署和调参的用户，这是一套边际成本可控、且不被单一 SaaS 供应商锁定的方案；对于不愿投入技术配置成本、希望打开网页就能写作的用户，FictionForge 的使用门槛会成为主要成本。

👥 适合人群

对 AI 长篇写作中“角色崩坏、设定遗忘、时间线错乱”问题有切肤之痛、愿意用工程手段而非反复调提示词来解决的创作者；有编程基础、希望深入控制多智能体协作机制和生成管线的技术型作者；研究 AI 叙事一致性、多智能体系统或长文本生成的研究者和开发者（CanonBench 提供了可复现的评测基准和消融实验设计）；以及希望把小说创作流程拆解为可配置、可审计、可版本管理的工程系统的团队。FictionForge 尤其适合“技术能力足够、且对长篇结构控制有较高要求”的场景。如果核心需求是零部署、打开网页就能让 AI 写一段文字，或者完全没有 Python 环境和 Git 使用经验，这个框架的工程复杂度会构成实质障碍；专注于 MCP 工具链和扫描器能力的用户，可以关注 geobond13/fiction-forge 这一侧重不同的开源分支。

✅ 优点

• 多智能体架构把长篇一致性从“模型自觉”变成“工程约束”：每个角色独立持有记忆和信念，叙事合成器负责合并，避免了单一上下文窗口中所有角色信息互相干扰的问题，这是多数 AI 写作工具在架构层面没有解决的
• 质量门禁是可执行、可配置的硬约束：反 AI 词、比喻上限、禁止词等指标在每一章生成后自动校验，不通过则重写，把“底线质量”交给代码而不是依赖模型每次都听话
• CanonBench 把长程一致性变成可量化、可复现的基准：零 LLM 判定器、确定性输入生成器和三档 harness 消融，让“哪个模型更好”这个问题有了更诚实的回答框架——答案取决于你把它装进什么样的管线
• 开源免费且架构透明，没有 SaaS 订阅和供应商锁定，所有代码和评测产物随仓库发布，clone 后即可离线复现和审计，对于研究者和希望深度定制的开发者来说价值明显
• 内容包与引擎代码分离的设计务实：私有不公开的连载可以放在仓库外，通过 novel_dir 指向独立目录，既享受开源框架的迭代，又不必把版权内容暴露在公共仓库中
• 项目对自身的局限和缺陷保持公开坦诚：README 中记录了判定器误报和 max_tokens 截断导致的结论订正，承认“口径缺陷会伪装成模型差异”，这种工程诚实度在 AI 工具项目中并不常见

⚠️ 缺点

• 不是开箱即用的写作 App，上手门槛高：需要克隆仓库、配置 Python 环境、理解 novel_config.json 中的 cast/Tier1/Tier2、bible 文件、vault 结构和 arcs 配置，没有编程和命令行经验的用户很难独立完成首次跑通
• 产出的是“工程可控的初稿”而非“可直接发布的终稿”：质量门禁校验的是可量化的底线指标（禁词、篇幅、人称等），但情节的感染力、人物的情感弧光和文风的个人辨识度仍然依赖作者在框架之外进行打磨，不能默认跑通管线就等于写出好小说
• 多智能体配置的复杂度与创作精力存在张力：为每个重要角色编写 Agent、维护 vault 状态和时间线、调整 bible 注入内容，这些都是需要持续投入的工程工作，对于只想专注“写”本身的作者，可能分散创作精力
• CanonBench 的首期结果规模有限（3 厂商 × 3 档 harness × 6 章），基准本身仍在迭代中，榜单上的数字应作为管线设计的参考而非绝对结论，不能简单理解为“某个模型一定最适合写小说”
• 项目存在多个同名或相近的仓库（wanqili857-byte/fictionforge 侧重多智能体框架和 CanonBench，geobond13/fiction-forge 侧重 MCP 工具链和扫描器），新用户容易混淆，需要先厘清自己需要的是“角色模拟与叙事合成”还是“上下文管理与质量扫描”
• 作为个人开源项目，长期维护、文档完备性和社区支持的稳定性无法与商业产品相比，遇到环境配置或框架层问题时主要依赖自行阅读代码和仓库文档排查

💡 使用技巧

• 先用“最低可用包”跑通最小闭环，不要一上来就配置完整的多智能体剧组：cast 只留主角或留空，bible 三件套（写作法则.md、世界观.md、人设.md）和最小 vault 即可运行 scripts/gen.py，确认环境、依赖和模型 API 连接正常后，再逐步增加 Tier1 Agent 和配角
• 把 novel_config.json 当作项目的“总控面板”来对待：protagonist_pronoun 是硬约束必填项，forbidden_words 会同时影响质量门禁和 LiteAgent 的 system prompt，quality 中的 anti-AI 词和比喻上限直接决定门禁的严格程度。先理解每个字段的作用再动手改，比跑出问题后再回头排查更省时间
• 私有不公开的连载，从一开始就使用 novel_dir 指向仓库外目录，不要把版权内容放进公共仓库。spec 中的 novel_dir 以 spec 所在目录为锚，绝对路径也可以，这样引擎代码和小说内容两套 Git 互不干扰，后续升级框架时不必担心内容被卷入
• 先跑一次 CanonBench 的离线复算（python3 -m bench.report.metrics bench/results/v2）和判定器自检，在零 token、零网络的条件下理解判定器能测什么、不能测什么，再决定你的质量门禁需要配置到多严格。理解基准的口径，比盲目调参更有助于避免“优化了错误指标”
• 质量门禁的配置需要在“严格”和“可读”之间找平衡：过严的 anti-AI 词表和比喻上限可能导致大量重写和 Token 消耗，过松则失去门禁的意义。建议先用示例小说的配置跑几章，观察重写率和最终文本的自然度，再针对自己的文风微调，而不是一次性把阈值拉到极限
• 把 Tier1 Agent 的编写视为“角色建模”而非“写提示词”：Agent 的 from_vault_state 方法接收的是结构化的 vault 状态和记忆存储，实现的是角色如何基于自己的记忆和信念做出反应，而不是一段静态的人设描述。先想清楚这个角色“知道什么、相信什么、会怎么做”，再写代码，比反过来更容易得到预期的叙事效果
• 如果主要需求是 MCP 上下文管理、冷读校验和扫描器，而不是多智能体角色模拟，可以转向 geobond13/fiction-forge 分支，它的侧重点不同（Context is the product），两个项目解决的是长篇写作中不同层面的工程问题，不必强行在同一个框架里同时满足所有需求