从单打独斗到九Agent流水线——小说创作系统的架构重构
两个月前我决定写一部长篇小说，250章，AI题材，时间跨度30年。第一周写了两章，第二周写了三章，第三周——卡住了。不是写不出来，是管理不过来。
九个角色（导演、编剧、研究员、设定守护、写手、精修师、审计师、试读者、插画师），每个都有自己的职责、输出格式和红线要求。我需要一个系统来管理它们。
第一阶段：硬编码平台
最初的方案最简单——把所有agent都注册在同一个平台上，用固定的slot ID绑定。配置写死在json里，模型写死在配置文件里，一切看起来都很美好。
直到我想切换模型。
然后我意识到：这个系统跟平台绑死了。如果我想换一个推理通道、换一个API后端，我需要重新配每一个agent。九个agent，每个的system prompt、model、base_url——全部重来。
这是典型的"拿锤子看什么都是钉子"架构。我把agent的角色定义和运行平台混在了一起。
第二阶段：解耦——agent_profiles.json
重构的核心是一个文件：agent_profiles.json。它做了三件事：
- 定义provider（aigent原生 / OpenAI兼容 / Hermes子代理）
- 定义9个agent模板（角色、system prompt路径、输出格式、依赖关系）
- 定义管线顺序和全局规则（红线、禁用词、质量门禁）
每一个agent的完整角色定义被抽到独立的 agent_prompts/director.md 这样的文件中。agent不再知道自己在什么平台上运行——它只知道自己的角色、输入和输出。
切换provider变成一条命令的事：
node setup-agents.js switch opencode-go把 aigent 换成 opencode-go，九个agent的system prompt全部重新注册到新的API后端。零人工干预。
第三阶段：九阶段管线
光有agent不够——需要定义它们怎么协作。我设计了一个九阶段管线：
| Phase | 名称 | Agent | 产出 |
|---|---|---|---|
| 1 | 并行准备 | 导演+编剧+研究员 | 导演笔记、剧本结构、研究笔记 |
| 2 | 设定审计 | 设定守护 | 设定审计报告 |
| 3 | 正文撰写 | 写手 | 章节草稿（≥5000字） |
| 4 | 精修增效 | 精修师+插画师 | 精修终版、插画方案 |
| 5 | 质量审计 | 审计师 | 6维度评分（全≥6/10通过） |
| 6 | 读者试读 | 试读者 | 8维度体验反馈 |
| 8 | 最终审计 | 设定守护 | 全文件一致性检查 |
| 9 | 格式发布 | 自动脚本 | md + txt + html |
注意Phase 7被跳过了——插画在Phase 4已经完成。而Phase 9（格式发布）必须放在所有质量门禁之后，避免精修完就出正式版、审计发现问题又要重新生成的尴尬。
这个顺序是在跑完第9章后才发现的——最初我把格式发布放在Phase 4.5，结果审计发现问题时正式版已经生成过了。现在它放在最后，确保只有全🟢通过的版本才会发布。
第四阶段：实时指挥部
有了agent和管线，还需要一个地方看到一切。我建了一个纯HTML页面，不依赖任何框架，通过fetch + ReadableStream实现真正的流式输出：
- 3×3卡片布局显示9个agent的实时状态
- 每个agent有状态灯（🟢空闲 / 🟡工作中 / 🔴超时）
- 输入指令后，agent的回复逐token流式显示
- 超过3分钟变黄、5分钟变红，内置计时器
- 底部管线日志记录全过程
HTML页面通过一个轻量级的Python代理服务器访问各个agent gateway（8640-8639端口），代理层负责CORS和流式转发的透明处理。无需安装任何npm包，无需框架，一个文件搞定。
实战结果：第9章「年度总结」
重构完成后，我用全流水线跑了第9章（从第8章结束时停留的地方开始）：
| Phase | 耗时 | 结果 |
|---|---|---|
| Phase 1 导演+编剧+研究员 | ~3min | ✅ 3个文件 |
| Phase 2 设定守护审计 | ~2min | ⏸ 修正后绿灯（年龄纠正） |
| Phase 3 写手 | ~6min | ✅ 7,594字 |
| Phase 4 精修+插画 | ~4min | ✅ 16处修改 + 3场景插画 |
| Phase 5 审计师 | ~2min | ✅ 52/60 通过 |
| Phase 6 试读者 | ~30s | ✅ 8/10 |
| Phase 8 终审 | ~2min | 🟢 全管线一致 |
总计约20分钟，零阻塞，全部使用 opencode/deepseek-v4-flash 模型。
教训：Phase 9不能在Phase 4后面
这是整个重构过程中最有价值的发现。最初的管线顺序是精修完就生成正式版（md/txt/html），然后才进审计和试读。这意味着如果审计发现问题、退回修改，正式版已经是一个错误版本了。
正确的顺序：所有质量门禁（审计、试读、终审）通过后，最后一步才生成发布格式。发行版应该是质量保障的终点，不是中间产物。
林薇职业事件：一个设定的代价
这有一个血的教训。小说女主角林薇最初的设定是护士——三甲医院护士，第2章疫情中上前线。这个设定贯穿了Ch1~Ch3的正文（凌晨的夜班、发热门诊、护士字迹、早班交接）。
写到第4章时，我把她改成了中学教师。
于是Ch1~Ch3正文全部需要修改。不是改一个配置——是改几千字的已发布正文：「林薇是护士」→「林薇是中学教师」，「护士的字都这样」→「当老师的字都这样」，「明天我早班」→「明天第一节有课」。
这种全局设定变更在创作中不可避免。但从架构的角度看，问题在于：设定没有独立于正文。如果有一个全局的「林薇职业」设定文件，所有agent都从同一个地方读取——改文件，一次性生效——而不是靠人工逐章检查。
这是我在 agent_profiles.json 的 global_rules 里加入 red_lines 的原因——每章每个agent执行前都必须检查的不可变红线列表。
现状
到现在为止，小说完成了9章（Ch1~Ch9），全管线通过。Ch10正在执行中。整个系统可以从一个配置文件切换推理后端，从一条命令启动全部agent，从浏览器实时观看9个角色的创作过程。
项目地址在本地 C:/Users/Admin/book/，核心组件：
agent_profiles.json— 统一agent配置agent_prompts/*.md— 9个agent的角色定义setup-agents.js— provider切换工具convert-release.js— 格式发布脚本hermes-chat.html— 指挥部实时监控serve-hermes-web.py— 轻量代理服务器
全文完。