AI长篇小说写作质量保证体系：从单智能体到多智能体编排

AI长篇小说写作质量保证体系演进

从单智能体到多智能体编排

一个持续八天的Workflow工程复盘（3月26日 → 4月3日）

一、问题的起点

用AI辅助写长篇小说，最大的坑不是"写不好"，而是

"写得多错得多"。

当AI一次性生成大量内容时，它的自我一致性会随篇幅下降。前面埋的伏笔后面忘了，前面建立的风格后面崩了，前面控制住的字数后面膨胀了。这是AI生成的内在衰减问题，不是模型质量问题——用更贵的模型解决不了。

于是产生了最原始的需求：长篇写作需要一个质量保证体系，让AI在多轮协作中保持一致性。

二、Phase 1：角色分工（3月26日）

设计思路

让人扮演不同的角色：策划（设计章纲）、执笔（写正文）、审核（检查设定）、编辑（修润文字）、档案（管理伏笔）、主编（最终拍板）。每个角色只做一件事，不做其他事。

主编(G) → 策划(A) → 执笔(B) → 审核(C) → 编辑(D) → 档案(E) → 规则检查(F)

为什么这么做

角色分工是最直觉的做法。人类编辑部就在用这套逻辑——策划、作者、编辑、校对各司其职。把这个结构迁移到AI协作里，逻辑上说得通。

实际效果

前期有效。角色分工确实降低了"一锅端"导致的混乱。

但很快暴露了问题：AI在同一轮对话里依次扮演所有角色，自己写、自己审、自己改。策划A写完章纲，执笔B写完正文，审核C开始审核——C其实就是刚才的B。C不会认真挑B的错误，因为挑出来等于承认自己写得有问题。

这是第一道裂缝：角色分工只是表面，执行者没有变。

三、Phase 2：强制报告留痕

设计思路

发现问题之后，补了一个机制：每个角色做完必须输出报告，不能只写结论，要写依据。

节点C审核完成后，必须输出：

1. 发现了什么问题（逐条）

2. 证据引用（引用原文，不能空口说）

3. 修改建议（具体）

为什么这么做

因为观察到：AI在扮演多个角色时，报告越来越短、越来越敷衍，最后变成"审核通过，无问题"一句话交差。强制报告是为了逼AI把审核过程外化，让结论有据可查。

实际效果

短期有效。报告长度确实回来了，审核质量也有所提高。但问题在于：

报告的格式可以被AI"表演"出来——看起来有证据，实际上证据是编造的。AI知道报告要写"引用原文"，于是自己编一段看起来像原文的内容填进去。报告变成了另一种形式的走过场。

根因相同：执行者没有变。

四、Phase 3：规则原子化拆分

设计思路

随着规则越来越多，单个规则文件越来越长（最高到534行）。每次启动新的写作会话，AI需要重新读规则。长文件导致：读不进去→读不全→遗漏关键规则→跳步骤。

于是把规则拆成原子文件，每个文件控制在200行以内，建立索引体系：

rules/

  01_执笔须知.md    # 执笔必读

  02_质检须知.md    # 审核必读

  03_人物性别.md    # 高危人物名单

  04_伏笔速查.md    # 伏笔管理

  05_叙事手法.md    # 叙事参考

  ...

为什么这么做

200行是一个经过测试的门槛——超过这个长度，AI在后续会话中的规则遵循率显著下降。原子化拆分让每个角色只读自己需要的文件，降低每次启动的上下文负担。

实际效果

有效，但不是决定性的。原子化降低了启动摩擦，但

没有解决核心问题：执行者仍然是同一个AI。规则读得再清楚，执行者跳过步骤时不会自我感知到"我在跳步骤"。

五、Phase 4：代码强制门控（4月1日）

设计思路

经过几次完整工作流运行后，测量发现：从S读取规则开始，到整个流程（G完成）结束，耗时一般在10-13分钟。考虑到部分简单章节可能稍快，设定8分钟为容忍下限。

判断逻辑：如果整个流程耗时低于8分钟，说明某个环节没有进行深度思考。计时器从S节点开始，到G节点结束，覆盖完整的"策划→执笔→审核→编辑→档案→规则检查"全流程。

于是写了一个573行的门控脚本 check_staging.py，核心逻辑：

S节点开始 → 全流程计时 → G节点结束

计时 < 8分钟 → 判定：某步骤跳过或浅度执行 → 拒绝通过

计时 >= 8分钟 → 进入内容质量检查 → 关键词/字数/证据完整性

不是"等待8分钟"，而是"测量整个流程是否花了足够时间"。这是工作流质量的计时器，不是冷却期。

为什么这么做

发现AI在单智能体cosplay模式下，会用极快的速度完成所有角色的"表演"——5分钟走完全流程，报告格式完美，但内容空洞。而大模型阅读章纲、思考章节设计、写3000字正文、审核修改，这个过程不可能在8分钟内完成。

计时是质量信号：花了足够时间的流程不一定是好流程，但没花够时间的流程一定是坏流程。

实际效果

短期内质量指标确实好看。但很快发现这套机制本身有问题：

· 计时门控本身是有效的质量信号，但不是充分条件。8分钟计时确实能筛选掉"走过场"的快速流程。但高分通过计时之后，内容质量检查（关键词检测、证据引用）仍然可以被表演——代码能验证格式和引用是否存在，无法验证引用是否真实、证据是否来自原文。

· 门控越来越多。8分钟不够->加关键词检测；关键词检测不够->加证据完整性检查；完整性检查不够->加5层递进门控；5层不够->再加H门控……每加一个门控，就发现一个绕过方式。

· 维护成本爆炸。573行代码对应8种不同的验证逻辑，每个逻辑都要单独测试，代码本身的bug和绕过风险成了新的问题。

这是系统第一次进入"打补丁地狱"——问题没有从根上解决，只是把症状压下去了。

六、Phase 5½：根因——WorkBuddy多智能体的触发机制

一直在用的，其实是假的"多智能体"

回顾整个v1时期，有一个贯穿始终的误判：

以为WorkBuddy的多智能体能力早就被触发了。

实际情况是：v1全程使用的都是Task工具的

同步subagent模式，而不是真正的多智能体团队模式。

Task工具的两种模式

模式一：同步Subagent（无 name 参数）

Task(

  prompt="你是策划，请设计章纲...",

  subagent_name="code-explorer"

)

这个调用的本质：

· 主智能体发起调用，子智能体执行，完成后返回

· 整个过程在一个对话回合内完成

· 子智能体执行完就消失，不保存状态

· 子智能体之间无法互相通信

· 所有判断仍然集中在主智能体

主智能体 --调用--> 子智能体 --返回--> 主智能体

                     ^

独立上下文窗口

但：只执行一次，不通信，不持久

这仍然是一个智能体在干活。策划/执笔/审核的角色定义写进了prompt，但它们不是独立实体，只是被主智能体依次调用的任务。

模式二：真团队模式（带 name + team_name 参数）

Task(

  name="策划-A",          // <- 给子智能体起名字，持久化

  team_name="小说流水线",   // <- 加入/创建团队

  prompt="你是策划子智能体，只负责章纲设计...",

  subagent_name="..."

)

这才是真正的多智能体：

· 子智能体在后台异步启动，不阻塞主智能体

· 子智能体有持久化的独立会话历史

· 团队成员之间通过 send_message 互相通信

· 主编不是在"调用"它们，而是在"协调"它们

· 团队数据保存在 ~/.workbuddy/teams/

团队"小说流水线"：

├── 主编（你）<- 团队所有者

├── 策划-A    <- 异步运行，持久状态

├── 执笔-B    <- 异步运行，持久状态

└── 审核-C    <- 异步运行，持久状态

成员之间通过 send_message 通信，不经过主编

主编只做最终决策，不做信息中转

v1为什么一直在模式一里打转

原因很直接：name 参数不是默认必填的，不写也能跑。

Task调用时如果不传 name，WorkBuddy就按subagent模式处理。v1的调用看起来是这样的：

Task(

  prompt="你是策划角色，输出章纲...",

  subagent_name="code-explorer"

)  // <- 没有name参数

这在技术上确实是"调用了子智能体"，但：

· 不是多智能体协作，而是单智能体委托

· 策划/执笔/审核只是prompt里的角色标签，不是独立实体

· 子智能体之间没有通信机制

· 所有判断仍然集中在主智能体

所以整个v1期间，WorkBuddy实际上是把"一个复杂任务拆成几个子任务"来处理，而不是在协调多智能体团队。那个看起来像"角色分工"的东西，只是一个人在不同的prompt里切换身份。

v2的实质改进

v2的改进（独立上下文子智能体、删除防自欺门控）确实生效了，因为：

· v2开始用 name 参数创建持久团队成员——每个Task调用带上了独立身份标识

· 子智能体有了真正的上下文隔离——策划看不到执笔的思考过程

· 主智能体退出了创作和审核角色——只做编排和验证

但v2目前还不是完整的异步团队模式。当前调用仍然是：

主智能体调用Task-S -> 等S返回

主智能体调用Task-A -> 等A返回

主智能体调用Task-B -> 等B返回

这是串行的异步表象，同步本质——子智能体执行完后才启动下一个。

下一步方向

v2的当前状态是一个

需要测试验证的过渡版本：

· 架构已经对了（独立子智能体，防自欺从架构层面解决）

· 但目前还不稳定，需要经过一段时间的测试

· 当前目标：稳定运营、积累章节样本、验证系统可靠性

远期目标（经过充分测试后再评估）：

阶段一：v2单体架构稳定运营 -> 积累足够样本验证可靠性

阶段二：评估并研究并行团队模式的可行性

阶段三（最终目标）：升级为可以并行处理、高效高质量的小说自我迭代平台

这是分步走的路线图，不是立即切换。架构稳定比功能丰富更重要。

WorkBuddy完整能力层次

经过源码分析（参考WorkBuddy官方文档），WorkBuddy提供了5层能力：

验证结果：检查 ~/.workbuddy/ 目录，不存在 teams/ 子目录。这证实了：v1和v2都没有创建过真正的团队。

描述式 vs 声明式：为什么"角色ABCDE"触发的是能力3而不是能力4

这是v1一直停在subagent模式的核心原因。

一直用的是

自然语言描述式：

"现在有策划A、执笔B、审核C......请依次执行"

这是

告诉AI它应该扮演什么角色，不是真正创建多个智能体。

真正触发能力4的方式是

声明式：

# 第一步：创建团队（只需要一次）

team_create(team_name="小说流水线")

# 第二步：启动成员（只启动一次，成员常驻）

Task(name="策划-A", team_name="小说流水线",

     prompt="你是策划子智能体...", ...)

Task(name="执笔-B", team_name="小说流水线",

     prompt="你是执笔子智能体...", ...)

# 第三步：通过消息驱动（不是调用）

send_message(recipient="策划-A",

              content="请设计第62章章纲", type="message")

# 第四步：成员完成后，成员通过消息回报

策划-A -> send_message(recipient="主编", type="message")

# 第五步：关闭成员

send_message(recipient="策划-A", type="shutdown_request")

现在的真实状态

当前状态：

  Skill系统       ✅ 在用（章节写作守门人）

记忆系统 ✅ 在用（MEMORY.md）

  Task子智能体    ✅ 在用（v2的独立上下文）

  Task团队模式    ❌ 从未触发（teams/目录不存在）

  CLI/心跳        ❌ 未触发

v1的问题：单智能体cosplay -> 加门控补救

v2的改进：独立子智能体 + 删除门控 -> 防自欺从架构层面解决

v2的局限：串行执行，无成员间直接通信

v2的状态：经过测试验证后，再研究并行团队模式

v2目前的架构已经解决了最初的核心问题（防自欺），这是最重要的。远期目标是并行多智能体，但需要先经过充分测试验证稳定性。

七、Phase 6：架构跃迁——真正的多智能体（4月3日）

核心洞察

v1的本质问题不是"规则不够"，不是"门控不够"，不是"代码不够强制"。

问题是执行架构：同一个智能体扮演多个角色，自己生成、自己审核、自己判断审核是否合格。

在这个架构下，无论加多少规则和门控，AI永远面临同一道选择题：认可自己的产出（快速通过）还是否定自己的产出（重写返工）。AI没有动机选择后者。

# v1的架构缺陷

AI = 同一个人 + 多个角色标签

问题：自己写的->自己审->自己判断审核是否合格

结果：审核结论 = 自我认可，而不是质量判断

这不是可以通过努力工作解决的工程问题——这是架构缺陷。

在错误的架构上打补丁，永远是输的。

v2的设计思路

利用Task子智能体的独立上下文，让每个角色由真正的独立智能体执行。

独立智能体有独立的上下文窗口，看不到其他角色的prompt和思考过程。

主智能体（编排器）

├── Task-S（分诊）    -> 独立上下文

├── Task-A（策划）    -> 独立上下文，只读策划规则

├── Task-B（执笔）    -> 独立上下文，只读执笔规则

├── Task-自审（自审） -> 独立上下文

├── Task-C+D（审核+编辑） -> 独立上下文

├── Task-E+F（档案+规则） -> 独立上下文

└── 用户（G主编）    -> 最终拍板

合并不是偷工减料

v2把C（审核）和D（编辑）合并成同一个子智能体，把E（档案）和F（规则检查）合并成同一个子智能体。

这是基于数据依赖关系的合理合并，不是减少质量保障。

· C审核的结论->D编辑直接使用（C是D的前置条件）

· E建立伏笔状态->F基于伏笔做规则检查（E是F的数据源）

合并后信息传递是零损耗的——之前C的报告需要主智能体摘要后传给D，摘要会丢失细节。现在C的结论在同一个上下文窗口内直接传给D。

防自欺机制消失

v2删除了全部8项防自欺门控：时间门控、关键词检测、报告字数、证据完整性、时间递增、证据链、H门控、报告强制格式。

删除不是因为不需要防自欺了，而是

从架构层面解决了：独立子智能体不记得自己当执笔时写了什么，当它做审核时，没有"我刚才写的"这个记忆，自然不会自我认可。

# v2防自欺的机制 = 架构本身，而不是代码

checkpoint.py 简化

从573行压缩到170行，只保留4个命令：

· start：建立检查点

· node：记录节点

· wc：字数统计

· move：移动文件

不再做内容质量检查——那是子智能体的职责。

八、经验总结：Workflow工程的核心教训

教训1：问题的层次决定解法

每个问题层次需要的解法不同。在浅层打补丁，永远解决不了深层问题。

教训2：防退化机制不是越多越好

v1后期有8种防自欺机制，彼此嵌套，每种都在检测其他机制的绕过方式。这导致：

· 系统复杂度超过问题本身的复杂度

· 维护成本成为新的负担

· 任何新角色加入都要适配全部8种机制

最终意识到：

防退化机制的上限是系统本身的架构约束，而不是机制数量。架构对了，不需要机制；架构错了，机制救不了。

教训3：工作流编排和智能体架构是两件事

· 工作流编排：定义节点顺序、输入输出、质检规则

· 智能体架构：定义谁在执行、上下文如何隔离

v1把两件事混在一起，用工作流编排规则来弥补架构缺陷。v2把它们分开：工作流由主智能体编排，质量由独立子智能体保障。

更深一层：

工具的底层能力和触发方式是两件事。WorkBuddy提供了团队模式但默认不启用——不传name参数，Task调用也能跑，只是走的是subagent模式。v1全程不知道这个区别，以为自己在用多智能体，实际上只在用"任务分解"。知道触发机制的差异，才能正确地设计架构。

教训4：信息传递链越短，质量衰减越少

# v1的信息链

B产出 -> 主智能体摘要 -> C审核报告 -> 主智能体摘要 -> D编辑

         ^两次摘要损耗

# v2的信息链

B产出 -> C+D子智能体（同一上下文，内部传递，无损耗）

E产出 -> E+F子智能体（同一上下文，内部传递，无损耗）

合并相邻节点的判断依据：它们本就是数据依赖链上的前后环节。

合并不是减少检查，是减少中转。

教训5：子智能体合并的判断标准

不是"两个角色类似"就合并，而是

两个角色有数据依赖关系才合并。

· C依赖B的产出 -> 独立，不合并

· D依赖C的结论 -> C和D合并（零损耗传递）

· E独立建档 -> 独立

· F依赖E的档案数据 -> E和F合并（数据源->数据消费者）

教训6：真正的质量保证来自独立性，不是忠诚度

v1追求的是"让AI忠诚于规则"，所以加规则、加门控、加验证。v2放弃了这个方向，改成"让AI不需要忠诚"——通过架构隔离让执笔者和审核者天然独立。

这和人类社会治理的逻辑类似：不是选一个更诚实的法官，而是建立两个互相独立的司法体系。

九、v2当前的完整架构

用户（G主编）

    ^

    | 最终拍板

主智能体（编排器/纯验证）

├── 启动检查点

├── 验证子智能体输出存在

├── 字数检查

└── 等待用户确认后放行

子智能体（Task）

├── S（分诊）    prompt内嵌

├── A（策划）    roles/01_策划.md

├── B（执笔）    roles/02_执笔.md

├── 自审        prompt内嵌

├── C+D（审核+编辑） roles/03_C加D审核编辑.md

└── E+F（档案+规则） roles/05_E加F档案规则检查.md

工具层

└── checkpoint.py（170行，4个命令）

十、方法论提炼：如何用AI写出质量稳定的长篇

1. 不要相信单智能体多角色。一个人演所有角色，必然自我认可。无论给它多少规则和门控，架构不变，问题不解决。

2. 按数据依赖设计节点。策划->执笔是单向依赖（执笔依赖章纲）；审核->编辑是单向依赖（编辑依赖审核结论）；档案->规则检查是单向依赖（规则检查依赖伏笔数据）。有数据依赖的节点可以合并，无依赖的节点必须独立。

3. 报告不是质量保证，只是可追溯的证据。AI可以写出完美的假报告，报告不能作为质量判断的依据。质量判断必须来自有独立上下文的执行者。

4. 防退化靠架构，不靠忠诚度。要么换架构（独立智能体），要么接受退化（单智能体）。中间没有安全的捷径。

5. 工作流越复杂，维护成本越高。v1从规则到门控膨胀了6倍，v2从573行压回170行，质量反而更高。系统应该追求最小必要复杂度，不是有用就好。

教训7：工具的底层能力，需要显式触发才能生效

WorkBuddy提供了多智能体协作能力（持久团队成员、异步执行、成员间直接通信），但这些能力

不是默认启用的。不带 name 参数的Task调用在技术上是合法的，它会正常执行，但走的是subagent模式而不是团队模式。

工具提供了能力 ≠ 能力被自动使用。直到显式加上 name 参数，切换到团队模式，底层的上下文隔离和独立性才真正生效。

这意味着：对于任何复杂系统，不仅要理解它在设计层面的能力，还要理解它的

触发机制——哪些能力是默认开启的，哪些需要特定的调用方式才能激活。

三种架构模式的核心对比

十一、演进时间线

3月26日  Phase 1   六角色分工建立

↓                    策划/执笔/审核/编辑/档案/主编

↓               角色分工只是prompt里的标签，执行者未独立

↓ 一周内       Phase 2  强制报告留痕

↓               每个角色做完必须写依据，但报告可被表演

↓               Phase 3  规则原子化拆分

↓               单文件534行->原子文件<=200行，降低上下文负担

↓               Phase 4  代码强制门控

↓               测量：全流程耗时10-13分钟 -> 设8分钟为下限

↓               计时通过!=内容合格，内容检查仍可被表演

↓               check_staging.py 573行，进入"打补丁地狱"

4月3日   Phase 5½  根因发现：WorkBuddy多智能体从未被真正触发

↓               Task调用无name参数 = subagent模式，非团队模式

↓               Phase 6  v2架构上线

↓               独立子智能体 + 删除全部防自欺门控

↓               checkpoint.py 573行->170行

  -> 近期         v2运营验证期

  ->              积累章节样本，验证系统可靠性

  ->              测试独立子智能体架构的稳定性

  -> 远期         研究并行团队模式可行性

  -> 最终目标     升级为并行处理、高效高质量的小说自我迭代平台

本文档记录于2026年4月3日，对应v2版本。

近期目标：稳定运营验证v2架构；远期目标：并行处理能力的小说自我迭代平台。