程式碼代理如何有效運用上下文：提升效率與降低成本的關鍵

無論是使用 Claude Code、Codex 還是 Gemini CLI，會話的品質及其成本，很大程度上取決於代理讀取了哪些資訊。管理這些上下文是一項架構上的學問，需要簡潔的基準線、在正確時間載入知識、控制會話長度，並積極衡量成本。

程式碼助理和程式碼代理已成為開發者日常工作流程的一部分。根據 Stack Overflow 最新針對全球 169 個國家、超過 3 萬名開發者和技術專業人士的調查，程式碼助理和代理已成為最主要的 AI 使用案例，採用率達 66%，領先於通用型聊天機器人。在 AI 程式碼助理或代理的使用者中，有 73% 每天都會使用它們。

當會話出錯或費用開始飆升時，第一個被懷疑的通常是模型本身，或是提示詞的措辭方式。然而，代理在回答之前已經讀取了什麼，卻很少受到關注。代理只能利用其上下文中的可用資訊來工作，而部分上下文從未在螢幕上顯示。

這引出了本文的核心問題：我們如何在不讓程式碼代理過載或每次都為相同資訊付費的情況下，為其提供足夠的上下文以有效工作？為了回答這個問題，我們需要追蹤整個會話中的上下文：從第一個提示詞之前載入的內容，到最終導致成本的因素。

代理的閱讀方式與聊天機器人不同。它會開啟檔案、執行指令、接收工具輸出，並將所有這些內容添加到其上下文中。Anthropic 指出，Claude Code 會話比標準聊天更消耗 token，因為它們包含系統提示詞、檔案上下文、工具呼叫和多輪推理。

部分上下文在第一個使用者提示詞之前就已載入。在啟動時，代理會載入其指令檔案（Claude Code 的 CLAUDE.md、Codex 和其他代理的 AGENTS.md，以及 Gemini CLI 的 GEMINI.md），以及記憶體、可用工具和功能描述。在 Claude Code 中，/context 指令會顯示目前載入到上下文視窗中的內容。

連接的工具可能會消耗比團隊預期更多的上下文。Anthropic 曾記錄過工具定義在代理處理使用者請求之前就消耗了超過 5 萬個 token 的案例，這就是為什麼工具發現和按需載入對於保持上下文可管理性至關重要。

此外還有指令檔案，每個團隊都傾向於擴展它。最近的研究已經衡量了其影響，結果好壞參半。一項與 ETH Zurich 和 LogicStar.ai 相關的研究發現，任務成功率沒有普遍提高，但推論成本增加了 20% 以上。儘管常見，儲存庫概覽並沒有太大幫助。

另一項關於 AGENTS.md 檔案的研究測量了 124 個拉取請求任務的執行速度，中位執行時間減少了近 29%，但沒有評估結果的正確性。相比之下，Khatri 的消融研究發現，生成程式碼的正確性沒有可衡量的改善。然而，這些研究都指向同一個方向：指令檔案並不會讓代理從根本上變得更強大。

它只是防止代理猜測那些無法推斷的內容。因此，此類檔案的最佳內容是那些在 README 或程式碼庫中尚未提供的資訊：專案特定的慣例、非功能性需求、不尋常的建置步驟、架構限制或容易違反的規則。Anthropic 也建議保持 CLAUDE.md 精簡，大約在 200 行以下。

一旦會話開始，上下文會隨著每個讀取的檔案和執行的指令而增長。隨著上下文視窗被填滿，工具可能會總結對話以釋放空間。Claude Code 透過 /compact 實現這一點，而 /clear 則在切換任務時啟動一個新的對話。Anthropic 的實用規則很簡單：新任務使用 /clear，繼續長任務時使用 /compact。

這很重要，因為上下文品質直接影響輸出品質。一個漫長的偵錯會話可能包含數十個檔案、指令輸出、失敗嘗試和中間推理。如果所有這些都保留在會話中，每個新的請求都會帶來更多的雜訊和更高的成本。

有些步驟會為一個單一結論產生大量文字：探索程式碼庫、檢查結果、閱讀冗長的日誌或審查測試輸出。子代理可以在自己的上下文中處理這項工作，並只向主會話返回一個簡潔的摘要。Claude Code 文件將子代理描述為在自己的上下文視窗中工作，然後再回報的次要 Claude 實例。

關鍵問題很直接：原始輸出以後會有用，還是只有結論有用？如果只有結論重要，隔離任務可以使主上下文更清晰。但隔離也有成本：每個子代理仍然可能探索檔案、執行指令並消耗 token。

Claude Code 還支援針對任務不同部分使用不同模型的工作流程。Anthropic 建議 Sonnet 用於大多數程式碼工作，Opus 用於更困難的架構或偵錯問題，而 Haiku 則用於更快、更便宜的查詢或簡單的編輯。常見的模式是使用更強大的模型進行規劃，然後使用更經濟的模型執行。

然後就是成本問題。在 Claude Code 中，成本主要來自重複的上下文。每次輪次都會將迄今為止的對話、專案上下文、讀取的檔案和新的使用者提示詞發送回模型。會話越長，每次額外互動的成本就越高。Anthropic 的文件建議對 API 計費的會話使用 /cost，並對團隊或企業監控使用使用情況分析。

提示詞快取通常是降低成本的主要手段之一：穩定的上下文可以比不斷變化的上下文更便宜地重複使用。因此，穩定的基準線隨著時間的推移成本更低；重複重寫的基準線則失去了部分優勢。上下文也是一個安全表面。

代理讀取的所有內容都可能影響其行為：網頁、問題、拉取請求、日誌檔或工具的輸出。OWASP 在其 2025 年十大風險中，將提示詞注入（直接或間接）列為基於 LLM 應用程式的首要風險。這導致了兩項重要實踐：將外部內容視為資料，絕不視為指令；只連接有用、經過驗證且必要的 MCP 連接器。

管理程式碼代理上下文的原則包括：簡短且定期審查的指令；僅在需要時載入知識；保持會話專注和有界；適當隔離嘈雜任務；持續監控成本；將外部輸入視為不受信任的資料。每個團隊成員都在自己的層面做出貢獻：檢查代理載入哪些資訊、維護版本化和審查過的指令檔案、定義存取權限或設定使用預算。這些互補的職責決定了代理可以存取什麼、可以消耗多少以及可以多可靠地工作。