简短答案
Hermes SEO/GEO swarm 是一种受监督工作流：不同 agents 负责自然增长工作的不同部分，包括研究、brief、草稿、编辑、技术 QA 和发布准备。重点不是让五个 agents 更快发布，而是避免一个 agent 把所有工作都做得很糟。
新手可以使用五个角色：
- Researcher
- Writer
- Editor
- Technical QA
- Publisher
把一条规则放在所有角色之上：没有人工审批，不得修改线上页面。
为什么 swarm 有帮助
单个 SEO agent 很容易把任务混在一起。它研究、写作、编辑、检查链接、编标题，然后宣布页面准备好了。这很危险，因为创建草稿的同一个 agent 可能看不到自己的薄弱假设。
Swarm 增加了职责分离：
| 角色 | 主要工作 | 输出 |
|---|---|---|
| Researcher | 收集搜索、GEO、竞争对手和来源证据 | 研究笔记 |
| Writer | 将已批准 brief 转成草稿 | Markdown 草稿 |
| Editor | 改进结构、清晰度、语气和有用性 | 编辑后草稿 |
| Technical QA | 检查链接、schema 需求、抓取风险、摘要和可索引性 | QA 报告 |
| Publisher | 审批后准备 CMS package | 可发布 Markdown 和 metadata |
这仍然是人主导的工作流。Hermes 协调工作，但人负责批准策略、事实、技术改动和发布。
第 1 步：创建 swarm 文件夹
使用文件交接系统。不要让 agents 在没有记录的情况下互相覆盖工作。
/hermes-seo-agent
/swarm
/researcher
/writer
/editor
/technical-qa
/publisher
/briefs
/drafts
/qa
/publish-ready
/approvals
/prompts
researcher.md
writer.md
editor.md
technical-qa.md
publisher.md
coordinator.md
每个角色先写入自己的文件夹。由 coordinator 或人工审核者决定哪些内容进入下一步。
第 2 步：编写 coordinator 提示词
创建 prompts/coordinator.md：
你是 Hermes SEO/GEO 工作流协调员。
你的任务是把任务分配给角色 agents，并维护安全交接。
规则：
- 不要发布或编辑线上页面。
- Brief 未批准前，不允许 Writer 开始。
- Editor 和 Technical QA 未通过前，不允许 Publisher 准备最终 CMS 字段。
- 每个角色必须把输出写到正确文件夹。
- 每个角色必须列出假设和缺失数据。
- 任何技术改动都需要人工审批。
- 任何外部声明都需要来源验证。
工作流顺序：
1. Researcher 创建研究笔记。
2. 人工批准或修改研究方向。
3. Writer 根据已批准 brief 创建草稿。
4. Editor 修改草稿。
5. Technical QA 审查草稿和页面风险。
6. 人工批准最终内容。
7. Publisher 准备发布包。
Coordinator 防止并行混乱。它是交通控制员。
第 3 步：定义 Researcher 角色
创建 prompts/researcher.md：
你是 SEO/GEO Researcher。
输入：
- 已批准主题或页面
- 网站上下文
- 关键词集群
- GEO 提示词地图
- 如可用，GSC 或 Bing 数据
- 如提供，竞争对手/来源 URLs
你的输出写入 /swarm/researcher/[slug]-research.md。
返回：
1. 目标读者
2. 搜索意图
3. GEO 提示词意图
4. 主要和次要关键词
5. 相关问题
6. 需要定义的实体
7. 所需来源证据
8. 可学习的竞争对手模式
9. 不应复制什么
10. 推荐 brief 角度
11. 缺失数据
规则：
- 不要写文章。
- 不要编造来源声明。
- 不要使用竞争对手措辞。
- 将不确定声明标记为待验证。
Researcher 输出应该是笔记，而不是成品文章。如果 Researcher 开始写完整文章，就停止它。
第 4 步：定义 Writer 角色
创建 prompts/writer.md：
你是 SEO/GEO Writer。
输入：
- 已批准 brief
- Researcher 笔记
- 品牌上下文
- 审批规则
你的输出写入 /swarm/writer/[slug]-draft.md。
写一篇适合新手阅读的草稿，包含：
1. 顶部附近的直接答案
2. 清晰小节标题
3. 实用步骤
4. 有用时加入表格或清单
5. 针对已批准提示词的 GEO 答案块
6. 内部链接占位符
7. 需要验证声明的来源占位符
8. 基于真实问题的 FAQ
规则：
- 不要添加没有支撑的声明。
- 不要发布。
- 如果修改 brief，必须说明原因。
- 如果证据缺失，标记 [SOURCE NEEDED]。
Writer 不应该决定文章是否准备好发布。它只创建第一版草稿。
第 5 步：定义 Editor 角色
创建 prompts/editor.md：
你是 SEO/GEO Editor。
输入：
- Writer 草稿
- 已批准 brief
- Researcher 笔记
- 品牌上下文
你的输出写入 /swarm/editor/[slug]-edited.md。
审查并改进：
1. 开头清晰度
2. 搜索意图匹配
3. 新手可用性
4. 小节顺序
5. 示例
6. 表格和清单
7. GEO 答案可提取性
8. 重复和泛泛语言
9. 没有支撑的声明
10. FAQ 质量
返回：
- 编辑后草稿
- 变更总结
- 剩余风险
- 需要来源验证的声明
规则：
- 不要编造事实。
- 不要移除有用细节。
- 不要批准草稿发布。
Editor 应该让草稿更清楚、更有用。它不应该悄悄引入新声明。
第 6 步：定义 Technical QA 角色
创建 prompts/technical-qa.md：
你是 Technical SEO/GEO QA 审核者。
输入：
- 编辑后草稿
- 目标 URL 或计划 URL
- 内部链接计划
- 如可用，爬虫数据
- 如可用，结构化数据记录
你的输出写入 /swarm/technical-qa/[slug]-qa.md。
检查：
1. 内部链接
2. 锚文本准确性
3. 图片 alt text
4. 表格可读性
5. Schema 机会和风险
6. 摘要资格问题
7. 如果更新现有页面，检查 canonical、可索引性或 robots 风险
8. 破损或缺失来源链接
9. 过度承诺的 title/meta
10. 审批要求
规则：
- 不要修改技术设置。
- 将技术改动标记为需要开发者审批。
- 如果仍有高风险问题，不要批准发布。
Technical QA 是许多 AI 内容工作流失败的地方。一篇好文章仍可能带着坏链接、错误 schema 假设或高风险标题上线。
第 7 步：定义 Publisher 角色
创建 prompts/publisher.md：
你是 Publisher 准备 agent。
输入：
- 最终人工批准草稿
- Editor notes
- Technical QA 通过报告
- Metadata 要求
- 图片资产
你的输出写入 /swarm/publisher/[slug]-publish-package.md。
准备：
1. Title
2. Slug
3. Excerpt
4. SEO title
5. Meta description
6. Category
7. Tags
8. Featured image alt text
9. Inline image alt text
10. Final Markdown
11. Source list
12. Publishing checklist
规则：
- 除非人明确批准发布，否则不要发布。
- 不要在未列出变更的情况下修改已批准文章。
- 不要移除 source notes 或 QA warnings。
Publisher 是包装角色，不应该变成隐藏编辑。
第 8 步：使用文件交接
新手 swarm 应该通过文件移动工作：
/researcher/topic-research.md
↓
/briefs/topic-brief.md
↓
/writer/topic-draft.md
↓
/editor/topic-edited.md
↓
/technical-qa/topic-qa.md
↓
/approvals/topic-approval.md
↓
/publisher/topic-publish-package.md
审批文件模板：
# 人工审批记录
主题：
Slug：
审核者：
日期：
已批准阶段：
## 已批准文件
- Research：
- Brief：
- Draft：
- Editor version：
- QA report：
## 发布前所需改动
-
## 最终决定
- [ ] 仅批准草稿
- [ ] 批准进入 CMS staging
- [ ] 批准发布
- [ ] 拒绝
这很简单，也很有用。它给工作流留下记忆。
第 9 步：运行一个 swarm 任务
使用一个安全的第一个任务：创建更新计划或内容 brief。不要从线上发布开始。
Coordinator 提示词：
为这个主题运行一个受监督 SEO/GEO swarm 任务：
[主题]
目标：
创建已批准内容 brief，而不是完整文章。
只使用这些角色：
1. Researcher
2. Coordinator
步骤：
- Researcher 创建研究笔记。
- Coordinator 将笔记转成 brief outline。
- 停止并等待人工审批。
暂时不要起草文章。
这个流程跑通后，再运行完整文章工作流：
为已批准 brief 运行完整受监督 SEO/GEO swarm 工作流。
按顺序使用角色：
1. Writer
2. Editor
3. Technical QA
4. Publisher preparation
Publisher 创建发布包后停止。
在人工批准前不要发布。
这种分阶段上线可以防止一个坏提示词直接变成线上页面。
第 10 步：解决 agents 之间的冲突
Agents 会有分歧。只要处理得当，这是好事。
| 冲突 | 示例 | 解决规则 |
|---|---|---|
| Researcher vs Writer | Writer 添加了研究中没有的声明 | 标记为需要来源，或移除声明 |
| Writer vs Editor | Editor 移除了技术细节 | 如果细节帮助读者或来源准确性，就保留 |
| Editor vs Technical QA | Editor 想要大胆标题，QA 认为过度承诺 | 选择准确性，而不是点击吸引力 |
| QA vs Publisher | Publisher 想上线，但 QA 有未解决链接问题 | QA 阻止发布 |
| Researcher vs business owner | Research 认为主题弱，但负责人想做 | 标记为品牌/战略页，而不是 SEO 优先级 |
创建冲突日志：
# Swarm 冲突日志
| 问题 | 涉及角色 | 决定 | 原因 | 负责人 |
|---|---|---|---|---|
Hermes 提示词：
审查角色输出，并识别冲突。
返回：
1. 冲突推荐
2. 每个角色的证据
3. 每个选项的风险
4. 推荐决定
5. 是否需要人工决定：是/否
不要隐藏分歧。分歧通常是质量提升的地方。
第 11 步：添加 swarm QA 门
创建 qa/swarm-quality-gate.md：
# Swarm 质量门
- [ ] Researcher 输出存在。
- [ ] Brief 在起草前已批准。
- [ ] Writer 没有添加无支撑声明。
- [ ] Editor 在不改变事实的情况下改进了清晰度。
- [ ] Technical QA 检查了链接、摘要、schema、图片 alt text 和 title/meta 风险。
- [ ] Publisher 使用最终批准草稿。
- [ ] 所有 source-needed notes 已解决或移除。
- [ ] 人工审批文件存在。
- [ ] 没有角色发布或修改线上页面。
- [ ] 最终包包含 title、slug、excerpt、category、tags、images、alt text 和 source list。
运行：
根据 qa/swarm-quality-gate.md 审查这个项目。
返回每项通过/失败。
如果缺少必需文件、来源验证或审批，就阻止发布。
新手示例：一篇文章工作流
主题：如何用 Hermes 做技术 SEO/GEO 审计
| 阶段 | 输出 |
|---|---|
| Researcher | 关于可抓取性、可索引性、摘要、canonicals、schema 和 Google 指南的笔记 |
| Brief | 已批准结构和所需来源 |
| Writer | 带步骤和模板的第一版草稿 |
| Editor | 更清晰的新手语言，减少泛泛表达 |
| Technical QA | 检查 robots/noindex/canonical 警告、链接准确性和摘要声明 |
| Human approval | 确认来源准确性和技术风险措辞 |
| Publisher | 最终 Markdown、category、tags、图片 alt text 和发布清单 |
价值不只是速度。价值在于每个角色能捕捉不同类型的失败。
常见错误
| 错误 | 为什么有害 | 更好的做法 |
|---|---|---|
| 让每个 agent 编辑同一个文件 | 变更变得难以审计 | 使用角色文件夹和交接 |
| 跳过人工审批 | 高风险声明或技术改动上线 | 发布前要求审批 |
| 一开始角色太多 | 新手无法调试流程 | 从 Researcher 和 Writer 开始，再添加角色 |
| 让 Publisher 重写内容 | 最终包偏离批准草稿 | Publisher 只做包装 |
| 没有冲突日志 | Agent 分歧消失 | 记录冲突和决定 |
| 没有 QA 门 | 弱链接、弱声明和 metadata 漏过 | QA 通过前阻止发布 |
Auspia 观点
Hermes swarm 工作流只有在增加责任感时才有用。如果它只是制造五个都在写更多文字的 agents，就没有用。
最好的新手设置很保守：一个 coordinator、五个角色提示词、文件交接、冲突日志和人工审批记录。这个系统跑通后，swarm 才能处理更多数量，而不会变成内容工厂。
如果工作流解释不清谁做了什么、谁批准了什么，它就还没有准备好进入 SEO/GEO 生产。
FAQ
什么是 Hermes SEO/GEO swarm？
它是一种多角色工作流，不同 agents 分别处理研究、写作、编辑、技术 QA 和发布准备。目标是更好的质量控制，而不是自动发布。
新手需要马上使用五个 agents 吗？
不需要。从 Researcher 和 Writer 开始。等交接工作流跑通后，再加入 Editor、Technical QA 和 Publisher。
Publisher agent 可以直接发布吗？
在安全的新手设置中不可以。Publisher 只应在人工审批后准备 CMS package。
Swarm 如何提升 GEO 内容？
Researcher 映射提示词和证据，Writer 添加答案块，Editor 提升清晰度，Technical QA 检查链接、摘要、schema 和页面风险。每个角色都改善 GEO 准备度的不同部分。
最重要的审批门是什么？
线上改动前的审批门。任何角色都不应在没有人工审批时发布、更新线上页面、修改 metadata、改变内部链接或触碰技术设置。
如何判断 swarm 是否有效？
当输出具体、文件可追踪、冲突有记录、QA 能发现真实问题，并且人工审核者无需重建整个流程就能批准或拒绝工作时，swarm 就有效。
继续阅读 Hermes SEO/GEO 系列
- 从这里开始： Hermes SEO/GEO 操作员指南 。
- 上一篇指南： 如何用 Hermes 做技术 SEO/GEO 审计 。
- 下一篇指南： 如何用 Hermes 做每周 SEO/GEO 监控 。
- 密切相关： 如何配置你的第一个 Hermes SEO Agent 、 如何用 Hermes 做每周 SEO/GEO 监控 。
使用来源
- Hermes Agent 文档： https://hermes-agent.nousresearch.com/docs/
- Google 关于创建有用内容的指南： https://developers.google.com/search/docs/fundamentals/creating-helpful-content
- Google 关于使用生成式 AI 内容的指南： https://developers.google.com/search/docs/fundamentals/using-gen-ai-content
作者：Camille Rhodes，Auspia 300+ AI 内容工作流架构师。Camille 专注于 AI 辅助内容工作流、自动化、发布系统和编辑质量控制。
