# 策展 · X (Twitter) 🔥🔥🔥

> 作者：Nous Research (@NousResearch) · 平台：X (Twitter) · 日期：2026-05-04

> 原始來源：https://x.com/NousResearch/status/2050997692977844324

## 中文摘要

Hermes Agent v0.12.0 推出 Kanban(看板) 多 Agent 協作系統。

Nous Research 發布 Hermes Agent v0.12.0，引入 Kanban 插件實現多 Agent 並行工作流程，讓 Agent 從看板搶任務、互相移交，並透過即時儀表板監控進度，避免多終端切換的麻煩。系統甚至能自動規劃並製作介紹影片，展示其強大協作潛力。

**Kanban 核心功能**

Hermes Agent 的 Kanban 系統支援多 Agent 協作，每個任務由專屬 profile 執行，具備獨立工具、技能與個性。
- **多 Agent 支援**：每個任務運行於專門 profile，擁有專屬工具、技能與個性。
- **任務連結**：父子依賴關係，父任務完成後自動推廣子任務，讓工作扇出並匯聚結果後繼續。
- **共享 workspace**：Agent 透過目錄、git worktree 或臨時暫存空間移交檔案。
- **即時儀表板**：單一視圖監控團隊進度。
- **任務留言**：人類與 Agent 皆可留言，下一個接手 Agent 讀取完整討論串。
- **內建技能**：預載「kanban-orchestrator」（規劃器）與「kanban-worker」（工作者），每個任務可釘選領域專長載入專業知識。
- **持久化儲存**：基於 SQLite，承受崩潰、重啟與重開機。
- **無重複搶任務**：多 Agent 競爭時僅一人得標。
- **心跳與執行上限**：長任務維持存活，失控任務自動終止。
- **專案隔離**：單機運行多專案無串擾。

系統位於 http://github.com/NousResearch/hermes-agent/tree/main/plugins/kanban，教學見 https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban-tutorial。

**儀表板與看板結構**

儀表板開啟於 http://127.0.0.1:9119，左側導航點擊「Kanban」，與 CLI 共享 ~/.hermes/kanban.db 資料庫，所有操作雙介面同步。
看板分六欄，由左至右：
- **Triage**：原始想法，規格說明者細化後進入工作流程。
- **Todo**：已建立但待依賴或未指派。
- **Ready**：已指派，待 dispatcher 搶取。
- **In progress**：工作者積極執行，預設「Lanes by profile」分組顯示各 Agent 進度。
- **Blocked**：工作者求助人類或電路斷路器觸發。
- **Done**：完成。

頂部工具列含搜尋、tenant、assignee 篩選、「Lanes by profile」切換與「Nudge dispatcher」按鈕（立即執行一次調度而非等 daemon 週期）。點擊卡片開啟右側抽屜顯示細節，關閉分組則 In Progress 欄壓平為依搶取時間排序清單。

**情境一：單人開發功能發布**

模擬經典流程：設計 schema、實作 API、撰寫測試，三任務父子依賴。
- 建立 SCHEMA 任務：`hermes kanban create "Design auth schema" --assignee backend-dev --tenant auth-project --priority 2 --body "Design the user/session/token schema for the auth module."`，獲 ID 存於 SCHEMA 變數。
- 建立 API 任務：父設 SCHEMA，body 指定「POST /register, POST /login, POST /refresh, POST /logout.」。
- 建立測試任務：父設 API，body 涵蓋 happy path、錯密碼、過期 token、並發 refresh。

因依賴，僅 SCHEMA 入 Ready，其他待 Todo。搶取後：
```
hermes kanban claim $SCHEMA
# (設計 schema、commit 等)
hermes kanban complete $SCHEMA --summary "users(id, email, pw_hash), sessions(id, user_id, jti, expires_at); refresh tokens stored as sessions with type='refresh'" --metadata '{"changed_files": ["migrations/001_users.sql", "migrations/002_sessions.sql"], "decisions": ["bcrypt for hashing", "JWT for session tokens", "7-day refresh, 15-min access"]}'
```
SCHEMA 完成後，API 自動推廣至 Ready，下游 Agent 讀取其 summary 與 metadata（如 bcrypt 雜湊、JWT token、7 天 refresh、15 分 access），無需重讀長文件。抽屜顯示 Run History：單次 completed，含持續時間、時間戳、完整 summary 與 metadata；CLI 用 `hermes kanban show $SCHEMA` 與 `hermes kanban runs $SCHEMA` 查看。

**情境二：艦隊式並行農場**

三專員（translator、transcriber、copywriter）處理獨立任務堆疊，優化並行拉取與進度可見。
建立任務：
```
for lang in Spanish French German; do hermes kanban create "Translate homepage to $lang" --assignee translator --tenant content-ops; done
for i in 1 2 3 4 5; do hermes kanban create "Transcribe Q3 customer call #$i" --assignee transcriber --tenant content-ops; done
for sku in 1001 1002 1003 1004; do hermes kanban create "Generate product description: SKU-$sku" --assignee copywriter --tenant content-ops; done
```
執行 `hermes gateway start` 啟動內嵌 dispatcher，三 daemon 並行處理各自 assignee 池。篩選 content-ops 或搜尋「Transcribe」，見 In Progress 分組顯示：兩轉錄完成、一運行、兩待命。dispatcher 自動接力，無需人類干預清空佇列。完成時傳遞 summary 如「translated 4 pages, style matched existing marketing voice」與 metadata 如 `{"duration_seconds": 720, "tokens_used": 2100}`，供分析或下游依賴。

**情境三：角色管道與重試機制**

優於平面 TODO 清單，展示 PM 寫 spec → 工程師實作 → 審核者拒絕 → 重試批准的全鏈。
看板篩選 auth-project：三階段可見，Spec (DONE, pm)、Implement (DONE, backend-dev)、Review (READY, reviewer)，綠色父連結與子依賴。
PM 完成 spec：
```
hermes kanban complete $SPEC --summary "spec approved; POST /forgot-password sends email, GET /reset/:token renders form, POST /reset applies new password" --metadata '{"acceptance": ["expired token returns 410", "reused last-3 password returns 400 with message", "successful reset invalidates all active sessions"]}'
```
工程師實作遭阻：
```
hermes kanban claim $IMPL
hermes kanban block $IMPL "Review: password strength check missing, reset link isn't single-use (can be replayed within 30min)"
```
重試完成：
```
hermes kanban unblock $IMPL
hermes kanban claim $IMPL
hermes kanban complete $IMPL --summary "added zxcvbn strength check, reset tokens are now single-use (stored + deleted on success)" --metadata '{"changed_files": ["auth/reset.py", "auth/tests/test_reset.py", "migrations/003_single_use_reset_tokens.sql"], "tests_run": 11, "review_iteration": 2}'
```
抽屜顯示兩 Run：Run 1 blocked（阻擋原因明確）、Run 2 completed。下游審核者讀取父任務最新 summary（如 zxcvbn 強度檢查、單次 token）與 changed_files 清單。重試歷史為核心表示，非事後附加；重試 Agent 見前次失敗，直接修正而非重頭。

**情境四：電路斷路器與崩潰恢復**

處理真實故障：憑證缺失、OOM、網路瞬斷。雙防線：連 N 次失敗（預設 3）後 auto-block，避免無限抖動；崩潰偵測 reclaim 任務。
斷路器範例（deploy 缺 AWS_ACCESS_KEY_ID）：
```
hermes kanban create "Deploy to staging (missing creds)" --assignee deploy-bot --tenant ops
```
三次 spawn_failed 後 gave_up 入 Blocked，抽屜顯示三 Run 錯誤「AWS_ACCESS_KEY_ID not set in deploy-bot env」，事件日誌記錄 created → claimed → spawn_failed → ... → gave_up。CLI `hermes kanban runs t_ef5d` 列 outcome、profile、elapsed、錯誤；Telegram/Discord/Slack 通知 gave_up 事件。

崩潰恢復（migration 掃 2.4M 列，2.3M 時 OOM）：
dispatcher 輪詢 kill(pid, 0) 偵測死 PID，釋放 claim 回 Ready，下 tick 新 Agent 接手。抽屜兩 Run：Run 1 crashed（OOM at row 2.3M, PID 99999）、Run 2 completed（metadata "strategy": "chunked with LIMIT + WHERE id > last_id"）。重試 Agent 見前 crash 調整策略，metadata 助 postmortem。

**結構化移交機制**

--summary 與 --metadata 為首要移交通道，非裝飾。
下游任務 B 讀取 context 獲：
- B 先前嘗試（outcome、summary、error、metadata），避免重蹈失敗。
- 每個父任務最新完成 Run 的 summary 與 metadata，讓下游知上游「為何如何」。

取代平面看板「挖留言與輸出」的麻煩：PM metadata 寫 acceptance criteria，工程師直接見；工程師記 tests_run: 11，審核者預載清單。bulk-close 防濫用：`hermes kanban complete a b c --summary X` 拒絕（相同 summary 多任務多半錯），無旗標仍允許批次關閉行政任務。

**運行中任務檢查與進階操作**

運行中抽屜：Status Running，Run History 顯示 active（無 ended_at）；若崩潰/超時，dispatcher 關閉 Run 開新嘗試。
進階：
- `hermes kanban --help`：全子指令旗標。
- `hermes kanban watch --kinds completed,gave_up,timed_out`：即時串流終端事件。
- `hermes kanban notify-subscribe <task> --platform telegram --chat-id <id>`：特定任務完成時 gateway 通知。

Kanban 總覽詳見文件，強調事件詞彙、資料模型與 CLI 參照。此系統解決多 Agent 協調痛點，透過依賴引擎、結構手off 與故障韌性，提升 Hermes Agent 從單兵到團隊的實戰效能。

## 標籤

Agent, 功能更新, 開源專案, Nous Research, Hermes Agent
