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

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

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

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

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

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

不繞彎子。我選平臺(tái)時(shí)腦子里過的是這么幾件事，按重要性排：

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

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

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

二、拿 Key：三個(gè)必須記下來的東西

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

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

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

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

控制臺(tái)每個(gè)模型點(diǎn)進(jìn)去都有 API 示例，照著抄不會(huì)錯(cuò)：

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

任何新 API 到手，我第一件事永遠(yuǎn)是發(fā)一個(gè)最小請(qǐng)求，確認(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ù)兩個(gè)字:通了\"}]}" | jq .

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

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

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

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

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

這是全篇我最想掰扯清楚的一點(diǎn)。

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

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

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

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

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

for i in 1 2 3 4 5; do
  curl -sS -N -o /dev/null \
    -w "#$i TTFT: %{time_starttransfer}s | 總耗時(shí): %{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 秒來回跳，波動(dòng)幅度是藍(lán)耘的十幾倍。

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

測的時(shí)候注意一個(gè)口徑問題：如果你測的是 DeepSeek-R1 這類帶思維鏈的推理模型，TTFT 會(huì)天然偏高——因?yàn)樗?ldquo;想”一大段再吐字，這是模型特性，不是平臺(tái)慢。想量平臺(tái)鏈路本身的延遲，就用 V3.2 這種普通對(duì)話模型，別拿 R1 的數(shù)去黑平臺(tái)，那不公平。

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

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

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

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

所以選平臺(tái)，緩存支持與否，對(duì) Agent 場景是決定性的。光看單價(jià)那個(gè)“元/百萬 token”根本不夠，得看它算不算緩存價(jià)。

我怎么驗(yàn)的呢？造一個(gè)大的 system 上下文（約 6000 token），然后用完全一樣的請(qǐng)求連發(fā)兩次——注意，是一字不差，因?yàn)榫彺婵壳熬Y匹配，你改一個(gè)字都可能讓它不命中：

# 造一個(gè)約 6000 token 的大 system 上下文
BIG=$(python3 -c "print('你是一個(gè)資深工程師。以下是項(xiàng)目規(guī)范:'+ '規(guī)則條目。'*2000)")
# 連發(fā)兩次完全相同的請(qǐng)求,盯 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é)果非常干凈：

第二次請(qǐng)求，6015 個(gè) input token 里有 5888 個(gè)命中了緩存，命中率 97.9%。

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

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

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

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

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

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

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

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

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

藍(lán)耘給了 Anthropic 端點(diǎn)（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)于“多模聚合”的實(shí)感：因?yàn)槭墙y(tǒng)一網(wǎng)關(guān)，我想從 DeepSeek 換成通義的 qwen3.6-flash（藍(lán)耘模型廣場里主打 agentic coding 的那個(gè)），就是改一行 ANTHROPIC_MODEL 的事，Claude Code 那頭完全無感。選型階段能這么低成本地橫向切模型試，這個(gè)價(jià)值比宣傳頁上“多模聚合”四個(gè)字實(shí)在多了。

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

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

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

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

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

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

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

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

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

這里我必須誠實(shí)地說一個(gè)反直覺的事，因?yàn)椴刂脑?，這篇文章就不值得信了：

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

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

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é)點(diǎn)打，鏈路不一樣。
3. 有沒有吃緩存。我重復(fù)請(qǐng)求容易命中緩存，AI Ping 每次大概率是冷啟動(dòng)。

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

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

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

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

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

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

工程層——決定能不能用

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

成本層——決定貴不貴

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

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

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

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

結(jié)尾

回到開頭那個(gè)讓我肉疼的賬單。上次換便宜 API 越換越貴，不是因?yàn)槲疫\(yùn)氣差，是因?yàn)槲覊焊鶝]搞懂該看什么——我只看了單價(jià)那一個(gè)數(shù)字，漏掉了緩存這個(gè)真正決定 Agent 成本的杠桿。

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

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

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

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