theagentrouter/agent-router 是什麼？

Agent Router 前身是 Envoy AI Gateway，用一組 CRD 與 OpenAI 相容端點，把供應商憑證、路由、配額與用量歸屬集中管理，實際轉發交給 Envoy。本文整理它的機制、部署路徑、限制與替代方案的差異。

theagentrouter/agent-router 可以商用嗎？

可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。

theagentrouter/agent-router 還在維護嗎？

有在維護。儲存庫最近一次提交在 1 天前。

theagentrouter/agent-router 是用什麼程式語言寫的？

主要是 Go（依據 GitHub 的語言統計）。

Agent Router 評測：Envoy 上的 AI 流量控制平面

秒懂

它是什麼？: Agent Router 前身是 Envoy AI Gateway，用一組 CRD 與 OpenAI 相容端點，把供應商憑證、路由、配額與用量歸屬集中管理，實際轉發交給 Envoy。本文整理它的機制、部署路徑、限制與替代方案的差異。
適合誰用？: 已經在用 Envoy Gateway 的平台團隊，是最直接的採用者：CRD 與 API group 沿用 aigateway.envoyproxy.io，CLI 仍是 aigw，命名空間仍是 envoy-ai-gateway-system，容器映像與 Go module path 都沒換，既有 manifest 不必改寫。只想在筆電上驗證多供應商路由的人，用 OPENAI_API_KEY=sk-your-key aigw run 起一個行程即可，不必先碰 Kubernetes。
可以商用嗎？: 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
還在維護嗎？: 有在維護。儲存庫最近一次提交在 1 天前。
用什麼語言寫的？: 主要是 Go（依據 GitHub 的語言統計）。

以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。

開源專案深度解析

Hysen Labs 編輯部 · 2026年9月10日 · theagentrouter/agent-router

它要解的問題：模型變多之後，憑證與配額散在各處

應用團隊面對的狀況通常是這樣：同一個服務要打 OpenAI，也要打 Azure OpenAI，可能還要接自架的推論叢集或 MCP server。每個供應商有自己的認證方式、自己的端點格式、自己的配額語意。金鑰放在應用端的環境變數裡，用量歸屬只能靠各家的帳單事後拼湊，換模型等於改程式。Agent Router 針對的就是這一層。README 把它定位成「The open source control plane for AI and agent traffic, powered by Envoy.」，並用一句話切開職責：「Agent Router controls. Envoy carries.」控制面負責政策，資料面交給 Envoy 承載。它提供的介面是 OpenAI 相容的 API，應用端看到的是一組一致的端點，背後連到託管供應商、自架推論或 MCP server。平台團隊則在同一處管理憑證、路由、配額、故障轉移與用量歸屬。這個分工決定了它的適用對象：不是單一模型、單一金鑰的個人專案，而是同時接多個供應商、且已經有平台團隊在管閘道與身分的組織。

控制面與資料面的切法：CRD 定義政策，Envoy Gateway 執行

從 README 可見的資源名稱來看，Agent Router 的政策是以 Kubernetes CRD 表達的：AIGatewayRoute、AIServiceBackend、BackendSecurityPolicy，全部掛在 aigateway.envoyproxy.io 這個 API group 下。這三個名字本身就說明了資料流的方向。AIServiceBackend 描述後端要去哪裡，BackendSecurityPolicy 描述用什麼憑證去打那個後端，AIGatewayRoute 則把進來的請求條件對應到某個後端。憑證因此不落在應用程式的環境變數裡，而是由控制面持有並在轉發時注入。執行者是 Envoy 與 Envoy Gateway，這也解釋了為什麼專案把「控制」與「承載」分開講：政策是宣告式的，實際的連線、重試與流量處理是 Envoy 既有的能力。README 另外提到兩層閘道模式。Tier One Gateway 是集中入口，負責認證、頂層路由與全域速率限制；Tier Two Gateway 處理自架模型服務叢集的入口流量，並提供 endpoint picker 支援 LLM 推論最佳化。這個切法的用意是把跨組織的治理與單一叢集的排程分開，代價是你得維運兩層，而不是一層。

跑起來的兩條路：aigw run 與 Kubernetes 部署

最快看到東西的方式是單機模式。README 給的指令是 OPENAI_API_KEY=sk-your-key aigw run，跑起來之後把任何 OpenAI 相容的客戶端指向 http://localhost:1975/v1 即可。這條路徑不需要 Kubernetes，適合先確認路由與供應商設定是否符合預期。CLI 的安裝與供應商自動設定寫在 CLI guide，部署到 Kubernetes 的步驟則在 Getting Started guide，兩者都指向 theagentrouter.ai/docs 底下的頁面。要注意的是，單機模式與 Kubernetes 模式用的是同一套概念，但前者把控制面的資源換成了命令列參數與自動設定。若你的目標是驗證 AIGatewayRoute 這類 CRD 的行為，單機模式幫不上忙，因為那些資源只有在 Kubernetes 上才有意義。反過來說，如果你的問題只是「同一段程式碼要打不同供應商」，先用 aigw run 驗證再決定要不要進叢集，成本低得多。

改名之後沒有改的東西，以及這件事對升級的意義

專案從 Envoy AI Gateway 更名為 Agent Router，並成為 Agentic AI Foundation 專案。README 對這件事的說明相當具體：CRD 與 API group 不變，CLI 仍是 aigw，命名空間仍是 envoy-ai-gateway-system，容器映像與 Helm chart 仍是 docker.io/envoyproxy/ai-gateway-*，Go module path 仍是 github.com/envoyproxy/ai-gateway。變動的是倉庫位置移到 theagentrouter/agent-router，舊的 envoyproxy/ai-gateway 連結會轉址；網站移到 theagentrouter.ai，原本 aigateway.envoyproxy.io 的連結逐頁轉址。README 的說法是「Your manifests from yesterday apply tomorrow.」。對已經部署的人來說，這代表升級不需要改 YAML，但需要改的是腳本與 CI 裡寫死的倉庫路徑與文件連結。這一點在自動化程度高的環境裡反而容易漏，因為 manifest 不會壞，壞的是抓取來源的那些步驟。授權是 Apache-2.0，README 也確認與更名前一致。實際的授權義務仍應以倉庫內的 LICENSE 檔案為準，這裡不做法律判斷。

供應商清單與它的邊界

README 列出的供應商涵蓋 OpenAI、Azure OpenAI、Google Gemini、Vertex AI、AWS Bedrock、Mistral、Cohere、Groq、Together AI、DeepInfra、DeepSeek、Hunyuan、SambaNova、Grok、Anthropic，以及 Tetrate Agent Router Service。清單本身不構成採用理由，真正要問的是每個供應商的驗證方式是否都被 BackendSecurityPolicy 涵蓋。README 只給了圖示與名稱，沒有逐一列出各家的驗證機制差異，這部分必須回到 Concepts 與各供應商章節確認。另一個容易被忽略的邊界是 OpenAI 相容性的深度。專案提供的是相容端點，但各家模型在工具呼叫、串流格式、多模態輸入上的實作並不整齊。如果你的應用依賴特定供應商的專有欄位，經過這一層之後是否還能完整傳遞，README 沒有交代，需要自己驗證。把 Agent Router 當成「所有模型都長得一樣」的保證，是對相容性一詞的過度延伸。

什麼時候它會變成錯的工具

最明顯的反例是單一供應商、單一金鑰的場景。這種情況下你要付的是 Envoy Gateway 加上一組 CRD 的維運成本，換來的是一條本來就不複雜的呼叫路徑。第二個反例是團隊沒有 Kubernetes 能力，卻想用兩層閘道模式：Tier One 與 Tier Two 的分工是為了治理與推論排程，如果只有一層的需求，這個切法只是多一層要顧。第三個要留意的是故障面。政策集中在控制面，好處是改一處生效全體，代價是控制面出問題時影響範圍也是全體。README 沒有描述控制面不可用時的行為，這在有嚴格可用性要求的環境裡是需要先確認的空白。最後，endpoint picker 是為 LLM 推論最佳化設計的，若你的後端不是自架推論叢集，這個功能對你沒有意義，而它正是 Tier Two 存在的理由之一。

與 LiteLLM 這類方案的差異在哪

常見的替代方案是 LiteLLM 這類以 Python 套件或代理服務形式提供的多供應商路由層。兩者的差別不在功能清單，而在流量經過的位置。LiteLLM 通常以一個應用層的 proxy 行程存在，路由邏輯、金鑰管理與轉換都在那個行程裡，部署單位是應用或容器。Agent Router 把政策寫成 Kubernetes CRD，交給 Envoy 執行，部署單位是叢集裡的一組資源，認證、路由與速率限制由 Envoy Gateway 的既有機制承擔。這個差異會反映在幾件事上：如果你已經在用 Envoy Gateway 管其他流量，Agent Router 是往同一條路徑上加規則；如果你的環境根本沒有 Envoy，導入它等於同時導入一個閘道。反過來，如果你的團隊不熟 Kubernetes，LiteLLM 那類單一行程的模型在操作上門檻更低。選擇的關鍵不是哪個支援的供應商多，而是你希望這一層政策活在應用行程裡，還是活在叢集的資料面上。

編輯結論

已經在用 Envoy Gateway 的平台團隊，是最直接的採用者：CRD 與 API group 沿用 aigateway.envoyproxy.io，CLI 仍是 aigw，命名空間仍是 envoy-ai-gateway-system，容器映像與 Go module path 都沒換，既有 manifest 不必改寫。只想在筆電上驗證多供應商路由的人，用 OPENAI_API_KEY=sk-your-key aigw run 起一個行程即可，不必先碰 Kubernetes。相反地，如果你的需求只是單一供應商、單一金鑰的呼叫包裝，導入 Envoy Gateway 與 CRD 只會增加維運面積。動手前先確認三件事：你的 Envoy Gateway 版本是否落在專案支援範圍、BackendSecurityPolicy 對你要接的供應商是否已具備對應的驗證方式、以及 Tier Two Gateway 的 endpoint picker 是否真的對得上你的自架推論叢集。這三項在文件裡都有對應章節，但不會替你判斷環境是否相容。

官方來源

社群筆記