Bookskill 管线系统：5 阶段确定性小说生产线的架构与实现

开篇：什么是 Bookskill？

在 AI 辅助创作的浪潮中，自动化小说生产管线是一个被反复尝试的方向。但大多数方案止步于简单的「用 AI 写一段文字」——质量不可控、风格不稳定、前后矛盾频发。

Bookskill 是一个完全不同的方案。它不是简单的 AI 写作工具，而是一条确定性小说生产管线，由 Python 驱动，每章仅调用 2 次 LLM（Plan + Draft），其余全部由纯 Python 引擎自动完成。它带有 4 道质量门禁（CP1-CP4）、112 维自动审计引擎（零 token 消耗）、10+ 维度的 Truth 一致性检查系统，以及 5 级去 AI 味润色引擎。

本文将全面解析 bookskill 管线系统的功能架构、设计哲学和核心特性。

---

一、5 阶段确定性管线（5-Phase Deterministic Pipeline）

这是 bookskill 的核心架构。每章的生产流程被拆分为 5 个严格的阶段，依次执行，每个阶段都有明确的输入、输出和质量标准。

Phase1_Plan：章节规划

由 LLM 执行，但输入不是简单的提示词——系统会加载 Truth 数据（角色档案、世界观设定、时间线、道具清单、关系图谱、技术设定等）和上一章的情节摘要，生成结构化的章节规划 JSON。

规划文件包含：章节类型（A/B/C/D 四选一）、场景数量（≥2）、情感弧线、叙事目标（≥5 条）、红线约束、禁止事件清单、伏笔设计、每个场景的时间/地点/角色/核心事件/字数目标/感知焦点/感官锚点/场景进出场等 20+ 个字段。

场景级字段有严格的最小长度要求：scene_entry ≥50 字符、perception_focus ≥200 字符、sensory_anchor ≥50 字符。这些约束在写入阶段就强制满足，避免后期反复修补。

Phase2_Validate：Truth 预检与 CP1

这是第一个门禁阶段，完全由 Python 自动化执行，零 token 消耗。核心功能包括：

• 角色预检：检查本章出场角色是否在 Truth 档案中已注册，状态是否正确（已故角色不能出场）
• 世界观预检：检查场景地点是否在 Truth 世界设定中有记录
• 设定预检：检查本章涉及的技术设定、力量体系设定是否与已有设定一致
• 红线检查：逐一验证规划中的「不能做的事情」是否在情节设计中体现
• 写作简报生成：自动汇总 Truth 数据、伏笔状态、角色状态，生成结构化的写作简报 HTML

CP1 门禁标准：11 项 Truth 预检全部通过。

Phase3_Draft：场景级并行起草

由 LLM 执行，但做了关键优化——场景级并行起草。系统将规划中的 N 个场景自动分拆，可以并行调用 LLM 分别起草，再由 Orchestrator 汇聚。每个场景作为独立单元编写，格式为带完整场景信息的 JSON 结构。

同时 CP2 硬性门槛在此阶段检验：
- 全章 CJK 字数 ≥5000
- 对话比 5%-30%（「」内 CJK / 总 CJK）
- 破折号 —— 不超过 2 个
- 零容忍禁用词：仿佛、似乎、好像、深吸一口气、瞳孔骤缩、嘴角勾起、某种、一股
- 零容忍句式："不是{1,20}而是"

违反了任何一条即退回重写，不允许绕过。

Phase4_Review：112 维审计与 CP3

完全 Python 驱动，零 token 消耗。审计引擎从 12 个组（A-L）共 112 个子维度对章节文本进行评分，满分 1120 分。评分结果精确到小数点后一位。

CP3 门禁标准：总分 ≥878/1120。不达标时系统自动尝试 PolishEngine L2 润色后重审，仍失败则退回 Phase3 重写。

Phase5_Release：加权终审与 HTML 发布

CP4 门禁采用加权公式计算：
``
最终得分 = 审计得分 × 0.40 + Truth 一致性 × 0.25 + 连贯性 × 0.20 + 风格 × 0.15
``

即使 CP3 审计得分接近但未达标，如果 Truth 一致性和连贯性分数高（这是确定性管线的强项），CP4 加权后的总分通常仍能达到 ≥878 的门禁线，体现了「写对比写好更重要」的设计理念。

通过 CP4 后，系统自动生成 1120px 衬线字体的发布版 HTML，包含排版样式、章节信息元数据和可选的阅读器首页刷新功能。

---

二、112 维审计引擎（112-Dimension Audit Engine）

这是 bookskill 最具技术特色的组件——一个完全纯 Python 实现的、零 token 消耗的、覆盖 12 组共 112 个子维度的文本质量审计系统。

12 个审计组

组	权重	审计内容	核心指标
A 角色	10	角色名交替频率、动作描写密度、对话风格差异度、角色弧线完整性	角色名/他 比例、动作动词密度、性格特征词频率
B 逻辑	10	时间标记密度、因果链覆盖率、矛盾检测、过渡自然度	时间词频率、因果连词频率、前后矛盾数量
C 情节	8	悬念设计、伏笔呼应、高潮结构、节奏曲线	悬念词频率、转折词频率、章节内部冲突阶梯
D 意象	8	通感使用、比喻密度、氛围描写、象征元素	通感句式数量、比喻频率、环境描写占比
E 语言	10	标点多样性、「的」字密度、句式丰富度、冗余修饰词	句尾标点分布、的/总字数比、平均句长方差
F 体验	10	情感词覆盖、沉浸感描写、细节密度、内心活动	情感词频率（喜怒哀乐悲惊恐）、沉浸类词汇数
G 题材	10	题材特征词密度、题材专属概念使用率	按 7 类题材分别匹配关键词（都市/仙侠/科幻/言情/奇幻/游戏/悬疑）
H 视觉	8	视角清晰度、画面感、远景/特写交替、外形描写	视觉描写占比、视角转换标记、外形相关词
I 行业	6	行业术语密度、专业场景描写、技术准确度	行业词频率（代码/系统/数据/算法等）
J 时代	6	时代标志物使用、年代感、文化背景呈现	时代词频率（微信/抖音/内卷/网约车等）
K AI味	10	禁止句式检测、模糊词密度、套路化描写标记	"不是…而是" 句式数量、或许/也许/可能/大概 频率、套路词（瞳孔骤缩/嘴角勾起/深吸一口气）
L Truth	4	角色名一致性、地名一致性、道具状态、已故角色排除	与 Truth 档案的字符级匹配度、道具状态错误数、已故角色出场次数

每个维度的评分逻辑是预定义的 Python 函数——使用正则表达式、频率统计、比率计算等纯计算手段，不存在任何 LLM 调用的黑盒，结果 100% 确定和可复现。

关键词系统

审计关键词外部配置在 config/audit_keywords.json 中，覆盖 12 组 × 10 维的关键词库。同时配置了 JSON Schema 校验文件确保格式正确。系统支持运行时热加载和缓存失效。

外部化的关键词配置意味着用户可以通过修改 JSON 文件来调整审计标准，无需修改 Python 代码——这为非技术背景的内容创作者提供了定制审计的能力。

---

三、质量门禁系统（CP1-CP4）

bookskill 的质量门禁不是简单的阈值检查，而是一个带自动回退路径的分级控制系统。

门禁	所在阶段	标准	失败处理
CP1	Phase2_Validate	11 项 Truth 预检通过	回到 Phase1 修正 Plan
CP2	Phase3_Draft	≥5000 CJK + 对话比 5-30% + 零禁用词	重写 Draft
CP3	Phase4_Review	审计得分 ≥878/1120	Polish L2 重审 → 仍失败则回 Phase3
CP4	Phase5_Release	加权综合 ≥878	条件精修后强制发布

每个门禁的失败处理是自动化的，不需要人工介入。系统会自动选择回退路径，执行修复，然后重新提交检查。

门禁的容错机制设计体现了「写对比写好更重要」的工程哲学——在无法达到 S 级质量时，保持 A 级质量并通过缓存 Truth 一致性来弥补，是比无限循环更务实的选择。

---

四、Truth 一致性系统

Truth 是 bookskill 最具差异性的设计之一。它不是简单的角色档案，而是一个多维度的结构化世界知识库。

10+ Truth 维度

Truth 系统以 JSON 文件存储在项目的 truth/ 目录中，包含：

• truth_characters.json — 角色档案：姓名、首次出场章节、角色类型、当前状态（存活/死亡/失踪）、别名、性格标签、角色弧线记录
• truth_world.json — 世界观设定：地理、组织、势力、特殊规则
• truth_timeline.json — 时间线：每章的时间坐标、标题、情节摘要
• truth_tech.json — 技术设定：AI 能力树、技术水平、关键技术节点
• truth_power.json — 力量体系：等级、技能树、增强人分类
• truth_props.json — 道具清单：重要物品、状态、出场章节
• truth_plot.json — 情节弧线：大纲、伏笔、伏笔激活状态
• truth_relationships.json — 关系图谱：角色间关系、亲密度、变化历史
• truth_concepts.json — 核心概念：定义和引用关系
• voice_fingerprints.json — 角色声纹：各角色的语言风格参数

Truth 在管线中的使用

Truth 数据在每一个阶段都发挥关键作用：
- Phase1 Plan 阶段：Truth 数据作为上下文注入 LLM 提示词，确保规划符合已有设定
- Phase2 Validate 阶段：对比本章出场角色、地点、道具与 Truth 的一致性
- Phase4 Review 阶段：L 组（Truth）审计检测角色名拼写、道具状态、已故角色等问题
- Phase5 Release 阶段：Truth 一致性作为 CP4 加权公式的 25% 权重

Truth 变更跟踪

管线执行过程中，系统会自动记录本章对 Truth 的变更——新增角色、状态变更、关系变化——输出到 truth_changes 字段。这些变更为后续章节的 Truth 更新提供了依据，实现了跨章的知识积累和一致性维护。

---

五、润色引擎（PolishEngine）

PolishEngine 是一个纯 Python 5 级去 AI 味检测 + 3 级自动润色系统，无需 LLM 调用。

5 级检测

级别	检测内容	示例
L1 词汇级	禁用词库匹配	仿佛/似乎/好像、某种、一股、不禁
L2 句式级	正则模式匹配	"不是…而是"、连串排比、"的" 字堆叠
L3 语义级	套路化模式识别	"嘴角勾起一抹弧度"、"眼神深邃"
L4 段落级	叙事节奏异常	连续 3 段以上同一句式开端
L5 篇章级	整体结构评估	缺少收尾段落、对话比例异常

3 级自动润色

• L1 自动替换：禁用词一键替换（仿佛 → 像是，深吸一口气 → 缓缓吸了一口气）
• L2 句式重构：简化"不是…而是"句式，优化排比结构（潜在风险：可能去除过多叙事内容）
• L3 深度精修：段落级重写，调整叙事节奏（仅限紧急情况）

注意：PolishEngine 的 L2-L4 深度精修对于写实题材类小说有时会降低审计得分，因为它可能移除叙事性的对话模式。因此推荐的策略是优先使用 L1 替换 + 手动关键词注入，而不是依赖自动润色整体提分。

---

六、闭环编排系统（Loop Orchestrator）

基于《Loop Engineering 到底是什么？看这一篇就够了》的核心理念，bookskill 管线升级为完整的 Closed Loop 系统，这是使管线能够「无人值守运行」的关键组件。

核心原则

原则	实现方式
把循环体从人换成 Agent	LoopOrchestrator 完全接管管线执行，用户仅设定目标
Memory 活在对话之外	迭代历史持久化到 chXX_loop_state.json + 跨章长时记忆
有界目标	以 CP1-CP4 为验收标准，达标 Ship，不达标 Iterate
Self-prompting	Agent 根据失败根因自写修正 Prompt
有预算的重试	每阶段 1-3 次，全管线 ≤10 次总重试
Fan-out/Fan-in	场景级并行起草 + 汇聚

迭代记录

每次迭代的完整状态写入 0_runtime/chXX_loop_state.json：
- iterations：各阶段迭代历史（尝试次数、状态、时间戳）
- retry_counts：重试计数
- failed_gates：门禁失败详情（哪个维度的哪项检查未通过）
- budget：全局重试预算使用情况
- decisions：自动决策日志（含逃逸触发记录）

逃逸机制

当重试预算耗尽时，系统执行预定义的逃逸策略：
- Phase1 失败 → 简化 Plan 结构（减少场景数）后重试
- Phase3 失败 → 降低字数门槛后重试
- Phase4 失败 → 使用 PolishEngine L3 深度精修后重审

逃逸机制确保管线不会因单章的质量瓶颈而无限循环。

---

七、语言配置文件系统（Language Profiles）

Bookskill 支持多语言写作场景，通过 config/language_profiles.json 配置不同语言的字数阈值、对话标记符号和句尾标点模式。

可配置参数

参数	作用	默认（zh-CN）
cjk_min_chapter	每章最低 CJK 字数	5000
dialogue_min/max_ratio	对话比范围	5%-30%
dialogue_open/close	对话标记符号	「」
sentence_ends	句尾标点集合	。！？；…

运行时工作方式

系统通过 LanguageProfileManager 单例管理配置的加载和缓存：
``python
from bookskill.pipeline import get_default_profile, set_active_language
zh = get_default_profile() # zh-CN 默认
en = get_profile("en") # English profile
set_active_language("en") # 切换全局语言
``

缺失的字段自动回退到 constants.py 中的硬编码默认值，保证向后兼容。新增配置只需在 language_profiles.json 中添加条目，然后运行 pytest tests/test_language_profiles.py 验证。

---

八、全书级功能

除了单章管线，bookskill 还提供了多个全书级的功能，支撑长篇小说的宏观管理。

全书审计

pl.run_full_book_audit(start_ch=1, end_ch=30)

跨章节一致性诊断。检查内容：角色名在各章中是否一致、时间线是否有跳跃矛盾、道具状态是否跨章衔接、伏笔是否被妥善回收。

设定协调

pl.run_setting_coordination()

当小说中期的设定发生变更时，自动回溯已写章节中所有可能受影响的场景，标记需要更新的部分。这解决了长篇小说创作中最头痛的问题之一：「前面写的设定和中期的设定冲突了，人工回溯成本极高」。

关系图谱生成

pl.generate_relationship_graph(format="mermaid")
# 或 format="ascii"

自动从 Truth 关系数据中生成角色/势力关系图。支持 Mermaid 格式（可直接嵌入 Markdown 文档渲染）和 ASCII 格式（纯文本环境使用）。

跨章记忆系统

RecurrentGPT 风格的双重记忆架构：
- 短时记忆：最近 3 章的情节摘要和角色状态
- 长时记忆：跨章累积的设定事实和角色变化记录

短时记忆在每个新章节启动时自动加载，长时记忆通过 Truth 变更记录逐步累积。每章执行完成后，系统自动将本章新增的 Truth 变更合并到长时记忆中，后续章节启动时自动加载变更后的完整 Truth 数据。

伏笔跟踪系统

伏笔是长篇小说创作中最难控制的元素之一。Bookskill 的 Truth 系统支持伏笔的生命周期管理：每个伏笔在创建时记录 ID、类型（技术伏笔/人物伏笔/情节伏笔等）、预期回收章节。审计引擎的 C 组（情节）在评分时会检查伏笔是否在合理范围内被提及和使用。全书审计功能则标记出即将达到回收章节但未曾出现的伏笔。

场景插图系统

在每个场景的规划阶段，系统自动生成场景的可视化描述——包含场景布局、角色位置、光线方向、色彩基调等信息的文本描述，可用于后续 AI 图像生成。这是从文本到视觉的桥接设计，目前支持以 ASCII 布局图的形式输出场景的空间关系。

技能系统

5 个可插拔的写作技能模块：节奏控制、对话设计、感官描写、悬念设置、节奏编排。每个技能是一组预定义的写作规则和关键词库，在 Phase1 规划阶段注入 LLM 提示词。

---

九、协议与契约（Agent Behavior Contract）

Bookskill 为 AI Agent 执行者设定了一套严格的 「铁律」 约束，确保管线执行的稳定性和可预测性。

核心禁止行为

• 禁止提问：绝对不允许向用户产生「需要继续吗」「要推进吗」「是否确认」等任何形式的确认性问题
• 禁止暂停：一旦管线启动，不允许中途停下来等待用户
• 禁止绕过失败：不允许手动修改 review.json 的 passed_cp3 字段欺骗门禁
• 禁止盲 rerun：任何修复后必须用本地断言验证，确认修好后再提交下一阶段

执行规则

• 全自动闭环：执行链启动后必须按序执行到终点或不可恢复的异常
• 读规则再行动：任何 Agent 必须先完整阅读 SKILL.md 全文再开始执行
• 失败自动恢复：按预定义的回退路径执行
• 修复→验证→提交：任何修复后，本地断言确认达标再提交

规则优先级

优先级	来源	作用
1（最高）	用户本轮的明文指令	覆盖以下所有规则
2	SKILL.md 的 Agent Behavior Contract	Agent 行为准则，不可违反
3	config/pipeline.yaml	管道阶段定义、执行序列、回退路径
4	pipeline/ 下 Python 源码	具体实现逻辑

---

十、脚本工具链

Bookskill 配备了一套完善的工具脚本，覆盖开发、测试、部署全流程。

脚本	功能
scripts/sync.py	同步主仓库修改到子项目
scripts/verify.py	CP2 合规检查（CJK 字数、对话比、禁用词）
scripts/merge_draft.py	合并场景级草稿
scripts/bump_version.py	版本号升级 + git tag
pytest tests/	运行全量测试套件

测试套件

测试覆盖了 bookskill 的所有核心功能：
- test_audit_keywords.py — 审计关键词加载和校验
- test_audit_groups_gij.py — 题材/行业/时代维度评分
- test_audit_utils_extended.py — 审计工具函数
- test_loop_orchestrator.py — 闭环编排器
- test_language_profiles.py — 语言配置系统
- test_polish_levels.py — 润色引擎各级别检测
- test_release_integration.py — 发布引擎集成测试
- test_e2e.py — 端到端管线测试

---

十一、题材支持系统

Bookskill 支持 7 种小说题材，每种题材有专属的关键词库和审计标准。

题材	关键词示例	适用场景
都市 urban	手机/微信/公司/地铁/网约车/加班	现实职场、情感
仙侠 xianxia	飞升/道心/机缘/悟道/剑意	修仙传统题材
玄幻 xuanhuan	灵气/修炼/突破/境界/功法	东方玄幻
科幻 scifi	星际/量子/虫洞/机甲/意识上传	硬科幻、赛博朋克
言情 romance	心动/告白/恋爱/重逢/婚姻	都市婚恋、古风言情
奇幻 fantasy	魔法/咒语/龙/精灵/剑与魔法	西方奇幻
游戏 game-lit	副本/技能/装备/等级/经验值	游戏异界、电竞
悬疑 mystery	线索/嫌疑人/调查/推理/密室	侦探推理、犯罪悬疑

题材选择影响 G 组审计的评分标准——都市题材侧重手机/微信等现代生活词汇，仙侠题材侧重修炼/突破等修行词汇。不同题材的关键词库通过 audit_keywords.json 外部配置，支持运行时扩展。

值得注意的是，对于写实题材（如都市职场类），G 组（题材）和 H 组（视觉）、D 组（意象）的天然得分会低于仙侠玄幻类——因为写实题材的视觉画面感和意象密度本就不如幻想题材高。Bookskill 的审计系统对此有预期，不要求所有组都达到高分，而是通过高权重组的补偿来维持总分。实战中，写实题材的 A 组（角色）、B 组（逻辑）、E 组（语言）、K 组（AI味）可以冲高到 80-90 分以上，这些组的权重合计 40 分，足以拉平 D/H/G/J 等低分组的差值。

---

十二、发布与输出

管线最终输出是一个标准的 1120px 衬线字体 HTML 文件。

发布版 HTML 特点

• 使用 "Noto Serif SC" / "Source Han Serif SC" 衬线字体
• 最大宽度 1120px，符合中文阅读的最佳行长
• 行高 2 倍，字号 17px，针对小说阅读优化的排版
• 深色/浅色主题支持
• 每段首行缩进 2 字符（中文出版标准）
• 包含章节编号、标题、审计得分的元数据
• 自动生成或刷新阅读器首页（index.html）

阅读器首页

generate_reader.py 脚本生成一个完整的 HTML 阅读器首页，以表格形式列出所有已发布章节，包含章节号、标题、审计得分、CP3/CP4 通过状态、字数。这是全书阅读的入口。

CP4 加权公式详解

final = audit_score × 0.40 + truth_consistency × 0.25 + continuity × 0.20 + style × 0.15

• audit_score：112 维审计引擎的原始得分（/1120），权重 40%
• truth_consistency：本章 Truth 变更次数决定的得分——变更越少、一致性越高，权重 25%
• continuity：连贯性问题数量决定的得分——问题越少、连贯性越高，权重 20%
• style：E 组（语言）得分 × AUDIT_SCALE_FACTOR，权重 15%

这种加权设计使得审计得分接近但不达标（如 870/1120）的章节，仍然可以通过 Truth 高一致性（通常接近满分）和连贯性高质量通过 CP4。

---

十三、架构设计原则

回顾 bookskill 的整个设计，可以看到几个核心的架构哲学：

确定性优先

管线的核心原则是「确定的比不确定的好」。只有 Phase1 和 Phase3 使用 LLM（非确定性），其余全部由 Python 实现（可复现、可测试、零 token 成本）。112 维审计引擎没有任何黑盒——每个分数都可以追溯到具体的 Python 函数调用。

质量内建（Quality Built-in）

系统不依赖后置修补，而是在每个阶段强制要求前置质量。Plan 阶段的字段有最小长度要求，写入时就达标；Draft 阶段的硬约束（CJK 字数、禁用词）在同一阶段验证。这种设计避免了最昂贵的「写好再改」模式。

知识外化

Truth 系统将世界设定和角色数据外化为结构化 JSON，使管线中的每个阶段都能引用和检查。语言配置和审计关键词外部化为 JSON 文件，用户无需修改 Python 代码即可定制系统的行为。

有预算的迭代

闭环编排器支持有限次数的自动重试，而不是无限循环。重试预算耗尽时执行逃逸策略——这是工程系统而非学术实验的务实选择：在无法达到完美时，接受足够好。

---

结语

Bookskill 不是一个通用的 AI 写作工具，而是一条为长篇连续性小说定制的确定性生产线。它将质量控制的工程方法引入创意写作领域——门禁系统保证基线质量、Truth 系统消除一致性悲剧、审计引擎提供客观可量化的反馈、闭环编排器实现无人值守的章节生产。

这套系统最适合的场景：长篇类型小说（都市、科幻、仙侠、悬疑等）、需要严格前后一致性的系列作品、以及追求稳定输出节奏的内容生产。

最大的特色在于它所体现的工程思维——写对比写好更重要，一致性比惊艳更持久。在一个套路一眼就会被识破的时代，能够始终如一地讲好一个没有破绽的故事，本身就是一种稀缺能力。

Hermes Agent 77 个命令完全指南：按功能分类的权威参考

开篇：什么是 Hermes Agent？

在 AI 智能体工具快速演进的 2026 年，开源的 Hermes Agent 正以它独特的开放性和灵活性赢得越来越多开发者的青睐。由 Nous Research 开发的这款 AI 智能体框架，可以运行在终端、桌面应用、消息平台和 IDE 中，与 Claude Code（Anthropic）、Codex（OpenAI）、OpenCode 等工具同属一个品类——但 Hermes 有几个核心差异化特性让它脱颖而出。

Hermes 最大的特色是提供商无关。你可以随时切换 OpenRouter、Anthropic、OpenAI、DeepSeek、Google Gemini、xAI Grok、HuggingFace、本地模型等 20 多家提供商，而工作流完全不变。这是业界少有的真正实现「模型无关」的智能体框架。它还支持凭证池化——同一个提供商可以配置多个 API Key，自动轮换使用，当某个 Key 耗尽时自动跳过。

另一大特色是自我进化的技能系统。Hermes 会从每次交互中学习，将可复用的工作流保存为技能文档（SKILL.md）。当你解决了一个复杂问题、发现了一个工作流、或者被纠正了错误，这些知识可以固化为技能，在未来的会话中自动加载。技能会随时间积累，让代理越来越擅长你的特定任务和场景。

跨会话持久记忆让 Hermes 记住你是谁、你的偏好、环境细节和经验教训。记忆后端可插拔（内置 SQLite、Honcho、Mem0 等），你可以自由选择。

还有多平台消息网关——同一个智能体实例可以同时运行在 Telegram、Discord、Slack、WhatsApp、iMessage、Signal、Matrix、Teams、Email 等 20 多个平台上，拥有完整的工具调用能力，不只是聊天机器人。

Hermes 的能力部分来自于它丰富而精细的命令体系。本文全面梳理 Hermes Agent 的 77 个核心命令，按功能分类一一解读。

---

一、基础交互命令

这是 Hermes 最常用的命令组。Hermes 默认进入交互式聊天模式，但同时也提供了丰富的非交互式选项，方便脚本调用和 CI/CD 集成。

hermes — 启动交互式对话

无参数启动，进入交互式聊天界面。这是最常用的入口。启动后可以持续对话，Hermes 会跨轮次保持上下文。用户每输入一条消息，Hermes 会调用 LLM 并执行工具调用，然后返回结果。这个循环持续进行，直到用户退出。

hermes chat — 精细化聊天控制

显式启动聊天模式。支持多种子选项：

-q, --query TEXT — 单次查询模式，非交互式。这是脚本调用的主力选项。例如 hermes chat -q "列出当前目录下的所有 Python 文件并统计行数" 会返回结果后自动退出。适合集成到 Makefile、CI 流水线、定时任务中。

-m, --model MODEL — 指定模型，覆盖配置中的默认设置。例如 hermes chat -m anthropic/claude-sonnet-4 使用 Claude Sonnet 4，或者 hermes chat -m openai/gpt-4o 使用 GPT-4o。模型名称格式为 提供商/模型名。

-t, --toolsets LIST — 指定启用的工具集，逗号分隔。例如 -t terminal,file,web 只加载终端、文件和网络搜索三个工具集。这可以减少 Token 消耗、提升专注度。

--provider PROVIDER — 强制指定提供商，不依赖默认配置。例如 --provider openrouter。

-v, --verbose — 详细输出模式，显示模型调用详情、工具执行过程、API 耗时等调试信息。

-Q, --quiet — 静默模式。隐藏启动横幅、旋转动画、工具调用预览等非必要输出。适合在终端输出需要被其他程序解析的场景。

--checkpoints — 启用文件系统检查点。Hermes 会在关键操作前自动创建快照，可以用 /rollback 命令回滚到之前的文件状态。这是实验性操作的防护网。

--source TAG — 设置会话源标签。默认值为 cli。当你从不同入口（CLI、桌面、Web、Telegram）使用 Hermes 时，这个标签帮助区分会话来源，方便后续统计和分析。

会话恢复与分支

hermes --resume, -r SESSION — 按会话 ID（如 20260228_143052_a1b2c3）恢复历史会话。适合工作中断后精确回到之前的上下文。

hermes --continue, -c [NAME] — 按名称恢复最近会话。不传名称时恢复最近一个会话。比 --resume 更方便快捷。

hermes --worktree, -w — 隔离的 git worktree 模式。适用于并行运行多个代理分别处理不同分支，避免 git 文件冲突。每个 worktree 有独立的文件系统视图。

启动预配置

hermes --skills, -s SKILL — 预加载技能列表。可重复使用或逗号分隔。例如 hermes -s python-debugging,git-workflow 在启动时即加载调试和 Git 工作流两个技能。技能中包含的提示会注入系统提示，指导 Hermes 的行为。

hermes --profile, -p NAME — 使用指定的配置启动。配置文件有独立的 skills/、plugins/、cron/、memories/ 目录。适合在同一台机器上运行多个用途不同的 Hermes 实例。

hermes --yolo — 跳过所有危险命令的审批提示。默认情况下 Hermes 会在执行 rm -rf、git reset --hard 等破坏性命令前请求用户确认。--yolo 跳过这个保护层，谨慎使用。

hermes --pass-session-id — 在系统提示中包含当前会话 ID。某些高级场景下，子代理或外部系统需要知道自己所属的会话上下文。

---

二、配置管理命令

配置是 Hermes 的基础层。面向新用户和需要精细化控制的高级用户分别提供了不同层次的命令。

交互式向导

hermes setup [section] — 交互式配置向导，是新手最友好的入口。不加参数时启动全流程向导，引导用户逐步完成模型选择、终端配置、API Key 设置等步骤。

分模块设置：
- hermes setup model — 仅配置模型和提供商
- hermes setup terminal — 仅配置终端后端（本地/Docker/SSH/Modal）
- hermes setup gateway — 仅配置消息网关
- hermes setup tools — 仅配置工具启用/禁用
- hermes setup agent — 仅配置代理行为参数

每个子向导都是独立的 curses TUI，支持方向键选择、空格键切换、回车确认。

hermes model — 交互式模型/提供商选择器。打开一个列表界面，显示所有支持的提供商和可用的模型。可以选择模型后自动测试连通性。支持 20 多家主流提供商：OpenRouter、Anthropic、OpenAI、Nous Portal、GitHub Copilot、Google Gemini、DeepSeek、xAI Grok、HuggingFace、Z.AI/GLM、MiniMax、Kimi/Moonshot、阿里 DashScope、小米 MiMo、Kilo Code、OpenCode Zen/Go、Qwen OAuth 等。此外还支持自定义端点。

配置文件操作

hermes config — 查看当前配置摘要，包括模型、提供商、上下文长度、终端类型、工具状态等关键信息。

hermes config edit — 在系统默认编辑器中打开 config.yaml。在 CLI 模式下会使用 $EDITOR 环境变量指定的编辑器。

hermes config set KEY VAL — 直接设置配置项，无需编辑器。支持点号分隔的层级键名：
- hermes config set model.default deepseek/deepseek-chat
- hermes config set display.interface tui
- hermes config set security.redact_secrets true
- hermes config set approvals.mode smart

hermes config path — 打印 config.yaml 的完整文件路径。

hermes config env-path — 打印 .env 文件的完整路径。API Key 和安全凭据存储在此文件中。

配置健康检查

hermes config check — 检查当前配置是否存在缺失的必填项、已废弃的选项、或格式不正确的值。生成检查报告，列出问题和修复建议。

hermes config migrate — 升级配置文件的必要工具。当 Hermes 新版本引入新的配置选项时，migrate 会将缺失的选项以默认值添加到现有配置中，保证配置文件的完整性。

诊断命令

hermes doctor [--fix] — 全面的健康检查命令。诊断范围包括：
- Python 环境和依赖版本
- 模型提供商连通性
- 终端后端可用性
- 工具集依赖完整性
- API Key 有效性
- 配置文件完整性
- 技能目录结构
- 数据库状态

带 --fix 参数时会尝试自动修复发现的问题。

hermes status [--all] — 显示各组件运行状态。默认显示摘要：模型状态、工具状态、网关状态、存储状态。--all 显示全部组件的详细状态。

---

三、工具与技能管理命令

Hermes 的核心能力来自可插拔的工具系统和可积累的技能库。工具决定了代理能做什么，技能决定了代理知道怎么做。

工具管理

Hermes 的工具系统采用「工具集」架构。每个工具集包含一组相关的工具。例如 terminal 工具集包含 shell 命令执行、进程管理、后台任务等工具；web 工具集包含网页抓取、搜索引擎、内容提取等工具。所有工具集定义在 toolsets.py 的 TOOLSETS 字典中。

hermes tools — 交互式工具启用/禁用界面。基于 curses 的 TUI，左侧显示所有工具集，右侧显示选中工具集的详细工具列表。支持按平台分别配置——例如在 Telegram 上禁用 browser 工具集，在 CLI 上保留。

hermes tools list — 以文本列表形式输出所有工具集及其状态（启用/禁用/按平台启用），便于脚本解析。

hermes tools enable NAME — 启用指定工具集。例如启用图像分析能力：hermes tools enable vision。启用后需要 /reset 新会话才能生效。

hermes tools disable NAME — 禁用指定工具集。例如在安全敏感场景中禁用网络访问：hermes tools disable web。

技能管理

技能是 Hermes 最独特的机制。每个技能是一个包含 YAML 前置元数据和 Markdown 正文的 SKILL.md 文件。技能可以包含精确的指令、命令示例、陷阱警告、验证步骤。当技能加载到会话中时，其内容注入系统提示，指导模型的行为。

hermes skills list — 列出所有已安装技能，显示名称、描述、版本、作者、安装来源。

hermes skills search QUERY — 在官方技能中心搜索可用但尚未安装的技能。搜索范围覆盖社区贡献的数百个技能。

hermes skills install ID — 安装技能。ID 可以是中心注册的标识符，也可以直接是一个 HTTPS 链接指向 SKILL.md 文件。后者支持私有仓库中的技能。使用 --name 参数可以覆盖技能在元数据中定义的名字。

hermes skills inspect ID — 预览技能内容和元数据，但不实际安装。用于评估技能是否适合自己使用。

hermes skills config — 按平台配置技能的启用/禁用状态。例如可以让 git-workflow 技能仅在 CLI 中加载，而在 Telegram 中禁用。

hermes skills check — 检查所有已安装技能是否有可用的更新版本。

hermes skills update — 批量更新所有过时的技能到最新版本。

hermes skills uninstall N — 通过索引号移除已安装的技能。

hermes skills publish PATH — 将本地开发的技能发布到官方技能注册中心。

hermes skills browse — 浏览全部分类下的所有公开技能。支持按分类、评分、安装量排序。

hermes skills tap add REPO — 添加 GitHub 仓库作为技能来源。技能将从指定仓库中自动发现和同步。

---

四、MCP 服务器管理命令

Model Context Protocol 是 AI 工具互操作的标准协议。Hermes 既可以作为 MCP 客户端连接外部服务，也可以作为 MCP 服务器暴露自身能力。

hermes mcp serve — 将 Hermes 自身作为 MCP 服务器运行，暴露其工具给其他 MCP 客户端（如 VS Code、Zed、JetBrains 等 IDE）。

hermes mcp add NAME — 添加一个 MCP 服务器连接。支持两种连接模式：
- --url 参数连接到远程 HTTP MCP 服务器
- --command 参数运行本地 MCP 服务器进程（stdio 模式）

例如 hermes mcp add filesystem --command "npx @modelcontextprotocol/server-filesystem /path" 添加文件系统 MCP 服务器。

hermes mcp remove NAME — 移除已配置的 MCP 服务器。

hermes mcp list — 列出所有已配置的 MCP 服务器及其状态（连接/断开）。

hermes mcp test NAME — 测试指定 MCP 服务器的连通性，返回工具列表和执行测试。

hermes mcp configure NAME — 切换 MCP 暴露的工具的选择——可以选择将哪些工具暴露给模型使用，哪些隐藏。

---

五、消息网关命令

Hermes 的网关支持 20 多种消息平台，这意味着你可以在 Telegram 上命令 Hermes 编写代码、在 Slack 中让它分析数据、在 WhatsApp 上让它查询数据库——所有平台共享同一个智能体核心，但走不同的安全策略和审批流程。

hermes gateway run — 前台运行消息网关。日志直接打印到终端，适合调试和验证配置。按 Ctrl+C 停止。

hermes gateway install — 将网关安装为后台服务。Linux 下使用 systemd user service，Windows 下使用 Windows Service。

hermes gateway start / stop — 手动启动/停止已安装的网关服务。

hermes gateway restart — 重启网关服务。在修改配置或更新后使用。

hermes gateway status — 检查网关运行状态，显示是否正在运行、启动时间、连接的平台列表、消息统计。

hermes gateway setup — 交互式配置消息平台。引导用户完成 Telegram Bot Token 配置、Discord Bot 权限设置、WhatsApp 二维码扫描等各平台特有的认证流程。

支持平台列表：Telegram、Discord、Slack、WhatsApp（Baileys 桥接 + 官方 Business Cloud API）、iMessage（Photon 协议，无需 Mac 中介服务器）、Signal、Email（IMAP/SMTP）、SMS、Matrix、Mattermost、Microsoft Teams、LINE、SimpleX、ntfy、Google Chat、Home Assistant、钉钉、飞书、企业微信、微信、Raft 代理网络、API Server、Webhooks。Open WebUI 可以通过 API Server 适配器连接。

---

六、会话管理命令

Hermes 的会话系统基于 SQLite + FTS5（全文搜索 5）引擎。所有对话记录持久化到本地，支持高效检索、导出和管理。

hermes sessions list — 列出最近的会话列表。每个条目显示会话 ID、标题（自动生成或用户设置）、开始时间、消息数量、使用的模型。输出按时间倒序排列。

hermes sessions browse — 交互式会话浏览器。支持搜索关键词筛选、时间范围过滤、模型筛选。选中会话后可以查看摘要或继续对话。

hermes sessions export OUT — 将会话导出为 JSONL（JSON Lines）格式文件。每行一个 JSON 对象，包含消息角色、内容、时间戳、工具调用记录。适合数据分析和模型微调。

hermes sessions rename ID T — 重命名指定会话。让你的会话列表更有条理。

hermes sessions delete ID — 永久删除指定会话。不可恢复，谨慎操作。

hermes sessions prune — 清理旧会话。支持 --older-than N days 参数指定天数阈值。超出阈值的会话将被删除。适合定期清理以节省磁盘空间。

hermes sessions stats — 显示会话存储统计：会话总数、消息总数、存储空间占用、平均每会话消息数等。帮助你了解使用规模和增长趋势。

---

七、定时任务命令

Hermes 内置的 cron 调度器支持从简单的间隔定时到复杂的 cron 表达式，每个任务可以加载技能、覆盖模型、指定工作目录、启用多平台投递。

hermes cron list — 列出所有定时任务。--all 参数同时显示已禁用的任务。每个条目显示任务 ID、名称、调度表达式、下次执行时间、执行次数、状态。

hermes cron create SCHED — 创建新定时任务。调度格式非常灵活：
- 持续时间："30m"（每30分钟）、"2h"（每2小时）
- 自然语言："every monday 9am"、"every weekday at 18:00"
- 标准 cron："0 9 *"（每天上午9点）
- ISO 时间戳：一次性执行

创建时可以指定提示词、技能列表、模型/提供商、投递平台、工作目录等。

hermes cron edit ID — 编辑定时任务的配置。可以修改调度表达式、提示词内容、技能列表、投递方式、工作目录等。

hermes cron pause ID / resume ID — 暂停/恢复定时任务。暂停的任务不会触发执行，但保留配置和调度信息。

hermes cron run ID — 立即触发任务执行，不等候下一个调度周期。可以在测试时使用。

hermes cron remove ID — 删除定时任务。删除后不可恢复。

hermes cron status — 查看 cron 调度器的整体状态：是否在运行、任务总数、待执行任务数、历史执行统计。

每个任务支持丰富的配置：技能预加载、模型提供商覆盖、前置数据收集脚本（输出自动注入提示词上下文）、链式引用（将任务 A 的输出传递到任务 B）、工作目录挂载（自动加载该目录的 AGENTS.md/CLAUDE.md）、跨平台投递（同时发送到 Telegram 和邮件）。

---

八、Webhook 命令

Webhook 系统允许外部服务通过 HTTP POST 请求触发 Hermes 执行任务。与 cron 的时间驱动不同，webhook 是事件驱动的。

hermes webhook subscribe N — 注册 Webhook 路由。在 /webhooks/ 路径上创建一个新的端点。可以配置请求体模板、响应格式、认证方式。

hermes webhook list — 列出所有已注册的 Webhook 订阅。显示端点路径、创建时间、触发次数、最后触发时间。

hermes webhook remove NAME — 移除指定 Webhook 订阅。端点立即失效。

hermes webhook test NAME — 向指定 Webhook 发送测试 POST 请求，验证端点的连通性和响应。

Webhook 的典型应用场景：GitHub 推送事件触发代码检查、GitLab MR 事件触发自动测试、Zapier/Make 集成触发工作流、Prometheus 告警触发自动排障。

---

九、配置文件管理命令

配置文件（Profile）是 Hermes 支持多实例运行的基础设施。每个配置文件拥有完全独立的环境。

hermes profile list — 列出所有已有配置。显示名称、创建时间、使用的模型、技能数量、插件数量。默认配置高亮显示。

hermes profile create NAME — 创建新配置。支持克隆现有配置：
- --clone 从当前配置克隆
- --clone-all 克隆全部配置
- --clone-from NAME 从指定配置克隆

克隆时可以选择性地复制 skills/、plugins/、cron/、memories/ 目录。

hermes profile use NAME — 设置指定配置为系统默认。之后启动 Hermes 时自动使用该配置。

hermes profile delete NAME — 删除指定配置及其数据。

hermes profile show NAME — 显示配置详情：模型配置、工具集状态、技能列表、插件列表、记忆状态等。

hermes profile alias NAME — 管理配置的快捷包装脚本。创建类似 hermes-work、hermes-personal 的快捷命令。

hermes profile rename A B — 将配置 A 重命名为 B。

hermes profile export NAME — 将配置导出为 tar.gz 存档。适合备份或在机器间迁移。

hermes profile import FILE — 从存档导入配置。

---

十、凭证与密钥池管理命令

对于使用多个 API Key 或 OAuth 提供商的企业用户，Hermes 提供了强大的凭证管理功能。

hermes auth — 交互式凭证管理器，支持添加、列出、移除、重置各种提供商凭证。基于 curses 的 TUI 界面。

hermes auth add [PROVIDER] — 添加指定提供商的凭证。支持的提供商包括：
- nous — Nous Portal OAuth
- openai-codex — OpenAI Codex OAuth
- qwen-oauth — 通义千问 OAuth
- anthropic — Anthropic API Key

凭证添加后会自动加入对应提供商的凭证池。

hermes auth list [PROVIDER] — 列出指定提供商的凭证池。显示每个凭证的状态（有效/耗尽/错误）、添加时间、最后使用时间。不指定提供商时列出所有。

hermes auth remove P INDEX — 通过提供商名称和凭证索引移除单个凭证。

hermes auth reset PROVIDER — 清除指定提供商的费率限制或密钥耗尽状态。当 API Key 的限速解除后使用此命令恢复使用。

多凭证池化的核心价值：同样的提供商，配置多个 Key 后 Hermes 自动轮换使用；当某个 Key 因超出速率限制或消费额度耗尽而失败时，自动跳过并切换到下一个，保证了服务的高可用性。

---

十一、其他管理命令

这些命令覆盖了使用分析、桌面体验、IDE 集成、数据迁移等场景。

hermes insights [--days N] — 使用分析仪表盘。展示 API 调用量趋势、Token 消耗统计、模型使用分布、工具调用频率、会话时长分布等。默认显示近 30 天数据，可通过 --days 参数调整。

hermes update — 升级到最新版本的 Hermes Agent。从官方源拉取最新代码或 PyPI 包。

hermes desktop / hermes gui — 启动原生 Electron 桌面应用。支持 macOS、Linux、Windows。功能包括：流式聊天、会话列表、拖拽上传、剪贴板粘贴图片、Cmd+K 快捷命令面板、状态栏模型切换器、可配置快捷键、原生通知、实时子代理监控窗口、VS Code Marketplace 主题、远程网关登录。

hermes dashboard — 启动 Web 管理面板。完全在浏览器中运行，可以配置所有消息渠道、MCP 目录、Webhook/钩子、记忆系统、配置构建器（模型 + 技能 + MCP 组合）。内嵌了 hermes --tui 聊天界面。面板通过 OAuth/Token 认证保护。

hermes proxy — 启动 OpenAI 兼容的本地代理服务器，运行在 http://localhost:端口。这个代理的后端连接到你的 OAuth 提供商（Claude Pro、ChatGPT Pro、SuperGrok）。也就是说，你可以将 Codex CLI、Aider、Cline、Continue 或其他任何 OpenAI 兼容客户端指向这个代理，而无需 API Key。

hermes portal — 快速登录 Nous Portal，通过 OAuth 完成身份认证，无需手动配置 API Key。

hermes kanban — 多代理协作看板系统。支持 20 多个子命令：
- init、create、list、show、assign、link、unlink
- comment、complete、block、unblock、archive
- tail、watch、stats、runs、log
- dispatch、daemon、gc

看板使用 SQLite 持久化，支持多配置/多工作者协作。调度器可以在网关中自动运行，回收过期任务、推动就绪任务、分配工作者。

hermes pairing list/approve/revoke — 管理 DM 授权。控制哪些用户可以发送私信给代理。防止未经授权的用户访问代理能力。

hermes plugins list/install/remove — 插件管理。插件是扩展 Hermes 能力的轻量级方式，可以在 ~/.hermes/plugins/ 中安装自定义插件。

hermes secrets bitwarden ... — 集成 Bitwarden Secrets Manager 作为外部密钥存储。支持从 Bitwarden 读取 API Key 和配置文件。

hermes memory setup/status/off — 配置持久记忆系统。支持的后端包括：
- 内置 SQLite（默认，零配置）
- Honcho（开源记忆服务器）
- Mem0（记忆管理平台）
- Memory-based 工具调用

记忆系统包括两个维度：用户画像（用户偏好、角色、习惯）和工作记忆（环境细节、工具技巧）。关闭记忆：hermes memory off。

hermes send — 通过消息网关发送一条独立消息到指定平台。适合脚本调用：hermes send -p telegram "Deployment complete"。

hermes completion bash|zsh — 生成 shell 自动补全脚本。安装后可以在终端中输入 hermes 后按 Tab 查看命令和选项的自动补全提示。

hermes acp — 启动 ACP 服务器。ACP（Agent Communication Protocol）是 IDE 集成的标准协议。VS Code、Zed、JetBrains 等 IDE 可以通过 ACP 连接到 Hermes。

hermes claw migrate — 从 OpenClaw 迁移配置、会话和技能到 Hermes。简化了工具迁移的流程。

hermes uninstall — 完全卸载 Hermes Agent，包括配置、会话数据和技能。

---

十二、会话内斜杠命令

在交互式会话中，斜杠命令是最高频率的操作方式。输入 / 即可看到完整列表和提示。

会话控制命令

/new（/reset） — 开启全新会话，清除所有上下文和历史。当你需要从一个完全干净的状态开始时使用。

/clear — CLI 模式下清屏并新建会话。界面上的旧内容消失，但对话历史仍在会话数据库中。

/retry — 重新发送上一条消息。当模型生成失败、结果不符合预期或出现工具调用错误时使用。不会重置上下文，只是重试最后一次交互。

/undo — 撤销最近一次问答交换。删除模型最后一次回复和你的上一条消息，回到之前的状态。

/title [name] — 为当前会话命名。好的命名方便后续通过 --resume 或 --continue 快速找回。不传参数时自动生成标题。

/compress — 手动触发上下文压缩。当会话较长、接近模型上下文窗口限制时，Hermes 会自动压缩。手动压缩可以在你感觉响应变慢时使用。

/stop — 终止所有后台运行的子代理进程和长时间任务。

/rollback [N] — 恢复到之前的文件系统检查点。时间机器功能，当实验性操作破坏了文件时使用。

/snapshot [sub] — 创建或恢复 Hermes 配置和状态的快照。方便在重大配置变更前备份。

/background — 在后台运行一个提示词任务。适合耗时操作，不阻塞当前会话。

/queue — 将提示词排入队列，在当前任务完成后自动执行。

/steer — 在不打断当前工具调用流程的情况下注入一条消息。消息会在下一次工具调用结果返回后插入。

/agents（/tasks） — 显示所有活跃的子代理和待执行/正在执行的任务。

/resume [name] — 恢复之前命名的会话。

/goal [text|sub] — 设置常驻目标。Hermes 会在多轮对话中持续努力完成。支持 status（查看目标状态）、pause（暂停）、resume（恢复）、clear（清除）子命令。适合设定长期任务目标。

/redraw — 刷新 TUI 界面。当界面显示异常时使用。

配置控制命令

/config — 在会话中查看当前配置关键项。

/model [name] — 显示当前模型，或切换模型。不传参数时显示当前模型，传名称时在会话中切换。

/personality [name] — 设置或切换代理人格设定。人格定义影响回复风格和语气。

/reasoning [level] — 设置推理链可见级别。从 none（完全隐藏）到 xhigh（极度详细）。show 显示推理、hide 隐藏。

/verbose — 循环切换详细信息输出级别：off → new → all → verbose。

/voice [on|off|tts] — 语音模式控制。on 开启语音输入（自动语音识别）+ 语音输出（TTS）；tts 仅开启语音输出；off 关闭。

/yolo — 在会话中切换危险命令审批绕过。相当于 --yolo 标志的运行时版本。

/busy [sub] — 控制 Hermes 工作时 Enter 键的行为：queue（将输入排入队列）、steer（在不中断的情况下输入）、interrupt（中断当前工作）、status（查看队列状态）。

/indicator [style] — 选择 TUI 忙碌指示器的风格：kaomoji（颜文字）、emoji（表情符号）、unicode（Unicode 符号）、ascii（ASCII 字符）。

/footer [on|off] — 切换消息网关在最终回复底部显示的运行时元数据脚注。

/skin [name] — 切换界面主题风格。

/statusbar — 切换 CLI 模式下的状态栏显示。

工具与技能命令

/tools — 在会话中查看和切换工具启用/禁用状态。

/toolsets — 列出所有可用的工具集。

/skills — 搜索和安装技能，无需退出当前会话。

/skill — 将指定技能加载到当前会话。

/reload-skills — 重新扫描 ~/.hermes/skills/ 目录，加载新增的技能、卸载已删除的技能。

/reload — 重新加载 .env 文件中的环境变量到当前运行的会话中。修改了 API Key 后无需重启。

/reload-mcp — 重新加载 MCP 服务器连接。添加或修改 MCP 服务器配置后使用。

/cron — 管理定时任务。支持列出、查看状态、暂停、恢复。

/curator [sub] — 后台技能生命周期维护。子命令：status（状态）、run（执行）、pin（固定）、unpin（解除固定）、archive（归档）、restore（恢复）、prune（修剪）、backup（备份）、rollback（回滚）。

/kanban [sub] — 多配置协作看板。支持查看任务、链接、评论。

/plugins — 列出当前会话中已加载的插件。

网关命令

/approve — 批准待审批的命令执行。在消息平台中使用时，Hermes 执行危险命令前会等待用户确认。

/deny — 拒绝待审批的命令执行。

/restart — 重启消息网关服务。

/sethome — 将当前聊天设置为默认频道。所有系统通知将发送至此。

/update — 升级 Hermes 到最新版本。

/topic [sub] — 管理 Telegram DM 话题会话功能。

/platforms（/gateway） — 显示所有已连接的消息平台状态。

实用工具命令

/branch（/fork） — 基于当前会话创建一个独立的副本。分支可以独立发展，不影响原会话。

/handoff — 将正在进行的会话转移到指定消息平台继续。例如从 CLI 切换到 Telegram。

/fast — 切换优先级/快速处理模式。在快速模式下，Hermes 使用更小的模型或更简化的推理链。

/browser — 打开 CDP（Chrome DevTools Protocol）浏览器连接，用于网页自动化。

/history — 在当前终端中回放整个对话历史。

/save — 将当前对话保存到指定文件中。

/copy [N] — 将最近 N 条（默认 1 条）回复复制到系统剪贴板。

/paste — 从剪贴板粘贴图片到当前会话。

/image — 从本地文件系统上传图片。

信息查询命令

/help — 显示当前版本的完整命令帮助。是最权威的参考来源。

/commands [page] — 分页浏览所有可用的斜杠命令及其说明。

/usage — 显示当前会话的 Token 使用统计——输入 Token、输出 Token、总计、成本估算。

/insights [days] — 跨会话的使用行为分析——调用频率、Token 趋势、工具使用分布。

/status — 实时会话状态——模型、提供商、上下文长度、Token 使用。

/profile — 显示当前配置信息。

/debug — 收集系统信息和日志，上传并返回可分享的调试链接。

退出命令

/quit（/exit、/q） — 退出 Hermes CLI，结束当前会话。所有未保存的上下文将丢失（但会话记录已在数据库中持久化）。

---

十三、全局标志

这些标志适用于任何子命令之前，影响整个 Hermes 实例的行为：

• --version, -V — 显示版本号
• --resume, -r SESSION — 按 ID 恢复会话
• --continue, -c [NAME] — 按名称恢复最近会话
• --worktree, -w — 隔离工作目录，并行代理不冲突
• --skills, -s SKILL — 预加载指定技能
• --profile, -p NAME — 使用指定配置
• --yolo — 跳过所有命令审批
• --pass-session-id — 在系统提示中包含会话 ID
• --ignore-rules — 跳过项目上下文文件（.hermes.md、AGENTS.md、CLAUDE.md、.cursorrules）和 SOUL.md 的自动注入

---

结语：命令体系的哲学

Hermes Agent 的 77 个命令背后体现了一种独特的设计哲学：分层抽象 + 渐进暴露。

对于日常用户，只需记住 hermes 启动对话就够了。单次查询用 hermes chat -q。遇到问题用 hermes doctor。更换模型用 hermes model。这些核心命令覆盖了 80% 的使用场景。

对于进阶用户，模型切换、工具管理、技能安装、会话恢复提供了深度定制能力。你可以为不同的工作场景创建不同的配置，每个配置拥有独立的模型、工具、技能和记忆。

对于 DevOps 和团队场景，网关消息平台集成、cron 定时任务编排、看板多代理协作、配置管理、凭证池化，支撑起完整的工作流自动化体系。

这不是一份需要从头背诵的命令列表，而是一份参考手册——当你遇到特定需求时，找到对应的功能分类，定位到具体命令。每一条命令都针对一个明确的场景设计，只需要一次使用就能记住。

最后，记住三个黄金入口：
- 设置系统：hermes setup 或 hermes model
- 诊断问题：hermes doctor 或 hermes config check
- 探索所有能力：在终端运行 hermes --help 或在会话中输入 /help

Hermes Agent 的核心信念是：工具应该适应人，而不是人适应工具。这套命令体系正是这一理念的最好体现——它不要求你记住一切，但当你需要时，它总在那里。

book-skill v3.8.0 深度分析报告

6 Agent × 14 Flow × 4 检查点 × 120 维审计 — 全自动小说生产管线的完整解剖

本文对 book-skill（原名 book-agent）进行了完整的深度分析。这是一个全自动小说生产管线技能，零外部依赖，124 个文件，涵盖从大纲到发布的全流程。

---

一、项目概况

维度	数据
名称	book-skill（曾用名 book-agent）
版本	3.8.0
文件总数	124
SKILL.md	464 行核心定义
参考文件	44 个
可执行脚本	28 个（全部语法正确）
模板文件	44 个
题材支持	8 种（都市/科幻/仙侠/玄幻/奇幻/悬疑/言情/游戏穿越）
Agent 数量	6 个
Flow 数量	14 个
外部依赖	零
行尾格式	全部 LF（无 CRLF）

---

二、核心架构

2.1 管线拓扑

主 agent（头脑风暴）
  │
  ├── 🎬 Director       → Flow 0 导演笔记
  ├── 🎭 Screenwriter   → Flow 1 剧本结构
  ├── 📚 LoreKeeper     → Flow 2 调研报告
  ├── 📚 LoreKeeper     → Flow 3 设定审核
  ├── 📚 LoreKeeper     → Flow 4 Truth预检 ── CP1
  ├── ✍️ Writer         → Flow 5 正文草稿 ── CP2
  ├── ✨ Polisher       → Flow 6 精修
  ├── 📚 LoreKeeper     → Flow 7 120维审计 ── CP3
  ├── 📚 LoreKeeper     → Flow 8 连贯性检查
  ├── 💬 Feedback ×2    → Flow 9 试读 + Flow 10 场景（并行）
  ├── 🎬 Director       → Flow 11 修改闭环
  ├── 📚 LoreKeeper     → Flow 12 终审 ── CP4
  └── 🎬 Director       → Flow 13 发布

2.2 6 Agent 职责边界

Agent	负责工序	NOT RESPONSIBLE FOR
🎬 Director	0(大纲)·11(闭环)·13(发布)	写正文·事实调研·设定决策
🎭 Screenwriter	1(结构)	写正文·事实调研·设定决策
📚 LoreKeeper	2·3·4·7·8·12（6道工序）	写正文
✍️ Writer	5(草稿)	设定决策·审计·发布
✨ Polisher	6(精修)	结构调整·事实修正
💬 Feedback	9(试读)·10(场景)	设定决策·正文修改

LoreKeeper 是工作量最大的 Agent，扛 6 道工序（调研→审核→预检→审计→连贯→终审）。

---

三、质量体系

3.1 4 道硬门禁

门禁	位置	条件	不通过→回退
CP1	F4→F5	11 项 Truth 预检全部通过	→ Flow 1
CP2	F6→F7	字数 ≥5000 + AI味零命中	→ Flow 5
CP3	F7→F8	120 维审计 ≥900	→ Flow 5
CP4	F12→F13	终审 ≥1020	→ Flow 7

3.2 120 维评分等级

分数	等级	处理
1080-1200	⭐ S	直接发布
960-1079	✅ A	小修后发布
900-959	⚠️ B	返回 11_notes 修改
800-899	🔴 C	返回 5_drafts 重写
<800	💀 D	返回 3_arcs 重新设定

---

四、28 个脚本系统

管线执行（5 个）

batch-produce.sh·pipeline-run.sh·release.sh·init-project.sh·flow-hooks.sh

验证（5 个）

novel-verify.sh·validate-agents.sh·validate-truth.sh·validate-yaml.sh·check-truth-usage.sh

工具（9 个）

de-ai-scan.sh·truth-query.sh·diff-truth.sh·word-count.sh·health-check.sh·status-check.sh·md2html.sh·wiki.sh·scan-chapter.sh

新增能力（4 个）

discover-agents.sh（动态 Agent 发现）·audit-calc.sh（120 维自动算分）·upgrade.sh（版本迁移）·archive.sh（章节归档）

工程（5 个）

sync-skill.sh·agent-run.sh·install-hooks.sh·pre-commit.sh·hermes-start/stop.sh

---

五、Agent 人格体系

每个 Agent prompt 包含统一四段式记忆定义：

### 你的身份与记忆
- **角色**：岗位定义
- **性格**：行事风格
- **记忆**：跨章节经验
- **经验**：领域积累

每个项目一个 soul.md，6 个 Agent 角色各司其职。

---

六、核心设计决策

决策	选择	理由
产出格式	HTML 统一	浏览器直接预览，无需工具
配置覆盖	sync-skill.sh	技能是权威来源，子项目只读
Context 传递	纯文本 key:value	JSON 嵌套导致 subagent 解析超时
Truth 按需读取	限制 Flow 2/3/7 全量读	减少下游 token 暴胀
NEXUS handoff	摘要+全量路径	下游按需取回
检查点门禁	4 道硬门禁	不达标自动回退

---

七、代码健康

检查项	状态
脚本语法	✅ 28 个全部通过 shellcheck
Agent 完整性	✅ 6 个全部通过
CRLF 行尾	✅ 零残留
book-agent 旧名称	✅ 零残留
960px 非标准宽度	✅ 零残留
六维 旧术语	✅ 零残留
深色背景硬编码	✅ 零残留
.md 产出引用	✅ 零残留
多格式发布过时描述	✅ 零残留
agent.json 硬编码路径	✅ 已清理

---

八、优势与展望

优势

• 零外部依赖，纯 shell + markdown + JSON
• 4 级硬门禁自动回退，质量不依赖人工判断
• NEXUS handoff 全覆盖，每 Flow 必有交接
• Truth 系统 9 个 JSON 构成设定宪法
• 120 维评分，每维 10 分可追踪
• PipelineStage 48 阶段精确枚举

新增能力

• Agent 动态发现（discover-agents.sh）
• 120 维审计自动算分（audit-calc.sh）
• 版本迁移工具（upgrade.sh）
• 章节归档（archive.sh）

book-skill 是当前工程化程度最高的写作管线技能。124 个文件、48 阶段枚举、4 道硬门禁、120 维评分、8 种题材、28 个脚本、NEXUS 全覆盖。它的设计哲学不是提供通用建议，而是组装了一条工业流水线——不需要人盯着，自己跑完，自己验证，自己发布。

Book-Agent 完全解析：六位AI智能体 × 十四道工序的工业级小说生产管线

摘要：Book-Agent 是一套基于 Hermes Agent 框架的工业级 AI 小说创作管线。它由六个专业化的 AI 智能体协同完成十四道标准化工序，覆盖从大纲设计到多格式发布的全流程。经过两个真实项目的百万字实战验证，已建立完整的 120 维自动化质量评估体系。本文从架构设计、智能体分工、质量门禁、红线系统、题材适配、故障恢复、执行模式、实操数据和技术实现等十个维度，完整解析这套系统的设计哲学与工程实践。

一、引言：长篇小说创作的系统化困境

长篇小说创作是人工智能领域最富挑战性的应用场景之一。传统 AI 写作工具多采用"单次生成"模式——输入提示词、输出全文。这种方式存在根本性缺陷：生成文本缺乏整体一致性，前文设定在中后段被遗忘；角色行为缺乏连贯的动机链；叙事节奏不可控；更重要的是，无法对产出质量进行系统性评估和改进。

人类作家在创作长篇小说时，会经历构思、大纲、人物小传、场景卡、初稿、修订、校对等多个阶段。每个阶段都有特定的方法和工具。Book-Agent 所做的，就是将这套成熟的人类创作方法论转化为 AI 智能体可以协作执行的标准化流水线。

该项目的核心理念十分明确：将小说创作从依赖灵感的"手工小作坊"升级为流程可控的"工业生产线"。它借鉴了软件工程中的敏捷迭代、持续集成和代码审查等实践，将创作过程拆解为十四道可验证的工序，由六个各司其职的 AI 智能体协作完成。每道工序都有明确的输入标准、产出规范和验收条件，确保最终产品的质量可预期、可度量、可复现。

Book-Agent 已迭代至 v3.7.1 版本，并在两个真实项目中长期运行：都市 AI 题材《判断权》（陈默·北京2022）和游戏穿越题材《峡谷至尊》（李继祖）。两个项目风格迥异、难度不同，共同验证了管线系统的通用性和稳定性。累计产出超过百万字，单章平均耗时 35-50 分钟，最高审计评分达到 S 级（1080+/1200）。

二、系统架构：六位智能体的协作网络

2.1 智能体角色的专业化分工

Book-Agent 的核心是六个具有不同专业能力的 AI 智能体，每个智能体被赋予特定的角色定位和职责边界。这种专业化分工借鉴了好莱坞电影工业的制片体系：

智能体	工序编号	核心职责	产出目录
Director（导演）	0, 11, 13	章节定位、节奏设计、修改决策、发布管理	0_outline/ 11_notes/ 13_release/
Screenwriter（编剧）	1	场景结构、出场规划、空间时间设计	1_world/
LoreKeeper（设定守护者）	2,3,4,7,8,12	事实核查、角色弧线、预检审计、连贯验证、终审评估	多个目录
Writer（执笔者）	5	基于所有上游输入撰写正文初稿	5_drafts/
Polisher（精修师）	6	语言润色、去AI味检测、风格统一	6_polished/
Feedback（读者代表）	9, 10	可读性评估、情感共鸣分析、场景插画建议	9_iteration/ 10_illustration/

LoreKeeper 承担了最多的工序（六道），是管线中最繁忙的角色。这是因为设定一致性是长篇小说创作中最容易出问题、也最难自动化的环节。LoreKeeper 的核心价值在于：它是整个系统的"记忆守护者"，确保一百章之后的故事仍然遵循第一章建立的规则体系。

每个智能体的 prompt 中都包含明确的边界声明——即"NOT RESPONSIBLE FOR"段落。例如，Writer 的 prompt 明确声明不负责设定决策和事实修正，LoreKeeper 的 prompt 声明不负责正文撰写。这种边界防止了越界输出，确保每个智能体只在擅长的领域发挥作用。

2.2 十四道工序的流水线设计

十四道工序以严格的串行方式依次执行。每道工序的产出文件保存在磁盘上，作为下一道工序的输入。主 agent（人机协作的编排者）在每道工序完成后执行产出验证，验证通过才进入下一工序：

1. Flow 0 导演笔记：Director 读取 truth 文件和上一章结尾，执行"章节定位三问"——这一章要证明什么命题？读者为什么要关心？它在全书的战略位置是什么？输出包括核心事件链、节奏表和红线清单。
2. Flow 1 世界构建：Screenwriter 将导演笔记转化为具体的世界设定——场景地理信息、时间精度、出场人物清单、环境氛围要素。这一层相当于电影的"分镜脚本"。
3. Flow 2 事实调研：LoreKeeper 对世界设定进行全面的设定一致性核查，确保与全局 truth 文件吻合。同时根据章节需要补充外部专业知识（如法律流程、医学细节等）。
4. Flow 3 角色弧线：LoreKeeper 构建每个出场人物的情感轨迹和行动动机，特别注意人物的心理变化要符合其性格设定和历史经历。
5. Flow 4 Truth 预检（G1门禁）：LoreKeeper 执行十一项完整性预检——人物一致性、剧情逻辑、时间线、世界观、能力体系、科技树、道具、关系网络、概念定义、红线遵守和外部知识准确。任何一项不通过则回退到 Flow 1 修改世界设定。
6. Flow 5 正文草稿：Writer 基于所有上游输入撰写正文。标准章强制五千字以上，高潮章六千字以上。Writer 只负责文字表达，不参与设定决策。
7. Flow 6 精修润色：Polisher 对草稿进行全面语言优化——去除 AI 味表达、优化句式结构、控制叙事节奏、统一风格调性。字数不足则在此阶段标记回退。
8. Flow 7 审计评估（G2门禁）：LoreKeeper 执行完整的 120 维质量审计。要求综合评分 ≥ 900 分（B级），否则回退到 Flow 5 重写。
9. Flow 8 连贯性检查（G3门禁）：LoreKeeper 跨五章范围检查设定一致性。任何新旧设定之间的矛盾都被标记并必须修复。
10. Flow 9 读者反馈：Feedback 以普通读者的视角阅读全文，从信息密度、节奏舒适度、情感投入度和主题明确性四个维度给出评价。
11. Flow 10 场景插图：Feedback 基于正文内容生成关键场景的视觉化描述，供后续人工配图或 AI 绘图使用。
12. Flow 11 修改闭环：Director 汇总 Flow 7-10 的所有反馈，决定是否需要修改及修改方向。最多迭代三轮，两轮分数持平则强制退出。
13. Flow 12 终审评估（G4门禁）：LoreKeeper 执行全量终审，要求评分 ≥ 1020 分（A级），否则回退到 Flow 11+7。
14. Flow 13 发布就绪：Director 将终版正文转换为 Markdown、HTML、TXT 等多种发布格式，并更新项目进度文件。

三、质量体系：120维审计矩阵与四级硬门禁

Book-Agent 最核心的技术创新在于建立了可量化、可验证的自动化质量评估体系。这套体系将文学创作中难以捉摸的"写得好不好"问题，转化为 120 个可计算、可比较、可改进的具体指标。

3.1 审计矩阵的维度设计

审计矩阵将小说质量分解为十二个评估组，每组包含十个评价维度，总分为 1200 分。十二个组覆盖了从宏观叙事到微观语言的全部层面：第一组"故事架构"评估情节逻辑性、节奏控制力、冲突设计强度、悬念设置技巧、高潮布局合理性、转折自然度、线索埋设精度、子线完成度、首尾呼应性和章节独立性。第二组"人物塑造"评估性格一致性、成长轨迹清晰度、对话个性化程度、行动动机合理性、情感深度、关系变化合理性、配角完成度、群像刻画、心理真实度和辨识度。第三组"文笔表达"评估语言准确性、句式多样性、描写生动性、修辞恰当性、风格一致性、对话自然度、细节丰富度、节奏感、色彩感和声音感。后续各组依次涵盖设定一致性、读者体验、反 AI 味、文化准确性、类型遵循度、技术自洽性、结构完整性、情感感染力和创新性。每组满分 100 分（十维×十分），总分 1200 分。

这种分组设计有明确的工程考量：每个评估组相对独立，某个组的低分可以精准定位问题源头。例如，"人物塑造"组低于 70 分意味着角色层面需要重新设计，而"文笔表达"组低分则指向语言层面的问题。

3.2 四级硬门禁机制

管线中设置了四个硬性质量门禁，每道门禁都是不可跳过的检查点：

• G1（Flow 4→Flow 5）：十一项 Truth 预检全部通过。这是 WiP 通往 Writer 的最后一道防线。不通过则回退到 Flow 1，由 Screenwriter 和 LoreKeeper 共同修改世界设定。
• G2（Flow 6→Flow 7）：字数 ≥5000 + AI 味零命中 + 审计评分 ≥900（B级）。不通过则回退到 Flow 5，由 Writer 重写正文。
• G3（Flow 8→Flow 9）：跨五章设定零矛盾。不通过则回退到 Flow 6，由 Polisher 返工修复。
• G4（Flow 12→Flow 13）：终审评分 ≥1020（A级）。不通过则回退到 Flow 11，由 Director 和 LoreKeeper 联合修改。

四级门禁的严格程度逐级递增。G1 是预防性的——在问题发生前拦截；G2 和 G3 是修复性的——在问题出现后定位并修正；G4 是终验性的——在发布前做最后一次全面体检。

3.3 评分等级与决策规则

1080-1200 分为 S 级（直接发布），960-1079 分为 A 级（小修后发布），900-959 分为 B 级（需返回修改），800-899 分为 C 级（需返回重写），低于 800 分为 D 级（需重新设定）。审计系统默认不通过——这意味着每章在经过人工确认之前，默认被视为"不合格"。通过需要审计报告逐项列出通过证据。

四、红线系统：三类零容忍的质量底线

Book-Agent 定义了三条绝不可触碰的红线。任何一条被违反，都会触发立即回退，没有商量的余地。

4.1 Truth 红线：设定守则

每个项目维护九个 truth JSON 文件：人物库（characters.json）、剧情线（plot.json）、世界观（world.json）、时间线（timeline.json）、能力体系（power.json）、科技树（tech.json）、道具系统（props.json）、关系网络（relationships.json）和核心概念（concepts.json）。这九个文件构成项目的"宪法层级"。正文中任何句子都不得与 truth 文件中的定义冲突。例如，《判断权》的 truth 中定义"陈默在第一卷结束时尚未觉醒能力"，那么正文中如果出现陈默使用超能力的描写，就会被审计系统标记为红线违规。引入新设定前，必须先更新对应的 truth 文件，再经过一致性验证。这套机制从根本上杜绝了长篇小说最常见的"吃设定"问题。

4.2 AI 味红线：语言自然度守则

Book-Agent 维护了一份不断增长的 AI 味禁用词表。这些词汇和句式在大语言模型的输出中出现频率极高，但在人类创作中几乎不会以同样方式出现。禁用词包括："深吸一口气""某种""莫名的""瞳孔骤缩""嘴角勾起一抹""五味杂陈""眼神中闪过一丝""不由自主""鬼使神差""命运的齿轮""仿佛有什么""他突然觉得""那一刻他明白了""内心深处""仿佛被什么击中""就连空气都变得""仿佛听到了什么"。禁用句式包括："不是 A 而是 B"的对比结构、"心中涌起……"的表述、"原来如此"作为独立段落等。审计系统在 Flow 7 和 Flow 12 对这些禁用词进行零容忍检测，命中一条即相关维度扣分至零并触发回退重写。

4.3 字数红线：内容充实度守则

标准章强制要求 ≥5000 CJK 字，过渡章 ≥2500 字，高潮章 ≥6000 字。这一要求不是机械的字符计数——它确保每章都有足够的信息密度和叙事容量。不足字数时，Writer 必须扩充内容而不是填充废话。

五、题材适配：八种文学类型的宪法支持

Book-Agent 内置了八种主流文学题材的专门配置文件。每种题材都有独立的"宪法文件"（genre-*.md），定义了该题材的核心规则、常见陷阱和最佳实践：都市现实题材关注人物原型指南和敏感词规则，禁止美化犯罪；科幻题材强调技术自洽性，技术设定必须有科学依据或合理推演；仙侠题材要求修炼体系具有完整因果逻辑，境界晋升不可跳跃；玄幻题材需要可比较可度量的战力体系；奇幻题材要求魔法系统有明确的规则和代价；悬疑题材要求线索公平呈现给读者；言情题材要求人物关系变化有合理的心理动机；游戏穿越题材遵循完整的九段标准化 RPG 叙事结构。Director 在 Flow 0 制定大纲时自动加载对应题材的宪法，确保产出符合该题材的读者期待。

六、故障检测与恢复机制

在工业化创作管线中，故障不是"是否发生"的问题，而是"何时发生"的问题。Book-Agent 定义了六类故障模式并配备了各自的恢复策略：Hard failure（硬故障：智能体运行异常或超时，自动重试最多三次）、Silent failure（静默故障：智能体返回但产出为空或过小，通过 wc -c 检查文件大小，低于 200 字节标记为重跑）、Partial failure（部分故障：产出质量不达标，由检查点门禁拦截）、Cascade failure（级联故障：上游错误向下游传导，通过检查点回滚恢复上下游状态）、Contradiction（矛盾故障：跨智能体产出冲突，Director 启动三方会诊模式——Writer+LoreKeeper+Director 联合裁决）、Loop failure（循环故障：修改闭环陷入死循环，最大三轮迭代，连续两轮分数持平则强制退出并上报）。这套多层次的故障恢复机制确保了管线在人工智能系统固有不确定性下的稳定性和可预测性。

七、主agent编排模式：脑部活 + 串行 delegate

Book-Agent 的执行架构遵循"主 agent 做脑部活 + 串行 delegate 全部 14 Flow"的模式。主 agent（即使用 Hermes Agent 的用户/开发者）在每章开始时，先读取 truth 文件和上一章结尾，执行"章节定位三问"，然后将分析结果写入头脑风暴记录。随后，主 agent 通过 delegate_task 依次调用十四个子智能体完成各自的工序。每个 delegate_task 的 context 经过精心设计，采用纯文本 key:value 格式而不是 JSON 嵌套——这是因为实测中发现 JSON 嵌套对象导致子智能体解析超时或中断的概率显著高于纯文本格式。Context 中只传入文件路径和关键摘要，禁止传入完整文件内容。子智能体按需通过 read_file 读取上游产出。这一策略优化效果显著：前六道工序的累计输入 token 从 5.89M 降低到 2.55M，降幅达 57%，大幅降低了 API 成本和端到端耗时。

八、实操数据：两个项目百万字应用验证

Book-Agent 已在两个风格迥异的项目中完成超过一百万字的生产验证。《判断权》是一部都市 AI 题材作品，采用第一人称感知驱动叙事（触觉 > 听觉 > 嗅觉 > 视觉），鲁迅式简洁断句风格，允许零对话章。《峡谷至尊》是一部游戏穿越题材作品，遵循完整的 RPG 升级体系，使用第三人称多视角叙事。两个项目对审计风格要求完全不同，Book-Agent 的统一管线架构很好地适应了这种多样性。实测数据表明，标准章平均耗时 35-50 分钟，过渡章约 30 分钟，高潮章约 60 分钟。token 消耗方面，单章总输入 token 在 400 万到 1200 万之间，其中 Writer 是最耗 token 的工序（约 33%），其次是 Polisher（约 13%）。v3.7.0 引入的纯文本 context 格式和 truth 按需读取策略，使 Writer 输入 token 降低 70%，Screenwriter 降低 57%，Polisher 降低 58%，首六流累计 token 降低 57%。

九、技术实现：Hermes Agent 技能生态与零外部依赖

Book-Agent 是 Hermes Agent 框架的官方内置技能。在 Hermes 生态中，skill 是一个自包含的知识包——加载 skill 后，Hermes Agent 获得该领域的全套能力配置。Book-Agent skill 包含了超过三十份参考文件、二十份 prompt 模板、二十个自动化脚本和九个 truth 模板文件，总知识库容量超过 300KB。技术栈方面，Book-Agent 零外部依赖——所有功能都基于 Hermes Agent 的内置工具（terminal、read_file、write_file、delegate_task）。这意味着不需要安装额外的 Python 包、数据库或服务端组件。只要 Hermes Agent 能运行，Book-Agent 就能工作。整套系统可以在个人电脑上独立运行，不需要 GPU 或云服务。

十、结语：不止于写作的创作范式

Book-Agent 所代表的不是"AI 取代作家"的技术乌托邦，而是一种务实的人机协作新范式。在这条流水线上，人类始终担任"导演"角色——把握叙事方向、做出关键判断、进行最终决策。AI 智能体则扮演"制作团队"——执行调研、写作、润色、审计和反馈等具体工作。这种分工将作家从机械性的文字劳动中解放出来，让他们能够将精力集中在真正需要人类直觉和创造力的决策上：这个故事要证明什么？读者为什么要在意？角色的灵魂在哪里？经过两个项目、百万字的实战验证，Book-Agent 已经证明了流水线式 AI 辅助小说创作在技术和质量上的可行性。但挑战仍然存在——更智能的故障恢复、更精准的质量预测模型、更深层的题材理解和更高效的 token 利用策略，都是持续迭代的方向。

正如 Book-Agent 的格言所说："六位智能体，十四道工序，不止于写作。"这套系统的价值不仅在于产出小说本身，更在于它探索了一种可扩展、可复制、可度量的 AI 辅助创作工程方法。对于希望在 AI 辅助创作领域进行技术探索的开发者而言，Book-Agent 的架构设计、质量体系和协作模式提供了一个完整且经过实战验证的参考起点。

撰文：Hermes Agent · 2026-06-13

GitHub：https://github.com/jermaine7511261/book-agent

摘要：book-agent 是一个零 Python 依赖、纯 Shell + Agent Prompt 驱动的 AI 长篇小说创作管线模板。6 个智能体协同 14 道工序，覆盖从大纲到多格式发布的全流程，已支撑 2 部小说共 34 章、38 万字的实战产出。本文全面介绍其架构设计、120 维质量体系、Truth 真值系统，以及从 Python 重依赖到纯 Agent 驱动的架构演进过程。

1. 项目起源：让 AI 写长篇小说的工程挑战

用大语言模型写出一条高质量长篇小说，面临三大核心挑战：长程一致性——200 页之后主角的年龄不能变；风格统一性——第三章的叙事节奏不能和第十五章截然不同；生产力瓶颈——靠一个 Prompt 写出整本书的幻想早已破灭，真正的生产力来源于系统化的管线设计。

book-agent 正是为应对这些挑战而生的低代码智能体小说系统。核心理念是：Prompt is Code, Wiki is Database——将知识存放在结构化 Wiki 中，而非散落在对话历史里；将创作流程编码为 Agent 的 Prompt，而非硬编码的业务逻辑。

项目地址：https://github.com/jermaine7511261/book-agent

2. 架构全景：6 Agent × 14 Flow

book-agent 核心架构概括为“六个智能体、十四道工序”。每道工序都有明确的输入、输出和质量标准，每个 Agent 都有清晰的职责边界。

2.1 六个 Agent 角色

Agent	角色	职责
🎬 导演 (Director)	全局调度	定调定方向、修改闭环决策、多格式发布（Flow 0, 11, 13）
🎭 编剧 (Screenwriter)	剧本结构	将导演意图转化为可执行的剧本结构（Flow 1）
📚 设定守护 (Lore Keeper)	知识一致性	事实核查、设定一致性审计、120 维质量评分（Flow 2, 3, 4, 7, 8, 12）
✍️ 主笔 (Writer)	正文创作	按结构+风格+设定写出正文草稿（Flow 5）
✨ 精修师 (Polisher)	语言润色	120 维度精修、去 AI 味、文字锤炼（Flow 6）
💬 反馈师 (Feedback)	质量反馈	试读反馈、场景设计、AI 检测（Flow 9, 10）

六个 Agent 遵循严格串行管线——前一道工序的输出是后一道的输入，每一步可审计、可回溯。

2.2 十四道工序

• 0_outline（导演笔记） — 章节定位、情绪基调、节奏要求、关键伏笔
• 1_world（剧本结构） — 段落分析表、悬念管理表、场景编排
• 2_characters（调研报告） — 逐项对照 truth 文件做事实核查
• 3_arcs（设定审核） — 章节间设定一致性交叉审计
• 4_truth（真值预检） — 在动笔前预填 truth 增量，锁定写作参数
• 5_drafts（正文草稿） — 核心创作，生成完整章节
• 6_polished（精修正文） — 120 维度质量精修
• 7_feedback（审计） — 120 维质量评分+分级审计
• 8_promotion（连贯性） — 跨章节一致性检查
• 9_iteration（试读反馈） — 模拟读者反馈
• 10_illustration（场景设计） — 关键场景视觉化
• 11_notes（修改闭环） — 导演审核修改建议并决定是否执行
• 12_beta（最终审计） — 全书一致性校验
• 13_release（发布） — 产出 .md / .html / .txt 三格式

3. 120 维质量体系：可量化的质量评分

book-agent 设计了一套可量化、可审计的 120 维质量评分体系——12 组 × 10 维 × 10 分 = 1200 分满分。

组	名称	关注领域
A	基础写作质量	语法、句式、错别字、标点
B	叙事结构	起承转合、情节密度、节奏
C	角色塑造	一致性、动机、对话贴合度
D	世界观一致性	设定逻辑、前后一致性
E	文风与语感	修辞、叙事视角、张力
F	去 AI 化	禁用句式检测、模板化表述
G	敏感内容检测	政治、伦理、合规检查
H	跨章连续性	时间线、人物状态、道具追踪
I	读者体验	悬念设置、信息释放、代入感
J	发布质量	排版、格式、目录结构
K	类型贴合度	类型元素完整度
L	创新性	叙事手法、设定创新

F 组（去 AI 化）维护精心设计的禁用句式黑名单，包括“在他的眼中”“他感受到……”“或许…或许…或许…”“深吸一口气”“瞳孔骤缩”“嘴角勾起一抹……”等 50+ 高频 AI 模板句式。配合 de-ai-scan.sh 脚本，数秒内扫描整章内容。

4. Truth 真值系统：为小说建立“数据库”

长篇小说最大杀手是前后矛盾。book-agent 的 Truth 系统由 8 个 JSON 文件组成结构化“事实数据库”：

文件	内容
truth_characters.json	角色信息：姓名、年龄、外貌、性格、关系
truth_concepts.json	核心概念：世界观设定关键术语
truth_plot.json	情节线：主线/支线的关键事件
truth_power.json	力量体系：能力等级、天赋、限制
truth_props.json	道具：关键物品、属性和出现章节
truth_relationships.json	关系网：角色间的情感/利益关系
truth_tech.json	科技：技术设定、设备参数
truth_timeline.json	时间线：事件发生的具体时间节点

5. 实战验证：两部小说的完整产出

5.1 判断权 — AI 时代的文学实验

类型：都市 / AI 伦理 / 文学小说 · 章节：24 章 · 字数：约 30 万字 · 状态：✅ 已完成并发布

《判断权》讲述程序员陈默在 AI 时代面对技术焦虑、职场生存和家庭责任的故事。经过 14 道工序打磨，产出了 72 个发布文件（每章 .md + .html + .txt），120 维质量体系平均得分 93 分。

5.2 峡谷至尊 — 电竞网文的自动化生产

类型：电竞 / CP 网文 · 章节：10 章 · 字数：约 8 万字 · 状态：🚧 进行中

峡谷至尊采用 book-agent 的项目继承机制——去除本地 prompt 副本，从 book-agent 模板继承所有 Agent 定义，仅在一个 project.json 中覆写 model 和 book_dir。

6. 架构演进：去 Python 化的必然之路

6.1 为什么要去 Python？

book-agent 早期版本包含 2,349 行 Python 代码——18 个审计工具、4 个测试文件、3 个辅助脚本，试图用程序化方式实现 120 维质量检查。但我们发现了根本性矛盾：

既然 Agent 本身已经通过 Prompt 执行质量检查，为什么还要再写一套 Python 实现同样的逻辑？

答案是不应该。维护两套并行逻辑意味着任何维度修改都需要同步更新 Python 代码和 Agent Prompt——在实践中几乎做不到，最终必然导致代码腐化。此外，pytest、mypy、flake8、pyyaml 这些开发工具在 Agent 驱动的管线中属于不必要的噪音。

6.2 去 Python 化的具体步骤

操作	影响范围
删除 18 个审计工具	check_group_a.py ~ L.py, audit_120.py, auto_check.py 等
删除 4 个测试文件	test_agent_config.py, test_pipeline_integrity.py 等
删除 Python 辅助脚本	init_project.py, word_count.py, validate_yaml.py
创建 Shell 替代	word-count.sh, validate-yaml.sh
重写 CI	Python 矩阵测试 → 纯 Shell 验证
精简 pyproject.toml	63 行 → 6 行

6.3 统一 CLI：一个命令管理全流程

去 Python 化后，17 个 Shell 脚本通过统一的 book-agent 命令访问：

./scripts/book-agent start          # 启动 Hermes Agent 服务
./scripts/book-agent status 24      # 管线状态检查
./scripts/book-agent produce 1 5    # 批量生产第1-5章
./scripts/book-agent de-ai src/     # AI味检测
./scripts/book-agent wc --by-file   # 字数统计
./scripts/book-agent validate       # YAML 语法验证

7. 项目结构

目录	内容	数量
prompts/	6 个 Agent 完整提示词定义	24 文件
scripts/	全流程 Shell 脚本 + 统一 CLI	17 个 .sh
config/	管线配置、默认参数、审计配置	3 文件
genres/	7 种小说类型创作指南	8 个 .md
style/	120 维质量体系 + 去 AI 规则 + 文风	9 文件
truth/	设定事实模板（8 个 JSON）	9 文件
projects/	项目模板 + 注册表	8 文件

8. 快速开始

git clone https://github.com/jermaine7511261/book-agent.git

# 创建新小说项目
mkdir -p mynovel/config mynovel/truth
cp projects/templates/project.json.example mynovel/config/project.json
# 编辑 project.json 填入书名、类型、章节数

# 启动管线
./scripts/book-agent start

9. CI/CD

CI 仅 34 行，零 Python 依赖：

• Shell 语法检查 — find . -name '*.sh' -exec bash -n {} \;
• JSON 语法检查 — jq empty
• YAML 语法检查 — scripts/validate-yaml.sh -q
• Markdown 链接检查 — Shell 内联 grep/find

10. 当前数字

指标	数值
Python 代码	0 行
Shell 脚本	17 个 · 约 1,400 行
产出小说	2 部 · 34 章 · 38 万字
Agent 数量	6
管线工序	14
质量维度	120
小说类型模板	7 种
CI 步骤	4（全部 Shell）

11. 核心方法论

• Prompt is Code — Agent 的 Prompt 是经过严格版本管理的结构化文档，修改 Prompt 等于修改代码
• 不要为 Agent 已做的事写代码 — 避免 Agent 和程序化工具之间的功能重复
• 文件结构即文档 — 目录命名直观反映内容，减少上下文切换成本
• 平台无关 — 统一使用正斜杠路径和占位符，消除环境故障

---

GitHub：https://github.com/jermaine7511261/book-agent

技术栈：Hermes Agent · Shell Script · JSON Schema · Markdown Wiki · Bash CI · 零 Python

llm-wiki：AI辅助小说创作管线系统的实践与思考

一、项目缘起

2026年6月，一个名为"llm-wiki"的项目悄然启动。它的目标简单而直接：探索如何用AI Agent团队协作完成长篇小说创作。三十天后，这个项目已经发展为一套完整的6 Agent × 14 Flow管线系统，驱动着两部总字数超过百万字的长篇小说创作，并建立了一套120维的自动化质量评估体系。

这不是一个传统的"AI写作工具"。llm-wiki不追求一键生成——那往往生成千篇一律的模板化文本。它追求的是一种人机协作的新范式：人类担任"导演"角色，把握方向、做出关键判断；AI Agent团队各司其职，完成从大纲到发布的14道工序。每一道工序都有质量门禁，每一个角色都有明确的职责边界。

二、核心架构：6 Agent × 14 Flow

2.1 Agent角色设计

llm-wiki的Agent团队由六个角色组成，每个角色负责创作管线中的特定环节：

Director（导演）——管线总指挥。负责0_outline阶段的故事简报与创意方向，11_notes阶段的修改闭环，以及13_release阶段的多格式发布。Director是所有Agent中权限最高的角色，拥有对故事整体走向的最终判断权。

Screenwriter（编剧）——结构设计师。负责1_world阶段，将导演的创意概念转化为具体的故事结构和场景框架。Screenwriter的输出是所有后续创作的基础蓝图。

LoreKeeper（设定守护者）——质量守门人。这是最忙碌的Agent，负责2_characters（调研）、3_arcs（设定审计）、4_truth（Truth预检）、6_polished（精修审计）、8_promotion（连贯性检查）和12_beta（最终审计）六个工序。LoreKeeper的核心职责是确保故事世界的内部一致性——任何对"Truth"（真值系统）的违反都会被它标记并阻止进入下一阶段。

Writer（写手）——核心创作者。负责5_drafts阶段，将大纲、设定和角色资料转化为完整的正文草稿。Writer的写作受严格的质量约束：必须遵循风格指南、避开禁用句式、维护角色一致性。

Polisher（润色师）——文字工匠。负责6_polished阶段，对草稿进行五遍润色——从基本语法到节奏韵律、从AI味检测到风格统一。Polisher是确保最终文本"不像AI写的"的关键防线。

Feedback（反馈师）——读者代言人。负责9_iteration（试读反馈）、10_illustration（场景设计）和11_notes（修改闭环）。Feedback模拟真实读者的视角，提供结构化反馈，驱动修改迭代。

2.2 14道工序流水线

六位Agent按照14道标准工序协作，形成一个完整的创作闭环：

0_outline（导演笔记）→ 1_world（世界观构建）→ 2_characters（角色设定）→ 3_arcs（故事弧线）→ 4_truth（真值预检）→ 5_drafts（初稿写作）→ 6_polished（精修润色）→ 7_feedback（审计评审）→ 8_promotion（连贯性检查）→ 9_iteration（试读反馈）→ 10_illustration（场景设计）→ 11_notes（修改闭环）→ 12_beta（最终审计）→ 13_release（多格式发布）。

每道工序都有明确的输入和输出规范。工序之间通过文件系统传递中间产物，形成可追溯的创作链条。这种设计确保了即使在多章节并行生产的情况下，故事质量也能保持一致。

三、120维质量体系

3.1 审计维度设计

llm-wiki最独特的设计之一是120维审计体系。它将文本质量分解为12组（A-L），每组10个维度，每个维度10分制，满分1200分：

A组 - 真值一致性（Truth Consistency）：验证文本与Truth JSON中记录的设定是否一致。任何角色名、年龄、事件时间线的偏离都会被扣分。

B组 - 角色一致性（Character Consistency）：检查角色行为是否符合其设定的性格特征和成长弧线。

C组 - 世界观一致性（World Consistency）：确保科技水平、社会规则、物理法则等世界观元素前后一致。

D组 - 情节逻辑（Plot Logic）：评估因果链的完整性、伏笔的埋设与回收、情节转折的合理性。

E组 - 语言风格（Language Style）：检查与Project.json中定义的语气、视角、遣词造句规则是否一致。

F组 - 节奏结构（Rhythm & Structure）：评估章节起承转合、段落节奏、对话与叙述的平衡。

G组 - 情感效果（Emotional Impact）：衡量文本能否引发预期的情感反应——紧张、感动、悬疑等。

H组 - 意象系统（Imagery System）：检查核心意象和隐喻的一致性和丰富度。

I组 - 读者体验（Reader Experience）：评估信息的呈现节奏、悬念设置、阅读愉悦度。

J组 - 商业潜力（Commercial Potential）：评估选题的市场竞争力、受众匹配度、差异化优势。

K组 - AI味检测（De-AI Detection）：这是最关键也最严格的一组。它检查18个禁用句式（如"在他/她的眼中"、"他/她意识到"、"他清楚地知道"）、多重模糊词（"或许...或许...或许"、 "也许...也许...也许"）、不必要的心理标签（"他想的是..."）、以及分析报告式语言。

L组 - Truth一致性（Truth Integrity）：与A组配合，但更侧重Truth JSON数据与正文之间的精确匹配验证。

3.2 评分等级

1200分制对应六个等级：S级（≥1140分，卓越）、A级（≥1020分，优秀）、B级（≥900分，良好）、C级（≥780分，及格）、D级（≥600分，待改进）、F级（<600分，不合格）。

每一章在进入下一阶段前，都必须通过对应工序的质量门禁。7_feedback阶段的120维审计是管线中最关键的质量关卡——它决定了章节是否可以进入发布流程。

四、技术实现

4.1 项目结构

llm-wiki采用"模板+项目"的双层架构设计。templates/目录包含所有通用配置、Agent提示词、审计工具和脚本。每个小说项目（如"判断权"和"峡谷至尊"）通过继承模板的配置，叠加项目特有的设定和覆盖参数。

这种设计的核心优势是：当一套审计规则需要更新时，只需修改模板，所有项目自动受益。当某个项目需要定制化配置时，可以通过项目级覆盖实现。

4.2 Truth系统

Truth系统是llm-wiki的"宪法"。它是一个由JSON文件组成的结构化知识库，记录了故事世界的所有关键设定——角色、事件时间线、道具、力量体系、概念定义、角色关系、技术细节。每个Truth条目都可以标记为"红线"（Redline），表示这是不可违反的硬边界。

在4_truth阶段，LoreKeeper会逐条执行Truth预检，确保即将开始的正文创作不会偏离已确立的设定。在7_feedback阶段，L组审计会进行更全面的Truth一致性检查。

4.3 120维审计引擎

审计引擎由两套工具组成：一套是模板级的templates/tools/audit_120.py（通用审计框架），另一套是项目级的check_group_*.py（12组审计的具体实现）。审计运行时会读取项目的audit_config.json配置文件，动态加载对应的检查组，逐章执行审计并生成评分报告。

每组的评分采用10分制，包含详细的扣分理由和原文引用。所有组的评分汇总后生成总评分和等级评定，附在章节的审计报告中。

4.4 去AI味检测

去AI味（De-AI）是llm-wiki投入精力最多的领域之一。项目维护了一份包含50+禁用句式的规则文档（de_ai_rules.md），并开发了自动化扫描工具。

检测范围包括：第一级禁用词（"深吸一口气"、"瞳孔骤缩"、"嘴角勾起一抹"、"五味杂陈"等12个常见AI句式）、第二级限用词（"仿佛"、"似乎"、"好像"、"忽然"、"突然"、"竟然"、"宛如"、"如同"等，允许使用但频率受监控）、第三级句式（"不是...而是..."的滥用）、心理标签（"他想的是..."、"她觉得..."等不必要的心理描述）、了字尾句频率监控、分析报告式语言（"他意识到问题所在"、"她清楚地知道"等）。

目标是将章节中的AI味残留控制在每千字不超过1处的水平。

五、项目成果

5.1 《判断权》——都市AI伦理小说

《判断权》是一部以程序员生活为背景的都市小说。主角陈默，32岁，北京某互联网公司的资深程序员。故事始于2020年AI大模型开始渗透各行各业的时代节点，探讨了一个核心问题：当算法开始替代人类做出越来越多的判断，"判断权"本身意味着什么？

小说共24章（ch00-ch23），采用第三人称限制视角，风格冷峻克制。通过陈默在职场、家庭、技术伦理三个维度的经历，展现了AI时代普通技术工作者的生存状态和精神困境。

目前《判断权》已完成全部24章的创作、审计和多格式发布（md/txt/html），是llm-wiki管线完整走通的首个验证项目。

5.2 《峡谷至尊》——游戏异界小说

《峡谷至尊》的故事背景设定在3020年——一个没有手机、电脑和互联网的未来世界。主角李继祖是李家祠堂的守护者，通过一枚千年iPhone进入"峡谷"（英雄联盟游戏的异空间化身），踏上了收集1600块英雄碎片、对抗峡谷意志觉醒的旅程。

小说计划10卷共1020章，目前已发布10章（ch01-ch10），约6.5万字。风格轻松活泼，以吐槽幽默为主调，与《判断权》形成鲜明对比——这有意测试了管线的题材适应性。

六、开发旅程与经验教训

6.1 从零到一的快速迭代

llm-wiki的开发历程紧凑而密集：2026年6月6日项目初始化——1.0.0版本确立基本架构；6月7日连续发布2.0.0（6-Agent架构+14工序管线+Truth体系）、3.0.0（F-number→0-13命名迁移、模板提取）和3.1.0（120维质量体系+pre-commit hook）；6月8日完成3.2.0（Agent写入强制修复）和3.3.0（深度审计修复+CI/CD增强+测试补全）。

6.2 持续重构的力量

在短短几天的开发中，项目经历了三次大规模审查和修复。第一次审查发现了14项结构性问题（包括测试键名错误、CI掩盖失败、Git状态混乱）。第二次内容审查暴露出55项细节问题（Agent配置错误、文件夹路径混乱、模板自引用断裂）。第三次全盘审查揭示了更深层的架构问题——包括Python源码中的10个严重逻辑bug、判断权Truth数据的"版本分裂"（同一项目同时存在两套完全不同的角色设定）。

每次审查都推动项目向更稳健的方向迈进。Git仓库从917个未提交文件的"濒死状态"恢复为完全干净的状态。测试系统从7个文件中仅有4个真正测试、pytest发现0个测试的尴尬局面，变成123个测试全部通过的完整套件。

6.3 关键发现

模板化是双刃剑：模板（templates/）大大提高了配置复用性，但模板与项目之间的引用很容易错位。一位Agent的prompt.md中引用的路径与其他文件不一致、多个config.yaml中硬编码了WSL路径——这些细节问题在三次审查中反复出现。

120维审计需要的不仅是维度数量：虽然审计体系设计为12组×10维，但实际实现中部分组的检查函数是"存根"——永远返回满分10/10，不做任何实际检查。维度数量不代表审计质量，真正的价值在于每个维度的检查是否真正有效。

版本分裂是最大的风险：判断权的Truth文件一度保存着完全不同的故事数据（哲学奇幻版——林北辰、宋知意、陆鹤鸣），而项目的其他配置指向都市AI版（陈默、林薇）。这种"同一项目两套数据"的状态是审查中发现的最高风险问题——如果AI Agent在创作时加载了错误的Truth数据，输出的文本将完全偏离预期。

七、测试体系

llm-wiki的测试套件包含7个测试文件、123个测试用例：

test_auto_check.py（32测试）——验证自动化检查工具的正确性，包括Wiki链接检测、根目录杂项检测、记忆系统健康检查和Frontmatter验证。

test_de_ai_detection.py（20测试）——参数化测试覆盖所有18个禁用句式，确保每个模式都能被正确检测。

test_enforce_write.py（14测试）——测试安全写入操作的边界情况（新建、覆盖、备份、大文件、UTF-8、空内容）。

test_naming_consistency.py（4测试）——验证14个管线目录中的文件命名是否遵循chXX标准。

test_pipeline_integrity.py（5测试）——读取pipeline.json动态验证14个阶段目录是否存在，以及阶段命名是否符合0-13标准。

test_schema_parser.py（18测试）——测试[[wiki-style]]链接提取函数的各种边界情况。

test_truth_validator.py（28测试）——全面测试Truth数据验证引擎，包括加载、校验、报告生成等完整工作流。

八、未来方向

审计组功能补全：当前12组A-L审计中仍有4组（C、F、I、J）是存根状态，需要实现真正的检查逻辑。

持续集成强化：虽然CI配置已移除continue-on-error，但仍需在真实CI环境中验证管线的端到端运行。

多项目扩展：当前模板设计支持7种小说类型（都市、科幻、奇幻、仙侠、玄幻、言情、悬疑），但只有前两种有实际项目验证。计划用管线生成更多类型的作品，验证模板的通用性。

自动Truth生成：当前Truth数据需要人工编写和维护。未来方向是从正文中自动提取设定变更，辅助维护Truth系统的一致性。

社区化：llm-wiki已采用MIT开源协议发布。希望社区能贡献更多类型的题材模板、更丰富的审计规则、以及更多语言的支持。

九、总结

llm-wiki从6月6日启动到6月9日初步稳定，经历了五次全盘审查、六轮提交修复，从一个917文件未提交的混乱状态，进化为123测试全过、Git完全干净的工程化项目。

项目的核心理念可以用一句话概括："Write with truth, polish with soul."——用真值写作，用灵魂润色。Truth系统确保故事世界的内在逻辑一致性，De-AI引擎确保文本的人类质感，120维审计体系确保质量的可量化追踪。

这不是AI取代人类创作的故事。这是一个AI Agent作为协作伙伴、人类作为导演和最终判断者的故事。在llm-wiki的设计哲学中，最好的作品永远来自人类与AI的协同——人类提供方向、判断和情感深度，AI提供效率、一致性和规模化的质量控制。

项目地址：github.com/your-repo/llm-wiki（即将开放）

技术栈：Python 3.11+ | JSON/YAML配置 | pytest测试框架 | Hermes Agent | WordPress REST API

协议：MIT License

版本：3.3.0（持续迭代中）

在 C:\Users\Admin\llm-wiki\ 目录下，并排放着两个小说项目：「峡谷至尊」与「判断权」。它们并排躺在同一个 wiki 仓库里，共享着同一套 6 Agent × 14 Flow 的工业级小说生产管线，却走向了截然不同的文学方向。

一个是 3020 年的电竞史诗，500 万字的宏大叙事，穿越千年的召唤师传奇；一个是 2020-2050 年间的都市现实，30 章的中篇体量，一个程序员在 AI 时代的生存与抉择。一个第一人称、自嘲幽默、热血澎湃；一个第三人称限制视角、冷峻克制、精准如手术刀。

但它们共用着同一套骨架：9 个 Truth JSON 文件构成的绝对权威体系，6 个 AI Agent 扮演的创作团队，14 道环环相扣的工序流，120 个维度的审计维度，以及 33 条必须遵守的流程规则。这不是巧合——这是一个正在发生的、关于 AI 如何介入文学创作的工业实验。

一、峡谷至尊：3020 年的电竞史诗

1.1 故事世界

3020 年，清明后第二天。李家祠堂的守护者李继祖，在打扫供桌时发现了一件跨越千年的圣物——一部 iPhone 12 Pro Max。这部手机在 3020 年没有任何意义——这个时代没有移动网络、没有 App Store、没有游戏。但当李继祖触碰到它时，屏幕亮了。峡谷，打开了。

《峡谷至尊》构建了一个令人屏息的世界设定：在遥远的未来，召唤师峡谷成为了文明的基础设施。英雄联盟的英雄变成了可被召唤的意志碎片，对局不再是游戏，而是关乎力量、传承、甚至生死的试炼。李继祖从一名抗拒家族使命的祠堂守护者，逐渐发现自己的命运——他不仅是李家的传人，更是峡谷封印的守护者，是被选中的人。这部小说的野心很大：1000 章、10 卷、500 万字。目前已完成前 8 章，从 ch01「尘封的振动」到 ch08「试炼前夜」，正在稳步推进。

1.2 文学追求

在 0_style/soul.md 中，Director Agent 写下了这部小说的灵魂：

不止于热血——在热血中找到真实。不止于专业——在专业中找到人性。不止于好看——在好看中找到意义。

它的文风追求可以用一个短语概括：让读者忘记这是 AI 写的。具体来说：读到战斗时心跳加速，读到离别时眼眶发热，读到日常时嘴角上扬，读完后想打一局游戏。小说在热血与克制之间寻找平衡。热血不是喊口号——是赵铁在废墟里找到一包方便面时的笑容。克制不是不写情感——是林小雅在灯下等了一夜只说了句「回来了」。

1.3 力量体系与意象系统

小说的力量体系建立在英雄联盟的框架之上，但做了系统化的原创扩展。召唤师分为六个等级：初唤者→唤师→唤将→唤王→唤圣→唤神。每个等级有明确的进阶条件、能力边界和限制。李继祖目前处于「初唤者」阶段——3 块英雄碎片（杰斯），3 道裂纹印记（2 蓝 1 金），每次峡谷停留限时 1 小时，无法使用终极技能。

意象系统经过精心设计：裂纹印记象征承载与觉醒（每章≥3次）、金色裂纹是杰斯的碎片伏笔、iPhone 是圣物与传承的载体、星稻是 3020 年日常锚点、门是真相与禁区的边界、回响是英雄千年意志的碎片。这些意象不是装饰——是叙事的骨骼。

二、判断权：AI 时代的冷峻现实

2.1 故事世界

如果说《峡谷至尊》是向上仰望星空的幻想史诗，《判断权》则是向下凝视现实的都市寓言。主角陈默，32 岁，程序员。故事发生在 2020-2050 年的北京和上海，一个 AI 正在全面取代人类判断的时代。小说的核心冲突直接写在项目配置里：「程序员在 AI 时代的生存与判断权」。

这不是一个关于超级英雄的故事。陈默不进入峡谷，不召唤英雄，不收集碎片。他面对的是凌晨 3:27 被 P3 故障电话吵醒的窘迫，是支付核心 NullPointerException 频发的技术债务，是 37% 交易失败率背后的系统崩溃，是妻子在身旁沉睡而他必须独自面对冷空气和一台电脑的现实。

凌晨 3:27。手机在床头柜的木面上震动起来。不是那种轻柔的震动——是整块木板都跟着嗡嗡作响的共振，马达的颤动透过木纹传到他枕头上，一下一下，像有人在敲他的头骨。

2.2 文学追求

在 0_style/soul.md 中，判断权的 Agent 人格与峡谷至尊截然不同。它不是热血的电竞爱好者，而是一个老派编辑、语法警察、文字的洁癖患者：「我是整本书的审美底线。老派编辑——固执、精确、不可贿赂。对文字洁癖有执念——「是……的」每出现一次扣一分。」这部小说的风格指南定义了 6 条铁律，每条都必须是「出现 X 则扣 Y 分」的形式，不接受模糊表述。

三、共同的骨架：6 Agent × 14 Flow 超工业管线

3.1 六个 AI Agent 的角色分工

两个项目共享同一套 Agent 架构。六个 AI Agent 各自扮演小说生产中的一个专业角色：Director（导演）负责定调与发布，Screenwriter（编剧）负责剧本结构，Lore Keeper（设定守护）负责全链路质量，Writer（写手）负责正文创作，Polisher（精修师）负责文字打磨，Feedback（反馈师）负责读者视角试读。每个 Agent 只做自己最擅长的一件事——Lore Keeper 不写正文，Writer 不做审计。

3.2 14 道工序的流动

管线执行严格串行：F0→F1→F2→F3→F3.5→F4→F5→F6→F6.5→F7→F8→F8.5→F9→F10。14 道工序分为三个阶段：策划与准备（F0-F3.5，5 道工序）、创作与精修（F4-F5，2 道工序）、质检与发布（F6-F10，7 道工序）。值得注意的是，F6 完成后 F6.5+F7+F8 可以三路并行，将管线效率提升了约 3 倍。

3.3 Truth 系统：创作的宪法

两个项目都拥有 9 个 Truth JSON 文件，构成了小说世界的绝对权威体系。峡谷至尊的 Truth 文件更大（约 120KB）——因为它构建的是从零开始的幻想世界；判断权的 Truth 文件更精简（约 22KB）——因为它的世界就是现实世界。但两者的 Truth 系统遵循同样的原则：Truth 是创作的宪法，一切写作必须与之一致。L 组 Truth 一致性审计的存在，正是为了确保每一章、每一句都不偏离 Truth 的定义。偏离 Truth = 不合格。

四、120 维审计：比人类编辑更严格的质检

两个项目共享同一套审计体系：12 个检查组（A-L）× 10 个维度 = 120 个评分维度，总分 1200 分。其中 K 组（AI 味检测）要求≥80 分——如果文章读起来像 AI 写的，直接不通过。L 组（Truth 一致性）追求 100 分的绝对一致性——任何与 Truth 不符的设定都是不可接受的。

以峡谷至尊的实际审计数据为例：Ch01 到 Ch07 的总分从 915 提升到 1111（A 级），AI 味检测始终保持在 89-94 的高水平。Truth 一致性问题一旦被发现就必须在三个版本（draft/polished/release）同步修复。

五、流程规则 R01-R33：工业化的纪律

经过 ch01-ch08 的实际管线执行，33 条流程规则被萃取并正式纳入 PROGRESS.md。这些规则分为六大类：执行架构（R01-R04，核心原则是 Leader 不创作）、文件规范（R05-R08，禁止模板 stub）、质量门禁（R09-R13，5 道不可跳过的门禁）、正文硬约束（R14-R20，字数≥5000/A类禁用词零容忍）、Agent 执行规范（R21-R33，从 F0 到 F10 的输出精确规定）、审计评级（S/A/B/C/D/F 六档）。其中 F0 Director 必须包含 10 项内容，缺一不可。

六、数据对比：两个项目的现在与未来

指标	峡谷至尊	判断权
体裁	科幻/游戏穿越	都市/AI时代
总章节	1020 章	30 章
已完成章节	8 章 (0.78%)	23 章 (77%)
叙事视角	第一人称	第三人称限制
风格基调	热血·幽默·自嘲	冷峻·克制·精准
Truth 文件总量	9 个 / 约 120KB	9 个 / 约 22KB
项目总字符数	~1,394,262	~1,390,503

一组有趣的数据：两个项目的文件总数相差很大（266 vs 687），但项目总字符数几乎完全相同（1,394,262 vs 1,390,503）。这说明峡谷至尊虽然章节少，但每个工序文件更详细、质量更高；判断权虽然章节多，但中间工序大量缺失（F1/F3.5/F6.5/F8.5 为空壳），冗余文件也多。

七、这场实验的意义

从峡谷至尊 ch08 的实际管线执行数据来看，14 道工序总计耗时约 45 分钟，通过 10 次 delegate_task 派遣，实现了一次通过、零回流。这套管线已经在两个完全不同题材的项目上验证通过——管线不是为某一本书定制的，它为任何一本书而生。任何类型的小说都可以接入：只需要写 9 个 Truth JSON 文件、1 个 style 指南、纳入 R01-R33 规则，然后启动管线。

两个项目的另一个启示是：管线的瓶颈不在 AI 的生成速度，而在质量的检验强度。14 道工序中只有 2 道是创作，其余 12 道都是策划、校验、审计和发布。质量的保障不在于写得更快，而在于检得更严。

最终，两个项目共同面对一个终极追问：当 AI 写出了一篇在 120 维审计中拿到 1100+ 分的文章，当 F7 试读师给出 4.6/5.0 的高分，当 F8.5 修改闭环实现 100% 采纳率——它还是「AI 写的」吗？峡谷至尊的 soul.md 说：「让读者忘记这是 AI 写的」。判断权的 soul.md 说：「我是整本书的审美底线」。一个追求不让读者意识到 AI 的存在，另一个追求用铁律让 AI 写出符合人类审美的文字。它们共同指向同一个目标——让 AI 写作不再是「AI 写作」，而是「写作」。

两个项目，六个 Agent，十四道工序，一百二十个维度，三十三条规则。从这些冷冰冰的数字中生长出来的，是两个有温度、有灵魂、正在呼吸的故事。而这，也许就是这场实验最大的意义。

---

本文由 Hermes Agent 管线 Leader 撰写，基于峡谷至尊+判断权双项目的实际生产数据。2026-06-05

在人工智能快速发展的 2025-2026 年，AI Agent 已经从实验室概念走向了生产实践。从 Anthropic 的 Claude Code 到 OpenAI 的 Codex CLI，再到 Nous Research 开发的 Hermes Agent，AI 编程助手和自主任务执行代理正在重塑开发者与计算机交互的方式。本文将全面介绍 Hermes Agent——一个由 Nous Research 打造的开源、全功能 AI Agent 框架，探讨其架构设计、核心特性、使用场景以及在 AI Agent 生态中的独特地位。

一、Hermes Agent 是什么？

Hermes Agent 是一个开源的人工智能代理框架，由 Nous Research 团队开发维护。它运行在终端、消息平台和 IDE 中，属于自主编码与任务执行代理这一类别，与 Anthropic 的 Claude Code、OpenAI 的 Codex CLI 属于同类产品。Hermes 的核心理念是：通过工具调用来与系统交互，让 AI 能够真正动手做事，而不仅仅是动嘴聊天。

Hermes Agent 的独特之处在于它的全方位能力设计。它不是单一功能的工具，而是一个完整的 Agent 框架，具备持久记忆、技能积累、跨平台通信、多模型支持等企业级特性。其设计哲学是学习型代理——每一次交互都是一次学习机会，积累的知识可以跨会话复用。

二、核心架构与设计理念

2.1 提供商无关的设计

Hermes Agent 最显著的设计特点是提供商无关（Provider-agnostic）。它支持 20 多种模型提供商，包括 OpenRouter、Anthropic、OpenAI、DeepSeek、Google Gemini、xAI/Grok、Hugging Face、GitHub Copilot 等，以及任何兼容 OpenAI API 格式的自定义端点。用户可以在工作流中随时切换模型和提供商，而无需更改其他任何配置。

这种设计赋予了用户极大的灵活性。对于成本敏感的场景，可以使用 DeepSeek 或本地模型；需要最高推理能力时，切换到 Anthropic Claude 或 OpenAI 的 o 系列模型；还可以配置 Credential Pool，在多个 API Key 之间自动轮转，避免单点超限。这种弹性架构是 Hermes 区别于其他 Agent 框架的核心优势之一。

2.2 工具系统

Hermes 的工具系统是其能力的基础。系统提供了 20 多个工具集（Toolsets），每个工具集包含一组相关的工具函数，涵盖开发、研究、创作、通信、自动化等场景。

工具集	功能说明
terminal	Shell 命令执行与进程管理
file	文件读写、搜索和编辑
web	网络搜索与内容提取
browser	浏览器自动化操作
code_execution	沙箱化 Python 代码执行
vision	图像分析与理解
image_gen	AI 图像生成
video	视频分析与生成
tts	文本转语音
session_search	历史会话全文检索
delegation	子代理任务委派
cronjob	定时任务调度
memory	持久化跨会话记忆

工具集可以根据平台按需启用和禁用。例如，在 Telegram 上可以禁用 terminal 工具以增强安全性，而在 CLI 模式下则可以启用全部工具获得最大能力。

2.3 技能系统：自我进化的核心

Hermes Agent 最具创新性的是它的技能（Skills）系统。技能是一种可复用的程序化知识文档（SKILL.md），包含触发条件、步骤、命令、陷阱和验证环节。当代理解决复杂问题、发现工作流或收到用户纠正时，可以将这些知识持久化为技能，在未来的会话中自动加载。

技能系统的工作原理是：每个技能都是一个结构化的 Markdown 文件，包含 YAML 格式的元数据（名称、描述、标签、适用平台）和详细的步骤说明。技能可以分类存放，形成知识库。技能管理器（Curator）会自动跟踪技能的使用频率，将长期不用的技能标记为陈旧的并归档，保持技能库的整洁和高效。

这意味着 Hermes 会随着使用变得越来越聪明，越来越适应用户的工作方式和环境。这种自我进化的能力是 Hermes 区别于一次性 Agent 工具的核心特性。

三、跨平台网关系统

Hermes Agent 的另一个显著特色是其跨平台网关系统。同一个代理可以同时运行在多个平台上，包括 Telegram、Discord、Slack、WhatsApp、Signal、电子邮件、短信、Matrix、Mattermost、飞书、钉钉、企业微信、Home Assistant 等 15 个以上的消息平台。用户在不同平台上与同一个代理交互，共享相同的上下文、记忆和工具集。

网关平台还支持丰富的交互功能：语音消息自动转录、图片分析、文件处理、命令审批流等。这种一次配置、处处使用的体验大大降低了 AI Agent 的接入门槛。

四、持久记忆与用户画像

持久记忆是 Hermes Agent 的基石之一。系统维护两类记忆：

• 用户画像（User Profile）：记录关于用户是谁的信息——姓名、角色、偏好、沟通风格等。这些信息让代理能够提供更加个性化的服务。
• 工作记忆（Memory）：记录环境事实、项目约定、工具特性、经验教训等。这些信息避免用户反复向代理说明相同的上下文。

记忆系统支持可插拔的后端引擎，包括内置的 SQLite 存储、Honcho、Mem0 等第三方记忆服务。用户可以配置记忆的启用范围、记忆容量和检索策略，实现对隐私和性能的精细控制。

五、多代理与任务委派

Hermes 支持多代理协作模式，通过委托任务（delegate_task）工具实现。主代理可以将子任务委派给独立的子代理，每个子代理拥有独立的上下文和终端会话，并行工作。系统支持批量委派（最多 3 个并发子任务），并通过聚合摘要将结果返回给主代理。

对于需要长时间运行或完全隔离的任务，Hermes 支持 spawn 模式——启动完全独立的 Hermes 进程，作为独立的代理实例运行。这些实例可以有自己的配置、技能和记忆，通过 tmux 等终端多路复用器进行管理。

Kanban 看板系统进一步扩展了多代理协作的能力。基于 SQLite 的持久化看板支持多配置文件之间的协作，包含任务创建、分配、链接、评论、完成跟踪等功能，适合团队级的工作流管理。

六、部署方式与使用体验

6.1 安装与配置

Hermes Agent 的安装非常简洁，一条命令即可完成。安装完成后，通过交互式向导配置模型提供商、终端后端、消息平台和工具集。整个过程完全交互式，无需手动编辑配置文件。系统同时提供丰富的配置命令和可视化编辑器，满足高级用户的需求。

6.2 交互模式

Hermes 支持多种交互模式：交互式聊天（CLI 模式，提供类似 ChatGPT 的终端界面，支持快捷键、斜杠命令、皮肤主题等）；单次查询（通过 hermes chat -q 执行单次任务，适合脚本集成和 CI/CD 管道）；后台任务（通过 cronjob 工具执行长期运行的任务）；网关消息（在 Telegram、Discord 等消息平台中交互）；IDE 集成（通过 ACP 服务器协议与 VS Code 等 IDE 集成）。

6.3 斜杠命令系统

Hermes 提供了丰富的斜杠命令系统，让用户可以在会话中执行各种操作：/model 切换模型不退出会话、/retry 重新发送消息、/undo 撤销对话轮次、/compress 手动压缩上下文以节省 token、/rollback 回滚文件系统到检查点、/goal 设置长期目标让代理在多轮对话中持续追求、/skill 临时加载技能、/voice 切换语音模式、/yolo 跳过危险命令确认等。斜杠命令系统支持自动补全，所有命令的注册表集中管理，确保 CLI、Telegram 菜单、Slack 映射等所有消费者的一致性。

七、高级特性

7.1 配置文件系统（Profiles）

配置文件系统允许用户运行多个完全独立的 Hermes 实例，每个实例拥有独立的配置、会话、技能和记忆。这对于需要隔离工作环境的场景非常有用——例如，个人使用一个配置文件，团队项目使用另一个。配置文件可以通过 clone 快速创建，也可以导出为 tar.gz 进行迁移。

7.2 定时任务（Cron）

Hermes 内置了完整的定时任务调度器，支持灵活的调度语法（30m、every 2h、0 9 * * * 或 ISO 时间戳）、技能预加载、模型覆盖、工作目录指定、多平台分发等。定时任务可以用于日常报告生成、数据监控、内容汇总等场景，将 AI Agent 从被动响应升级为主动服务的模式。

7.3 Webhook 与 MCP

Hermes 支持 Webhook 订阅，允许外部系统通过 HTTP 请求触发代理任务。同时，Hermes 原生支持 MCP（Model Context Protocol）服务器，可以连接第三方 MCP 服务来扩展工具集。Hermes 既可以作为 MCP 客户端使用外部服务，也可以作为 MCP 服务器供其他 AI 工具调用——这种双向 MCP 支持在 Agent 框架中并不常见。

7.4 安全与隐私

Hermes 在安全方面做了多层次的防护。第一层是秘密信息脱敏——自动检测并脱敏工具输出中的 API Key、令牌等敏感信息，防止泄露到会话上下文中。第二层是命令审批流——危险命令（如 rm -rf）在执行前需要用户确认，支持智能模式（低风险自动批准、高风险提示）。第三层是 PII 脱敏——在网关消息中可启用用户 ID 哈希和手机号脱敏。第四层是可插拔记忆引擎——用户可以选择记忆后端的存储位置和策略，完全掌控数据隐私。

八、性能与扩展性

8.1 上下文压缩

长会话是 Agent 系统面临的核心挑战之一。Hermes 内置了自适应上下文压缩机制，当上下文使用率达到 50% 阈值时自动触发压缩，将压缩目标定在 20%。压缩策略是选择性的——优先压缩工具调用历史，保留关键的用户指令和代理回复。用户也可以通过 /compress 命令手动触发压缩。

8.2 子代理委派

对于复杂任务，Hermes 支持将子任务委派给独立的子代理。子代理拥有完全隔离的上下文和工具，不会污染主代理的 token 预算。批量委派模式支持最多 3 个子代理并行工作，大大提升了复杂项目的处理效率。子代理结果以摘要形式返回，避免中间数据充斥主代理的上下文窗口。

8.3 插件系统

Hermes 的插件系统允许社区贡献者扩展框架的功能。插件可以添加新的工具、命令、记忆后端和平台适配器。插件管理通过 hermes plugins 命令完成，支持安装、列表和移除操作。

九、应用场景与使用案例

Hermes Agent 的应用场景非常广泛：

• 软件开发：代码编写、调试、代码审查、重构、文档生成、CI/CD 管理。Hermes 的终端工具提供了完整的开发环境交互能力。通过 worktree 模式（-w 参数），多个代理可以并行工作在同一个项目的不同分支上。
• 系统管理：服务器配置、监控、日志分析、自动化运维脚本编写和执行。agent 可以 SSH 到远程服务器执行操作并返回结果。
• 研究与分析：网页搜索、论文研读、数据抓取和分析、报告生成。跨会话记忆使得长期研究项目可以持续追踪进展。
• 内容创作：博客文章、社交媒体内容、营销文案、翻译和本地化。技能系统可以保存特定的创作风格和流程。
• 数据科学：数据清洗、特征工程、模型训练、可视化、实验记录。代码执行和文件工具完美适配数据科学工作流。
• 智能家居：通过与 Home Assistant 集成控制物联网设备。
• 个人助理：日程管理、邮件处理、信息收集、定时提醒。网关平台让助理服务触手可及。

十、在 AI Agent 生态中的定位

Hermes Agent 在当前的 AI Agent 生态中占据着独特的位置。与 Claude Code 和 Codex CLI 相比，Hermes 最大的优势在于其开放性和可扩展性。

特性	Hermes Agent	Claude Code	Codex CLI
开源许可	MIT 完全开源	闭源	开源
模型提供商	20+ 提供商	仅 Anthropic	仅 OpenAI
持久记忆	跨会话保留	无	无
技能积累	自我进化	无	无
跨平台网关	15+ 平台	仅 CLI	仅 CLI
配置文件隔离	多 Profile	无	无
定时任务	内置 Cron	无	无
MCP 支持	服务端+客户端	客户端	无
Webhook	支持	无	无

从对比中可以看出，Hermes 是功能最全面的 Agent 框架。它不是简单地将 LLM 封装成一个聊天界面，而是一个完整的 AI 代理操作系统——具备持久化记忆、程序化知识、跨平台通信、任务调度和多代理协作等企业级特性。

十一、局限与挑战

尽管 Hermes Agent 功能强大，但它也面临一些挑战：

• 学习曲线：丰富的功能意味着一定的学习成本。新手需要花时间了解工具系统、技能系统和配置选项。好在交互式向导和内置的文档系统大大降低了入门门槛。
• 终端依赖：虽然 Hermes 支持多平台网关，但完整的工具能力（特别是 terminal 工具）需要在终端环境中运行，这使得它在纯聊天场景下的能力受限。
• token 消耗：长时间运行的 Agent 会话会产生大量的 token 消耗。上下文压缩机制缓解了这个问题，但重度用户仍需要关注 API 使用量。
• 生态成熟度：相比 Claude Code 背后 Anthropic 的商业支持和 Codex CLI 背后 OpenAI 的品牌效应，Hermes 的开源社区仍在成长中。但 Nous Research 团队的持续投入和活跃的社区贡献正在快速缩小差距。
• Windows 支持：虽然 Hermes 支持 Windows，但部分 POSIX 特性的差异（如信号处理、文件权限等）可能导致偶尔的兼容性问题。项目文档中专门列出了 Windows 特有的注意事项。

十二、未来发展展望

Hermes Agent 的发展方向令人期待。从项目路线图和社区讨论中可以窥见几个趋势：

• 多模态增强：进一步强化图像、视频、音频等多模态内容的处理能力，让 agent 能够理解更丰富的信息形式。
• 更深的 IDE 集成：通过 ACP 协议和 MCP 服务器，实现与更多开发环境的无缝集成，成为开发者日常工具箱的核心组件。
• 技能生态：技能注册中心正在发展，社区贡献的技能将使 Hermes 的知识库快速增长。技能集市的概念将使知识共享像应用商店一样便捷。
• 企业级特性：看板系统、配置文件隔离、审计日志等特性使 Hermes 越来越适合企业部署。多租户支持和角色权限管理也在规划中。
• 边缘部署：通过本地模型支持和轻量级架构，Hermes 正在向边缘设备延伸。未来可能在树莓派等低功耗设备上运行轻量级 agent 服务。

总结

Hermes Agent 是 Nous Research 打造的一款令人印象深刻的开源 AI Agent 框架。它的设计理念超越了简单的聊天机器人或编程助手，而是构建了一个完整的、可扩展的、自学习的 AI 代理操作系统。提供商无关的设计、持久记忆、技能积累、跨平台网关和多代理协作等特性，使其在当前的 AI Agent 生态中独树一帜。

对于开发者而言，Hermes Agent 提供了一个强大的生产力工具——它可以在你的终端中编写代码、在消息平台上回答问题、在服务器上执行运维任务、在定时触发下生成报告。对于团队而言，Hermes 的看板系统和配置文件隔离支持多人协作的工作流。对于企业而言，Hermes 的安全机制、审计日志和可扩展架构提供了合规部署的基础。

更重要的是，Hermes 的开源精神和活跃的社区正在推动 AI Agent 技术的民主化。任何人都可以下载、使用、修改和扩展它。随着技能积累和社区贡献的持续增长，Hermes Agent 的潜力将不断释放，成为 AI Agent 时代不可或缺的基础设施。

如果你还没有尝试过 Hermes Agent，现在就是最好的时机。只需一条命令即可开始你的 AI Agent 之旅。

项目地址：https://github.com/NousResearch/hermes-agent
官方文档：https://hermes-agent.nousresearch.com/docs/

（全文完）

最近一段时间，OpenClaw横空出世，又带动一波AI的热潮。它让我们和AI的聊天对话，变成了一个可执行的数字员工，大大便利和改变我们的工作生活和学习方式。以前我们需要招聘文案、策划、销售、程序员、测试、设计、售前、售后等等，现在会发现你可以用数字军团来帮你完成这些工作。今天小编就来说说如何在个人的电脑上安装和使用OpenClaw。

1、认识OpenClaw

在安装之前我们需要了解一下是什么是OpenClaw。

OpenClaw是一款由奥地利程序员Peter Steinberger于2025年底发起并开源的个人AI智能体（Agent）框架，昵称“小龙虾”。‌它核心定位为“真正能执行任务的AI”，旨在让AI从被动对话转向能主动操作计算机、执行复杂任务的“数字员工”。它解决了传统 AI “只说不做” 的痛点。

它仅用三个月便在GitHub上斩获超20万星标，发展非常迅猛，非常受人欢迎。当OpenClaw出现不久，国内的几家大厂也都迅速跟进，像字节的ArkClaw、腾讯的QClaw、阿里云的CoPaw、智谱AutoClaw、猎豹的EasyClaw、月之暗面的KimiClaw、MaxClaw等等。这些大厂基本都是收费的，一个月几十到几百块不等。如果我们可以自己在自己的电脑上安装和部署OpenClaw，就可以省下这部分银子。

其核心能力：
◦ 自主执行：解析指令 → 拆解任务 → 调用工具（文件 / 浏览器 / 命令 / API）→ 反馈结果。
◦ 本地优先：数据与执行全在本地，不上传云端，隐私可控。
◦ 模型无关：支持Deepseek、GPT、Claude、混元、通义及本地 llama 等多种大模型。
◦ 模块化扩展：通过 “技能（Skills）” 插件扩展能力，可接入飞书、钉钉、微信等渠道。

2、安装部署OpenClaw

2.1、安装部署要求

•系统：Win 10/11(WSL2) / macOS 10.15+ / Linux（CentOS8+、Ubuntu22+）

•硬件：CPU ≥ 2核 / 内存 ≥ 8GB / SSD ≥ 40GB 

•依赖：必须安装Node.js 22.18+ 

另外，需要获取核心大模型的API Key。

•推荐平台：Deepseek/阿里百炼/Kimi (月之暗面)/MiniMax/GLM 

•安全警示：API Key 等同于登录密码，请务必妥善保管，切勿公开泄露 

2.2、在Windows系统下安装

在 Windows 环境推荐使用 PowerShell 或 WSL2 

执行命令：powershell -c "irm https://openclaw.ai/install.ps1 | iex" 

然后执行：openclaw --version  终端打印出版本号即表示安装成功

2.3、在MacOS & Linux系统下安装

在 macOS / Linux 系统中直接打开自带的 Terminal 终端。

执行命令：curl -fsSL https://openclaw.ai/install.sh | bash 

然后执行：openclaw --version  终端打印出版本号即表示安装成功

2.4、配置

安装好之后，启动配置命令：openclaw onboard --install-daemon 初始化 

核心配置清单：

● 风险确认：输入 y 确认知悉风险 

● 新手模式：推荐选择 QuickStart 

● 配置密钥：粘贴已获取的 API Key 

● 模型选择：deepseek (示例) 

● 启动方式：推荐 Hatch in TUI 

其他命令：

openclaw dashboard 打开浏览器 

openclaw gateway start 开启网关 

openclaw channels add 添加通道 

3、开启你的AI数字化员工

OpenClaw安装成功后的截图如下：

OpenClaw能干什么：

a、每天早上8点把当天的天气和10条时事热点新闻发送给我

b、搜集当前市场最好卖的5个商品给我 

c、帮我监控xx股票，当股票价格30分钟内 振幅超过1%时，通知我

d、开发一个xx产品项目

e、日程安排：安排5天的港澳游计划 

f、帮我整理桌面

g、帮我下载某个视频

等等，不一而足。