如何讓模型能呼叫外部工具，並親手實作「模型選工具 → 執行 → 回輸 → 答覆」的完整迴圈 核心原則
Tool Calling 是 Agent 的底層——Agent 不過是「會自己決定何時呼叫哪個工具的迴圈」

模型本身只會產生文字，不會真的算數、查資料、打 API。Tool Calling 的機制是：

1. 把工具的 JSON Schema 連同問題一起送給模型
2. 模型回答「我要呼叫 calculator，參數 {expression:'...'}」
3. 而程式（不是模型）真的去執行該函式
4. 再把執行結果回輸給模型
5. 模型用結果產出最終自然語言答覆

- 閱讀剩餘部分 -

延續上一篇的話題，關於 λ 的修正計算，如何更準確的預估或是計算出 λ 呢？

理論上 λ 應由「外部基準」決定，以下是三條可行的校準路徑：

PATH 1：對照官方建照數據

最直接的方法——以政府公布的「年度核發建照數」作為 ground truth，反推 λ：

λ* = log(N_t/N_0 / G_real) / log(C_t/C_0)

其中 G_real 為官方建照累計增長率。台中建管處（CPA）有公開資料，可據此反算出城市特定的 λ 值。

PATH 2：跨城市穩定性檢驗

若同一個 λ 值應用於台北、高雄、台中均能與官方數據對齊，則可視其為 OSM 系統性偏差的穩健估計，與個別城市無關。

- 閱讀剩餘部分 -

本章節要實作滑動視窗與摘要壓縮兩種記憶，並用事實問答量化「省 token vs 記得住」的取捨

一、滑動視窗記憶

實作只保留最近 N 輪的 SlidingWindowMemory，並驗證在 Context Window 中「忘掉久遠的事」

- 閱讀剩餘部分 -

一、大模型沒有記憶

由於 LLM 本質上是無狀態的（Stateless）。每一次 API 呼叫都是獨立的、全新的計算過程，模型內部不會保留任何「記住上一句話」的狀態。因此，兩次呼叫彼此獨立，第二次完全不知道第一次發生過的事情。於是乎就有了以下的做法。

Prompt 層模擬記憶

把「歷史聊天記錄」+「當前新問題」打包拼接，作為一個完整的 Prompt 一次性傳給模型，讓它在 單次推理中 看到全部上下文。

我們會把對話歷史塞進 context 中，如下：

- 閱讀剩餘部分 -

「將原始模型輸出轉化為結構化、可靠、可預測的行為」。 這是 prompt engineering 的工程定義。其中三個層次：

1. 策略：zero-shot / few-shot / Chain-of-Thought — 用什麼方式引導模型推理
2. 約束：JSON mode、schema、格式規範 — 讓輸出可被程式接住
3. 曡代：用標註資料集量化準確率，像調程式一樣調 prompt

Context Engineering（上下文工程）：重點不是單句 prompt，而是 「在有限 context window 裡，放對的範例、對的格式說明、對的歷史」。

- 閱讀剩餘部分 -