假設節點已可用 launchd 常駐行程，且客戶端只認穩定別名與單一端點。鑑權見《LangGraph 與 OpenClaw 閘道》；退避見《JSON Schema 與重試範本》；觀測欄位見《OpenTelemetry GenAI 矩陣》。
痛點拆解
1）金鑰散落各應用程式時，稽核與輪換成本陡升。2）供應商改代號若無別名層，客戶端與 CI 同步受擊。3）熔斷若無每租戶併發與錯誤率視窗，難以保護毛利。
分層矩陣（誰做什麼）
| 層級 | 職責 | 失敗時先看 |
|---|---|---|
| OpenClaw 閘道 | 權杖 scope、租戶識別、對外錯誤摘要形狀 | 是否直連繞過閘道、反代是否剝標頭 |
| LiteLLM Proxy | model_list、別名、後備、上游逾時與重試 | 錯誤率、五〇三與讀逾時比例 |
| 遠端 Mac 節點 | 常駐行程、磁碟日誌、時鐘與網路穩定度 | 節點睡眠、磁碟水位、同機多服務埠衝突 |
實務上可將 LiteLLM 管理介面與指標埠一併綁在回環，維運經 SSH 隧道或零信任通道存取；對外僅暴露閘道 TLS。設定建議拆成可入庫的 router.yaml 與僅存於節點的 secrets.env，變更路由時先於測試別名驗證再切換正式別名，避免尖峰時段大範圍回滾。
部署、設定與驗收步驟
1）~/llm-edge 為設定根，權杖與環境檔 0600；上游金鑰僅供 LiteLLM 讀取，不入庫。
2）LiteLLM 綁 127.0.0.1；model_list 宣告路由與 fallbacks，並以 model_alias 對外給穩定名（如 prod-chat）。
3）閘道對外、內轉 LiteLLM；Dashboard 權杖僅含允許別名，落實最小權限。
4）每租戶併發與 QPS 預算，加滑動視窗熔斷與後備切換；門檻取自試跑 p95 與錯誤率。
5）閘道統一錯誤欄位：類型、是否重試、請求雜湊、建議退避秒；不回傳提示詞正文。
6）驗收：撤權杖、關單路由、灌五〇三，確認熔斷、後備與日誌鏈路。
- launchd 設定
StandardOutPath／StandardErrorPath並啟用日誌輪替，避免推理高峰灌滿磁碟。 - 閘道與 LiteLLM 分屬兩個 plist，先啟動 LiteLLM 再啟動閘道，避免啟動瞬間連線失敗被誤判為上游故障。
- 以環境變數注入
LITELLM_MASTER_KEY等管理金鑰時，權限與行程使用者須與執行使用者一致，避免多使用者誤讀。
# 煙霧：經閘道呼叫別名（示意）
curl -sS https://<閘道>/v1/chat/completions \
-H "Authorization: Bearer $OC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"model":"prod-chat","messages":[{"role":"user","content":"ping"}]}'可引用：閘道僅回環；權杖檔 0600；別名與實際端點對照表單一來源並納入變更紀錄；路由表變更後保留灰度別名至少一個發版週期；每條路由保存最近一次成功與失敗的供應商請求識別以利對帳。
排錯 FAQ
四零一且閘道無日誌？查路徑前綴與反代是否剝 Authorization；在機器本機用最小 curl 復現。
熔斷誤傷？勿共用同一視窗鍵；按租戶或模型分桶統計。
別名已改仍舊路由？重載 LiteLLM 並檢查外層快取 TTL。
小結：閘道管鑑權與錯誤形狀，LiteLLM 管上游路由與退避；分層後多模型才可擴充而不擴大金鑰面。