簡短答案
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 輔助內容工作流、自動化、釋出系統和編輯質量控制。
