您正在將此倉庫連接至 Caveman 閘道。Caveman 是一個位元組保留的 LLM 代理：在記錄模式下，它會測量您的應用程式傳送的內容及其成本，除此之外不會改變任何內容。您的工作是進行最小化、經過驗證的整合，而不是重構。

提示為您提供了四個值。請參考以下名稱：

GATEWAY — 閘道基本 URL（例如 https://gateway.caveman.so 或 http://127.0.0.1:8787）
CAVE_API_KEY — 閘道驗證密鑰（請像對待任何 API 金鑰一樣：僅使用環境變數，絕不提交，絕不完整列印）
PROVIDER_KEYS — stored（提供者金鑰以加密方式存在於 Caveman Cloud 中）或 byok（此應用程式在每個請求中發送自己的提供者金鑰）
DASHBOARD — 儀表板基本 URL（例如 https://app.caveman.so）

如果缺少任何值，請停下來並要求提供。不要猜測 URL 或產生金鑰。

規則（不可協商）

一致性的整合。 透過現有的設定和相關接縫連接每一個實際運作的 LLM 呼叫點。觸及每個正確性所需的層。不要順帶進行重構或格式化檢查；僅在抽象層能釐清所有權或降低生命週期成本時才新增抽象層。
機密必須放在環境變數中。 將 CAVE_API_KEY 放入倉庫已使用的環境變數檔案中（.env, .env.local, …）。如果該檔案未被 .gitignore 忽略，將其加入 .gitignore 並說明。絕不要將金鑰寫入原始碼中。
只報告您觀察到的結果。 最終報告必須陳述來自實際驗證回應的 HTTP 狀態和使用數據——絕不假設成功。如果驗證失敗，請改用失敗範本。
僅限記錄模式。 您正在新增測量功能。您不會啟用任何最佳化功能，也不會聲稱任何節省——在最佳化功能被明確啟用並通過其評估關卡之前，驗證後的節省金額為 $0。
提供者金鑰不關您的事。 使用 PROVIDER_KEYS: stored 時，您永遠不會看到提供者金鑰。使用 byok 時，應用程式現有的提供者金鑰保持在其原來的位置。

步驟 1 — 找到每個實際運作的 LLM 呼叫點

讀取依賴檔案（package.json, requirements.txt, pyproject.toml, go.mod, lockfiles）並在原始碼中搜尋 LLM 客戶端：

SDK 匯入：openai, @anthropic-ai/sdk, anthropic, ai + @ai-sdk/* (Vercel), langchain*, litellm, google-genai / @google/genai, crewai, pydantic_ai, openai-agents / agents
對 api.openai.com, api.anthropic.com, generativelanguage.googleapis.com 的原始 HTTP 請求
現有的基本 URL 環境變數：OPENAI_BASE_URL, OPENAI_API_BASE, ANTHROPIC_BASE_URL, GEMINI_BASE_URL, GOOGLE_GEMINI_BASE_URL

在進行任何修改之前，列出您找到的內容（每個呼叫點的路徑:行號）。如果您找到沒有 LLM 呼叫點，請停下來並回報本文檔末尾的「無可連接」範本—— 不要憑空發明一個整合。

步驟 2 — 選擇應用程式別名

一個別名在閘道路徑中命名此應用程式：GATEWAY/w/<app>。根據套件/模組名稱（例如 support-bot, acme-api）推導出來。語法：以小寫 [a-z0-9]開頭，接著 [a-z0-9._-]，最長 64 個字元。此整個應用程式的花費將在儀表板上以該別名群組顯示。

步驟 3 — 連接每個呼叫點

模式始終相同：基本 URL → 閘道加上 /w/<app>，再加上一個驗證標頭。 閘道驗證是 x-cave-api-key: CAVE_API_KEY（在標頭不方便的地方，Authorization: Bearer CAVE_API_KEY 也行）。使用 PROVIDER_KEYS: byok 時，還要發送 x-cave-upstream-key: <應用程式已使用的提供者金鑰>。

有兩個事實讓連接變得安全（兩者都由閘道強制執行，而非空想）：閘道會從頭開始重建上游驗證標頭，因此客戶端的 Authorization/x-api-key 值永遠不會被轉發給提供者；並且使用 stored 時，上游驗證來自伺服器端的加密連線。因此，在 stored 模式下，如果 SDK 強制要求 api-key 參數，請將其設定為 Cave 金鑰—— 它用於驗證閘道，不會被進一步轉發。

確切形式（使用與每個呼叫點匹配的形式——這些是產品的已發布配方，而非建議）：

OpenAI SDK (TS) — Chat Completions 和 Responses 都透過以下方式路由：

const client = new OpenAI({
  baseURL: `${process.env.CAVE_GATEWAY_URL}/w/<app>/openai/v1`,
  apiKey: process.env.OPENAI_API_KEY,           // byok: 不變 · stored: 使用 CAVE_API_KEY
  defaultHeaders: {
    "x-cave-api-key": process.env.CAVE_API_KEY!,
    // 僅限 byok:
    "x-cave-upstream-key": process.env.OPENAI_API_KEY!,
  },
});

OpenAI SDK (Python) — 相同形式：base_url=f"{gw}/w/<app>/openai/v1"， default_headers={"x-cave-api-key": ..., "x-cave-upstream-key": ...}。

Anthropic SDK (TS/Python) — SDK 會自行附加 /v1/messages。在此兩種模式下，都需要 x-cave-api-key 標頭（此 SDK 自己的金鑰參數使用 x-api-key，這不是閘道驗證標頭）：

client = anthropic.Anthropic(
    base_url=f"{os.environ['CAVE_GATEWAY_URL']}/w/<app>",
    api_key=os.environ["ANTHROPIC_API_KEY"],      # byok: 不變 · stored: 使用 CAVE_API_KEY
    default_headers={
        "x-cave-api-key": os.environ["CAVE_API_KEY"],
        # 僅限 byok:
        "x-cave-upstream-key": os.environ["ANTHROPIC_API_KEY"],
    },
)

Vercel AI SDK — createOpenAICompatible({ baseURL: ${gw}/w//openai/v1， headers: { "x-cave-api-key": ... } })；Anthropic 模型透過 createAnthropic({ baseURL: ${gw}/w//v1，headers: { ... } })。

LangChain / LangGraph — ChatOpenAI(base_url=f"{gw}/w/<app>/openai/v1"， default_headers={...})；ChatAnthropic(base_url=f"{gw}/w/<app>"， default_headers={...})。LangGraph 會繼承您傳遞給它的任何模型。

LiteLLM — 每次呼叫 api_base=f"{gw}/w/<app>/openai/v1" + extra_headers={...}，或在 LiteLLM 代理程式的 config.yaml 中進行整個部署設定。

原始 HTTP / 其他任何東西 — 交換主機，保留提供者的原生路徑： GATEWAY/w/<app>/v1/chat/completions（OpenAI 協議）或 GATEWAY/w/<app>/v1/messages（Anthropic 協議），並加上標頭。

具體來說，使用別名 support-bot 和託管閘道，OpenAI SDK 的基本 URL 為 https://gateway.caveman.so/w/support-bot/openai/v1。而在 stored 模式下，完全刪除每一行 x-cave-upstream-key——它僅供 byok 使用。

對於未列出的框架（google-genai, crewai, pydantic-ai, openai-agents），請提取 <docs origin>/docs/integrations/ 下的對應頁面——與此技能來自相同的來源—— 並遵循其指示。

新增至倉庫的環境變數檔案（並在程式碼中引用——不要使用字面值）：

CAVE_GATEWAY_URL=<GATEWAY>
CAVE_API_KEY=<CAVE_API_KEY>

步驟 4 — 使用一個真實請求進行驗證

使用者貼上設定提示就是為了授權這件事：一個小型驗證請求。現在就發送它—— 不要停下來請求許可。一個因為您猶豫而未經驗證就結束的整合，比一個小小的請求更糟糕；自主完成驗證和報告正是此技能的重點。

透過您剛建立的連接發送一個最小請求——如果有的話，使用應用程式自己的成本最低的路徑（如果有腳本可用），否則使用 與您剛連接的協議匹配的路徑 上的 curl，使用應用程式自己的模型和一個小的上限（max_tokens ≤ 32）：

# OpenAI 協議連接:
curl -sS "$CAVE_GATEWAY_URL/w/<app>/v1/chat/completions" \
  -H "x-cave-api-key: $CAVE_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"<倉庫已使用的模型>","max_tokens":16,"messages":[{"role":"user","content":"ping"}]}'

# Anthropic 協議連接:
curl -sS "$CAVE_GATEWAY_URL/w/<app>/v1/messages" \
  -H "x-cave-api-key: $CAVE_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"<倉庫已使用的模型>","max_tokens":16,"messages":[{"role":"user","content":"ping"}]}'

（byok：請加上 -H "x-cave-upstream-key: $PROVIDER_KEY"。）這是一個真實的、會產生費用的提供者請求——這就是重點：真實的流量，真實的測量。

讀取回應。成功 = HTTP 200 且帶有 usage 區塊。其他任何情況 = 下方的匹配失敗範本。

步驟 5 — 報告

以完全相同的格式結束，根據您實際執行的操作和看到的結果填寫數值：

## Caveman 已在這個倉庫中啟用

已連接：<n> 個檔案中的 <n> 個呼叫點
  - <檔案> — <一行說明變更內容>
應用程式別名：<app> — 此應用程式的花費將以此別名群組
已驗證：HTTP 200 · 模型 <model> · <輸入> 輸入 / <輸出> 輸出 tokens（一個真實請求）
模式：記錄 — 僅測量。沒有模型可見的位元組被更改，沒有啟用最佳化。
驗證後的節省金額為 $0，直到您開啟最佳化功能並且它通過其評估關卡。
這種誠實就是產品的價值所在。

查看花費：<DASHBOARD>/traces — 您的請求位於最上方一行，價格來自公開目錄。
<DASHBOARD>/getting-started 會切換為「已收到第一個請求。」

想要按工作流程（例如 support-reply vs nightly-digest）而非僅按應用程式
來劃分花費嗎？請說「發現工作流程」——我將提取 <docs origin>/docs/discover-workflows.md
並為每個呼叫點標記其所屬的工作。

失敗範本（請逐字使用，填入資料——切勿弱化）

無可連接：「我在這個倉庫中沒有找到任何 LLM 呼叫點（已搜尋 SDK、原始提供者 HTTP、基本 URL 環境變數）。如果此倉庫執行的是編碼代理而非部署 LLM 程式碼，請改用 caveman wrap <agent>——請參閱 /getting-started。」
閘道無法連線：「驗證請求無法到達 GATEWAY （<錯誤>）。連接已就位但未經驗證——在閘道可連線之前，不會測量任何東西。請檢查 URL 和網路，然後重新執行上述的驗證 curl。」
401 cave_invalid_api_key：「閘道拒絕了 CAVE_API_KEY。請在 /getting-started 產生一個新的金鑰並更新環境變數檔案；連接本身無需更改。」
404 cave_route_not_found：「閘道沒有匹配到任何路由——通常是 /w/ 別名格式錯誤（以小寫 [a-z0-9] 開頭，接著 [a-z0-9._-]，最長 64 個字元）或路徑與 SDK 的協議不匹配。請修正 URL 並重新驗證。」
提供者錯誤（經由閘道的 4xx/5xx）：報告狀態和主體原文；閘道可連線且驗證已通過，但上游呼叫失敗——通常是應用程式本身的提供者金鑰或模型名稱問題。

切勿在任何這些情況下報告成功。未經驗證的整合應報告為未經驗證。

Caveman 倉庫設定