🎯 什麼情境該想到我
當你發現「一次呼叫模型」做不好，想多呼叫幾次來換品質，卻不知道該串、該分流、該平行，還是該讓它自己改到好的時候。先從這五種固定流程挑，真的不夠再升級成自主 agent。
⚙️ 怎麼用（步驟 / 公式）
0. 先記住共同的代價
五種模式都是用更多的呼叫次數（成本、延遲）換品質。repo 範例全部只靠兩個小工具：llm_call(prompt) 送一次訊息拿回文字，extract_xml(text, tag) 用正規表示式抽出 <tag>…</tag> 之間的內容。模型輸出用 XML 標籤包起來，程式才好拆。
1. 提示鏈 Prompt Chaining：一步做一件事，接力傳下去
- 做法：準備一串 prompt，上一步的輸出當下一步的
Input:，依序呼叫。 - 範例：季報文字 → ① 抽出「數值: 指標」→ ② 換成百分比 → ③ 由大到小排序 → ④ 排成 Markdown 表格。
- 何時用：步驟固定、每步都比整件事簡單。
- 好處：每一步都能單獨檢查輸出。範例的輸出就看得到第 2 步把「$43 每位用戶獲客成本」變成
43.0，到最後表格還混在百分比欄裡。錯在哪一步一目了然。
2. 路由 Routing：先分類，再交給專門的 prompt
- 做法：第一次呼叫只做分類。prompt 列出可選的路線，要求先寫
<reasoning>再寫<selection>。程式抽出選擇、轉小寫，查表拿對應的專用 prompt，再呼叫第二次。 - 範例：客服工單分到 billing／technical／account／product 四組。每組 prompt 規定開頭、語氣、必含段落。
- 何時用：輸入種類差很多，一個 prompt 很難同時處理好。
- 自己補（看程式推論）：範例直接
routes[route_key]，模型若回了表外的名字就會 KeyError。正式用要加預設路線。
3. 平行化 Parallelization：同一個 prompt，同時處理多份輸入
- 做法：
ThreadPoolExecutor開 3 個 worker，每份輸入各呼叫一次，最後收齊。 - 範例：同一份「市場變化影響分析」prompt，同時套到客戶、員工、投資人、供應商四個群體。
- 何時用：子任務彼此獨立，而且事先就知道要切成哪幾份。
4. 協調者—工作者 Orchestrator-Workers：切法由模型當場決定
- 兩階段：
- 分析規劃：協調者模型讀任務，輸出
<analysis>和一串<task><type>…</type><description>…</description></task>。prompt 要求切成 2–3 個不同做法。 - 執行：每個工作者拿到「原始任務＋自己的 type＋description＋其他 context」，輸出
<response>。
- 分析規劃：協調者模型讀任務，輸出
- 和平行化的差別：子任務不是事先寫死，而是每次依輸入產生。範例是環保水壺文案，協調者自己決定寫「規格型／生活情感型／實用效益型」三版。
- 成本：N+1 次呼叫（1 個協調者＋N 個工作者）。
- 範例沒做、要自己補的：
- 工作者是一個接一個跑的，可改用 asyncio 或執行緒池平行。
- 工作者回空字串時，範例會塞一段錯誤訊息當結果。正式用應加重試。
- 範例沒有彙整階段，可加一個模型把工作者的結果合起來。
- 可以用 Opus 當協調者、Haiku 當工作者來壓成本。
- 會壞在哪：協調者切得不好（prompt 最關鍵）、工作者回空或格式錯、模型沒照 XML 格式導致解析失敗（可改用 JSON）。
5. 評估者—優化者 Evaluator-Optimizer：一個寫，一個挑，改到過關
- 做法：
- 生成者輸出
<thoughts>和<response>。 - 評估者只評不寫，輸出
<evaluation>（PASS／NEEDS_IMPROVEMENT／FAIL）和<feedback>。只有完全沒建議時才能給 PASS。 - 不是 PASS，就把「之前所有版本＋這次回饋」塞回生成者的 context，再生一版。
- 生成者輸出
- 範例：實作 O(1) 的
push／pop／getMin堆疊。第一版演算法正確，評估者仍要求改：空堆疊要丟例外、補型別標註和 docstring。 - 適用的兩個訊號：① 給了回饋，產出確實會變好；② 模型自己就能給出有意義的回饋。前提是評分標準清楚。
- 自己補（看程式推論）：範例的迴圈是
while True，沒有次數上限。評估者標準太嚴（「沒有任何建議才 PASS」）時可能停不下來。一定要加最大輪數。
6. 怎麼選
| 你的狀況 | 選 |
|---|---|
| 步驟固定、可以拆成依序的小步 | 提示鏈 |
| 輸入分好幾類，各類處理方式不同 | 路由 |
| 子任務獨立，切法事先知道 | 平行化 |
| 子任務獨立，但切法要看輸入才知道 | 協調者—工作者 |
| 有明確評分標準，改一輪會更好 | 評估者—優化者 |
模式可以疊：路由之後接提示鏈，協調者的工作者再各自跑評估迴圈。
7. 什麼時候才升級成自主 agent
repo 對「何時升級」沒有直接寫判準。以下是推論：上面五種的步驟數和分支都由你的程式碼決定；當「要做幾步、下一步做什麼」得看中途查到的結果才知道，固定流程寫不出來時，才換成讓模型自己決定下一步的 agent。
升級後，repo 的研究型 agent prompt（prompts/research_lead_agent.md、research_subagent.md）示範了要另外加的預算規則：
- 先判斷題型再決定派幾個子 agent：直接題 1 個；一般 2–3 個；中等 3–5 個；高複雜 5–10 個，上限 20 個。「更多子 agent＝更多開銷」，寧可少而能幹。
- 子 agent 自訂工具呼叫預算：簡單題 5 次以下、中等約 5 次、難題約 10 次、非常難最多 15 次；硬上限 20 次呼叫、約 100 個來源，超過就被終止。
- 報酬遞減就停：已經能給夠好的答案，就不再派新的子 agent，直接寫報告。
- 最終報告由主 agent 自己寫，不外包給子 agent。
🧪 我實際套用的紀錄
- 2026-11-02：（待填）
⚠️ 注意 / 什麼時候不適用
- repo 明說這些是示範核心概念的範例，不是正式產品程式碼：沒有重試、逾時、輪數上限。
- 單一輸出、一次呼叫就夠好的任務，不要硬套。協調者—工作者在「簡單任務」「延遲很敏感」「子任務永遠一樣」時都不建議用。
- 用 XML 標籤解析時，模型漏標籤
extract_xml會回空字串，不會報錯。下游要檢查空值。 - 多個模型分頭做會有上下文分裂、錯誤放大的問題，見 多 Agent 編排與 Agent Drift。
🔗 相關工具
- 多 Agent 編排與 Agent Drift：多 agent 拓撲、何時有用、何時垮掉、偏移診斷
- ReAct 與 Agent Loop：升級成自主 agent 後的迴圈怎麼寫、怎麼停
- 工具-AI-Agent設計：agent 的規劃、工具、記憶三要素
- 工具-agent的測試金字塔：換模式後怎麼確認沒變差
- 工具-讓模型寫程式一次呼叫多個工具：工具呼叫很多時，把迴圈交給模型寫的程式碼