Agent 很慢、LLM 不夠聰明——什麼時候該用多步驟處理？

🌏 Read this article in English

---

200 頁報告，AI 漏掉了關鍵數據

你用 ChatGPT 分析一份 200 頁的報告。

它很快給了你摘要：「重點是 A、B、C…」

你鬆了一口氣，準備把結論貼進簡報。

但是！

同事問了一句：「第 150 頁那個風險評估呢？」

你回去看報告，發現那段被完全忽略了。

⸻

Context window 塞得進去，不代表 LLM 真的「看完了」。

這時候你想：是不是該用 Agent？讓它分段處理？

但 Agent 跑了 20 分鐘，還在鬼打牆…

⸻

⚡ 3 秒重點

• 核心問題：單次呼叫不夠用，但 Agent 又太重——中間選項是什麼？
• 關鍵理解：這不是二選一，而是一個光譜：單次 → CoT → RAG → 多次呼叫 → Agent
• 選擇依據：資料量、驗證需求、控制程度、成本預算
• 常見錯誤：跳過中間選項，直接從單次跳到 Agent

---

不是二選一，是一個光譜

很多人把 LLM 使用方式想成「單次呼叫 vs Agent」的二選一。

這是錯的。

實際上是一個光譜，中間有很多選項：

flowchart LR
    A["單次呼叫
最基本"] --> B["CoT
讓 LLM 分步驟想"]
    B --> C["RAG
先檢索再生成"]
    C --> D["手動分解
你控制流程"]
    D --> E["Agent
AI 決定下一步"]
    E --> F["深度分解
極端場景"]

    style A fill:#e8f5e9
    style B fill:#e3f2fd
    style C fill:#fff3e0
    style D fill:#fce4ec
    style E fill:#f3e5f5
    style F fill:#ffebee

簡單 → 複雜 ｜ 便宜 → 昂貴 ｜ 快速 → 緩慢

每種方法解決不同問題：

方法	解決什麼問題	典型場景
單次呼叫	簡單任務	翻譯、摘要、QA
CoT Prompting	推理品質不夠	數學、邏輯、複雜分析
RAG	資料太長或需要外部知識	長文件、知識庫查詢
多次呼叫（手動）	需要中間驗證	分階段處理、流程固定
Agent	不知道需要幾步、需要動態決策	探索性任務、工具串接
深度分解（RLM 等）	極端長文、深度遞迴	百萬行 log、超大 codebase

Key Insight: 80% 的任務用前三種方法就能解決。直接跳到 Agent 通常是過度工程。

---

方法 1：單次呼叫（Baseline）

最簡單的方式：一個 prompt，一個回應。

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "把這段翻成英文：..."}]
)

適用條件：

• 問題明確，不需要探索
• 資料量在 context window 內（且不太長）
• 錯了可以接受，或容易人工檢查
• 需要快速回應

具體範例：

• ✅ 翻譯一封 email
• ✅ 摘要一篇 3000 字文章
• ✅ 回答明確技術問題（「Python 怎麼讀 JSON？」）
• ✅ 生成短程式碼片段（50 行以內）

成本估算：1 次 API 呼叫，約 1K-10K tokens

---

方法 2：Chain-of-Thought（讓 LLM 分步驟想）

當單次呼叫的推理品質不夠時，最輕量的升級。

核心概念：不是呼叫多次 API，而是讓 LLM 在一次回應中分步驟思考。

Before（單次呼叫）

Prompt: 「這個 function 有什麼問題？」

Response: 「看起來沒問題。」  ← 可能漏掉細節

After（CoT Prompting）

Prompt: 「這個 function 有什麼問題？請一步一步分析：
1. 先看輸入驗證
2. 再看邊界條件
3. 最後看錯誤處理」

Response:
「1. 輸入驗證：沒有檢查 null...
 2. 邊界條件：當 array 為空時會 crash...
 3. 錯誤處理：缺少 try-catch...」  ← 更完整

適用場景：

• 複雜推理（數學、邏輯）
• 需要更仔細的分析
• 單次呼叫常常漏掉細節

成本估算：還是 1 次 API 呼叫，但 output tokens 更多（約 1.5-2x）

Key Insight: CoT 是「免費的升級」——不需要改架構，只需要改 prompt。如果單次呼叫效果不好，先試 CoT 再考慮其他方法。

---

方法 3：RAG（先檢索再生成）

當資料太長，或需要外部知識時。

核心概念：不是把所有資料塞進 context，而是先找相關片段，再讓 LLM 處理。

flowchart TD
    Q["❓ 你的問題
「報告中的風險評估結論是什麼？」"]
    Q --> S["🔍 Step 1: 向量搜尋
從 200 頁中檢索相關段落"]
    S --> R["📄 Step 2: 篩選結果
只取相關的 5 頁"]
    R --> L["🤖 Step 3: LLM 生成
基於這 5 頁回答問題"]

    style Q fill:#e3f2fd
    style S fill:#fff3e0
    style R fill:#e8f5e9
    style L fill:#f3e5f5

為什麼有效：

• 避免「Lost in the Middle」問題（LLM 處理長文時，中間內容容易被忽略）
• 降低成本（只處理相關片段）
• 可以處理超過 context window 的資料

適用場景：

• 長文件分析（100+ 頁）
• 知識庫 QA
• 需要引用來源的場景

成本估算：向量搜尋 + 1 次 API 呼叫，總成本通常比塞滿 context 便宜

常見工具：LangChain、LlamaIndex、Pinecone、Chroma

---

方法 4：多次呼叫（手動分解）

當你需要中間驗證，或流程是固定的。

核心概念：你自己決定流程，每一步呼叫 LLM 處理。

範例：分析 10 個檔案的程式碼架構

summaries = []
for file in files:
    summary = llm.analyze(f"分析這個檔案的主要功能：{file}")
    summaries.append(summary)

# Step 2: 整合所有摘要
architecture = llm.synthesize(f"基於以下摘要，描述整體架構：{summaries}")

# Step 3: 產出最終報告
report = llm.generate(f"基於架構分析，產出技術報告：{architecture}")

vs Agent 的差異：

	手動分解	Agent
誰決定下一步？	你（工程師）	AI
流程固定嗎？	是	動態
可預測性	高	低
適合場景	流程已知	流程未知

適用場景：

• 多步驟流程，但每步做什麼是確定的
• 需要在中間步驟加入驗證或人工檢查
• 想要最大控制權

成本估算：N 次 API 呼叫（N = 步驟數）

Key Insight: 很多人直接跳到 Agent，但其實「手動分解」更可控、更便宜、更容易 debug。先問自己：我能不能把流程寫死？

---

方法 5：Agent（AI 決定下一步）

當你不知道需要幾步，或需要動態決策時。

核心概念：讓 AI 決定下一步要做什麼，直到任務完成。

flowchart TD
    T["🎯 任務
找出這個 bug 的 root cause"]
    T --> A1["🤔 Agent 思考
「我需要先看 error log」"]
    A1 -->|"呼叫 read_file"| A2["🤔 Agent 思考
「error 指向 db.py，我去看看」"]
    A2 -->|"呼叫 read_file"| A3["🤔 Agent 思考
「發現是連線沒關，確認一下...」"]
    A3 -->|"呼叫 search"| R["✅ 結論
Root cause: connection pool 沒設 timeout"]

    style T fill:#e3f2fd
    style A1 fill:#fff3e0
    style A2 fill:#fff3e0
    style A3 fill:#fff3e0
    style R fill:#e8f5e9

適用場景：

• 探索性任務（不知道答案在哪）
• 需要串接多個工具
• 步驟數不固定

風險：

• 可能鬼打牆（同一個錯誤重試多次）
• 可能過度分解（簡單問題拆成 10 步）
• 成本不可預測

常見框架：LangChain Agent、CrewAI、AutoGen、Claude Code

成本估算：不可預測，可能 5 次呼叫，也可能 50 次

---

方法 6：深度分解（RLM 等）

當處理極端長文或需要真正的遞迴時。

這是最新、最重量級的方法，適合極端場景。

RLM（Recursive Language Models） 是 MIT 團隊提出的框架，讓 LLM 可以：

• 把長文存成變數，不塞進 prompt
• 動態分割、遞迴搜尋
• 在百萬 token 規模下保持效果

適用場景：

• 100 萬行 log 中找特定錯誤
• 超大 codebase 分析
• 傳統方法都失敗的極端長文

現階段建議：除非你的任務真的是極端場景，否則先用前 5 種方法。

---

判斷框架：5 個問題選方法

不確定該用哪種？依序問自己這些問題：

flowchart TD
    Start["🤔 我的任務"] --> Q1{"1️⃣ 單次呼叫
效果夠嗎？"}

    Q1 -->|"夠"| A1["✅ 單次呼叫"]
    Q1 -->|"不夠，推理太淺"| A2["✅ 試 CoT"]
    Q1 -->|"不夠，資料太長"| Q2{"2️⃣ 需要檢索
還是全部處理？"}

    Q2 -->|"需要檢索"| A3["✅ 用 RAG"]
    Q2 -->|"全部都要看"| Q3{"3️⃣ 流程
是固定的嗎？"}

    Q3 -->|"是，我知道每步做什麼"| A4["✅ 手動分解"]
    Q3 -->|"不是，需要動態決策"| Q4{"4️⃣ 資料量
有多大？"}

    Q4 -->|"< 100K tokens"| A5["✅ Agent"]
    Q4 -->|"> 100K tokens"| A6["✅ 深度分解 RLM"]

    style A1 fill:#e8f5e9
    style A2 fill:#e8f5e9
    style A3 fill:#e8f5e9
    style A4 fill:#e8f5e9
    style A5 fill:#e8f5e9
    style A6 fill:#e8f5e9

預算考量：如果時間或預算有限，從簡單方法開始，逐步升級。

快速對照表

你的情況	建議方法
簡單任務，快速回應	單次呼叫
推理品質不夠	CoT Prompting
文件太長	RAG
需要分階段驗證	手動分解
不知道要幾步	Agent
極端長文（百萬 token）	RLM

---

成本比較

同樣一個「分析 10 個檔案」的任務：

方法	API 呼叫次數	Token 用量	大約成本（GPT-4o）
單次呼叫（全塞）	1	50K input + 2K output	~$0.30
CoT	1	50K input + 5K output	~$0.32
RAG	1	10K input + 2K output	~$0.07
手動分解（10 步）	10	5K × 10 = 50K total	~$0.30
Agent（假設 15 步）	15	變動，約 80K total	~$0.50+

重點：RAG 通常最便宜，因為只處理相關片段。Agent 最貴且不可預測。

---

常見誤區

誤區 1：「直接用 Agent 最方便」

不對。Agent 的問題：

• 成本不可預測
• 容易鬼打牆
• 難以 debug

建議：先問「我能不能把流程寫死？」如果可以，手動分解更好。

誤區 2：「Context window 越大越好」

不完全對。研究顯示長 context 有問題：

• 中間內容容易被忽略
• 回應品質可能下降
• 成本線性增加

128K context ≠ 128K 都有效處理

誤區 3：「RAG 只適合知識庫」

不對。RAG 的核心是「先檢索再生成」，適用於：

• 長文件分析
• 歷史對話參考
• 任何「不需要全部看，只需要相關部分」的場景

誤區 4：「CoT 需要特別的模型」

不對。任何 LLM 都支援 CoT，只需要在 prompt 加上「請一步一步分析」。

---

下一步行動

如果你目前只用單次呼叫

1. 先試 CoT：在 prompt 加上「請分步驟分析」
2. 觀察效果：推理品質有改善嗎？
3. 再考慮 RAG：如果資料太長

如果你在考慮 Agent

1. 先問：流程真的不能寫死嗎？
2. 先試手動分解：自己控制每一步
3. 設限：如果用 Agent，設定最大步數和 timeout

如果你處理極長文件

1. 先試 RAG：大多數情況夠用
2. 評估需求：真的需要「全部看過」嗎？
3. 再考慮 RLM：只有極端場景才需要

---

延伸閱讀

想深入了解 AI 工程實踐？這些文章可能有幫助：

• 不是每間公司都該做 RAG——這是判斷標準

  深入探討 RAG 的適用場景與評估框架

• 用 AI 接手 Legacy Code——4000 行 function 怎麼辦

  Agent 實戰場景：如何用 AI 漸進式重構大型 codebase

• 十分鐘價值：AI 時代，什麼才算資深？

  AI 改變了「資深」的定義——判斷力比產出量更重要

• 團隊開始用 AI 寫程式，為什麼效率沒提升？

  AI 工程成熟度模型：從個人效率到團隊協作

• Copilot 不是萬靈丹

  務實看待 AI 輔助編程的效果與限制

---

Sources

Chain-of-Thought Prompting

• Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (2022) | Archive
  

  Google 研究發現，讓 LLM 分步驟思考可以顯著提升推理任務的表現，尤其是數學和邏輯問題。

Lost in the Middle 現象

• Lost in the Middle: How Language Models Use Long Contexts (2023) | Archive
  

  研究發現 LLM 處理長文時，中間內容的召回率明顯低於開頭和結尾。後續模型已有改善，但問題仍存在。

Recursive Language Models

• RLM: Recursive Language Models (2025) | Archive
  

  MIT 團隊（Zhang, Kraska, Khattab）提出的框架，讓 LLM 可以遞迴處理超長 context，在百萬 token 規模下保持效果。

Agent 設計模式

• Building Effective Agents – Anthropic (2024) | Archive
  

  Anthropic 的 Agent 設計指南，強調「workflows」（固定流程）通常比「agents」（動態決策）更可靠。