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

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

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

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

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

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

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

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

觸發 CoT 有兩種常見作法：一種是 few-shot，在 prompt 裡塞幾個「逐步推理的範例」給模型模仿；另一種是 zero-shot，什麼範例都不給，只加一句「Let’s think step by step」。前者效果較穩，但要花 prompt 空間；成本低、較容易套到新任務。下面的 prompt 示範標準的 CoT 結構——先給角色、再給明確的多步驟流程，屬於 zero-shot 的範本，模型照著走就會吐出「內在獨白」，最後才給最終答案：

// 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 的 TypeScript SDK（@google/adk）示範一個「搜尋代理 + 程式碼代理」的 PALM 結構：

// Google ADK（@google/adk）：把搜尋與程式碼執行各交給專門代理
import { LlmAgent, AgentTool, BuiltInCodeExecutor, GOOGLE_SEARCH } from '@google/adk'

// 搜尋代理：把 google search 當工具掛上來
const searchAgent = new LlmAgent({
  name: 'SearchAgent',
  model: 'gemini-2.5-flash',
  instruction: "You're a specialist in Google Search",
  tools: [GOOGLE_SEARCH],
})

// 程式碼代理：把運算外包給確定性執行環境
const codingAgent = new LlmAgent({
  name: 'CodeAgent',
  model: 'gemini-2.5-flash',
  instruction: "You're a specialist in Code Execution",
  codeExecutor: new BuiltInCodeExecutor(),   // ← 確定性執行環境（非 tools）
})

// 根代理：把兩個子代理包成工具，按需呼叫
export const rootAgent = new LlmAgent({
  name: 'RootAgent',
  model: 'gemini-2.5-flash',
  description: 'Root Agent',
  tools: [
    new AgentTool({ agent: searchAgent }),
    new AgentTool({ agent: codingAgent }),    // ← PALM：把計算外包給程式
  ],
})

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

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

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

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

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

對團隊的實用啟示是：不是所有問題都值得動用推理模型。推理模型貴、慢，但對真正複雜的問題，邊際算力花得很值。路由器代理要做的事，就是判斷「這題值不值得砸思考預算」，把推理模型保留給需要深思熟慮的情況。可參考這裡-讓 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

  // llm 為已初始化的模型客戶端，decideNext 依歷史步驟決定下一步
  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 代理圖：反思驅動的迭代檢索
import { StateGraph, START, END } from '@langchain/langgraph'

const builder = new StateGraph(OverallState, { context: Configuration })

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

// 入口
builder.addEdge(START, 'generate_query')

// 條件分支：根據查詢平行展開 web 研究
builder.addConditionalEdges(
  'generate_query', continueToWebResearch, ['web_research'],
)

// 反思前一輪研究的成果
builder.addEdge('web_research', 'reflection')

// 評估：還有缺口就回去再研究，夠了就收斂
builder.addConditionalEdges(
  'reflection', evaluateResearch, ['web_research', 'finalize_answer'],
)

builder.addEdge('finalize_answer', END)

const graph = builder.compile({ name: 'pro-search-agent' })

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

系統該怎麼設計：把推理階段當成可串流的事件

上面的代理圖是 LangGraph 內部的節點流轉，但它有個工程上的現實問題：generate_query → web_research → reflection 這幾個階段在後端跑，整個過程可能長達幾十秒甚至幾分鐘。如果後端等全部跑完再一次回傳，前端只能顯示一個空泛的「研究處理中」——使用者完全不知道代理在想什麼、查到什麼、還缺什麼。

解法跟 RAG、A2A、資源感知最佳化那幾篇一致：後端把每個節點的進出當作事件，透過 SSE 即時推給前端。可參考這裡-RAG：讓 AI 從閉卷考變開卷考。重點不是用了什麼協定，而是後端把「產生查詢」「上網研究」「反思找缺口」「收斂答案」拆成獨立事件，前端才能分開渲染、分層呈現。

// 後端：把 DeepSearch 的節點流轉包成 SSE 事件串流
import { createServer } from 'node:http'

createServer(async (req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    Connection: 'keep-alive',
  })

  const send = (event: string, data: unknown) => {
    res.write(`event: ${event}\ndata: ${JSON.stringify(data)}\n\n`)
  }

  // 1. 產生搜尋查詢：先讓使用者看到「代理在想什麼方向」
  const queries = await generateQuery(userPrompt)
  send('queries', { queries })

  // 2. 平行上網研究：逐筆推送找到的來源
  for (const q of queries) {
    send('searching', { query: q })
    const results = await webResearch(q)
    send('sources', { query: q, results })
  }

  // 3. 反思：把「還缺什麼」這段內部獨白推出去
  const gaps = await reflection()
  send('reflection', gaps)

  // 反思發現缺口沒補滿 → 回到步驟 2 再查一輪
  while (gaps.needsMore) {
    for (const q of gaps.followUpQueries) {
      send('searching', { query: q })
      const results = await webResearch(q)
      send('sources', { query: q, results })
    }
    gaps = await reflection()
    send('reflection', gaps)
  }

  // 4. 收斂：逐字推送最終有引用的答案
  for (const token of await finalizeAnswer()) {
    send('token', token)
  }

  send('done', {})
})

關鍵是後端把 LangGraph 節點的每一次流轉都變成事件，而不是只把最終答案送出去。reflection 節點在跑的時候，前端就能即時顯示「代理覺得還缺第三個視角的資料」——這種即時性，正是深度研究從「黑箱跑很久」變成「看得見的思考」的關鍵。

LangGraph 節點流轉              SSE 事件              前端能渲染什麼
┌─────────────────┐
│ generate_query  │──────────▶  queries  ──────────▶  搜尋方向清單
└────────┬────────┘
         ▼
┌─────────────────┐
│  web_research   │──────────▶ searching ─────────▶  正在查什麼
└────────┬────────┘            sources  ──────────▶  找到哪些來源
         ▼
┌─────────────────┐
│   reflection    │──────────▶ reflection ────────▶  代理覺得還缺什麼
└────────┬────────┘
         │ needsMore？
         ├─ 是 → 回 web_research（前端看到「再查一輪」）
         └─ 否 → finalize_answer
         ▼
┌─────────────────┐
│ finalize_answer │──────────▶ token ─────────────▶  逐字答案＋引用
└─────────────────┘

對 UI/UX 的影響：把「思考時間」變成看得見的進度

深度研究最傷 UX 的，不是它跑得久，而是它跑得久卻一聲不響。使用者按下送出，畫面只掛一個 spinner，幾分鐘過去，不知道代理是卡住了、查錯方向了，還是真的在認真想。推理技巧給了系統「想久一點」的能力，但 UI/UX 的工作是讓這段等待有節奏、可預期、看得見進展。

核心矛盾： 路由決策、反思、收斂這些動作在後端發生得很快又分散，如果後端不分階段推送，前端就只能顯示一個空泛的「處理中」。跟 RAG 一樣，這裡的解法是後端把每個推理階段當事件，前端再依事件渲染對應的 UI 狀態。

下面用一個深度研究的問答畫面為例，使用者看到的會長這樣：

┌─────────────────────────────────────────────────────────┐
│  🔍 深度研究助手                                         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  使用者：生成式 AI 對前端工程師的就業影響？               │
│                                                         │
│  代理正在研究（已 1 分 20 秒）                           │
│  ┌─ 第 1 輪搜尋 ────────────────────────────────────┐  │
│  │  • "generative AI impact frontend engineer jobs"   ✔  │  │
│  │  • "AI code generation frontend 2026 trends"       ✔  │  │
│  │  • "frontend developer skills demand AI era"        ✔  │  │
│  └────────────────────────────────────────────────────┘  │
│                                                         │
│  🤔 代理的反思：                                        │
│  目前找到的多是 2024–2025 的報告，缺產業實際招聘           │
│  數據與資深 vs 初階的差異。需要再查一輪。                 │
│                                                         │
│  ┌─ 第 2 輪搜尋 ────────────────────────────────────┐  │
│  │  • "frontend job postings senior junior split 2026" ✔ │  │
│  └────────────────────────────────────────────────────┘  │
│                                                         │
│  ✅ 綜合答案（逐字生成中）                                │
│  生成式 AI 對前端工程師的影響呈兩極化：日常切版、           │
│  樣式套版等工作被 AI 工具[1]加速邊緣化；但涉及互動          │
│  設計、效能調校、跨元件架構的資深需求反而上升[2][3]...      │
│                                                         │
│  ┌─────────────────────┐  ┌─────────────────────┐       │
│  │ 📑 展開 3 個來源      │  │ 🔁 重新研究方向     │       │
│  └─────────────────────┘  └─────────────────────┘       │
└─────────────────────────────────────────────────────────┘

有三個細節值得特別設計：

• 第一，反思階段要讓使用者看見——這是跟「普通 chat」最大的差異點。深度研究的信任來自「代理敢說自己還缺什麼」，把 reflection 的內部獨白適度曝露成一行「代理覺得還缺 XX 資料」，比靜默跑完更有說服力。
• 第二，輪次要可數——使用者能看到「第 1 輪搜尋」「第 2 輪搜尋」，每次迭代都讓等待有節奏，而不是模糊的「研究中」。
• 第三，每段答案都要能連回來源——深度研究的答案一定要帶行內引用，點下去能跳到對應的來源卡片，這是把「代理想得久」的價值外化為可查證的信任。

最後跟資源感知最佳化那一篇一樣的原則：判斷在後端，呈現在前端。要不要再查一輪、要不要收斂、答案品質夠不夠，這些都在 LangGraph 的節點裡用確定性規則決定，前端只負責把「已經決定要做的事」畫成看得懂的進度。可參考這裡-讓 AI 代理聰明更要精明：資源感知最佳化對「判斷在後端、呈現在前端」的整套拆解。前端絕對不能自己決定「該不該再研究方向」，那會跟後端的 reflection 節點打架，使用者會收到互相矛盾的訊號。

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

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

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

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

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

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

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

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

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

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

總結

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

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

未來值得觀察的方向有兩個。一是推理模型跟資源感知路由的邊界會不會被同一個框架吃掉——當模型自己會動態決定要想多久，路由器就只負責「要不要派它上場」，整個系統會更簡潔。二是 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