■ 傳統看板的一個隱藏假設
大多數 Kanban 看板都建立在一個假設上:工作是單向前進的。
任務從 To Do 出發,被人領走,進入 In Progress,最後抵達 Done。這是一個乾淨的心智模型,對人類做的、可預測的、循序性的工作來說,運作得很好。開發者領一張票、寫程式、送 PR、收到 review 意見、修改、合併——即使中間有修訂,任務整體上還是「往前走多於往後退」。
但 AI agent 的工作流不是這樣。
把任務交給 agent 之後,實際發生的事情是:agent 產出 → 人審查 → 退回 → agent 修改 → 人再審 → 也許再退回一次 → 最後核准。任務不是往前走,而是在人與 agent 之間繞圈(orbit)。
傳統看板沒有任何欄位可以承接這個循環。一張卡在 In Review 被退回給 agent 時,它該去哪裡?團隊通常有兩種做法,兩種都不好:
一是硬塞回 In Progress,結果是你失去了迭代次數的紀錄,看不出這張卡已經來回幾趟了。
二是開一個叫 Feedback Given 的模糊欄位,很快就變成一個黑洞,沒人知道裡面的卡處於什麼狀態。
這不只是板面美觀的問題。板面反映不了真實流程,你就看不清楚 WIP 在哪裡、瓶頸在哪裡、生產力該怎麼量測。
■ 更深層的問題:兩種不對稱的工作
傳統 Kanban 把所有工作視為等價——一張卡,一個工作單位。但在人機協作系統裡,其實有兩種截然不同的工作在平行發生:
一種是 agent 端的工作:處理、生成、推理、執行。
另一種是人這端的工作:審查、判斷、修正、核准。
這兩種工作不應該互相不必要地阻塞。但如果你的看板不區分它們,你就無法看出真正的限制在哪一邊——是 agent 產出太慢,還是人的審查量能不夠?
這跟我之前寫過的主題是同一件事:在 agentic coding 時代,瓶頸已經從「產出程式碼」移到「驗證與審查」。看板設計如果不把這兩種工作分開呈現,你連瓶頸移動了都看不見。
■ 什麼是迭代式 Kanban 模式?
迭代式 Kanban(Iterative Kanban Pattern)是一種板面設計,它把人與 AI agent 之間的來回互動,明確建模成一個結構化的循環,而不是線性流程。
相較於只會由左往右移動的欄位,這個模式加入了四個關鍵元素:
1. 明確的交接狀態:工作從人交給 agent、或從 agent 交回給人的那個瞬間,在板上有明確的位置。
2. 迭代次數追蹤:每張卡記錄它已經循環了幾次。
3. 平行泳道:把 agent 端的工作和人這端的審查工作分開。
4. 再入點:任務被人退回後,重新進入 agent 佇列的位置有明確定義。
背後的核心洞察是:在 AI agent 工作流裡,「完成」不只是任務做完,而是人與 agent 產出之間達成共識。板面設計如果反映這一點,你視覺化工作、排優先序、設 WIP 限制的方式都會跟著改變。
把循環顯性化之後,有三件事會直接受益:
第一,週期時間量測。你量的是 agent 的處理時間,還是「人+agent」的完整週期?這兩個數字會差很多。
第二,瓶頸辨識。工作堆積是因為 agent 太慢,還是因為人的審查是限制?
第三,agent 改善。如果你追蹤每張卡的迭代次數,就能找出哪一類任務需要更多修訂循環,回頭調整 prompt 或 agent 的設計。
■ 人機回饋循環的六個階段
在設計板面之前,先理解這個循環本身的結構。不管內容怎麼變,人機回饋循環有一個可預測的骨架:
階段 1|任務定義
人(或上游系統)定義任務——可能是一段 prompt、一張表單、或一個結構化輸入。這個階段的特徵是:人是作者,agent 是接收者。
階段 2|Agent 執行
Agent 處理任務。可能幾秒鐘(生成摘要),也可能幾分鐘(多步驟邏輯、呼叫外部 API)。人在這個階段不主動參與。
階段 3|產出審查
Agent 交付產出,人依照某種驗收標準(明示或隱含)審查。循環在這裡要嘛關閉(核准),要嘛繼續(要求修改)。
階段 4|回饋交接
如果需要修改,人提供回饋。這個回饋成為 agent 的新輸入——可能是後續 prompt、標記的段落、或結構化的修正指示。這就是大多數看板沒有建模的「再入點」。
階段 5|Agent 修訂
Agent 處理回饋,產出新版本。注意:這不等於重跑一次階段 2——這時的脈絡更豐富、任務更收斂、agent 有前一版產出可以依據。設計良好的板面會讓這個差異看得見。
階段 6|最終核准或升級
最終,產出要嘛被核准進入 Done,要嘛被升級——標記為人工接手、改走別的路徑、或放棄。這個出口條件必須被明確建模,否則任務會無限循環。
■ 板面怎麼設計:一個實用的十欄結構
以下是一個建模人機回饋循環的實用欄位結構。這不是唯一正解,但對大多數 agent 輔助的工作流來說,是很好的起點:
1. Backlog
等待指派的任務。建議加上「任務類型」欄位,之後可以分析哪類任務歷史上需要較多迭代。
2. Ready for Agent
已定義、已界定範圍、可被 agent 領取的任務。WIP 限制從這裡開始適用——不要一次倒 50 個任務進來。
3. Agent Processing
Agent 正在處理。卡片要有時間戳記,才能標記卡太久的任務(可能是 agent 失敗或 API 逾時)。
4. Awaiting Human Review
Agent 已交付產出,等人評估。這是最需要盯的欄位——卡片在這裡堆積,代表審查量能是你的瓶頸。
5. Feedback in Progress
有人正在撰寫或整理回饋。簡化版的板常省略這欄,但它能區分「等待被審查」和「正在被審查」。
6. Revision Queue
回饋已給出,任務等待 agent 處理修訂。功能類似 Ready for Agent,但專屬於迭代循環。
7. Agent Revising
Agent 正在依回饋產出修訂版。結構上類似 Agent Processing,但分開追蹤,才能獨立量測修訂週期時間。
8. Final Review
需要最終簽核才能發布或使用的工作流用這欄。可以是同一位審查者,也可以是另一位利害關係人。
9. Done
核准,產出被接受。
10. Escalated / Blocked
無法透過標準循環完成的任務——迭代太多次失敗、範圍變更、需要人工接手。這一欄是診斷金礦。
每張卡上,除了標準欄位(負責人、期限、優先序),再加上四個資訊:迭代次數(已經循環幾次修訂)、agent 信心標記(agent 有沒有標記不確定之處)、最後交接時間戳記(上一次換手是什麼時候)、任務類型或模板(這張卡由哪個工作流或 prompt 模板產生)。
WIP 限制要兩邊分開設:對 agent 端欄位(Agent Processing、Agent Revising)和人這端的審查欄位分開設限,你才能看出系統是被 agent 量能卡住,還是被人的注意力卡住。
一個常見的起點:Awaiting Human Review 限制在每位審查者 5 到 10 張卡。如果持續超過,你需要的不是催 agent,而是增加審查量能,或改善 agent 的首次產出品質。
這跟我之前寫過的主題完全一致:AI 時代的 WIP 限制,限的不再是開發者的產出,而是人的審查量能。
■ 跑起來之後,你會看到四種模式
迭代式看板運轉幾週後,一些在線性看板上永遠看不見的模式會浮現出來:
第一種,螺旋模式。
有些任務循環的次數遠多於其他任務——不是因為比較難,而是因為一開始的任務定義太模糊。在傳統看板上,它看起來就是一張普通的卡;在有迭代計數的板上,它會立刻凸顯出來。解法通常在上游:更好的任務模板、更清楚的輸入欄位、或任務交給 agent 之前先做一次簡短的人工預審。做過 Specification by Example 的人應該很熟悉這個味道——範例寫得清楚,來回就少。
第二種,審查瓶頸。
當 Awaiting Human Review 持續是卡片最多的欄位,你就有審查瓶頸。這在低估「AI 產出需要多少人工注意力」的團隊裡非常常見。解法有幾種:把審查批次化到固定時段、改善 agent prompt 品質以降低修訂率、或讓低風險產出走「自動核准加抽查」的路徑。
第三種,幽靈完成問題。
有些任務顯示為 Done,但產出從來沒有真正被使用——因為下游系統還沒準備好、需求變了、或品質勉強及格但實際上沒人敢用。對高風險工作流,要追蹤這個問題,需要再加一個 Used in Production 欄位。
第四種,修訂不對稱。
有些 agent(或某些 prompt 設定)的產出幾乎不需要修訂,有些則不停地循環。按任務類型追蹤迭代次數,就能揭露這個模式,並指出哪些 agent 設定需要調校。
■ 常見的五個實作錯誤
即使理解了迭代式 Kanban 的概念,團隊在落地時還是常犯這幾個錯:
錯誤一:把 agent 產出當成最終版。
最常見的錯誤是板面設計假設 agent 產出只需要一次審查就過。實務上,首次通過率因任務類型和 agent 品質差異很大。從一開始就假設會有迭代來設計板面。
錯誤二:把修訂當成新工作。
任務被退回修訂時,有些團隊會關掉原卡、開一張新卡。這會摧毀你的迭代歷史,讓你永遠無法量測改善趨勢。一個原始任務只留一張卡,用迭代次數遞增來記錄。
錯誤三:只在 agent 端設 WIP 限制。
團隊常在 agent 端欄位設限(因為 agent 是有限資源),卻忘了限制人的審查欄位。人的注意力也是有限資源,一樣要設上限。
錯誤四:沒有升級路徑。
如果你不定義「迭代失敗後的明確出口」,這些任務會永遠塞在板上。事先設定最大迭代次數(三到五次是常見值),超過就自動升級為人工接手或標記重做。這一點跟我之前寫的三 agent pipeline 完全呼應:Auditor 的角色之一,就是在循環失控之前把任務攔下來。沒有明確的升級條件,循環就沒有煞車。
錯誤五:量錯東西。
很多團隊把「agent 處理時間」當主要指標。但對業務成果更相關的,通常是完整週期時間——從任務建立到最終核准,包含所有修訂循環。迭代式看板讓你能分開量測這兩個數字,兩個都看,比只看其中一個有用得多。
■ 小結
傳統 Kanban 假設工作線性前進;AI agent 工作流本質上是迭代的,在 agent 與人類審查者之間來回循環。
迭代式 Kanban 用明確的交接欄位、修訂佇列、迭代計數,把這個循環顯性化。
人機回饋循環有六個階段:任務定義 → agent 執行 → 產出審查 → 回饋交接 → agent 修訂 → 最終核准或升級。
Agent 處理時間和完整人機週期時間要分開量測,它們告訴你的是系統中不同的限制。
升級條件要事先定義,最大迭代次數是防止任務無限循環的煞車。
看板的本質從來不是欄位,而是讓真實的工作流變得看得見。當工作流從「人做」變成「人與 agent 來回」,看板不跟著變,你看見的就只是一個不存在的流程。
—
出處說明:本文主要觀點整理自 MindStudio Team 於 2026 年 4 月發表的文章 What Is the Iterative Kanban Pattern for AI Agents? How to Model the Human-Agent Feedback Loop(mindstudio.ai/blog)。需要說明的是,MindStudio 是 no-code AI agent 平台廠商,原文帶有產品推廣成分;本文只取其中平台無關的板面設計概念,這些概念可以在任何看板工具上實作。
課程: 不確定時代下的大規模敏捷 – Less 入門篇 (2026/07/25)
https://agile3uncles.com/products/a003/
課程: 不確定時代下的敏捷測試 (2026/07/26)
https://agile3uncles.com/products/t005/
課程: Scrum 敏捷開發的系統性做法 – AI coding 時代的新做法 (2026/08/29)
https://agile3uncles.com/products/a004/
課程: 如何利用價值流和看板改善開發效能 (2026/08/30)
https://agile3uncles.com/products/p004/
發表迴響