07 - 實戰工作流範例：多代理 + 中央驗證
← 06-進階功能-Skills-Automations-多代理 | 00-Index | 下一篇 → 08-術語速查表
這篇要幹嘛
前面幾篇講原理（多代理、prompt 與 review、權限）。這篇用真實跑過的工作流把它們串起來，讓你看到「平行產出 + 中央驗證」到底長什麼樣。
核心心法只有一句，先記住：
平行產出，中央驗證。 agent 可以一次很多個同時做事，但「對不對」這關必須收回到一個中央點統一檢查——不能外包給正在產出的那批 agent。
案例 A：用多代理平行處理大規模知識庫維護
背景
一個 Obsidian 醫學筆記庫，13 科、約 190 篇臨床筆記。目標是做「全庫品質稽核」並強化偏弱的篇章。190 篇若一篇一篇順著做，又慢又無聊；但它剛好是適合平行的任務——各篇之間互相獨立，符合 06-進階功能-Skills-Automations-多代理 講的「可切成獨立子任務」。
流程設計（兩階段 + 一個收斂關卡）
階段一：平行稽核評分
- 用平行 subagents 逐科處理，每批 5–9 篇。
- 每個 agent 對自己那批筆記用固定 rubric 評等（A / B / C / D），產出評分與「弱在哪」的理由。
- 重點：rubric 固定 → 評分標準一致、結果可比較、可被中央 review。
階段二：針對偏弱篇平行強化
- 把評到偏弱（C / D）的篇章挑出來，再開一批 subagents 平行強化。
- 關鍵紀律：每篇 agent 只改自己那一檔。 這樣多個 agent 同時寫檔也不會互相覆蓋（呼應 06-進階功能-Skills-Automations-多代理 的 worktree / 一 agent 一檔原則）。
- 反向連結（cross-link）與 wiki 維護（index / log）不交給各 agent 做，而是由協調者最後統一處理。原因：這些是跨檔的一致性工作，分散給各 agent 會互相踩（大家都要改同一個 index 檔）→ 衝突。集中到一個收斂點做最乾淨。
中央驗證關卡（這步是整套的安全核心）
每批強化完，協調者用 PubMed MCP 逐筆抽驗新增的引用——檢查 PMID metadata 真偽（這篇 PMID 是否真的存在、作者期刊年份對不對）。
這關實際抓到過：
- 引用到 retracted paper（已撤稿論文）
- 期刊年份誤植
- 概念錯誤
這就是為什麼「平行產出 + 中央驗證」是關鍵安全設計：subagent 為了補強內容，可能很自信地塞進看似合理、其實是錯的引用。如果沒有一個中央關卡逐筆查證，這些錯誤會直接進庫、之後很難發現。產出可以快、可以平行；驗證必須慢、必須集中。
為什麼這樣切是對的
- 任務可拆（各篇獨立）→ 值得平行。
- 每個 agent 範圍窄（只改一檔）→ 不衝突。
- 產出可被中央驗證（rubric 一致 + PubMed 抽驗 + 協調者收斂）→ 安全。
三個條件都滿足，正是 06-進階功能-Skills-Automations-多代理 說的「該平行才平行」。
案例 B：量產型 subagent（刷題網頁的考題詳解）
另一個專案是一個內科考古題刷題網頁（純前端），需要為大量考題量產詳解。這是另一種「大批同質工作」的平行場景，但踩到的雷不一樣。
實戰參數（用 token / 時間換出來的經驗）
- 一個 agent 約 10–12 題最穩。
- 超過 ~16 題容易 stream idle timeout——題目特別長或混合多個次專科時更明顯，要切小批。
- agent 常在 token / 用量上限之間擺盪，而且多數會「寫完檔案才回報達到上限」。
因此衍生的處理紀律
- 失敗先檢查產出檔，再決定重派。 因為它常常是「做完了才喊上限」，盲目重派 = 做白工、又燒一次 token。先看
tmp_drafts/（暫存產出）有沒有東西，再決定是補沒做完的、還是整批重來。 - 批量抓在甜蜜點：寧可多開幾批小的（每批 ~10 題），也不要貪心一批塞 20 題然後 timeout 整批重來。
這呼應 04-權限與安全設定 的「失敗與中斷怎麼處理」：先看產出、再決定重派，是省時省 token 的鐵則。
案例 C：多個 agent / 工具同時推同一個 repo
同一個刷題網頁專案，是Codex 持續推進 main、Claude 也並行的並行開發。兩邊都在動同一個 repo。
處理方式：
- 合併前必須 reconcile：把遠端最新（對方剛推的 commit）先拉下來對齊，再合併自己的改動。
- 降低衝突的天然分工：盡量讓不同 agent / 工具改不同檔，附加式的改動（各自加各自的東西）幾乎都能乾淨合併。
這就是 06-進階功能-Skills-Automations-多代理 講的 worktree / 多源並行：隔離產出、合併前對齊。
案例 D：把固定流程包成 Skill / Automation
當同一套流程跑很多次（例如「產生一篇筆記 → 維護 wiki 層」），就值得把它包成可重複調用的 skill pipeline，而不是每次重講一遍 prompt。
實際做法是把流程拆成有分工的幾個 skill：
orchestrator → writer → wiki-maintain
（協調入口） （產內容） （維護索引/連結）
orchestrator：唯一入口，解析意圖、決定要做什麼、dispatch 給下游、最後做唯一一次 commit。writer：只負責產內容，不碰 wiki、不 commit。wiki-maintain：只維護 index / log / 反向連結，不改筆記主體、不 commit。
好處：
- 職責單一 → 每個 skill 都好 review、好除錯。
- commit / 收斂集中在 orchestrator（中央點）→ 不會多個環節各自亂 commit。
- 流程穩定後可掛 Automation 定期跑。
這跟案例 A 是同一個原則的不同形態：產出分散、收斂集中。
把四個案例濃縮成可帶走的心法
- 只在任務真的可拆時才平行化——強順序依賴、高歧義、共享狀態的任務，乖乖用單一 thread。
- 每個 agent 範圍要窄——最好「一個 agent 只改一個檔」，並行寫檔才不會衝突。
- 產出要可被中央 review / 驗證——平行產出越多，中央驗證關卡越不能省（PubMed 逐筆查 PMID 就是活教材）。
- 失敗先看產出再重派——agent 常「寫完才喊上限」，盲目重派浪費 token。
- 跨檔一致性（連結 / 索引 / commit）集中到協調者做——分散給各 agent 會互相踩。
- 多源並行同 repo → 合併前先 reconcile——隔離產出、對齊後再合。
重點整理
- 真實世界的多代理不是「開很多 agent 就好」，而是產出分散、驗證與收斂集中。
- 大規模知識庫維護（190 篇 / 13 科）靠「平行稽核 → 平行強化 → 中央 PubMed 驗證」跑得又快又安全。
- 量產型 subagent 有甜蜜點（~10–12 題/agent）與雷區（>16 題易 timeout、常寫完才喊上限）。
- 固定流程值得包成 skill pipeline，把 commit / 收斂集中在 orchestrator 這個中央點。
參考資料
← 06-進階功能-Skills-Automations-多代理 | 00-Index | 下一篇 → 08-術語速查表