網(wǎng)上給 Claude Code 接第三方 API 的教程一抓一大把，但清一色都在教你怎么填 base_url、api_key，填完能對話就算完事?？烧嬲阉鼟焐先ヅ芤魂囎幽憔蜁l(fā)現(xiàn)：填 URL 是五分鐘的體力活，選對平臺才是真功夫。

我自己就踩過一次：一個掛著 Claude Code 跑的小工具，原本用官方額度，想省錢換了家便宜的第三方 API，結(jié)果月底賬單不降反升。單價明明更低，總價怎么反而漲了？后來才搞明白，是漏看了一個關(guān)鍵的東西——緩存。

這篇就是把“換之前到底該看什么”這件事測明白后的復(fù)盤。用藍(lán)耘元生代 MaaS 接 DeepSeek-V3.2，中間拉了另一家平臺的同款模型做對照。數(shù)據(jù)都是自己 curl 跑出來的，截圖都在，能復(fù)現(xiàn)。

結(jié)論先放這兒，后面全是論證：

延遲看尾部，成本看緩存，Agent 看工具調(diào)用。

一、先說清楚：為什么我最后落在藍(lán)耘，而不是繼續(xù)用官方

不繞彎子。我選平臺時腦子里過的是這么幾件事，按重要性排：

1. 它到底支不支持 Claude Code 的原生協(xié)議，還是要我自己搭翻譯層；
2. 同樣的活兒，重復(fù)上下文能不能命中緩存、省下那筆冤枉錢；
3. 延遲穩(wěn)不穩(wěn)定，別一卡就是好幾秒；
4. 出了問題有沒有地方查——用量、賬單、調(diào)用日志。

藍(lán)耘 MaaS 這幾條我一條條測下來基本都能對上，尤其是第 1 和第 2 條，后面會拿數(shù)據(jù)說話。這里先給個平臺的直觀印象：模型廣場里 DeepSeek、通義 Qwen、智譜 GLM、Kimi、MiniMax 這些主流的都在，一個 Key 全能調(diào)，想換模型改一行配置的事。

這個“一個 Key 調(diào)所有模型”的統(tǒng)一網(wǎng)關(guān)設(shè)計，是我后面能輕松做橫向?qū)Ρ鹊那疤?mdash;—我不用去每家單獨注冊、單獨拿 Key，選型這件事本身的成本就低了。

二、拿 Key：三個必須記下來的東西

先到藍(lán)耘 MaaS 控制臺（https://console.lanyun.net/#/register?promoterCode=a1acd000c1）注冊登錄，然后充值——不充值 Key 是激活不了的，這是我踩的第一個小坑，建的 Key 一直報 invalid company api key，后來發(fā)現(xiàn)是賬戶余額為空。充完值再建 Key 就正常了。

小提醒：Key 建好只在創(chuàng)建那一刻完整顯示一次，記得馬上復(fù)制存好。

拿到 Key 之后，有三個東西你必須在控制臺確認(rèn)清楚，這決定了后面怎么接：

1. 調(diào)用地址（Base URL）：https://maas-api.lanyun.net
2. 協(xié)議格式：藍(lán)耘同時提供了 OpenAI 兼容（/v1/chat/completions）和 Anthropic 兼容（/anthropic/v1/messages）兩套端點——這一點非常關(guān)鍵，下面單獨講。
3. 模型的準(zhǔn)確調(diào)用名：比如 DeepSeek 是 /maas/deepseek-ai/DeepSeek-V3.2，注意它帶 /maas/ 前綴，不是干巴巴一個 deepseek-chat，寫錯了直接 404。

控制臺每個模型點進(jìn)去都有 API 示例，照著抄不會錯：

三、第一關(guān)：連通性冒煙，順便看清它的 usage 長什么樣

任何新 API 到手，我第一件事永遠(yuǎn)是發(fā)一個最小請求，確認(rèn)“通沒通”，別急著寫代碼。

export LY_KEY="你的Key"       # 打碼,別外泄
export LY_BASE="https://maas-api.lanyun.net/v1"
export LY_MODEL="/maas/deepseek-ai/DeepSeek-V3.2"
curl -sS "$LY_BASE/chat/completions" \
  -H "Authorization: Bearer $LY_KEY" -H "Content-Type: application/json" \
  -d "{\"model\":\"$LY_MODEL\",\"messages\":[{\"role\":\"user\",\"content\":\"只回復(fù)兩個字:通了\"}]}" | jq .

返回里有個細(xì)節(jié)我特意多看了兩眼——usage 字段：

"usage": {
  "prompt_tokens": 9,
  "completion_tokens": 1,
  "total_tokens": 10,
  "prompt_tokens_details": {
    "cached_tokens": 0,
    "audio_tokens": 0
  }
}

看到那個 prompt_tokens_details.cached_tokens 了嗎？這個字段的存在，意味著平臺把“緩存命中了多少 token”這件事透明地告訴了你。 很多人冒煙測試只看 content 對不對，我一定會看 usage——因為這決定了我后面能不能算清成本賬。這里先記住它現(xiàn)在是 0，第五節(jié)我會讓它“活”起來。

一個 URL 拼接的坑，我替你踩了：控制臺給的是帶 /v1 的。如果你像我一樣 export LY_BASE=".../v1"，那命令里就只能拼 /chat/completions；要是再手賤拼成 /v1/chat/completions，就變成了 /v1/v1/...，直接 405 Not Allowed。這種低級錯誤排查起來還挺費時間的，統(tǒng)一好前綴，一次性釘死。

四、第二關(guān)：延遲——只看平均值的評測都是外行

這是全篇我最想掰扯清楚的一點。

網(wǎng)上絕大多數(shù)“某某模型延遲實測”，給你一個“平均 1.2 秒”就完事了。但對 Claude Code 這種 Agent 來說，平均值幾乎沒用，你該看的是尾部延遲（p95/p99）。

道理很簡單：Agent 干一個活，不是發(fā)一次請求，是連著發(fā)十幾到幾十次工具調(diào)用。這一長串請求里，只要有一次卡了十秒，你整個任務(wù)的體感就崩了。平均值把這種“偶爾的暴雷”給抹平了，而你實際感受到的，恰恰是那些暴雷的瞬間。

延遲本身也得拆成兩個指標(biāo)看：

• TTFT（首 Token 延遲）：從發(fā)出請求到蹦出第一個字的時間，決定“跟不跟手”。流式輸出下，curl 的 time_starttransfer 就約等于它。
• TPS（吞吐，tokens/秒）：決定長輸出要等多久，重構(gòu)整個文件、生成大段代碼時它才是瓶頸。

我用同一個 prompt、同樣的流式請求，把藍(lán)耘的 DeepSeek-V3.2 和另一家大廠的同款 DeepSeek-V3.2 各連打五次（蘋果對蘋果，同一個模型，只是平臺不同）：

for i in 1 2 3 4 5; do
  curl -sS -N -o /dev/null \
    -w "#$i TTFT: %{time_starttransfer}s | 總耗時: %{time_total}s\n" \
    "$LY_BASE/chat/completions" \
    -H "Authorization: Bearer $LY_KEY" -H "Content-Type: application/json" \
    -d "{\"model\":\"$LY_MODEL\",\"stream\":true,\"messages\":[{\"role\":\"user\",\"content\":\"用三句話解釋什么是KV Cache\"}]}"
done

數(shù)據(jù)擺出來，自己看：

藍(lán)耘這邊，五次 TTFT 全部壓在 174~194 毫秒，窗口窄到 20 毫秒，穩(wěn)得像一條直線。某大廠那邊，從 0.6 秒到 2.0 秒來回跳，波動幅度是藍(lán)耘的十幾倍。

這里的關(guān)鍵不是“藍(lán)耘更快”這句大白話——快慢受網(wǎng)絡(luò)、時段影響，不同人測未必一樣。真正值錢的結(jié)論是：藍(lán)耘這條鏈路的延遲方差極小。 對 Agent 來說，一個穩(wěn)定的 200 毫秒，比一個“平均 800 毫秒但偶爾飆到 2 秒”的鏈路，體驗上是碾壓級的差距。這就是“延遲看尾部”的實際含義。

測的時候注意一個口徑問題：如果你測的是 DeepSeek-R1 這類帶思維鏈的推理模型，TTFT 會天然偏高——因為它要先“想”一大段再吐字，這是模型特性，不是平臺慢。想量平臺鏈路本身的延遲，就用 V3.2 這種普通對話模型，別拿 R1 的數(shù)去黑平臺，那不公平。

五、第三關(guān)：緩存——這是我上次月賬單暴漲的真兇

到這兒才是我這篇文章最想講的東西，也是我上次“越換越貴”的謎底。

Claude Code 這類 Agent 有個特點：每一輪對話，它都會把一大坨東西重新發(fā)一遍——系統(tǒng)提示詞、工具定義、你項目里的文件上下文……動輒幾千上萬 token。你以為你只問了一句“改下這個函數(shù)”，實際發(fā)出去的 input 大得嚇人，而且每輪都發(fā)。

官方 Anthropic 是支持提示詞緩存（Prompt Caching）的：相同的前綴，第一次請求寫進(jìn)緩存，后面命中的部分只按大約十分之一計價。如果你換的那家第三方 API 不支持緩存，那你每一輪都在按全額 input 付費——成本翻個五到十倍輕輕松松。 我上次就是栽在這：圖便宜換了家不支持緩存的，單價是低了，但緩存沒了，總賬單反而漲上去了。

所以選平臺，緩存支持與否，對 Agent 場景是決定性的。光看單價那個“元/百萬 token”根本不夠，得看它算不算緩存價。

我怎么驗的呢？造一個大的 system 上下文（約 6000 token），然后用完全一樣的請求連發(fā)兩次——注意，是一字不差，因為緩存靠前綴匹配，你改一個字都可能讓它不命中：

# 造一個約 6000 token 的大 system 上下文
BIG=$(python3 -c "print('你是一個資深工程師。以下是項目規(guī)范:'+ '規(guī)則條目。'*2000)")
# 連發(fā)兩次完全相同的請求,盯 cached_tokens 的變化
for round in 1 2; do
  echo "=== 第 $round 次 ==="
  curl -sS "$LY_BASE/chat/completions" \
    -H "Authorization: Bearer $LY_KEY" -H "Content-Type: application/json" \
    -d "$(jq -n --arg m "$LY_MODEL" --arg s "$BIG" \
        '{model:$m,messages:[{role:"system",content:$s},{role:"user",content:"回復(fù)ok"}]}')" \
    | jq '.usage.prompt_tokens, .usage.prompt_tokens_details.cached_tokens'
  sleep 2
done

結(jié)果非常干凈：

第二次請求，6015 個 input token 里有 5888 個命中了緩存，命中率 97.9%。

翻譯成人話：在 Claude Code 那種“每輪重發(fā)大 prompt”的場景里，從第二輪開始，你的輸入成本里近 98% 的部分都能走緩存價。DeepSeek-V3.2 在藍(lán)耘上的定價是輸入 2 元/百萬 token，而據(jù) AI Ping 的數(shù)據(jù)（下一節(jié)），藍(lán)耘的緩存命中價只要 0.40 元/百萬 token——也就是原價的兩成。

算一筆賬你就懂差距了。假設(shè)一個任務(wù)跑 20 輪，每輪重發(fā) 6000 token 的上下文：

• 不走緩存：20 × 6000 × 2元/M = 約 0.24 元
• 走緩存（第二輪起命中）：首輪全價，后續(xù)按 0.4 元/M ≈ 約 0.05 元

同一個任務(wù)，光輸入這塊就差了將近 5 倍。 我上次賬單暴漲的謎，到這兒徹底解開了——不是模型貴，是我把緩存這個最大的省錢杠桿給弄丟了。

六、第四關(guān)：接入 Claude Code——協(xié)議對不對，決定你省不省心

前面說藍(lán)耘同時給了 OpenAI 和 Anthropic 兩套端點，這一節(jié)講為什么這件事重要。

Claude Code 說的是 Anthropic 的方言（/v1/messages，認(rèn)證用 x-api-key）。而 DeepSeek 原生 API 說的是 OpenAI 的方言（/v1/chat/completions，認(rèn)證用 Bearer）。兩者不通。

所以接 Claude Code，你有兩條路：

• 路 A：平臺只有 OpenAI 端點。那你得自己掛一個 claude-code-router 或 LiteLLM 在中間做協(xié)議翻譯。能用，但多一層進(jìn)程、多一個故障點、多一份延遲，還多一堆配置。
• 路 B：平臺直接提供 Anthropic 兼容端點。那就是填幾個環(huán)境變量的事，零翻譯層。

藍(lán)耘給了 Anthropic 端點（https://maas-api.lanyun.net/anthropic），所以我走的是路 B，直連：

export ANTHROPIC_BASE_URL="https://maas-api.lanyun.net/anthropic"
export ANTHROPIC_AUTH_TOKEN="你的藍(lán)耘Key"
export ANTHROPIC_MODEL="qwen3.6-flash"   # 也可換成 /maas/deepseek-ai/DeepSeek-V3.2
claude

這里插一句關(guān)于“多模聚合”的實感：因為是統(tǒng)一網(wǎng)關(guān)，我想從 DeepSeek 換成通義的 qwen3.6-flash（藍(lán)耘模型廣場里主打 agentic coding 的那個），就是改一行 ANTHROPIC_MODEL 的事，Claude Code 那頭完全無感。選型階段能這么低成本地橫向切模型試，這個價值比宣傳頁上“多模聚合”四個字實在多了。

一個必須提醒的坑：ANTHROPIC_BASE_URL 填到 /anthropic 這一層就行，后面的 /v1/messages 是 Claude Code 自己補(bǔ)的，你別畫蛇添足寫全，寫全了反而 404。

但是——能聊天，不等于能干活。 這是我要講的“Agent 看工具調(diào)用”。

Claude Code 的本質(zhì)是個 Agent，它靠的是穩(wěn)定、格式正確地發(fā)起工具調(diào)用（tool_use）：讀文件、寫文件、跑命令。很多“OpenAI 兼容”的網(wǎng)關(guān)，普通對話跑得好好的，一到 function calling 就靜默降級——非 Claude 原生的模型（比如 DeepSeek、Qwen）偶爾會把工具調(diào)用的格式吐歪，Claude Code 直接報錯中斷。所以驗證接入成不成功，絕不能只問一句“你好”看它回不回，必須讓它做一件真正需要動文件的活：

在當(dāng)前目錄創(chuàng)建 demo.py,寫一個計算斐波那契第 30 項的函數(shù)并打印;
然后運(yùn)行它,把輸出讀回來確認(rèn)結(jié)果是 832040。

盯著看它有沒有依次觸發(fā) Write（寫文件）→ Bash（執(zhí)行）→ Read（讀回結(jié)果） 這條完整的工具鏈。跑通了，才叫真的接上了。

順帶說一句方法論：這一步無論成功失敗都有價值。跑通，說明這條鏈路對 tool_use 支持良好；萬一報錯卡住，那也不是白測——它恰好印證了“工具調(diào)用保真度是選型必測項”這個判斷。真實的失敗，比虛假的成功有用得多。

七、第五關(guān)：交叉驗證——把自測的數(shù)，拿去和第三方榜單對一遍

到這我其實已經(jīng)挺滿意了，但一個習(xí)慣讓我沒停手：自己測的數(shù)，一定要找個獨立信源對一遍，不然容易自我感覺良好。

我用的是 AI Ping（aiping.cn），它對各家平臺的同款模型做標(biāo)準(zhǔn)化壓測。我把藍(lán)耘的 DeepSeek-V3.2 那一行拉出來看（數(shù)據(jù)為 7 月中旬截圖，以實時榜單為準(zhǔn)）：

這里我必須誠實地說一個反直覺的事，因為藏著的話，這篇文章就不值得信了：

AI Ping 上藍(lán)耘的吞吐是 20.18 tokens/s、延遲 4.33s，在這張榜單里都屬于偏低的。 跟我自己 curl 測出來的 180 毫秒，差了二十多倍。

這個矛盾怎么解釋？我想了一下，原因是幾個測法上的差異，都合理：

1. prompt 長度和負(fù)載不同。我 curl 用的是“用三句話解釋 KV Cache”這種極短 prompt、輕負(fù)載；AI Ping 用的是標(biāo)準(zhǔn)化的較長 prompt、固定并發(fā)壓測。短 prompt 輕負(fù)載當(dāng)然快，這不是誰作弊，是量的東西本來就不一樣。
2. 網(wǎng)絡(luò)路徑不同。我從本地直連，AI Ping 從它自己的探測節(jié)點打，鏈路不一樣。
3. 有沒有吃緩存。我重復(fù)請求容易命中緩存，AI Ping 每次大概率是冷啟動。

所以看待延遲這事兒，得認(rèn)清：沒有一個“絕對的延遲數(shù)字”，只有“在特定測法下的延遲”。 我的 180ms 和 AI Ping 的 4.33s 都是真的，只是回答的是不同的問題。

那藍(lán)耘的真正價值在哪？恰恰不在裸吞吐。 看 AI Ping 這張表里藍(lán)耘那些不顯眼但要命的指標(biāo)：

對 Claude Code 這種“每輪重發(fā)大 prompt、經(jīng)常要吐長文件”的 Agent 場景，可靠性 100%、最大輸出 128k、緩存價兩折這三樣，比裸吞吐值錢得多。我要的不是跑分榜第一，我要的是它別在我寫代碼寫到一半的時候抽風(fēng)、別把我的長輸出截斷、別讓我為重復(fù)上下文反復(fù)付全價。這三點它都穩(wěn)穩(wěn)做到了。

這也是我實測完緩存命中率 97.9% 之后，決定把 side project 長期落在藍(lán)耘的真實原因——不是它某個單項最亮眼，是它在我真正在乎的維度上都不掉鏈子，還便宜。

八、把這半天的教訓(xùn)，壓縮成一張選型清單

如果你也要給自己的項目挑第三方大模型 API，別只盯著單價。照著下面這張表打勾，能幫你避開我踩過的坑：

工程層——決定能不能用

• 延遲看 p95/p99 尾部，別信平均值；流式下 time_starttransfer 約等于 TTFT
• 用真實工具調(diào)用任務(wù)驗 tool_use（讀寫文件），不是問一句“你好”就算接上了
• 確認(rèn)協(xié)議：有 Anthropic 端點就直連，只有 OpenAI 端點就得掛翻譯層
• 看可靠性 / 有沒有智能路由做故障轉(zhuǎn)移——Agent 發(fā)幾十次請求，1% 錯誤率就夠你崩

成本層——決定貴不貴

• 支不支持提示詞緩存，以及緩存命中怎么計價（這是 Agent 場景最大的省錢杠桿）
• 計價粒度透不透明，有沒有用量看板 / 調(diào)用日志能對賬
• 標(biāo)稱上下文 vs 真實可用的最大輸出，別被“128k 上下文但輸出砍到 4k”坑了

長期層——決定敢不敢一直用

• 模型版本能不能鎖定，別今天滿血明天偷偷換量化版
• 數(shù)據(jù)合規(guī)：你的代碼 prompt 會不會被拿去訓(xùn)練、日志留多久

我自己這輪測下來，藍(lán)耘 MaaS 在“Anthropic 直連、緩存命中 97.9%、可靠性 100%、延遲方差極小”這幾條上是實打?qū)嵾^關(guān)的，截圖和數(shù)據(jù)都在上面，你可以自己復(fù)現(xiàn)。它不是每一項都第一，但在我這個“自費跑 Agent”的場景里，它把我真正在乎的都做對了。

結(jié)尾

回到開頭那個讓我肉疼的賬單。上次換便宜 API 越換越貴，不是因為我運(yùn)氣差，是因為我壓根沒搞懂該看什么——我只看了單價那一個數(shù)字，漏掉了緩存這個真正決定 Agent 成本的杠桿。

這半天測下來，我最大的收獲不是“藍(lán)耘好用”這個結(jié)論，而是那三句話：

延遲看尾部，成本看緩存，Agent 看工具調(diào)用。

下次再有人問我“接第三方 API 是不是填個 base_url 就行”，我會把這篇甩給他。填 URL 誰都會，但選之前先把這幾個數(shù)測一遍，能省下的可能就是你下個月的賬單。

到此這篇關(guān)于Claude Code 接藍(lán)耘實測：選第三方 API 的三條鐵律(最新整理)的文章就介紹到這了,更多相關(guān)Claude Code 接藍(lán)耘內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持腳本之家！