OpenAI 6/12 收購 Ona（前 Gitpod）完整解析：Codex VPC 部署實況、中小企業 AI Coding 採購 5 個訊號 + 60 天行動清單

你的 AI Coding 工具，到底是在客戶的機器上跑，還是在別人的雲端跑？這個問題聽起來像技術細節，但 6/12 OpenAI 宣布收購 Ona（前身為 Gitpod） 之後，它突然變成了一份合約條款、一個採購決策、甚至一個資料主權問題。

我們在自己的開發流程裡每天都在跑 20+ 個 AI 自動化流程，其中包括 Codex 的 agent 任務。6/12 那天早上看到這則消息，第一個反應不是「OpenAI 又出手了」，而是：「這代表 long-running agent 的戰場，終於從 SaaS demo 移到企業 VPC 裡了。」

收購消息由 The Next Web 最先報導，CNBC 隨後跟進確認，InfoWorld 的技術分析也很值得一讀。Codex 周活躍用戶超過 500 萬，年增率 400%——這個數字告訴你：AI Coding agent 的擴張速度，早就超過大多數企業評估採購的節奏。

本文為中小企業老闆拆解這件事的真正意義：Ona 是誰、這筆收購想解決什麼問題、對競爭格局的影響，以及——最重要的——你在評估 AI Coding 採購時需要看的 5 個訊號和接下來 60 天的具體行動清單。

Ona 是誰：從 Gitpod 到 AI Agent 編排平台的演進

Ona 的前身是 Gitpod，2020 年由 Johannes Landgraf 等人創立於德國 Kiel。如果你在軟體圈，Gitpod 這個名字應該不陌生——它做的是「把開發環境搬到雲端」，讓工程師打開瀏覽器就能進入一個已配好環境的 VS Code，不需要本機設定。

Gitpod 解決的痛是真實的：新人 onboarding 要花一天 setup 環境、不同機器上環境不一致導致「在我電腦上跑得好好的」問題、跨時區協作時環境同步困難。它用 ephemeral（一次性）開發環境解決這些問題，在 DevOps 社群積累了一批忠實用戶。

但 Gitpod 在 2025 年做了一個關鍵的策略轉向：把自己重新定位為 AI agent 編排平台，更名為 Ona，主攻「讓 AI agent 有一個持久化、隔離、可管理的執行環境」。這個轉向，恰好對準了整個 AI Coding 生態系的最大缺口——agent 關機後任務就中斷。

Ona 的核心技術建立在三層：(1) Secure cloud 平台，提供隔離的執行沙盒；(2) 持久化開發環境，agent 能在開發者離線後繼續工作；(3) AI agent 編排層，管理多個 agent 的任務佇列、上下文切換與結果回寫。這三層加在一起，恰好是 Codex 要做「long-running task」欠缺的那塊基礎建設。

對台灣企業特別值得注意的是：Gitpod 在台灣工程圈已有一批使用者，SiliconAngle 的分析 指出這次收購主要是技術與人才的戰略取得，Gitpod 原有的開源生態系（gitpod.io）後續走向仍待觀察。

收購的真正意義：long-running agent 是主戰場，VPC 內運行才是關鍵

表面上，這是一筆「AI 公司收購開發工具公司」的新聞。但如果只這樣看，你會錯過最重要的那層。

Codex 需要解決的問題：agent 不能「睡覺」

Codex 原本的使用方式是：你給它一個任務，它在 session 裡執行，執行完結束。如果任務需要 30 秒，沒問題；如果需要 3 小時——codebase 現代化、批次漏洞掃描修補、大型 refactoring——Codex 以前做不到，因為它沒有一個可以在你關電腦後繼續跑的執行環境。

Ona 提供的正是這個環境。有了 Ona，Codex 能在客戶關機後繼續執行 agent 任務，第二天早上回來看結果。這件事的意義遠不只是「方便」——它讓 AI Coding 從「對話工具」升級為「數位同事」，有自己的工作佇列、有任務優先序、有持續工作的能力。

具體的長時間任務場景包括：把一個 10 萬行 legacy codebase 從 Python 2 遷移到 Python 3（估計需要 4-8 小時）、全站 dependency 掃描並批次更新（常見 2-6 小時）、大型測試套件生成（依 codebase 規模 1-5 小時不等）。這些任務過去要工程師盯著跑，或拆成多個 session 手動銜接。Long-running agent 讓這些成為「丟任務、去睡覺、隔天看結果」的工作流。

VPC 內運行：企業合規的最後一道牆

這才是這筆收購最值得中小企業老闆關注的部分。OpenAI 的計畫是讓 Codex 能在客戶自己的 VPC（虛擬私有雲）內運行 agent——也就是說，你的 source code 不需要離開你自己掌控的雲端環境。

這直接打掉了企業採用 AI Coding 工具的最大合規顧慮：「我的程式碼會不會被 OpenAI 拿去訓練模型？」VPC 內部署讓資料不出境，讓程式碼在你可審計的環境裡被處理。這個設計對受 SOC 2、ISO 27001、GDPR 約束的企業非常重要。

我們的判斷是：這場 long-running agent 競賽，最終會走向「VPC 內運行 + 治理層」之爭，而不是單純的功能比拼。廠商鎖定的深度，會從「你的工程師習慣用哪個工具」升級為「你的合約裡寫著 agent runtime 落在哪裡」。這對採購方來說，是一個層級完全不同的問題。

競爭格局：long-running agent 四強的牌局

OpenAI 收購 Ona 不是在真空中發生的。整個 AI Coding 生態系在過去半年同時向「long-running agent」這個方向推進，形成一場多方競賽。

從競爭格局看，Anthropic 的 Claude Code 是 Codex 最直接的競品。Claude Code 在工程師社群的口碑 不差，但它目前欠缺原生的持久化 agent runtime——這是 OpenAI 透過 Ona 想填補的差距。也可以對照我們早先分析的 Codex vs Claude Code 完整比較，了解兩者在功能與費用上的差異。

Google 的 Antigravity 方案（詳細解析在這篇）走的是另一條路：深度整合 GCP 基礎設施，對已在 Google 雲上的企業有天然優勢，但對非 GCP 客戶形成高牆。

OpenCode、Aider 等開源方案（比較見這篇）走的是 self-host 路線，VPC 部署對它們來說從一開始就是預設選項。這反而是這波競賽中對小型工程團隊最友善的選擇，尤其是預算有限、對廠商鎖定風險敏感的中小企業。

Codex 插件生態系的另一面

除了 agent runtime，OpenAI Codex 的插件方向 也值得一提。Codex 在今年陸續開放垂直行業插件，讓 Coding agent 能跟 Jira、Confluence、GitHub Actions 等工具連線——這代表 long-running agent 的工作範圍，已經從「寫程式」擴張到「在整個工程工作流裡協作」。結合 Ona 的持久化能力，這個組合的潛力確實值得關注。

另一個值得追蹤的方向是 Claude Managed Agents。Anthropic 推出 Managed Agents 之後，MCP（Model Context Protocol）的生態系有了新的可能——讓 agent 跨工具協作的基礎設施在快速成熟中。

中小企業老闆採購 AI Coding 的 5 個訊號

這五個訊號不是功能清單，而是採購決策的判斷框架。在你正式評估之前，先把這五個問題問完。拿著這五個問題去跟廠商開會，你會立刻知道對方是真的有 enterprise 方案，還是只在賣一個「企業版 SaaS 訂閱」。

訊號一：合約鎖定深度

先問自己：「如果我一年後想換工具，切換成本是多少？」AI Coding 工具的合約鎖定，已經從「工程師換 IDE 的習慣成本」升級為「agent 的工作歷史、上下文、任務記錄落在哪裡」。Ona 整合之後，Codex 的 agent 會累積你的 codebase 知識——這些知識在供應商那裡，你的退場選項就受限。合約裡必須寫清楚：agent 知識庫的資料所有權歸屬。

具體詢問方式：「如果我終止合約，agent 累積的 codebase 上下文、任務歷史、自訂規則，可以用什麼格式匯出？匯出需要多少時間？」對方如果答不出來，或說「這屬於平台資料」，代表合約鎖定風險很高。

訊號二：Source code 落點

不管廠商說的再好，你需要確認：你的程式碼有沒有離開你可審計的環境。 VPC 部署解決的是這個問題，但 VPC 部署目前在各家廠商的成熟度不同——Codex + Ona 的 VPC 方案還在路線圖階段，Google Antigravity 對 GCP 客戶比較成熟。評估時不要只看廠商的行銷文案，要問：「現在、今天，能給我一個在我們 AWS/Azure/GCP 帳號裡跑的 demo 嗎？」

延伸閱讀：AI 採購的合規 3 道防線，有完整的合約審查框架，適合拿去跟法務一起看。

訊號三：廠商 runtime 透明度

你需要知道的不只是「agent 在哪裡跑」，還有「agent 怎麼跑」。具體問：（1）agent 執行環境的 OS / container 版本是否公開；（2）agent 的執行日誌能否匯出；（3）agent 執行期間能否中斷或暫停。缺乏透明度的廠商，代表你對 agent 的行為沒有可見性——這在合規場景是一個硬傷。

這個訊號特別重要的原因：AI agent 在執行過程中可能接觸到你的 API keys、資料庫憑證、機密 config。如果你沒辦法審計 agent 的行為記錄，你就不知道這些憑證被用在了哪裡。

訊號四：退場條款

AI Coding 工具的市場變化速度快得難以想像——Claude Managed Agents 剛推出沒多久，Codex 就收購了 Ona，6 個月後又會有新動作。你的採購合約裡，退場條款要先談：資料匯出格式（能匯出多少 agent 上下文？）、合約提前終止費、下架通知期（至少 12 個月）。

一個好的退場條款框架應該包含：（1）30 天資料匯出期保證；（2）服務終止前 12 個月書面通知；（3）提前終止違約金上限；（4）資料刪除確認書。這些條款現在談起來對方可能覺得不必要，但它們是你在市場快速變化中保持靈活性的基礎。

訊號五：Token 成本透明度

Long-running agent 最容易踩的成本雷，是 token 消耗不透明。一個跑了 3 小時的 codebase 現代化 agent，可能吃掉幾百萬 token。在合約裡要求：每次 agent 執行的 token 消耗報告、每月上限設定、超限警報機制。如果廠商不願意提供這些，代表你沒辦法管控成本。

參考：Codex vs Claude Code 詳細費用比較，有實際 token 成本的試算框架。另外，AI Coding 工具完整選型指南 也有各工具費用結構的橫向比較，幫助你在 PoC 前就對成本區間有概念。

60 天行動清單：從觀望到有策略的評估節奏

看完五個訊號，下一步是把評估節奏拉出來。以下是我們建議的 60 天框架，不需要馬上做決定，但要開始累積資訊——因為 AI Coding 採購的決策窗口，通常是在你有數據之後才會出現。

有一點我們想特別說：60 天的評估期，不代表你 60 天後一定要做決定。AI Coding agent 市場現在的變化速度，每 3 個月就會有新的重要事件。Ona 今天被收購，3 個月後可能有新的競品出現更好的 VPC 方案——採購節奏拉長，才是對的。

這個 60 天框架也適用於更廣泛的 AI 工具採購場景。AI Code Review 工具選型指南 的框架可以搭配這份清單一起用，幫助你在評估 AI Coding 工具的同時，也把 code review 自動化的需求一起納入評估範疇。

我們在用 Codex，這是我們的第一手觀察

在進入「我們怎麼看」之前，先說清楚我們的位置：我們公司自己每天就在跑 20+ 個 AI 流程，Codex 是其中的一部分。我們用它做 code review 自動化、dependency 更新檢查、和部分 unit test 生成。

在實際使用裡，我們最直接感受到的瓶頸，恰好就是「任務中斷」。一個中型的 refactoring 任務，Codex session 斷了就得從頭 context、甚至重跑。Ona 如果真的能解決持久化問題，我們很想試——但「試」跟「合約鎖定採購」是兩件事。

另一個我們實際測到的問題是成本預測性。Long-running agent 的 token 消耗是非線性的——複雜程度高的 task 可能吃掉的 token 是你預估的 3-5 倍。在我們自己的流程裡，我們給每個 agent task 都設了 token 預算上限，超過就中斷並發警報，確保月度成本可控。

這也是為什麼我們會在這篇提出「訊號五問卷」的框架：像這類 AI 系統整合的評估，我們在跟客戶討論的時候，最常遇到的問題是「不知道問什麼」，而不是「不想做」。問對問題，比快速下決定更重要。

常見問題

AI Coding 採購是一個會持續演進的議題。如果你想持續追蹤這個領域的進展，可以參考我們的 AI 顧問服務，或是直接把你的情況丟給我們，我們陪你一起看哪些做得起來，從最有效益的那一塊開始。