三種 Workflow Patterns

TL;DR

• Chaining：A → B → C 連環，每步用上一步的輸出，單一 prompt 太擠時的解法
• Routing：先分類、再丟對應 prompt，輸入種類差異大時用
• Parallelization：同一輸入丟多個 prompt 同時跑、最後合，多面向評估時用

一個情境：社群行銷工具

假設你在做一個工具——使用者輸入主題，產出短影片發到社群。看起來很單純的功能，但拆開後會用到三個 pattern：

1. 從關鍵字找熱門 topic（chaining：搜尋 → Claude 挑最有趣 → Claude 寫腳本 → TTS → 上架）
2. 不同主題要不同口吻（routing：先分類「教育 / 娛樂 / 喜劇」→ 走對應的 prompt 模板）
3. 每段腳本要評三個面向（parallelization：節奏、用詞、賣點同時各跑一個 prompt → 合成最終評分）

這三個都不是抽象學術概念，而是你做 LLM 系統一定會用到的招。

Pattern 1：Chaining（鏈式）

把一個複雜任務拆成 N 個依序執行的小任務，每一步只專注一件事。

input ──► [Claude A] ──► [Claude B] ──► [Claude C] ──► output
              (挑主題)      (做研究)      (寫腳本)

經典場景：長 prompt 違反限制

你叫 Claude 寫一篇技術文章，限制：

• 不要說自己是 AI
• 不要用 emoji
• 不要老套用語
• 要專業口吻

塞在同一個 prompt 裡，Claude 常常違反其中一兩條。改成兩步 chain：

# Step 1: 寫初稿（接受不完美）
draft = chat([{"role": "user", "content": f"寫一篇關於 {topic} 的技術文章"}])

# Step 2: 拿初稿叫 Claude 自己改
revised = chat([{"role": "user", "content": f"""
修改下面的文章，依序：
1. 移除任何「我是 AI」的提及
2. 移除所有 emoji
3. 改寫老套句子成專業技術寫作風格

文章：
{draft.content[0].text}
"""}])

為什麼有效：第二步 Claude 只在乎「修問題」，不用同時想內容創作。注意力集中，限制就更穩。

何時用 chaining

• 一個 prompt 寫太長、Claude 開始忘記其中幾條
• 步驟之間想插入非 LLM 處理（DB query、外部 API）
• 想對中間結果做 validation 才繼續

Pattern 2：Routing（路由）

先用 Claude 把輸入分類，再丟給對應 prompt 模板。

                ┌─► [Educational prompt] ──► output
                │
input ──► [router] ┼─► [Entertainment prompt] ──► output
                │
                └─► [Comedy prompt] ──► output

經典場景：輸入種類差異大

同一個社群行銷工具，使用者輸入「Python functions」跟「衝浪」應該得到完全不同口吻的腳本——但用同一個 prompt 兩邊都顧不好。

# Step 1: 分類
category = chat([{"role": "user", "content": f"""
把下面主題分類，只回類別名：
<topic>{user_topic}</topic>
<categories>
- Educational
- Entertainment
- Comedy
- Personal vlog
</categories>
"""}]).content[0].text.strip()

# Step 2: 用對應模板
prompt_map = {
    "Educational": "寫一個清晰、舉例豐富的教學腳本…",
    "Entertainment": "寫一個高能量、有梗、節奏快的腳本…",
    # ...
}
script = chat([{"role": "user", "content": prompt_map[category].format(topic=user_topic)}])

何時用 routing

• 應用要處理多種任務類型（客服分類、內容生成）
• 你能事先列出有限類別
• 每個類別有自己的 specialized prompt / tools / 後處理

注意：分類那步要單獨 eval，分錯就整條後面都廢了。

Pattern 3：Parallelization（平行）

把同一輸入同時丟給多個 prompt，每個專注一個面向，最後 aggregate。

        ┌─► [評估 metal 適用度]   ─┐
        │                          │
input ──┼─► [評估 polymer 適用度] ─┼─► [aggregator] ──► 最終推薦
        │                          │
        └─► [評估 ceramic 適用度] ─┘

經典場景：多面向評估擠在一個 prompt

「給我這零件圖，幫我從金屬 / 高分子 / 陶瓷 / 複合材 / 木頭挑一個最適合」——塞進一個 prompt，Claude 要同時權衡 5 種材料的優缺點，常常顧此失彼。

拆開：

import asyncio

materials = ["metal", "polymer", "ceramic", "composite", "wood"]

async def evaluate(material):
    return await async_chat([{"role": "user", "content": f"""
評估這個零件用 {material} 製作的適合度。
考慮：強度、成本、加工難度、耐用度。
只考慮 {material}，不要比較其他材料。
"""}])

# 5 個 request 同時發
analyses = await asyncio.gather(*[evaluate(m) for m in materials])

# Aggregator 看完整理出最終答案
final = chat([{"role": "user", "content": f"""
看完下面 5 份分析，挑出最適合的材料並說明理由：
{format_analyses(analyses)}
"""}])

何時用 parallelization

• 評估獨立面向（彼此不互相依賴）
• 想加速（同時跑省 latency）
• 想單獨 eval 每個面向的 prompt

三個 pattern 的差異

Pattern	形狀	何時用	擴充方式
Chaining	線性 A→B→C	步驟之間有依賴	加新步驟
Routing	分支	輸入種類差異大	加新類別 + 新模板
Parallelization	扇出再合併	多面向獨立評估	加新並行任務

實務上會混用。社群行銷例子：先 chain 找主題、再 route 決定口吻、最後 parallel 評估腳本，這就是一個複合 workflow。

接下來

下一篇處理另一邊——agent。當你發現流程圖畫不出來、步驟數無法事先決定時，就該把控制權交回給 Claude。我們會看 agent 的四個元素（tools / state / loop / stop），怎麼讓它先看環境再動手，以及為什麼 MCP 系列 介紹的 MCP server 是 agent tool 的最佳供應源。