1. 使用 Hermes Agent 的看板功能建立多代理工作流程 [0]

本節介紹如何使用 Hermes Agent 的看板功能來建立一個多代理工作流程，讓代理程式能協調工作、避免重複，並在一個 SQLite 檔案中實現自我修復。

1.1. 多代理系統的挑戰與看板解決方案 [0]

  1. 多代理工作流程難以實現 [0]
    1. 許多人討論多代理工作流程，但實際執行時很容易出錯。[0]
    2. 影片展示了如何讓代理程式自主進行研究、判斷和建構工具，僅需人工進行最終審核。[1]
  2. Hermes Agent 的看板功能 [2]
    1. 透過 Hermes Agent 的看板功能，可以讓多個代理程式全天候運作，進行研究、建構解決方案、產生交付物，甚至營運業務。[2]
    2. 看板功能是 Hermes Agent 近期更新的重要特色，可以在網路儀表板的「外掛程式」下找到。[10]
    3. 看板上的卡片代表不同的工作單位，代理程式會認領、處理並交接這些卡片。[13]
    4. 看板解決了多代理系統中代理程式難以協同工作的問題，避免它們互相干擾或重複工作。[26]
    5. 過去的多代理系統嘗試都面臨相同問題：如何讓代理程式協同工作而不產生衝突。[28]
    6. 沒有看板，代理程式會競相執行重複工作，浪費資源，且沒有共享的進度記憶，一旦崩潰就會失去所有進度。[29]
  3. 看板的優勢 [32]
    1. 看板是唯一的真相來源，代理程式之間不需聊天或使用訊息佇列，只需讀取和寫入看板。[33]
    2. 狀態會保留在看板上，即使系統重新啟動也能恢復。[32]

1.2. 看板的運作方式與架構 [37]

  1. 看板設計與任務分配 [37]
    1. 看板上的卡片代表不同的任務，例如「建構原型」或「製作投影片」。[39]
    2. 整個協調層是一個 SQLite 檔案，同時作為匯流排和稽核日誌。[46]
    3. 每個任務卡片包含標題、任務內容、負責人（assignee）和狀態。[50]
    4. 負責人用於路由，例如分配給「建構者」的卡片會在建構者代理程式上執行。[52]
    5. 每個代理程式都是 Hermes Agent 內部的設定檔，可以設定不同的模型和任務。[55]
  2. 任務執行流程：調度器（Dispatcher） [57]
    1. 任務卡片透過一個稱為「調度器」的迴圈變成執行中的代理程式。[57]
    2. 調度器會認領看板上「就緒」的任務，確保沒有兩個調度器同時處理相同任務。[59]
    3. 調度器會在獨立的工作空間中啟動被分配的代理程式。[61]
    4. 代理程式完成任務後，會將卡片標記為「完成」，然後迴圈繼續執行。[62]
  3. 任務自動化與依賴關係 [64]
    1. 看板的巧妙架構允許任務自動等待彼此。[64]
    2. 卡片會停留在「待辦」狀態，直到其父任務完成，然後自動提升為「就緒」。[67]
    3. 例如，一個任務可以分派給三個研究任務（驗證來源、提取背景資訊、審核現有解決方案），這些任務會平行執行。[69]
    4. 當所有子任務完成後，下一個任務會自動觸發，無需輪詢或額外程式碼。[72]
  4. 多代理系統的五大優勢 [76]
    1. 更耐用（Durable）：系統能從重新啟動和崩潰中恢復，因為看板上的所有資訊都可以復原。[77]
    2. 平行（Parallel）：多個代理程式可以同時工作，並由一個看板協調。[81]
    3. 事件驅動（Event-driven）：工作流程會自動透過圖形流動，無需輪詢迴圈。[82]
    4. 自我修復（Self-healing）：失敗的任務會被重新認領並重新啟動。[84]
    5. 可稽核（Auditable）：每次認領、評論和完成都會完整記錄，方便追溯問題。[86]

2. 實際工作流程範例：AI 代理程式痛點解決方案 [88]

本節展示一個實際的工作流程範例，該流程旨在找出 AI 代理程式使用者遇到的痛點，並自動化解決方案的建構或說明。

2.1. 問題定義與代理程式團隊 [88]

  1. 欲解決的問題 [88]
    1. 找出 AI 代理程式使用者遇到的實際痛點，然後採取行動解決。[91]
    2. 這個工作流程是透過 Claude、Obelus 4.8 和 Hermes Agent 搭配 GPT 5.5 設計的。[89]
  2. 工作流程步驟 [93]
    1. 偵測（Detect）：從網路上收集服務投訴。[94]
    2. 驗證（Validate）：根據評分標準評估每個投訴，自動剔除較弱的投訴。[95]
    3. 路由（Route）：建構修復方案或製作影片解釋解決方案。[96]
    4. 發布（Ship）：在經過一次人工審核後發布。[97]
  3. 代理程式團隊 [98]
    1. 每個代理程式都是同一台機器上的設定檔。[98]
    2. 偵察代理程式（Scouts）：
      1. X 偵察代理程式：負責在 X 平台上研究，使用 Grok 模型。[99]
      2. 網路研究偵察代理程式：檢查 Reddit、YouTube 和其他網站。[101]
    3. 協調者（Orchestrator）：位於中央，負責判斷和驅動整個流程。[102]
    4. 工作代理程式（Workers）：
      1. 研究員（Researcher）、分析師（Analyst）、建構者（Builder）、測試員（Tester） 和 影片製作人（Video Producer）。[104]
      2. 這些代理程式負責實際執行工作。[106]
    5. 流程概述：偵察代理程式進行研究並建立報告，協調者決定後續行動，其他子代理程式根據判斷執行工作。[107]

2.2. 完整工作流程管線 [109]

  1. 偵察與初步篩選 [109]
    1. 偵察階段：偵察代理程式每小時或每兩小時在 X、網路、Reddit 等平台進行研究。[111]
    2. 協調者處理報告：
      1. 接收報告後，協調者會進行去重複化，避免處理已見過的問題。[113]
      2. 根據預設的評分標準（rubric）對問題進行評分，評分標準考量問題出現頻率、是否可修復、是否為暫時性問題等。[115]
      3. 任何評分低於 65 分（滿分 100 分）的問題會被擱置。[118]
  2. 研究與決策 [119]
    1. 研究員代理程式：通過初步篩選的問題會交給三個研究員代理程式，它們平行工作以驗證問題、找出背景資訊和現有解決方案。[119]
    2. 協調者再次決策：協調者收到研究報告後，會決定：
      1. 是否建構工具來解決問題。[120]
      2. 是否製作影片來解釋解決方案。[121]
      3. 是否擱置該問題。[122]
  3. 解決方案建構與影片製作 [123]
    1. 建構方案：如果是建構工具的點子，分析師代理程式會綜合資訊並詳細闡述該點子。[123]
    2. 影片方案：如果是影片點子，影片製作人代理程式會研究相關內容並為影片建立大綱。[124]
  4. 人工審核與最終交付 [125]
    1. 唯一的人工審核關卡：這是整個流程中唯一需要人工介入的環節，所有其他步驟都是自主執行的。[125]
    2. Telegram 通知：審核請求會透過 Telegram 發送，顯示多個提案等待審核。[127]
    3. 審核選項：使用者可以選擇「批准（approve）」、「擱置（shelve）」或「修改（modify）」提案。[131]
    4. 人工審核的重要性：即使經過多層篩選，代理程式仍可能提出不合理的點子，因此人工審核可避免浪費資源。[133]
    5. 批准後的流程：
      1. 如果是工具建構提案，會交給建構者代理程式，然後由測試員代理程式進行測試。[136]
      2. 交付物通常是腳本或技能。[138]
      3. 如果是影片提案，影片製作人會根據概念建立簡報投影片和腳本講稿。[139]
    6. 最終交付物：最終的程式碼或投影片和講稿會透過相同的 Telegram 頻道交付。[140]
  5. 評分標準細節 [144]
    1. 評分標準考量：問題頻率、痛點強度、是否可解決或解釋、解決方案差距，以及與頻道和開發工作的策略契合度。[145]
    2. 通過門檻為 65 分，這個分數在實踐中取得了良好的平衡。[148]
    3. 協調者再次根據評分決定是建構、製作影片還是放棄。[150]

3. 實際操作演示與系統行為 [152]

本節透過實際操作演示，展示了多代理工作流程如何在看板上運作，包括任務的啟動、平行處理、人工審核以及系統的自我修復能力。

3.1. 啟動偵察代理程式與看板更新 [152]

  1. 啟動協調者閘道器 [157]
    1. 為了讓協調者能發送 Telegram 訊息，必須先啟動協調者閘道器。[157]
    2. 建議在 tmux 類型的 shell 中執行，因為這是一個長期運行的閘道器。[159]
  2. 啟動偵察代理程式 [161]
    1. 透過命令列介面（CLI）強制執行 X 平台研究代理程式，使用 pain point scout 技能。[161]
    2. 同時啟動網路偵察代理程式進行研究。[168]
    3. 這些代理程式會進行徹底的研究，完成報告後，看板會開始更新。[170]
  3. 看板任務進度 [172]
    1. 偵察代理程式啟動後，看板上會出現任務卡片。[172]
    2. X 代理程式的報告被協調者認領並處理。[176]
    3. 網路代理程式因檢查更多來源而仍在工作。[178]
    4. X 代理程式的報告顯示沒有符合條件的痛點，因此進入「完成」區。[180]
    5. 網路偵察代理程式的報告包含六個潛在問題，協調者開始評估這些問題。[183]
    6. 協調者會對每個問題進行評分和去重複化。[198]
    7. 原始設定為每小時執行，但可能過於頻繁，每天幾次可能更合適。[201]

3.2. 平行研究與人工審核 [205]

  1. 研究員代理程式的平行工作 [205]
    1. 協調者完成初步評估後，會啟動研究員子代理程式。[205]
    2. 每個問題會啟動三個研究員代理程式，分別負責驗證來源、研究背景資訊和現有解決方案。[208]
    3. 演示中，有 18 個工作代理程式同時平行工作，且互不干擾。[212]
    4. 先前的任務會進入「完成」區，協調者完成工作後，研究員代理程式接手。[215]
    5. 協調者也會有新的待辦任務，負責在研究員完成後將問題路由到 Telegram。[217]
  2. 協調者決策與影片/建構提案 [219]
    1. 當每個問題的三個研究員都完成工作後，任務會進入「待辦」區。[219]
    2. 協調者會判斷是建構工具、製作影片還是擱置。[222]
    3. 任務從「待辦」轉為「就緒」，然後協調者代理程式做出判斷。[225]
    4. 演示中，一個問題（「Cloud code sub agents fail when many MCP tools are configured」）被判斷為適合製作影片，影片製作人代理程式開始研究現有解決方案並建立大綱。[238]
    5. 另一個問題（「Codex VS Code extension ignores config tunnel changes」）被判斷為適合建構工具，分析師代理程式開始分析問題並提出解決方案。[245]
    6. 看板的視覺化功能讓使用者能清楚看到多個代理程式同時處理不同問題，但互不干擾。[251]
  3. Telegram 人工審核 [257]
    1. 影片大綱準備就緒後，協調者會將提案發送到 Telegram 進行人工審核。[258]
    2. 演示中收到第一個建構提案，內容是關於 Codex VS Code 擴充功能的安全配置不匹配問題。[261]
    3. 提案詳細說明了建構原因（常見問題、現有解決方案失效、範圍受限）和建議的解決方案（建構一個 Python 腳本的 CLI 工具）。[265]
    4. 使用者可以回覆「approve」、「shelf」或「modify」來處理提案。[276]
    5. 演示中選擇「approve」建構提案，建構者代理程式立即開始建構原型。[281]
    6. 隨後收到第二個影片提案，內容是關於雲端程式碼子代理程式在配置多個 MCP 工具時失敗的問題。[289]
    7. 提案解釋了為何影片有幫助（缺乏簡單指南、使用者困惑於子代理程式的靜默退出）。[296]
    8. 演示中也選擇「approve」影片提案，影片製作人代理程式開始根據研究製作影片。[302]
    9. 另一個提案被「擱置」，它會從看板上移除並進入「完成」區。[335]

3.3. 系統自我修復與最終交付物 [313]

  1. 自我修復機制 [313]
    1. 在測試階段，系統展示了自我修復功能。[313]
    2. 協調者代理程式發現影片概念的投影片和腳本被寫入臨時工作空間，導致最終交付無法引用真實檔案。[317]
    3. 系統自主意識到這是問題，並重新生成影片投影片到一個持久的輸出目錄，無需人工干預。[321]
    4. 雖然這個特定錯誤在程式碼庫中會被修復，但這展示了系統內建的恢復功能。[324]
  2. 建構工具的交付物 [339]
    1. 建構者代理程式完成了 CLI 工具（config verifier CLI）的建構，並附帶了 README 報告模板。[340]
    2. 所有測試都通過，且成品儲存在持久工作空間中。[342]
    3. 該工具是一個 Python 腳本，可以自動發現 Codex VS Code 配置的可能路徑。[346]
    4. 運行腳本後，它會生成報告，檢查配置路徑、編輯機密資訊並記錄策略值。[353]
    5. 雖然它不能完全解決問題，但提供了一個很好的起點，因為所有研究都已完成，並提供了工具的基本框架。[357]
  3. 影片製作的交付物 [365]
    1. 影片任務也已完成，可以在看板的「完成」區看到。[365]
    2. 系統生成了投影片，雖然視覺效果不如人工製作精美，但基於所有研究。[368]
    3. 這些投影片解釋了一個問題，即解決方案存在但不明確，因此影片可以幫助人們理解。[371]
    4. 這些交付物是很好的起點，但仍需人工審查和調整。[373]
    5. 最終的影片交付物訊息也會發送到 Telegram，包含事實清單、最終交接的 Markdown 檔案、投影片和腳本。[376]
  4. 總結與系統優勢 [382]
    1. 整個流程只需一個命令和一次人工審核，就能產生良好的基礎。[382]
    2. 在一次運行中，系統完成了 97 個任務。[384]
    3. 整個系統是自主運行的，除了唯一的人工審核關卡，可以透過定時任務啟動偵察代理程式。[385]
    4. 系統展示了從頭到尾的順利運行，沒有任何崩潰或重複工作。[393]
    5. 即使發生問題，系統也具備自我修復能力，能自動發現並解決問題。[394]

4. 開源工作流程模板與未來展望 [395]

本節介紹了開源的工作流程模板，並鼓勵使用者根據自身需求進行調整，同時展望多代理工作流程的發展潛力。

4.1. 開源工作流程模板 [395]

  1. 模板可用性 [395]
    1. 影片中展示的工作流程已開源，並提供了一個通用版本。[395]
    2. 該模板位於 Tombi Studio Hermes multi-agent workflow。[397]
  2. 模板用途 [398]
    1. 雖然需要使用者根據自身目的進行調整，但其骨架已完整。[398]
    2. 模板遵循相同的基本路徑：進行研究、評分、根據研究決定行動，並在中間設有人工審核關卡。[398]
    3. 該模板可以適應不同的用途。[400]

4.2. 未來展望與社群互動 [402]

  1. 多代理設定的挑戰 [402]
    1. 多代理設定雖然有趣，但也可能非常困難且脆弱。[404]
    2. 社群應持續尋找使其更耐用的方法。[405]
  2. 持續發展 [406]
    1. 影片作者將在多代理設定和代理程式工作流程領域投入更多工作。[407]
    2. 該領域仍有很大的發展空間。[408]