最近在折騰 AI 自動化辦公工具時我發現了一個很有意思的現象很多朋友把 WorkBuddy 這類工具裝好跑通一兩個示例就以為萬事大吉了。但真到了想把 DeepSeek 這類大模型無縫集成進去實現一些復雜的、定制化的辦公流程時問題就來了——要么是 API 調用不通要么是 Token 不夠用要么是自定義模型配置起來一頭霧水。這背后其實是一個典型的“從玩具到工具”的認知斷層。單次跑通一個 Demo和把一個 AI 能力穩定、可靠、低成本地嵌入到你的日常工作流里完全是兩回事。今天我們就來聊聊如何利用騰訊云 API 網關這個“中轉站”把 DeepSeek 這樣的模型變成 WorkBuddy 里一個聽話且強大的自定義技能。更重要的是如何在這個過程中巧妙地獲取和利用那些免費的 API 調用額度比如傳說中的“100萬 Token”讓自動化辦公不再是個燒錢的無底洞。1. 先想清楚為什么需要“自定義模型”這個中間層在 WorkBuddy 里直接填上 DeepSeek 的官方 API Key看起來是最直接的方案。但如果你真的這么試過很快會遇到幾個繞不開的坎第一成本與額度管理。DeepSeek 的 API 有免費額度但用完了就得付費。如果你的 WorkBuddy 流程設計得比較復雜或者需要高頻調用賬單增長會很快。更重要的是你無法在 WorkBuddy 內部精細地控制每個流程、每個用戶的用量。第二功能定制與增強。官方 API 提供的是標準能力。但你的辦公場景可能需要一些“組合拳”比如在調用模型前先對輸入文本進行預處理提取關鍵信息、格式化在拿到模型輸出后再進行后處理解析 JSON、提取特定字段、轉換成表格。這些邏輯如果都寫在 WorkBuddy 的指令里會變得極其臃腫且難以維護。第三穩定性與降級策略。直接依賴一個外部 API意味著它的任何波動服務降級、響應變慢都會直接影響你的自動化流程。你可能會希望加入重試機制、緩存層或者在主模型不可用時能自動切換到另一個備用的、能力相近但更便宜的模型上。第四安全與審計。將所有請求通過一個受你控制的中間服務轉發可以方便地加入日志記錄、請求審計、敏感詞過濾等安全措施。這對于企業環境或處理敏感信息的自動化流程至關重要。而騰訊云 API 網關恰恰就是為了解決這些問題而生的“中間層”。它不是一個 AI 模型而是一個強大的流量調度、管理和轉發平臺。你可以把它想象成一個高度可編程的“智能路由器”接收端接收來自 WorkBuddy或其他任何客戶端的請求。處理端在這里你可以編寫函數比如用云函數 SCF對請求進行任意加工驗證 Token、修改參數、合并多個請求、調用其他服務等。轉發端將處理后的請求轉發給真正的目標服務——比如 DeepSeek 的官方 API 端點。響應端接收 DeepSeek 的返回結果再次進行加工格式化、錯誤處理最后返回給 WorkBuddy。通過這個架構上面提到的所有問題都有了解決方案。成本控制你可以在 API 網關層設置流控策略限制每分鐘/每天的調用次數。功能定制在云函數里寫任何預處理/后處理邏輯。穩定性配置重試和備用上游地址。安全審計開啟網關的詳細訪問日志。所以接入“自定義模型”的第一步不是急著去配置參數而是想明白我到底要通過這個中間層解決哪些具體問題是省錢是增強功能還是提升穩定性目標不同后續的架構設計和配置重點也會完全不同。2. 核心資源獲取理解“Token”與“免費額度”的玩法幾乎所有主流大模型 API 的計費單位都是Token。你可以把它粗略理解為“字數”但更準確地說它是模型用來分割和理解文本的基本單位。一個中文字通常對應 1-2 個 Token一個英文單詞可能對應 1 個或更多 Token。當我們談論“免費領 100 萬 Token”時通常指的是某個平臺為新用戶或完成特定任務提供的API 調用免費額度。這可能是模型提供商直接贈送如 DeepSeek 官方會提供一定量的免費 Token 供測試。云平臺作為促銷手段例如騰訊云、阿里云等為了推廣其 AI 云市場或 API 網關等產品可能會打包贈送合作模型的調用額度。第三方工具集成獎勵像 WorkBuddy 這類平臺有時會與模型方合作為用戶提供兌換碼兌換成對應模型的 API 額度。關鍵點在于這些額度往往綁定的是某個具體的 API Key 或訪問憑證而不是直接給你的賬戶充錢。那么如何找到并利用這些額度呢一個可靠的行動路徑如下2.1 第一步確認額度來源與規則不要輕信來路不明的“兌換碼”。優先從以下渠道核實DeepSeek 官方平臺登錄 DeepSeek 開放平臺查看個人中心的“余額”或“用量統計”確認官方贈送的免費額度及有效期。騰訊云 AI 相關產品頁關注騰訊云“AI 開發平臺”、“云市場-AI模型”等板塊的活動。有時新用戶注冊、實名認證、完成新手任務會贈送包含多種模型調用的通用代金券或資源包。WorkBuddy 官方社區或文檔查看其公告或教程確認是否有正式的合作伙伴額度發放活動。2.2 第二步獲取并保管好 API Key無論額度來自哪里最終都會體現為一組API Key通常包含一個API Key和一個Secret Key或一個Bearer Token。DeepSeek 官方在平臺創建應用即可獲得。騰訊云如果在騰訊云上調用其集成的或自定義封裝的模型需要在“訪問管理”中創建密鑰對。重要原則這些 Key 如同銀行卡密碼切勿泄露。不要直接寫在客戶端代碼或 WorkBuddy 的公開配置里。2.3 第三步理解額度的消耗方式假設你獲得了 100 萬 Token 的免費額度。如何消耗每次調用 API模型處理你的輸入Prompt和生成輸出Completion所花費的 Token 總數會從額度中扣除。一個簡單的估算如果你每次問答平均消耗 1000 Token那么 100 萬 Token 大約可以支持 1000 次交互。對于自動化辦公中的文本總結、郵件撰寫、數據清洗等任務這個額度足夠進行深入的學習和測試。監控用量務必定期在發放額度的平臺查看用量明細避免在不知情的情況下超額使用產生計劃外的費用。2.4 第四步將額度“接入”你的架構這是我們接下來要搭建的核心。我們的目標不是把 DeepSeek 的 API Key 直接填進 WorkBuddy而是將其配置在騰訊云 API 網關的后端服務中。這樣WorkBuddy 只需要調用騰訊云 API 網關的地址而真正的 DeepSeek Key 被安全地隱藏在后端。這樣做的另一個好處是如果未來 DeepSeek 的免費額度用盡或者你想切換成另一個有額度的模型比如騰訊云內部的某個模型你只需要在 API 網關的后端配置里修改一下轉發地址和 KeyWorkBuddy 側的所有指令和流程都無需任何改動。這實現了調用方WorkBuddy與模型服務方的解耦。3. 實戰搭建從騰訊云 API 網關到 WorkBuddy 的完整鏈路現在我們進入實操環節。請跟隨以下步驟目標是創建一個屬于你自己的、可被 WorkBuddy 調用的“DeepSeek 自定義模型”。3.1 第一階段在騰訊云創建 API 網關服務登錄騰訊云控制臺搜索并進入API 網關產品。創建服務點擊“新建服務”。服務名稱可以叫workbuddy-ai-proxy類型選擇“HTTP”網絡類型通常選“公網”。創建 API在剛創建的服務下點擊“新建 API”。前端配置路徑Path/deepseek/chat你可以自定義這是 WorkBuddy 要調用的地址請求方法POST鑒權類型選擇“免鑒權”進行測試后期可改為“密鑰對”以提升安全性。后端配置后端類型選擇“HTTP”后端域名填寫 DeepSeek 的官方 API 端點例如https://api.deepseek.com路徑/chat/completions這是 DeepSeek 的聊天補全接口路徑請求方法POST關鍵步驟參數映射與 Header 設置這是核心所在。我們需要將 WorkBuddy 發來的請求原樣或加工后轉發給 DeepSeek并將 DeepSeek 的響應返回。在“后端配置”中找到參數配置或Header 配置。你需要添加一個Header名為Authorization值設置為Bearer 你的DeepSeek_API_Key。請將你的DeepSeek_API_Key替換成你實際的 Key。確保請求體Body的映射是“透傳”的。通常 API 網關默認會將前端請求的 Body 直接轉發給后端。發布服務配置完成后將 API 發布到某個“發布環境”例如release或test。發布后你會獲得一個訪問地址形如https://service-xxxxx-xxx.gz.apigw.tencentcs.com/release/deepseek/chat。這個地址就是 WorkBuddy 未來需要調用的“自定義模型”地址。3.2 第二階段在云函數中實現邏輯增強可選但推薦如果你需要預處理或后處理上述簡單的轉發就不夠了。這時需要引入云函數 SCF。在 API 網關的“后端配置”中將后端類型改為“云函數”。創建一個新的云函數運行環境選擇Python 3.7或Node.js。編寫函數邏輯。以下是一個 Python 示例展示了如何轉發請求并加入簡單的日志和錯誤處理import json import requests def main_handler(event, context): # 1. 解析 API 網關傳遞過來的請求 req_body json.loads(event[body]) print(fReceived request: {json.dumps(req_body, ensure_asciiFalse)}) # 2. (可選) 請求預處理例如確保 messages 字段存在 if messages not in req_body: return { statusCode: 400, body: json.dumps({error: Missing messages field}) } # 3. 準備請求 DeepSeek 的 Headers headers { Content-Type: application/json, Authorization: Bearer YOUR_DEEPSEEK_API_KEY_HERE # 務必替換 } # 4. 轉發請求到 DeepSeek deepseek_url https://api.deepseek.com/chat/completions try: response requests.post(deepseek_url, headersheaders, jsonreq_body, timeout30) response.raise_for_status() # 檢查 HTTP 錯誤 result response.json() print(fDeepSeek response: {json.dumps(result, ensure_asciiFalse)}) # 5. (可選) 響應后處理例如提取標準格式內容 ai_message result[choices][0][message][content] if result.get(choices) else # 6. 返回給 API 網關 (最終到 WorkBuddy) return { statusCode: 200, body: json.dumps({ original_response: result, extracted_content: ai_message # 提供一個更干凈的字段 }) } except requests.exceptions.RequestException as e: print(fError calling DeepSeek: {e}) return { statusCode: 500, body: json.dumps({error: Failed to call AI service, detail: str(e)}) }將這個云函數與 API 網關的 API 關聯起來。這樣所有流量都會先經過你的云函數由你完全控制再決定如何與 DeepSeek 交互。3.3 第三階段在 WorkBuddy 中配置自定義模型現在我們回到 WorkBuddy。打開 WorkBuddy 的技能或模型配置頁面找到“自定義模型”或“外部 API”的添加入口。模型名稱可以命名為“我的 DeepSeek 代理”或“騰訊云-DeepSeek”。API 端點填寫你在3.1 第5步獲得的騰訊云 API 網關地址。認證信息如果在 API 網關創建 API 時選擇了“密鑰對”鑒權這里需要填寫騰訊云 API 網關的SecretId和SecretKey。如果選擇的是“免鑒權”這里可能留空或填寫一個固定的 Token具體看 WorkBuddy 的字段要求。請求格式通常選擇JSON。請求體Body的格式需要與 DeepSeek API 要求的一致。一個最簡化的示例格式如下你可以在 WorkBuddy 的自定義指令或技能配置中以變量的形式動態構建這個 JSON{ model: deepseek-chat, messages: [ {role: user, content: {{用戶輸入的問題}}} ], stream: false }響應解析告訴 WorkBuddy 如何從返回的 JSON 中提取出文本內容。如果使用簡單的網關轉發路徑可能是choices[0].message.content。如果使用了上述云函數并返回了extracted_content字段則路徑可以設為extracted_content。測試連接保存配置后使用 WorkBuddy 提供的測試功能發送一條簡單消息看是否能收到正確的 AI 回復。至此一個通過騰訊云 API 網關橋接的、可被 WorkBuddy 調用的自定義 DeepSeek 模型就配置完成了。你的 WorkBuddy 技能現在調用的不再是官方端點而是你完全可控的代理服務。4. 從“跑通”到“用好”關鍵配置、避坑與高階思路成功調通只是第一步。要讓這個組合在真實的辦公自動化中穩定、高效、省錢地運行還需要關注以下幾個層面。4.1 安全與成本管控給 API 網關加上“閥門”直接在公網暴露一個轉發服務是危險的可能被他人盜刷消耗你的 Token 額度。開啟鑒權在 API 網關中將 API 的鑒權類型從“免鑒權”改為“密鑰對”。這樣只有攜帶正確SecretId和SecretKey的請求來自你的 WorkBuddy才能調用。設置流量控制在 API 網關中為你的 API 創建“流控策略”。例如限制單個密鑰對每分鐘最多調用 10 次每天最多 1000 次。這能有效防止意外循環調用或惡意攻擊導致的額度爆掉。綁定自定義域名并啟用 HTTPS使用自己的域名并配置 SSL 證書讓通信更安全、更專業。4.2 穩定性與可觀測性知道發生了什么啟用日志務必在騰訊云 API 網關控制臺和云函數 SCF 控制臺開啟日志投遞功能。所有請求和響應的詳情、錯誤信息都會被記錄下來。當 WorkBuddy 流程出錯時這是你排查問題的第一現場。設置超時與重試在 API 網關配置中合理設置后端超時時間如 30 秒。對于網絡波動導致的偶發失敗可以在云函數邏輯中或 WorkBuddy 技能層面加入簡單的重試機制。監控告警在騰訊云“云監控”中為 API 網關的請求次數、錯誤率、響應時間等關鍵指標設置告警。當服務異常時能第一時間收到通知。4.3 高階玩法讓“自定義模型”更智能單一的模型轉發只是開始API 網關云函數的組合能玩出更多花樣負載均衡與降級在云函數中可以同時配置多個模型的上游地址如 DeepSeek、GPT、國內其他大模型。根據當前主模型的響應狀態、成本或任務類型智能地選擇或切換調用目標。當 DeepSeek 服務不穩定時自動切換到備用模型保障流程不中斷。上下文管理與記憶WorkBuddy 的單次調用可能是無狀態的。你可以在云函數中集成 Redis 等數據庫為每個會話Session保存歷史對話記錄。當新的請求到來時自動將歷史記錄拼接成完整的上下文再發給模型實現跨指令的連續對話。結果格式化與集成對于辦公場景模型返回的可能是自由文本。你可以在云函數中編寫后處理邏輯將其自動解析成標準的 JSON 結構、Markdown 表格甚至直接調用騰訊云的其他服務如發送郵件、寫入在線文檔、生成圖表形成一個完整的自動化閉環。4.4 常見錯誤排查指南如果在配置或使用過程中遇到問題請按以下順序排查WorkBuddy 側報錯首先檢查 WorkBuddy 中配置的 API 端點、認證信息是否完全正確。使用簡單的工具如 Postman 或 curl直接測試你的騰訊云 API 網關地址看是否能收到預期響應。API 網關日志查看 API 網關的日志確認請求是否成功到達網關網關轉發給后端云函數或 DeepSeek的請求是什么后端返回了什么。常見的 403、404、502 錯誤在這里都能找到根源。云函數日志如果你使用了云函數這里是查看業務邏輯錯誤如 Python 代碼異常、網絡請求超時的最佳位置。DeepSeek 額度與狀態確認你的 DeepSeek API Key 有效且額度充足。直接使用該 Key 調用官方接口驗證服務是否正常。網絡與權限確認云函數或 API 網關所在的云服務網絡能夠正常訪問 DeepSeek 的海外 API 地址如果需要。檢查云函數的運行角色是否擁有訪問外網的權限。回過頭看我們做的遠不止是“接入一個模型”。我們實際上是在構建一個屬于你自己的、可管控的 AI 能力微服務。騰訊云 API 網關是這個服務的網關和調度中心DeepSeek 是背后的能力提供者之一而 WorkBuddy 則是這個服務的一個優秀消費者。這種架構帶來的最大好處是控制力和靈活性。你控制了成本、安全、邏輯和穩定性。未來無論 DeepSeek 的 API 如何變化是否有新的、更劃算的模型出現你都可以在后臺無縫切換和升級而前端的無數個自動化工作流完全不受影響。這才是將 AI 深度融入辦公流程并使之長期、可靠運行的關鍵所在。