每個 AI 自動化平台都聲稱支援「多模型」。實際上，這通常意味著您可以在設定下拉選單中切換 GPT-4o 和 GPT-5。也許 Claude 也列出來了。如果您想執行開源模型，就只能靠自己了。
JieGou 採取不同的方法。我們建構了一個通用模型層，將每個 LLM——無論是雲端託管還是自託管、專有還是開源——都視為一等公民。這篇文章解釋了它的運作方式以及為什麼重要。
同一平台中的四個提供商層級
第一層：帶有 BYOK 的雲端提供商
為 Anthropic（Claude Sonnet 4.6、Haiku 4.5、Opus 4.6）、OpenAI（GPT-5.2、GPT-5-mini、GPT-5-nano、o3、o4-mini）和 Google（Gemini 3.1 Pro、Gemini 3 Flash、Gemini 2.5 Pro/Flash）帶入您自己的 API 金鑰。
您的金鑰使用 AES-256-GCM 加密，通過 HKDF-SHA256 衍生的帳戶專屬金鑰。它們僅在執行時在記憶體中解密，永不以明文儲存。您也可以在免費層使用平台提供的金鑰，無需輸入任何憑證即可開始。
第二層：認證的開源模型
我們在 vLLM 上端對端測試了四個開源模型，並認證它們完全相容 JieGou——包括工具呼叫、結構化 JSON 輸出和配方執行：
| 模型 | 參數量 | 工具呼叫 | 結構化輸出 | 視覺 | 上下文 |
|---|---|---|---|---|---|
| Llama 4 Maverick | 400B+ MoE | 是 | 是 | 是 | 1M tokens |
| DeepSeek V3.2 | 671B MoE | 是 | 是 | 否 | 128K tokens |
| Qwen 3 235B | 235B MoE | 是 | 是 | 否 | 128K tokens |
| Mistral 3 Large | 123B dense | 是 | 是 | 是 | 128K tokens |
「認證」意味著我們已針對這些模型執行了數千次配方，驗證了工具呼叫和結構化輸出是否正確運作，並記錄了相容性等級。您可以放心地部署它們。
第三層：社群模型
任何可通過 OpenAI 相容 API 存取的模型都可以與 JieGou 配合使用。我們沒有測試過它，所以它得到「社群」層級標籤——但整合方式完全相同。如果它支援 OpenAI API 格式，JieGou 就能使用它。
第四層：自動發現的本地模型
JieGou 在啟動時探測本地推理伺服器：
http://ollama:11434（Docker Compose 服務名稱）http://localhost:11434（本地 Ollama）http://localhost:8000（本地 vLLM）OLLAMA_BASE_URL環境變數
當它找到伺服器時，會查詢模型列表並使這些模型在模型選擇器中可用。無需手動設定。發現結果會快取 5 分鐘，以避免頻繁存取您的推理伺服器。
逐步模型選擇
這是讓多提供商支援真正有用的功能，而不僅僅是比較表上的一個勾選框。
在 JieGou 工作流程中，每個步驟都可以使用不同的模型。典型的設定：
| 工作流程步驟 | 任務 | 模型 | 原因 |
|---|---|---|---|
| 1. 研究 | 深度競爭分析 | Claude Opus 4.6 | 最佳推理品質 |
| 2. 分類 | 分類研究結果 | GPT-5-nano | 快速且便宜的分類 |
| 3. 擷取 | 提取結構化資料 | Llama 4 Maverick | 最低成本的大量處理 |
| 4. 摘要 | 撰寫執行摘要 | Claude Sonnet 4.6 | 強大的寫作品質 |
| 5. 翻譯 | 本地化為 5 種語言 | Qwen 3 235B | 最佳多語言表現 |
同樣的靈活性適用於配方（每個配方有自己的模型設定）、對話（每次聊天選擇模型）和批次執行（所選模型適用於所有行）。
模型推薦引擎
為每個任務選擇正確的模型聽起來很強大但也很複雜。推薦引擎讓這變得實用。
在配方執行超過 10 次後，引擎有足夠的資料為您使用過的每個模型評分：
score = successRate × 0.5 + costEfficiency × 0.3 + speed × 0.2它查看過去 60 天的執行歷史並比較：
- 成功率 — 完成且無錯誤的執行百分比
- 成本效率 — 每次成功執行的成本（越低越好）
- 速度 — 平均執行時間（越快越好）
如果您當前的模型在 10 次以上的執行中有 ≥90% 的成功率，引擎會確認這是個好選擇。否則，它會推薦得分最高的替代方案，並提供完整的指標，讓您做出明智的切換。
如需嚴格比較，您可以執行 Bakeoff——使用 LLM 作為評審的正面對決評估，具有 95% 信賴區間。Bakeoff 可以比較任何兩個模型、任何兩個配方或任何兩個工作流程。
企業級韌性
在多個提供商之間執行生產工作負載需要的不僅僅是 API 金鑰管理。JieGou 包含三個韌性層：
斷路器
每個提供商都有自己的斷路器。如果 60 秒內有 5 次呼叫失敗，電路開啟——後續呼叫快速失敗而不是超時等待。30 秒後，電路進入半開狀態並發送探測請求。如果成功，電路關閉，流量恢復。
對於 openai-compatible 提供商，斷路器的範圍限定在每個帳戶（因為每個客戶可能有不同的端點）。雲端提供商共享全域斷路器。
關鍵是，斷路器是故障開放的——如果 Redis 停機且我們無法檢查電路狀態，我們會讓呼叫通過。這意味著監控故障永遠不會阻塞您的工作流程。
並行限制
全域信號量限制每個帳戶的並行 LLM 呼叫，以防止失控使用。限制隨您的方案而擴展：
| 方案層級 | 全域容量份額 | 每帳戶上限 |
|---|---|---|
| Enterprise | 100%（150 個插槽） | 10 個並行 |
| Pro | 83%（125 個插槽） | 10 個並行 |
| Starter | 67%（100 個插槽） | 10 個並行 |
成本追蹤
每次 LLM 呼叫都記錄 token 使用量和估計成本。當您使用 BYOK 時，成本會單獨追蹤——它會顯示在您的分析儀表板中，但不計入平台使用限制，因為您直接向提供商付費。
成本估算器使用您最近 20 次成功執行的歷史平均值來預測執行前的成本。您可以看到每個配方、每個工作流程步驟和每個批次執行的預期花費。
零知識金鑰架構
JieGou 永遠不會在靜態時看到您的 API 金鑰明文。加密流程：
- 根金鑰從 Secret Manager 或環境變數載入（64 字元十六進位）
- 每帳戶金鑰通過 HKDF-SHA256 衍生：
HKDF(rootKey, "", "jiegou-byok-envelope-v1:{accountId}", 32) - 加密：AES-256-GCM，使用隨機 12 位元組 IV 和 16 位元組驗證標籤
- 儲存：只有密文 + IV + 驗證標籤儲存在 Firestore 中
- 解密：在執行時在記憶體中進行，永不持久化
支援金鑰輪換——系統可以從舊版全域加密方案遷移到每帳戶信封加密，無需停機。
如果 API 呼叫返回 401 或 403，系統會自動將金鑰標記為無效並顯示清楚的錯誤。您可以從設定頁面重新驗證或更換金鑰。
開始使用
- 免費層：使用平台提供的 Anthropic、OpenAI 和 Google 金鑰——無需憑證
- BYOK：前往設定 > API 金鑰，添加您的提供商金鑰，它們會立即加密
- 開源：輸入自訂基礎 URL（例如
http://your-vllm-server:8000/v1）和模型名稱 - 自動發現：如果 Ollama 或 vLLM 在本地執行，模型會自動出現
多提供商模型存取適用於所有方案。OpenAI 相容端點和模型推薦引擎適用於 Pro 及以上。認證模型註冊表和自動發現是 Enterprise 功能。