GPT-5.4 mini/nano Subagent 架構實戰指南：哪些任務給旗艦、哪些給 mini、哪些給 nano

你有沒有看過月底的 OpenAI 帳單，發現大部分費用來自那些重複性的子任務——搜尋程式碼、分類文件、抽取結構化資料？我們在自己的 AI agent 系統中也遇到同樣的問題。後來我們發現，問題不是「mini/nano 夠不夠好」，而是「我們從來沒想過哪些任務根本不需要旗艦模型」。

這篇文章用 Planner-Executor-Reviewer 框架，給你一張可以直接套用的任務分配決策表。根據我們實際把 content pipeline 中的子任務逐一測試 mini 的經驗，以下是真實的結果和建議。

TL;DR

• GPT-5.4 mini/nano 不是便宜版旗艦——OpenAI 明確設計它們為多模型 agent 架構中的特定角色
• Planner-Executor-Reviewer 三層架構：旗艦規劃、mini 執行、nano 分類，可節省 ~70% API 費用
• mini 的 coding benchmark 僅差旗艦 3%（OpenAI 自述），但在 128K+ context 任務上準確率從 79.3% 降到 33.6%（Simon Willison 個人實測）
• nano 的幻覺率 3.1% 在 grounded summarization 測試中比某些旗艦模型更低（Vectara HHEM-2.3 獨立測試），但這只適用於結構化抽取，不是通用準確性指標
• 最務實的策略：不是「全部換成 nano」，而是「新增的重複性子任務用 mini/nano，現有工作流不動」

GPT-5.4 mini/nano 不是「便宜版旗艦」：它們被設計來扮演不同角色

大多數人看到 mini/nano 的第一反應是「便宜但打折版的 GPT-5.4」。但如果你去讀 OpenAI 的官方發布文件，定位完全不同。

OpenAI 在 2026 年 3 月 17 日發布 GPT-5.4 mini 和 nano 時，明確定義了它們的角色：nano 適合「classification, data extraction, ranking, and coding subagents for simpler supporting tasks」；mini 則適合「systems that combine models of different sizes, where GPT-5.4 handles planning while mini subagents handle narrower subtasks in parallel」。The New Stack 的報導標題直接寫明：「GPT-5.4 mini and nano are built for the subagent era」。

這裡有一個反直覺的事實：nano 在 Vectara HHEM-2.3 的 grounded summarization benchmark 中，幻覺率只有 3.1%——比 GPT-5.4-pro 更低。原因是 nano 被訓練為保守型回答：不確定的時候不生成，而不是硬湊一個看起來合理的答案。

重要：這個 3.1% 幻覺率來自 Vectara 的 grounded summarization 測試（usewire.io 報導），專門衡量模型「是否忠於原文」的能力，不是通用準確性指標。在開放式問答或複雜推理任務上，nano 仍然明顯不如旗艦模型。這也是為什麼 nano 適合做分類和抽取，而不是做規劃或判斷。

所以正確的問題不是「mini/nano 比 GPT-5.4 差多少」，而是「在我的 agent 系統中，哪些子任務的特性剛好符合 nano 的強項（結構化、短 context、高重複）」。

Planner-Executor-Reviewer 三層架構：降低 70%+ 成本的設計邏輯

理解了 mini/nano 的角色定位後，下一個問題是「具體怎麼用」。答案是 Planner-Executor-Reviewer 三層架構——這不是我們發明的框架，而是 OpenAI 在發布 mini/nano 時實際描述的使用模式。

架構邏輯很直覺：

Planner（旗艦模型：GPT-5.4 / Claude Opus）
  → 分析任務需求、制定計畫、做最終判斷
  → 處理複雜推理、需要全局理解的決策

Executor（GPT-5.4 mini）
  → 執行 Planner 分配的子任務：搜尋程式碼、處理文件、平行跑多個任務
  → 適合需要速度和 CP 值的執行層

Reviewer / Classifier（GPT-5.4 nano）
  → 快速分類、資料抽取、結構化輸出
  → 適合高量重複的品質驗證步驟

The Neuron Daily 用了一個很精準的比喻：旗艦模型是 senior manager，mini/nano 是實習生執行重複任務。你不會讓 senior manager 去做 500 筆資料的分類，同樣不會讓實習生去做戰略規劃。

根據我們實際在 content pipeline 中的測試，把 classification 和 data extraction 步驟從旗艦模型換成 mini/nano 後，這些子任務的 API 成本降低了約 70%，而且輸出品質在結構化任務上幾乎沒有差異。關鍵在於任務量和單次費用的乘積效應——你的 agent 系統中，70-80% 的 API 呼叫通常是重複性子任務，這些才是真正燒錢的地方。用一個模型做所有事，就像用一把刀切所有食材——可以，但不聰明。

任務分配決策表：一張表決定用哪個模型

這是本文最重要的部分。根據 OpenAI 官方文件和我們的實際測試，以下是每種任務類型的建議模型：

任務類型	建議模型	理由
策略規劃、最終判斷	旗艦（GPT-5.4 / Opus）	需要複雜推理，出錯成本高
程式碼搜尋、文件處理（<100K tokens）	mini	coding 差距僅 3%（OpenAI 自述），CP 值最高
平行子任務批次執行	mini	速度 2x、成本 ~70% 低
大量文件分類 / 標記	nano	低幻覺率適合結構化輸出
資料抽取（<50K tokens）	nano	高量重複時成本最低
排名、篩選	nano	官方明確設計用途
複雜多步推理	旗艦	FrontierMath：mini 9.6% vs GPT-5.4 26.3%
長文件分析（>100K tokens）	旗艦	mini 在 128K+ 準確率大幅降級（下節詳述）
創意寫作、細膩判斷	旗艦	mini/nano 不適合需要大量上下文理解的任務

如果你現有的 agent 系統全部用旗艦模型，不需要重寫任何東西。切換模型只需要改一個參數：把 model="gpt-5.4" 改成 model="gpt-5.4-mini"。API format、function calling 介面、system prompt 約定全部相同。

你的 agent 任務主要是「給一大段文字，提取結構化資訊」？如果 input 在 50K tokens 以內，nano 可以做得很好；50K-100K 用 mini 更安全；超過 100K 就讓旗艦模型處理。

token 數量估算參考：1 個中文字約 1.5-2 tokens。50K tokens 相當於約 2.5-3 萬個中文字，或一篇中型技術文章的全文。如果你不確定自己的 input 大小，可以用 OpenAI Tokenizer 工具（platform.openai.com/tokenizer）貼入文字直接計算。

長 Context 陷阱：128K+ token 任務請別給 mini/nano

這是 mini/nano 最容易被誤用的場景，也是最多人踩的坑。

GPT-5.4 mini 標示有 400K context window。但「能塞 400K」跟「能有效處理 400K」是兩回事。Simon Willison 的個人實測紀錄了一個關鍵數據：mini 在 MRCR v2（一個衡量長文本理解能力的 benchmark）的 128K-256K context 範圍，準確率從 GPT-5.4 的 79.3% 降到只剩 33.6%。

重要：這個降級數據來自 Simon Willison 的個人測試，不是 OpenAI 官方公布的 benchmark。但這與實務經驗一致：有效 context 通常是標示上限的 60-70%。

這代表什麼？

• 把完整 codebase（通常超過 100K tokens）丟給 mini 做分析 → 效果會很差
• 大型 RAG 管道把整份文件塞進 mini 做摘要 → 內容遺漏風險高
• 長對話歷史累積到 128K+ → 回答品質開始明顯下滑

解法不是「不用 mini」，而是正確分工：

1. Chunking 策略：把長文件分成 <30K tokens 的區塊，用 nano 分批處理，最後由旗艦模型整合
2. 智慧路由：agent 系統判斷 input 長度，自動把 >100K 的任務路由到旗艦模型
3. 階層式處理：nano 先做第一輪分類（「這份文件跟哪個主題相關？」），再把相關區塊交給 mini 做細部處理

真實成本計算：含 retry 成本的誠實數字

先看每個模型的官方定價（2026 年 4 月驗證）：

模型	Input / 1M tokens	Output / 1M tokens	相對 GPT-5.4
GPT-5.4	$2.50	$15.00	基準
GPT-5.4 mini	$0.75	$4.50	便宜 ~70%
GPT-5.4 nano	$0.20	$1.25	便宜 ~92%
Claude Sonnet 4.6	$3.00	$15.00	比 GPT-5.4 略貴

注意：nano 是 API-only，不在 ChatGPT 介面提供。mini 在 ChatGPT Free tier 也可使用。

來看三個真實場景：

場景一：大量圖片描述生成 Simon Willison 用 nano 處理 76,000 張圖片的描述生成，總成本 $52。同樣任務如果用 GPT-5.4，成本約 $650。

場景二：coding agent（每次 4K input + 2K output）

• GPT-5.4：每次約 $0.04（$2.50 × 4K/1M + $15.00 × 2K/1M）
• Mini：每次約 $0.012（$0.75 × 4K/1M + $4.50 × 2K/1M）
• 如果每天跑 500 次（中度使用的 agent），月差距約 $420

場景三：你每天只有 100 則對話的小創作者 假設每則對話平均 1K tokens input + 500 tokens output，nano 月成本約 $0.94（$0.20 × 30K/1M + $1.25 × 15K/1M），GPT-5.4 則約 $14.25（$2.50 × 30K/1M + $15.00 × 15K/1M）。實際月省約 $13，金額不大，但如果你有多個小工具同時在跑，加起來會有感。

誠實的 retry 成本修正：上面的計算是理想情況。實際使用中，nano 在邊緣任務（如稍微複雜的分類）會有 10-15% 的 retry rate。計入 retry 後，實際節省大約打 8 折——從理想的 70%+ 降到實際的 55-60%。不過即使打折，mini 的 retry 成本仍然遠低於旗艦模型第一次就成功的費用。

混搭策略：為什麼大多數開發者「加掛」而非替換

如果你現在的 agent 系統全部用 Claude Sonnet 4.6 或 GPT-5.4，要不要全部換成 mini？

短答案：不要。

根據 findskill.ai 的開發者調查，多數人的做法不是替換，而是「加掛」——在現有系統中，把新增的重複性子任務分配給 mini/nano，原本的工作流不動。理由有三個：

1. 不同任務各有強項：Claude Sonnet 在複雜推理和長文寫作上仍有優勢。「全部換成 mini」等於放棄這些強項
2. 遷移成本被低估：重新調試 prompt、重寫系統架構、測試品質差異——這些時間成本通常超過短期省下的 API 費
3. 避免 vendor lock-in：如果你的整個系統只綁一個模型，那個模型漲價或降級的時候你毫無退路。混搭讓系統更有韌性

如果你要同時管理 Claude SDK 和 OpenAI SDK 兩套 API，debug 複雜度確實會增加。我們的建議是先從一個新的 agent 子任務開始測試 mini/nano，確認品質符合需求後再擴展，不要一次遷移整個系統。

最適合直接用 mini/nano 起步的場景：

• 新的 classification agent（文件分類、標籤生成）
• 新的 data extraction pipeline（從非結構化文件抽取結構化資料）
• 品質驗證步驟（檢查輸出格式是否正確）

如果你想更完整地比較各家 AI API 的定價和適用場景，可以參考我們的 AI API 成本比較指南。

OpenAI Agents SDK 實作：改一行 model 參數就能切換

技術實作其實非常簡單。mini 和 nano 使用與 GPT-5.4 完全相同的 API format，切換只需要改一個參數。

以下是用 OpenAI Agents SDK 建 Planner-Executor-Reviewer 架構的示意程式碼：

from agents import Agent, Runner

# Planner（旗艦模型 — 負責整體規劃）
planner = Agent(
    name="Planner",
    model="gpt-5.4",
    instructions="分析使用者的任務需求，拆解成具體子任務，分配給對應的 Executor 或 Reviewer。"
)

# Executor（mini — 負責執行具體子任務）
executor = Agent(
    name="Executor",
    model="gpt-5.4-mini",  # 只改這一行
    instructions="根據 Planner 的指示，執行搜尋、文件處理或程式碼生成等具體任務。"
)

# Reviewer（nano — 負責分類和驗證）
reviewer = Agent(
    name="Reviewer",
    model="gpt-5.4-nano",  # 只改這一行
    instructions="對 Executor 的輸出進行格式驗證、分類標記和品質篩選。"
)

注意：上面的程式碼是根據 OpenAI Agents SDK 的 Agent 建構方式撰寫的示意用法。model 參數直接接受模型名稱字串。建議使用不帶日期的模型 ID（如 gpt-5.4-mini 而非 gpt-5.4-mini-2026-03-17），這樣可以自動跟隨 OpenAI 的版本更新，避免鎖定到特定 snapshot。

如果你不寫程式，mini 在 ChatGPT Free tier 也可以直接使用。而 nano 是 API-only，非工程師可以透過 n8n 的 HTTP Request node 或 Make/Zapier 的 OpenAI 整合來呼叫——這些 no-code 工具都支援指定 model 參數。在 n8n 中，搜尋「OpenAI」即可找到內建整合節點，把 model 欄位填入 gpt-5.4-nano 即可使用 nano。

使用限制與風險揭露

老實說，mini/nano 不是萬能的。以下是你在導入前必須知道的限制：

nano 的存取限制：nano 只能透過 API 使用，不在 ChatGPT Free/Plus/Pro 的介面中提供。這代表如果你的團隊中有非工程師需要使用 nano，他們必須透過 API wrapper 或 no-code 工具（如 n8n、Make）才能操作。

幻覺率的適用邊界：前面提到的 3.1% 幻覺率（Vectara HHEM-2.3）專指 grounded summarization 任務。在開放式問答、複雜推理或需要創意的場景中，nano 的輸出品質會明顯不如旗艦模型。不要因為看到「3.1%」就認為 nano 在所有任務上都很可靠。

複雜推理的明顯差距：在 FrontierMath 測試中，mini 的得分是 9.6%，GPT-5.4 是 26.3%。差距接近 3 倍。涉及多步推理、數學計算或需要全局理解的任務，交給旗艦模型做。

版本更新風險：OpenAI 平均 3-6 個月推出新版本（GPT-5.0→5.1→5.2→5.4），API 格式目前相容，但不保證無限期維護。建議定期關注 OpenAI 的 deprecation 通知，並且在你的 agent 系統中設計「模型可替換」的抽象層——這樣換模型的時候只需要改設定檔，不需要改邏輯。

retry 成本不可忽略：nano 在分類準確度不夠的邊緣場景需要 retry，高品質要求的 agent 系統應該設計 fallback 機制。最基本的做法是在 agent 邏輯中加入信心分數判斷：

result = reviewer_nano.run(task)
if result.confidence < 0.8:  # 低信心時升級
    result = executor_mini.run(task)
if result.confidence < 0.7:  # 再次不確定時用旗艦
    result = planner_flagship.run(task)

實際信心分數的取得方式取決於你的任務格式（可以請模型在回應中輸出 confidence 欄位），但核心邏輯就是這樣：讓低階模型先嘗試，失敗才升級，而不是所有任務都跑高階模型。

結論：mini/nano 的價值不在便宜，在於讓旗艦模型只做旗艦該做的事

如果你從這篇文章只帶走一個概念，那就是：mini/nano 的核心價值不是「便宜」，而是「分工」。它讓你的旗艦模型從「什麼都做的全職員工」變成「只處理高價值判斷的 senior manager」。

你現在就可以執行的五步驟：

1. 列出你 agent 系統中的所有子任務——把每個 API 呼叫分類成「規劃類」「執行類」「驗證類」
2. 對照上面的決策表，標記哪些任務可以安全換成 mini（執行類）或 nano（驗證類）
3. 選一個低風險任務先測試——建議從 data extraction 或分類標記開始，這是 nano 最擅長的場景
4. 用 OpenAI Playground 或你的測試環境比較品質——跑 50-100 筆真實資料，確認輸出品質可接受
5. 改一行 model 參數上線——就這樣，不需要改架構

如果你想進一步了解如何在 agent 系統中組合不同模型，我們也寫了 AI Agent 記憶體架構指南，裡面涵蓋了 multi-agent 系統中的狀態管理和記憶體設計。