OpenAI Codex 與 Dell、Ona 兩條線放在一起看，訊號很清楚：Codex 正從「幫工程師寫程式的工具」，走向「可以在企業環境裡長時間工作的代理（agent）基礎設施」。
5 月的 Dell 合作，解的是企業資料與部署位置問題；6 月的 Ona 收購，解的是代理需要一個安全、持久、可治理的工作環境。兩者合起來，比單一模型更新更值得工程主管注意。
對已經在評估 OpenAI Codex、Claude Code vs Codex 或企業級 AI 寫程式代理評估表 的團隊來說，現在最該先問：這個代理能不能安全地進入軟體開發生命週期（SDLC），並在可審核的邊界內完成工作？
2026-06 最新狀態：OpenAI 想把 Ona 的背景代理環境放進 Codex
OpenAI 在 2026 年 6 月 11 日宣布計畫收購 Ona。交易仍需完成例行成交條件與監管核准；在交易完成前，OpenAI 與 Ona 仍是獨立公司。
根據 OpenAI 公告，Ona 的價值在於安全、持久的環境（secure, persistent environments）：讓代理有一個可以持續工作的雲端環境，能接觸必要工具、系統與上下文，不必綁在使用者當下那台筆電或某次互動工作階段（session）。
Ona 自己的公告則把重點說得更直接：企業代理需要三件事。
| 需求 | Ona 強調的能力 | 對 Codex 的意義 |
|---|---|---|
| 上下文（context） | 代理必須在企業工作真正發生的系統裡運作 | 需要讀到程式庫、文件、ticket、CI 與內部流程 |
| 控制（control） | 資料、憑證、權限、網路與執行環境（runtime）都要有邊界 | Codex 進企業不能靠一把萬用 token，而要按任務縮小權限 |
| 協作（collaboration） | 工作要跨團隊、工具與 session 延續 | 長時間 migration、測試修補、漏洞調查與文件同步才有機會交給背景代理 |
OpenAI 公告還提到，Codex 每週已有超過 500 萬人使用，較今年稍早成長 400%；Ona 則稱其雲端開發環境服務過 200 萬開發者。這兩個數字不能直接相加，但能看出同一個方向：AI 寫程式代理會從個人效率工具，變成企業要管理的工作負載。
Dell 合作解的是「企業資料在哪裡」
OpenAI 與 Dell Technologies 合作 的方向，是讓 Codex 更接近企業資料、系統與工作流程已經所在的混合雲與企業內部部署（on-premises）環境。
官方提到兩個重點：
| Dell 產品線 | Codex 可能接上的價值 |
|---|---|
| Dell AI Data Platform | 讓 Codex 靠近企業既有資料、文件、程式庫（codebase）、營運知識與治理流程 |
| Dell AI Factory | 探索 Codex、ChatGPT Enterprise 與 API 解決方案如何在混合雲或企業內部基礎設施中準備資料、跑測試、管理系統紀錄與部署應用 |
它的管理意義高於通路合作。大型企業真正卡住的問題通常是：
- 私有原始碼能不能不離開指定環境？
- 代理能不能只讀該讀的程式庫、文件與 ticket？
- 內部資料、客戶資料與 production secret 怎麼隔離？
- 代理執行測試、產生 PR 或觸發 workflow 時誰負責？
- audit log、成本與審核紀錄能不能被平台團隊追蹤？
Dell 解的是企業基礎設施入口；Ona 解的是代理執行環境。Codex 要從展示（demo）進到正式環境（production），兩者都需要。
Ona 補上的是「代理在哪裡工作」
很多 AI 寫程式助理卡住的地方，是工作狀態太短、環境太臨時、權限太粗。
一個真正能做企業工作的代理，至少需要：
- 可重現的開發環境。
- 清楚的程式庫、網路與工具權限。
- 不把 production secret 直接暴露給模型的憑證設計。
- 可保存的 session、log、diff、工具呼叫與審核紀錄。
- 能從手機、桌面或 CI 重新接手的工作狀態。
- 可被人類中途打斷、改方向、要求證據與 rollback 的流程。
這些正是 Ona 官方長期主打的背景代理與雲端開發環境能力。它把一次性的本機工作，推進到企業指定受控環境裡的持續工作。
這也和 GitHub Agentic Workflows 的方向呼應：AI 代理進工程流程後，真正的競爭會從提示（prompt）變成執行入口、權限模型、工作流治理與安全輸出。
對開發團隊代表什麼？採購問題要換一組
以前評估 AI 寫程式工具，常見問題是：
- 哪個模型寫程式比較準？
- 哪個 IDE 體驗最好？
- 哪個工具最會修 bug？
- 哪個方案比較便宜？
Codex + Dell + Ona 這條線出現後，企業採購問題會變成：
| 要問的問題 | 為什麼重要 |
|---|---|
| 代理跑在哪裡？ | 本機、廠商雲、企業 VPC、on-prem 或混合雲，風險完全不同 |
| 它看得到哪些資料？ | 程式庫、ticket、文件、CI log、客戶資料與 secret 需要不同權限 |
| 它能做哪些動作？ | 只讀、開 PR、改 label、跑測試、觸發部署，不應混成同一層權限 |
| 它的輸出如何被審核？ | PR、留言、issue、部署請求都要有不同審核關卡 |
| 成本怎麼歸屬？ | 背景代理長時間運作後，推理費用會變成新的工程平台成本 |
| 失敗後怎麼回溯？ | 沒有紀錄、差異、工具軌跡與批准紀錄，就很難進企業正式環境 |
如果團隊還沒有分支保護（branch protection）、CODEOWNERS、CI 必跑、機密掃描（secret scanning）與審查政策（review policy），先不要把 Codex 或任何代理直接放進高風險程式庫。AI 自動化會放大既有流程：流程清楚，它省時間；流程混亂，它更快製造混亂。
和 OpenAI Agents SDK Sandbox 的差別
OpenAI Agents SDK Sandbox 討論的是代理測試框架（agent harness）與運算沙箱（compute sandbox）怎麼分開，重點在開發者怎麼把代理執行隔離起來。
Dell 與 Ona 這一輪更偏企業基礎設施：
| 層級 | 主要問題 | 代表方向 |
|---|---|---|
| Agents SDK / Sandbox | 單一代理任務怎麼安全執行？ | 沙箱、工具邊界、交接與追蹤 |
| Ona | 背景代理怎麼有持久工作環境？ | 雲端環境、範圍化憑證、執行政策與稽核紀錄 |
| Dell | 企業資料與 AI 工作負載住在哪裡？ | 混合雲、企業內部基礎設施與資料治理 |
| Codex | 誰提供模型、產品體驗與編排？ | AI 寫程式代理、長任務、跨工具工作流 |
這四層不互斥。真正成熟的企業部署，很可能會同時需要模型、代理執行環境、沙箱、資料平台、審核流程與成本治理。
更大的風險：錯誤權限加上長時間執行
很多人談 AI 寫程式代理風險時，第一個想到的是「AI 會寫錯程式」。那當然重要；在企業環境裡，更大的風險是代理帶著錯誤權限長時間工作。
高風險情境包括：
- 代理讀到不該讀的客戶資料、credential 或內部政策文件。
- 代理在沒有審核下修改 auth、payment、deployment、migration 或安全相關檔案。
- 代理執行 shell、CI 或內部 API 時，繞過原本人類需要遵守的核准流程。
- 代理產生看似合理、但缺少測試證據的 PR，讓 reviewer 變成 rubber stamp。
- 長時間背景任務失控，消耗大量 AI credits 或 Actions minutes。
導入策略應先從最小可用權限開始，再逐步擴大任務範圍。可以把權限分成四層：
| 權限層級 | 可做的事 | 必要審核 |
|---|---|---|
| 只讀分析 | 讀程式庫、文件、issue、CI log，產生風險報告 | 引用來源、標示不確定性，不寫入檔案 |
| 小型 PR | 文件、測試、lint、型別或低風險修補 | 分支保護、CI 必跑、真人 review |
| 受控長任務 | 跨檔 migration、批次測試修補、文件同步 | 範圍化憑證、成本上限、完整工具軌跡 |
| 高風險系統 | auth、payment、資料庫 migration、部署、客戶資料 | 人工主導；代理只產生分析、測試或檢查清單 |
當團隊無法把任務放進這四層，就先不要讓背景代理常駐執行。權限、成本、日誌與回滾路徑比模型跑分更能決定它能否進正式環境。
建議導入順序：先只讀，再小 PR，最後才是長任務
比較穩的試點順序如下。
第一階段：只讀分析與報告
先讓 Codex 或其他代理做不寫入正式環境的任務，例如：
- 大型 repo onboarding 摘要。
- CI failure 分析。
- 測試覆蓋缺口報告。
- 文件與程式碼 drift report。
- Dependabot / CVE 修補影響分析。
這一階段的目標是驗證代理讀上下文、引用證據、指出限制與交付可審核結果的能力；自動改 code 要等到證據品質穩定後再開放。
第二階段：低風險 PR
當報告品質穩定，再讓代理產生小型 PR：
- 文件更新。
- 測試補強。
- lint 或型別修正。
- 明確範圍的 API migration。
- 低風險依賴更新。
每個 PR 都應該有測試證據、變更摘要、風險說明與 rollback 路徑。
第三階段：持久背景任務
最後才適合把 Ona 這類背景代理能力用在長時間工作：
- 大型 legacy migration。
- 跨 repo 安全修補。
- 重複性的測試與文件同步。
- 長週期 incident investigation。
- 多系統資料整理與 release note 產出。
這一階段必須搭配範圍化憑證、網路控制、人工批准、成本上限與完整稽核紀錄。沒有這些條件，就不該把代理變成常駐工程工作者。
Codex 採購的下一個問題：工作環境誰來控？
OpenAI 正替 Codex 擴大入口；更關鍵的是，Dell 與 Ona 指向同一個產品方向：把 Codex 從單次 AI 寫程式助理，推向可在企業環境裡持續工作的代理執行環境。
短期看，這會提高 Codex 在大型企業採購中的可信度，因為 OpenAI 能回答更多 CIO、CISO、平台工程團隊會問的問題。中期看，Codex、Claude Code、GitHub Copilot、Cursor、Devin 的競爭會從「誰回答更好」擴大到「誰能被治理、被審核、被部署」。
長期看，企業會採購一整套代理工作環境：資料在哪裡、代理跑在哪裡、權限怎麼切、輸出怎麼審、成本怎麼控、人類怎麼接手。
這才是 Dell 與 Ona 兩個消息真正連在一起的地方。
FAQ
OpenAI 收購 Ona 已經完成了嗎？
尚未。OpenAI 6 月 11 日的說法是計畫收購 Ona，交易仍需完成例行成交條件與必要監管核准。在完成前，OpenAI 與 Ona 仍是獨立公司。
Codex 進企業內網代表可以完全離線使用嗎？
不一定。企業內網、私有環境、混合雲與完全離線是不同層級。OpenAI 與 Dell 的重點是讓 Codex 更接近企業資料與混合雲基礎設施，並不等於所有模型權重都會完整本地化或完全離線部署。
Ona 對 Codex 最大的補強是什麼？
Ona 的補強重點在於提供可持續工作的雲端環境。長時間任務、跨裝置接手、企業內部工具、範圍化憑證（scoped credentials）、稽核紀錄（audit trail）與執行環境安全，都是背景代理要進正式環境前需要的能力。
公司已經有 GitHub Copilot，還需要 Codex 嗎？
不一定。Copilot、Codex、Claude Code、Cursor 的重疊會增加。企業應該用真實工作流測試：哪個工具能接上程式庫、CI、審查、權限、成本治理與批准流程，哪個才值得留。
企業導入 AI 寫程式代理最大風險是什麼？
最大風險通常出在代理拿到太大權限後，在錯誤上下文（context）中長時間行動。最危險的是正式環境、secrets、資料庫 migration、CI/CD、內部客戶資料與安全修補。導入前要先做權限、審核、測試、成本與稽核紀錄設計。