AI Agent 工作流程模式：7 種模式與各自真正勝出的時機（2026）

AI Agent 工作流程模式：7 種模式與各自真正勝出的時機（2026）

AI Agent 工作流程模式終於有了數字佐證：2026 年 1 月，Google Research 評估了 180 種 agent 配置，發現同一項協調方式的改變，讓可平行化的金融推理提升了 80.9%，卻讓 PlanCraft 上的序列式規劃最多下降 70%。同一個槓桿，結果完全相反。決定勝負的變數是任務可分解性，而不是 agent 數量；下文以公開數據而非供應商示意圖，逐一檢視這 7 種模式。

• 重要的模式有 7 種：序列式、路由式、平行化、orchestrator-workers、反思式、ReAct、plan-and-execute。
• 任務可分解性決定贏家。可平行化的工作會受益，序列式工作會退化。
• 從單一 agent 開始。只有當單一 agent 的準確度停滯在約 85% 以下時，才加入第二個。

AI Agent 工作流程模式總覽：數據說了什麼

這 7 種 AI Agent 模式分別是：序列式（prompt chaining）、路由式（handoff）、平行化（fan-out/fan-in）、orchestrator-workers、反思式（evaluator-optimizer）、ReAct，以及 plan-and-execute。5 家供應商的文件各有不同命名，但這 7 種架構涵蓋了 Anthropic、OpenAI、Vercel、Microsoft 與 Google Cloud 目前公開的所有分類。人機協同（human-in-the-loop）不屬於這 7 種：它是包覆在任何一種模式外層的控制層。

「實測」這一欄要用懷疑的眼光看。只有 3 列有真實數字，另外 4 列寫著「無公開數據」，這正是 2026 年這個領域誠實的現狀。5 家供應商為實際上 3 到 4 種底層架構，取了 5 套不同名字。最後一欄的存在，就是讓你可以把任何名字對應回底層架構；本文後續會逐一拆解每個家族。

SERP 上沒有人討論的兩欄，是 token 成本與延遲預算。序列式與路由式在兩者上都花得最少；orchestrator-workers 在兩者上都花得最多；平行化則是用 token 花費換取牆鐘時間。選模式時，依據你的任務真正受限的資源來挑，而不是挑示意圖看起來最響亮的那個。

什麼是 AI Agent 工作流程模式（AI 工作流程的 4 個階段是什麼？）

AI Agent 工作流程設計模式，是把 LLM 呼叫、工具使用與控制邏輯組裝成系統的可重用架構。在每家供應商的分類中反覆出現的 7 種，就是序列式、路由式、平行化、orchestrator-workers、反思式、ReAct 與 plan-and-execute。每一種在 token 成本、延遲與準確度上的取捨都不同，所以正確選擇取決於任務的結構，而不是你碰巧使用的框架。

一個典型的 AI Agent 工作流程以迴圈方式執行 4 個階段：

1. 規劃（Plan）：模型根據目標與目前的歷史，決定下一步要做什麼。
2. 行動（Act）：呼叫工具，在 2026 年通常指 MCP 伺服器或函式呼叫。Model Context Protocol（MCP）讓這個工具層在不同模型之間標準化。
3. 觀測（Observe）：工具結果作為新訊息回到上下文中。
4. 反思／迴圈（Reflect / loop）：模型判斷結果是否足夠好，然後繼續迴圈或停止。

本文中的每一種模式，都是這 4 個階段的不同接線方式。序列式在程式碼中固定順序；ReAct 讓模型每一輪自己挑下一個階段；orchestrator-workers 則把迴圈拆分到多個模型上。

在進入型錄之前，有一個區別很重要。工作流程（workflow）是預先決定的程式碼路徑；agent 則把控制權交給模型。Anthropic 在 Building Effective Agents 中這樣劃線：「對明確定義的任務，工作流程提供可預測性與一致性；而當彈性與模型驅動的決策需要大規模運作時，agent 是更好的選擇。」

如果你是為了 AI 中經典的 agent 類型（簡單反射式、模型基礎式、目標基礎式、學習式）而來，那套分類早於 LLM；上面這 7 種模式，才是決定你的建置能否上線的那一批。

確定性模式：序列式、路由式與平行化

有 3 種模式把控制權留在你的程式碼裡，而不是模型裡。它們執行成本最低，也最容易偵錯；Claude 團隊在 2026 年 3 月的建議說得很直白：「從能解決問題的最簡單模式開始。預設選序列式。」

序列式（prompt chaining）

一次呼叫的輸出餵給下一次。你把困難任務拆成有序步驟，每一步都以上一步的輸出作為輸入。好處是可讀性：你可以檢查每個中間結果，並為每一步做快取。當子任務彼此獨立時就該避免它，因為你正在為不需要的排序付出延遲。如果狀態必須在步驟之間或跨工作階段保存，那是記憶體問題，不是鏈結問題；兩者的分界可參考我們的 agent 記憶體指南。它唯一公開的背書是「預設選項」：沒有研究衡量過鏈結本身帶來的效益，因為它是其他所有模式都要額外花成本去超越的基準線。

from anthropic import Anthropic

client = Anthropic()

def chain(steps: list[str], context: str = "") -> str:
    for step in steps:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
        )
        context = msg.content[0].text
    return context

summary = chain([
    "Extract the five key claims from this report: {report}",
    "Rewrite those claims as bullets an engineer would trust.",
])

路由式（handoff）

一個便宜的分類器讀取輸入，再分派給專家提示或模型。OpenAI 在 Agents SDK 文件中這樣描述：「分診 agent 把對話路由給專家，該專家就成為這一輪剩餘時間的現役 agent。」當分類器不如直接跑一條通用路徑可靠時，就該避免路由，因為每一次誤判路由都是一個無聲的錯誤答案。這裡有名的失敗模式，是交接過程中的上下文流失：專家只看得到路由器轉交的東西。是否攜帶完整軌跡，是一個上下文工程決策；做錯了，正是路由系統讓人覺得健忘的原因。即便如此，token 的算術仍然有利於路由：分類器跑在小模型上（上面用的是 gpt-4o-mini），所以路由器每個請求只多加幾百個便宜 token，而不是第二次昂貴呼叫。

from openai import OpenAI

client = OpenAI()
SPECIALISTS = {
    "billing": "You answer billing and refund questions.",
    "technical": "You debug API errors and integration issues.",
}

def route(question: str) -> str:
    triage = client.responses.create(
        model="gpt-4o-mini",
        input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
    )
    key = triage.output_text.strip().lower()
    return client.responses.create(
        model="gpt-4o",
        instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
        input=question,
    ).output_text

平行化（fan-out/fan-in）

獨立的子任務同時執行，再由合併步驟把它們結合起來。Anthropic 把它細分為切分（sectioning，把工作切開）與投票（voting，同一任務跑多次再比較）。這正是 Google Research 在 2026 年 1 月測出較單一 agent 提升 +80.9% 的架構，場景是可平行化的金融推理，原因恰恰在於該任務能被乾淨地分解。只要第 n+1 步依賴第 n 步的輸出，就立刻避免它；平行化一條依賴鏈，只是更快地把錯誤答案重新排序。延遲是這項收益的另一半：獨立呼叫可同時執行，所以牆鐘時間大約隨工作者數量下降，而 token 總花費維持不變。

from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic

client = Anthropic()

def run(subtask: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": subtask}],
    )
    return msg.content[0].text

def fan_out(subtasks: list[str]) -> list[str]:
    with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
        return list(pool.map(run, subtasks))

parts = fan_out([
    "Summarize Q1 revenue drivers in two sentences.",
    "Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")

ReAct 與 Plan-and-Execute：該用哪種推理模式？

ReAct 把推理與行動交錯進行：模型思考、呼叫工具、觀測結果，然後才決定下一步。Plan-and-execute 則在任何工具執行之前先寫出完整計畫，再依序執行步驟。ReAct 能在執行中途適應意外；plan-and-execute 則預先為一次大型規劃呼叫付費，並信任這條路徑。

ReAct 在每次觀測之後決定下一步；plan-and-execute 在第一次工具呼叫之前，就確定整條路徑。

ReAct 出自 Yao 等人（arXiv 2210.03629，v1 為 2022 年 10 月，v3 為 2023 年 3 月），該論文回報在 ALFWorld 上較模仿學習與強化學習基準絕對提升 +34%，在 WebShop 上提升 +10%，而且只用了一兩個上下文範例。它是大多數工具使用型 agent 背後的預設迴圈，也是 SERP 第 3 名結果的一個缺口：Microsoft Learn 那份 7,133 字的編排文件完全沒提 ReAct。正是這種「觀測-決策」的節奏，讓 ReAct 處理開放式任務（「瀏覽直到找到 X」）比任何事先規劃都好：事先規劃必須在讀取頁面之前就猜中頁面內容。

Plan-and-execute 出自 Wang 等人的 Plan-and-Solve Prompting（arXiv 2305.04091，ACL 2023），該方法先擬出把任務拆成子任務的計畫，再逐一執行。論文回報在全部 10 個受測資料集上都勝過 zero-shot chain-of-thought；我們不引用單一數字，因為論文摘要沒有公布任何一個。當路徑可預測、且每步之後都重新規劃會浪費 token 時，就適合用它。代價是脆弱：如果第 3 步失敗，plan-and-execute 迴圈需要一個明確的重規劃掛鉤，而 ReAct 在結構上就會自行重規劃。

「實測證據」這一列是誠實的訊號。ReAct 有一篇 2022 年的論文，附帶任務層級的數字；plan-and-execute 有橫跨 10 個資料集的全面測試，卻沒有頭條數字，這也是它被引用的次數多於被基準測試次數的原因之一。

from anthropic import Anthropic

client = Anthropic()

def react(question: str, tools: list, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if msg.stop_reason == "end_turn":
            return msg.content[0].text
        messages.append({"role": "assistant", "content": msg.content})
        messages.append({"role": "user", "content": dispatch(msg.content)})
    return "Stopped: hit the iteration cap with no final answer."

那個迭代上限不是可有可無的。沒有出口的 ReAct 迴圈會燒 token，直到你的預算燒完為止；max_steps 是整篇文章裡最便宜的護欄。Plan-and-execute 需要在高一層加上同樣的護欄：設上限的不只是步驟，還有重規劃次數，否則一個失敗的計畫會無限期地重新產生自己。

品質模式：反思式、Evaluator-Optimizer 與人機協同

品質模式花額外 token 來提升輸出品質，而且只有在品質可衡量時才划算。反思式（Anthropic 稱之為 evaluator-optimizer）讓產生者與批評者在迴圈中運行：一個模型起草，另一個批評，草稿隨之改善。如果你沒辦法用測試、評分規準或評分模型為輸出打分，那批評者只是在跟自己爭論的多餘 token。建出那個評分器才是難處；我們的生產環境 agent 評估指南說明了一個可用的評分函式需要什麼。當前提成立時，這個模式就是便宜的保險：Anthropic 把 evaluator-optimizer 描述為迴圈中的兩次 LLM 呼叫，一次產生、一次批評，用幾秒額外延遲換來可衡量的品質提升。

沒有人畫進示意圖的失敗模式，是失控的反思：批評者與產生者永遠迴圈下去，或更糟，來回震盪。解法是硬性迭代上限加上「無改善即中止」，寫在程式碼裡，而不是在提示裡要求：

def refine(task: str, score_fn, max_rounds: int = 4) -> str:
    best = generate(task)
    best_score = score_fn(best)
    for _ in range(max_rounds):
        critique = critic(task, best)
        candidate = generate(f"{task}\n\nCritique:\n{critique}")
        score = score_fn(candidate)
        if score <= best_score:
            break  # no improvement: stop spending tokens
        best, best_score = candidate, score
    return best

人機協同（human-in-the-loop）是控制層，不是第 8 種模式。它包覆在 7 種模式的任何一種之外：由人類在不可逆步驟執行前核准。SERP 前 6 名結果中只有 2 個有提到它。把關卡設在不可逆的動作、真實花費，以及任何會以對外溝通形式離開你系統的東西上。其他一切都應該無人值守地執行，或者根本不執行。關卡本身應該是笨拙的程式碼，而不是另一個 LLM：一個核准佇列、一個花費門檻、一個網域允許清單。讓模型來決定人類該不該看，就違背了目的。

多 Agent 值得花 15 倍 Token 嗎？基準測試實際說了什麼

Orchestrator-workers 是第 7 種模式：由主 agent 分解任務，把各部分委派給工作者 agent，再合併它們回傳的結果。「多 agent」是這個模式推到極致，而不是另一種獨立架構，所以真正的問題是：編排者何時賺回它的額外開銷。

什麼時候該用多 agent 而非單一 agent？只有當單一 agent 在該任務上的準確度停滯在約 85% 以下時。這條經驗法則在 r/AI_Agents 上（2026-04-23）與 Google Research 的研究一起流傳，而且與實測數據吻合：超過那條線之後，增加 agent 只會增加成本與錯誤放大，不會增加準確度。

以下是我們能驗證的全部公開數字，並列呈現：

點進連結之前先提醒一點：上面每一個 Google Research 數字都來自 2026-01-28 的部落格文章，而其背後的論文（arXiv 2512.08296）此後經過修訂，所以目前版本回報的是 260 種配置與 R² = 0.373，而非部落格的 180 與 0.513。無論哪個版本，方向都一致；確切數字取決於你讀的是哪一版。

其中有兩列經常被誤引，所以這裡列出算術。Anthropic 的 15 倍是相對於聊天互動測得的，而它的單一 agent 數字是 4 倍。所以多 agent 的成本大約是單一 agent 的 15 / 4 = 3.75 倍 token，而不是 15 倍。而 Google Research 的錯誤放大，獨立式 agent 17.2 倍、集中式 4.4 倍，代表編排者的錯誤放大比放任 agent 無人監督少了大約 17.2 / 4.4 = 3.9 倍。

把 Anthropic 的報告對照 Google Research 的數字，我們的解讀是：決定勝負的變數是可分解性，而不是 agent 數量。Anthropic 的研究任務能乾淨地拆成平行子搜尋，所以更多 agent 有幫助。Google 的序列式規劃任務拆不開，所以更多 agent 反而互相妨礙。

這與實務工作者在系統上線之後的說法一致。在 r/AI_Agents 上，一個標題為「Multi agent systems are a total nightmare in production」的討論串（2026-04-23，56 分，68 則留言）來自一位已交付 20 多個客戶系統的發文者：「那些真的持續在跑的……幾乎簡單到令人難為情」，以及「每次一個 agent 跟另一個說話，你就會失去上下文。就像那場傳話遊戲。」最高分留言濃縮了整節的結論：「試著用單一 agent 解決你的問題。如果這個 agent 的準確度超過 85%，多 agent 系統不會再增加任何價值。」

在加入 agent 之前，先試試 Anthropic 測過的便宜修正：一則改善過的工具描述讓任務完成時間下降 40%，平行工具呼叫則讓研究時間最多減少 90%。兩者在成本上都勝過第二個 agent。如果你真的要在實際工具裡走向多 agent，Claude Code subagents 是你可以逐行檢視的 orchestrator-workers。

同一種模式，五個名字：框架羅塞塔對照表

同樣的 4 種架構，在每家供應商的文件裡都以不同名字出現，而且命名無法跨框架通用。Microsoft 的「magentic」與「group chat」在 OpenAI SDK 裡毫無意義，除非你先翻譯；而這筆翻譯稅是實實在在的成本，這張表格把它消除了。

5 家供應商，5 套詞彙，3 到 4 種真實架構。實際成本在你切換框架時浮現：一個從 Microsoft Agent Framework 遷移到 OpenAI SDK 的團隊，必須先把「magentic」對應到 agents-as-tools、把「group chat」對應到 handoff 圖，才能搬移哪怕一行程式碼。Google Cloud 的 11 個名字分類是最長的，Anthropic 的 7 個名字清單是被引用最多的，而 Claude 部落格的 3 個名字是你最先會實作的那些。先讀懂架構，再讀 SDK。各欄欄頭就是文件本身：Anthropic、Claude 部落格、OpenAI Agents SDK、Vercel AI SDK、Microsoft Learn，以及 Google Cloud。一旦你看懂架構，挑框架就是一項獨立的決策；我們的 2026 年最佳 AI agent 框架總覽，以及 LangGraph vs CrewAI vs OpenAI Agents SDK 比較，涵蓋的就是這件事。

什麼時候你根本不該用 Agent 工作流程？

很多時候，你都不該用。r/AI_Agents 上最高票的決策階梯（2026-03-09）講得很清楚：「如果 if…then 語句行得通，就用它。如果傳統工作流程行得通，就用它。否則才用 agentic AI。」SERP 前 3 名中有 2 個是雲端供應商文件，它們在結構上不可能告訴你少蓋一點。我們可以。本文的數據也指向同一個方向：兩項最大的實測收益（+80.9% 與 +90.2%）都來自能乾淨分解的任務，而最慘的實測損失（−70%）來自把 agent 硬塞給一個不能分解的任務。

這些失敗模式都有名字，而且如今每一個都附帶數字：

• 交接時的上下文流失：每一次 agent 對 agent 的訊息都會丟掉狀態（r/AI_Agents 的「傳話遊戲」抱怨，2026-04-23）。
• 錯誤放大：獨立式 agent 17.2 倍，集中式 4.4 倍（Google Research，2026-01-28）。
• 失控的反思迴圈：如上面程式碼所示，設迭代上限，並在無改善時中止。
• 序列式任務退化：把不能分解的工作平行化，會變差 39–70%（Google Research，2026-01-28）。
• 成本爆掉：多 agent 系統大約是聊天 token 的 15 倍（Anthropic，2025-06-13）。

上述每一個失敗模式，都有一個你用十行程式碼就能寫出的上限，而這個上限永遠比你正要加入的那個 agent 便宜。

Cognition 的 Walden Yan 從建置者一方提出了同樣的論點，見 Don't Build Multi-Agents（2025-06-12）：「共享上下文，而且共享完整的 agent 軌跡，不只是個別訊息」，以及「行動帶有隱含決策，而互相衝突的決策會帶來壞結果。」我們反覆回到的，是 r/AI_Agents 上的那句話：「多 agent 開始看起來很像微服務。當邊界是真的時候很強大，當邊界是硬造出來的時候很痛苦。」

Techsy 如何挑選模式

下面這座階梯，是我們對 Google Research 與 Anthropic 研究結果加上實務討論串的解讀，不是我們自己的實測結果。我們由上而下執行，停在第一個符合的列：

本文的數據帶出 3 件事。從序列式開始，因為 Anthropic 這麼說，而且 SERP 上沒有任何東西能反駁。只平行化能分解的部分，因為同一項協調改變測出 +80.9% 的同時，也測出了 −70%。把第二個 agent 視為最後手段，因為 token 帳單是真的，錯誤放大也是實測的。貫穿全文的主軸是：增加 agent 是擴展之舉，不是品質之舉；基準測試只在工作可拆分時獎勵它，而實務討論串在其他所有場景都證實了這一點。如果你想在蓋之前找人對架構給個第二意見，取得免費諮詢。

常見問題

AI Agent 的 7 種模式是什麼？

這 7 種是：序列式（prompt chaining）、路由式（handoff）、平行化（fan-out/fan-in）、orchestrator-workers、反思式（evaluator-optimizer）、ReAct，以及 plan-and-execute。從 Anthropic 到 Google Cloud，它們在每家供應商的分類中都以不同名字反覆出現。人機協同常與它們一起被討論，但它是包覆在 7 種模式之外的控制層，不是第 8 種模式。

AI Agent 工作流程的 4 個階段是什麼？

規劃、行動、觀測、反思。模型規劃下一步，以呼叫工具的方式行動，觀測工具結果進入上下文，然後反思目標是否達成，並繼續迴圈或停止。本文中的每一種模式，都是把這 4 個階段以不同方式接線。

AI 工作流程與 AI Agent 有什麼差別？

工作流程遵循預先決定的程式碼路徑；agent 則讓模型指揮自己的控制流。Anthropic 的準則：對明確定義的任務用工作流程取得可預測性，當需要大規模的模型驅動決策時用 agent 取得彈性。多數生產環境系統，是內部帶有少數 agent 步驟的工作流程。

ReAct 與 plan-and-execute，該用哪個？

當下一步取決於上一個工具回傳了什麼、且路徑可能在執行中途改變時，用 ReAct。當路徑事先可預測、且每步後重規劃會浪費 token 時，用 plan-and-execute。ReAct 在 ALFWorld 測得 +34%（Yao 等人，2022）；plan-and-execute 在 10 個資料集上勝過 zero-shot CoT（Wang 等人，2023）。

使用這些模式需要 LangGraph 之類的框架嗎？

不需要。本文中的每個程式碼區塊都是純粹的 SDK 呼叫，而這些模式早於為它們命名的框架。框架的價值在於狀態持久化、重試與追蹤，而不在模式本身。如果你正在挑選框架，我們的框架比較涵蓋了各種取捨。

如何防止反思迴圈永遠跑下去？

兩道護欄，都寫在程式碼裡：硬性迭代上限（我們用 4 輪），以及一個無改善即中止的機制，在批評者改寫的分數沒有優於目前草稿的那一刻就停止。不要指望提示會結束迴圈；模型根本不知道東西多少錢。

什麼時候單一 Agent 就夠了？

當它在任務上的準確度達到約 85% 時。這條經驗法則在 r/AI_Agents 上（2026-04-23）與 Google Research 的研究一起流傳，而且與基準測試吻合：超過那條線之後，額外 agent 只會增加成本與錯誤放大，不會增加準確度。在設計任何更大的東西之前，先量出單一 agent 的基準線。

哪裡找得到附程式碼的 AI Agent 工作流程模式範例？

上面 5 個 Python 區塊涵蓋了序列式、路由式、平行化、ReAct 與反思式，全部是純 SDK 呼叫，你可以直接搬用。若要供應商風味的範例，Vercel AI SDK 為每種模式附帶可執行的 TypeScript，OpenAI Agents SDK 文件則涵蓋 handoff 與 agents-as-tools。兩者的連結都在下方的來源清單中。

來源

• Anthropic，Building Effective Agents（2024-12-19）
• Anthropic，How we built our multi-agent research system（2025-06-13）
• Google Research，Towards a science of scaling agent systems（2026-01-28）；論文：arXiv 2512.08296
• Yao 等人，ReAct: Synergizing Reasoning and Acting in Language Models（v3 2023-03-10）
• Wang 等人，Plan-and-Solve Prompting（ACL 2023）
• Claude by Anthropic，Common workflow patterns for AI agents（2026-03-05）
• OpenAI Agents SDK，Orchestrating multiple agents
• Vercel AI SDK，Workflow Patterns
• Microsoft Learn，AI Agent Orchestration Patterns（更新於 2026-05-12）
• Google Cloud，Choose a design pattern for your agentic AI system（2026-05-28）
• Cognition（Walden Yan），Don't Build Multi-Agents（2025-06-12）
• r/AI_Agents，Multi agent systems are a total nightmare in production（2026-04-23）；Wait, are workflows actually better than multi-agent systems?（2026-03-09）