Red Hat Developer Hub 更新，AI 代理從查目錄走到觸發動作

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Red Hat 在 2026 年 11 月 9 日發表 Developer Hub 2.1，把這個以 Backstage 為基礎的企業開發入口，再往 AI 代理推了一步。入口裡累積多年的軟體目錄、內部文件與自動化流程，原本主要給人查閱，現在開始變成 AI 代理可讀取、甚至可觸發動作的整合點。用官方的說法，這個目錄收著程式碼、文件、即時工具資料、基礎架構資訊與自動化的自助式流程，而且標記了元件之間的關係、持續與最新版本同步，這些正是代理產出可用結果需要的材料。同一份官方公告也宣布，自 2.1 起每次發行的支援期，從 1.X 時期的六個月延長到十個月。

這次更新真正值得留意的，是各功能之間的狀態落差。讓代理「動手」的新能力，包括 MCP 動作、AI 資產目錄、螢幕脈絡與技能支援，官方部落格全部標註為開發者預覽；相對地，升上正式供應的是新版外掛架構，加上延長的支援週期。骨架先轉正，AI 功能還在試車，這個順序本身就說明了 Red Hat 對企業客戶的優先順序。

誰該在這次更新停下來看

已經在用 Red Hat Developer Hub 的平台團隊，是這次更新最直接的受影響者，尤其符合兩個條件之一：入口上有自己寫的自訂外掛，或者正在把 AI 編碼代理引進開發流程。前者要面對外掛架構遷移，後者則多了一批可接線的新出口。

另一個該留意的是已部署 OpenShift AI 的團隊。2.1 的 AI Catalog 會自動把 OpenShift AI 目錄裡的模型與 AI 資產帶進入口，來源真相仍留在原本的平台，兩邊看得到同一份清單。

如果團隊根本沒有用 Backstage 或 Developer Hub，這次發表與你無關，不需要因為「AI 代理」幾個字而改變任何採購或導入計畫。另外要注意，官方自 1.9 起提供英、德、法、義、西、日六種介面語言，清單裡沒有中文，這點對台灣團隊的推廣成本是實際變數。

一年前的 MCP 只能讀，這一版開始能動

Developer Hub 對 MCP（Model Context Protocol，一種把資料與工具開放給 AI 客戶端使用的介面標準）的支援不是這次才開始。對照官方文件，前後差異相當清楚。

一年前的官方文章寫得明白：「工具應聚焦在唯讀操作作為起點，寫入或可能具破壞性的操作需要進一步的安全考量。」當時的接法，是透過一個基於 Backstage Actions Registry 的 MCP 伺服器，用固定的靜態權杖做驗證，官方示範的客戶端是 Cursor、Continue 與 Claude CLI，能做的事不出查目錄與讀文件。到了 2.1，公告列出新的初期整合：用 Kubernetes 拿環境資訊、用 Scorecards 看服務健康狀態、用 Orchestrator 尋找並啟動工作流。方向從「讓代理看」走到「讓代理做」，但官方同時把這組能力標為開發者預覽，企業支援條件與穩定度承諾都還沒跟上。而且公告明說，這是持續擴充的機制：後續有更多外掛註冊 MCP 動作，能力會跟著長出來。

把視角拉遠看生態的兩端：開源圈有讓 LLM 直連 MCP 伺服器的 mcp-use 函式庫，資源查找有 Awesome MCP Servers 的收錄整理；Google 則以 Connected Apps 預覽把 MCP 服務接進 Gemini 與搜尋。Developer Hub 選的位置在企業內部，把治理過的目錄與流程當成 MCP 工具的來源，這也是它跟消費端整合最大的差別。

這裡有個容易誤讀的地方。代理能找到某個流程，跟每位使用者都有權啟動它，是兩回事。MCP 動作的實際執行範圍，仍由接入的工具、身分與權限設定決定，入口本身不會自動放行。

助手、技能與自備知識：哪些能用，哪些還在預覽

入口內的智慧助手在 2.1 有明顯的角色調整。它的前身是 Red Hat Developer Lightspeed for Developer Hub，這一版除了回答文件與除錯問題，還支援更貼近組織內規的回答，並可對外部系統執行動作。官方部落格內嵌的介面截圖裡，Notebooks 分頁直接掛著 Developer preview 標籤，狀態誠實地寫在畫面上。

Pin

幾個配套功能值得一一拆開看狀態：

自備知識（BYOK）。這裡的 BYOK 是 Bring Your Own Knowledge，指平台工程師把內部事故應變手冊、API 文件、架構決策紀錄與新人指南接進助手，跟常見的「自帶模型金鑰」是兩回事。知識接上後，品質仍取決於來源文件有沒有維護；目錄裡的負責人已離職、手冊過期，代理拿到的就是過期答案。

AI Catalog（開發者預覽）。把 AI 代理、MCP 伺服器、技能與規則收進可搜尋的清單，讓開發者找得到組織認可的 AI 資產。它同時整合 OpenShift AI 目錄，來源真相留在原平台。

Pin

螢幕脈絡（開發者預覽）。開發者除錯時，助手可讀取目前作用中的入口瀏覽器畫面，範圍是 docked 與 overlay 兩種模式下的入口頁面，全螢幕模式反而停用，因為放大後的對話窗會蓋住工作區。根據同日發布的官方開發者文件，這個功能預設關閉，要管理員在設定檔開啟，使用者再自行打開，而且擷取嚴格只在按下送出那一刻發生，連續與背景擷取完全停用，敏感欄位與憑證會先從 DOM 清掉，送出的內容是壓縮過的畫面截圖加上清理過的畫面文字。範圍講清楚：它讀的是入口頁面，不是整台電腦。

技能支援（開發者預覽）。組織可把內部規範寫成技能，讓助手依情境自動套用。官方舉的例子是結合 MCP 工具後，可以建立 Jira 議題、啟動 Jenkins 建置或發起程式碼審查。要試用這組合，先把可讀資料與可寫動作列清楚，再決定權限開到哪裡，會比一次全開容易追責；代理回報『完成』之後怎麼核對，可以再搭配 TechMoon 先前整理的文件、網站與資料任務驗收方法。

另外兩個小改進屬於正式功能：使用者可把常用提示存成書籤，之後一鍵重用；助手內建的產品知識庫改接 Red Hat 線上知識入口，每週自動更新產品文件。要留意「每週更新」只覆蓋官方產品文件，企業自己接進來的內部文件不在代為維護的範圍。

正式供應的是骨架：外掛新架構與十個月支援

與 AI 功能的預覽狀態相比，這次升上正式供應的是門面與骨架。官方把新的外掛架構升為正式供應，Red Hat 已開始把自家最常用的外掛遷移到新架構，並提供自訂外掛的遷移指南；舊前端系統仍保留，讓客戶按自己的步調搬家，但官方明言會在未來版本棄用。

對平台團隊來說，這部分的實際改變包含四件事：外掛可透過視覺化的擴充套件目錄啟用，不必再改設定檔；品牌主題一次設定就套用到所有外掛；側邊欄與頁面標題的在地化更完整；外掛的局部調整（換掉某張卡片、隱藏某個面板、把 Catalog 改名叫 Service Registry）都能用 YAML 設定完成，不需要再 fork 外掛原始碼。寫前端外掛本身也變簡單，官方提供預建樣板，照樣板寫出來的外掛自動支援在地化、品牌與導覽設定。這些改動的共同方向，是讓客製化留在升級路徑上，而不是每次升級都重新合併衝突；官方對舊架構的態度寫得直接：保留是為了漸進搬家，未來版本會棄用。

治理面也有兩處更新。Scorecards 新增 SonarQube 整合，帶進程式碼覆蓋率、安全熱點與可維護性評級，加上 DORA 指標，與既有的 Jira、GitHub 資料併在同一頁看元件健康。Orchestrator 則加入工作流視覺化，看得出每一步的狀態與誰觸發了流程，多步驟表單也會保留已填資料。

支援期從六個月延長到十個月，給的是緩衝時間，不是免遷移保證。官方的說法是客戶可以少花時間在升級入口本身，把力氣放回其他工程事項；但外掛盤點、測試環境驗收、回復方案，這些工作不會因為支援期變長而消失，只是排程壓力變小。

Red Hat 拿來說服你的數字，要對照原文讀

官方公告開頭用了兩組數字說明「缺乏組織上下文的 AI 產出會吃掉生產力」。一組是引用 Kaggle 白皮書，宣稱缺乏上下文讓每個功能多花三到十倍成本；另一組引用 Faros 的 2026 年報告，寫成「epic 完成率增加 66%，每個 PR 的事故暴增 243%」。

回到 Faros 原文核對，數字本身存在，但表述值得還原。原文寫的是每位開發者完成的 epic 數量增加 66%，事故對 PR 的比率增加 242.7%，Red Hat 部落格把它進位成 243%；同一份報告還有每月事故增加 57.9% 這個數字。同一份報告也呈現正面數字：每位開發者的任務吞吐增加 33.7%，PR 合併率增加 16.2%。這份報告以各組織 AI 採用前後期的對比呈現，通篇未宣稱因果。拿這組數字當「引入上下文層」的動機可以，當成已證實的投資報酬就過頭了。

三到十倍那組則是廠商引用第三方白皮書的宣稱，公告原文用的是估計語氣。它支撐的是「上下文很重要」這個方向，支撐不了任何具體的採購決策數字。

升級前後，不同團隊現在可以做的事

已經在用 Developer Hub 且有自訂外掛的團隊，這次的實際功課在外掛盤點。對照官方遷移指南，把自訂外掛分成要遷移、可淘汰、必須重寫三類，先在測試環境用 2.1 驗收一輪，再談正式升級。判斷基準是外掛能不能在新架構下穩定運作，支援期延長只改變時間壓力，不改變這個判斷。

想把編碼代理接進入口的團隊，入口已經提供 CLI，讓代理直接查組織目錄與規範，減少在瀏覽器裡來回翻找。官方對這個工具的定位說得很直白：代理看不到組織允許什麼、已經有什麼、彼此怎麼連接，就會重複造已有的服務、挑未經認可的技術；CLI 把目錄與最佳實踐直接交給代理，讓它產出的每個決定有跡可循。不過官方部落格對 CLI 的支援狀態沒有標註，採用前值得向 Red Hat 確認支援條件。MCP 動作與技能都還在開發者預覽，建議先把讀取類整合（查目錄、看健康狀態）跑順，寫入與啟動類動作等預覽轉正或內部驗證通過再開。

還在評估是否導入開發入口的團隊，這次發表可以當成一個觀察點：Red Hat 把代理整合放在產品路線中心，方向明確，但多數能力還掛著預覽標籤。公告結尾描繪的下一步，是幫開發者消化代理產生的大量 PR、看清楚代理正在做什麼、評估代理交付的品質，甚至把任務直接交辦給代理。先用 Backstage 或開源版把服務目錄與範本建立起來，等 2.x 系列把 AI 功能轉正，再決定要不要走商業支援的路，是風險比較低的順序。

還沒確定的事，與這篇的保存期限

兩件事在官方公告裡沒有講清楚。代理 CLI 的支援狀態（正式供應、社群預覽或技術預覽）官方部落格未標註，文件入口的完整版本資訊以 Red Hat 官方文件為準；四個開發者預覽功能（MCP 動作、AI Catalog、螢幕脈絡、技能支援）何時轉正，公告只說持續投資代理式軟體開發週期，沒有給時間表。

這篇的時效邊界：十個月支援期與外掛架構轉正是已定的版本事實；預覽功能的狀態會隨後續版本變動，建議在下個 minor 版本發布或外掛遷移指南更新時回來核對一次。如果那時 CLI 或 MCP 動作已經轉正，本文對採用風險的判斷就需要跟著更新。

資料來源

• Red Hat 官方公告：Red Hat Developer Hub 2.1: Agent ready, extended support, new plugin architectures（2026-11-09）
• 官方開發者文件：MCP 支援的起點（1.8 時期）（2025-11-10）
• 官方開發者文件：隱私優先的螢幕閱讀功能設計（2026-11-09）
• 官方開發者文件：為 2.1 準備自訂外掛遷移（2026-10-20）
• Faros：The AI Engineering Report 2026 原文