別只走一條路——Tree of Thoughts 讓 AI Agent 同時探索多條推理路徑的完整指南

你有沒有想過一件反直覺的事：讓 AI 同時走三條路，最後居然比專心走一條路更快到終點？

Chain-of-Thought（CoT）已經讓 LLM 學會「一步一步想」。但 CoT 有個致命弱點——它只走一條路。一旦第三步走偏，後面全部跟著歪，而且 AI 完全不知道自己歪了。NeurIPS 2023 發表的 Tree of Thoughts 框架直接挑戰這個限制：讓 AI 在做決定之前先想出多條路，評估每條路的可行性，走不通就回頭換路。結果在 Game of 24 這個經典數學推理任務上，GPT-4 的成功率從 4% 飆升到 74%——差距是量級的翻轉，遠超出微調的範圍。

這篇文章會帶你完整拆解 ToT 的運作機制、它跟 CoT / ReAct 的本質差異、後續延伸的 Graph of Thoughts 和 Branch-Solve-Merge 框架，以及你今天就能跑的 Python 實作程式碼。如果你正在開發 AI Agent，這套多路徑推理思維會徹底改變你設計推理鏈的方式。

為什麼一條推理鏈不夠用

先回到 CoT 的底層邏輯。2022 年 Wei et al. 提出 Chain-of-Thought，讓模型在回答之前先輸出中間推理步驟。這在算術、常識推理上效果顯著——但它本質上是一條貪婪搜尋路徑。模型從 token 到 token 往前推，每一步選當下看起來最好的選項，不回頭、不比較、不反悔。

這在簡單任務上夠用。但碰上需要「試錯」的問題，CoT 就崩了。舉個例子：Game of 24 要用加減乘除把四個數字湊成 24。假設你拿到 4、5、6、10，CoT 可能第一步就決定「4 × 5 = 20」，接下來不管怎麼算都到不了 24，但它無法回到第一步改成「4 × 6 = 24」。問題並不在模型不夠聰明，真正的限制是推理架構本身不允許回溯。

Yao et al.（2023）在 ToT 論文裡精準點出了問題：語言模型的自迴歸生成機制，天生就缺少三種能力——局部探索（在每一步考慮多個選項）、全局評估（判斷目前路徑的整體可行性）、回溯（走不通就退回重選）。這三個能力，恰好是人類解決複雜問題時最核心的思維模式。

用一個比喻來解釋：CoT 像是開車走高速公路，從 A 到 B 只走一條路線。ToT 像是開啟 Google Maps 顯示三條路線，即時比較哪條最快、哪條有車禍、哪條正在施工——然後選最好的那條。差別不在速度，在於你有沒有「選擇權」。

Tree of Thoughts 的核心架構

ToT 的設計靈感來自認知科學中的「dual-process theory」——人的思維有快速直覺（System 1）和慢速審慎推理（System 2）兩種模式。CoT 模擬的是 System 1，而 ToT 模擬的是 System 2：在每一步暫停、展開多個可能性、評估、選擇最佳路徑、必要時回溯。

ToT 有三個核心組件，缺一不可：

Thought Decomposition — 把問題拆成可搜尋的步驟

第一步是決定「思考的粒度」。在 Game of 24 裡，一個 thought 是「一次算術運算」（例如 4 × 6 = 24）。在創意寫作裡，一個 thought 是「一個段落計畫」。粒度太細會導致搜尋空間爆炸，太粗則失去多路徑比較的意義。這是 ToT 設計中最需要人工判斷的部分。

Thought Generator — 在每一步展開多條路

ToT 提供兩種生成策略：Sample（獨立取樣）和Propose（序列提議）。Sample 是用 temperature > 0 從同一個 prompt 取樣多次，適合思考空間豐富的場景（如創意寫作）。Propose 是用一個 prompt 讓模型一次列出多個候選 thought，適合候選項可以被結構化列舉的場景（如 Game of 24 的運算組合）。

State Evaluator — 為每條路打分

這是 ToT 最精巧的部分。模型不只是生成候選路徑，還要自己評估每條路的可行性。評估方式有兩種：Value（獨立打分）讓模型給每條路一個「sure / maybe / impossible」的判斷；Vote（比較投票）讓模型從多條路中選出最好的。Value 適合可以獨立判斷的任務，Vote 適合需要相對比較的任務。

搜尋策略上，ToT 支援 BFS（廣度優先搜尋）和 DFS（深度優先搜尋）。BFS 適合搜尋空間較小、需要比較多條完整路徑的場景（如 Game of 24）。DFS 適合搜尋空間大、只需要找到第一個可行解的場景（如 Mini Crosswords）。在 DFS 模式下，ToT 還支援在評估結果為 impossible 時自動回溯，這是 CoT 做不到的。

實際運作的過程可以這樣想像：BFS 是「每一層都展開所有路，比較完再往下走」，像是圍棋的棋局分析，每一步考慮多個落子點。DFS 是「先深入探索一條路走到底，走不通再退回來換路」，像是迷宮探索——碰到死路就回頭。

值得一提的是，ToT 框架的程式碼和 prompt 模板都已開源。Princeton NLP 團隊的官方 GitHub 提供了完整的 Python 實作，你可以透過 pip install tree-of-thoughts-llm 直接安裝。

ToT、CoT、ReAct 三大推理框架的本質差異

這三個框架經常被混為一談，但它們解決的是根本不同的問題。CoT 解決的是「模型不會展示推理過程」，ReAct 解決的是「模型不會使用外部工具」，而 ToT 解決的是「模型不會探索和回溯」。

一個關鍵觀察：ToT 的 API 呼叫量是 CoT 的 10 到 100 倍。這意味著 ToT 適合「答案價值高、容錯空間低」的場景，而不適合日常對話或簡單問答。如果你正在設計 反思型 Agent，ToT 提供的多路徑評估機制可以作為反思環節的核心引擎。

Python 實作：從零搭建 Tree of Thoughts

看完架構，直接上程式碼。以下是一個精簡但完整的 ToT 實作，用 BFS 搜尋策略解 Game of 24。你可以在 Python 3.10+ 環境直接執行。

import openai
from typing import List, Tuple

client = openai.OpenAI()

def generate_thoughts(state: str, k: int = 5) -> List[str]:
    """Thought Generator: 從當前狀態展開 k 條候選路徑"""
    prompt = f"""Given the current state: {state}
    Generate {k} different possible next steps for solving Game of 24.
    Each step should be one arithmetic operation using available numbers.
    List each step on a new line, format: 'a op b = c (remaining: x, y, ...)'"""

    resp = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.7
    )
    return [line.strip() for line in resp.choices[0].message.content.split("\n") if line.strip()]

def evaluate_state(state: str) -> str:
    """State Evaluator: 判斷當前路徑可行性 → sure / maybe / impossible"""
    prompt = f"""Evaluate if this state can reach 24: {state}
    Answer ONLY with: sure, maybe, or impossible"""

    resp = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.1
    )
    return resp.choices[0].message.content.strip().lower()

def tot_bfs(numbers: List[int], breadth: int = 3, max_depth: int = 4) -> str:
    """Tree of Thoughts BFS 主迴圈"""
    initial_state = f"Numbers: {numbers}, Target: 24"
    current_states = [initial_state]

    for depth in range(max_depth):
        candidates = []
        for state in current_states:
            thoughts = generate_thoughts(state, k=breadth)
            for thought in thoughts:
                evaluation = evaluate_state(thought)
                if evaluation == "impossible":
                    continue  # 剪枝：不再探索這條路
                candidates.append((thought, evaluation))

        # 排序：sure > maybe，取前 breadth 條繼續
        candidates.sort(key=lambda x: 0 if x[1] == "sure" else 1)
        current_states = [c[0] for c in candidates[:breadth]]

        # 檢查是否已找到解答
        for state, eval_result in candidates:
            if eval_result == "sure" and "24" in state:
                return state

    return "No solution found"

# 使用範例
result = tot_bfs([4, 5, 6, 10])
print(f"Solution: {result}")

這段程式碼展示了 ToT 的三個核心機制：generate_thoughts 展開多條路、evaluate_state 為每條路打分、主迴圈裡的剪枝和排序。實際部署時，你還需要加入快取機制（避免重複評估相同狀態）和 token 使用量監控。

如果你的場景更適合 DFS（找到第一個可行解就停），以下是帶回溯的 DFS 版本：

def tot_dfs(state: str, depth: int = 0, max_depth: int = 4,
            breadth: int = 3, visited: set = None) -> str:
    """Tree of Thoughts DFS + Backtracking"""
    if visited is None:
        visited = set()

    if depth >= max_depth:
        return None

    # 評估當前狀態
    evaluation = evaluate_state(state)
    if evaluation == "impossible":
        return None  # 回溯：這條路走不通
    if evaluation == "sure" and depth > 0:
        return state  # 找到解答

    # 展開候選路徑
    thoughts = generate_thoughts(state, k=breadth)

    for thought in thoughts:
        if thought in visited:
            continue
        visited.add(thought)

        # 遞迴深入探索
        result = tot_dfs(thought, depth + 1, max_depth, breadth, visited)
        if result is not None:
            return result  # 找到解，逐層返回
        # 沒找到 → 自動回溯，嘗試下一條路

    return None  # 所有路都走不通

# DFS 版本適合搜尋空間大的任務
result = tot_dfs("Numbers: [2, 3, 7, 11], Target: 24")
print(f"DFS Solution: {result}")

BFS vs DFS 的選擇取決於你的任務特性。BFS 保證找到「最短路徑」但記憶體消耗大，DFS 記憶體效率高但可能陷入很深的死路。ToT 原論文在 Game of 24 用 BFS、在 Mini Crosswords 用 DFS，兩者各有所長。

在實際部署中，我們發現一個混合策略效果不錯：先用 BFS 展開第一層，從中選出前 2-3 個最有潛力的路徑，然後對每條路徑用 DFS 深入探索。這兼顧了 BFS 的全面性和 DFS 的效率。

另一個實務技巧是用非同步呼叫平行化 thought generation 和 state evaluation。因為不同路徑的評估是獨立的，你可以用 Python 的 asyncio 同時送出多個 API 請求，把延遲從串行的 N 次呼叫壓縮到接近 1 次。

從樹到圖：Graph of Thoughts 與 Branch-Solve-Merge

ToT 打開了多路徑推理的大門，但「樹」這個結構本身也有限制——它不允許不同分支之間交換資訊。2023-2024 年間出現的兩個後續框架，各自用不同方式突破這個限制。

Graph of Thoughts — 讓推理路徑互相合併

Besta et al.（AAAI 2024）提出的 Graph of Thoughts（GoT）把 ToT 的樹結構推廣成任意有向圖。在 GoT 裡，不同路徑的 thought 可以被合併（aggregation）、精煉（refinement）、或互相回饋。這模擬了人類思維中「把兩個不同角度的想法結合出新觀點」的過程。

GoT 的實測結果亮眼：在排序任務上，品質比 ToT 高 62%，同時成本降低 31%。品質提升來自不同路徑的交叉驗證，成本降低來自圖結構允許共享中間計算結果——兩條路徑如果走到同一個中間狀態，只需要計算一次。

Branch-Solve-Merge — 先拆再合的平行策略

Saha et al.（2023）提出的 Branch-Solve-Merge（BSM）走的是另一條路。它不像 ToT/GoT 那樣在推理過程中展開分支，而是在任務層級做分解：先把一個複雜任務拆成多個獨立子任務（Branch），每個子任務獨立求解（Solve），最後把結果合併（Merge）。

BSM 的強項在複雜生成任務。實測結果顯示：在受約束的故事生成中，約束滿足率提升 12%，連貫性也同步提升。更驚人的是，用 BSM 框架的 LLaMA2-chat 在多數領域的表現能匹配甚至超越 GPT-4。

LATS（Language Agent Tree Search）是另一個值得關注的框架。Zhou et al.（2023）把蒙地卡羅樹搜尋引入 LLM 推理，在 HumanEval 程式生成任務上達到 92.7% pass@1。它的核心創新是用 LLM 本身作為 value function，加上反思機制來持續改善搜尋策略——概念上像是 AlphaGo 的 LLM 版本。

2024 年發表的一篇研究更進一步發現，Chain-of-Thought 的推理路徑其實已經「藏在」模型的 token 分佈裡——只是被貪婪解碼遮蓋了。換句話說，模型本來就會想多條路，只是輸出機制只讓它說出一條。ToT 和 GoT 從外部框架解鎖了這些隱藏的推理路徑，而未來的原生推理模型則從模型架構內部解鎖。

哪些場景真的需要 Tree of Thoughts

ToT 不是萬能藥。它適合的場景有一個共同特徵：答案的搜尋空間大、錯誤成本高、且存在可以被評估的中間狀態。以下是目前已驗證有效的應用場景：

反過來，以下場景用 ToT 是殺雞用牛刀：日常對話、簡單問答、翻譯、摘要。這些任務的搜尋空間小、CoT 甚至 zero-shot 就能解決，加入 ToT 只會增加延遲和成本。

一個判斷是否需要 ToT 的經驗法則：問自己「如果第一步走錯，後面能不能自己修正？」如果答案是「不能」，就該考慮 ToT。如果答案是「多數時候可以」，CoT 就夠了。

如果你在設計 多 Agent 辯論系統，ToT 的思路可以應用在單一 Agent 的內部推理中，而多 Agent 辯論則在 Agent 之間進行外部推理。兩者可以組合使用。

想深入了解如何讓 Agent 自動累積和複用解題經驗，可以參考技能庫架構的設計。ToT 搜尋出的成功路徑，可以被提煉成技能模板，下次遇到相似問題就直接套用，不需要重新搜尋。

效能基準與成本分析

光說 ToT 好用不夠，數字說話。以下整理了 ToT 及其衍生框架在主要基準測試上的表現：

這裡有兩個值得注意的趨勢。第一，ToT 在「需要探索」的任務上效果最顯著——Game of 24 的 70 個百分點提升是所有 prompt engineering 技術中最驚人的數字之一。第二，GoT 證明了圖結構可以在提升品質的同時降低成本，這對生產環境部署至關重要。

另一個隱含的趨勢是：隨著模型能力提升，ToT 的 base performance 也在提升。同樣的 ToT 框架，2023 年用 GPT-3.5 跑出的數字遠低於 GPT-4。2026 年最新的模型（GPT-4o、Claude 3.5 Sonnet、Gemini 2.0）作為 ToT 的 base model 時，上限還會繼續推高。框架和模型是乘數關係，不是加法關係。

部署 ToT 的最佳實踐與避坑指南

把 ToT 從論文搬到生產環境，你會碰到論文裡不會提的實務問題。以下是我們團隊的踩坑總結：

1. 先用 CoT 建立 baseline，再決定是否需要 ToT。 很多開發者一看到 ToT 的效果就急著導入，結果發現自己的任務 CoT 就能解決。ToT 的複雜度和成本是真實的代價，不要為了技術優越感犧牲效率。

2. Thought 粒度的設計是成敗關鍵。 太細（每個 token 都是一個 thought）會讓搜尋空間爆炸；太粗（一整段就是一個 thought）會失去回溯的精確度。經驗法則：一個 thought 對應一個「可以獨立被評估對錯」的推理步驟。

3. State Evaluator 的品質決定了 ToT 的上限。 如果模型無法準確判斷中間狀態的可行性，剪枝就會出錯——可能剪掉正確的路，保留錯誤的路。在部署前，一定要在你的任務上驗證 evaluator 的準確率。

4. 設定明確的搜尋預算（token 上限和時間上限）。 沒有預算控制的 ToT 可能會無限展開，特別是在 DFS 模式下。建議設定 max_depth、max_breadth、max_tokens 三重限制。

5. 快取重複狀態。 不同路徑可能走到相同的中間狀態。用 hash table 快取已評估過的狀態，可以大幅減少 API 呼叫量。GoT 的成本優勢有一部分就來自這個機制。

多路徑推理的未來走向

ToT / GoT / BSM / LATS 這些框架的共同方向是讓 LLM 的推理從「直覺反應」走向「審慎思考」。2025-2026 年，這個領域有幾個值得關注的演進方向：

• 原生推理模型的崛起：OpenAI 的 o1/o3 和 Google 的 Gemini 2.0 Flash Thinking 已經把多路徑推理內建到模型架構裡，不再需要外部框架。但理解 ToT 的原理仍然重要——因為原生推理模型的行為模式跟 ToT 高度吻合，懂原理才能有效使用。

• 搜尋與學習的融合：LATS 開創的「用搜尋結果訓練模型」的範式正在被放大。Meta 的 Self-Rewarding 和 DeepSeek 的強化學習框架都在用類似 ToT 的搜尋策略來生成訓練資料。

• 多 Agent 協作搜尋：把 ToT 的每個分支分配給不同的 Agent，各自獨立探索後再合併結果。這結合了 ToT 的搜尋能力和多 Agent 系統的平行化優勢。

• 領域特化的 Thought 模板：通用的 ToT 在特定領域（如法律推理、醫療診斷）的效果有限。未來會出現針對特定領域預設好 thought decomposition 和 evaluation criteria 的專用 ToT 框架。

想了解如何用 DSPy 自動優化 prompt，包括 ToT 的 evaluator prompt，可以參考我們的專文。自動化的 prompt 調參是讓 ToT 從「研究工具」變成「生產工具」的關鍵跨步。

開始你的第一個多路徑推理實驗

Tree of Thoughts 不只是一個 prompt 技巧，它代表了一種思維模式的轉變：從「讓 AI 快速給答案」到「讓 AI 先充分探索再給答案」。這個轉變的代價是更多的計算資源和等待時間，但回報是在複雜問題上質的飛躍。

如果你的業務場景涉及複雜決策——策略規劃、程式碼架構設計、多步驟問題求解——ToT 值得你投入時間研究。從這篇文章的 Python 程式碼開始，在你自己的任務上跑一遍 BFS 和 DFS，感受多路徑推理帶來的差異。

建議的學習路徑：先理解 CoT → 再學 ToT → 然後看 GoT 和 BSM → 最後接觸 LATS。每一層都建立在前一層的概念上，跳著學容易在實作時搞混不同框架的搜尋邏輯。

最後分享一個我們在生產環境的觀察：ToT 最大的價值往往體現在「讓你知道為什麼這個答案是好的」。因為搜尋過程完整記錄了每條路徑的評估結果，你可以向客戶或團隊解釋「我們考慮了 A、B、C 三條路，A 因為 X 原因不可行，B 因為 Y 原因次優，所以選了 C」。這種可解釋性在企業 AI 應用中價值極高。

如果你正在評估如何將 ToT 或其他多路徑推理框架整合到你的 AI Agent 架構中，歡迎預約我們的 AI 技術諮詢，我們可以根據你的具體場景提供架構建議和 POC 規劃。

延伸閱讀：Tree of Thoughts 是神經符號思維的雛形——想了解這套推理架構背後的技術基礎，推薦閱讀《神經符號 AI 如何補上深度學習的最大缺陷》。