引言：一下午搞完一條 ML 管線是什麼體感？

說實話，第一次聽到「團隊用一個下午就建構出比賽勝者預測、航班推薦、新聞前頁預測三個完整 ML 應用」這句話時，我的反應是：嗯，又是哪家新創的 PR 話術吧。但當我把 Hopsworks 5.0 的架構圖攤開、把內部 hackathon 的流程拆解後，不得不承認——這次的「快」不是行銷詞，是架構層面的根本性壓縮。

2026 年 6 月 18 日，總部位於斯德哥爾摩的 Hopsworks 正式推出 5.0 版本，核心賣點是一個叫「Coding Data & AI Stack」的東西。名字聽起來有點像把所有 buzzword 塞進一個盒子裡，但拆開看，它的邏輯其實很粗暴：與其讓工程師在 Jupyter、Airflow、MLflow、Feature Store、Kubernetes 之間手動縫合，不如直接把 Claude Code 和 OpenAI Codex 嵌進平台裡面，讓 coding agents 在一個統一的 terminal 裡面幫你寫、跑、迭代所有的程式碼。

這篇觀察報告不是要幫 Hopsworks 打廣告。我更感興趣的是：當 coding agents 真的住進 ML 平台內部，這件事對 2026 下半年到 2027 年的整個 MLOps 生態鏈意味著什麼？碎片化工具的末日到了嗎？還是只是又一層抽象的堆疊？

Hopsworks 5.0 的 Coding Data & AI Stack 到底是什麼玩意？

先把架構講清楚。Hopsworks 5.0 做的事情，本質上是把四層東西壓成一層：

• 數據湖（Data Lake）：基於 HopsFS 的分散式檔案系統，原生支援 S3、ADLS 等外部數據源接入，搭配 Trino SQL 引擎做即時查詢。
• Feature Store：Hopsworks 的招牌能力，提供線上/離線特徵的統一存儲與版本管理，確保訓練與推論環境的特徵一致性。
• ML 研發環境：內建 Jupyter、Spark，現在又加了 development containers，裡面預裝好 Claude Code 和 Codex CLI。你開一個 container，agent 就在那裡等著。
• 推論服務：透過 KServe 做模型部署，搭配 Kafka 做特徵/預測日誌，Istio 負責低延遲安全路由。

關鍵差異在於：以前這四層之間的「黏合劑」是人。工程師要手動寫 ingestion script、手動定義 feature pipeline、手動配置 K8s deployment。現在，Hopsworks 把這層「人肉黏合劑」換成了 coding agents。

具體操作流程長這樣：你用自然語言或 YAML/JSON 描述你想要建構什麼，平台內建的 agent（Claude Code 或 Codex）就開始自動生成資料處理腳本、特徵工程邏輯、模型訓練程式碼，甚至連部署配置都一併搞定。多個 agent session 可以並行跑，你可以同時讓一個 agent 處理數據清洗、另一個搞特徵工程、第三個調參數。

Coding Agents 如何取代碎片化 ML 工具鏈？

先盤點一下傳統 ML 團隊的工具鏈有多碎。一個典型的 end-to-end ML pipeline，你可能需要：S3/Azure Blob 做數據存儲、Airflow 或 Prefect 做調度、dbt 做數據轉換、Feast 或 Tecton 做 Feature Store、Jupyter 做實驗、MLflow 做模型追蹤、Kubeflow 或 Sagemaker 做訓練、KServe 或 Triton 做推論、Grafana 做監控。這還沒算上 CI/CD、IaC 和各種 ad-hoc 腳本。

工具多不是問題，問題是這些工具之間的語義斷層。你在 dbt 裡定義的特徵邏輯，到了 Feature Store 要重新寫一遍；你在 Jupyter 裡調好的模型，推到 KServe 又要改一遍 API 介面。每一次「翻譯」都是時間和錯誤的入口。

Hopsworks 5.0 的解法很直白：既然斷層在「工具之間」，那就把所有東西塞進一個平台，然後讓 coding agent 在這個統一環境裡面操作。因為 agent 能直接讀到 Feature Store 的 schema、能直接呼叫 Spark API、能直接寫 K8s manifest，它生成的程式碼天然就是「平台原生」的，不需要任何膠水層。

更具體地說，Hopsworks 5.0 引入了幾個關鍵機制：

• Platform Intelligence：用 LLM 自動為數據源生成描述和 metadata，省去手動文檔標註的工夫。
• Wizard 介面：引導式 pipeline 設定，新 UI 比上一版降低了 50% 延遲。
• 原生 Trino SQL：不用再外掛查詢引擎，直接在平台內跑分散式 SQL。
• Development Containers：每個 container 預裝 Claude Code 和 Codex，多 session 並行，互不干擾。

這套組合拳打下來，傳統工具鏈裡至少 Airflow（被平台調度取代）、dbt（被 agent 生成的轉換腳本取代）、部分 MLflow 功能（被原生模型追蹤取代）的角色會被邊緣化。不是說這些工具會消失，而是它們在 ML pipeline 裡的「必經之路」地位被繞過了。

Hackathon 實戰：30 分鐘迭代真的不是唬爛嗎？

這是最值得拆解的一段。Hopsworks 在發布 5.0 之前辦了一場內部 hackathon，結果是這樣的：

• 團隊只用了一個下午，就建構出三個完整的 ML 應用。
• 案例一：比賽勝者預測——用歷史賽事數據訓練模型，預測競賽結果。
• 案例二：航班推薦系統——基於用戶偏好和航班數據做即時推薦。
• 案例三：新聞前頁預測——預測哪些新聞應該出現在首頁，涉及 NLP 特徵工程。
• 每個案例的迭代週期壓縮到了 30 分鐘以內。

30 分鐘迭代是什麼概念？在傳統流程裡，從「改了一個特徵」到「看到新模型的 AUC 變化」，你需要：改 feature pipeline → 重新跑 batch ingestion → 更新 Feature Store → 重新訓練 → 評估 → 看 metric。這個迴圈在好的團隊裡大概要 2-4 小時，在一般團隊裡可能是一整天。Hopsworks 把這個迴圈壓到 30 分鐘，靠的是 coding agent 自動完成「改 pipeline → 重跑 → 重訓練 → 評估」的閉環，中間不需要人類介入。

Hopsworks 團隊後來甚至在 YouTube 上做了一場 live coding 直播，標題是「Predicting the World Cup Winner: Live Coding with Hopsworks」，現場用 Hopsworks 5.0 和 coding agents 在 30 分鐘到 1 小時內 vibe coding 出一個完整的預測系統。他們的原話是：「How about live coding a prediction system live just before the competition? We’ll just get a brand new Hopsworks 5.0 and a couple of beers.」——邊喝啤酒邊 vibe coding 出一個 ML 系統，這個畫面本身就說明了門檻被拉低到什麼程度。

2026-2027 MLOps 市場格局會被怎樣改寫？

把視角拉到市場層面。Gartner 在 2026 年 5 月的預測報告中指出，全球 AI 支出將達到 2.59 兆美元，年增 47%。這個數字比 1 月版本的 2.52 兆美元又上調了 700 億美元，增量主要來自 agentic AI 的加速落地。具體到 AI 服務支出：2025 年 4,364 億美元 → 2026 年 5,855 億美元 → 2027 年預計 7,594 億美元。

在這個大盤子裡，MLOps 市場本身就是一個高速增長的子賽道。MarketsandMarkets 和 Technavio 的報告都指向同一個方向：2026-2030 年間，MLOps 市場以 26.3% 的 CAGR 擴張，增量超過 103 億美元。而 Hopsworks 5.0 的定位——將 coding agents 嵌入 MLOps 平台——恰好踩在 agentic AI 和 MLOps 兩個增長引擎的交叉點上。

這對產業鏈的長遠影響，我推測會在三個維度展開：

1. 工具鏈整合者的窗口期正在關閉。像 Hopsworks 這種「all-in-one + agent-native」的平台，正在把「用最佳-of-breed 工具拼一條 pipeline」的策略變得越來越不經濟。當 agent 能在統一平台裡零摩擦完成全鏈路工作，獨立工具商的價值主張會從「我這個功能最強」變成「我的 API 能不能被 agent 呼叫」。2027 年之前，我們可能會看到一波 MLOps 工具商的併購潮，因為獨立存在的 ROI 越來越難講。

2. ML 工程師的角色邊界會大幅挪移。當 coding agents 接管了「寫 pipeline 腳本」這個工作，ML 工程師的核心能力會從「能寫好 Spark job」轉向「能寫好 YAML spec」和「能審查 agent 生成的特徵邏輯是否正確」。這其實是好事——把人力從 boilerplate 裡解放出來，投入到模型策略和業務理解上。但對於只會寫 glue code 的工程師來說，壓力是實實在在的。

3. 主權數據 AI 的政治正確性。Hopsworks 5.0 強調「Sovereign Data and AI platform」，這不是附帶提一句的 marketing tag。在 GDPR、EU AI Act、以及各國數據本地化法規的壓力下，企業越來越需要一個「數據不出域、模型不出域、agent 也不出域」的 AI 平台。Hopsworks 的 K8s-native 架構讓它可以在私有雲、邊緣節點甚至 on-prem 部署，agent 跑在客戶自己的 container 裡——這對金融、醫療、政府這些強合規行業來說，是硬需求。

主權數據與 Agent 生成程式碼的隱形地雷有哪些？

講完好的，來講地雷。Hopsworks 5.0 的架構很漂亮，但落地時有幾個不能假裝看不見的問題：

地雷一：Agent 生成的特徵工程邏輯可能藏 data leakage。Claude Code 和 Codex 確實能根據你的自然語言描述自動生成特徵工程腳本，但 LLM 對「哪些特徵包含了未來資訊」的判斷力並不穩定。比如你讓 agent 建構一個「航班延誤預測」的特徵，它可能會很「聰明」地把「當天全部航班的平均延誤時間」做成特徵——但這個值在預測時刻是未知的，屬於經典的 target leakage。訓練時 AUC 爆表，上線後崩盤。人工審查 agent 生成的特徵定義，在目前階段是不可跳過的步驟。

地雷二：多 agent 並行的狀態一致性。Hopsworks 支援多個 agent session 並行跑，這在速度上很爽，但如果兩個 agent 同時修改同一個 Feature Group 的 schema，可能產生衝突。平台目前看起來沒有提供 agent-level 的樂觀鎖機制——這在多人 + 多 agent 的場景下遲早會出事。

地雷三：Sovereign Data 的「主權」邊界。Hopsworks 5.0 的賣點之一是數據和模型都不離開客戶的基礎設施。但 Claude Code 和 Codex 本質上是外部 LLM 服務——如果 agent 在生成程式碼時需要呼叫 Anthropic 或 OpenAI 的 API，那麼你的「數據描述」和「pipeline 意圖」是不是也外洩了？Hopsworks 需要非常清楚地說明：agent 的推理是在 local container 裡完成的，還是要 round-trip 到外部 API？這個問題對金融和政府客戶來說是 deal-breaker 級別的。

FAQ：你可能想問的三件事

Hopsworks 5.0 的 Coding Data & AI Stack 和傳統 MLOps 平台有什麼本質區別？

本質區別在於 coding agents 的嵌入方式。傳統 MLOps 平台（如 Databricks、SageMaker）也有 AI 輔助功能，但通常是「外掛式」的——你在 notebook 裡呼叫一個 AI assistant，它幫你寫幾行程式碼，然後你再把程式碼複製貼上到正式的 pipeline 裡。Hopsworks 5.0 的做法是把 Claude Code 和 Codex 直接裝進 development container，agent 對平台的 Feature Store schema、Spark API、K8s 配置有原生感知，生成的程式碼可以直接在平台內執行和部署，零 context switching。這是「native 嵌入」和「外掛呼叫」的架構級差異。

Coding agents 自動生成的 ML 程式碼品質可靠嗎？可以直接上生產環境嗎？

目前階段，不建議將 agent 生成的程式碼未經審查直接推到生產環境。主要風險包括：特徵工程邏輯中可能隱藏 data leakage、agent 對業務語境的理解有限可能生成語義錯誤的特徵、以及多 agent 並行時的 schema 衝突。最佳實踐是將 agent 生成的程式碼視為「高品質草稿」，由 ML 工程師進行 code review 和特徵邏輯驗證後再合併。Hopsworks 的 YAML/JSON 輸入機制有助於這個流程——你可以 version control 你的 pipeline spec，每次 agent 生成後做 diff review。

中小型團隊適合導入 Hopsworks 5.0 嗎？還是只適合大型企業？

Hopsworks 5.0 對中小型團隊其實特別有吸引力，原因有二。第一，coding agents 降低了 ML pipeline 的建構門檻——一個 3-5 人的數據團隊，如果能用自然語言 + YAML 驅動 agent 完成從數據接入到模型部署的全鏈路工作，等於變相擴充了工程產能。第二，Hopsworks 提供 managed cloud（app.hopsworks.ai）和 self-hosted 兩種模式，中小團隊可以從 managed 起步，成本可控。需要注意的是，如果你團隊裡沒有人熟悉 K8s 和 Spark，初期學習曲線仍然存在——agent 可以幫你寫程式碼，但你至少要能看懂它寫了什麼。

開始行動

如果你的團隊正在被碎片化 ML 工具鏈拖慢迭代速度，或者你正在尋找一個 agent-native、支援主權數據部署的統一 AI 平台，Hopsworks 5.0 值得認真評估。我們可以幫你梳理從現有工具鏈遷移到 Coding Data & AI Stack 的路線圖，包括 Feature Store 遷移策略、agent 生成程式碼的審查流程設計、以及 K8s 部署架構規劃。

立即諮詢遷移方案 →

參考資料

• Hopsworks 官方發布：Releasing Hopsworks 5.0 — Introducing the Coding Data and AI Stack
• Hopsworks 5.0 — Where AI Agents Go to Work
• Gartner：2026 年全球 AI 支出預測達 2.59 兆美元（年增 47%）
• MarketsandMarkets：MLOps 市場規模與預測報告
• Technavio：MLOps 市場 2026-2030 增長分析（CAGR 26.3%）
• Hopsworks Webinar：From Modern Data Stack to the Coding Data Stack (CDS)
• Hopsworks Live Coding：Predicting the World Cup Winner with Hopsworks 5.0
• Hopsworks 官方技術文檔
• Wikipedia：Feature Store 概念解析