若要讓不可信開發環境呼叫 AI 服務，同時開放小程式供使用者試用，關鍵不是多加幾層基礎設施，而是讓不同使用者只拿到完成任務所需的權限。

建議採用同一個原則：**網關留在可信 VPS，可信業務後端負責對外接入。**開發環境使用受限的開發入口；小程式則只呼叫業務功能。這樣不必一開始就部署 Nginx、負載平衡器或複雜防火牆，但也不能因此承諾完全沒有額外延遲。

先補上目前的安全缺口

在採用這個架構前，現有程式有幾項需要處理的地方：

• 啟動入口預設監聽所有網卡，而非只監聽本機。依據：main.go。可信 VPS 上的網關應明確綁定本機回環位址，避免直接暴露在公網。
• 主路由尚未接入呼叫端認證，並註冊了模型目錄、統計與兩組聊天路徑。依據：internal/api/chat.go。不能只因客戶端填了密鑰，就假設入口已受到保護。
• 專案有舊版 Gin 認證中介層，但目前啟動鏈使用標準 HTTP 路由；已檢視的主路由並未呼叫該中介層。依據：middlewares/auth.go、main.go。單靠設定舊版認證環境變數，無法證明目前入口安全。
• 現有准入設定明確屬於本機測試用途，且要求每個客戶端的額度為零，不能直接視為可用的正式多使用者限流機制。依據：internal/chatadmission/config.go、internal/chatadmission/config.go。

不可信開發環境：遠端呼叫，不在那裡部署網關

建議的請求路徑是：

不可信開發 VPS → HTTPS 受限開發入口（可信業務後端）→ 私有連線 → 可信 VPS 上的網關

原始碼、建置流程、網關執行個體與上游憑證都留在可信環境。不可信 VPS 只取得呼叫網址及開發專用憑證。

開發入口可以保留既有客戶端需要的聊天協定，但只開放必要的 HTTP 方法、路徑與模型；不要提供統計、管理、任意轉送或帳號能力。每個開發環境應有獨立、可撤銷且有效期較短的憑證，並搭配模型白名單、請求大小限制、並發限制與累計預算。開發憑證不可與正式業務憑證共用。

憑證驗證與預算扣除都必須在可信後端執行，不能倚賴不可信環境內的設定或檢查程式。若環境的主機管理員不可信，就應假設該環境內的憑證、請求與回應都可能遭讀取或竄改。短期憑證只能縮小洩漏後的損失，不能避免憑證被偷；一般容器、二進位檔散布或程式混淆，也不能保證對主機管理員保密。

因此，目標不是把主密鑰放進不可信 VPS，並期待它無法被竊取；而是讓主密鑰不進入該環境，並將開發權限設計成可撤銷、損失有上限。真正敏感的開發內容仍應留在可信環境。

也不建議讓不可信 VPS 透過 SSH 隧道直連目前沒有認證的網關：隧道身分一旦遭竊，限制就可能被繞過。若必須使用隧道，應只讓它連到受限的開發入口，而不是原始網關或其他私有網路服務。

小程式公開試用：開放業務功能，不開放通用網關

建議的請求路徑是：

微信小程式 → 可信業務後端（登入、額度、Agent）→ 私有連線 → 網關 → 上游模型

小程式沿用業務登入狀態。微信官方流程是由客戶端取得臨時登入憑證，再由伺服器換取使用者識別資訊並建立自訂登入狀態；session_key 不應下發到客戶端。9

小程式只提交職缺描述、職位要求與必要的個人經歷，不持有網關主密鑰，也不應直接選擇任意模型、系統提示或工具。可在既有後端新增「個人亮點優化」業務入口，由後端固定可用模型、提示模板、搜尋能力與輸出格式，而不是把一個不受限制的聊天代理直接透給使用者。

使用者身分應從後端驗證過的登入狀態取得，不能信任請求內容自行申報的使用者 ID。後端應按使用者管理任務、上下文與額度，避免不同使用者共用歷史紀錄。

公開試用可以免費，但仍須設好每位使用者的額度、每個任務可呼叫模型與工具的次數、輸入和輸出上限，以及全站總預算與緊急停用開關。多步驟 Agent 應由後端執行，每一步都計入同一任務預算；取消、逾時和重試也必須受限，避免探索迴圈不斷放大呼叫量。若後端使用多個工作程序，額度預留與結算應透過既有資料庫的交易能力統一管理，不能讓每個程序各自計算一份總預算。

小程式可繼續使用既有 HTTPS 業務網域。微信一般網路通訊要求事先設定允許的伺服器網域，因此沒有必要另外向小程式公開網關網域。7

私有連線與延遲：先沿用既有 SSH 隧道

若業務後端與網關位於同一台可信主機，優先使用本機連線；若分屬兩台可信主機，第一階段可沿用既有常駐 SSH 隧道，由可信業務後端連到網關，不要每次請求都重新建立隧道。

SSH 應使用專用、僅具連接埠轉送權限的身分，並限制可轉送的目標連接埠。網關綁定本機位址；隧道中斷時應拒絕呼叫，而不是退回沒有保護的公網入口。只有在受控的內部連線中，且確認同一主機上的其他程序也在信任範圍內時，才考慮保留空呼叫密鑰。任何面向不可信環境的入口，都必須實際驗證獨立憑證。

只有在測量確認現有隧道成為瓶頸後，才考慮改用 WireGuard 連接兩台可信主機。WireGuard 支援依對端金鑰進行驗證與加密，但這不代表你的實際連線一定會更快。1216

這個方案不需要新增第三方中轉，也不要求再部署一層反向代理。業務後端應盡量重用連線、即時轉送串流輸出，並在小程式中斷連線時通知正在執行的任務。

目前沒有足夠證據能預先判定額外延遲有多少。建議分別測量後端至網關的網路耗時、首段輸出的時間與整個任務的耗時，並比較中位數及高分位數；中國大陸至網關與上游的實際線路，也需要另行驗證。

另外，「快速模型」不能只看名稱。現有候選測試要求預設仍維持深度模式、高推理與詳細輸出，且明確不代表真實上游可用性或延遲已獲驗證。依據：internal/upstream/studioglobal/registry_fast_models_test.go、internal/upstream/studioglobal/registry_fast_models_test.go。建議為「個人亮點優化」另設輕量業務預設並實測，不要直接改動既有開發預設。

建議的最小實施順序

1. 收緊網關監聽範圍，確認公網與不可信開發環境都不能繞過後端直連網關。
2. 在可信後端建立兩個權限域：受限的開發呼叫，以及公開試用的業務呼叫；憑證與預算分別管理。
3. 實作有界 Agent、額度預留、取消傳遞與串流輸出，並保留全站預算上限。
4. 驗收無憑證或已撤銷憑證會遭拒、開發權限無法存取管理路徑、額度用盡即停止、使用者上下文彼此隔離，以及多步呼叫與重試不會突破任務預算。
5. 先小規模試用並測量延遲，再決定是否更換私有傳輸方式或拆分執行個體。

開放前仍需確認的事項

第一階段不需要建置負載平衡、服務網格或永久 Agent 平台；相應取捨是接受單一執行個體可能故障，以及容量有上限。這是一項架構建議，並不代表已完成安全部署或驗證；本次也沒有進行實作、部署、測試，或寫入 ADR 與計畫文件。

此外，上游是否允許面向公眾提供試用、個人經歷資料實際會流向何處，以及相關合規要求，目前都缺乏足夠資訊，正式開放前應先確認。建議只提交必要且盡量去識別化的資料，並避免記錄完整履歷正文或憑證。

整體而言，最重要的界線是：**原始碼與主憑證留在可信環境；開發端只拿受限權限；小程式只拿業務能力；內部連線沿用受控私有通道。**先補齊認證、預算和任務邊界，再考慮增加基礎設施層數。

若要讓不可信開發環境呼叫 AI 服務，同時開放小程式供使用者試用，關鍵不是多加幾層基礎設施，而是讓不同使用者只拿到完成任務所需的權限。

建議採用同一個原則：**網關留在可信 VPS，可信業務後端負責對外接入。**開發環境使用受限的開發入口；小程式則只呼叫業務功能。這樣不必一開始就部署 Nginx、負載平衡器或複雜防火牆，但也不能因此承諾完全沒有額外延遲。

先補上目前的安全缺口

在採用這個架構前，現有程式有幾項需要處理的地方：

• 啟動入口預設監聽所有網卡，而非只監聽本機。依據：main.go。可信 VPS 上的網關應明確綁定本機回環位址，避免直接暴露在公網。
• 主路由尚未接入呼叫端認證，並註冊了模型目錄、統計與兩組聊天路徑。依據：internal/api/chat.go。不能只因客戶端填了密鑰，就假設入口已受到保護。
• 專案有舊版 Gin 認證中介層，但目前啟動鏈使用標準 HTTP 路由；已檢視的主路由並未呼叫該中介層。依據：middlewares/auth.go、main.go。單靠設定舊版認證環境變數，無法證明目前入口安全。
• 現有准入設定明確屬於本機測試用途，且要求每個客戶端的額度為零，不能直接視為可用的正式多使用者限流機制。依據：internal/chatadmission/config.go、internal/chatadmission/config.go。

不可信開發環境：遠端呼叫，不在那裡部署網關

建議的請求路徑是：

不可信開發 VPS → HTTPS 受限開發入口（可信業務後端）→ 私有連線 → 可信 VPS 上的網關

原始碼、建置流程、網關執行個體與上游憑證都留在可信環境。不可信 VPS 只取得呼叫網址及開發專用憑證。

開發入口可以保留既有客戶端需要的聊天協定，但只開放必要的 HTTP 方法、路徑與模型；不要提供統計、管理、任意轉送或帳號能力。每個開發環境應有獨立、可撤銷且有效期較短的憑證，並搭配模型白名單、請求大小限制、並發限制與累計預算。開發憑證不可與正式業務憑證共用。

憑證驗證與預算扣除都必須在可信後端執行，不能倚賴不可信環境內的設定或檢查程式。若環境的主機管理員不可信，就應假設該環境內的憑證、請求與回應都可能遭讀取或竄改。短期憑證只能縮小洩漏後的損失，不能避免憑證被偷；一般容器、二進位檔散布或程式混淆，也不能保證對主機管理員保密。

因此，目標不是把主密鑰放進不可信 VPS，並期待它無法被竊取；而是讓主密鑰不進入該環境，並將開發權限設計成可撤銷、損失有上限。真正敏感的開發內容仍應留在可信環境。

也不建議讓不可信 VPS 透過 SSH 隧道直連目前沒有認證的網關：隧道身分一旦遭竊，限制就可能被繞過。若必須使用隧道，應只讓它連到受限的開發入口，而不是原始網關或其他私有網路服務。

小程式公開試用：開放業務功能，不開放通用網關

建議的請求路徑是：

微信小程式 → 可信業務後端（登入、額度、Agent）→ 私有連線 → 網關 → 上游模型

小程式沿用業務登入狀態。微信官方流程是由客戶端取得臨時登入憑證，再由伺服器換取使用者識別資訊並建立自訂登入狀態；session_key 不應下發到客戶端。9

小程式只提交職缺描述、職位要求與必要的個人經歷，不持有網關主密鑰，也不應直接選擇任意模型、系統提示或工具。可在既有後端新增「個人亮點優化」業務入口，由後端固定可用模型、提示模板、搜尋能力與輸出格式，而不是把一個不受限制的聊天代理直接透給使用者。

使用者身分應從後端驗證過的登入狀態取得，不能信任請求內容自行申報的使用者 ID。後端應按使用者管理任務、上下文與額度，避免不同使用者共用歷史紀錄。

公開試用可以免費，但仍須設好每位使用者的額度、每個任務可呼叫模型與工具的次數、輸入和輸出上限，以及全站總預算與緊急停用開關。多步驟 Agent 應由後端執行，每一步都計入同一任務預算；取消、逾時和重試也必須受限，避免探索迴圈不斷放大呼叫量。若後端使用多個工作程序，額度預留與結算應透過既有資料庫的交易能力統一管理，不能讓每個程序各自計算一份總預算。

小程式可繼續使用既有 HTTPS 業務網域。微信一般網路通訊要求事先設定允許的伺服器網域，因此沒有必要另外向小程式公開網關網域。7

私有連線與延遲：先沿用既有 SSH 隧道

若業務後端與網關位於同一台可信主機，優先使用本機連線；若分屬兩台可信主機，第一階段可沿用既有常駐 SSH 隧道，由可信業務後端連到網關，不要每次請求都重新建立隧道。

SSH 應使用專用、僅具連接埠轉送權限的身分，並限制可轉送的目標連接埠。網關綁定本機位址；隧道中斷時應拒絕呼叫，而不是退回沒有保護的公網入口。只有在受控的內部連線中，且確認同一主機上的其他程序也在信任範圍內時，才考慮保留空呼叫密鑰。任何面向不可信環境的入口，都必須實際驗證獨立憑證。

只有在測量確認現有隧道成為瓶頸後，才考慮改用 WireGuard 連接兩台可信主機。WireGuard 支援依對端金鑰進行驗證與加密，但這不代表你的實際連線一定會更快。1216

這個方案不需要新增第三方中轉，也不要求再部署一層反向代理。業務後端應盡量重用連線、即時轉送串流輸出，並在小程式中斷連線時通知正在執行的任務。

目前沒有足夠證據能預先判定額外延遲有多少。建議分別測量後端至網關的網路耗時、首段輸出的時間與整個任務的耗時，並比較中位數及高分位數；中國大陸至網關與上游的實際線路，也需要另行驗證。

另外，「快速模型」不能只看名稱。現有候選測試要求預設仍維持深度模式、高推理與詳細輸出，且明確不代表真實上游可用性或延遲已獲驗證。依據：internal/upstream/studioglobal/registry_fast_models_test.go、internal/upstream/studioglobal/registry_fast_models_test.go。建議為「個人亮點優化」另設輕量業務預設並實測，不要直接改動既有開發預設。

建議的最小實施順序

1. 收緊網關監聽範圍，確認公網與不可信開發環境都不能繞過後端直連網關。
2. 在可信後端建立兩個權限域：受限的開發呼叫，以及公開試用的業務呼叫；憑證與預算分別管理。
3. 實作有界 Agent、額度預留、取消傳遞與串流輸出，並保留全站預算上限。
4. 驗收無憑證或已撤銷憑證會遭拒、開發權限無法存取管理路徑、額度用盡即停止、使用者上下文彼此隔離，以及多步呼叫與重試不會突破任務預算。
5. 先小規模試用並測量延遲，再決定是否更換私有傳輸方式或拆分執行個體。

開放前仍需確認的事項

第一階段不需要建置負載平衡、服務網格或永久 Agent 平台；相應取捨是接受單一執行個體可能故障，以及容量有上限。這是一項架構建議，並不代表已完成安全部署或驗證；本次也沒有進行實作、部署、測試，或寫入 ADR 與計畫文件。

此外，上游是否允許面向公眾提供試用、個人經歷資料實際會流向何處，以及相關合規要求，目前都缺乏足夠資訊，正式開放前應先確認。建議只提交必要且盡量去識別化的資料，並避免記錄完整履歷正文或憑證。

整體而言，最重要的界線是：**原始碼與主憑證留在可信環境；開發端只拿受限權限；小程式只拿業務能力；內部連線沿用受控私有通道。**先補齊認證、預算和任務邊界，再考慮增加基礎設施層數。