Factory OpenCompute 開放私人預覽：代理沙盒放進自家雲端，哪些資料仍要確認？

OpenCompute 讓企業把 AI 代理執行程式的沙盒放在自己控制的雲端或資料中心。

Factory 公開自架協調服務的私人預覽，目標是讓代理使用內部程式庫與服務，同時保留既有基礎設施安排。

沙盒是隔離執行任務的環境，但任務在哪裡跑，和模型在哪裡推論、對話存在哪裡，是不同設定。

因此，自家雲端執行不能直接解讀成所有資料都留在同一處，仍需要一起看模型與儲存路徑。

對已經有維運能力且需要內網存取的企業，這個選項值得評估；一般團隊則要把自行維護的工作量算進選擇。

要理解部署範圍，先看協調服務與控制平面如何分工。

OpenCompute 私人預覽提供什麼部署方式？

它在企業基礎設施中按需求建立沙盒，Factory 仍管理其生命週期。

協調服務負責在需要工作時建立執行環境，把可用資源準備給代理。它不像把助手裝到一台固定電腦，而是要接住不同任務對沙盒的需求。

Factory 官方文件說明，OpenCompute 在企業控制的基礎設施執行，Factory 控制平面提出需求，並管理沙盒的生命週期。

控制平面可以理解成安排與追蹤工作環境的管理部分。生命週期則包括環境建立、使用與結束，這些步驟需要和企業提供的資源接起來。

假設團隊同時有多項程式任務，每個任務需要自己的依賴與檔案，按需求建立沙盒就有機會減少彼此干擾，但仍要有足夠容量承接。

這裡的容量不是無限供應。企業能建立多少工作環境，仍受自己的設備、配置與維運安排影響，所以自架也要規劃尖峰需求。

私人預覽先確認支援，再安排試點

截至十月十五日的官方文件，這項服務仍是有限開放的私人預覽。實際先決條件與設定步驟由導入流程提供，不能假定每個帳號都能直接啟用。

因此，文章能協助理解部署選項，卻不能替所有企業提供通用安裝步驟。適合先確認的是支援的環境、團隊責任與試點範圍。

如果團隊原本沒有持續維護基礎設施的人，自架可能增加更多工作。任務在自己的環境跑，是一項控制能力，也伴隨更新、監控與容量管理。

對已有內部平台的組織，則可以評估是否沿用既有流程。能接進熟悉的環境，可能比另外維護一套特殊系統更容易長期運作，仍需實際驗證。

這項選擇最重要的前提，是知道為什麼需要控制執行位置。先把需求說清楚，後續才容易判斷 OpenCompute 解決的是哪一段問題。

這個分工會決定網路與內部系統如何連接。

沙盒如何連到內部程式庫與服務？

沙盒可從企業網路內接觸既有服務，協調程式則向外連接 Factory。

內部程式庫、套件來源與服務，常放在企業網路裡。代理如果在外部環境執行，要讀取它們就需要額外連線安排，這也是自架沙盒的用途之一。

官方描述沙盒可以從企業網路內接觸既有系統，協調服務則向外連接 Factory，因此不需為 Factory 開啟對內的防火牆入口。

這個方向說明連線如何建立，卻不等於任何內部資源都應開放。能連到網路與有權讀取指定程式庫，仍是不同的配置問題。

假設任務只需要某個測試專案，可以先限定該專案與所需工具。這樣既容易驗收，也能避免一開始就把所有內部服務都放進試點。

連線成功之後，還要確認任務真的能做完

可以從一次簡單的程式準備開始，例如取得測試專案、讀取依賴，再執行已知結果的檢查。這是建議流程，不是官方保證會自動替團隊測好的範例。

若程式庫可以讀到，套件卻無法取得，環境仍不能完成工作。把每個必要依賴列清楚，才能看出連線與權限缺在哪一段。

也要保留用到的版本。沙盒每次重新建立，若都讀到不同依賴，結果便可能改變，讓團隊誤以為是代理能力不穩定。

這種一致性可從既有開發流程借用，不必為代理另創一套完全不同的規則。重點是新環境能否重現團隊原本認可的工作條件。

任務結束後，還要知道哪些內容應保存、哪些只是暫存。沙盒被銷毀，不應讓唯一成果一起消失，也不能假定所有輸出都已交回。

因此，網路連接只是起點。資料取得、程式執行與成果交付串在一起，才算驗證代理確實能使用這個內部環境。

任務位置確定後，資料仍可能有其他流向。

執行環境、模型推論與對話儲存為何要分開？

三者可以有不同位置，所以要逐段確認處理路徑。

執行環境回答程式在哪裡跑，模型推論回答誰處理模型請求，對話儲存回答聊天與相關記錄存在哪裡。三段可以有不同位置。

推論就是模型接收輸入並產生結果的運算。即使程式在企業沙盒執行，應用仍可能依設定把部分內容送到另一處模型服務，不能只看主機位置。

官方文件特別把沙盒位置與模型、儲存設定分開。這是讀取資料路徑時的重要限制，不能把自家雲端執行改寫成所有內容都留在內網。

用一個任務畫出資料如何移動

假設代理讀取內部程式，再請模型提出修改，團隊需要知道傳送的是哪些內容。原始檔、摘錄或其他上下文，可能有不同處理需求。

接著看模型回覆如何回到執行環境，產生的檔案又保存在哪裡。只確認第一段讀取位置，會漏掉後面的推論與成果保存。

這是部署規劃建議，並非指出 OpenCompute 預設一定使用某種模型供應商。實際路徑由模型與資料設定決定，應按自己的組合確認。

對話內容也可能包含專案資訊。即使沒有直接上傳完整檔案，聊天摘要或錯誤訊息仍可能帶有工作脈絡，所以不能只盤點檔案傳輸。

如果企業有特定資料位置需求，可以先列出哪些內容受到要求，再逐段對照。這樣才能知道是執行位置已符合，還是模型與儲存也需要調整。

沙盒的隔離同樣需要實際設定支援。它提供分開任務的環境，但誰能存取、可連哪些服務與結果如何保存，仍要看完整部署方式。

當這三段資料路徑能清楚說明，團隊才有辦法比較選項。否則一句資料留在自己這裡，可能把不同服務責任與處理位置全部蓋住。

路徑清楚之後，才好和其他部署方式比較。

代管、自架與 Remote Control 怎麼選？

三種方式在供應與維護責任上不同，適合的工作規模也不同。

Factory 代管讓團隊使用供應好的執行資源，OpenCompute 則把按需求建立沙盒的部分放進自己控制的基礎設施，兩者的維護負擔不同。

Remote Control 官方文件則描述另一種方式：連接自己管理的電腦，讓 Factory 的程式代理 Droid 使用那台機器既有的開發環境。

這比較接近把已準備好的工作站帶進流程，而不是每次需要都自動供應新實例。官方也區分它與 OpenCompute 的按需求沙盒安排。

先看工作規模，再看控制需求

假設只有一位開發者偶爾使用自己的工作站，連接既有環境可能容易開始。若很多團隊同時需要獨立任務環境，就要另外考慮供應與容量。

反過來，工作規模很大，也不代表一定適合自架。若沒有內部系統存取或執行位置需求，維持一套基礎設施的工時可能超過得到的好處。

官方把代管列為多數團隊的預設建議。需要自家基礎設施時再考慮 OpenCompute，能讓選擇從具體需求出發，而不是只因自架聽起來更有控制。

比較時可以問，誰建立資源、誰更新環境、誰在故障時處理。這幾個問題能把部署名稱轉成實際工作，讓負責人知道自己承擔什麼。

也要看閒置與尖峰兩種狀況。自己提供容量時，平常用不到的資源仍可能有成本；尖峰超出容量，則要決定等待或增加資源的方式。

這些是成本結構的分析，不是特定方案的價格比較。沒有相同工作量與使用條件，不能只憑主機單價判定哪種方式一定較便宜。

最好的選擇應與團隊已有能力相配。若改用某種部署後，需要少數人長期手動補洞，便應把那段工時放回評估，而不是只看任務最後成功。

選擇自架時，維運責任需要有具體負責人。

企業試點該怎麼驗收與估算成本？

把建立、銷毀、故障恢復與資源用量一起測，才能看到完整維護成本。

試點可以先選不影響日常服務的專案，把環境建立、依賴取得、檢查與成果保存走完。這樣較容易分清平台配置問題與代理本身的問題。

每一步都要有可讀的結果。例如環境建立成功之後，應能執行指定檢查，而不是只有管理畫面出現一個名稱，就當作資源已完全可用。

假設任務中途失敗，也要觀察環境如何結束。能否保留必要紀錄、釋放資源並重新開始，會直接影響維運負擔與成本。

同時計算機器資源與人的時間

資源用量可以描述執行與閒置的消耗，人工時間則包括設定、監控、更新與故障處理。兩者一起看，才接近自行維護的完整成本。

如果初次設定需要較多時間，可以和後續常態操作分開記錄。這樣既不會把一次建置重複計入，也不會漏掉定期更新與修復的工作。

也可以在可控制的環境測一項常見失敗，看看值班人員能否根據紀錄處理。這是一般驗收建議，具體情境應由負責團隊依支援範圍安排。

如果每次都要原本的導入工程師協助，代表流程還沒完全交接。讓另一位同事按文件完成恢復，能看出哪些步驟仍依賴個人記憶。

任務結果也需要對回版本與來源。環境可靠，不表示模型修改一定正確，所以程式測試與審查仍要保留，避免把部署完成當成產品完成。

試點結束後，可以把成功次數、恢復時間與維護工時並列。若主要需求已滿足，且團隊能持續維護，再增加工作量會比較有依據。

私人預覽的下一步應回到正式導入窗口，確認可使用的範圍。先把支援條件與自己的試點結果對起來，再決定擴大，才能避免過早承諾部署成果。

試點也可以保留一項原本人工完成的相同工作作對照。若代理環境建立更快，卻讓後續成果整理變慢，完整流程的優勢便沒有單一指標看起來明顯。

這個比較讓導入決定更具體。團隊知道省下哪一段、增加哪一段，以及哪些問題能在下一輪修正，才不會只因部署成功就承諾更大範圍。

私人預覽階段先確認支援範圍，再決定是否擴大。

OpenCompute 常見問題

OpenCompute 現在人人都能直接啟用嗎？

官方仍標示有限開放的私人預覽，實際先決條件與設定由導入流程提供。

沙盒在自家雲端代表資料全部留內網嗎？

不能如此推定。模型推論與對話儲存是不同設定，需要一起確認資料路徑。

OpenCompute 與 Remote Control 相同嗎？

前者按需求建立企業沙盒，後者連接自己管理的既有電腦，供應與維護方式不同。

自架一定比較便宜嗎？

還要看容量、閒置、監控、更新與人工恢復時間，不能只比單一主機費用。

自架的價值，要由需求與維護能力一起決定

OpenCompute 提供控制執行位置的選項，但資料流向與營運責任仍要逐段確認。先用一個完整試點，證明環境可建立、結果可交付、故障可恢復，再評估是否擴大。

想持續看企業 AI 部署與代理工具的實際條件，可以免費訂閱 AI 郵報，追蹤功能之外的維運與資料路徑。

延伸閱讀：Runway Baseten 企業部署合作：專屬影片模型，值得哪些團隊評估？

延伸閱讀：TencentDB Agent Memory 是什麼？把 AI 工作記憶分層，本機儲存還要注意哪些事？

資料來源

• Factory OpenCompute 官方文件。
• Factory Remote Control 官方文件。