Context Window

Token 是什麼？中文、英文、程式碼各自「消耗」多少 Token？

Token 是 LLM 處理文字的基本單位——不完全是「字」，也不完全是「詞」，而是語言模型的分詞器（Tokenizer）把文字切成的片段。不同語言的 Token 效率差很多，這直接影響你的 API 成本和 Context Window 的使用效率。

英文的 Token 效率最高：英文平均每個 Token 約 4 個字符，一個常見英文詞通常是 1 個 Token（如 the、agent、wallet），長詞可能 2-3 個 Token（如 cryptocurrency）。英文大約 750 個詞 ≈ 1,000 Token。

中文的 Token 效率較低：中文每個字通常是 1-2 個 Token（Claude 的 Tokenizer 對中文的壓縮效率比英文差）。繁體中文大約 500-600 個字 ≈ 1,000 Token。（也就是說，同樣的信息用中文寫，消耗的 Token 大約是英文的 1.3-1.5 倍）

程式碼的 Token 消耗最多：縮排、括號、引號、分號——這些符號每個都佔 Token，長函數名也佔更多 Token。一段 100 行的 Python 代碼可能消耗 500-800 Token，遠超等字數的英文散文。

SVG 圖解的 Token 消耗驚人：這是很多人沒想到的——SVG 代碼（<rect x="30" y="40" width="100" fill="#333"> 這樣的標籤）對 Tokenizer 非常不友好，每個屬性值、引號、坐標都是獨立 Token。一張中等複雜的 SVG 圖可能消耗 2,000-5,000 Token，如果在 Agent 的工具回傳裡包含 SVG，會非常快地填滿 Context Window。

實際啟示：在 Agent 的工具回傳設計裡，最小化回傳的 Token 量——只回傳 Agent 需要的字段，不回傳整個 API Response。

Context Window 用滿了會發生什麼？有哪些處理策略？

當 Context Window 接近上限時，模型有不同的處理策略，但都不理想——這就是為什麼「管理 Context Window」是 Agent 工程的核心問題之一。

「硬截斷」（Hard Truncation）：最簡單但最糟糕的處理——直接砍掉最早的 Context 內容，只保留最新的 N Token 給模型。後果：Agent「忘記」了早期的對話和決策上下文，可能重複執行已經做過的操作，或者遺忘了早期設置的重要約束（如「今天不要碰 Aave，因為它正在升級」）。

「滑動視窗摘要」（Sliding Window Summarization）：當 Context 使用超過 70%，自動觸發摘要壓縮——把最早的 N 輪對話用 LLM 壓縮成一段高密度摘要，然後用摘要替換原始對話。損失：細節被壓縮，但關鍵決策點被保留。適合：長時間運行的 DeFi Agent，只需要記住決策結果、不需要記住每個中間步驟。

「RAG 外部化」（Retrieval-Augmented Generation）：把長期信息移出 Context Window，存入向量資料庫，每次推理前只把「最相關的 K 個片段」召回放入 Context。Context 裡只有當前任務相關的信息，而不是全部歷史。這是最靈活的方案，但引入了向量搜尋的延遲和工程複雜度。

「任務切分」（Task Decomposition）：把一個需要大量 Context 的長任務拆成多個獨立的短任務，每個短任務用獨立的、乾淨的 Context。Orchestrator 負責協調各個子任務的輸入/輸出，不讓任何單個任務的 Context 過長。這是 Multi-Agent 系統的設計優勢之一。

實際場景建議：對 DeFi Agent，最常用的是「滑動視窗摘要 + 結構化 DB 長期記憶」的組合——短期 Context 管理用摘要，長期決策記錄用 PostgreSQL 存儲，不完全依賴 Context Window 保留歷史。

Claude、GPT-4o、Gemini 的 Context Window 大小有什麼差異？選模型時怎麼考慮這個維度？

主流模型的 Context Window（截至 2026 年中）：

Claude Sonnet（Anthropic）：200K Token ≈ 約 15 萬個英文詞，或約 10 萬個中文字。對大多數 DeFi Agent 任務足夠，能在一個 Context 裡容納幾小時的操作歷史 + 當前任務 + 工具回傳。

GPT-4o（OpenAI）：128K Token。比 Claude 小，對長時間運行的 Agent 更容易達到上限，需要更積極的 Context 管理策略。

Gemini 1.5 Pro（Google）：1M Token，是目前主流模型裡最大的。理論上可以放入整個 DeFi 協議的代碼庫進行分析，但 Token 越多 API 費用越高，且「大海撈針問題」（在 100 萬 Token 裡找最關鍵的幾行）仍然是未解決的工程問題。

選模型時的 Context Window 考量：

不是越大越好。如果你的 Agent 任務每次 Context 使用量在 20K-50K Token，從 200K 升到 1M 對 Agent 性能幾乎沒有影響，但可能大幅增加 API 費用（通常按 Token 計費，更大 Context 版本的模型每 Token 更貴）。

真正需要超大 Context 的場景：一次性分析大型代碼庫或長篇文件（不是持續運行的 Agent，而是一次性分析任務）；需要在一個 Context 裡比較大量文件的跨文檔分析任務。

對持續運行的 DeFi Agent：200K Token（Claude Sonnet）通常夠用，配合滑動視窗摘要可以無限期延伸。優先考慮模型的推理能力和 Tool Use 支持質量，而不是 Context Window 大小。

「Context Window 大 = Agent 更聰明」是真的嗎？Context Window 大小和 Agent 性能的關係是什麼？

這是最常見的誤解之一。Context Window 大小和 Agent 性能的關係比大多數人想像的更複雜：

Context Window 大小確實影響的事：能否在一個 Context 裡放入完整的任務相關信息（長文件、長對話歷史）；Agent 在單次對話裡「記住」的信息量；一次性大規模分析任務（分析一個完整的合約代碼庫）的可行性。

Context Window 大小不影響的事：模型的推理深度（複雜問題的推理質量）——推理質量主要由模型本身的訓練決定，不由 Context Window 大小決定。一個 200K Token 的 Claude Sonnet，在推理複雜的多步驟 DeFi 策略問題上，可能比 1M Token 的較弱模型做得更好，即使後者能「看到」更多信息。模型的 Tool Use 準確率（工具函數的調用準確性）；模型對 Prompt Injection 的抗性（大 Context 反而可能增加攻擊面——更多外部數據能注入更多惡意指令）。

「大海撈針問題」（Lost in the Middle）：研究發現，當 Context Window 裡有大量文字時，模型傾向於注意 Context 開頭和結尾的信息，忽略中間的信息——即使關鍵信息在中間。這意味著單純增大 Context Window，不能保證模型「更好地利用」更多信息。

實際建議：選模型時，把推理能力、Tool Use 支持質量、定價放在 Context Window 大小之前考慮。Context Window 夠用就好（大多數 Agent 用 128K-200K 足夠），不需要為了大 Context 而選一個推理能力更弱的模型。