模型呼叫

這是什麼

Hermes 將構建好的上下文發送給所選模型提供者的時刻。

白話解釋

就像把信投入郵筒：你不需要知道或關心是哪輛卡車、哪架飛機或哪個快遞員實際把它送到目的地——你只要封好信封、投進去，它就出發了。模型呼叫就是那個交接點：Hermes 收集的所有內容被打包並發送給當前開啟的 AI 提供者，而對話循環的其餘部分無需知道或關心是哪個提供者。

為什麼重要

在對話上下文建構期間組裝的一切——歷史記錄、記憶、工具、護欄——都匯聚到一個狹窄的時刻：實際發送給當前配置的提供者（無論是本地還是託管）的請求。保持這個邊界的明確性，讓提供者可以在不觸及對話循環本身的情況下被更換，只需更改路由配置。這也是重試和後備邏輯最密切關注的時刻，因為提供者超時和速率限制會在對話中的任何其他地方之前在這裡出現。

運作方式

當對話循環準備好向模型提問時，build_api_kwargs（agent/chat_completion_helpers.py）會組裝實際的請求——訊息、工具、令牌限制、推理設定——格式符合當前啟用的傳輸方式：OpenAI 風格的聊天補全、Anthropic 的原生 Messages API、AWS Bedrock 的 Converse API 或 Codex 風格的 Responses。在發送任何內容之前，請求中介軟體會先有機會改寫它；然後一個 pre_api_request 插件鉤子會觸發，並帶有最終的請求，但該鉤子只能觀察它，不能更改它（agent/conversation_loop.py）。Hermes 偏好串流回覆，即使在沒有監聽即時文字的情況下也是如此，因為串流提供了精細的健康檢查——一個過時串流計時器和一個讀取超時——這是普通的阻塞請求無法提供的，可以在整個對話停滯之前捕捉到已經無響應的連線。

具體範例

使用者將 Hermes 配置為針對 OpenAI 相容端點，然後切換到 Anthropic。每次變更只需要更新提供者別名；build_api_kwargs 的其餘邏輯——附加工具、設定令牌限制——則保持不變。