5 個開源 MCP Gateway 怎麼選

我拆五個開源 MCP gateway，直接看誰真的能做治理、稽核和權限控管。

我盯 MCP 這波一陣子了，越看越像以前那些「先接了再說」的 infra 災難。模型能用、工具能串、agent 也跑起來了，然後大家就把這叫做「可控」。我每次看到這種說法都很想翻白眼，因為真正麻煩的從來不是能不能呼叫工具，而是誰能呼叫、呼叫了什麼、出了事能不能追、密鑰到底放哪裡。這些沒先想清楚，後面補都很痛。

我就是因為這個不對勁，才去看 Lunar.dev 這篇整理：The Best Open Source MCP Gateways in 2026。它不是在幫某家廠商洗地，而是很直接地把開源 MCP gateway 拉出來比，重點放在 access control、auditability、deployment pain 這些真正會卡住團隊的東西。文中提到五個選項：MCPX、Docker MCP Gateway、Microsoft MCP Gateway、IBM ContextForge、MCPJungle。

MCP gateway 不是 proxy，別再偷懶混著講

An MCP gateway sits between your AI agents and the MCP servers they access. It centralizes authentication, enforces access control, logs every tool invocation, and provides a single point of policy enforcement.

翻譯一下就是：gateway 不是單純把流量轉過去而已，它是 agent 到 tool 的控制面。身份驗證、權限、稽核、政策都應該在這裡收斂。你如果把這層當成 proxy，最後每個 agent 都會變成自己的小王國，權限越長越亂，誰呼叫了什麼也說不清楚。

我看過太多團隊一開始覺得「先讓 Cursor、Claude Desktop、內部 bot 都接上去再說」，結果三週後才發現每個 client 的限制都不一樣，server 端也沒有統一的記錄。這種狀況不是監控不夠，是治理根本沒站起來。你到時候要追責，連第一張圖都畫不出來。

Lunar.dev 這篇有用的地方，就是它把 gateway 當基礎設施，不是方便工具。它看的面向也很務實：access control 深度、audit trail、secrets management、部署複雜度、整合能力。這些才是平台團隊每天會被問的問題，不是 README 寫得多漂亮。

實操上我會這樣做：先寫下 policy 要在哪裡生效。是 server？是 tool？是參數層？還是 gateway？如果答案是「在 agent 裡自己管」，那你大概已經輸一半了。治理要能集中，否則每個人都會說自己有控管，但其實只是各自為政。

MCPX 會被拿來講，不是沒原因

MCPX is Lunar.dev's open source MCP gateway and AI control plane for enterprise teams. It provides a single governed entry point for all agent-to-tool interactions, enforcing access control, auditability, and policy across every MCP server in your organization.

白話一點，MCPX 想解的是那個最無聊、但最重要的問題：多團隊共用工具時，怎麼不要把 blast radius 做大。它不是只讓你「接得上」，而是想讓你「管得住」。開源版就有 Tool Groups、tool customization、本地和遠端 MCP server auth、Prometheus-compatible metrics、基本 invocation logging。老實說，這已經比很多號稱 gateway 的東西像樣多了。

我最在意的是 Tool Groups。這功能不是炫技，是避免一個 team 因為 server 共用，就看到所有工具。你如果同時有 finance workflow 和 engineering workflow，兩邊根本不該看到同樣的 surface area。MCPX 在 gateway 層先切開，至少方向是對的，不然你只是做了一個很大的共享風險池。

另一個我覺得實際的點是導入成本。文章提到它可以用 Docker 很快起來，也支援 local 和 remote MCP server，走 STDIO 或 HTTP。這很重要，因為沒人想為了驗證治理可不可行，先花一個 sprint 寫一堆 plumbing。先跑起來，看 policy 能不能真的落地，比空講架構有用太多。

如果是我評估 MCPX，我會先拿一個真實 team、真實 server 來試。先列出這個 team 真的該看哪些 tools，把其他的先藏起來，再把 audit log 當成驗收條件，不是之後再補。文章也很誠實：identity provider integration 和 automated MCP vulnerability scanning 是付費功能。這種講法我比較能接受，至少不會讓你 pilot 到一半才發現缺了一大塊。

我也喜歡它沒有假裝 open source 版什麼都包。它沒有。這種誠實反而比較像能進 production 的東西，因為你知道哪些是現成的，哪些是你要自己補的。

Docker 這條路，適合只想先隔離的人

Docker's MCP Gateway runs each MCP server in its own container with defined resource limits and cryptographically signed images. Security comes from isolation rather than policy enforcement at the gateway layer.

翻譯一下就是：Docker 給你的是 container boundary，不是治理系統。這不是貶義，只是提醒你 isolation 跟 access control 根本不是同一件事。如果你們本來就很熟 Docker / Kubernetes，這條路會很順；但如果你期待 gateway 自帶權限、稽核、密鑰管理，那你會開始自己補很多東西。

文章講得很直白：沒有 built-in access control、沒有 audit trails、沒有 secrets management。這句我認真同意。很多團隊會高估「我們把 MCP server 跑在 container 裡」的效果，以為這樣就安全了。其實你只是把服務關在箱子裡，沒有回答誰能進、誰做了什麼、出事怎麼查。

但 Docker 也不是完全沒用。若你的組織本來就是 container-native，平台團隊也已經有自己的安全邊界，那 Docker 這種做法很自然。你得到的是 resource limits、signed images，以及大家都懂的部署模式。它比較像包裝層，不像治理層。

實操上我會這樣選：只有在你已經有別的地方負責 identity、logging、secrets、policy 的前提下，才把 Docker MCP Gateway 當成選項。若沒人願意接這些責任，那就不要騙自己這叫治理。那只是容器化而已。

• 適合：容器化很成熟、治理能力已經在別處的團隊。
• 不適合：期待 gateway 自己回答稽核與權限問題的團隊。

Microsoft 只有在你本來就在 Azure 裡才好用

Microsoft's open source reverse proxy for MCP servers provides session-aware routing and lifecycle management for Kubernetes, with an optional path to Azure API Management.

這段翻譯起來很簡單：如果你的世界本來就是 Azure，Microsoft 這條路會很順。它有 Entra ID authentication、Azure Monitor、App Insights，還能接 Azure API Management 做 policy enforcement。這對 Azure shop 很合理，因為你不用把 identity 和 observability 再拆出去找別的系統。

但問題也很明顯：治理深度其實是被 APIM 的 policy engine 限住的，而且那個 engine 本質上是 rule-based。也就是說，Microsoft 這裡更像是在做 operational routing，不是 intent-aware access control。這差很多。很多人會把 traffic management 跟 policy 混在一起，結果最後才發現 gateway 根本不知道誰該做什麼。

我之前也看過類似場景：團隊很愛說「我們有路由、有監控、有 IAM」，聽起來很完整，實際上 tool-level RBAC、agent identity attribution 還是得自己補。這不是不能做，而是你要先知道自己在補什麼，不然會以為買到一整套，其實只是買到接得上 Azure 的骨架。

實操建議很單純：只有當 Azure 已經是你的 control plane，這個選項才值得看。你如果已經把 identity、monitoring、policy 都放在 Azure，整合會很舒服。若不是，你會花一堆時間把架構硬塞進去，最後只是讓自己更忙。

• 適合：Azure-only、已經有 Entra ID 與 APIM 的團隊。
• 不適合：multi-cloud，或需要原生 tool-level governance 的團隊。

ContextForge 很強，但它先是 federation，再談治理

ContextForge is IBM's open source AI gateway framework that federates tools, agents, models, and APIs into a single MCP-compliant endpoint across multi-cluster Kubernetes environments.

白話講，ContextForge 比較像 federation layer，不是先把治理問題解乾淨再說。它支援 MCP、A2A、REST-to-MCP、gRPC-to-MCP，還有 multi-cluster discovery、OpenTelemetry tracing、一堆 plugins。這種東西看起來很完整，但也很容易把平台團隊拖進更大的複雜度。

文章裡有一個我覺得很重要的提醒：1.0 RC2 新加的 Cedar RBAC plugin 是 rule-based，而且治理功能，包括 vault-backed key storage，文件相對沒有那麼完整。這種時候你就該警覺了。因為如果文件最強的是 routing、最弱的是 control，那你買到的很可能是架構複雜度，不是治理成熟度。

我不是完全否定這方向。對大型企業、跨多個 cluster、跨多個 region 的平台團隊來說，federation 很有價值。但我不會因為它聽起來 enterprise 就選它。我只會在我真的需要統一一堆分散環境，而且我也真的有能力維護它時才考慮。

實操上我會這樣看：如果你們本來就有很強的 Kubernetes 人力，而且問題是多 cluster、多環境的整合，那可以看 ContextForge。若你的主要痛點只是 access control，那先別急著跳進 federation。先把控制面講清楚，不然你只是把混亂做得更大。

MCPJungle 是變數最多的那個，別先把它神化

Only one tool on this list was designed to answer all five of these questions out of the box.

這句話的意思其實很直接：不要假設每個開源專案都能幫你把 enterprise governance 一次補齊。Lunar.dev 的比較文很明顯是在說，MCPX 是這份清單裡唯一直接對準 access control、auditability、secrets handling、deployment effort、ecosystem integration 這五件事的選項。那 MCPJungle 就比較像你要認真驗證的候選人，而不是預設答案。

我想特別吐槽一下這種常見情境：看到 open source、README 寫得不錯、社群討論也有一點熱度，就開始想像缺的功能之後會慢慢補齊。通常不會。尤其是治理這種東西，沒有明講 control model 的專案，最後都會在壓力下露餡。等 security 或 compliance 問你誰做了什麼時，你才會知道自己當初省了哪一段功課。

實操上我會這樣用 MCPJungle：先把你的治理需求寫死，再拿它去逐條對照。不要問「能不能用」，要問「能不能原生回答這些問題」。如果你需要自己加 identity、logging、policy，這就不只是 gateway 選型了，這是工程專案，而且還是會拖人的那種。

我覺得這份比較最有價值的地方，就是它逼你面對一個很土但很真實的問題：你要的是 gateway，還是你想買一堆零件然後自己拼成 gateway？這兩件事完全不同，成本也完全不同。

我會怎麼選，講白一點

如果今天是我在買，我會直接分四種情境。第一種，想先把治理做起來，不想自己搭 control plane，就看 MCPX。第二種，團隊本來就 container-heavy，而且治理已經在別處，就看 Docker。第三種，整個組織就是 Azure，identity 和 monitoring 都在那裡，才看 Microsoft。第四種，Kubernetes 很重、跨 cluster 很多、你也有足夠平台人力，才看 ContextForge。MCPJungle 我會放在最後，先驗證再說，不會先腦補它能補齊所有 enterprise 缺口。

這篇比較帶給我的結論其實很樸素：最好的 MCP gateway 不是最會講故事的那個，而是最符合你治理現況的那個。你如果沒有 access control、immutable logs、secrets isolation，卻又想直接進 production，那後面一定有人要補課，而且通常是最忙的那個人。

所以我的建議很無聊，但很實際：先問 security 和 platform team 之後一定會問的問題，再去看產品。能原生回答的，就加分；不能的，就老實算工程成本。不要等 demo 結束才想起來問，因為那時候大家通常都已經有點上頭了。

可抄的模板

# MCP Gateway 選型模板（開源版也適用）

## 1) 我們到底要管什麼
- 使用 MCP 的團隊：
- 會接的 MCP servers：
- 涉及的身份來源：
- 資料敏感度：
- 合規要求：

## 2) Gateway 必須原生做到的事
- 集中式認證：
- Tool-level access control：
- Agent / user attribution：
- 不可竄改的 audit logs：
- Secrets isolation：
- 部署目標：
- IdP 整合：
- Observability 整合：

## 3) 每個專案都要問的問題
1. Policy 是在 server、tool、parameter，還是 gateway 層生效？
2. 我能不能在每次操作裡看到 user、agent、tool？
3. Log 是內建的，還是我要自己拼？
4. Secrets 怎麼存、怎麼引用？
5. 從 eval 到 production 要補哪些控制？
6. 有哪些 IdP、SIEM、監控整合？
7. 哪些是開源，哪些是付費？

## 4) 快速評分表
| 類別 | 權重 | 分數 | 備註 |
|---|---:|---:|---|
| Access control 深度 | 30 |  |  |
| Auditability | 25 |  |  |
| Secrets management | 15 |  |  |
| Deployment complexity | 15 |  |  |
| Ecosystem integration | 15 |  |  |

## 5) 決策規則
- 只有當前 3 項原生成立，才算真的適合 production。
- 如果不成立，把缺的控制列成獨立工程工作。
- 如果那些工作沒人接，就不要把它叫 production-ready。

## 6) Pilot 計畫
- 選一個 team：
- 選一個 server：
- 先限制可見 tools：
- 打開 logging：
- 驗證 attribution：
- 測試 secrets handling：
- rollout 前先記錄缺口：

## 7) 最後一句
如果 gateway 說不清楚誰能做什麼、誰做了什麼、secrets 放哪裡，它就還沒準備好進企業環境。

這份模板是我拿來把「看起來很酷的 MCP gateway」拉回現實的工具。你可以直接貼進選型文件、POC checklist，甚至拿去跟安全團隊對齊。比起空講願景，我比較相信這種會逼大家回答問題的表格。

來源主要是 Lunar.dev 的比較文：https://www.lunar.dev/post/the-best-open-source-mcp-gateways-in-2026，另外參考了各專案的官方 GitHub 與產品頁：MCPX、Docker、Microsoft MCP Gateway、ContextForge、MCPJungle。上面這篇是我自己的拆解，產品描述與比較重點則是衍生自原文。