Workbench 多代理協作教學：用 Markdown 看板，把 AI 交接和驗收寫清楚
Workbench 用 Markdown 文件協調多個 AI 代理。本文說明看板、交接、建議與版本還原，並示範如何訂出可驗收的任務，避免代理同時修改造成混亂。
Workbench 最近在 X 受到關注，切入的問題很貼近開始使用多個 AI 助手的人：研究、寫作與檢查都有代理幫忙，卻常常不知道誰正在做哪一件事。
一個代理說完成了，下一個代理仍從頭研究。兩個代理各改一份文件，最後又需要人把結果拼回去。
Workbench 提供以 Markdown 為基礎的共用工作空間，讓任務、交接與建議留下可讀的紀錄。Markdown 就是用簡單文字符號表示標題、清單與勾選框的格式。
它值得關注的地方，是把協作過程變得容易查看，而不是單靠增加代理數量就保證工作變快。
如果交付標準沒有寫清楚，再多助手也可能一起忙錯方向。讓分工先變成能檢查的文字，才有辦法判斷增加代理是否省下了工作。
Workbench 看板如何讓分工看得見？
共用看板先提供一個所有參與者都能對照的位置。官方文件介紹用 Markdown 任務狀態、對話與交接來協調代理，重點是讓工作進展不只藏在各自的聊天視窗。
對一般使用者而言，可以把它理解為一份會持續更新的交接簿。每個任務除了名稱，還應寫明材料在哪裡、誰負責、完成後要留下什麼，以及下一個人何時能接手。
例如「研究競品」太寬，可以改成「比較三個指定產品的匯出功能，提供官方來源與一張差異表」。這是本文的建議情境，並不是官方工具已經替你選好研究範圍。
任務名稱越明確，接手者越能判斷自己的工作是否依賴前一步。研究尚未確認來源時，寫作可以先準備結構，但不宜把候選資料直接寫成定論。
官方的看板元件使用標題表示欄位，待辦、進行中與完成則由不同勾選符號表示。卡片可以附上負責人、標籤與期限，並在下面保留說明或自訂欄位。
這個設計把看板資訊留在文字裡，代理不用猜卡片顏色的意義，就能讀到任務狀態。人員也可以直接查看同一份內容，確認狀態是否反映實際交付。
在前面的競品研究情境中，卡片下方可以列出三個產品、功能名稱與資料截止日。研究者先交來源表，檢查者核對完畢後才把卡片移到完成，避免找到資料就誤認為比較已經定案。
期限也應對應交付物。例如上午交來源表、下午交差異表，比只寫「今天完成研究」更容易安排後續。這些時間是示例，團隊需依自己的工作量設定。
看板上的完成符號只是狀態標記，不能替代檔案或來源。若卡片寫完成，說明中卻沒有交付位置，接手者仍無法開始工作，應把缺漏補在原卡片中。
交接內容要讓下一個代理接得下去
好的交接應保留結果、依據與尚未完成的部分。只寫「已完成」容易讓接手者猜測完成範圍，也無法發現中途遇到的限制。
假設研究代理找到兩份互相矛盾的價格資料，就應保留兩份來源的日期，並指出尚未確定哪個適用。寫作代理才能先排除該數字，而不是選一個看起來比較新的答案。
官方文件的具名代理動作，能協助在工作紀錄中辨認行為。但顯示名稱本身不等於經過完整的身分認證。資料分享仍需依實際權限處理。
同樣地，評論與修改建議可以留下討論依據，是否接受建議仍要有人決定。建議被提出、被閱讀、被採用，是三個不同狀態。
Workbench 的建議權限允許提出修訂，卻不能直接重寫正式文件。官方文件也說明，一般文件讀取不包含尚未接受的建議，所以接手者不會自動把候選改法當成已通過的正文。
對初次建立流程的團隊，這提供了可操作的分工。研究者附上依據，寫作者提出段落修訂，指定的審核者接受或退回，下一個代理再讀取正式版本。
若來源表中的費用還有爭議，可以把爭議留在該句的留言串，並在回覆中補上適用方案。這比把「有人覺得有問題」散落在另一個聊天視窗更容易追蹤。
代理交接時，則應說明本次使用的版本與未採納的建議。當下游知道哪一份是正式內容，就不必重新詢問每個上游角色，也能避免引用遭退回的文字。
官方另提供開放請求的認領機制，同一個請求同時被認領時，只有成功取得的代理應接手。它用於減少多人搶做同一項工作，與單純在看板上填名字不同。
團隊不一定需要立刻使用所有機制。兩個角色合作時，清楚的卡片與留言可能就足夠。當開放任務常被重複處理，再考慮加入認領流程，才不會為了功能而增加維護負擔。
權限與版本還原如何用在試行？
官方介紹包含不同分享權限與版本紀錄。這使團隊有機會先讓代理查看或提出建議，再逐步給予編輯權限。
第一次試行可以從非敏感的範例文件開始。讓一個代理整理內容，另一個只留下檢查意見，由人員決定是否套用，較容易看清楚每個角色的責任。
版本還原則用來處理不合適的修改。試行時應實際確認能找到修改前的版本，並知道還原後哪些內容會受到影響，而不是等到文件被改壞才第一次使用。
官方文件說明，內容更新可以帶上讀取時的版本。若另一位協作者已經修改，伺服器會回報版本衝突，原寫入者需重新讀取，再把自己的修改合進新版本。
這就像兩個人各自拿到同一份舊文件，其中一人先改了日期。另一人再交回內容時，系統要求先查看新的日期，避免連同自己的段落把同事的修改蓋掉。
因此，串接代理時應把「先讀最新版再改」寫進流程。遇到衝突也要重新理解差異，不能把錯誤訊息當成只是需要反覆重送的網路問題。
版本紀錄保存的是正式 Markdown，尚未接受的新增建議不會自動變成還原內容。人員回復某一版時，仍需確認原本的留言與建議是否繼續適用。
可以用一份範例做還原演練：先記錄原文，讓代理改一小段，再找回修改前的版本，最後比對文字。這是本文建議的操作驗收，並非宣稱我們已在使用者帳號完成測試。
分享權限應跟這個責任分工一起設定。只做查核的角色可以讀取或留言，負責提案的角色使用建議權限，只有需要定稿的人取得編輯能力。
分享連結中的存取金鑰也代表權限。官方提醒不要把帶有金鑰的網址貼進文件、聊天或留言，否則能讀到那段內容的人可能連帶取得該連結的能力。
免費編輯器也不代表整個代理流程沒有費用。若連接需要付費的模型或工具，運算與其他服務的成本仍應另外計算。
多代理協作先驗收什麼？
先看重複工作有沒有減少。若接手者仍花很多時間重新詢問背景，看板只是增加一個記錄位置，並未改善交接。
再看結果能否回查。每份輸出應指向材料或檔案，讓檢查者能確認工作真的完成，而不是只接受代理自己的敘述。
最後看修改是否可控。多人同時更新時，要知道誰可以定稿、誰只能提建議，以及出現衝突後由誰處理。
這些是團隊需要建立的工作規則，不應期待工具自動替所有組織做相同決定。規則越貼近原本的工作，導入越容易持續。
假設試行工作仍是三個產品的功能比較，可以保留人工完成同一件工作的時間。代理流程也從開始找資料計時，一路算到人員願意採用差異表，才是同一範圍的比較。
若產出較快，卻需要更多時間重新確認來源，應追查交接缺的是日期、適用方案還是原始連結。把具體缺漏補進卡片範本，比單純要求代理「寫詳細一點」更有效。
當流程需要人員決定，官方的工作狀態元件可以標示等待人員介入，並記錄需要回答的問題。通知是否寄出仍與設定有關，團隊應避免每次小進度都要求人員回覆。
例如「請選擇比較免費版或商務版」是會改變工作的決定，值得提出。一般查詢進度則留在紀錄中即可，這樣人員注意力才會集中在需要拍板的事項。
第一輪試行後，只保留確實減少重工的欄位與角色。若一個人能直接完成來源查核，就沒有必要拆成好幾個代理，讓資訊在交接中反而變薄。
不同入口，仍要維護同一份成果
Workbench 讓代理透過一般 HTTP 網頁通訊介面或官方命令列工具操作文件，人員則可以留在網頁編輯器。兩邊工作的重點，是共同查看正式文件，而非各自在聊天裡維護一份副本。
對已經有 AI 工具的團隊，可以先確認該助手能否讀到指定文件，再讓它提出一個小修改。沒有必要為了試行先更換所有工具，也不應把安裝連接器當成協作流程已經建立。
若一位同事提出新的比較需求，應把需求補回原卡片，讓研究者與檢查者都知道範圍變了。私下告訴其中一個代理，容易讓另外的角色繼續驗收舊範圍。
最後交付時，則提供正式成果所在的位置及適用版本。狀態紀錄解釋工作怎麼完成，成果文件承載最後答案，兩者連在一起，接手的人才能省下重新追查的時間。
Workbench 常見問題
Workbench 必須先裝 MCP 才能協作嗎？
官方同時提供網頁、一般 HTTP 與命令列入口，MCP 是讓 AI 助手以一致方式使用外部工具的連接介面。它讓支援的助手使用文件工具，但不是所有分享連結工作的必要前提，應依原本使用的工具決定是否加入。
用了看板就能讓代理自己把整個專案做完嗎？
看板協助協調資訊與進度，代理能做什麼仍取決於連接的模型、工具、資料與權限。先讓它完成一個能清楚驗收的任務，再考慮更大的範圍。
最初應該安排幾個角色？
可以先安排產出與檢查兩個角色。這是試行建議，目的在於比較結果與減少交接混亂。沒有必要一開始就仿造龐大的代理團隊。
如何知道代理沒有重複研究？
要求接手者先閱讀已有交接，再記錄新增證據與差異。若它重新做相同查詢，應確認是否因來源過期或前一份交接不足，而不是只看工作量。
從一份能還原的交接簿開始
Workbench 的實用價值在於讓多人與多代理共享工作脈絡。它能提供記錄與協調方式，完成標準仍需要團隊自己寫清楚。
先挑一份可公開或不敏感的工作，寫下材料、交付物與驗收條件，實際走過一次產出、建議、修訂與還原，再決定是否接入更多代理。
延伸閱讀：AI 程式驗收教學：人工審查、測試與逐步上線，各自能抓到哪些錯誤
延伸閱讀：GitSwarm 是什麼？Meta 用共享 Git 記憶讓 AI 代理接力，團隊如何借用這套方法
