致有缘人,我当保存文档而已

🦞 小龙虾多智能体小说工厂设计方案（完善版）

1. 项目概述

基于 OpenClaw 框架，构建一个由四个智能体（Agent）组成的自动化小说创作流水线。系统不仅能分工协作完成小说章节的连续生成，还内置了自愈机制，确保在单个 Agent 发生故障时能自动发现并修复，从而实现真正的 7×24 小时无人值守创作。

2. 智能体角色与职责

角色 代号 核心职责 次要细节（括号内为可深入方向）
大纲与档案管理员 A 负责项目初始化、生成大纲、保存章节、维护项目档案 （如何管理多项目任务池？大纲生成采用何种 prompt 策略？档案目录结构设计）
章节撰写人 B 根据大纲和已有章节，续写下一章 （如何维持长篇小说的人物一致性？是否引入记忆向量或摘要？多轮写作时的上下文裁剪）
审核官 C 检查新生成章节的质量，决定通过、退回修改或触发重写 （审核规则如何定义？能否引入人工反馈循环？是否区分硬性规则和 AI 主观评分？）
维修工 D 监控其他 Agent 健康状态，发现故障时自动介入修复 （故障判定标准是什么？维修操作包括哪些？如何保证维修过程不影响已有数据？）

3. 核心工作流程（大方向）

3.1 正常流程

1. 任务分配：从任务池（如 projects/pending/）中取出一个选题，交由 Agent A 处理。
2. 大纲生成：Agent A 根据选题生成大纲、人物设定、世界观等，保存到项目专属文件夹（如 projects/project_X/outline.md）。
3. 写作循环：
· Agent B 读取大纲和已有章节，撰写下一章，保存到 chapters/。
· 完成后通知 Agent C 审核。
· Agent C 审核通过，通知 Agent A 存档（将章节合并到完整稿件），并通知 Agent B 继续下一章。
· 若审核不通过，Agent C 返回修改意见，Agent B 根据意见重写本章（可设置最大重试次数）。
4. 项目完结：当完成预设章节数（如 10 章），Agent A 将最终稿件生成为 Markdown 文件（final.md），并更新项目状态为完成，同时从任务池中取出下一个选题，触发新一轮循环。

3.2 异常流程（自愈机制触发）

· 当任一环节超时或无响应时，其下游 Agent 会尝试唤醒（如发送心跳请求）。
· 若唤醒失败，下游 Agent 立即通知 Agent D。
· Agent D 根据故障类型执行修复（如重启进程、恢复数据、回滚到上一检查点），修复后通知相关 Agent 继续工作。

4. 自愈机制详解（核心亮点）

4.1 监控体系

· 心跳检测：每个 Agent 定期向共享状态文件（如 status.json）写入时间戳。
· 超时判定：下游 Agent 在执行前检查前置 Agent 的最后心跳时间，超过阈值则视为可疑故障。
· 试探唤醒：向下游 Agent 发送 ping 指令（可借助框架的消息队列），等待回应。

4.2 故障上报

· 若试探后仍无回应，下游 Agent 将故障信息写入 fault_queue，并附带故障上下文（如当前项目、预期数据位置等）。
· Agent D 监听故障队列，一旦有新故障立即处理。

4.3 维修动作

· 进程级修复：通过框架 API 重启无响应的 Agent。
· 数据级修复：检查项目数据完整性，若数据损坏则从备份恢复（备份策略见 6.2）。
· 逻辑级修复：若 Agent 运行但逻辑错误（如陷入死循环），可强制重置其状态并重新分配任务。
· 维修记录：所有维修行为写入日志，供后续分析。

5. 技术架构建议（大方向）

5.1 通信机制

· 基于文件的状态同步：简单可靠，每个 Agent 定期读写共享目录下的状态文件。（小方向：是否需要引入 Redis 或消息队列提高实时性？）
· 任务队列：用文本文件或 SQLite 管理待处理项目。（小方向：是否需支持优先级？）
· 指令传递：通过约定格式的 .cmd 文件传递跨 Agent 指令。（小方向：是否使用 JSON-RPC over HTTP？）

5.2 存储结构

“`
projects/
├── pending/ # 待处理选题（每个选题一个 .txt 或 .json）
├── active/ # 进行中的项目
│ └── project_001/
│ ├── config.json # 项目配置（章节数、风格等）
│ ├── outline.md # 大纲
│ ├── status.json # 项目状态（当前章节、各 Agent 进度）
│ ├── chapters/ # 原始章节
│ │ ├── 01.md
│ │ └── …
│ ├── reviews/ # 审核记录
│ └── backup/ # 自动备份
└── completed/ # 已完成项目
└── project_001/
└── final.md
“`

5.3 模型与 API

· Agent A（规划）：可使用强推理模型（如 GPT-4）以保证大纲质量。（小方向：能否用本地模型降低成本？）
· Agent B（写作）：可选用性价比高的模型（如 Claude Instant 或 GPT-3.5）。（小方向：是否需要针对不同风格微调？）
· Agent C（审核）：需较强判断力，建议使用与 A 相同的强模型，但提示词更侧重于规则执行。
· Agent D（维修）：无需调用大模型，直接通过脚本执行系统操作。

6. 部署与安全

6.1 运行环境

· 推荐使用 Docker 容器隔离每个 Agent，防止相互影响。
· 设置资源限制（CPU/内存），避免单个 Agent 耗尽主机资源。

6.2 数据安全

· 自动备份：Agent A 每次保存章节前，自动将当前项目目录备份到 backup/（带时间戳）。
· 版本控制：可考虑将 projects/ 目录纳入 Git 管理，方便回滚。

6.3 权限控制

· Agent 只能读写自己的项目目录和共享状态目录，不能修改系统文件或其他 Agent 配置。
· OpenClaw 配置文件应设置为只读，防止 Agent 误修改导致崩溃。

7. 潜在问题与优化方向

问题 优化方向（括号内为深入点）
Token 消耗过高 为不同 Agent 分配不同模型；启用长上下文压缩；定期总结历史章节作为上下文摘要
审核标准主观 引入多重审核（如两个 Agent 投票）；允许人工介入修正
Agent 逻辑冲突 增加协调者 Agent，统一管理任务分配与冲突解决
维修操作误判 设置故障确认机制（多个下游同时上报才触发维修）；维修前快照当前状态
无限循环 为每个项目设置最大重试次数（如某章最多重写 3 次），超过则标记异常并通知人工

8. 下一步开发建议

按阶段推进，每个阶段完成后再深入括号内的细节：

· 阶段一：最小可行性闭环
· 实现单个项目（1 章）的 A→B→C 流程，手工触发，无自愈。
· （提示词设计、文件结构、简单通信）
· 阶段二：循环与多章节
· 加入章节计数、自动触发下一章、最终保存 Markdown。
· （任务池管理、项目切换逻辑）
· 阶段三：自愈机制
· 实现心跳监控、故障上报、Agent D 的简单重启。
· （故障判定阈值、维修操作脚本）
· 阶段四：健壮性提升
· 加入备份恢复、多重审核、Token 优化。
· （备份策略、审核规则细化、上下文摘要）
· 阶段五：扩展功能
· 多项目并行、人工介入界面、模型动态切换。
· （并发控制、Web 仪表盘、模型路由）

—

这个设计方案为你搭建了一个坚实的骨架，每个括号内的内容都是可以深入挖掘的技术点。你可以根据自己的时间和兴趣，逐步填充细节，最终打造出一个真正智能的自动小说工厂。如果有任何部分需要展开讨论，随时告诉我！