別再只談模型了：你的 Agent 成本失控，問題可能出在上下文工程

在建構 AI Agent 的過程中，我們經常將成本失控歸咎於模型本身，直覺地認為解決方案就是尋找更便宜、更輕量的模型。然而，真正的成本槓桿，往往隱藏在一個更基礎、卻也更容易被忽略的環節：上下文工程（Context Engineering）。近期一個案例顯示，透過精細地重構資訊供給方式，在不更換模型的前提下，就成功將單次請求的 token 消耗量從 16 萬降低到 8 萬，成本直接減半。這證明了，將上下文工程從單純的「提示詞技巧」提升到「系統設計與成本治理」的層次，才是控制 AI 營運成本、提升系統穩定性的根本之道。

這個令人振奮的案例來自一篇日本開發者的實踐分享。他們在 Google Kubernetes Engine (GKE) 上部署了一個名為 Kagent 的開源工具，用於透過自然語言查詢 Google Cloud 的成本數據。系統初期運作良好，但他們很快發現，每一次使用者查詢，背後驅動的 Gemini 1.5 Flash 模型都需要處理高達 16 萬 token 的上下文，這不僅成本高昂，也對系統的回應速度和穩定性構成潛在威脅。

面對這個問題，許多團隊的第一反應可能是降級模型，例如換成一個能力較弱但 token 成本更低的選項。然而，這往往是一場與模型能力的痛苦權衡，可能導致 Agent 的分析能力或任務完成度下降。但該團隊選擇了另一條路：他們沒有更換模型，而是回頭審視整個請求的處理流程，對上下文的供給方式進行了徹底的工程優化。

為什麼上下文工程是比更換模型更根本的解法？

大型語言模型（LLM）的運作成本，與其處理的 token 數量成正比。上下文（Context）就是我們餵給模型的原料，它包含了指令、使用者問題、背景資料、範例等一切資訊。上下文的品質與精確度，直接決定了模型需要花費多少「心力」去理解問題、尋找答案。一個臃腫、嘈雜、充滿無關資訊的上下文，就像一篇沒有重點的會議紀錄，只會讓模型耗費更多運算資源去蕪存菁，從而推高 token 消耗。

我們可以從幾個角度來深入理解，為何優化上下文是比單純更換模型更為根本的解法：

我們能 100% 掌控的變數：可控性與確定性

模型本身對我們而言是一個相對黑箱的元件，其內部運作與成本效益比由模型供應商決定。然而，輸入給模型的上下文，卻是我們作為系統建構者可以 100% 控制的變數。這意味著，透過精準的上下文工程，我們能更確定地影響模型的行為與成本。

將昂貴運算「前移」：Shift-Left Computation

在資訊進入昂貴的 LLM 運算之前，先用傳統且廉價的程式邏輯進行預處理、過濾和結構化，遠比讓 LLM 在龐大的資訊中自行摸索來得有效率。這與資料庫查詢優化的邏輯如出一轍：我們不會把整張表傳給應用程式，而是在資料庫層就下達精確的 SQL 查詢，只取回必要的資料。

不只省錢，更能提升任務成功率

精準的上下文不僅能顯著降低成本，更能大幅提升模型的理解力與任務成功率。當模型收到的資訊都是高度相關且結構清晰的，它犯錯的機率自然會降低，從而減少了因錯誤而需要重試的額外成本，也讓使用者體驗更流暢。

在上述的 Kagent (v0.8.6) 案例中，將 token 從 16 萬降至 8 萬的成果，正是這種思維的體現。他們可能分析了送入模型的完整提示，發現其中包含了大量非必要的 BigQuery 表格結構（schema）描述或其他冗餘的背景資訊，並透過程式化的方式將其動態裁減，只提供與當前查詢最相關的部分。

如何將上下文工程提升到系統設計層次？

將上下文工程視為系統設計的一環，意味著我們需要超越手動調整提示詞的範疇，建立一套自動化、可擴展的上下文建構機制。這不僅是 Prompt Engineer 的工作，更是架構師與後端工程師的共同責任。具體實踐可以從以下幾個方向著手：

動態上下文建構：告別「萬用範本」

摒棄靜態、寫死的「萬用提示範本」。一個高效的 Agent 系統應該根據使用者的具體意圖，程式化地從不同的知識來源（如文件、資料庫、API 回應）中拉取必要資訊，即時組合成一個高度客製化的上下文。這確保了模型只接收到當下最相關的資訊。

分層與路由：讓輕量級 Agent 擔任「交通警察」

對於複雜任務，可以設計一個「分派器 Agent」。這個輕量級的 Agent 使用成本較低的模型，它的唯一任務是分析使用者意圖，並決定接下來應該調用哪個專業 Agent、需要載入哪些特定的工具或知識庫。這避免了一開始就用昂貴模型載入所有可能用到的上下文，實現精準的資源調度。

上下文壓縮與摘要：聰明地處理長篇資訊

在將長篇文件或對話歷史送入模型前，先透過演算法或另一個小型模型進行摘要，提取核心資訊。例如，與其提供過去 50 輪的完整對話紀錄，不如提供一份由模型自己生成的對話摘要，這能有效縮減歷史資訊的 token 佔用。已有不少研究在探索長上下文處理的效率問題，這是一個值得投入的方向。

我們應該抱持一個核心原則：系統中最昂貴的運算，就是那些本可以避免的運算。讓一個價值數百萬美元訓練出來的模型去做簡單的資料篩選和格式整理，無疑是一種巨大的資源浪費。

這個從 16 萬 token 到 8 萬 token 的優化，不僅僅是數字上的成功，它更代表了一種思維上的轉變。它告訴我們，在追求更強大模型的同時，我們也必須回歸軟體工程的基本功：對輸入和輸出進行嚴格的管理，對系統的每一個環節進行成本效益分析。當我們開始將 token 消耗視為一個需要嚴肅對待的系統指標，並為其設計對應的治理機制時，我們才真正走在打造可持續、可規模化的 AI 系統的正確道路上。

延伸閱讀

• 原案例研究：GKE上のコスト分析エージェントのトークン消費を半分にした話
• Kagent 官方 GitHub 儲存庫
• Google Kubernetes Engine (GKE) Autopilot 官方文件
• LlamaIndex Blog: Context is All You Need

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。