 Claude Code 和 Codex 等 Agent CLI 的自動重試：把 endpoint 改到 TaoToken)
1. 長任務(wù)跑到一半斷掉Agent CLI 的重試到底難在哪如果你用 Claude Code 或 Codex 跑過一個稍微長點的任務(wù)大概率見過這種場面前面十幾輪工具調(diào)用都正常突然某一步卡住終端里蹦出一行 429 或者stream disconnected然后整個會話就停在那里既不報錯退出也不繼續(xù)往下走。你只能手動敲一句「繼續(xù)」運氣好它能接著跑運氣不好上下文已經(jīng)丟了得從頭再來。這類問題的核心不是「請求失敗了要不要重發(fā)」而是「流式執(zhí)行到一半前面吐出來的內(nèi)容還算不算數(shù)」。普通 HTTP 請求失敗重發(fā)一次就行冪等的話甚至無感。但 Agent CLI 不一樣它一邊流式輸出一邊綁定 thread、session 或 resume token工具調(diào)用的生命周期和上下文是耦合的。你重試的時候得先回答三個問題——這次失敗值不值得重試、當(dāng)前上下文還能不能續(xù)、續(xù)的時候發(fā)什么內(nèi)容。我實測下來很多團隊第一版都會寫成「報錯就再試一次」然后立刻踩坑認(rèn)證失敗被反復(fù)重放、沒有 thread 的請求和有 thread 的請求被一視同仁、退避沒邊界把后臺打爆。所以自動重試不是加個try/catch而是一套分層設(shè)計共享協(xié)調(diào)器管重試循環(huán)Provider 只回答「這個終態(tài)可不可重試」和「上下文還在不在」。這篇就以 Claude Code 和 Codex 為例把 endpoint 指向 TaoToken 統(tǒng)一通道交付可復(fù)制的重試配置片段再給你一套用連續(xù)請求驗證重試是否真的生效的檢查動作。適合正在把 Agent CLI 接進自己工作流、被 429 和超時折磨過的開發(fā)者。2. 前置準(zhǔn)備把 endpoint 統(tǒng)一到 TaoToken 通道在寫重試邏輯之前先把「請求打到哪」這件事定下來。Agent CLI 默認(rèn)會連各自的官方 endpoint一旦網(wǎng)絡(luò)抖動或者上游限流你很難區(qū)分是本地網(wǎng)絡(luò)問題還是上游問題。把 endpoint 統(tǒng)一指向 TaoToken 的 API 通道好處是入口收斂、Key 統(tǒng)一管理、模型 ID 集中配置重試策略也只需要在一個地方調(diào)。TaoToken 的 API 地址是https://taotoken.net/api官網(wǎng)入口在https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。你需要先在控制臺創(chuàng)建一個 API Key路徑是https://taotoken.net/consoleKey 管理在https://taotoken.net/api-keys。模型對話調(diào)試頁在https://taotoken.net/models接入文檔在https://taotoken.net/doc。這里有個關(guān)鍵點Agent CLI 的重試要生效Base URL、Key、Model ID 三件套必須寫全缺一個都會在重試時暴露成 401 或者 model not found。我見過有人只改了 Base URLKey 還是舊的結(jié)果第一次請求就 401重試邏輯根本沒機會觸發(fā)。Claude Code 側(cè)的配置通常寫在~/.claude/settings.json或者項目級的.claude/settings.json里。Codex 側(cè)則看~/.codex/auth.json和對應(yīng)的 config。如果你用 CC Switch 這類工具切換 Provider配置會落在它自己的 profile 里但底層還是這三件套。先把通道打通再談重試。順序反了的話你會把「配置錯誤」誤判成「需要重試的臨時故障」越試越亂。下面一節(jié)直接給可復(fù)制的配置片段。3. 可復(fù)制配置Claude Code 與 Codex 的 endpoint 與重試參數(shù)先給 Claude Code 的settings.json片段。路徑按你實際使用的來全局是~/.claude/settings.json項目級是project/.claude/settings.json。注意env里的三個字段要和 TaoToken 控制臺里的一致{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: sk-你的TaoTokenKey, ANTHROPIC_MODEL: claude-sonnet-4-5 }, retry: { enabled: true, maxAttempts: 3, backoffMs: [10000, 20000, 60000], retryOn: [429, timeout, stream_disconnected] } }Codex 側(cè)走~/.codex/auth.json把 provider 指向同一個通道。注意base_url結(jié)尾不要多加/v1否則會拼成/api/v1/v1{ OPENAI_API_KEY: sk-你的TaoTokenKey, OPENAI_BASE_URL: https://taotoken.net/api, model: gpt-5-codex, provider: { name: taotoken, base_url: https://taotoken.net/api, wire_api: responses } }如果你用 CC Switch 管理多套配置profile 里同樣要落這三件套。CC Switch 的 profile 本質(zhì)是一份可切換的 settings切換時它會覆蓋ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN。所以你在 profile 里寫的是[profile.taotoken] base_url https://taotoken.net/api api_key sk-你的TaoTokenKey model claude-sonnet-4-5 retry_max_attempts 3 retry_backoff_seconds [10, 20, 60]退避節(jié)奏我建議就用 10 秒、20 秒、60 秒這個梯度。第一檔短一點快速吃掉網(wǎng)絡(luò)抖動第二檔拉開避開上游瞬時壓力第三檔給足時間讓上游恢復(fù)。三檔之后還不成功就該承認(rèn)這次真不行了把最終失敗透傳給上層而不是無限重放。還有一個容易忽略的點continuation prompt 要統(tǒng)一。第二輪開始不要再發(fā)原始 prompt而是發(fā)一句固定的「繼續(xù)當(dāng)前上下文」指令讓 Provider 明確走續(xù)跑路徑。否則你會看到重復(fù)文本、工具調(diào)用錯亂。這個在配置里體現(xiàn)為一個continuation_prompt字段值可以寫成Continue from where you left off.。配置寫完先別急著跑長任務(wù)用下一節(jié)的連續(xù)請求驗證一下重試到底有沒有生效。4. 驗證請求用連續(xù)請求確認(rèn)重試真的觸發(fā)了驗證重試是否生效不能靠「跑一個長任務(wù)看它斷不斷」那樣變量太多。更靠譜的做法是構(gòu)造可控的連續(xù)請求觀察退避間隔和最終態(tài)。第一步先用一個最簡單的請求確認(rèn)通道是通的。Claude Code 側(cè)可以直接在終端里發(fā)一條短 prompt看它是否正常返回。如果這一步就 401說明 Key 或 Base URL 有問題先回去查配置別往下走。第二步構(gòu)造一個會觸發(fā) 429 的場景。最直接的辦法是短時間內(nèi)連續(xù)發(fā)多個請求把速率頂上去。你可以寫一個小腳本循環(huán)調(diào)用觀察日志里是否出現(xiàn)「attempt 1 failed, retrying in 10s」這類記錄。如果重試邏輯生效你會看到請求沒有立刻失敗而是按 10 秒、20 秒、60 秒的節(jié)奏重試。第三步檢查最終態(tài)。重試預(yù)算耗盡后上層應(yīng)該收到一個明確的失敗消息而不是一堆半途而廢的中間噪音。你可以用curl直接打 TaoToken 的 API 做對照curl -sS https://taotoken.net/api/v1/messages \ -H Authorization: Bearer sk-你的TaoTokenKey \ -H Content-Type: application/json \ -d {model:claude-sonnet-4-5,max_tokens:64,messages:[{role:user,content:ping}]}如果這條 curl 正常返回說明通道沒問題問題在 CLI 的重試配置。如果 curl 也失敗先解決通道問題。第四步驗證上下文續(xù)跑。這一步最關(guān)鍵。你需要在一次會中斷的流式請求里確認(rèn)第二輪 attempt 發(fā)的是 continuation prompt 而不是原始 prompt?？梢栽谌罩纠锼裞ontinuation關(guān)鍵字或者臨時把 continuation prompt 改成一個顯眼的標(biāo)記看它有沒有出現(xiàn)在第二輪請求里。我試過用這種方式排查發(fā)現(xiàn)過一個坑Codex 的某類 reconnect 報文沒有被識別成可重試終態(tài)結(jié)果恢復(fù)機制根本沒機會觸發(fā)。表面看是「沒有自動重試」實際是「沒把這次值得重試認(rèn)出來」。所以驗證的時候一定要確認(rèn)終態(tài)判定這一層是對的。驗證通過后再跑長任務(wù)心里就有底了。5. 常見報錯排查401、local proxy failed 與 reading choices接入和重試過程中有幾類報錯特別高頻這里逐個對照。401 Unauthorized九成是 Key 寫錯或者沒帶上。檢查ANTHROPIC_AUTH_TOKEN和OPENAI_API_KEY是否和 TaoToken 控制臺里的一致注意別把 Key 前后的空格帶進去。還有一種情況是 Base URL 寫成了https://taotoken.net/api/帶尾斜杠某些客戶端會拼出雙斜杠導(dǎo)致鑒權(quán)失敗。改成不帶尾斜杠即可。local proxy failed這個通常出現(xiàn)在你本地掛了某些轉(zhuǎn)發(fā)工具或者 CC Switch 的 profile 切換后舊進程沒重啟。先確認(rèn)沒有多余的本地轉(zhuǎn)發(fā)在跑然后重啟 CLI。如果用的是 CC Switch切換 profile 后要確保新配置被重新加載而不是沿用舊的環(huán)境變量。reading choices 相關(guān)報錯這類多半是響應(yīng)體解析失敗常見于流式返回被中途截斷或者 wire_api 選錯了。Codex 側(cè)要確認(rèn)wire_api是responsesClaude Code 側(cè)確認(rèn)走的是 messages 接口。如果響應(yīng)格式對不上重試再多次也沒用因為每次都會在解析階段掛掉。OAuth 相關(guān)報錯如果你之前登錄過官方賬號本地可能殘留了 OAuth tokenCLI 會優(yōu)先用它而不是你的 API Key。這時候要清理掉舊的憑證緩存強制走 API Key 路徑。具體位置看 CLI 的文檔一般在用戶目錄下的隱藏文件夾里。重試不觸發(fā)如果確認(rèn)有 429 或超時但日志里看不到重試記錄先檢查retry.enabled是不是 true再看retryOn列表里有沒有包含實際發(fā)生的錯誤類型。有些客戶端的錯誤類型字符串和你想的不一樣比如實際是stream_error而你寫的是stream_disconnected那就匹配不上。排查順序建議是先 curl 確認(rèn)通道再確認(rèn)三件套再看重試配置最后看終態(tài)判定。一層層往下別跳步。6. 把重試做成共享能力而不是每個 Provider 重寫一遍走到這里你應(yīng)該已經(jīng)能把 Claude Code 和 Codex 的 endpoint 指向 TaoToken并且用連續(xù)請求驗證重試生效了。但如果你同時接多個 Agent CLI很快會發(fā)現(xiàn)一個問題每個 Provider 都寫一套重試狀態(tài)機維護成本會爆炸。更穩(wěn)的做法是把重試提煉成共享層。共享協(xié)調(diào)器管重試循環(huán)、退避節(jié)奏、continuation promptProvider 只回答兩個問題——這個終態(tài)值不值得重試、當(dāng)前上下文還能不能續(xù)。Codex 看 thread 還在不在Claude Code 看 continuation target 還在不在。退避策略和重試次數(shù)不該讓每個 Provider 重新發(fā)明。策略最好做成 snapshot跟著請求一起走而不是依賴某個「此刻的全局配置」。這樣會話排隊、消息持久化、執(zhí)行轉(zhuǎn)發(fā)都不會把策略弄丟。業(yè)務(wù)層決定「該不該重試」運行時決定「怎么重試」兩邊各管一攤。如果你需要長期跑編碼任務(wù)或者 Agent 工作流可以考慮用 Coding Plan入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite。模型對話調(diào)試在https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite接入文檔在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteKey 管理在https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite。最后留一個實用技巧重試預(yù)算一定要有邊界三檔退避之后就該停手。無限重試不是恢復(fù)機制是事故放大器。把邊界守住比把重試次數(shù)調(diào)大更重要。 如何實現(xiàn) Claude Code 和 Codex 等 Agent CLI 的自動重試：把 endpoint 改到 TaoToken
1. 長任務(wù)跑到一半斷掉Agent CLI 的重試到底難在哪如果你用 Claude Code 或 Codex 跑過一個稍微長點的任務(wù)大概率見過這種場面前面十幾輪工具調(diào)用都正常突然某一步卡住終端里蹦出一行 429 或者stream disconnected然后整個會話就停在那里既不報錯退出也不繼續(xù)往下走。你只能手動敲一句「繼續(xù)」運氣好它能接著跑運氣不好上下文已經(jīng)丟了得從頭再來。這類問題的核心不是「請求失敗了要不要重發(fā)」而是「流式執(zhí)行到一半前面吐出來的內(nèi)容還算不算數(shù)」。普通 HTTP 請求失敗重發(fā)一次就行冪等的話甚至無感。但 Agent CLI 不一樣它一邊流式輸出一邊綁定 thread、session 或 resume token工具調(diào)用的生命周期和上下文是耦合的。你重試的時候得先回答三個問題——這次失敗值不值得重試、當(dāng)前上下文還能不能續(xù)、續(xù)的時候發(fā)什么內(nèi)容。我實測下來很多團隊第一版都會寫成「報錯就再試一次」然后立刻踩坑認(rèn)證失敗被反復(fù)重放、沒有 thread 的請求和有 thread 的請求被一視同仁、退避沒邊界把后臺打爆。所以自動重試不是加個try/catch而是一套分層設(shè)計共享協(xié)調(diào)器管重試循環(huán)Provider 只回答「這個終態(tài)可不可重試」和「上下文還在不在」。這篇就以 Claude Code 和 Codex 為例把 endpoint 指向 TaoToken 統(tǒng)一通道交付可復(fù)制的重試配置片段再給你一套用連續(xù)請求驗證重試是否真的生效的檢查動作。適合正在把 Agent CLI 接進自己工作流、被 429 和超時折磨過的開發(fā)者。2. 前置準(zhǔn)備把 endpoint 統(tǒng)一到 TaoToken 通道在寫重試邏輯之前先把「請求打到哪」這件事定下來。Agent CLI 默認(rèn)會連各自的官方 endpoint一旦網(wǎng)絡(luò)抖動或者上游限流你很難區(qū)分是本地網(wǎng)絡(luò)問題還是上游問題。把 endpoint 統(tǒng)一指向 TaoToken 的 API 通道好處是入口收斂、Key 統(tǒng)一管理、模型 ID 集中配置重試策略也只需要在一個地方調(diào)。TaoToken 的 API 地址是https://taotoken.net/api官網(wǎng)入口在https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。你需要先在控制臺創(chuàng)建一個 API Key路徑是https://taotoken.net/consoleKey 管理在https://taotoken.net/api-keys。模型對話調(diào)試頁在https://taotoken.net/models接入文檔在https://taotoken.net/doc。這里有個關(guān)鍵點Agent CLI 的重試要生效Base URL、Key、Model ID 三件套必須寫全缺一個都會在重試時暴露成 401 或者 model not found。我見過有人只改了 Base URLKey 還是舊的結(jié)果第一次請求就 401重試邏輯根本沒機會觸發(fā)。Claude Code 側(cè)的配置通常寫在~/.claude/settings.json或者項目級的.claude/settings.json里。Codex 側(cè)則看~/.codex/auth.json和對應(yīng)的 config。如果你用 CC Switch 這類工具切換 Provider配置會落在它自己的 profile 里但底層還是這三件套。先把通道打通再談重試。順序反了的話你會把「配置錯誤」誤判成「需要重試的臨時故障」越試越亂。下面一節(jié)直接給可復(fù)制的配置片段。3. 可復(fù)制配置Claude Code 與 Codex 的 endpoint 與重試參數(shù)先給 Claude Code 的settings.json片段。路徑按你實際使用的來全局是~/.claude/settings.json項目級是project/.claude/settings.json。注意env里的三個字段要和 TaoToken 控制臺里的一致{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: sk-你的TaoTokenKey, ANTHROPIC_MODEL: claude-sonnet-4-5 }, retry: { enabled: true, maxAttempts: 3, backoffMs: [10000, 20000, 60000], retryOn: [429, timeout, stream_disconnected] } }Codex 側(cè)走~/.codex/auth.json把 provider 指向同一個通道。注意base_url結(jié)尾不要多加/v1否則會拼成/api/v1/v1{ OPENAI_API_KEY: sk-你的TaoTokenKey, OPENAI_BASE_URL: https://taotoken.net/api, model: gpt-5-codex, provider: { name: taotoken, base_url: https://taotoken.net/api, wire_api: responses } }如果你用 CC Switch 管理多套配置profile 里同樣要落這三件套。CC Switch 的 profile 本質(zhì)是一份可切換的 settings切換時它會覆蓋ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN。所以你在 profile 里寫的是[profile.taotoken] base_url https://taotoken.net/api api_key sk-你的TaoTokenKey model claude-sonnet-4-5 retry_max_attempts 3 retry_backoff_seconds [10, 20, 60]退避節(jié)奏我建議就用 10 秒、20 秒、60 秒這個梯度。第一檔短一點快速吃掉網(wǎng)絡(luò)抖動第二檔拉開避開上游瞬時壓力第三檔給足時間讓上游恢復(fù)。三檔之后還不成功就該承認(rèn)這次真不行了把最終失敗透傳給上層而不是無限重放。還有一個容易忽略的點continuation prompt 要統(tǒng)一。第二輪開始不要再發(fā)原始 prompt而是發(fā)一句固定的「繼續(xù)當(dāng)前上下文」指令讓 Provider 明確走續(xù)跑路徑。否則你會看到重復(fù)文本、工具調(diào)用錯亂。這個在配置里體現(xiàn)為一個continuation_prompt字段值可以寫成Continue from where you left off.。配置寫完先別急著跑長任務(wù)用下一節(jié)的連續(xù)請求驗證一下重試到底有沒有生效。4. 驗證請求用連續(xù)請求確認(rèn)重試真的觸發(fā)了驗證重試是否生效不能靠「跑一個長任務(wù)看它斷不斷」那樣變量太多。更靠譜的做法是構(gòu)造可控的連續(xù)請求觀察退避間隔和最終態(tài)。第一步先用一個最簡單的請求確認(rèn)通道是通的。Claude Code 側(cè)可以直接在終端里發(fā)一條短 prompt看它是否正常返回。如果這一步就 401說明 Key 或 Base URL 有問題先回去查配置別往下走。第二步構(gòu)造一個會觸發(fā) 429 的場景。最直接的辦法是短時間內(nèi)連續(xù)發(fā)多個請求把速率頂上去。你可以寫一個小腳本循環(huán)調(diào)用觀察日志里是否出現(xiàn)「attempt 1 failed, retrying in 10s」這類記錄。如果重試邏輯生效你會看到請求沒有立刻失敗而是按 10 秒、20 秒、60 秒的節(jié)奏重試。第三步檢查最終態(tài)。重試預(yù)算耗盡后上層應(yīng)該收到一個明確的失敗消息而不是一堆半途而廢的中間噪音。你可以用curl直接打 TaoToken 的 API 做對照curl -sS https://taotoken.net/api/v1/messages \ -H Authorization: Bearer sk-你的TaoTokenKey \ -H Content-Type: application/json \ -d {model:claude-sonnet-4-5,max_tokens:64,messages:[{role:user,content:ping}]}如果這條 curl 正常返回說明通道沒問題問題在 CLI 的重試配置。如果 curl 也失敗先解決通道問題。第四步驗證上下文續(xù)跑。這一步最關(guān)鍵。你需要在一次會中斷的流式請求里確認(rèn)第二輪 attempt 發(fā)的是 continuation prompt 而不是原始 prompt?？梢栽谌罩纠锼裞ontinuation關(guān)鍵字或者臨時把 continuation prompt 改成一個顯眼的標(biāo)記看它有沒有出現(xiàn)在第二輪請求里。我試過用這種方式排查發(fā)現(xiàn)過一個坑Codex 的某類 reconnect 報文沒有被識別成可重試終態(tài)結(jié)果恢復(fù)機制根本沒機會觸發(fā)。表面看是「沒有自動重試」實際是「沒把這次值得重試認(rèn)出來」。所以驗證的時候一定要確認(rèn)終態(tài)判定這一層是對的。驗證通過后再跑長任務(wù)心里就有底了。5. 常見報錯排查401、local proxy failed 與 reading choices接入和重試過程中有幾類報錯特別高頻這里逐個對照。401 Unauthorized九成是 Key 寫錯或者沒帶上。檢查ANTHROPIC_AUTH_TOKEN和OPENAI_API_KEY是否和 TaoToken 控制臺里的一致注意別把 Key 前后的空格帶進去。還有一種情況是 Base URL 寫成了https://taotoken.net/api/帶尾斜杠某些客戶端會拼出雙斜杠導(dǎo)致鑒權(quán)失敗。改成不帶尾斜杠即可。local proxy failed這個通常出現(xiàn)在你本地掛了某些轉(zhuǎn)發(fā)工具或者 CC Switch 的 profile 切換后舊進程沒重啟。先確認(rèn)沒有多余的本地轉(zhuǎn)發(fā)在跑然后重啟 CLI。如果用的是 CC Switch切換 profile 后要確保新配置被重新加載而不是沿用舊的環(huán)境變量。reading choices 相關(guān)報錯這類多半是響應(yīng)體解析失敗常見于流式返回被中途截斷或者 wire_api 選錯了。Codex 側(cè)要確認(rèn)wire_api是responsesClaude Code 側(cè)確認(rèn)走的是 messages 接口。如果響應(yīng)格式對不上重試再多次也沒用因為每次都會在解析階段掛掉。OAuth 相關(guān)報錯如果你之前登錄過官方賬號本地可能殘留了 OAuth tokenCLI 會優(yōu)先用它而不是你的 API Key。這時候要清理掉舊的憑證緩存強制走 API Key 路徑。具體位置看 CLI 的文檔一般在用戶目錄下的隱藏文件夾里。重試不觸發(fā)如果確認(rèn)有 429 或超時但日志里看不到重試記錄先檢查retry.enabled是不是 true再看retryOn列表里有沒有包含實際發(fā)生的錯誤類型。有些客戶端的錯誤類型字符串和你想的不一樣比如實際是stream_error而你寫的是stream_disconnected那就匹配不上。排查順序建議是先 curl 確認(rèn)通道再確認(rèn)三件套再看重試配置最后看終態(tài)判定。一層層往下別跳步。6. 把重試做成共享能力而不是每個 Provider 重寫一遍走到這里你應(yīng)該已經(jīng)能把 Claude Code 和 Codex 的 endpoint 指向 TaoToken并且用連續(xù)請求驗證重試生效了。但如果你同時接多個 Agent CLI很快會發(fā)現(xiàn)一個問題每個 Provider 都寫一套重試狀態(tài)機維護成本會爆炸。更穩(wěn)的做法是把重試提煉成共享層。共享協(xié)調(diào)器管重試循環(huán)、退避節(jié)奏、continuation promptProvider 只回答兩個問題——這個終態(tài)值不值得重試、當(dāng)前上下文還能不能續(xù)。Codex 看 thread 還在不在Claude Code 看 continuation target 還在不在。退避策略和重試次數(shù)不該讓每個 Provider 重新發(fā)明。策略最好做成 snapshot跟著請求一起走而不是依賴某個「此刻的全局配置」。這樣會話排隊、消息持久化、執(zhí)行轉(zhuǎn)發(fā)都不會把策略弄丟。業(yè)務(wù)層決定「該不該重試」運行時決定「怎么重試」兩邊各管一攤。如果你需要長期跑編碼任務(wù)或者 Agent 工作流可以考慮用 Coding Plan入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite。模型對話調(diào)試在https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite接入文檔在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteKey 管理在https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite。最后留一個實用技巧重試預(yù)算一定要有邊界三檔退避之后就該停手。無限重試不是恢復(fù)機制是事故放大器。把邊界守住比把重試次數(shù)調(diào)大更重要。