讓 AI 代理學會深思熟慮：推理技巧

在這篇文章-讓 AI 代理聰明更要精明：資源感知最佳化談的是怎麼讓代理在預算內「動態決策」——該用哪個模型、該不該降級、剩多少預算-把重心放在「省」。這一篇要談它的鏡像：什麼時候該反過來大方花算力，讓代理「想久一點」。

兩者其實是同一枚硬幣的兩面。省，是不要把昂貴的推理砸在跑腿任務上；花，是面對真正複雜的問題時，願意給代理更多「思考時間」。這篇談的推理技巧（Reasoning Techniques），核心是在推理階段分配更多計算資源，把一個困難的單步問題拆成一系列可管理的小步，讓代理的內部思考變得明確、可審計、可修正。

為什麼「想久一點」會變成競爭力

標準的大型語言模型給答案的方式像直覺反射：一個 prompt 進來，一串 token 出去，中途不回頭。碰到「幫我訂明天下午會議室」這種輕量任務，這套快槍俠邏輯完全夠用。但遇到下面這類問題，一次出答案往往會出事：

這些場景的共同點是：答案對，還不夠；過程對，才可靠。推理技巧的整套工具，就是為了讓代理把「想清楚」這件事拆成看得見的中間步驟，而不是塞在一次性的黑箱答案裡。

思想鏈（CoT）：把單步難題拆成多步小題

思想鏈（Chain of Thought, CoT）是整套推理技巧的地基。它的想法很簡單：不要讓模型直接吐答案，而是引導它一步一步想。困難的單步問題，就會被分解成一串簡單的小步。這聽起來像個小動作，效果卻很驚人——在算術、常識推理、符號操作這類需要多步推理的任務上，準確率會顯著上升。對代理來說更重要的價值是透明度：因為每一步都看得到，决策可被審計、可被 debug，這正是自主代理能在複雜環境裡被信任的前提。

下面的 prompt 示範標準的 CoT 結構——先給角色、再給明確的多步驟流程，模型照著走就會吐出「內在獨白」，最後才給最終答案：

// CoT prompt：用結構化流程逼迫模型逐步推理
const cotPrompt = `
You are an Information Retrieval Agent.
Answer the user's question comprehensively by thinking step-by-step.

Process you must follow:
1. Analyze the Query：拆出核心主題、關鍵實體、需要的資訊類型
2. Formulate Search Queries：列出要對知識庫下的精確查詢
3. Simulate Information Retrieval：對每個查詢，先想像會找到什麼、哪裡有歧義
4. Synthesize Information：把模擬取得的片段整合成完整答案
5. Review and Refine：輸出前自問準確嗎、完整嗎、清楚嗎，不夠就改

User Query: "說明古典電腦與量子電腦的主要差異，並簡述量子運算的一個潛在應用。"
`

執行起來，模型的輸出會分成三層：

┌──────────────────────────────────────────────┐
│ 1. 規則層：prompt 定義的角色與五步流程        │
├──────────────────────────────────────────────┤
│ 2. 思考層：Thought 1 → Thought 2 → ... → 5  │  ← 這就是「思想鏈」
│    逐步分析、搜尋、模擬、綜合、自評           │
├──────────────────────────────────────────────┤
│ 3. 答案層：根據思考鏈整理出的最終回應         │
└──────────────────────────────────────────────┘

關鍵不在於這五個步驟多麼標準，而在於模型被要求把中間想法說出來。這個動作把困難的單步推理變成可追蹤的多步推理，也讓後續優化（自我修正、ReAct）有可以介入的接縫。思想鏈可參考這裡-自主 AI 代理的進化之路：從架構設計、意圖分流到平行加速對「規劃代理」的探討——規劃代理本質上就是一個會吐出思想鏈的角色。

思想樹（ToT）：在鏈的每個節點分岔、回溯

思想鏈是一條線，走到底不回頭。思想樹（Tree of Thoughts, ToT） 把它升級成樹：模型在每個中間步驟可以分岔出多條推理路徑，評估哪條比較有希望，必要時還能回溯。

這對需要策略規劃、需要比較替代方案的任務特別關鍵。思想鏈只負責「往下走」，思想樹負責「走錯了能換路」。模型透過維護一棵「可能性樹」，在定案之前先評估多條推理軌跡，再挑最穩健的那條收斂成答案。

                問題
                 │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
    想法 A     想法 B     想法 C      ← 分岔：探索多條路徑
       │         │         │
    評估 A     評估 B     評估 C      ← 評估：每條路徑打分數
       │      ❌分數低     │
       │     ↙ 回溯        │
       ▼                   ▼
    細化 A               細化 C       ← 收斂：挑有希望的路徑細化
       │                   │
       └─────────┬─────────┘
                 ▼
              最終答案                   ← 從最有支持的分支收斂

思想樹的代價就是算力。每多分一棵分支，token 消耗就成倍跳。換言之，思想樹是用「思考時間」換「思考品質」的最直接體現——而這正是後面縮放推理法的核心主張。

自我修正：把品管直接焊進生成流程

思想鏈讓模型的思考變得可見，自我修正（Self-Correction） 則讓模型對自己的思考品頭論足。代理在輸出前，先對自己生成的內容和中間思維做一輪內部評估，找出歧義、資訊缺口、不準確之處，再迭代修正。

這件事對工程背景的人來說一點都不陌生——它就是 TDD 的味道：先寫預期，再生產出，每步有回饋，出錯可見、可改。差別只在這裡的「測試」是模型自己對自己提問。

// 自我修正 prompt：把品管流程直接寫進去
const selfCorrectionPrompt = `
You are a Self-Correction Agent. Review the draft against original requirements:

1. Understand Original Requirements：原本要什麼？限制是什麼？
2. Analyze Current Content：仔細讀草稿
3. Identify Weaknesses：點出準確度、完整度、清晰度、語氣、冗餘的問題
4. Propose Specific Improvements：不只說哪裡有問題，要提出具體改法
5. Generate Revised Content：依改法重寫，輸出可交付版本

Original Requirement: "寫一篇短、有互動性的社群貼文（150 字內），
                      宣布新環保產品線 GreenTech Gadgets。"

Initial Draft: "我們有新產品。它們又綠又科技。現在就買 GreenTech Gadgets！"

# 模型的內部獨白會走這樣：
# Thought 1：原需求要短、要 engaging、150 字內、宣布 GreenTech Gadgets
# Thought 2：草稿 64 字，符合長度
# Thought 3：弱點——不夠 engaging、沒強調 eco-friendly、CTA 太弱
# Thought 4：具體改——用更有力的動詞、強調 eco 與 innovation、加強 CTA、加 hashtag
# Thought 5：重寫成最終版
`

重點不是這個草稿改得多漂亮，而是品管被整合進生成流程，不是事後人工檢查。對代理人來說，這意味著輸出階段就自帶一層品質保證，可以把爛答案攔下來、改好再回給使用者。這也跟資源感知最佳化的「評論家代理」一脈相承——評論家代理就是自我修正的獨立化版本，把「審查」從同一個模型的自我對話中拉出來，交由另一個代理來做，藉此降低自吹自擂的偏差。

程式輔助語言模型（PALM）：該算的就用程式算

思想鏈擅長語言推理，但碰到精確計算、符號邏輯、資料操作，語言模型就露出弱點了——它會算錯、會硬編數字、會自圓其說。程式輔助語言模型（Program-Aided Language Models, PALM） 的解法很直接：碰到這類任務，不要讓模型用文字算，讓它寫程式，把運算丟到確定性的執行環境去跑，再把結果轉回自然語言。

對工程師來說，這就是 tool calling 或 code interpreter 那一層。模型專注理解和生成，精確計算交給直譯器。下面用 Google ADK 示範一個「搜尋代理 + 程式碼代理」的 PALM 結構：

# Google ADK：把搜尋與程式碼執行各交給專門代理
from google.adk.tools import agent_tool
from google.adk.agents import Agent
from google.adk.tools import google_search
from google.adk.code_executors import BuiltInCodeExecutor

search_agent = Agent(
    model="gemini-2.0-flash",
    name="SearchAgent",
    instruction="You're a specialist in Google Search",
    tools=[google_search],
)

coding_agent = Agent(
    model="gemini-2.0-flash",
    name="CodeAgent",
    instruction="You're a specialist in Code Execution",
    code_executor=BuiltInCodeExecutor(),   # ← 確定性執行環境
)

root_agent = Agent(
    name="RootAgent",
    model="gemini-2.0-flash",
    description="Root Agent",
    tools=[
        agent_tool.AgentTool(agent=search_agent),
        agent_tool.AgentTool(agent=coding_agent),   # ← PALM：把計算外包給程式
    ],
)

PALM 對代理的意義在於把「可能出錯的計算」從模型的黑箱裡抽出來，交給可重現的執行環境。算錯的時候，我們修得動；算對的時候，結果可信。這跟前面談的資源感知有關：把跑腿任務交給便宜工具，把運算交給直譯器，都是把「不該用語言推理解的東西」從昂貴的模型裡挪出去。

RLVR：訓練出真的會推理的模型

前面幾招都是推理階段的小技巧，可驗證獎勵的強化學習（Reinforcement Learning with Verifiable Rewards, RLVR） 走更深——直接訓練出「推理模型」這個新品種。

標準思想鏈的缺點是它走的是單一、預先決定的思路，不會依問題難度調整思考量。推理模型反過來：答案出來之前，先投入可多可少的「思考時間」，產生可能長達數千 token 的思想鏈，在過程中自我修正、回溯、把更多力氣砸在更難的題目上。能做到這件事，靠的是 RLVR 這種訓練策略——拿數學題、程式題這種「答案可驗證」的問題當訓練素材，讓模型透過試錯學會產生有效的長式推理，不必人工逐步監督。

從這裡也能看出思想鏈、推理模型、縮放推理法三者的關係：

CoT           一條固定的思想鏈            （推理階段的低成本花招）
推理模型       可長可短、會回溯的思想鏈     （訓練階段就學會該想多久）
縮放推理法     更大方地給推理時間會更高分   （跨這兩者的共同原則）

對團隊的實用啟示是：不是所有問題都值得動用推理模型。推理模型貴、慢，但對真正複雜的問題，邊際算力花得很值。路由器代理要做的事，就是判斷「這題值不值得砸思考預算」，把推理模型保留給需要深思熟慮的情況。可參考這裡-讓 AI 代理聰明更要精明：資源感知最佳化對路由分流的整套討論。

ReAct：把推理接上行動

思想鏈、思想樹、自我修正都還停留在「想」。ReAct（Reasoning + Acting） 是關鍵的一躍——把推理跟行動交錯在一起，讓代理不只會想，還會動。ReAct 是代理真正的核心操作迴圈。

它的循環是「思想 → 行動 → 觀察」三拍：

1. 思想（Thought）：代理先用文字想，拆問題、定計畫、分析當下情況。這段內心獨白讓推理過程透明、可操縱。
2. 行動（Action）：根據想法，從預先定義的行動空間選一個動作——查資料庫、搜網頁、呼叫 API、給最終答案。
3. 觀察（Observation）：環境回饋結果——搜尋回了什麼、API 吐了什麼。

接著觀察餵回下一個思想，循環重來，直到代理決定收斂成「完成」行動。

        ┌─────────────────────────────────┐
        │  Thought：探討問題、定計畫       │
        └──────────────┬──────────────────┘
                       ▼
        ┌─────────────────────────────────┐
        │  Action：挑一個工具執行           │  ← 查 DB / 搜網 / 呼叫 API
        └──────────────┬──────────────────┘
                       ▼
        ┌─────────────────────────────────┐
        │  Observation：讀環境回饋         │  ← 搜尋結果 / API 回應
        └──────────────┬──────────────────┘
                       │
            ┌──────────┴──────────┐
            ▼                     ▼
       還沒解完                已收斂
       回到 Thought           給最終答案

ReAct 比線性 CoT 強的地方，在於它會回應即時回饋。代理不再閉門造車，而是「想一步、做一步、看一步、再想」。對於要跟外部工具、動態環境互動的代理，這個迴圈就是它能不能被稱為「真正的代理」的分界線。工具使用與函式呼叫的完整脈絡，可參考這裡-工具使用與函式呼叫：讓 AI 代理真正會做事。

// ReAct 的最小骨架：思想/行動/觀察循環
type Action =
  | { kind: 'search'; query: string }
  | { kind: 'lookup'; source: string }
  | { kind: 'finish'; answer: string }

type Step = { thought: string; action: Action; observation?: string }

async function reactLoop(question: string): Promise<string> {
  const steps: Step[] = []
  let solved = false

  while (!solved) {
    // 1. Thought：根據問題與目前觀察，決定下一步
    const { thought, action } = await llm.decideNext(question, steps)

    // 2. Action：執行工具
    let observation: string | undefined
    if (action.kind === 'search') observation = await webSearch(action.query)
    else if (action.kind === 'lookup') observation = await lookup(action.source)
    else { solved = true; return action.answer }

    // 3. Observation：把結果寫回，餵給下一輪思想
    steps.push({ thought, action, observation })
  }
  return ''
}

實務上有個調整旋鈕：每個動作要不要配一個思想？知識密集、要查證的任務（事實查核），思想跟行動交織得密一點；動作多、要導航的任務，思想可以用得省一點，讓代理自己決定什麼時候該停下來想。

辯論鏈與辯論圖：從單一代理到代理團隊

走到這裡，推理模型還是單打獨鬥。辯論鏈（Chain of Debate, CoD） 是微軟提出的框架——跳過「一個 AI 自己想」，改成讓多個不同模型圍成一圈開會：各自提初版、互相批評對方的推理、交換反駁。它像 AI 版的同儕審查，目的是用集體智慧拉高準確率、壓低偏見。

辯論圖（Graph of Debate, GoD） 再把結構升級：辯論不再是線性鏈，而是動態的非線性圖——論點是節點，節點之間用「支持」「反駁」等關係連起來。新的探究線可以中途長出分支、獨立發展、再合併；最後的結論不是「鏈的尾端」，而是從整張圖裡找最穩健、最被支持的論點簇來收斂。這比線性的 CoD 更貼近真實辯論有多線並進的樣貌。

對代理人來說，這反映了一個趨勢轉變：從「單一代理給答案」走向「代理團隊集體推理」。可參考這裡-多代理協作：讓 AI 代理分工不吵架對多代理協作的整套探討——CoD 與 GoD 就是「多代理怎麼一起想」的具體模式。

MASS：把代理團隊的設計也自動化

多代理系統設計之所以難，難在兩件事同時要調：每個代理的 prompt 要好，代理之間的拓撲（誰接誰、誰看誰的輸出）也要好。兩者構成的搜尋空間又大又雜。多代理系統搜尋（Multi-Agent System Search, MASS） 就是為了自動化這個設計過程而提出的框架。

MASS 走三階段最佳化：

階段 1：區塊級 prompt 最佳化
   先單獨把每個代理（block）的 prompt 調到局部最好
            │
            ▼
階段 2：工作流程拓撲最佳化
   從可自訂的設計空間挑出哪個拓撲「增量影響」最大
   （以影響力加權引導搜尋，不是盲目試）
            │
            ▼
階段 3：工作流程層級 prompt 最佳化
   拓撲定了，再回頭對「整個系統的 prompt」做全局微調
   針對編排與代理間的相互依賴做最佳化

從 MASS 的實驗，整理出三個值得記下來的設計原則：

1. 先把單一代理的 prompt 調好，再組系統——地基不好，蓋起來會被放大的缺陷拖垮。
2. 建立有影響力的拓撲，而不是漫無目的試所有結構——用影響力分數引導搜尋。
3. 最後對整條工作流程一起微調 prompt——把代理之間的相互依賴關係模進去。

MASS 結果顯示，自動調出來的 MAS 在一系列任務上顯著勝過手動設計與其他自動方法。其中一個發現的程式設計工作流程特別有意思：它不是簡單結構，而是「預測器代理做多輪反思 + 執行器代理跑測試案例驗證」的組合。換句話說，對寫程式這類任務，把「迭代自我修正」跟「外部測試驗證」綁在一起，效果優於大多數 MAS 設計——這恰好呼應了前面自我修正那段對工程背景的人的味道。

深度研究：把推理技巧打包成一個可信的產品

前面所有技術，到了深度研究（Deep Research） 就被整合成一個可以給一般使用者用的產品形態。Perplexity、Google Gemini 的深度研究、ChatGPT 進階功能，都是這一類。它跟一般搜尋最根本的差別是：一般搜尋給連結，綜合留給人；深度研究給的是「時間預算」，幾分鐘後回覆一份整理好的報告。

在這段時間裡，代理會自動跑下面這套流程——對人來說非常耗時，但對代理只是本份：

1. 初步探索
   根據初始 prompt 跑多個有針對性的搜尋
            │
            ▼
2. 推理與提煉
   讀第一波結果、綜合、批判性地找
   資訊缺口、矛盾、要再挖的點
            │
            ▼
3. 後續調查
   根據內部推理做更細緻的搜尋，補缺口
            │
            ▼
4. 最終綜合
   經過幾輪迭代，編譯成一份有引用、有結構的摘要

這正是把 CoT、自我修正、ReAct、PALM、檢索全部串起來的現成範例。它的價值不在哪個模型多強，而在於「給代理一個明確的時間預算，讓它自己跑完一輪研究」這個產品決策。

Google 把 DeepSearch 開源在 gemini-fullstack-langgraph-quickstart 儲存庫裡，整個代理圖的核心定義如下（簡化呈現，方便我們對照上面的 ReAct 迴圈和自我修正的接縫）：

# DeepSearch 代理圖：反思驅動的迭代檢索
from langgraph.graph import StateGraph, START

builder = StateGraph(OverallState, config_schema=Configuration)

# 核心節點：對應 ReAct 三拍 + 反思
builder.add_node("generate_query", generate_query)   # 思想：產生搜尋查詢
builder.add_node("web_research",   web_research)      # 行動：實際上網研究
builder.add_node("reflection",     reflection)        # 觀察 + 自我修正：找知識缺口
builder.add_node("finalize_answer",finalize_answer)  # 收斂：綜合出有引用的答案

# 入口
builder.add_edge(START, "generate_query")

# 條件分支：根據查詢平行展開 web 研究
builder.add_conditional_edges(
    "generate_query", continue_to_web_research, ["web_research"]
)

# 反思前一輪研究的成果
builder.add_edge("web_research", "reflection")

# 評估：還有缺口就回去再研究，夠了就收斂
builder.add_conditional_edges(
    "reflection", evaluate_research, ["web_research", "finalize_answer"]
)

builder.add_edge("finalize_answer", END)

graph = builder.compile(name="pro-search-agent")

看這段可以特別注意 reflection 這個節點——它就是自我修正的具體落地。每次做完一輪 web_research，代理回到 reflection 節點問自己「我還缺什麼」，缺口沒補滿就再回去 web_research，補滿了才進 finalize_answer。整個代理圖其實就是 ReAct 加上自我修正的結構化呈現。

要提醒一下：這份開源是結構完整的示範，不是 production-ready 的後端。要拿來上線，還要做快取、錯誤重試、預算控制那一層，那又是資源感知最佳化的領域了。

縮放推理法：模型不必愈大愈好，想得久才有時候才關鍵

所有上述技巧背後，有個共通的法則：縮放推理法（Inference Scaling Law）——在推理階段分配愈多計算資源，模型表現就會可預期地提高。它跟「訓練縮放法」不同：訓練縮放法談的是模型在「被造出來」的階段，餵更多資料、更多算力會更聰明；推理縮放法談的是模型在被「使用」的階段，給更多「思考預算」會答得更準。

這個法則對團隊最直接的啟示是——更大的模型，不一定比小模型加更多推理時間划算。拿同一份預算，砸在「用大一級的模型」是線性花錢；砸在「讓小模型多想幾步、自評幾輪、生成多候選再挑最優」往往更值。後者的具體花法包含：

這就使得縮放推理法變成一個平衡三個變數的設計框架——模型尺寸、反應延遲、營運成本。三者互相牽動：

        模型尺寸             反應延遲             營運成本
         （大）              （高）              （貴）
            ▲                   ▲                   ▲
            │                   │                   │
            └───────── 縮放推理法 ─────────┘
            不必同時拉到最右邊
            在「思考時間」上做取捨，
            在「模型尺寸」上做省略

這跟資源感知最佳化其實是同一個硬幣——一個省在「不必動用大模型」，一個花在「值得多想一想」。實務上的最佳設計，是把這兩套原則放在一起調：路由器代理判斷題目難度，難的丟給推理模型 + 給思考預算，簡單的丟給便宜模型 + 限制思考步數，整體成本才守得住。

代理到底怎麼想：回到核心迴圈

把這些技巧疊在一起，可以用一張圖把「代理怎麼想」整個收束回核心迴圈：

   給目標
      │
      ▼
   ┌───────────┐
   │  CoT 思想   │  ← 透明的內在獨白
   └─────┬─────┘
         ▼
   ┌───────────┐
   │  ToT 分岔 / 自我修正  │  ← 評估多策略、走錯能回溯
   └─────┬─────┘
         ▼
   ┌───────────┐
   │  ReAct 行動  │  ← 思想→行動→觀察，跟環境互動
   └─────┬─────┘
         ▼
   ┌───────────┐
   │ PALM / 工具  │  ← 精確運算外包給程式、API
   └─────┬─────┘
         ▼
   ┌───────────┐
   │  CoD / GoD  │  ← 多代理一起推理，壓低偏見
   └─────┬─────┘
         ▼
   ┌───────────┐
   │ 深度研究綜合  │  ← 長時間預算換可信結論
   └───────────┘

愈往上愈便宜、愈線性；愈往下愈貴、愈接近真正的自主。每一層都把「思考時間」拿來換「思考品質」，而每一層也都是一個可以調整的旋鈕——該給多久的思考時間，是可以被系統調度的資源，跟 GPU、跟 token 一樣。

總結

推理技巧的家族看似龐雜——CoT、ToT、自我修正、PALM、ReAct、CoD、GoD、MASS、深度研究——背後其實只有一個 schema：明確推理、迭代修正、把計算外包給確定性工具、願意給更多思考時間。這套 Schema 的價值，不在讓模型答得更漂亮，而在讓答案的「過程」變得透明、可審計、可信任。

我的觀點是：推理技巧與資源感知最佳化，是設計代理人時最該擺在同一個白板上一起畫的兩條線。光會花思考預算而不會路由，會把錢燒光；光會省模型而不肯給難題思考時間，會在最該精準的場景失準。真正會設計代理人的團隊，是同時掌握「該花則花、該省則省」的人——把難題砸在推理時間、把跑腿任務丟給便宜模型。

未來值得觀察的方向有兩個。一是推理模型跟資源感知路由的邊界會不會被同一個框架吃掉——當模型自己會動態決定要想多久，路由器就只負責「要不要派它上場」，整個系統會更簡潔。二是 MASS 這類自動化框架會不會把多代理設計本身變成一種可最佳化的服務——到時候，我們要做的可能不再是「設計一套多代理架構」，而是「刻畫目標與限制，讓框架幫我們長出來」。無論哪條路，能把「思考」當成一種可調度資源的團隊，會走得比只想著「裝更大的模型」的團隊更遠。

參考資料

• 第 17 章：推理技巧
• 讓 AI 代理聰明更要精明：資源感知最佳化
• 自主 AI 代理的進化之路：從架構設計、意圖分流到平行加速
• 工具使用與函式呼叫：讓 AI 代理真正會做事
• 多代理協作：讓 AI 代理分工不吵架
• Wei et al., “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models”, 2022
• Yao et al., “Tree of Thoughts: Deliberate Problem Solving with Large Language Models”, 2023
• Gao et al., “Program-Aided Language Models”, 2023
• Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models”, 2023
• “Scaling Laws for Inference Compute: An Empirical Analysis of Compute-Optimal Inference for LLM Problem Solving”, 2024
• “Multi-Agent Design: Optimize Agents with Better Prompts and Topologies”, arxiv 2502.02533