推理在哪裡現身：數學、程式、工具、計畫

數學：步驟最不留情的地方

數學是經典的試煉場，因為步驟清晰，一步出錯整個答案就毀了。數學解題（math problem solving）正是思維鏈最早展現戲劇性進步的地方：把工作過程寫出來，讓模型得以攜帶中間數量，而不必一躍算完所有東西。現代的推理模型靠著長篇推理並反覆檢查代數，能處理競賽等級的題目。

p(r_{1:n},\,a \mid q) \;=\; \left(\prod_{t=1}^{n} p\!\left(r_t \mid r_{<t},\,q\right)\right) p\!\left(a \mid r_{1:n},\,q\right)

思维链把答案分解为一连串条件推理步骤的乘积——任何一步出错都可能毁掉整条链。

但純文字推理在長串算術上仍會出包——模型可以對「該如何」相乘兩個大數字推理得完美無瑕，動手算時卻錯了一位。這個侷限，正是通往下面「工具」一節的橋。

程式碼：可以執行的推理

程式碼生成（code generation）是經濟上最重要的能力之一，而它其實是偽裝過的推理：寫出一支正確的程式，意味著追蹤狀態、遵守限制，並把片段組合成一個能運作的整體。程式碼有個難得的優點——它是可檢查的。你可以執行它、看測試是否通過，這把含糊的「這對嗎？」變成了一個明確的訊號。

User: What is 4173 * 2891?

Assistant (reasoning): Long multiplication by hand is error-prone.
I'll compute it instead of guessing.

  >>> 4173 * 2891
  12064143

Answer: 12,064,143

推理意識到自己不擅長算術，於是把計算交給工具，而不是去猜數字。

伸手去拿工具

近期能力上最深刻的轉變，是推理不必只發生在模型「腦中」。工具增強推理（tool-augmented reasoning）把思考與工具使用（tool use）交織起來：模型判斷自己需要一個事實、一次計算或一次網路查詢，便呼叫它、讀取結果，然後帶著那個結果繼續推理。程式碼直譯器（code interpreter）是這裡的主力——模型寫一小段程式、執行它，相信那個精確的輸出，而不是相信自己搖搖欲墜的心算。

這正是數學和程式兩節要放在一起看的原因：一個推理模型能做的最聰明的舉動，往往是認清自己腦袋的極限並把工作外包出去。知道何時該伸手拿工具，本身就是一種推理能力。

跨越許多步驟的規劃

把工具呼叫沿時間縫合起來，你就得到多步驟規劃（multi-step planning）：把一個目標拆成有順序的子任務，逐一完成，並在某步失敗時調整。把時間跨度拉長——許多次工具呼叫、許多分鐘、一個需要數十個彼此相依動作的目標——它就變成長程推理（long-horizon reasoning），最困難的場景，每步微小的錯誤率會複利累積成偏移。這正是大型語言模型代理人（LLM agent）內部的引擎。

把目標拆成一份有順序、具體的子任務清單。
執行一個子任務，在模型自己的腦袋不可靠時呼叫工具。
讀取結果，並對照計畫的預期加以檢查。
若現實與預期有出入，就修訂剩下的計畫，再繼續下一步。