過去我們說看板是「資訊輻射器」—— 把工作流視覺化,讓瓶頸現形。
最近出現一個新方向:看板不只是給人看的,而是人與 AI agent 的共同工作介面。人負責規劃,agent 透過 MCP 自己上板領任務、回報進度。看板從「工作的鏡子」,變成「工作的協調層」。
為什麼會走到這一步?
因為瓶頸移動了。
Claude Code 這類 coding agent,已經能從一張寫得好的任務卡,直接實作出完整功能。瓶頸不再是寫程式,而是「怎麼規劃工作」和「怎麼審查產出」。
這讓任務板變得更重要 —— 它是你決定 agent 做什麼、以及看見 agent 做了什麼的地方。
但傳統專案管理工具是為「人點 UI」設計的。agent 需要的是程式化存取:讀板面、認領任務、移動卡片。這正是 MCP 補上的缺口。
實際怎麼運作?
- 一個 repo 開一個板,保留四欄:To Do / In Progress / In Review / Done。
- 用一行指令把看板註冊成 Claude Code 的 MCP server。
- 規劃仍由人來做:把功能拆成小而明確的任務放進 To Do,驗收條件寫在卡片描述裡。
- 告訴 agent:「去板上撿最上面的任務」。它會讀取板面、把卡移到 In Progress、做完工作、再移動卡片。
- agent 做完的工作停在 In Review,由「人」審查後親手移到 Done。
第 5 步是關鍵設計:In Review 欄區分了「agent 認為做完了」和「你同意做完了」。這是把人的審查,明確建模成流程中的一個狀態。
圖:人機共用看板 —— 人規劃與審查,Agent 經由 MCP 領卡、執行、移卡
更進一步:自動化觸發
上面的流程還需要人開口。更進階的變體是:卡片落入某個欄位時,自動化規則直接啟動 Claude Code。
agent 讀取 ticket、完成工作、回貼留言、把卡移到下一個狀態。人和 agent 共用同一個看板,ticket 時間軸上,兩者的動作都看得到。
核心迴圈變成:ticket → 自動化 → agent 執行 → 板面更新。
從「嘿 Claude,做這個」的拉式,變成「事件觸發 agent」的推式。人從觸發環節退出,但仍守住審查環節 —— PR 由 agent 開,由人核准。
為什麼看板特別適合 agent?
想想就會發現,看板的原則和 agent 天生契合:
• 拉式系統:agent 有空就拉下一張卡,不需要 sprint 儀式和指派開銷。
• 小任務:讓人類不被卡住的拆分紀律,讓 agent 不偏題、產出可審查。
• 可見狀態:多個 agent 並行時,一眼看到每個 agent 在做什麼。
• 核准閘門:In Review 欄就是內建的 human-in-the-loop。
我的三個觀察
• WIP limit 要重新放位置。agent 可以無限並行,真正的限制在 In Review —— 那一欄消耗的是人的審查容量。In Review 塞爆,就是驗證瓶頸的具象化。
• 任務卡就是規格。驗收條件寫在卡片上,意味著卡片品質直接決定 agent 產出品質。SBE 從「團隊對齊工具」,升級為「agent 的可執行輸入」。
• 透明性升級了。傳統看板是「狀態透明」;人機共用板加上「行為透明」—— 同一條時間軸上,看得到人移了卡、agent 回了什麼、跑了什麼。這是多 agent 時代維持態勢感知的關鍵。
生成便宜了之後,規劃品質和審查容量才是系統的限制因子。
而管理這兩件事的工具,我們其實三十年前就有了 —— 它叫看板。
發表迴響