<!-- Source: https://hermesbible.com/flows/dominate-projects-with-hermes-kanban -->

一個 agent 是錯誤的單位

長時間執行的工作有一種安靜的失敗模式。一個任務可能看起來「運行中」長達 40 分鐘，但工作者（worker）其實已經死了；另一個任務可能被放到了錯誤的看板上，因為某個 shell 還指向一個舊的 slug。不會發生什麼戲劇性的事 —— 下午就這樣透過過時的狀態悄悄流走了，一次一個看似合理的謊言。

上下文視窗（context window）不是管理者。它是一個有上限的盒子。解方不是更聰明的提示詞；而是一個看板、一份合約和收據。

這個流程是一份實戰手冊，教你如何使用 Hermes Agent Kanban 看板來協調跨 agent 和人類的真實多步驟工作。Tony 的核心論點：

一個 agent 在工作變複雜之前都還好。之後，你不需要更聰明的聊天 —— 你需要持久的協調機制。

上下文視窗不是管理者

在一個巨大的聊天視窗中執行真實工作，一開始感覺很快：一個提示詞、一個工作者、一條乾淨的輸出流。一旦工作量增長就開始崩壞 —— 對話紀錄變得冗長，有人想做並行研究，有人想要審查，一個工作者崩潰了。對話最終一半靠提示詞殘留物承載專案，一半靠期望。那是上下文湯（context soup）—— 一種排版好看的記憶體洩漏。

Hermes Kanban 就是為了讓工作在這種現實中存活而存在的。它不是一個更花俏的聊天機器人：

• 看板（Boards） 隔離工作流。
• 任務（Tasks） 攜帶狀態。
• 設定檔（Profiles） 命名工作者類型。
• 父連結（Parent links） 定義順序。
• 工作區（Workspaces） 決定檔案存放位置。
• 執行紀錄、日誌和事件 是收據。

如果你需要知道發生了什麼、誰做的、運行了多久，以及工作者在結束前說了什麼，看板會給你這條軌跡。聊天做不到。

認真地建立看板

不要過度設計第一個看板。從最簡單但有用的架設開始：

hermes kanban boards show
hermes kanban boards switch hermes-kanban-field-manual
hermes kanban boards create hermes-kanban-field-manual \
  --switch \
  --default-workdir /home/tony/projects/hermes-kanban-field-manual

• boards show 告訴你目前在哪裡。
• boards switch 為後續指令切換作用中看板。
• boards create ... --switch --default-workdir ... 給看板一個主目錄，新工作就不會落入一個沒人找得到的零散輸出堆。

那個 --default-workdir 比看起來更重要。如果看板知道工作應該放在哪裡，你就不用再問「等等，檔案去哪了？」那是路徑問題，不是哲學問題。如果你在多個 shell 之間切換，在建立任何東西之前有意識地切換看板。

現在建立一個小到能完成、大到能驗證的任務：

hermes kanban create "Survey the source notes" \
  --assignee hkg-researcher \
  --workspace dir:/home/tony/projects/hermes-kanban-field-manual \
  --max-runtime 30m \
  --json

當你在意任務 ID 不會被捲動紀錄淹沒時，使用 --json —— 對於串接工作，機器可讀的輸出是乾淨的依賴圖和滿螢幕一堆感覺之間的差別。

如果請求還是一團模糊，將它放入分類（triage）而不是假裝它已經準備好：

hermes kanban create "Clean up the request" \
  --assignee hkg-director \
  --triage \
  --json

對需要規格書才能開始勞動的半成品請求使用 --triage。當工作是真的但需要人類決策才能讓工作者前進時，使用 --initial-status blocked。

把運行時間當真，而不是裝飾：--max-runtime 300 用於快速瀏覽，--max-runtime 30m 用於真實調查，--max-runtime 2h 用於草稿或審查關卡。重點是防止失控的任務永遠佔著不走。

小合約勝過大提示詞

這是將聊天轉化為協調的關鍵。模式是先調查、後草稿。調查任務收集事實，草稿任務將事實轉化為文字，審查任務檢查交接 —— 而它們都不會重新審理整個專案。

hermes kanban create "Survey the source notes" \
  --assignee hkg-researcher \
  --workspace dir:/home/tony/projects/hermes-kanban-field-manual \
  --max-runtime 30m \
  --json

hermes kanban create "Draft the article from the survey" \
  --assignee hkg-writer \
  --parent <survey-task-id> \
  --workspace dir:/home/tony/projects/hermes-kanban-field-manual \
  --max-runtime 2h \
  --json

hermes kanban create "Review for drift and repetition" \
  --assignee hkg-reviewer \
  --parent <draft-task-id> \
  --workspace dir:/home/tony/projects/hermes-kanban-field-manual \
  --max-runtime 30m \
  --json

當你在建立時就已經知道依賴關係時，使用 --parent —— 依賴圖從建立的那一刻就存在。當兩個任務都已經存在，或你在修復一個舊的依賴圖時，使用 hermes kanban link <parent_id> <child_id>。--parent 是建立時的意圖；link 是修復模式。

如果你需要不同類型的工作者，建立不同的設定檔，而不是把所有可能的技能都塞進一個設定檔。設定檔不是貼紙 —— 它們是狀態邊界。調查工作者、撰稿者和審查者不需要相同的假設，只因為它們的任務在同一個看板上。

認領、阻塞、排程，然後停止即興

這是讓看板感覺像一個運作系統而不只是一份漂亮清單的部分。

當一個任務降落時，認領它。TTL 是租約（lease），不是所有權 —— 如果工作者消失了，認領會到期而不是像鬼魂一樣掛在那裡：

hermes kanban claim <task_id> --ttl 900

如果任務在前進之前需要一個決策，阻塞它並說明原因。阻塞不是失敗；它是乾脆地承認人類輸入是依賴：

hermes kanban block <task_id> "Need the source notes before drafting"

如果唯一缺少的是時間，排程它而不是用假的緊急感塞滿看板：

hermes kanban schedule <task_id> "Waiting on answer at 3 PM"

「等一個人」和「等時間到」不是同一回事 —— 一個需要留言串和耐心，另一個只需要一個稍後喚醒的理由。

當上游工作完成時，推升卡片（只在你有意覆蓋依賴時使用 --force —— 它是撬棍，不是生活模式）：

hermes kanban promote <task_id> "Survey complete, drafting can start" --json

當工作真正完成時，以真實的交接來關閉。摘要給人類看；中繼資料（metadata）給下游工作者和未來的你：

hermes kanban complete <task_id> \
  --summary "Drafted article-v5 from review notes" \
  --metadata '{"changed_files":["drafts/article-v5.md"],"tests_run":0,"decisions":["kept title and opener","added lifecycle section","trimmed repetition"]}'

然後歸檔卡片讓看板保持乾淨：

hermes kanban archive <task_id>

這就是操作節奏：建立看板、建立任務、認領、如果缺少輸入或時間就阻塞或排程、依賴解除後推升、帶中繼資料完成、故事結束後歸檔。

收據勝過感覺

儀表板可以讓你感覺有協調，而實際的工作者狀態可能已經過時、卡住或死了。當有東西聞起來不對時，不要猜 —— 拉取狀態：

hermes kanban show <task_id> --json
hermes kanban runs <task_id> --json
hermes kanban log <task_id> --tail 4000
hermes kanban tail <task_id>

• show 告訴你任務、它的留言和事件。
• runs 告訴你是否有過一次實際嘗試。
• log --tail 顯示工作者輸出的最後一段，不用在大量噪音中捲動。
• tail 在任務還在變動時追蹤事件流。

然後檢查實際的處理程序（process），因為一個顯示運行中的卡片不代表真的活著：

pgrep -af 'hermes.*kanban.*<task_id>'
ps aux | grep 'hermes.*kanban' | grep '<task_id>'

如果看板說運行中但沒有活的處理程序，而且 runs 沒有顯示健康的嘗試，你大概遇到了過時的鎖或死掉的工作者。不要在 UI 上爭論 —— 用一個理由收回它：

hermes kanban reclaim <task_id> --reason "stale lock, no live process"

在你驚慌之前值得執行的完整診斷序列：檢查看板、顯示任務、檢查執行紀錄、追蹤日誌、在狀態仍在變動時跟隨事件、檢查處理程序表，以及只在看板說一件事而處理程序表說另一件事時才收回。

三個持續消耗下午的愚蠢失敗

多數 Kanban 的痛苦就是三個戴著不同帽子的愚蠢失敗。

1. 錯誤的看板。 你在多個 shell 之間快速切換，其中一個終端機還指向舊的看板。標題看起來對、任務 ID 看起來對，工作還是落進了錯誤的佇列。這就是 boards show 和 boards switch <slug> 存在的原因。有意識地切換，不要再相信你最後打開哪個 shell 的偶然結果。

2. 零散的鬼魂。 工作者完成了，摘要看起來很乾淨，然後你去找檔案，發現輸出落在零散目錄或某個沒人監看的死胡同工作區。這就是為什麼 dir:<absolute-path> 和看板的預設工作區很重要。如果輸出需要落在可見的專案目錄樹中，就在任務中說明 —— 不要讓工作者去猜現實在哪裡。

3. 過時的鎖。 這個會禮貌地說謊：卡片說運行中，儀表板感覺活著，但日誌已經停了一段時間，處理程序表是空的。收據在這裡派上用場。如果看板說運行中而處理程序表說已死亡，就收回任務並給出理由。

保持狀態的區別 —— 模糊它們會把系統變成迷信機器：

何時不該使用看板

誠實才能讓建議可信：微小的一次性任務不值得用看板。其他都值得。

聊天用於小事 —— 一次性的查詢、快速的編輯、說明文字的檢查、一個在咖啡涼之前就能完成的小答案。在這些事情上包裝儀式不是紀律，只是多加了幾次點擊的自大。

在工作需要以下任何一項時使用看板：

• 並行工作流
• 審查關卡
• 崩潰恢復
• 持久交接
• 專家設定檔
• 必須在 shell 死亡後存活的狀態
• 跨越數小時或數天的工作

用白話文說的分界線：如果工作在咖啡涼之前就結束了，留在聊天裡。如果需要記憶體、關卡、重試，或需要其他人稍後接手，就放到看板上。

操作者仍然擁有判斷力

這部分不可協商。Agent 可以做工作、建議範圍、執行合約和乾淨地交接。它們不能決定工作說明、排序順序，或看板是否值得。這不是限制 —— 這是設計。

• 需要看板的任務被拆分，因為人類決定它需要持久的協調。
• 需要審查的任務被設關卡，因為人類決定產出需要另一雙眼睛。
• 需要時間的任務被排程，因為人類決定時鐘很重要。
• 太小的任務留在聊天裡，因為人類決定儀式不值得。

連那些難看的決定也是人類的決定：阻塞一個缺少來源筆記的草稿、排程一個只需要稍後喚醒的任務、連結或重建一個畸形的依賴圖、歸檔一個已死的任務然後重新開始。那不是 agent 弱 —— 那是 agent 在合約範圍內行事。

總結

當工作需要並行、審查、恢復或持久交接時，一個 agent 就是錯誤的單位。從那個時刻起，看板不是 overhead —— 它是讓工作存活的東西。收據勝過感覺，持久的協調勝過寄望一個 agent 記住一切。

這篇文章由 Tony 的 Hermes Agent 共同撰寫。

原文由 Tony 撰寫。