VibeCoding
← 返回首頁

如何將 Claude Code 的成本降低 3 倍（運用 Karpathy 的 context engineering

Avi Chawla
Avi Chawla
@_avichawla
♥462🔁 60
𝕏 (Twitter)🔥🔥
查看原文 ↗

如何將 Claude Code 的成本降低 3 倍（運用 Karpathy 的 context engineering 原則）

這是一份完整的分析，說明一個開源工具如何在不更動 CLAUDE.md、Prompt 或模型的情況下，將你的 Claude Code 工作階段成本降低 3 倍（包含設定指南與成效分析）。

MCPMark V2 的基準測試揭露了一個反直覺的現象。

當 Claude 從 Sonnet 4.5 升級到 Sonnet 4.6 時，透過 Supabase 的 MCP server 產生的後端 token 使用量，在 21 個資料庫任務中從 1160 萬增加到了 1790 萬 token。

模型變聰明了，但後端 token 的使用量反而增加了。

原因很微妙，且與模型本身無關。

這與後端如何向 Agent 揭露資訊有關。當 context 不完整時，能力更強的模型並不會直接跳過缺口。

它會花費更多 token 來推論該缺口、執行更多探索性查詢，並更頻繁地重試。因此，缺失的 context 並不會因為模型變強而消失，反而變得更昂貴。

讓我們來看看為什麼後端會成為 Agent 的 token 黑洞、替代架構長什麼樣子，以及在實際專案中的成本差異。

為什麼 Supabase 的 MCP server 會浪費 token

Supabase 是一個很棒的後端，但它並非為 AI Agent 的操作而設計，後續加入的 MCP server 也繼承了這項限制。

有三個具體機制導致了 token 的膨脹。

1) 文件檢索回傳了所有內容

當 CC (Claude Code) 需要透過 Supabase 設定 Google OAuth 時，它會呼叫 search_docs MCP 工具。

Supabase 的實作在每次呼叫時都會回傳完整的 GraphQL schema 中繼資料，這比 Agent 實際需要的 token 多出 5-10 倍。

如果 Agent 詢問 OAuth 設定說明，它會得到完整的驗證文件，包含電子郵件/密碼、Magic Links、電話驗證、SAML 和 SSO 等章節。

這發生在每次 search_docs 呼叫時，例如資料庫查詢、儲存設定和 Edge Function 部署。

每次呼叫都會傾倒該領域的完整中繼資料。在一個 Agent 設定驗證、資料庫、儲存和 Function 的工作階段中，僅文件開銷就可能導致數千個 token 的浪費。

2) 無法查看後端狀態

當你以人類開發者身分使用 Supabase 時，你可以打開儀表板並一目了然地看到所有內容，例如啟用的驗證提供者、資料表、RLS 政策、儲存桶設定、已部署的 Edge Function 等。

但 Agent 看不到儀表板。

Supabase 的 MCP server 確實透過 list_tables 和 execute_sql 等個別工具揭露了一些狀態，但沒有辦法詢問「我目前的整個後端看起來是什麼樣子？」並得到一個結構化的回應。

因此，Agent 必須透過多次呼叫將資訊拼湊起來，每次呼叫僅回傳部分視圖，且有些資訊（例如已設定哪些驗證提供者）根本無法透過 MCP 取得。

這種碎片化的探索過程會消耗 token，且 Agent 往往需要多次嘗試，因為回傳的資訊不完整，或者格式需要進一步查詢才能解讀。

3) 沒有結構化的錯誤 context

當出錯時（這一定會發生，因為 Agent 是在猜測），Supabase 只會回傳原始錯誤訊息。可能是 RLS 拒絕導致的 403，或是 Edge Function 設定錯誤導致的 500 等。

人類開發者會查看它，檢查 Supabase 儀表板，對照日誌，然後修復問題。

Agent 沒有這條路徑。它只會收到錯誤訊息，推論可能的原因，然後嘗試修復。

如果修復錯誤，它就會重試。每次重試都會重新發送整個對話歷史，並累積 token 成本。

這三個機制（文件開銷、狀態探索、錯誤重試迴圈）會快速疊加。

像 Sonnet 4.6 這樣推理能力更強的模型，會讓每個探索步驟變得更徹底，也更昂貴。

這就是為什麼 token 差距從 Sonnet 4.5 到 4.6 擴大了，而且隨著每個新模型的發布，這種差距可能會進一步擴大。

「後端 context engineering」應該是什麼樣子

解決方法不是切換到另一個模型。

而是給予 Agent 一個結構化的後端 context，這樣它就不需要探索和猜測。

這就是 Karpathy 所說的 context engineering：「將正確的資訊填入 context window 以進行下一步的精細藝術與科學。」他明確地將工具和狀態視為該 context 的一部分。大多數人將此概念應用於 Prompt 和 RAG 檢索。

但後端也是 context window 的一部分，而目前，這是幾乎沒人優化的部分。

為了看看這在實踐中是什麼樣子，InsForge（擁有 8k 星的開源專案）實作了這種方法。

它提供了與 Supabase 相同的基礎元件（Postgres with pgvector、驗證、儲存、Edge Functions 和即時功能），但結構化了資訊層，以便 Agent 可以高效地使用它。

關鍵的架構差異在於它如何將 context 傳遞給 Claude Code。

三個層級協同運作：

  • Skills：用於靜態知識。

  • CLI：用於直接後端操作。

  • MCP：用於即時狀態檢查。

每一層解決不同的問題，並基於不同的原因減少 token 使用。

1) Skills：零往返的靜態知識

知識的主要方法是 Skills。它們在工作階段開始時直接載入到 Agent 的 context 中，因此每個後端操作的 SDK 模式、程式碼範例和邊緣案例都無需任何工具呼叫即可使用。

Skills 也使用漸進式揭露，即最初僅載入中繼資料（名稱、描述，每個 skill 約 70-150 個 token）。

完整的 skill 內容僅在 Agent 判斷它符合當前任務時才會載入。這意味著你可以安裝 100 多個 skills 而不會導致 context 膨脹，這在使用 MCP 的全有或全無 schema 載入方式下是不可能的。

四個 skills 涵蓋了整個技術堆疊，每個都針對特定領域：

  • insforge：用於與後端對話的前端程式碼。

  • insforge-cli：用於後端基礎設施管理。

  • insforge-debug：用於跨常見故障的結構化錯誤診斷（例如驗證錯誤、慢查詢、Edge Function 失敗、RLS 拒絕、部署問題和效能下降）。

  • insforge-integrations：用於第三方驗證提供者（Clerk、Auth0、WorkOS、Kinde、Stytch）。

使用一個指令安裝所有四個：

npx skills add insforge/insforge-skills

2) 用於直接執行的 CLI

對於實際執行後端操作（建立資料表、執行 SQL、部署 Function、管理密鑰），InsForge CLI 是主要的介面。

每個指令都支援 --json 以進行結構化輸出，-y 以跳過確認提示，並回傳語意化的退出代碼，以便 Agent 可以程式化地偵測驗證失敗、專案缺失或權限錯誤。

這很有幫助，因為 Claude Code 可以透過 jq、grep 和 awk 來處理 CLI 輸出，這在以前需要多次連續的 MCP 工具呼叫。

來自 Scalekit 的基準測試顯示，CLI+Skills 在單使用者工作流程中，達到了近 100% 的成功率，且 token 效率比同等的 MCP 設定高出 10-35 倍。

以下是 Agent 實際執行的一些操作範例：

# 檢查後端狀態（先執行以發現已設定的內容）
npx @insforge/cli metadata --json

# 資料庫操作
npx @insforge/cli db query "CREATE TABLE posts (...)" --json
npx @insforge/cli db policies  # 檢查現有的 RLS 政策

# Edge functions
npx @insforge/cli functions deploy my-handler
npx @insforge/cli functions invoke my-handler --data '{"action":"test"}' --json

# 儲存
npx @insforge/cli storage create-bucket documents --json
npx @insforge/cli storage upload ./file.pdf --bucket documents

# 前端部署
npx @insforge/cli deployments env set VITE_INSFORGE_URL https://...
npx @insforge/cli deployments deploy ./dist --json

# 診斷
npx @insforge/cli diagnose db --check connections,locks,slow-queries

Agent 解析 JSON 並根據退出代碼處理錯誤。

3) 用於即時後端狀態的 MCP 工具

MCP 仍然有用，但用途更窄，例如在狀態變更時檢查後端的當前狀態。

InsForge 的 MCP server 提供了一個輕量級的 get_backend_metadata 工具，它可以在單次呼叫中回傳包含完整後端拓樸的結構化 JSON：

{
  "auth": {
    "providers": ["google", "github"],
    "jwt_secret": "configured"
  },
  "tables": [
    {"name": "users", "columns": ["id", "email", "created_at"], "rls": "enabled"},
    {"name": "posts", "columns": ["id", "title", "body", "author_id"], "rls": "enabled"}
  ],
  "storage": { "buckets": ["avatars", "documents"] },
  "ai": { "models": [{"id": "gpt-4o", "capabilities": ["chat", "vision"]}] },
  "hints": ["Use RPC for batch operations", "Storage accepts files up to 50MB"]
}

在一次呼叫和約 500 個 token 中，Agent 就了解了完整的後端拓樸。hints 欄位提供了特定於 Agent 的指導，減少了錯誤的 API 使用。

這裡的關鍵設計選擇是 MCP 用於狀態檢查（隨著 Agent 工作而變更），而不是用於文件檢索（不會變更）。

這顛倒了典型的使用模式，這也是 InsForge 在同等任務中消耗的 token 遠少於 Supabase 的主要原因。

Supabase vs Insforge：使用 Claude Code 構建 DocuRAG

為了具體說明，我使用 Claude Code 在兩個後端上構建了同一個應用程式，並記錄了整個工作階段。

該應用程式稱為 DocuRAG。使用者透過 Google OAuth 登入，上傳 PDF，系統將文字分塊並嵌入（text-embedding-3-small，1536 維度），將向量儲存在 pgvector 中，使用者透過 GPT-4o 以自然語言提問並獲得回答。

這幾乎觸及了所有後端基礎元件：使用者驗證、檔案儲存、文件資料表、向量嵌入、嵌入生成、聊天完成、檢索 Edge Function 以及隔離每個使用者文件的 RLS。

以下是每個後端的設定。

Supabase

  • 建立一個 Supabase 帳號並建立一個新專案。

  • 將 MCP server 連接到 Claude Code 並進行驗證：

claude mcp add --scope project --transport http supabase \
  "https://mcp.supabase.com/mcp?project_ref=<your-project-ref>"

claude /mcp
  • 安裝 Supabase 的 Agent Skills（在 Supabase 的官方設定中標記為「選用」）：
npx skills add supabase/agent-skills

這會安裝兩個 skills：

  • supabase：涵蓋資料庫、驗證、Edge Functions、即時功能、儲存、向量、Cron、佇列、客戶端函式庫 (supabase-js, @supabase/ssr)、SSR 整合 (Next.js, React, SvelteKit, Astro, Remix)、CLI、MCP、schema 變更、遷移和 Postgres 擴充功能的廣泛技能。

  • supabase-postgres-best-practices：涵蓋 8 個類別的 Postgres 效能優化。

Supabase 提供了一個廣泛的 skill，會在「任何涉及 Supabase 的任務」中觸發，加上一個專門的 Postgres 優化 skill。當 Supabase skill 啟用時，它的所有內容都會載入，因為觸發條件涵蓋了幾乎整個產品表面。

Insforge

  • 建立一個 Insforge 帳號並建立一個新專案（你也可以使用 Docker Compose 自行託管並完全在本地執行）。

  • 安裝所有四個 Skills：

npx skills add insforge/insforge-skills

這會安裝 insforge (SDK 模式)、insforge-cli (基礎設施指令)、insforge-debug (故障診斷) 和 insforge-integrations (第三方驗證提供者)。

  • 將 CLI 連結到你的專案（主要執行層）：
npx @insforge/cli link --project-id <project-id>

InsForge 提供四個範圍狹窄的 skills，每個都涵蓋特定領域。

  • 當你在編寫前端程式碼時，只有 insforge 啟用。

  • 當你在建立資料表時，只有 insforge-cli 啟用。

  • 當出現問題時，只有 insforge-debug 啟用。

完整的 skill 內容僅針對符合當前任務的一個 skill 載入。其他三個保持僅中繼資料成本。

兩個工作階段的 Prompt 幾乎相同，只有一個關鍵差異。

  • Supabase：
Build a chat with document app called DocuRAG.
It will be a typical RAG setup where a user
can upload a document. It will be chunked, embedded,
and stored in a vector DB. Once done, a user can ask
questions about the document. The engine will retrieve
the relevant chunks after embedding the query. Finally,
it will generate a coherent response using GPT-4o based
on the query and the retrieved context. Add Google OAuth.
Use Supabase as the backend and LLMs/embedding models via
the OpenAI API. Build frontend in next.js.
  • InsForge：
Build a chat with document app called DocuRAG.
It will be a typical RAG setup where a user
can upload a document. It will be chunked,
embedded, and stored in a vector DB. Once done,
A user can ask questions about the document.
The engine will retrieve the relevant chunks
after embedding the query. Finally, it will
generate a coherent response using GPT-4o based on
the query and the retrieved context. Add Google OAuth.
Use Insforge as the backend and also for the model
gateway. Build the front-end in Next.js.

Supabase 的 Prompt 說「透過 OpenAI API 使用 LLMs/嵌入模型」（需要串接兩個系統）。InsForge 的 Prompt 說「也作為模型閘道」（一個系統）。

我並排執行了兩個工作階段並記錄了完整的構建過程。這是有關從 Prompt 到可運作應用程式的並排影片。

它也展示了兩個工作階段中構建的最終應用程式，分別建立在兩個不同的後端上。

影片中未捕捉到的一件事：Supabase 需要在 Claude Code 之外手動設定 Google OAuth。我必須導航到 Google Cloud Console，建立 OAuth 2.0 用戶端 ID，設定同意畫面，將我的電子郵件添加為測試使用者，複製用戶端 ID 和用戶端密鑰，然後將其貼上到 Supabase 的儀表板中。這在 Insforge 中是不需要的。

在深入了解每個工作階段的細節之前，以下是最終的數據：

  • Supabase：1040 萬 token；9.21 美元成本，包含 12 則使用者訊息（10 則錯誤報告）。

  • InsForge：370 萬 token；2.81 美元成本，包含 1 則使用者訊息（0 則錯誤報告）。

現在讓我們看看每個工作階段實際發生了什麼。

為了客觀地分析這兩個工作階段，我匯出了兩次執行的完整 Claude Code 工作階段歷史記錄（作為 JSONL 檔案），並將它們餵給另一個 Claude 實例。下方的分析（包含工具呼叫次數、錯誤序列和 token 分解）來自於對這些工作階段日誌的解析。

Supabase（消耗 1040 萬 token，成本 9.21 美元）

最初的構建進行得很順利。

Agent 載入了 supabase skill，透過 MCP 工具 (list_tables, list_extensions, execute_sql) 發現了後端狀態，搭建了 Next.js 專案，建立了資料庫 schema，編寫了兩個 Edge Functions (ingest-document 和 query-document)，並部署了所有內容。構建通過了。

第一個問題：登入無法運作

當我嘗試使用 Google OAuth 登入時，應用程式拋出了錯誤。Agent 使用了錯誤的 Supabase 客戶端函式庫來進行 Next.js 的驗證。

在 Next.js 中，OAuth 回呼在伺服器上執行，但 Agent 使用了一個將登入狀態儲存在瀏覽器中的客戶端函式庫。瀏覽器狀態在伺服器上不可用，因此登入流程中斷。

Agent 透過切換到不同的函式庫 (@supabase/ssr)、重寫應用程式處理登入工作階段的方式並重新構建來解決此問題。

文件上傳失敗（花了 8 次嘗試才修復）

登入修復後，我嘗試上傳文件。Edge Function 回傳了一個錯誤，我回報了它，它嘗試修復，失敗，然後我再次嘗試，它回傳了相同的錯誤。這個循環重複了 8 次：

  • Agent 嘗試手動添加驗證標頭 → 相同的錯誤。

  • 重新部署並添加額外的日誌以查看發生了什麼 → 相同的錯誤。

  • 嘗試顯示真實的錯誤訊息而不是通用的錯誤訊息 → 不同的錯誤（現在是網路/CORS 問題）。

  • 修復了 CORS 問題 → 回到原始錯誤。

  • 嘗試了另一種讀取使用者登入 token 的方法 → 相同的錯誤。

  • 嘗試了另一種驗證方法 → 相同的錯誤。

經過 8 次失敗的嘗試，Agent 終於弄清楚發生了什麼事：「401 錯誤可能是在我們的程式碼執行之前，在平台的 verify_jwt 閘道處發生的。」

簡單來說，Supabase 有一個安全層，會在 Edge Function 程式碼執行之前檢查登入 token。Agent 安裝的新驗證函式庫（為了修復第一個問題）發送了一個該安全層無法識別的 token 格式。

因此，每個請求在函數程式碼有機會執行之前就被拒絕了。這就是為什麼沒有任何程式碼層級的修復有效的原因。

Agent 花了 8 輪時間修復程式碼層級的問題，而問題完全在程式碼的上游。

解決方案很簡單：關閉平台的自動 token 檢查，並在函數程式碼內處理驗證。

它花了 8 次嘗試，因為每次它都看到 401（未經授權）錯誤，但沒有任何東西告訴它拒絕來自哪裡。沒有那個訊號，它就不斷嘗試修復程式碼。

但在這個除錯過程中，Edge Function 被重新部署了 8 次（在構建期間的 2 次初始部署之上）。每次重新部署、日誌檢查和重試都會重新發送整個不斷增長的對話歷史，從而增加了 token 成本。

最終工作階段統計涉及：

  • 12 則使用者訊息（10 則為錯誤報告）

  • 135 次工具呼叫

  • 30+ 次 MCP 工具呼叫。

  • 1040 萬 token

  • 9.21 美元成本

Insforge（消耗 370 萬 token，成本 2.81 美元）

InsForge 工作階段在沒有任何需要我介入的錯誤的情況下完成。

Agent 首先檢查了後端狀態。

它的第一個動作是 npx @insforge/cli metadata --json，它回傳了專案的結構化概覽，包含已設定的驗證提供者、現有資料表、儲存桶、可用的 AI 模型和即時頻道。

這讓 Agent 在編寫任何程式碼之前就對它正在處理的內容有了完整的了解。

在 Supabase 工作階段中，Agent 需要多次 MCP 呼叫 (list_tables, list_extensions, execute_sql) 才能拼湊出類似的理解，即便如此，它還是錯過了關鍵細節，例如 verify_jwt 行為。

Schema 設定透過 6 個 CLI 指令執行，全部成功。

Agent 啟用了 pgvector，建立了 documents 和 chunks 資料表（帶有 vector(1536) 欄位），在兩者上啟用了 Row Level Security，建立了存取政策，並設定了 match_chunks 相似度搜尋函數。

每個指令都回傳了確認發生了什麼的結構化輸出，因此 Agent 可以在進入下一步之前驗證每個步驟。

Supabase 工作階段中的驗證和 Edge Function 問題在這裡沒有發生。

insforge skill 包含了 Next.js 的正確客戶端函式庫模式，因此 Agent 在第一次嘗試時就正確地串接了驗證。

而且兩個 Edge Functions (embed-chunks 和 query-rag) 都部署並執行且沒有錯誤，因為嵌入和聊天完成的模型閘道是同一個後端的一部分。

Agent 不需要單獨整合 OpenAI、管理第二個 API 金鑰，或處理跨服務驗證。

中繼資料回應已經將 text-embedding-3-small 和 gpt-4o 列為可用模型，因此 Agent 透過 InsForge SDK 直接呼叫它們。

最終工作階段統計涉及：

  • 1 則使用者訊息

  • 77 次工具呼叫

  • 0 次 MCP 工具呼叫。

  • 370 萬 token

  • 2.81 美元成本

我請 Claude 生成一個表格摘要，這是它產生的結果：

Supabase 工作階段的 token 成本是由錯誤重試迴圈驅動的。

每次 8 次 Edge Function 重新部署都會重新發送整個對話歷史（隨著每次嘗試而增加）。

Agent 檢查了 6 次日誌，重新部署了 8 次函數，並在找到根本原因之前嘗試了 6 種不同的驗證策略。

這些都不是 Agent 的錯。Supabase 平台的 verify_jwt 閘道在函數程式碼執行之前就拒絕了 token，而日誌沒有區分平台層級和程式碼層級的拒絕。

Insforge 工作階段避免了這些問題，因為 skills 從一開始就載入了正確的驗證模式，CLI 對每個操作都提供了結構化的回饋，而模型閘道意味著沒有第二個服務需要整合。

Agent 沒有遇到任何需要除錯的錯誤。

總結

這個比較凸顯了一個超越 Supabase 本身的問題。

大多數後端是為人類開發者設計的，他們可以閱讀儀表板、解讀模糊的錯誤，並在多個服務之間在心理上追蹤狀態。

當 Agent 接管該工作流程時，這些假設就會破裂。Agent 看不到儀表板。如果日誌沒有說明，它無法判斷錯誤來自哪裡。而且每次它猜錯，token 成本就會累積。

InsForge 是圍繞著一組不同的假設構建的。

  • 後端透過結構化中繼資料揭露其狀態，CLI 為 Agent 提供具有明確成功/失敗訊號的程式化控制。

  • Skills 編碼了正確的模式，因此 Agent 不需要透過反覆試驗來發現它們。

  • 模型閘道將 LLM 操作保持在同一個後端內，這消除了導致 Supabase 工作階段大部分除錯問題的跨服務整合問題。

這些架構選擇對你是否重要，取決於你如何使用 Claude Code 或任何其他程式撰寫 Agent。

如果你正在構建僅前端的應用程式，後端層並不是你 token 消耗的地方。

如果你正在構建包含驗證、儲存、向量搜尋和 LLM 呼叫的全端應用程式，後端正是 token 成本所在的地方，而該後端如何與 Agent 溝通會產生可衡量的差異。

但核心見解適用於你使用的任何工具。

如果你的 Agent 正花費 token 來探索你的後端如何運作、猜測設定，並因為錯誤訊息沒有告訴它哪裡出錯而重試操作，那麼你就是在為缺失的 context 付費。

解決方法不是更好的模型或更長的 context window。而是給予 Agent 關於你後端的結構化資訊，在它開始編寫程式碼之前。

這就是應用於後端的 context engineering。Karpathy 說得對，將正確的資訊填入 context window 是核心技能。

這個實驗的見解是，你的後端基礎設施是該 context 的最大來源之一，而我們大多數人並沒有這樣對待它。

InsForge 在 Apache 2.0 下完全開源，你可以透過 Docker 自行託管。

程式碼、skills 和 CLI 都在其 GitHub 儲存庫中：https://github.com/InsForge/InsForge

附註：此實驗中 2.8 倍的 token 減少部分是由於 Supabase 端的除錯迴圈所驅動，Agent 花了 8 輪時間修復了一個結果證明在其自身程式碼上游的問題。這是一個真實的場景，但並非每個工作階段都會遇到該特定問題。MCPMark V2 基準測試在 4 次獨立執行中測試了 21 個資料庫任務，並在 Sonnet 4.6 上顯示了更一致的 2.4 倍減少。

以上就是全部內容！

如果你喜歡這篇教學：

找到我 → @_avichawla

每天，我都分享關於 DS、ML、LLMs 和 RAGs 的教學與見解。

在 X 上閱讀原文 ↗Gemini 翻譯