編排品質模式

你將學到什麼

第 27 堂課介紹了 Workflow 工具。這堂課處理更重要的設計問題：如何讓多代理結果比單一看似合理的答案更可信？

你會學到七個模式：

1. 正交搜尋；
2. 明確的證據契約；
3. 對抗式驗證；
4. 漸進式綜整；
5. loop-until-dry 停止條件；
6. 可見的覆蓋範圍；
7. 人工或自動品質閘門。

這些是架構模式，不是未文件化的 Workflow API 保證。把模式寫進任務，讓 Claude 依目前支援的介面撰寫腳本。

1. 正交搜尋，而不是複製式 Fan-out

五個相同 prompts 往往會複製相同盲點。應按方法或邊界拆分：

• 檢查變更函式的局部邏輯；
• 追蹤 callers 與 downstream contracts；
• 檢查錯誤與復原路徑；
• 測試授權或信任邊界；
• 比對文件、測試與實作。

use a workflow to review this change through four independent lenses:
local logic, call-site contracts, failure recovery, and security boundaries.
Keep each lens separate until synthesis.

獨立性很重要。若每個 finder 一開始就看到其他人的答案，整組 agents 可能一起錨定在同一個早期錯誤上。

2. 定義證據契約

增加 workers 之前，先定義一則 finding 必須包含什麼。實用的最小集合是：

欄位	用途
Claim	一個可被證偽的陳述
Location	File、symbol、URL 或 command
Evidence	支持 claim 的觀察
Reproduction	適用時提供 inputs 與 steps
Impact	實際壞掉什麼、影響誰
Confidence	Confirmed、plausible 或 unverified

要求 finders 回傳精簡 records，沒有合格結果時回傳 NONE。不要讓最終 writer 推測 finder 未提供的證據。

3. 對抗式驗證

Discovery 與 verification 應有相反誘因：finder 負責提出候選，verifier 負責設法推翻它。

For every candidate, launch an independent verifier with this instruction:
assume the claim is wrong; reproduce it, identify the strongest counterexample,
and mark it confirmed, refuted, or unverified with evidence.
Do not count a rate limit or tool failure as refutation.

最後一項與目前 /deep-research 行為一致：無法檢查的 claim 會標為 unverified，而不是默默算成 false。

高風險工作可使用 correctness、security、operational impact 等不同驗證視角。只有在 evidence 彼此獨立時，多數意見才有價值。

4. 驗證後再綜整

最後的 synthesizer 不應只是串接 agent outputs，而應負責更窄的任務：

1. 丟棄已 refuted 的 candidates；
2. 把 unverified claims 明確分開；
3. 依 root cause 而非措辭去重；
4. 依可觀察 impact 排列 confirmed findings；
5. 每個結論都引用 evidence record。

這裡是一個合理的 barrier：它必須看到整組已驗證結果，才能比較、合併與排序。

5. 搜尋到連續無新結果

單次 audit 只能證明第一批 prompts 有回傳內容。開放式探索應設定明確停止條件：

use a workflow to find flaky tests in this repository.
Run independent rounds, deduplicate against every candidate already seen,
and stop after two consecutive rounds produce no new candidates.
Also stop if the same failures repeat without new evidence.

兩個重要細節：

• 對所有看過的 candidates去重，包括被拒絕的項目，否則同一個錯誤 claim 可能永遠被重新發現。
• 「沒有進度」必須可觀察：沒有新檔案、沒有新證據，或 failing check 沒有變化。

Dry-round rule 是實務上的停止 heuristic，不代表數學上已窮盡搜尋空間。

6. 讓覆蓋邊界可見

每次有限審查都有邊界，應記錄而非隱藏：

• 納入哪些 directories 與 file types；
• 跳過哪些檔案以及原因；
• 哪些路徑是 sampling、哪些是 exhaustive；
• 失敗或 timeout 的 commands；
• 仍未驗證的 claims；
• workflow 是否因使用者、runtime cap 或 no-progress rule 而停止。

昂貴 workflow 先跑小樣本。/workflows 會顯示每個 agent 的 token 使用量並可停止執行。Size guideline 與 Large workflow warning 都只是建議，並不是文件化 token-budget API。

7. 在失敗代價高的地方設閘門

在不可逆或高風險 phase 之前放置 gate：

• 綜整前要求 tests 通過；
• 每個 confirmed finding 都必須有 reproduction；
• 把 implementation 與 deployment 分成不同 runs；
• schema changes 或 release actions 前要求人類核准。

Workflow 無法在執行中詢問一般 user questions，因此人類簽核應放在兩個 workflows 之間。

若 workers 需要持續辯論或互相協調，agent team 可能更適合。Agent teams 共享 tasks 並能直接互傳訊息；但它仍是 experimental、預設關閉、成本較高，也不適合同檔修改或大量序列依賴。TaskCompleted 與 TeammateIdle hooks 可拒絕過早完成，並把修正指示送回 teammates。

參考審查結構

獨立探索
  ├─ 局部邏輯
  ├─ 跨模組契約
  ├─ 失敗路徑
  └─ 信任邊界
          │
          ▼
標準化 evidence records
          │
          ▼
對每個 candidate 做對抗式驗證
  ├─ confirmed
  ├─ refuted
  └─ unverified
          │
          ▼
去重、排序並回報 coverage bounds

這個設計也能縮小使用。只要角色與 evidence contract 清楚，兩個 finders 加一個 verifier 可能勝過二十個複製 agents。

反模式

• **Clone swarm：**大量複製同一個模糊 prompt
• **把共識當證明：**沒有獨立 evidence 就投票
• **Verifier contamination：**一開始就讓所有 reviewers 看到同一個結論
• **隱形 sampling：**把部分掃描說成 exhaustive
• **Failure collapse：**把 timeout、拒絕或無法取得資料當成 false
• **無限搜尋：**沒有 dry-round、passing-check 或 no-progress 條件
• **自創 runtime contract：**依賴未文件化的 cost、exception 或 null-return semantics

核心洞見

多代理品質來自誘因分離與可見證據，而不是 agent 數量。 廣泛搜尋、懷疑式驗證、明確停止、如實回報邊界。Workflow 的價值是反覆編碼這套結構，而不是 fan-out 本身保證正確。

下一堂課

第 29 堂課介紹持久記憶：保留長期知識，但不把舊結論變成不可質疑的真理。

官方來源

• Dynamic workflows 與品質範例
• Agent teams、共享 tasks 與品質 hooks
• Subagent 設計與隔離