很多人想到把 AI 代理搬進雲端沙箱，會先問本機檔案是不是因此安全了。這個問題還要再拆一層：代理實際在哪裡執行、模型服務在哪裡、呼叫模型的 API 金鑰又由誰保管？Ollama 與 Fly.io 新增的 Connector 整合，讓 Fly.io Sprites 裡的代理可以呼叫 Ollama Cloud 模型，並把模型服務的金鑰留在 Fly.io 管理的連線設定中。它改變的是代理存取模型憑證的路徑，並不會自動替整個工作流完成安全治理。
一、先分清楚代理跑在哪裡、模型從哪裡來
Fly.io Sprite 是代理執行程式碼與工具的 Linux 雲端環境，Ollama Cloud 則是提供模型推論的服務；Connector 負責在兩者間轉送模型請求與管理 API 金鑰。
Sprite 可以保留檔案與已安裝的工具，供代理在不同工作階段延續使用。這代表它像一台遠端電腦，而非單純替模型加上一層網頁介面。Ollama Cloud 位於另一端，接收提示與上下文後回傳模型輸出。代理流程因此至少有三個不同的權限面：能在 Sprite 內執行的程式、能送到模型端的資料，以及能否呼叫特定 Connector。
Ollama 在 2026 年 10 月 13 日的公告描述，Sprites 是為代理設計、具有持續磁碟的 Linux 虛擬機；新 Connector 讓其中的代理使用 Ollama Cloud 模型。過去談代理雲端化常聚焦於 Harness，也就是管理代理循環、工具呼叫和執行狀態的控制程式。本次新增的重點則是模型服務的連線方式與憑證放置位置，並非一套全新的代理框架。
名稱相近也容易讓人混淆。Sprites 提供執行環境，Connector 是通往外部服務的閘道連線，Ollama Cloud 才是模型服務。這個 Connector 連的是 Ollama Cloud，不是開發者桌上的本機 Ollama Server。若既有流程依賴本機模型、區域網路中的服務或自訂端點，仍須另外設計網路可達性與授權方式，不能把兩種架構視為同一條連線。
二、Ollama Connector 如何把請求送到雲端模型
組織管理者先在 Fly.io 建立 Ollama Connector 並設定 API key，再授權指定 Sprite 使用；Sprite 將請求送到 gateway，閘道辨識呼叫環境後附加金鑰並轉送給 Ollama Cloud。
依 Ollama 公告，Fly.io 會加密保存管理者設定的 key，API 不會再把原始金鑰回傳。Sprite 端取得的是 gateway URL 與 connection ID，沒有必要把真正的 Ollama key 寫進環境變數、設定檔或代理提示。connection ID 用來指向該連線，gateway URL 則是請求入口，兩者都不是模型憑證的替代品。
常見 API 用法是把相容用戶端的 base_url 指向 gateway，再照服務要求傳送模型名稱、訊息與其他參數。公告也示範可用 OpenAI SDK，相容端點包含聊天請求；Ollama 原生 /api/* 路徑亦可經過 gateway。程式庫仍需支援相應 API 格式，代理設定也得知道該使用哪個 URL、模型名稱與可用工具。用戶端若堅持要求真實 API key，佔位字串是否可用要依該用戶端行為及官方範例測試，不能假設所有工具都能直接套用。
「The Sprite itself only knows a gateway URL and a connection ID.」可譯為「Sprite 本身只知道 gateway URL 與 connection ID。」這是 Ollama 對整合架構的說明，描述的是憑證如何傳遞，不是對所有資料外洩情境的獨立安全保證。— Ollama 官方公告，〈Run AI agents safely with Ollama and Fly.io〉
設定時也要確認授權主體。能建立或修改組織 Connector 的人，通常能決定哪些 Sprite 具備使用權；能執行已獲授權 Sprite 的人，則可能透過代理代表工作流呼叫該模型服務。因此，「代理讀不到原始 key」不等於「代理不能使用付費服務」，費用、模型存取範圍和誰能啟動任務仍應納入組織權限設計。
三、雲端沙箱能隔離哪些風險，哪些仍要自行處理
Sprite 可把代理執行環境與開發者本機分開，Connector 可避免把 Ollama key 直接放進 Sprite；但已同步進去的資料、其他憑證、工具權限與外部網路存取仍須分別管理。
第一條界線是執行位置。代理若在雲端 Sprite 執行，通常不會直接讀取開發者筆電上的檔案或呼叫僅在本機安裝的工具。但只要使用者把程式碼、提示、測試資料或文件複製、掛載或同步到 Sprite，代理就可能讀取其執行環境可見的內容。沙箱隔開的是環境，不能撤回已送入環境的資料，也不能替資料分類或決定哪些內容可以交給模型。
第二條界線是憑證。Connector 可以讓 Ollama API key 留在 Fly.io 管理的連線中，由 gateway 代為附加。這降低了代理直接讀取這把 key 的機會，但不涵蓋工作流裡其他秘密。若 Sprite 還有 GitHub token、雲端服務憑證、資料庫密碼或其他 API key，它們不會因為設定 Ollama Connector 就自動獲得同樣保護。應逐一檢查環境變數、檔案、代理工具和同步流程，確認秘密是否真的必要、有效範圍是否足夠小。
第三條界線是代理可做的事。Connector 的授權對象與資料路徑，和代理能否執行 shell 指令、讀寫專案、使用其他工具或連上任意網址，是不同設定。Fly.io 的 Sprites 生態系說明目前可依 Sprite 標籤或名稱前綴設定存取範圍，並提醒各組織看到的 Connector 可能因 rollout 進度不同。管理者應在控制台核對當下可用項目與實際政策，並確認新連線預設拒絕未授權的 Sprite。
提示注入也不會因執行環境移到雲端就消失。代理可能讀到惡意 README、Issue 內容或網頁文字，進而試圖使用已授權的工具。若 Connector 可用，威脅重點會從「偷出原始 key」轉向「濫用已授權的服務」或「把資料送往不該去的目的地」。限制外連、縮小 Connector 授權對象、縮小可呼叫端點、審查代理工具和保留可追查的日誌，仍是部署者的工作。
Fly.io 官方 Connector 說明將這種模式概括為憑證由控制平面保存、每次請求經由 gateway 轉送。該產品文件有助理解設計意圖，但屬供應商描述；目前沒有獨立測試可據此量化所有威脅下的資料外洩率，也不能由金鑰不進 Sprite 推論其餘安全風險已消除。
「The raw token stays in Fly.io’s control plane (encrypted) and is attached to the request on the way out.」可譯為「原始 token 以加密方式留在 Fly.io 控制平面，並在請求送出時附加。」這段產品文件說明 Connector 的憑證路徑；工作流仍須另訂資料與工具政策。— Fly.io 官方 Connector 說明
四、接進既有代理流程要改哪些環節
先建立 Connector、設定允許使用的 Sprite 並測試連線，再調整代理的模型端點、資料同步與權限設定；同時檢查費用、延遲和環境維護責任。
實際操作從 Fly.io 組織控制台開始：新增 Ollama Connector，輸入 Ollama Cloud API key，設定允許存取的 Sprite，再對獲准的環境測試可達性。Fly.io 生態系文件指出，Connector 可按標籤或名稱前綴授權，並提醒不同組織的功能 rollout 可能不同。正式部署前，應以自己的控制台與該 Connector 頁面提供的呼叫範例為準，而非照搬別人的 connection ID 或假定介面完全一致。
接著在 Sprite 內設定代理使用的 base URL、connection ID、模型名稱與必要的請求格式。用一個不含敏感資料的測試提示確認請求能抵達模型並收到回應，再檢查錯誤處理：連線被拒、模型名稱錯誤、服務逾時或組織撤銷授權時，代理會停止、重試還是改走其他服務？沒有明確失敗路徑的自動重試，可能重複送出資料或增加不預期的模型費用。
對既有工作流來說，較費工的部分往往是周邊整合。原本讀本機目錄的代理需要改成取得明確的專案副本；使用本機 Ollama 的流程要換成雲端端點；需要 Git 操作、套件下載或部署的任務，還得安排其他憑證與網路政策。需決定哪些資料可同步、同步多久、完成後如何清除，以及誰有權建立或啟動可呼叫 Connector 的 Sprite。
成本不能只看模型 token 或 API 帳單。雲端執行環境可能有運算、儲存與資料傳輸費用，專案複製和依賴安裝也會增加啟動時間。遠端環境與本機之間的網路往返會影響互動延遲；代理若仰賴本機 GUI、硬體或未整理的檔案，可能需要重做整個操作流程。這些代價需依自己的任務測量，官方整合公告沒有提供足以推估各團隊總成本或延遲的獨立基準。
| 評估面向 | Sprite＋Ollama Connector | 本機代理＋本機或直接模型端點 |
|---|---|---|
| 執行位置 | Fly.io 雲端 Linux 環境 | 開發者本機或自建環境 |
| Ollama key | 由 Connector 管理，gateway 轉送 | 依部署方式由本機端點或設定管理 |
| 專案資料 | 需明確同步或傳入雲端 | 可直接讀取本機授權範圍內的資料 |
| 權限治理 | Sprite 存取政策、Connector 與其他工具分別設定 | 本機帳號、工具與憑證設定需自行管理 |
| 主要取捨 | 適合遠端持續執行，增加雲端資料與成本管理 | 可貼近本機工具，須留意本機資料和秘密暴露面 |
表格比較的是部署特性，不代表其中一種對所有任務都較安全。真正的差異取決於代理可見哪些檔案、獲准呼叫哪些服務，以及人員如何管理授權。
五、哪些工作流適合先搬進 Sprite 評估
需要在遠端持續執行、工作資料範圍可明確界定，且可以用程式介面操作的任務較適合先評估；依賴本機應用、廣泛權限或未整理敏感資料的流程，應先重畫信任邊界。
程式碼生成、測試、模糊測試與可重現的建置流程，通常比較容易切出低敏感度範圍。團隊可準備一份專用的測試專案，讓 Sprite 只取得必要檔案，透過 Connector 呼叫模型，再將輸出交由人員檢查。這種試行方式能觀察環境啟動、依賴安裝、模型請求和失敗復原是否符合現有工作節奏。
相對地，若代理要操作桌面應用、讀取大量未分類文件、接觸客戶資料，或使用可以修改正式環境的憑證，單純換成雲端執行位置並不足夠。先確認哪些資料必須留在本機、哪些可以上傳、模型服務會接收什麼內容，再決定是否將任務拆成有明確輸入輸出的階段。工作流若有多種秘密，要逐項核對，而不是只看 Ollama key 是否已離開 Sprite。
根因通常在權限設計，而非 VM 名稱。若代理因為能做的事情太多而有風險，將它移到另一台電腦不會自動縮小權限；如果真正問題是本機憑證暴露，Connector 可以改變一項重要的憑證路徑，但仍要盤點其他憑證與資料。先問清楚「代理為何需要這項存取」，才能決定是使用 Connector、移除工具、縮小資料集，還是保留本機流程。
可以用下列清單檢視試行設計：
- 列出代理讀取的資料、寫入位置、模型請求內容與需同步的檔案。
- 列出 Ollama 以外的 token、雲端憑證、工具與網路目的地，標出各自的負責人。
- 僅授權指定 Sprite 使用 Connector，確認組織內誰可建立、修改與啟動連線。
- 以低敏感度任務測試正常回應、拒絕授權、逾時、錯誤重試和撤銷存取等情境。
- 記錄運算和模型帳務、延遲、日誌保留與資料清除方式，再決定是否擴大任務範圍。
這份檢查表的目的，是讓團隊在導入前說清楚資料、憑證、權限、網路、成本與復原方式。若無法回答誰授權、代理看得到什麼、失敗後如何撤銷，就先縮小試行範圍。
六、從一個受限任務開始驗證整合效果
先選資料少、權限低、失敗後可復原的任務，追蹤整條請求與資料路徑；只有在權限、錯誤處理、成本與維護方式都符合需求後，才擴大使用。
試行前先定義通過條件，例如代理只能看到指定專案、只有列入政策的 Sprite 能呼叫 Connector、金鑰不出現在環境與日誌、失敗時不會無限重試。這些是團隊自己的驗收標準，不是 Ollama 或 Fly.io 公告替所有使用者提供的安全認證。設定過程要保留可核對的紀錄，包括誰建立連線、誰授權 Sprite、測試使用了哪些資料，以及錯誤時請求如何處置。
接著用實際任務檢查產出品質和操作成本。模型回覆能否融入既有工具鏈？資料同步、環境初始化與清理需要多少人工？端到端延遲是否影響工作？停止 Sprite 或撤銷 Connector 後，資料與日誌如何處理？回答這些問題，才能看出雲端執行帶來的便利是否足以抵銷額外的資料管理和帳務工作。
若結果不理想，先回頭定位是哪一層卡住：模型 API 格式、代理設定、資料輸入、遠端工具或權限政策。這些原因需要不同修正方式，不宜把全部問題都歸因於沙箱效能。對產品整合題材，目前主要依據是 Ollama 與 Fly.io 的官方公告和產品文件；這些資料足以說明設計與操作方式，卻沒有獨立測試可量化不同團隊的安全成效、速度或總成本。
適合評估的工作流，通常具備明確輸入、明確授權和可復原的輸出。先挑一個失敗後容易重做的低敏感度任務，盤點資料、憑證、網路和使用者權限，再讓受限 Sprite 跑完一次。把日誌、花費、延遲與復原結果記下來，才有依據判斷是否擴大使用。
- Sprite 提供代理執行環境，Ollama Cloud 提供模型，Connector 管理兩者間的請求與 Ollama API key。
- Connector 可避免原始 Ollama key 直接進入 Sprite，但不會自動限制其他憑證、已同步資料、工具或外部網路。
- 先用資料範圍明確、可復原的任務試行，核對權限、錯誤處理、帳務、延遲與日誌後再擴大。
常見問題
先確認使用的是 Ollama Cloud Connector、組織控制台已開放該功能，以及 Sprite 的授權、資料與其他工具權限都已分開檢查。
常見問題
Q1：Sprite 能連到我電腦上的 Ollama 嗎？
這項 Connector 整合連接的是 Ollama Cloud，不是開發者電腦上執行的 Ollama Server。若要連本機服務，需另行規劃遠端網路路徑、驗證和防火牆規則，並確認服務確實對 Sprite 可達。
Q2：API key 不在 Sprite 裡，是否代表代理無法使用模型？
不是。獲准使用 Connector 的 Sprite 可透過 gateway 發出模型請求，由閘道附加組織設定的金鑰。代理不必讀到原始 key 才能使用模型，所以還要管理誰可授權 Sprite、誰能啟動工作流，以及模型費用如何歸屬。
Q3：這種架構會自動阻止代理存取外部網路嗎？
不能這樣推論。Connector 控制特定服務連線與授權，代理的其他工具和網路流量仍須另外設定。部署前要核對 Sprite 的網路政策、可用工具、資料同步範圍與日誌留存。
