如果覺得文章對你有所啟發，可以考慮用 🌟 支持 Gthulhu 專案，短期目標是集齊 300 個 🌟 藉此被 CNCF Landscape 採納 [ref]。

在先前整合 free5GC 實作 5G URLLC 的實驗中讓我意識到，要讓每一個使用者深入的理解 kernel 的行為，並以此基礎找出正確的排程器策略。 是很困難的。換句話說，如果使用者對系統有深刻的了解，那麼他也能考慮自己開發排程器了。

我們的目標是打造一個能夠被廣泛使用的雲原生排程器方案，因此，將 LLM 或 AI 結合一直是我有在思考的可能方案之一。MCP（Model Context Protoco）的出現很大程度地解決了我的問題，因為它讓我能夠：

• 不需要從頭打造一個 LLM 應用，甚至是專屬的 AI Agent。
• MCP 廣泛的被現行的 Agents 採用，只要開發一次，就能在多個平台上運作。
• MCP 的生態圈相當開放，這也意味著 AI Agent 能夠幫我除錯、測試，甚至是開發 MCP 工具。

因此，我透過 GitHub Copilot 加上 SDD（Spec-driven development）的方式為 Gthulhu 快速的打造了一款專屬的 MCP 工具，讓 LLM 與排程器溝通不再只是紙上談兵：

上面的 DEMO 影片呈現了幾個重點：

• 一開始 API server 並沒有任何的 scheduling policy 存在
• 我透過與 Copilot 聊天的方式，請他幫我根據提供的條件提出一個 scheduling policy
• Gthulhu MCP 成功地與 API Server 溝通，下達了符合我期望的 scheduling policy

因此我們可以預期，當使用者提供給模型足夠完整的 Context，Agent 能夠根據這些資訊推斷我們的系統架構的瓶頸在哪，後續可以再利用 k8s-mcp 等工具篩選出對應的 Pod，最後將匹配的 scheduling policy 套用至 API Server，使 Gthulhu 大大的提供易用性。