Agentic AI Plan-and-Execute 多 Agent 架構降低 90% 推理成本實戰

你的 AI Agent 系統每月燒掉五位數美金的 API 費用，但其中超過 80% 的 token 其實不需要用到最貴的模型。這不是假設，而是我在三個生產環境中反覆驗證的結論。Plan-and-Execute 架構搭配異構 LLM 分工，能讓你在維持輸出品質的前提下，把推理成本壓到原本的十分之一。

Plan-and-Execute 模式到底在解決什麼問題

傳統的 ReAct 架構讓單一 LLM 同時負責推理和行動，每一步都需要完整的思考鏈。問題在於：一個複雜任務可能需要 15-20 步，每一步都用 Claude Opus 或 GPT-4o 來處理，成本會線性甚至超線性增長。

Plan-and-Execute 的核心概念很直覺：把「想清楚要做什麼」和「實際去做」拆開成兩個階段。Planner 負責分析任務、拆解步驟、決定執行順序；Executor 則按照計畫逐步完成具體操作。這兩個角色對模型能力的要求天差地別。

規劃階段需要強大的推理能力、全局觀和長文本理解，這正是旗艦模型的強項。但執行階段？多半是格式化輸出、API 呼叫、資料轉換這類結構化任務，用輕量模型就能勝任。這個洞察就是異構 LLM 架構的理論基礎。

異構 LLM 架構：讓對的模型做對的事

所謂異構 LLM 架構，就是在同一個 Agent 系統中混用不同等級的模型。實務上的分工策略如下：

規劃層（Planner）：Claude Opus、GPT-4o 等旗艦模型，負責任務分解、策略決策、異常處理方案設計
執行層（Executor）：Claude Haiku、GPT-4o-mini 等輕量模型，負責按指令完成具體步驟
驗證層（Validator）：中階模型如 Claude Sonnet，負責檢查執行結果是否符合計畫預期

以一個典型的資料處理 pipeline 為例：Opus 分析需求並產出 5 步執行計畫，Haiku 執行每一步的資料轉換，Sonnet 在最後驗證輸出品質。整體 token 分配大約是 5% 給規劃、85% 給執行、10% 給驗證。

成本分析：90% 節省是怎麼算出來的

直接上數字。假設一個任務總共消耗 100K tokens：

單一旗艦模型方案：100K tokens × $15/MTok（以 Opus 輸出價計算）= $1.50

異構架構方案：

規劃（Opus）：5K tokens × $15/MTok = $0.075
執行（Haiku）：85K tokens × $1.25/MTok = $0.106
驗證（Sonnet）：10K tokens × $3/MTok = $0.030
合計：$0.211

節省幅度：85.9%。如果執行層任務更簡單，能用更便宜的模型或更少的 token，節省比例可以輕鬆突破 90%。而且這還沒算上 Haiku 回應速度快 3-5 倍帶來的延遲降低效益。

用 LangGraph 實作 Plan-and-Execute

如果你已經熟悉 LangGraph 的 State Graph 架構，實作 Plan-and-Execute 其實非常自然。核心是定義三個節點和狀態流轉邏輯：

from langgraph.graph import StateGraph, END
from langchain_anthropic import ChatAnthropic

# 異構模型配置
planner_llm = ChatAnthropic(model="claude-opus-4", temperature=0)
executor_llm = ChatAnthropic(model="claude-haiku-4", temperature=0)
validator_llm = ChatAnthropic(model="claude-sonnet-4", temperature=0)

def plan_node(state):
    """Planner: 用旗艦模型分解任務"""
    plan = planner_llm.invoke(
        f"分解以下任務為可執行步驟：{state['task']}"
    )
    return {"plan": parse_plan(plan), "current_step": 0}

def execute_node(state):
    """Executor: 用輕量模型執行單一步驟"""
    step = state["plan"][state["current_step"]]
    result = executor_llm.invoke(
        f"執行以下步驟：{step}"
    )
    return {
        "results": state.get("results", []) + [result],
        "current_step": state["current_step"] + 1
    }

def validate_node(state):
    """Validator: 中階模型驗證結果"""
    validation = validator_llm.invoke(
        f"驗證執行結果是否符合計畫：{state['results']}"
    )
    return {"validation": validation}

# 建構 Graph
graph = StateGraph(AgentState)
graph.add_node("plan", plan_node)
graph.add_node("execute", execute_node)
graph.add_node("validate", validate_node)

重點在於 should_continue 條件邊的設計。當所有步驟執行完畢才進入驗證，驗證失敗則觸發重新規劃。這種架構與 Google ADK 的 Multi-Agent 框架理念一致，都強調明確的職責分離。

模型選擇策略與動態路由

固定的三層分工是起步，更進階的做法是動態模型路由。根據任務複雜度即時決定該用哪個模型：

複雜度評估器：用輕量模型快速評估每個子任務的難度，決定是否需要升級到更強的模型
信心分數閾值：Executor 輸出時附帶信心分數，低於閾值自動升級到中階或旗艦模型重做
任務類型路由表：預先定義不同任務類型對應的模型，例如程式碼生成用 Sonnet、純文字格式化用 Haiku

這種策略在 Claude Code Agent Teams 的多 Agent 並行開發中也有類似的實踐，不同能力等級的 Agent 負責不同複雜度的任務。

錯誤處理與降級策略

異構架構最容易踩的坑是執行層模型能力不足導致的靜默錯誤。幾個必備的防護機制：

結構化輸出驗證：每個 Executor 步驟都用 Pydantic schema 驗證輸出格式，格式錯誤立即重試
自動升級機制：同一步驟連續失敗 2 次，自動升級到更強模型。成本增加但避免無限重試
計畫修正迴圈：Validator 發現結果偏差超過閾值，將失敗資訊回傳給 Planner 重新規劃，而非重複執行錯誤的計畫
成本熔斷器：設定每次任務的 token 消耗上限，超過後強制中止並通知，防止重試風暴

單一模型 vs 異構多模型：什麼時候該用哪個

異構架構不是銀彈。以下是選擇建議：

適合異構架構：任務可清楚拆解為規劃和執行、執行步驟多且重複性高、對成本敏感的生產環境、批次處理場景。

適合單一模型：任務步驟少且高度耦合、需要跨步驟的深度上下文理解、原型開發階段追求快速迭代、任務複雜度無法事先評估。

實務上，大多數生產級 Agent 系統最終都會走向異構架構，因為成本壓力在規模化後會變得非常明顯。

生產環境最佳實踐

跑了半年的生產環境經驗，幾個關鍵心得：

先用單一模型建立 baseline：確認任務可行後再拆分，避免過早優化
每個步驟獨立可測試：Planner 產出的每一步都應該是 self-contained 的指令，不依賴隱含上下文
監控模型升級比率：如果超過 30% 的執行步驟需要升級模型，代表 Planner 的任務拆解不夠細
版本控制 Prompt：不同模型的 system prompt 需要獨立調整，旗艦模型的 prompt 搬到輕量模型通常效果會大幅下降
A/B 測試成本與品質：建立評估框架，量化不同模型配置下的輸出品質，找到成本和品質的最佳平衡點

結語

Plan-and-Execute 搭配異構 LLM 不是什麼前沿研究，它是一個已經在生產環境驗證過的工程實踐。核心就一句話：用最貴的腦力做最需要腦力的事，其他交給便宜又快的執行者。當你的 Agent 系統開始面臨成本壓力，這個架構幾乎是必然的演進方向。先從一個明確的 use case 開始試，跑出數據再逐步推廣，你會發現帳單上的數字比想像中更讓人驚喜。