LLM (Large Language Model)

LLM 和傳統的機器學習模型有什麼根本差別？為什麼「預測下一個 token」能產生看起來像「思考」的輸出？

傳統機器學習模型（分類器、迴歸模型）的設計是「輸入特定格式的數據，輸出特定的標籤或數值」——例如「輸入一張圖片，輸出是貓還是狗」。這類模型的能力被嚴格限定在訓練目標上，無法泛化到沒有訓練過的任務。

LLM 的設計本質是「給定前面所有的文字，預測下一個最可能出現的 token」。這個目標看起來非常簡單，但它帶來了一個意外的湧現效果：要在海量文本裡準確預測下一個 token，模型必須「學會」語言的語法、語意、世界知識、因果推理、邏輯一致性——不是因為有人明確教它這些，而是因為這些知識是準確預測所必需的。

結果是：當你問 LLM 一個問題，它在生成每個 token 時，實際上是在「尋找在它的訓練分布裡，跟著這個問題最可能出現的回答」。這個過程沒有真正的「理解」或「意識」，但從外部觀察，輸出高度接近一個真正在推理的系統。這就是為什麼 LLM 的輸出看起來像「思考」，但它其實是非常複雜的統計模式匹配。

對 AI Agent 的意義：理解這個本質讓你知道 LLM 為什麼會「幻覺」——它不是在說謊，而是在生成「統計上看起來像合理答案的文字」，即使那個答案在事實上是錯的。

LLM 的「幻覺」（Hallucination）是什麼？在加密 Agent 場景下，幻覺的後果比普通使用場景嚴重多少？

幻覺是指 LLM 生成了聽起來合理、有信心、但事實上不正確的內容。幻覺不是 bug，而是 LLM 的統計本質的必然副產品——模型在生成每個 token 時，優化的是「統計可信度」而不是「事實準確性」。當模型沒有可靠數據支撐某個答案，它仍然會生成一個「看起來像答案」的文字。

幻覺的幾種常見形態：虛構數據（如「Aave 當前 USDC 利率是 X%」，但這個數字是模型「合理猜測」而不是查到的）；錯誤的因果推斷（把相關性當成因果性）；以及過度自信地陳述不確定的事情。

在加密 Agent 場景，幻覺的後果比普通使用嚴重得多：在普通使用裡，幻覺最壞的後果是你得到了錯誤信息，你可以事後核查。但在加密 Agent 裡，LLM 的幻覺可能直接觸發鏈上操作——例如 Agent 幻覺了一個「利率高達 12%」的 Aave 數據，然後立刻執行了從低利率協議移倉到 Aave 的操作，而實際上 Aave 當時的利率只有 4%，移倉產生的 Gas 費讓這次操作凈虧損。

防禦設計：所有和市場數據、鏈上狀態相關的判斷，必須從工具回傳的即時數據中獲取，不能讓 LLM 「憑記憶」使用訓練數據裡的數字。在 System Prompt 裡明確指示：「所有數值類信息必須來自工具查詢結果，不得使用訓練數據裡的歷史數字。」

不同的 LLM（GPT-4、Claude、Gemini）在 AI Agent 場景有什麼顯著差異？選模型的時候應該考慮哪些維度？

在 Agent 場景，LLM 的選擇不只是「哪個更聰明」，而是需要從幾個具體維度評估：

Context Window 大小：Agent 的 context 通常包含 System Prompt、工具定義、對話歷史、工具回傳結果，實際消耗很快。Claude 的 200K token context window 在需要分析長文件或長期對話記憶的場景有明顯優勢。

工具調用（Tool Use）的穩定性：不是所有 LLM 都能可靠地輸出格式正確的工具調用請求。GPT-4 的工具調用生態最成熟；Claude 在工具調用的格式遵從和錯誤恢復上表現穩定；較小的開源模型在工具調用上通常更不穩定。

指令遵從性：Agent 的 System Prompt 通常很長且複雜，需要 LLM 在整個推理過程中持續遵守設定的規則（「不要在未確認的情況下執行寫入操作」）。不同模型在長 context 下的指令遵從性差異明顯。

延遲和成本：高頻 Agent（每分鐘多次調用）對延遲和成本敏感。旗艦模型（GPT-4o、Claude Sonnet）在速度和成本上優於更大的模型。

加密知識深度：不同模型在加密協議、DeFi 機制、鏈上概念的知識深度不同，雖然 Agent 應該通過工具查詢而不是依賴模型訓練知識，但模型的背景知識影響它解讀工具回傳結果的品質。

Fine-tuning（微調）一個 LLM 用在加密 Agent 場景，和直接用通用 LLM 加上好的 System Prompt，哪個更值得？

這個問題沒有絕對答案，但有幾個判斷框架：

Fine-tuning 值得投入的場景：你有大量高品質的加密 Agent 操作數據（幾千到幾萬個高品質的 Thought/Action/Observation 範例）；你的 Agent 執行的任務高度重複且有固定格式（例如每次都分析相同格式的 DEX 數據）；對延遲和成本有極嚴格要求（Fine-tuned 的小模型比 API 呼叫大模型便宜得多）；或者你需要讓模型記住大量加密協議的細節（讓它不需要每次都在 System Prompt 裡解釋 AMM 機制）。

通用 LLM + 好的 System Prompt 更值得的場景：你的數據量不夠（Fine-tuning 需要大量高品質數據，少量數據反而可能讓模型過擬合）；你的 Agent 任務多樣且不可預期（通用模型的泛化能力更好）；你需要快速迭代（修改 System Prompt 比重新 Fine-tuning 便宜得多）；以及你的場景對最新知識有要求（Fine-tuned 模型無法取得 API 後端的持續更新）。

2026 年的實際建議：對絕大多數加密 Agent 開發者來說，優先把精力放在工具設計、System Prompt 優化、記憶系統設計上，而不是 Fine-tuning。Fine-tuning 是一個「讓好的 Agent 更好」的手段，不是「讓差的 Agent 變好」的捷徑。