建议优化:长篇写作测试中单章写作时间可高达40分钟

[Evan-Pycraft]

[inkos] 1 post-write errors detected, triggering spot-fix before audit
修复过程,可能高达2000秒以上

spot-fix 需要的上下文所有文件都是全量的

但实际spot-fix 只是修复不是重写

不过这点我有疑问问下大佬的想法

当初是为了方便全部做了全量模板还是还没有开始做特定的优化

这导致一个非常严重的问题

就是写到50章之后修复时间会非常非常长

有些甚至40分钟才能一章 一开始的时候不会这么长时间

Reviser的时间也越来越长

还有在Settler 阶段也是 很多时候都是全量丢给大模型

一开始没啥感觉 到后面我的模型思考炸了@!@

[Evan-Pycraft]

不过话又说回来很多很多时候优化过度了会导致小说情节出现问题 不知道大佬设计思路是怎么样的 有时候有些事情鱼和熊掌不可兼得除非大模型上下文又大速度又快 😄

[Narcooo]

全量注入在早期是很有用的，不过写到长篇导致上下文，记忆和质量的系统性原因，大更新正在加紧测试中！！

[Evan-Pycraft]

原来如此 期待你的大更新 我这边持续测试!

[vvincol-arch]

优化卡在phase2这个阶段，因为上传chapter_summaries.md这个文件，这个文件是每一章的概括，越积越大；几十章就能过100kb，传给llm，基本都没回复，或者要等很久；这个要简化下还有机会；

[vvincol-arch]

全量注入在早期是很有用的，不过写到长篇导致上下文，记忆和质量的系统性原因，大更新正在加紧测试中！！

兄弟我有个想法，问题就在chapter_summaries.md这个文件越积越多，里面冗余信息太多了；如果说有用的信息，1.hook有关的信息抽出来 2.主要人物状态。。。 其他可以删掉，里面90%以上都是冗余无用信息

[Evan-Pycraft]

全量注入在早期是很有用的，不过写到长篇导致上下文，记忆和质量的系统性原因，大更新正在加紧测试中！！

兄弟我有个想法，问题就在chapter_summaries.md这个文件越积越多，里面冗余信息太多了；如果说有用的信息，1.hook有关的信息抽出来 2.主要人物状态。。。 其他可以删掉，里面90%以上都是冗余无用信息

大佬设计了个consolidate 命令,他就是用来压缩chapter_summaries.md 跑一次就会压缩前面的信息为一行 你可以试试 但是现在版本有问题 我之前报告了 作者会在下个版本解决
根本原因:
packages/core/src/agents/consolidator.ts 中 parseVolumeBoundaries() 方法使用的正则表达式与实际 volume outline 格式不匹配：
// 期望格式: 第1-30章（半角括号、en-dash）
// 实际格式: （1-20章）（全角括号、em-dash U+2014）
你可以修改下格式就能跑这个命令了 当然你也可以自己手动压缩 我测试不影响写作质量

[vvincol-arch]

Thanks for your mail.邮件已收，谢谢

[vvincol-arch]

全量注入在早期是很有用的，不过写到长篇导致上下文，记忆和质量的系统性原因，大更新正在加紧测试中！！

兄弟我有个想法，问题就在chapter_summaries.md这个文件越积越多，里面冗余信息太多了；如果说有用的信息，1.hook有关的信息抽出来 2.主要人物状态。。。 其他可以删掉，里面90%以上都是冗余无用信息

大佬设计了个consolidate 命令,他就是用来压缩chapter_summaries.md 跑一次就会压缩前面的信息为一行 你可以试试 但是现在版本有问题 我之前报告了 作者会在下个版本解决 根本原因: packages/core/src/agents/consolidator.ts 中 parseVolumeBoundaries() 方法使用的正则表达式与实际 volume outline 格式不匹配： // 期望格式: 第1-30章（半角括号、en-dash） // 实际格式: （1-20章）（全角括号、em-dash U+2014） 你可以修改下格式就能跑这个命令了 当然你也可以自己手动压缩 我测试不影响写作质量

感谢感谢，我试一下；

提个比较实际的建议，要控制输入token，因为输入太多，而且绝大多数都是冗余信息，目前的prompt应该是越来越长的，冗余信息其实是大部分（token也越来越多，回复越来越慢）；个人看法是应该上下文的篇幅限制（特别是很多人写分大块章节，前后基本场景完全无所谓，只要有主线hook记录就行），应该有个context限制，这样的话减少冗余同时；应该要有个策略控制prompt，（比如近3章提大纲，最后一章全文，前文覆盖前30章的压缩信息，再加各种状态真相，待解决hook。。。举个例子哈），这样的话需要有一个hook落实的具体章节位置细节表（提前规划）来配合，应该逻辑能圆。

---期待大作，这个程序非常专业，受益匪浅；感谢作者贡献

[Evan-Pycraft]

全量注入在早期是很有用的，不过写到长篇导致上下文，记忆和质量的系统性原因，大更新正在加紧测试中！！

兄弟我有个想法，问题就在chapter_summaries.md这个文件越积越多，里面冗余信息太多了；如果说有用的信息，1.hook有关的信息抽出来 2.主要人物状态。。。 其他可以删掉，里面90%以上都是冗余无用信息

大佬设计了个consolidate 命令,他就是用来压缩chapter_summaries.md 跑一次就会压缩前面的信息为一行 你可以试试 但是现在版本有问题 我之前报告了 作者会在下个版本解决 根本原因: packages/core/src/agents/consolidator.ts 中 parseVolumeBoundaries() 方法使用的正则表达式与实际 volume outline 格式不匹配： // 期望格式: 第1-30章（半角括号、en-dash） // 实际格式: （1-20章）（全角括号、em-dash U+2014） 你可以修改下格式就能跑这个命令了 当然你也可以自己手动压缩 我测试不影响写作质量

感谢感谢，我试一下；

提个比较实际的建议，要控制输入token，因为输入太多，而且绝大多数都是冗余信息，目前的prompt应该是越来越长的，冗余信息其实是大部分（token也越来越多，回复越来越慢）；个人看法是应该上下文的篇幅限制（特别是很多人写分大块章节，前后基本场景完全无所谓，只要有主线hook记录就行），应该有个context限制，这样的话减少冗余同时；应该要有个策略控制prompt，（比如近3章提大纲，最后一章全文，前文覆盖前30章的压缩信息，再加各种状态真相，待解决hook。。。举个例子哈），这样的话需要有一个hook落实的具体章节位置细节表（提前规划）来配合，应该逻辑能圆。

---期待大作，这个程序非常专业，受益匪浅；感谢作者贡献

我也觉得架构非常好,不过如果想要写好小说会有非常多的因素在里面,我在等大佬更新看他是如何来取舍的,不能单单的做限制,因为很多的东西是大模型自己完成的,例如有些伏笔收回的很晚或者规定了三章收回 但是大模型写到第四章甚至很后面还没有收回 如果单纯的去限制会导致后面写的乱七八糟.
我自己想的是多agent合作 例如下图:

                    ┌──────────────────────────────────────┐
                    │           ContinuityAuditor           │
                    │              (编排器)                 │
                    └──────────────────────────────────────┘
                                       │
        ┌──────────┬──────────┬────────┼────────┬──────────┐
        ▼          ▼          ▼        ▼        ▼          ▼
   ┌─────────┐┌─────────┐┌────────┐┌──────┐┌────────┐┌────────┐
   │Character││  Plot   ││ World  ││ Hook  ││ Style  ││ Cross  │
   │Continuity││Timeline ││Consist ││Recall ││Consist ││Reference│
   │ Agent   ││ Agent   ││ Agent  ││ Agent ││ Agent  ││ Agent  │
   └─────────┘└─────────┘└────────┘└──────┘└────────┘└────────┘
        │          │          │        │        │          │
        │          │          │        │        │          │
        └──────────┴──────────┼────────┴────────┴──────────┘
                               ▼
                    ┌──────────────────────────────────────┐
                    │            Aggregator               │
                    │  汇总 + 去重 + 冲突仲裁              │
                    └──────────────────────────────────────┘

但是我想想也有一个问题 流程太多了 会导致中间的过程比较久,整个架构太过复杂感觉不太符合作者设计思路, 这种方式每个agent只干一个事情会大大减少上下文 估计作者最近在加紧更新好几天没动了 在憋大的,我也在等 我现在正在测试不同的genres文件对于写作的影响,很有趣.