| name | novel-delegate-task-writing |
| description | 用 delegate_task 替代 CC CLI 写小说正文。触发：DRAFT/POLISH步骤。 |
delegate_task 小说正文生成方案
背景
2026-08-13 回测验证：Claude Code CLI 通过 pandai 中继调用 v4-flash/v4-pro 时存在严重问题——DSML 标记干扰、thinking block 吞正文、stream-json 解析复杂、进程不退出。改用 Hermes 原生 delegate_task 子智能体（glm-5.2-thinking）后问题全部消除。
回测数据（第66章）
| 指标 | 原流程(Claude Code sonnet) | delegate_task(DRAFT+EXPAND) |
|---|
| 最终字数 | 2305 | 2738 |
| 对话比例 | 48.07% | 40.4% |
| 总耗时 | 712秒 | 238秒（快67%） |
| 费用 | $2.36 | ~$0.05（降98%） |
| API调用 | stream-json事件流 | 11次（4+7） |
| 机械问题 | — | 0 |
| 真实地名 | — | 无 |
核心流程
DRAFT（初始正文生成）
- 主 Agent 读取骨架 + 前文时间线 + 书配置 → 构造 goal
- delegate_task 派发 leaf 子智能体，goal 中包含完整骨架和铁律
- 子智能体返回正文文本（summary）
- 主 Agent 验证：
review_scan.py 检查字数/对话比例/机械问题
EXPAND（字数不足时扩写）
- 初稿字数 < 2000 时，把初稿 + 扩写指令作为 goal 派发第二个子智能体
- 扩写指令指定：增加对话交锋轮次、增加围观者反应、增加对手反应细节
- 禁止：环境描写凑字、机械动作、静态等待
POLISH（内容打磨）
同 DRAFT 流程，把初稿 + 审查报告作为 goal 派发子智能体。
⛔ 禁止截断（铁律）
用户原话：「截断？剧情还能接？粗暴截断不就是傻逼行为？字数和对话占比差不多就行了」
绝对不要为了满足字数上限而截断正文。字数超了就是超了——这是小说，不是代码。截断会破坏剧情连贯性和章末钩子。
字数/对话比例的弹性区间（2026-08-13 确认）：
- 字数：2000—2800（目标 2350，但不强制截断）
- 对话比例：≥ 38%
- 字数略超（如 2700、2800）或对话比例略低（如 38-40%）不算问题，不微调
delegate_task goal 构造要点
必须包含
- 完整骨架（从
00-大纲细纲/章节骨架/第N章_骨架.md 读取）
- 前文时间线速查（最近3章）
- 书配置摘要（地名白名单、系统面板字段、方言词表）
- 铁律三条：禁止真实地名、系统面板原封不动、字数+对话+格式要求
- 网文校准：情绪直接给、事件密度高、大白话、钩子具体
context 参数
- 明确告知子智能体这是小说正文生成任务
- 列出关键约束（字数、对话比例、格式）
- 列出禁止项（真实地名、系统新功能、环境凑字、自创人物/机构）
已知限制
- 字数不稳定：glm-5.2-thinking 首次生成约 1760 字（压缩 20%），需要扩写补足
- 对话比例偏低：初次生成约 29%，需要扩写时明确要求增加对话交锋
- 禁用词：子智能体可能使用"最终"等禁用词，REVIEW 阶段 review_scan.py 会拦截
与 Claude Code CLI 的对比
| 维度 | Claude Code CLI | delegate_task |
|---|
| 模型 | v4-flash/v4-pro（pandai中继） | glm-5.2-thinking（Hermes原生） |
| 干扰 | DSML标记、thinking吞正文 | 无 |
| 超时管理 | idle_timeout + capture_idle_timeout | 自动完成（2分钟内） |
| 文件I/O | 模型自行Read/Write | 主Agent负责落盘 |
| 验证 | 模型自我验收（浪费轮次） | 主Agent脚本验证 |
| 成本 | $2.36/章 | ~$0.05/章 |
推荐流程（最终版）
PREP → PLOT → 骨架 → delegate_task DRAFT → 验证 →
(字数不足<2000?) → delegate_task EXPAND → 验证 →
(字数超了?) → 不动，直接通过 →
REVIEW → delegate_task POLISH → 验证 → TRACK → BACKUP
走过的弯路（避免重复）
- capture mode（零工具）：v4-flash 把正文写在 thinking block 里，不产生 text output。thinking 提取逻辑太脆弱（多版本正文混在 7 万字 thinking 中）。放弃。
- Write-only 到候选文件：v4-flash 仍先做 10 万字 thinking，max-turns=2 用完也没调用 Write。放弃。
- overshoot 系数调优：v4-flash 字数极不稳定（1974~3691），overshoot 无法稳定命中。放弃。
- 智能截断：用户明确拒绝——「粗暴截断是傻逼行为」。字数超了就超了，不截断。
- 结论：问题根源是 pandai 中继的 v4-flash extended thinking 行为，不是 prompt 或工具配置。delegate_task 绕过了所有中间层。
相关文件
references/delegate-task-novel-writing.md — 详细回测日志、prompt 模板- 脚本
chapter_fast_gate.py 的 chapter_gate_text() — 文本验证（不依赖文件I/O）
- 脚本
review_scan.py — 正式审查扫描器（主 Agent 使用）
注意
- novel-main SKILL.md 已在 2026-08-13 更新为 delegate_task 方案（DRAFT/POLISH 步骤）。
- novel-writing SKILL.md（入口技能）仍多处引用旧的 Claude Code CLI 和 claude_runner.py 命令，且仍保留"delegate_task 禁用"铁律。需用户执行
hermes curator adopt novel-writing 后才能自动更新。
- claude_runner.py 的 capture_mode 和 thinking 提取逻辑仍保留在代码中，但不再推荐使用。
