Content OS 技术架构文档

本文档描述何庆（heqing@farsthink.com）的 AI 内容生成系统的完整技术架构。 版本：v1.0 | 日期：2026-04-30 | 维护者：Hermes Agent

一、系统概述

Content OS 是一套以 Hermes Agent 为核心调度层的 AI 内容生产流水线。

它的目标很直接：把一个模糊的问题，变成一篇高质量的公众号文章，中间经过多角色对抗辩论、多写手并行创作、资深编辑审校，全流程无需人工介入。

目前已稳定运行，完成 Q003 到 Q030 累计十余篇定稿，覆盖「老实人困境」「短视频」「AI与真相」「独立个体」等主题。

二、系统架构（分层视图）

┌─────────────────────────────────────────────────────────────┐
│                    调度层：Hermes (CEO)                      │
│         理解意图 → 拆解任务 → 调度Agent → 质量验收           │
└─────────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────────────────────────────────────┐
│                    触发层：Trigger Box                        │
│    inbox (待评分) → bank (精选) → cron每小时整点扫描         │
│    8种触发类型：问题/台词/感受/事件/剧集/新闻/历史/场景        │
└─────────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────────────────────────────────────┐
│              Stage 1：鲶鱼激活的对抗辩论层                    │
│                                                              │
│   组1 ──并行── 组2              鲶鱼（轮值）                  │
│  芒格 vs 曾国藩            →   老喻/塔勒布/李诞/              │
│  达里奥 vs 塔勒布              张雪峰/咪蒙                     │
│                              │                               │
│                    强制对抗 → 找共同盲区 → 输出分歧结论        │
└─────────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────────────────────────────────────┐
│              Stage 2：多写手并行创作层                        │
│                                                              │
│   苏小暖 ──情绪共鸣──→ 初稿 ──┐                              │
│   老  陈 ──认知深度──→ 初稿 ──┼──→ 老周审校 → 定稿1（最佳）  │
│   老  高 ──高管真相──→ 初稿 ──┤                              │
│   卡兹克 ──AI圈视角──→ 初稿 ──┴──→ 直接保留 → 定稿2（独立）  │
│                                                              │
│   4个写手全部并行，各自独立，互不等待                         │
└─────────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────────────────────────────────────┐
│              Stage 3：咪蒙爆款标题层                          │
│         8种标题类型 + 40+公式 + 985篇标题语料                 │
│         生成3个备选标题，供发布前选用                          │
└─────────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────────────────────────────────────┐
│                    产出层：定稿仓库                           │
│                                                              │
│   定稿/     ← 老周宣布的最佳稿 + 审校报告                      │
│   定稿2/    ← 卡兹克版，无论评分如何保留                       │
│   materials/ ← Stage1产出（辩论素材）                         │
│   writers/tmp/ ← Stage2初稿（各写手目录）                      │
└─────────────────────────────────────────────────────────────┘

三、核心模块详解

3.1 调度层：Hermes Agent

Hermes 是整个系统的 CEO 和总操盘手。

它的职责不是埋头写代码，而是：

• 理解用户真正的意图（区分表面需求和本质需求）
• 把模糊目标变成清晰战略（定方向、定优先级）
• 拆解任务并调度合适的 Agent 执行
• 控制交付质量（什么是真的完成，什么是假完成）
• 守住用户的认知主权（帮用户看清局势，而不是替用户做决定）

在 Content OS 里，Hermes 的具体工作是：

1. 读取 bank.md 找到待触发问题
2. 计算鲶鱼轮值
3. 调度多组辩论并行执行
4. 收集辩论素材后分发给4个写手
5. 汇总初稿交给老周审校
6. 把最佳稿移制定稿目录
7. 更新 bank 状态

3.2 触发层：Trigger Box

Trigger Box 是统一的输入入口，取代了早期的 question-box。

8种触发类型：

流转机制：

inbox.md (新素材) → 评分 → bank.md (精选) → cron每小时扫描 → 流水线

bank.md 里的每条问题包含：

• Q编号（唯一标识）
• 问题正文
• 触发类型
• 触发角色（决定4智者组合）
• 状态（📋待触发 / ✅已触发）
• 可选：鲶鱼字段（手动指定覆盖轮值）

3.3 Stage 1：鲶鱼激活的对抗辩论层

这是整个流水线质量最高的节点，也是最有特色的设计。

为什么需要对抗辩论？

内容工厂的核心假设是：真正有价值的不是素材本身，而是智者之间产生的分歧点。这个分歧就是文章的骨架和张力所在。

如果4个智者各自亮完观点就结束，输出的只是"四段读后感"，写手照着素材写出来的也是综述感，没有内在张力。

结构设计（v2.1+）：

Step 1: 组1辩论（芒格 + 曾国藩）
Step 2: 组2辩论（达里奥 + 塔勒布）
         ↓ 并行执行，不放一个prompt里
Step 3: 鲶鱼反驳（Q%5轮值，至少反驳2个观点）
         ↓
合并输出：核心分歧结论 + 文章骨架建议

鲶鱼池（5人轮值）：

Q%5 = 0 → 老喻（概率算法、人生算法）
Q%5 = 1 → 塔勒布（反脆弱、风险杠精）
Q%5 = 2 → 李诞（嘴毒解构、荒诞现实）
Q%5 = 3 → 张雪峰（教育现实主义）
Q%5 = 4 → 咪蒙（情绪传播、爆款直觉）

bank.md 可手动指定 鲶鱼：字段覆盖轮值。

鲶鱼的核心价值：不是打倒某个人，而是找到"所有人都在讨论但没人说透"的那层窗户纸。

实战教训（Q030）：老喻发现"所有人讨论'是否展示'，没人讨论'何时展示'"——这个共同盲区被三个写手全部当核心论点写，效果极好。

3.4 Stage 2：多写手并行层

4个写手，各有分工：

并行机制：4个写手同时开工，互不等待。每批最多3个并发（delegate_task 默认限制）。

卡兹克的独立通道：卡兹克的稿子不参与老周评分竞争，无论评分如何直接保留为「定稿2」。原因：卡兹克的读者是AI从业者，有自己独立的价值维度，和通用公众号稿的评价体系不同。

3.5 审校层：老周

老周，52岁前《十月》《三联》首席编辑，内容工厂的「总编室」。

职责：

• 审校苏小暖/老陈/老高三篇初稿
• 宣布本轮最佳稿
• 检查虚构引用（这是 v2.2.1 新增的专项审查）
• 对卡兹克稿提供技术准确性点评（仅供参考，不参与竞争）

虚构引用专项：所有「XX（名人）说：...」格式的引用必须可查证。典型要警惕的模式：

• 「芒格说：展示功劳是一种逆向激励」（疑似虚构）
• 「曾国藩说：沉默是金」（后人附会，非原文）

3.6 咪蒙爆款标题层

基于985篇咪蒙标题分析蒸馏出的标题操作系统。

8种标题类型：

核心发现（反直觉）：顶级爆款64%是纯陈述句，感叹句是辅助钩子而非主力。

3.7 产出层：定稿仓库

/mnt/d/hqking/
├── trigger-box/
│   ├── bank.md          ← 精选问题库
│   ├── inbox.md         ← 待评分素材
│   └── archive.md       ← 已触发归档
├── materials/           ← Stage1产出（辩论素材）
├── writers/
│   ├── tmp/suxiaonuan/  ← 苏小暖初稿
│   ├── tmp/laochen/     ← 老陈初稿
│   ├── tmp/laogao/      ← 老高初稿
│   ├── tmp/khazix/      ← 卡兹克初稿
│   ├── editorial/       ← 老周审校稿
│   ├── 定稿/             ← 最佳定稿 + 审校报告
│   └── 定稿2/            ← 卡兹克版（独立保留）
└── question-box/
    └── factory.log      ← 流水线运行日志

四、安装与启动

4.1 环境要求

• 系统：WSL（Windows Subsystem for Linux）或 Linux
• Hermes Agent：v0.10.0+
• Python：3.11+
• uv：包管理器
• API Key：MiniMax CN API（配置在 ~/.hermes/.env）

4.2 安装步骤

Step 1：克隆 skills 仓库

skills 仓库托管在 GitHub + Gitee 双平台：

# GitHub
git clone git@github.com:wuqing1982/hermes-skills.git ~/.hermes/skills/skills

# 或 Gitee（国内更快）
git clone git@gitee.com:hqking22/hermes-skills.git ~/.hermes/skills/skills

Step 2：安装核心依赖

skills 目录结构：

~/.hermes/skills/skills/
├── content-factory/        ← 核心流水线skill
├── khazix-writer/          ← 卡兹克写手skill
├── mimeng-skill/           ← 咪蒙内容方法论
├── mimeng-title-skill/     ← 咪蒙爆款标题
├── perspective/            ← 智者人物profile
│   ├── munger-perspective/
│   ├── taleb-perspective/
│   ├── zeng-guofan-skill/
│   ├── dalio-principles-skill/
│   └── ...
└── senior-editor/          ← 老周审校skill

Step 3：配置 API Key

# 编辑环境变量
nano ~/.hermes/.env
# 添加：MINIMAX_CN_API_KEY=sk-cp-xxxxx

Step 4：配置定时任务（可选）

每小时整点自动扫描 bank 并触发流水线：

# 查看当前cron
cronjob list

# 创建新job
cronjob create \
  --name "Content Factory Cron" \
  --schedule "0 * * * *" \
  --prompt "执行Content Factory流水线。读取/mnt/d/hqking/trigger-box/bank.md，找到第一个📋待触发的问题，跑完整流水线（Stage1辩论→Stage2写手→Stage3标题→定稿→bank状态更新）。完成后汇报结果。" \
  --skills content-factory

4.3 手动启动流水线

两种方式：

方式1：Hermes 对话触发

用户：跑流水线
Hermes：读取bank.md → 找到待触发问题 → 调度Stage1 → Stage2 → Stage3

方式2：直接执行

# 找到待触发问题
# bank.md 中状态为「📋待触发」的第一条
 
# 手动跑Stage1（辩论）
# 调用 delegate_task 并行执行组1+组2辩论
 
# 手动跑Stage2（写手）
# 调用 delegate_task 并行执行4写手
 
# 手动跑Stage3（审校+标题）
# 调用老周审校 skill

五、运转机制

5.1 完整流水线时序

用户/定时触发
    │
    ▼
Hermes 读取 bank.md
    │  找到第一个📋待触发问题
    ▼
计算 Q%5 确定鲶鱼轮值
    │
    ├──▶ Stage1-A: 组1辩论（芒格+曾国藩）
    ├──▶ Stage1-B: 组2辩论（达里奥+塔勒布）
    │          ↓ 并行，约5分钟
    ├──▶ Stage1-C: 鲶鱼反驳（至少2个观点）
    │          ↓ 约2分钟
    ▼
合并辩论素材（核心分歧+骨架建议）
    │
    ├──▶ 写手1: 苏小暖 ──并行── 写手2: 老陈
    ├──▶ 写手3: 老高        ──并行── 写手4: 卡兹克
    │          ↓ 约8分钟
    ▼
老周审校（前3篇） + 卡兹克直接定稿2
    │
    ▼
移制定稿/ + 更新bank状态 + 咪蒙标题
    │
    ▼
流水线完成

总耗时：约 20-30 分钟（视素材复杂度）

5.2 质量控制机制

三层质量门：

L1 硬性规则：禁用词扫描、禁用标点扫描、结构性套话扫描

• 执行者：各写手在提交前自检

L2 风格一致性：开头检查、节奏检查、口语化检查

• 执行者：卡兹克使用四层自检体系

L3 资深编辑审校：老周逐篇审查，标注错误，宣布最佳

• 执行者：老周（52岁前首席编辑）

虚构引用专项：逐篇检查名人引用是否可查证

• 执行者：老周（v2.2.1+ 新增）

六、核心优势

6.1 对抗性辩论设计

大多数 AI 内容系统是"单源输入 → 单篇输出"。Content OS 的差异在于强制产生分歧，通过两组辩论 + 鲶鱼反驳，逼出智者之间的真正张力。

这个分歧张力就是文章的骨架。没有对抗，就没有张力；没有张力，文章就平。

6.2 多写手并行竞争

4个写手同时写同一个主题，最终只选最佳——这是竞争性创作。老周不是帮写手改稿，而是裁判，选出本轮最优秀的篇目。

卡兹克的独立通道设计也很有价值：AI从业者这个细分读者群，和通用公众号的读者需求完全不同，独立通道保护了这种独特性。

6.3 鲶鱼轮值机制

Q%5 轮值 + bank 手动覆盖，这个设计兼顾了自动化和灵活性。自动化保证不会忘记哪个鲶鱼该上场，手动覆盖让运营者可以在关键时刻指定特定角色。

6.4 智者的真实画像

不是通用大模型随机生成的"智者观点"，而是用真实著作、访谈、演讲蒸馏出的人物 Skill。芒格就是芒格，塔勒布就是塔勒布，有自己的认知框架、表达方式和决策启发式。

这是系统的护城河——素材质量的上限由智者 Skill 的深度决定。

6.5 完整的产出追踪

bank.md 状态管理 + factory.log 日志，让运营者随时知道：

• 哪些问题跑过了，哪些还没跑
• 每篇定稿的产出路径
• 流水线的运行历史

七、劣势与风险

7.1 辩论层容易退化

这是目前系统最脆弱的环节。设计上要求"芒格质疑曾国藩的某个前提"，但实际执行中，子 agent 倾向于"各自亮完观点就结束"。

退化模式：4个角色的发言变成"四段独立读后感"，没有真实交锋。

判断标准：检查素材文件里有没有芒格直接反驳另一方的对话结构。如果只有各段独立发言，说明退化发生了，需要重来。

修复方向：

• P1（轻量）：强制输出"核心分歧结论"作为验收标准
• P2（中等）：按话题类型动态分组而不是固定分组
• P3（重量）：两两对话三轮，强制产生分歧

7.2 虚构引用风险

这是最隐蔽的质量风险。写手在创作时可能无意中捏造名人语录，比如编一句"芒格说：展示功劳是一种逆向激励"——这句话听起来很有道理，但芒格从来没说过。

v2.2.1 已经加了专项审查，但这仍然需要老周高度警觉。

7.3 Token 成本较高

一次完整流水线大约需要：

• Stage1 辩论：~20000 tokens
• Stage2 4写手：~80000 tokens
• Stage3 审校：~30000 tokens
• 合计：~130000 tokens / 每次

每月跑30次，Token消耗约390万。这在可接受范围内，但需要关注成本控制。

7.4 老周的单点瓶颈

老周是整个流水线的唯一审校节点。如果老周的判断有偏差，或者老周因故缺席，整个流水线就停摆。

可以考虑：

• 多审校 Agent 并行（不同审校者竞争）
• 建立老周的评判标准手册，减少主观偏差

7.5 热点响应延迟

每小时扫描 bank，但 bank 是手动维护的。如果出现突发热点，需要人工把问题丢进 inbox → 评分 → bank 才能触发流水线。

热点抓取目前没有自动化，是待开发的功能。

八、对系统的理解

Content OS 是什么，不是什么

Content OS 是工具，不是替代者。

它的定位不是"取代人写文章"，而是"把人从重复性创作中解放出来"，专注于真正的决策和判断。

系统最核心的价值不在于"4个写手并行"，而在于对抗性辩论层——那才是真正的差异化所在。素材里的分歧张力，需要通过对抗性辩论才能被挖掘出来。

没有对抗辩论的流水线，就只是"多个人帮我写"，而不是"系统帮我思考"。

设计哲学

系统的设计哲学是：让噪音变成信号，让模糊变成框架，让碎片变成张力。

• Trigger Box 把各种形态的输入（问题/台词/事件/感受）统一成标准格式
• 4智者对抗辩论把杂乱的观点变成有骨架的分歧结论
• 多写手竞争把"写得差不多"变成"写得最好"
• 老周审校把"写完就发"变成"值得发布"

每一步都在做减法——去掉噪音，保留信号。

系统的局限

AI 内容工厂的核心局限在于：它擅长组合，不擅长创造；擅长执行，不擅长判断。

对抗性辩论能逼出张力，但张力的方向还是要靠人把握。 多写手能并行创作，但写什么角度还是要靠人决策。 老周能选出最佳稿，但最佳的标准还是要靠人定义。

Content OS 是强大的执行机器，但判断力永远在人的那端。

九、未来发展方向

9.1 辩论层的强化

方向A：强制收敛机制

不是让4个角色自由辩论，而是在适当时候强制收敛。比如：

• 第一轮：各自亮立场
• 第二轮：两两碰撞（强制）
• 第三轮：收敛到"最多人认同的反对意见"
• 鲶鱼：指出所有人的共同盲区

方向B：动态分组

不是固定（芒格+曾国藩 / 达里奥+塔勒布），而是根据问题类型动态选择组合。

问题涉及风险/不确定性 → 优先选塔勒布 + 老喻 问题涉及长期决策 → 优先选芒格 + 曾国藩 问题涉及组织管理 → 优先选段永平 + 达里奥

方向C：鲶鱼的 AI 评审

对鲶鱼的输出跑一次 LLM 评审：这段反驳是否真的产生了新张力？如果鲶鱼只是在重复已有的观点，降低其权重或要求重来。

9.2 热点自动抓取

目前是手动往 inbox 丢素材。未来可以：

微博热榜 API → 关键词过滤 → 自动生成选题候选 →
inbox自动评分 → 高分自动进bank → 触发流水线

这个功能有实操价值，但需要处理：

• 热点保鲜期短（2-4小时），流水线20-30分钟偏慢
• 自动选题质量不稳定，需要人工审核

9.3 公众号发布自动化

流水线最后一公里：定稿 → 草稿箱 → 发布。

目前是半自动（Playwright 脚本待开发）。这环打通后，整个流水线才算真正闭环。

9.4 素材库的扩展

目前 bank.md 有23个精选问题，素材库还很薄。

扩展方向：

• 按领域分类（职场/情感/认知/商业/科技）
• 按难度分级（简单观点型/复杂辩论型/深度分析型）
• 按受众分类（打工人/创业者/AI从业者/学生）

9.5 读者反馈闭环

目前流水线是单向的：bank → 流水线 → 定稿 → 发布。没有反馈。

可以建立读者反馈追踪：

• 哪篇定稿阅读量最高
• 哪篇评论最多
• 读者在讨论什么

这些数据可以反过来影响 bank 的选题权重——让系统越跑越懂什么选题值得做。

9.6 语音入口

目前的入口是 Hermes 对话或 cronjob 定时。可以加一个语音入口：

用户发一段语音 → Whisper 转文字 → 自动解析意图 → 丢进 inbox

这让 Content OS 的入口从"打字"变成"说话"，降低使用门槛。

十、附录

A. 核心文件索引

B. 流水线版本历史

C. 相关人物 Skill 清单

文档版本：v1.0 最后更新：2026-04-30 维护者：Hermes Agent (heqing@farsthink.com)