如果你想用 GPT、Claude、Gemini、DeepSeek 與 Grok 構建一個 AI 應用，請為共同的請求路徑使用統一 API，並將路由策略保留在你的應用內部。CometAPI 提供 OpenAI 相容的基底 URL 與共享模型目錄，因此一個 Python 服務可以透過同一個用戶端呼叫不同的模型 ID。你的程式碼仍然決定要跑哪個模型、允許哪些工具，以及何時可以安全地進行備援。
本教學將建立一個 Grok 4.7 代理，它可以請求兩個唯讀的業務工具、在執行前拒絕未知工具與格式錯誤的引數，並且只在選擇性的暫時性失敗後才切換到另一個經契約測試的模型。目標不是打造一個神奇的自動化系統，而是一個小型、可檢視的迴圈，可以在生產環境中測試與運行。
你將構建什麼
該代理包含五個明確的部分：
- 一個 CometAPI 用戶端。OpenAI Python SDK 使用下方設定中的 CometAPI API 基底 URL。
- Grok 4.7 作為主要模型。目前的 CometAPI 模型 ID 為
grok-4.7。 - 一個工具註冊表。模型可能提出函式呼叫，但只有應用程式端的程式碼才能執行被允許清單中的函式。
- 一個有界代理迴圈。該迴圈在固定的模型回合數後停止，而不是無限運行。
- 一個有序備援策略。僅在可重試的模型/API 失敗後，才嘗試相容的 GPT、Claude、Gemini 或 DeepSeek 模型 ID。
Grok 4.7 支援函式呼叫，且 CometAPI 目前為該模型同時提供 /v1/chat/completions 與 /v1/responses 路由。本教學使用 Chat Completions，因為其 OpenAI 相容的 tools、助理的工具呼叫，以及對應的 tool 結果訊息，可以直接對映為一個精簡、可檢視的 Python 迴圈。傳輸層的相容性不代表每個模型都特性等同，因此每個配置的備援都必須先通過相同的契約測試，方可進入生產環境。
多輪 Grok 4.7 代理中的推理狀態
Grok 4.7 接受 low、medium、high 或 xhigh 的推理強度，預設為 high。在 xAI 的 Responses API 上，每個 Grok 4.7 回應都會包含 reasoning.encrypted_content；由客戶端管理的多輪迴圈應將回傳的推理項目原封不動地傳回到下一次請求。較長的迴圈也可以使用上下文壓縮：將回傳的壓縮項作為不透明狀態保留，並在其後追加新的回合。由於這些是具狀態且供應商特定的回應欄位，請在將其作為生產依賴之前，驗證所選的 CometAPI 路由能端到端回傳它們。
代理架構：模型提出建議，你的應用做決策
一個安全的工具呼叫流程很簡單：
使用者請求 → 模型回應 → 驗證工具呼叫 → 執行允許清單中的工具 → 附加工具結果 → 模型回應
模型永遠不會獲得資料庫憑證，也不會直接執行 Python。它會產生結構化請求，例如「呼叫 get_order_status 並帶上此訂單 ID」。你的應用會檢查工具名稱、解析引數、套用授權與業務規則、執行函式，並回傳序列化的結果。
此分離比模型選擇更重要。備援模型應繼承相同的工具邊界——而不是更寬鬆的邊界——當工具結果包含外部內容時，必須將其視為不受信任的資料。
如何用 Python 構建 Grok 4.7 AI 代理
步驟 1：為 CometAPI 設定 OpenAI Python SDK
安裝 OpenAI SDK：
pip install openai
透過環境變數設定：
export COMETAPI_KEY="your-cometapi-key"
export PRIMARY_MODEL="grok-4.7"
export FALLBACK_MODEL_1="your-compatible-gpt-model-id"
export FALLBACK_MODEL_2="your-compatible-claude-model-id"
export FALLBACK_MODEL_3="your-compatible-gemini-model-id"
export FALLBACK_MODEL_4="your-compatible-deepseek-model-id"
本教學使用 Chat Completions，因為其明確的助理工具呼叫與對應的工具結果訊息，讓控制流程可以在精簡的 Python 範例中輕鬆檢視。對於更長且具狀態的迴圈，請評估上文所述的 Responses API。另外，不要從部落格文章複製舊的模型 ID 進入生產環境：在部署或啟動時抓取 CometAPI 的公開 GET /api/models 目錄，然後在模型目錄中確認能力與價格。
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["COMETAPI_KEY"],
base_url="https://api.cometapi.com/v1",
max_retries=0,
timeout=30.0,
)
明確的逾時與停用 SDK 重試是刻意的。應用程式將分類失敗，並決定是否重複請求或移動到下一個模型。隱含重試會讓延遲、重複的副作用與備援行為更難理解。
步驟 2：先定義狹義且唯讀的工具
先從讀取資料而非變更資料的工具開始。以下定義讓代理可以檢查訂單與查詢庫存。實作回傳示範資料；請以你自己的服務、並經過驗證的呼叫取代。
import json
TOOLS = [
{
"type": "function",
"function": {
"name": "get_order_status",
"description": "Read the current status of one order.",
"parameters": {
"type": "object",
"properties": {
"order_id": {"type": "string"}
},
"required": ["order_id"],
"additionalProperties": False,
},
},
},
{
"type": "function",
"function": {
"name": "check_inventory",
"description": "Read available inventory for one SKU.",
"parameters": {
"type": "object",
"properties": {
"sku": {"type": "string"}
},
"required": ["sku"],
"additionalProperties": False,
},
},
},
]
def get_order_status(order_id: str) -> dict:
# Replace this demo with an authenticated, read-only service call.
return {"order_id": order_id, "status": "in_transit"}
def check_inventory(sku: str) -> dict:
# Replace this demo with an authenticated, read-only service call.
return {"sku": sku, "available_units": 12}
TOOL_REGISTRY = {
"get_order_status": get_order_status,
"check_inventory": check_inventory,
}
JSON 結構綱要可以改善請求形狀，但它不是授權。請驗證引數長度與格式、確認目前使用者可以存取所請求的訂單或 SKU，並在將結果回傳給模型前限制每個工具結果的大小。
步驟 3：加入狹義的多模型備援策略
備援應該從暫時性路由失敗中恢復，而不是掩蓋有問題的請求。CometAPI 的官方備援指南建議：對於連線錯誤、逾時、HTTP 408、HTTP 429 與暫時性的 5xx 回應，移動到下一個已配置的路由。無效的憑證、不支援的參數與無效請求應立即失敗。
from openai import APIConnectionError, APIStatusError, APITimeoutError
def configured_models() -> list[str]:
names = [
os.getenv("PRIMARY_MODEL", "grok-4.7"),
os.getenv("FALLBACK_MODEL_1"),
os.getenv("FALLBACK_MODEL_2"),
os.getenv("FALLBACK_MODEL_3"),
os.getenv("FALLBACK_MODEL_4"),
]
return [name for name in names if name]
def is_retryable(error: Exception) -> bool:
if isinstance(error, (APIConnectionError, APITimeoutError)):
return True
if isinstance(error, APIStatusError):
return error.status_code in {408, 429} or error.status_code >= 500
return False
def complete_with_fallback(messages: list[dict], tools: list[dict]):
models = configured_models()
last_error = None
for index, model in enumerate(models):
try:
response = client.chat.completions.create(
model=model,
messages=messages,
tools=tools,
tool_choice="auto",
)
return response, model
except Exception as error:
last_error = error
final_route = index == len(models) - 1
if final_route or not is_retryable(error):
raise
raise RuntimeError("No configured model completed the request") from last_error
模型清單是設定，而不是品質排名。選擇支援該代理所需的相同訊息角色、工具結構、輸入模態、上下文需求與回應行為的備援。記錄所選路由與導致每次切換的失敗原因。
步驟 4：運行有界的 Grok 4.7 代理迴圈
下方迴圈會傳送對話、執行任何允許清單中的工具呼叫、使用相符的 tool_call_id 附加結果，並要求所選模型完成答案。
def execute_tool_call(tool_call) -> str:
name = tool_call.function.name
if name not in TOOL_REGISTRY:
return json.dumps({"error": f"Tool not allowed: {name}"})
try:
arguments = json.loads(tool_call.function.arguments)
result = TOOL_REGISTRY[name](**arguments)
return json.dumps(result)
except (json.JSONDecodeError, TypeError, ValueError) as error:
return json.dumps({"error": f"Invalid tool arguments: {error}"})
def run_agent(user_text: str, max_turns: int = 4) -> dict:
messages = [
{
"role": "system",
"content": (
"You are a support agent. Use tools only when needed. "
"Never invent order or inventory data."
),
},
{"role": "user", "content": user_text},
]
route_log = []
for turn in range(max_turns):
response, model = complete_with_fallback(messages, TOOLS)
route_log.append({"turn": turn + 1, "model": model})
assistant = response.choices[0].message
messages.append(assistant.model_dump(exclude_none=True))
if not assistant.tool_calls:
return {
"answer": assistant.content,
"routes": route_log,
"usage": response.usage.model_dump() if response.usage else None,
}
for tool_call in assistant.tool_calls:
messages.append(
{
"role": "tool",
"tool_call_id": tool_call.id,
"content": execute_tool_call(tool_call),
}
)
raise RuntimeError("Agent stopped after reaching max_turns")
result = run_agent("Where is order A-104, and is SKU BLUE-42 in stock?")
print(result["answer"])
print(result["routes"])
該程式支援在一個模型回應中進行多個工具呼叫，因為它會為每個回傳的呼叫附加一個結果。如果某個工具會改變狀態——例如寄送電子郵件、下訂單或進行退款——請加入冪等鍵與人工確認步驟。如果副作用可能已經發生，切勿在逾時後盲目地重新啟動整個代理回合。
GPT、Claude、Gemini 與 DeepSeek 如何融入同一應用
CometAPI 可以減少連線層的重複：一個帳號、一個 OpenAI 相容的基底 URL 作為共同路徑，並由應用程式碼選擇模型 ID。這樣就能在一個內部介面後面放置 GPT、Claude、Gemini、DeepSeek 與 Grok 作為候選。
但這不代表模型可以互換。在新增備援之前，請驗證：
- 目前的模型 ID 由 CometAPI 目錄回傳；
- 路由支援所需的工具結構與訊息角色；
- 工具呼叫引數與多重呼叫行為符合代理契約；
- 上下文視窗與輸入模態符合請求需求；
- 回應可在到達使用者前被驗證；
- 延遲與成本維持在產品預算之內。
供應商原生功能可能需要原生端點或獨立轉接器。將這些例外情況明確化，而不是強迫每個能力都走共同介面。
Grok 4.7 多模型備援不同於多代理
多模型備援鏈會在路由失敗時選擇另一個模型。多代理系統則是將不同責任分配給不同代理——例如規劃者、研究者與審核者。兩種模式解決的是不同問題。
如果你要把這個 Grok 4.7 代理擴展為多代理工作流程，請為每個工作者賦予狹義角色、獨立的工具允許清單、有界預算與結構化交接。不要讓每個代理都能呼叫所有工具，或轉發無限制的逐字稿。先從一個代理開始，直到評估數據證明角色分離可以改善結果。
Grok 4.7 代理的生產防護欄
執行工具前先驗證
在應用程式碼中檢查工具名稱、引數結構、租戶所有權、使用者權限與速率限制。將工具描述視為對模型的指引，而不是安全控制。
將讀工具與寫工具分離
唯讀工具通常可在授權後自動執行。寫工具則應要求更強的檢查、冪等與對具影響力操作的確認。
為每個迴圈設限
設定最大模型回合數、工具呼叫數、牆鐘時間、提示大小與權杖預算。當達到界限時，回傳受控錯誤或升級路徑。
記錄決策軌跡
記錄所請求的任務、政策版本、所選模型 ID、備援原因、工具名稱、工具延遲、驗證結果、權杖用量與最終狀態。不要記錄機密或不必要的客戶內容。
使用契約測試，而非假設
對每個配置的模型跑相同的固定測試。最低限度的實用測試套件應涵蓋：正常答案、一次工具呼叫、多次工具呼叫、格式錯誤的引數、未知工具、工具逾時、主要模型的 429，以及不得觸發備援的無效 API 金鑰。
部署檢查清單
- 抓取最新模型 ID，並在部署前驗證 Grok 4.7 路由。
- 將 CometAPI 金鑰放入秘密管理器，不要放在原始碼或提示中。
- 從唯讀工具與明確的 JSON 結構綱要開始。
- 在每次工具呼叫前套用驗證與租戶授權。
- 僅對分類為暫時性的錯誤啟用備援。
- 對每個備援做相同的工具呼叫契約測試。
- 在啟用寫工具前加入冪等與確認。
- 設定迴圈、延遲、上下文與成本限制。
- 衡量任務成功率，而不只是 API 可用性。
為何透過 CometAPI 構建此代理？
CometAPI 在此場景很有用，因為通用整合保持精簡。OpenAI Python SDK 指向同一個基底 URL，Grok 4.7 由模型 ID 選擇，其他供應商的相容模型則可放在同一個、由應用擁有的路由政策後面。
這給團隊空間去評估 GPT、Claude、Gemini 與 DeepSeek，而不會讓供應商特定的連線程式碼散落在產品中。它也保留了一個重要邊界：CometAPI 提供存取，而你的應用擁有能力檢查、工具執行、備援政策、評估與面向使用者的行為。
查看目前的 Grok 4.7 模型頁面，依照 CometAPI 快速入門 設定用戶端，並在選擇生產備援之前抓取最新的模型 ID。
常見問題
我應該為同時使用 GPT、Claude、Gemini 與 DeepSeek 的應用選擇哪個 API？
對於共同的聊天與工具呼叫路徑，像 CometAPI 這樣的 OpenAI 相容統一 API 可以降低整合工作。將模型選擇與備援政策保留在你的應用中，當某個必要功能無法符合共用契約時，使用供應商原生轉接器。
Grok 4.7 能直接呼叫 Python 函式嗎？
Grok 4.7 可以回傳結構化的函式呼叫請求。你的 Python 應用會解析請求、驗證它、執行允許清單中的函式，並將結果回傳給模型。模型本身不會執行本機 Python。
是否每個錯誤都應觸發切換到不同模型？
不應該。僅在選定的連線失敗、逾時、408、429 與暫時性的 5xx 回應時使用備援。無效請求、驗證失敗與不支援的參數應修正，而非送往另一個模型。
我可以對所有模型使用同一個工具結構綱要嗎？
只有在測試之後才可以。共用傳輸並不保證工具行為、引數品質、平行呼叫行為或結構綱要的強制一致。只有在通過代理契約測試後，才將某個模型加入備援鏈。
多模型備援系統是否等同於多代理系統？
不是。備援是在路由失敗後更換處理該請求的模型。多代理架構是將不同任務分派給不同代理。請將它們構建為不同層，並配備各自的測試與控制。