OSCHINA

大型語言模型（LLMs）強大但受限于上下文。它們：

→ 缺乏對業務、數據和工作流程的感知
→ 獨立運行，容易產生通用、不相關的回應
→ 無法訪問實時外部知識

雖然RAG（檢索增強生成）和Agentic AI（代理式 AI）為增強 AI 檢索能力與工具交互能力提供了方向，但它們的實現目前依然零散，常是定制開發、難以規模化的解決方案。

什么是 Model Context Protocol（MCP）？

Anthropic 推出的 MCP（模型上下文協議），旨在標準化 RAG 和代理式 AI 的實現方式，實現 LLM 應用的：

? 可擴展性
? 穩定性
? 深度上下文感知

MCP 是如何工作的？
1. 主機環境（Host Environment

LLM 應用所運行的基礎設施，包括：

• 實體機器 – 工作站、本地服務器

• 虛擬機 – 云端 VM、遠程服務器

• 容器 – Docker、Kubernetes

LLM 驅動的實際應用，比如：

• 聊天機器人、搜索助手

• 工作流自動化 AI 代理

• 帶代碼補全和調試功能的 IDE

MCP 客戶端運行在主機應用內，向 MCP 服務器請求外部數據或操作指令。

4. MCP 服務器（Server）

MCP 服務器在 LLM 和外部知識源之間架起一座橋梁，連接：

• 各類 API – CRM、ERP、企業工具

• 數據庫 – 業務數據庫、數據倉庫

• 代碼倉庫與本地文件

• 實時事件流 – SSE、WebSocket

MCP 不止用于數據檢索，還支持執行能力：

• 修改配置

• 運行腳本

• 觸發自動化流程

MCP 通過結構化通信協議（如JSON-RPC 2.0）進行數據交換，支持：

• 標準輸入輸出（Stdio）

• 服務器推送事件（SSE）

• 可自定義的實現（根據具體需求）

MCP 代表了 AI 演進的關鍵一環，它為核心 AI 模式提供標準協議：

?RAG– 從外部檢索知識的模式
?Agentic AI– 讓 AI 能夠與工具交互的模式
?MCP– 將這兩者規范化、結構化的實現協議

，讓開發者可以借助 AI 助手直接訪問代碼倉庫，讀取文件內容、查看 PR 變更、理解 Issue 描述，甚至直接操作代碼管理任務，比如創建 PR、合并分支、發布版本等。

簡單來說，Gitee MCP Server 讓 AI 不再是「代碼的旁觀者」，真正成為了參與軟件開發過程的智能助手。

開源地址：
https://gitee.com/oschina/mcp-gitee

↓更多精彩內容，歡迎預約直播↓