Agent Workflow

多個 Agent 一起開發時，怎麼讓大模型帶隊把協作做穩

模型越多，團隊越容易出現兩種錯覺：第一種是大家都很忙，看起來進度很快；第二種是每個人都交了回報，看起來事情做完了。真正有用的做法，是先把派工單、回報格式、檔案邊界、驗證命令和人類決策點固定下來。用 Codex、Claude Code、Copilot、Gemini，還是透過 MCP 接別的 Agent，都可以沿著同一條流程走。

帶隊模型負責排順序、定邊界、做裁決，不需要親自把每一段都寫完。

派工單格式共享欄位比共享品牌更重要，大家講同一種話，合作就會快很多。

回報對稱派工寫什麼，回報就對應什麼，資訊自然會變得中性又可核對。

為什麼多 Agent 團隊常常卡住

專案一旦失速，常見原因往往是每個模型都在用自己的格式講話。

多個 Agent 一起進同一個 codebase，很快就會碰到幾個熟悉的問題：有人只被要求做唯讀盤點，結果直接開始改檔；有人修的是小 bug，卻順手把一整包 generated artifacts 一起塞進同一顆 commit；有人回報說已完成，卻沒有附 validator、沒有說 pre-existing failure、也沒說工作樹裡還有哪些背景 dirty。

這些問題看起來分散，核心其實很一致：協作雙方沒有共用的派工單格式，也沒有共用的回報格式。帶隊模型如果每次都靠臨場口述，context 會越堆越厚，token 很快就被吃掉，最後連人類都很難追進度。

一條夠實用的帶隊主線

圖 1：帶隊模型的工作重點是調度與整合。便宜小助手先做唯讀盤點，執行 Agent 接落地工作，複審 Agent 做最後風險判讀。

先用便宜小助手

scope 還不清楚時，先派便宜模型做只讀 preflight 很划算。它可以幫忙盤 log、grep 檔案、找衝突、列 validator。等任務輪廓清楚，再交給比較高階的執行模型。

帶隊模型不要親自下海做每一段

高等模型適合做排序、裁決、拼圖、整合和對外溝通。把所有 patch 都自己寫完，通常會讓速度慢下來，context 也容易越背越重。

派工單格式要固定，這是整條線的地基

派工單最有價值的地方，是每個 Agent 一拿到就知道：自己能碰什麼、不能碰什麼、應該回報什麼。

回報第一行必須是：代號：005；模型：<實際使用模型>

任務：一句話說清楚這輪要做什麼。

repo：
路徑或工作樹位置

背景白話：
用 2-5 句講清楚：
- 為什麼現在要做這件事
- 它和前一輪工作的關係
- 這輪最重要的裁決點是什麼

請做：
1. ...
2. ...
3. ...

請回報：
1. 結論：PASS / CONCERN / BLOCK
2. ...
3. ...
4. ...

禁止：
- 不准 ...
- 不准 ...
- 不准 ...

大白話補一句：
用一句人話，說這一袋工作到底是在收什麼。

欄位	作用	實務提醒
第一行代號	確認是誰接到球	外部可轉貼版本一定要用人類 roster 代號，例如 001、004、007。
背景白話	讓執行者快速進入脈絡	不要重貼整段歷史，只講這輪真正要處理的那個結。
請做	把工作切成可執行步驟	一張單盡量只做一件主事，分析、實作、複審拆開最穩。
請回報	限制回報格式，降低歧義	這裡越固定，Captain 越能快速接回主線。
禁止	防止順手超 scope	「不准 stage / commit / push」這類句子真的很好用，少了常常出事。

回報格式要和派工單對稱，資訊才會中性

多 Agent 團隊最怕的狀況，是有人交上來一篇像心得文的回報。真正適合接棒的回報，會和派工單形成鏡像：派工要他查什麼，他就逐項回什麼；派工要求 PASS / CONCERN / BLOCK，他就不要自己發明第四種情緒。

圖 2：格式對稱之後，工具品牌差異會退到第二層。Captain 真正在讀的，是共享欄位與共享裁決詞。

這裡有一個很關鍵的小習慣：能力角色只留給隊長內部判斷，例如執行型、複審型、唯讀偵察型。外部派工單第一行只放人類看得懂的代號。這樣 roster 每天換人，格式還是穩的。

人類怎麼跟這整套系統合作

人類最適合做三件事：決定優先順序、決定誰有權碰主線、決定什麼時候可以 merge。這三件事如果沒抓在手上，再強的 Agent 組合也會開始漂。

先做 roster 綁定

每天一開始先把 roster 綁好。例子像是 001 做文件與 checklist、004 做裁決、007 做最快執行。內部可以再映射能力角色，外部派工單只寫數字代號。

先決定哪一袋要先出車

source fix、evidence、generated artifacts、docs，這幾袋分開看最清楚。小包先走，大包留 Draft，團隊會輕鬆很多。

人類節點	應該做什麼	常見失誤
派工前	確認 roster、優先順序、可碰檔案、禁止事項	只口頭交代，沒有留下可轉貼文字。
執行中	只在需要裁決時介入，平常讓格式自己收斂	什麼都親自追，結果把高階決策時間花在低階核對。
收尾時	看 PR、看 validator、看回報格式，最後才做 merge / push	看到「做完了」就直接放行。

實用 prompt 和 skill 範例

同一條線上通常會混用很多工具：Codex 管 worktree，Claude Code 接大 patch，Copilot 補小缺口，Gemini Flash 類的小模型先做偵察，MCP 負責把 issue tracker、repo、preview、design tool 串起來。真正重要的是這些工具都講同一種派工語言。

唯讀偵察 prompt

回報第一行必須是：代號：002；模型：<實際使用模型>

任務：先做唯讀盤點，判斷這一包 work 是否適合現在開始。

repo：
/workspace/example-repo

背景白話：
主線現在卡在一顆大 PR。這輪只想知道：
- 哪些檔案正在被碰
- 哪些 validator 會擋
- 這張卡要不要拆袋

請做：
1. git status -sb
2. git diff --name-only
3. 盤點是否有 source fix / generated artifacts / docs 混袋
4. 不改檔，不 commit

請回報：
1. 結論：PASS / CONCERN / BLOCK
2. 建議分袋方式
3. 建議下一張派工單該交給誰

禁止：
- 不准改檔
- 不准 stage
- 不准 commit
- 不准 push

執行落地 prompt

回報第一行必須是：代號：007；模型：<實際使用模型>

任務：只提交這三個 source 檔，不要混進 generated artifacts。

repo：
/workspace/example-repo

背景白話：
這輪是在收 source fix 那一袋。evidence 跟 runtime artifacts 先留在工作樹外側。

請做：
1. 跑最小 validator
2. 只 stage 白名單檔案
3. commit
4. 回報 commit SHA 與 git status -sb

請回報：
1. 結論：PASS / CONCERN / BLOCK
2. commit SHA
3. validator 結果
4. 是否有任何檔案被排除在外

常見 skill / MCP 組合

派工規範 skill：固定欄位、固定回報格式、固定禁止事項。
開卡 skill：建立 task card、補 shard、做 dry-run 開卡報告。
encoding guard skill：每次改文件或 HTML 後先掃 touched files，省下一堆亂碼事故。
browser QA skill：打開站內頁面、看版型、驗證中英切換。
MCP repo / issue / design connector：讓 Agent 讀到同一份資料來源，降低「我以為」的空間。

幾個很常見，也真的很痛的坑

只叫人看，結果他開始改

派工單如果沒把「唯讀」和「不准 commit」寫死，很多 Agent 會把被提到的任務卡直接當成開始信號。

小修和大包混在一起

source fix、runtime artifacts、governance evidence 混成一袋時，review surface 會瞬間變大，回退也會很痛。

直接從髒工作樹出車

工作樹上已經有背景 dirty 時，直接 push 主線很容易把別人的東西順手送上去。乾淨分支和 Draft PR 真的能救命。

每個人交不同格式的回報

有人寫散文，有人只貼 SHA，有人只說 done。Captain 每次都要重新翻譯，速度很快就掉下來。

比較穩的解法很一致：先派便宜小助手做唯讀盤點，接著用固定欄位派工，最後讓複審 Agent 用 PASS / CONCERN / BLOCK 收尾。中間如果遇到大包，開 Draft PR 把 review surface 縮小，大家都會輕鬆很多。

一份夠落地的起手式清單

先定一位帶隊模型，讓它負責調度和整合。
先做 roster 綁定，外部派工單只用人類代號。
先派便宜小模型做唯讀盤點，別讓高價模型一進場就背全場 context。
每張派工單只做一件主事，分析、實作、複審拆開。
派工單和回報文件用同一套欄位。
把 generated artifacts、source fix、evidence 分袋。
讓 skill 和 MCP 承接固定工序，讓人類專心做判斷。
需要上主線時，再做 PR、merge、push，不要提早偷跑。

工具很多很正常。沒有共同格式，協作很快就會亂掉。