這是什麼
這是三個從實戰中提煉出來的子代理工作流設計原則：分派前先寫好共用標準、設計明確的彙整步驟、先用小規模測試確認任務適不適合拆分。這三個原則要解決的共同問題，是子代理概念聽起來直覺，但實際設計成可重複使用的工作流時，很容易在標準不一致、彙整草率、任務本身不適合拆分這幾個環節翻車。
三個原則分別對應子代理工作流的三個階段：分派前（寫標準）、彙整時（設計檢查步驟）、正式套用前（小規模驗證），涵蓋一套子代理工作流從設計到落地的完整流程。
為什麼存在
這三個原則之所以重要，是因為子代理平行處理的架構本身，天生就會產生「標準不一致」和「看不到彼此」這兩個結構性問題，而不是操作上偶爾出錯。每個子代理都是獨立實例，如果沒有明確共用標準，各自依照自己的理解填補模糊指令，是這個架構下必然會發生的事，不是運氣不好；同樣的，每個子代理只看得到自己那一份資料，也是平行處理架構的天生限制，不會因為子代理「做得更仔細」就自動解決。
這三個原則存在的意義，就是針對這兩個結構性問題，在工作流設計階段就先預防，而不是等結果出來才發現不對勁再回頭補救。第三個原則（小規模測試）則是因為任務彼此的關聯程度常常在事前很難準確評估，只有實際跑過一輪才會清楚看出彙整成本值不值得，這也是為什麼不能只靠事前判斷，需要留一個驗證的步驟。
如何影響你的決策
如果你正在評估要不要用子代理處理某個批次性任務，這三個原則會改變你的規劃順序。原本可能想到「這個任務可以拆」就直接動手分派，現在應該先問自己三個問題：這個任務有沒有辦法寫出一份具體到位的共用標準；子代理彙整回來的結果，有沒有可能出現互相矛盾或該互相參照卻各自處理的情況；如果不確定，有沒有先用兩三筆資料小規模測試過。三個問題都想清楚了，再決定要不要正式套用到全部資料。
這也會影響你分配時間的方式。原本可能覺得「子代理應該能省時間」，所以把所有時間都放在等待子代理跑完；現在應該把一部分時間預留給彙整檢查這個步驟，因為這一步不是可有可無的收尾動作，而是決定整套工作流品質是否可靠的關鍵環節。
進階應用
進階使用者可以把彙整檢查這個步驟，本身也設計成一個專門的子代理，而不是回到主任務手動處理。具體做法是分派任務時，除了負責實際工作的子代理，額外指派一個「彙整審核子代理」，這個子代理不處理原始資料，只負責讀取其他子代理的輸出結果，專門檢查有沒有互相矛盾的判斷或遺漏的交叉關聯。這樣做的好處是彙整審核可以用跟原始任務不同的角度切入，專注在「找問題」而不是「做任務」，通常比主任務自己順手檢查一次更容易抓出問題。
另一個進階技巧，是把共用標準本身也交給 Claude 協助設計，而不是完全靠自己想。具體做法是先請 Claude 針對這個任務類型，列出可能被不同子代理理解成不同意思的模糊地帶，再針對這些模糊地帶逐一寫清楚。這一步等於是在分派任務之前，先做一次「標準本身夠不夠具體」的檢查，比等到子代理各自解讀完、彙整時才發現標準模糊要有效率得多，也更能從源頭避免原則一提到的標準不一致問題。
子代理的概念聽起來很直覺：把可以平行處理的工作拆給多個獨立實例同時做，比排隊處理快得多。但知道概念跟真正把它設計成一套可重複使用的工作流，中間還有一段距離——很多人第一次嘗試用子代理，會遇到彙整結果亂七八糟、子代理各自標準不一致、甚至比循序處理還花時間的狀況。這篇整理三個從實戰中提煉出來的設計原則，幫助子代理工作流真正落地，而不只是停留在「聽起來很厲害」的階段。
子代理最常見的翻車現場，是每個子代理拿到的指令太模糊，各自用自己的理解去補完，結果彙整回來的內容風格、判斷標準完全不一致。例如請三個子代理分別審查三份合約，如果只說「幫我審查這份合約有沒有問題」，子代理 A 可能著重付款條件，子代理 B 可能著重違約責任，彙整起來的結果看似都審查完了，實際上審查的角度完全不同，沒有辦法放在一起比較。解法是在分派任務之前，先花時間寫一份簡短但具體的共用標準——例如「請針對付款天數、違約金比例、單方解約條款這三點審查，每點給出符合或不符合的判斷」，讓每個子代理拿到的是同一把尺，而不是各自的主觀判斷。
子代理平行處理的天生限制，是每個子代理只看得到自己那一份資料，看不到其他子代理在做什麼。如果任務彼此其實有關聯——例如子代理 A 審查的付款條件，剛好會影響子代理 B 該怎麼判斷另一份合約的競業條款——這種關聯在各自獨立作業時很容易被忽略。因此彙整不能只是把三份結果貼在一起交差，而應該是獨立的一個步驟：讓主任務（或另一個專門負責彙整的子代理）重新讀過所有結果，特別檢查有沒有互相矛盾的判斷，或是原本該互相參照卻各自處理的隱藏關聯。這一步彙整檢查，正是彌補子代理「看不到彼此」這個結構性限制的關鍵動作。
不是所有看起來可以平行處理的任務，實際拆分後都會更有效率。如果任務之間的關聯性比想像中高，拆成子代理反而會因為彙整檢查的成本，讓整體花費的時間超過循序處理。實戰上比較穩妥的做法，是先挑兩三筆資料用子代理小規模測試，確認彙整出來的結果品質沒問題、彙整步驟沒有花費過多額外時間，再把這套流程套用到剩下的全部資料。如果小規模測試就發現彙整很花時間、或子代理之間的判斷經常互相矛盾，這通常代表任務本身的關聯性比一開始評估的更高，這時候調整拆分方式，或乾脆維持循序處理，會比硬套子代理更有效率。
如果你已經開始嘗試用子代理處理批次性的工作，但覺得彙整出來的結果不太可靠、或者花在整理結果上的時間比預期多，很可能是漏掉了以上某個環節——共用標準沒寫清楚、彙整只是形式上拼接、或是任務本身其實不適合拆分卻硬拆了。把這三個原則當成子代理工作流設計前的檢查清單，能大幅降低「聽起來很厲害，用起來卻不可靠」的落差。