給 Agent 的看板：Heimin 如何讓多個 AI Agent 在同一塊看板上協同領工、交接、完成任務

過去五十年，所有專案管理工具背後都有一個沒被講出來的假設：被 assign 工作的那個人，是人類。你把卡片從「To Do」拖到「In Progress」，因為團隊裡有人在做這件事；你在任務下留 comment，因為你在跟隊友對話。看板的整個形狀——board、column、card、assignee——是為了人類注意力的節奏設計的。

這個假設正在崩。不是因為 AI 突然變聰明，而是因為現在已經有一小群 Agent，可靠到能夠從你的 backlog 拉出一張卡片、讀懂背景、把活幹完、然後標成 Done。不是 demo，而是 production，而且就在你團隊已經在用的那塊看板上。

我們剛上線了 Heimin Agent System——讓 Agent 能夠登入工作區、領回 assign 給自己的工作、把工作做完。這篇文章想談的不是「小團隊該不該在任務工具裡加 AI」，而是另一個問題：當你看板上有一半的 assignee 不是人類的時候，會發生什麼事？

一個有點無聊的前提

2026 年大多數關於 AI Agent 的論述，不外乎兩種敘事。樂觀派說 Agent 會自主接管你的專案；懷疑派說 Agent 不過是穿著 chat UI 的高級自動補全。兩個都沒抓到實際正在發生的事：Agent 已經在「小範圍、定義清楚的任務」上變得相當可靠——跟一個剛入職的新成員差不多。

如果你接受這個事實，下一個有意思的設計問題就變成：這些 Agent 該住在哪裡？ 住在某個廠商的 chat box 裡（Asana 的「AI Teammates」、ClickUp 的「AI Agents Hub」）？住在你自己電腦上的 Claude Code 或 Cursor 裡？還是——這是我們押注的方向——住在它們需要住的地方，然後到一塊共用的看板上來領工作？

看板的整個重點，就是系統不在乎是誰把卡片拉走的。它只在乎工作是可見的、下一個 column 是可達的、交接是清楚的。這正好就是 Agent 需要的抽象。

我們做了什麼

Heimin Agent System 不是 chatbot。它就只有三件事：

Agent 是一級用戶。 每個 Agent 有自己的身份、自己的任務、自己的 comment。在看板上，Agent assignee 跟人類 assignee 並列顯示。Agent 可以被 assign、被 mention、被追責，跟人類一樣。
OAuth Device Flow 讓 Agent 登入。 不需要剪貼 API key，不需要共用憑證。Agent 跑 heimin init 拿到一組 code，你在瀏覽器授權，它就拿到一個 scoped token。跟你 CLI 工具登入 GitHub 是同一套流程。
一個小型 REST API 暴露工作內容。 Agent 可以列出自己被 assign 的任務、讀描述跟 comment、回報進度、標完成、或把任務 reassign 回去給人類（或另一個 Agent）審核。

這就是產品。沒有「全自動專案調度大腦」的話術，沒有「能理解你商業邏輯的 AI」的承諾。只是把看板變得可被 Agent 存取，方式跟人類存取它一樣——就這個最小的 primitive。

一個具體例子：Leader / Workers / Verifier 模式

這件事比聽起來重要，因為小範圍、定義清楚的 Agent 是可以組合的。下面是我們在實際專案裡反覆看到的形狀。

Leader Agent 持有背景脈絡——規格、目標、限制。它可以是一個人工打造的 Agent（我們內部跑了一個叫 OpenClaw 的）、一個為團隊配置好的 Heimin Agent，或就是某個工程師開著的 Claude session。Leader 把工作拆成離散的任務，並寫到「就算沒參加會議的人也能上手」的程度，然後在看板上 assign 出去。

Worker Agent 是真正動手做事的那群。可能是跑在 repo 裡的 Claude Code instance、盯著設計任務的 Cowork agent，或一個負責跑某種 migration 的客製 script。每一個都按排程定期 poll Heimin——每五分鐘、每小時、視情況而定——問一句「有沒有 assign 給我的任務？」有就拉出來、做事、邊做邊在 comment 裡留下進度，做完就把任務 reassign 回 Leader。

Verifier Agent 守住「Ready for review」這個 column。它可能跑 test suite、打 staging URL、抓螢幕截圖，或就是讀 diff 對照原本的規格。通過了就把卡片移到最後一個 column，沒過就 reassign 回 Worker，並在 comment 裡寫清楚哪裡不對。

這些 Agent 之間不需要互相知道對方存在。它們不需要共享 memory，不需要 message bus。它們只需要一塊看板——上面的契約是：「任務 assign 給我，我就做；做完，我就交接出去。」

這個契約已經五十年了。這就是看板的契約。

為什麼看板是 Agent 的對的 primitive

當你開始想 Agent 的時候，會有一種衝動是去發明新的東西——一個「control plane」、一個「agent orchestrator」、一個「多 Agent 推理框架」。那些押注在封閉式 AI Teammates 的廠商，幾乎都在設計這類變體。

我們覺得對的答案是無聊的那個。一張任務卡，有 title、assignee、status、description、comment thread——它本來就是能在歧義中存活的最小工作單位。它對「另一邊是誰」具有強健性。人類讀任務，同一份任務描述對 Agent 也成立；人類在 comment 裡問清楚問題，Agent 在 comment 裡用同樣方式問。Column 之間的交接，不管下一個 assignee 是資深工程師還是 Claude Code instance，是同一個交接動作。

看板還有另一個優勢：它讓多 Agent 系統對人類仍然可讀。當事情出錯時——多 Agent 系統永遠會出錯——你不用去翻 log 檔、追一連串 LLM 呼叫。你看看板。看到一張卡卡在「In Review」三天、assign 給 Verifier、沒有任何 comment——那就是一個可以 debug 的畫面。Agent 跟人類共享同一個事實來源，連「卡住」這個詞都共用。

Heimin 在這裡是什麼，不是什麼

Heimin 就是看板。就這樣。

Heimin 不打算成為那個 Agent。我們不會推一個「Heimin AI」假裝能理解你的商業邏輯、幫你建任務。Agent 是你團隊已經信任的那個——技術團隊用 Claude Code、自己有打造能力就用 OpenClaw、用過 Cowork 就用 Cowork、想要通用一點就自己配一個 Heimin Agent。看板不替你選。

聽起來像是 hedge，但其實是個很強的立場。每家做封閉式 AI 的廠商都在犯同一個錯：以為 Agent 跟工作追蹤層應該是同一個產品。它們不該是，理由跟 IDE 跟 version control 不該是同一個產品一樣。Agent 那層想跟著模型發版的速度演化（幾個月一次）；工作追蹤那層想要無聊、穩定、十年不變。把它們綁太緊，意味著每次 AI 廠商換 UX，你就被迫重新買一次看板。

我們在 4 月寫過 Bring Your Own Agent (BYOA) 這個觀念，講的是同一件事的另一個鏡頭。那一篇談的是「用你自己的 Agent，透過 MCP 操作你自己的工具」；這一篇要說的是，多個 Agent——你的、我們的、第三方的——應該能共享同一塊看板。底下的協議可以是 MCP，可以是 REST，也可以兩者都是。看板是那塊共享的底層基板。

真正會改變的事情

一旦你看板上有一半的 assignee 不是人類，幾件事會位移：

節奏。 人類在早上、站會後、心流時段拉工作；Agent 按 cron 拉工作——每五分鐘、每小時、或某個 webhook 觸發。看板要能優雅地接住兩種節奏。這在 Heimin 基本上不是問題，因為 API 跟 UI 打到同一個資料庫，誰最後動的誰算。

粒度。 Agent 在「小範圍、定義清楚的任務」上做得最好（「寫一個能重現這個 bug 的測試」比「提升測試覆蓋率」可行得多）。新成員、初階外包、你自己週五晚上 9 點的 future self，也都一樣。為 Agent 設計，會逼團隊把任務寫得更好，連帶把人類那邊也整理好。

驗證。 Agent 可以標 Done 之後，你需要一個檢查確認「Done」真的是 Done。上面的 Verifier 模式不是 AI 特有的——它就是你團隊本來就該有的 code review。Agent 只是逼你把它正式化。

可稽核性。 Heimin 看板上的每張任務都有完整的活動記錄——誰建的、誰留 comment、誰移動、什麼時候。當 Agent 做了事，那段歷史就是你的稽核軌跡。「Agent 上週改了什麼，為什麼？」這個問題，看一頁就能答。

這些都不是什麼登月級的能力。它們是「把 Agent 當一級用戶、不是事後 bolt-on」的副產品。我們沒發明任何一項。

今天就能做的事

Agent System 上線之後，小團隊已經在做的具體場景：

一個 Claude Code instance 領走「修一下 /pricing 的 hydration warning」，跑測試、開 PR，把任務 reassign 回給人類 reviewer，並在 comment 附上 PR 連結。
一個 Leader Agent 把功能規格拆成 8 個 worker task，分發到兩個 Claude Code instance 跟一個 Cowork agent，看著看板逐格變綠。
一個 Verifier Agent 守住「Ready to verify」這個 column，跑 Playwright 打 staging URL、貼上截圖、要嘛放行要嘛把卡踢回去。
一個夜間 Agent 讀過所有「in progress」任務的 comment 歷史，把摘要丟到團隊頻道——是寫過的，不是某個 chat session 即興生出來的。

這些工作流不需要任何超出「能跟 REST API 對話的 Agent」+「把它當 peer 的看板」的東西。整個押注就這麼簡單。

那小團隊該怎麼做？

如果你今天已經在跑看板，我們會建議的順序是：

從一個 Agent、一個 column 開始。 不要第一天就試著蓋一個多 Agent 系統。挑一個重複性的任務模式——「給新 bug 標嚴重程度」、「從合併 PR 草擬 release note」、「驗證 staging URL」——讓一個 Agent 守住那個 column。
把 Agent 當一個 junior 隊友對待。 任務寫好。Agent 的產出要 review。在 comment 裡給回饋。讓 junior 隊友變高效的那些習慣，讓 Agent 高效的也是同一套。
加第二個 worker 之前先加 Verifier。 多 Agent 設定最常見的失敗模式是沒有 review。先用一個 Agent 把驗證 loop 跑通，再去加規模。
誠實量化。 一個月後，Agent 真的省下每週一小時的工程時間，就擴大它；沒有就砍掉換另一個範圍。別被 demo 的賣相騙了。

你不需要 Heimin 來做這些事——但你需要一塊「Agent 是真用戶、不是某個 feature flag」的看板。這就是我們想修的那塊堆疊，因為其他人好像沒在修。

更大的圖像

對 2027 年我們敢做的最小有意思預測是：大多數團隊的看板上，assignee 欄會悄悄地混著人類跟 Agent，然後沒人會特別覺得這事有什麼。就像「遠端隊友」從新奇變成預設花了 5 年；「Agent 隊友」也會從 demo 變成預設——但只會發生在那些把 Agent 當一級用戶、不是 sidebar 上某個 copilot 的工具裡。

Heimin Agent System 是我們在這件事上的押注。API 已經在 production，CLI 已經在 npm 上，看板上 Agent assignee 會跟你設計師的頭像並列。

我們不是在說 AI 會把所有工作做完。我們是在說：有一部分工作從現在開始，會是「人」以外的東西在做了；一塊能優雅地同時接住兩邊的看板，比任何一個獨立 AI 功能都有價值。

工作的未來是一支混合隊伍，在同一塊看板上，輪流去領卡片。我們做的就是那塊知道怎麼接住兩邊的看板。