Area 2 · D1 架構選型
2.1 Workflow vs Agent 2.2 五 Pattern 選型 2.3 Multi-agent 成本 2.4 Plan/Direct/Multi-phase 2.5 平行執行 討論題
2.1 Workflow vs Agent — 總準則
Workflow Agent 定義 LLM 與工具走預先寫定的 code path LLM 動態決定 自己的流程與工具使用 強項 可預測、一致（well-defined tasks） 彈性、model-driven 決策（規模化時） 代價 彈性低 成本更高 + 錯誤複合累積 （compounding errors）
官方原句："workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale." 選 agent 前必答的兩個問題：任務真的無法拆成固定步驟嗎？價值撐得起成本 + 錯誤風險嗎？（配套：sandbox 測試、guardrails、checkpoint/blocker 時暫停要人回饋）
陷阱 ：「流程固定不分支」的題目給你 autonomous agent 選項 = over-engineering 反向題。不是所有東西都需要 agent——workflow over agent 。
2.2 五種 Workflow Pattern — 背「何時用」
Pattern 一句定義 選型鑰匙（官方措辭） Prompt chaining 固定步驟串行，每步吃上一步輸出 任務能乾淨拆成固定子步驟 ；用延遲換準確度 Routing 先分類輸入、導到專門處理 輸入有明顯不同類別 、各類分開處理更好 Parallelization 子任務同時跑、程式彙整sectioning （切塊求速度）/ voting （多次求信心） 子任務可獨立平行 （快），或要多視角/多次嘗試 （穩） Orchestrator-workers 中央 LLM 動態拆解 、委派、彙整 子任務無法事先預測 時Evaluator-optimizer 一個生成、一個評估回饋、迴圈 有明確評估標準 + 迭代有可衡量提升
選型流程：
子任務事先列得出來嗎？
├─ 列得出、彼此獨立 → Parallelization（sectioning）
├─ 列得出、必須依序 → Prompt chaining
├─ 列不出（邊做邊發現） → Orchestrator-workers
輸入天生分幾類？ → Routing
有 rubric、要反覆打磨？ → Evaluator-optimizer
要更高信心的判斷？ → Parallelization（voting）
最常考分界 ：orchestrator-workers vs parallelization 只差一件事——子任務能否事先預定 。能 → parallelization；要動態決定 → orchestrator。題目寫「每份報告固定五節」= 可預定；寫「調查方向取決於發現什麼」= 不可預定。
2.3 Multi-agent 適用性與成本
適用 ：高度可平行 + 資訊量超過單一 context window + 大量複雜工具；breadth-first （多獨立方向同時追）的研究型 query 最典型不適用 ：agent 間高度依賴、需共享 context——官方點名 coding （可平行子任務比 research 少）成本數字 ：agent ≈ 4× chat token；multi-agent ≈ 15× chat token → 只有高價值任務划算（經濟門檻）效能事實 ：lead(Opus)+subagents(Sonnet) 對 research 勝單一 Opus 90%+；token 投入解釋 80% 效能變異；升級模型 > 在舊模型上加倍 token 委派四要素 （subagent prompt 必含）：objective、輸出格式、工具/來源指引、任務邊界 ——缺邊界 = 重工/越界；缺格式 = 彙整困難回傳紀律 ：subagent 回 lead 的是濃縮摘要（約 1,000–2,000 tokens） ，不是原始資料傾倒投入要配題目大小：簡單比較型 query 不要 spin up 十個 subagent（effort scaling）
2.4 Plan mode / Direct / Multi-phase 選型
模式 機制 訊號 Plan mode 唯讀探索 → 出計畫 → 核准後切執行 mode 大規模改動、多可行解、架構決策、跨多檔；「改動前先探索」是官方定義場景 Direct 直接執行 範圍明確的小改動（rename、加 log、bump version） Multi-phase workflow 多個階段、每階段有人工核准 gate 高風險 + 法遵/審批需求明寫在題目裡（例：design 核准一次、staging 驗證後再核准一次）
陷阱 ：複雜度已明擺在需求裡（「跨數十檔」「重劃 service 邊界」），選項給「先動手、問題浮現再調整」= 錯。與 plan mode 的分界：multi-phase 是多個 核准點，plan mode 是一個 計畫核准點。
2.5 平行執行 — 一回合多個呼叫
Claude 原生支援 同一 assistant turn 發多個 tool_use / Task call = 平行。沒平行通常是沒被 prompt 引導 ，不是不會——先 prompt、別改架構
實務兩層平行：lead 一回合 spin up 3–5 個 subagent ；每個 subagent 內部工具再平行（研究時間可 −90%）
tool_result 鐵律 ：全部裝同一則 user message 、放任何文字之前 、用 tool_use_id 對應。一題一則分開回 = 教壞模型以後不 batch（官方點名的最常見退化原因）只 batch 彼此獨立 的呼叫；依賴呼叫序列做、絕不猜參數 （詳見 Area 3 §3.3）
Batch 裡沒跑到的呼叫照樣回 is_error: true 的 tool_result 說明原因
討論題（讀書會 session 用）
「每週競品報告：五個固定面向、各自獨立」和「盡職調查：查到什麼決定下一步」——兩個各用哪個 pattern？把分界一句話說出來。
為什麼官方說 coding 不適合 multi-agent？拿你手上的一個實際專案檢驗這個說法。
multi-agent 的 15× token 成本，什麼條件下值得付？三個條件背出來。
plan mode 和 multi-phase workflow 都有「人核准」——差在哪？各舉一個非題庫的例子。
「agent 沒有平行呼叫工具」——為什麼第一反應是改 prompt 不是改架構？哪個官方事實支撐這個判斷？