MCP 和 Semantic Kernel 有什么区别？协议、Agent 编排与企业项目选型

先给结论：MCP 负责连接，Semantic Kernel 负责编排

MCP 和 Semantic Kernel 不在同一抽象层。

MCP（Model Context Protocol）是一套客户端与 Server 之间的标准协议。它规定如何初始化连接、发现工具、读取资源、获取提示模板和调用工具，但不规定应用应该怎样选择模型、维护 Agent 状态或组织完整业务流程。

Semantic Kernel 是 Microsoft 提供的应用开发 SDK。它把原生代码、OpenAPI 或 MCP Server 中的能力组织成 Plugin，再通过模型的 Function Calling 完成函数选择、参数传递和结果回填。需要 Agent、插件依赖注入、应用内服务编排时，Semantic Kernel 才是主要工作层。

因此，真实项目中更准确的关系是：

用户请求
  ↓
Semantic Kernel：模型、Plugin、Agent、审批与业务编排
  ↓
MCP Client：发现并调用外部能力
  ↓
MCP Server：文件、数据库、SaaS、内部 API

核心差异对比

对比维度	MCP	Semantic Kernel
本质	开放的客户端—Server 通信协议	应用内 SDK 与 AI 编排框架
主要职责	标准化暴露 Tools、Resources、Prompts	组织 Plugins、Function Calling、Agent 与应用服务
运行边界	跨进程、跨客户端或远程服务	通常运行在你的应用进程和服务架构中
能力发现	Client 通过 tools/list 等协议方法动态发现	Kernel 在应用启动或运行时注册、导入 Plugin
工具执行	Client 通过 tools/call 调用 Server	模型请求函数后，Kernel 路由到对应 Plugin Function
传输方式	本地 stdio 或远程 Streamable HTTP	进程内调用、HTTP API、OpenAPI 或 MCP Plugin
最适合	多客户端共享工具、跨语言接入、远程能力服务化	企业应用编排、依赖注入、Agent 流程和业务权限控制
是否可组合	可以作为外部能力接入层	可以导入 MCP Server 作为 Plugin 来源

MCP、Semantic Kernel 和 Function Calling 的关系

这三个概念经常被混在一起，其实分别对应三层。

Function Calling：模型与函数之间的调用格式

Function Calling 解决的是：模型根据函数描述生成函数名和参数，应用执行函数后再把结果返回模型。它是最轻的一层，适合少量、稳定、只在当前应用内部使用的函数。

Semantic Kernel：把函数组织成可维护的应用能力

Semantic Kernel 的 Plugin 是一组带有语义描述的函数。Plugin 可以来自：

• 现有的 C#、Python 或 Java 原生代码；
• OpenAPI 描述；
• MCP Server。

Kernel 负责注册函数、传递依赖、调用模型并把 Function Calling 请求路由到正确的 Plugin。业务中的鉴权、审批、重试和状态管理仍应由应用代码控制。

MCP：把能力从单个应用中抽离出来

当同一套文件、数据库或 SaaS 能力需要同时提供给多个 AI 客户端时，继续为每个应用手写 Plugin 会产生重复集成。MCP Server 把这些能力按统一协议暴露出去，不同 Host 可以通过自己的 MCP Client 发现和调用。

什么时候只用 Semantic Kernel

以下场景先不要引入 MCP：

1. 只有一个后端应用和少量内部函数；
2. 函数依赖当前进程中的数据库连接、缓存或领域服务；
3. 不需要让 Cursor、Claude Desktop、VS Code 或其他客户端共享能力；
4. 工具列表固定，不需要运行时发现；
5. 团队更关注 Agent 编排、审批和业务状态，而不是跨客户端协议兼容。

这时直接把业务服务注入 Semantic Kernel Plugin，结构更简单，也更容易调试。

什么时候优先使用 MCP

以下场景更适合把能力做成 MCP Server：

1. 同一个工具需要被多个 AI Host 复用；
2. 工具由不同语言或不同团队维护；
3. 需要在运行时发现工具、资源或提示模板；
4. 本地工具要通过 stdio 接入桌面客户端；
5. 远程能力要通过 Streamable HTTP 提供给多个用户；
6. 希望把工具服务与 Agent 编排解耦，分别发布和升级。

需要注意：MCP 只让连接方式标准化，并不会自动替你完成租户隔离、最小权限、审计、速率限制和高风险操作审批。

推荐组合架构

企业项目可以把两者组合成四层：

1. Application Layer
   API、Web、桌面端、用户身份与业务权限

2. Semantic Kernel Layer
   模型路由、Plugin 注册、Agent 编排、Human-in-the-loop

3. MCP Client Layer
   Server 连接、能力协商、工具发现与调用路由

4. MCP Server Layer
   文件系统、数据库、CRM、监控平台、内部 API

在这套架构中：

• Semantic Kernel 不直接获得无限制的数据库或文件权限；
• MCP Server 只暴露经过收敛的工具和资源；
• 高风险写操作在应用层或 Plugin 层增加人工确认；
• 每次 Tool Call 都记录用户、Server、工具名、参数摘要和执行结果；
• 本地工具使用 stdio，远程共享服务使用 Streamable HTTP 和认证。

一个实际选型决策表

项目情况	推荐方案
单个 .NET 服务调用 5 个内部函数	Semantic Kernel Plugin
一个 Agent 要组织多个业务 Plugin	Semantic Kernel
Cursor 和内部聊天助手都要访问同一套文档工具	MCP Server
多语言团队需要共享相同工具接口	MCP Server + 各自 MCP Client
Semantic Kernel Agent 需要调用远程 CRM 工具	Semantic Kernel + MCP Plugin
只需要模型输出一个函数名和参数	原生 Function Calling

常见误区

误区一：用了 MCP 就不需要 Agent 框架

MCP 不负责完整的 Agent 决策循环、业务状态和人工审批。它提供连接和能力交换，编排仍然要由 Host、Semantic Kernel、LangGraph 或你的业务代码完成。

误区二：Semantic Kernel Plugin 只能写在本地代码里

Plugin 不只来自原生代码，也可以从 OpenAPI 或 MCP Server 导入。需要跨平台共享时，可以逐步把成熟能力从进程内 Plugin 抽成 MCP Server。

误区三：所有函数都应该改造成 MCP Server

把只供单个服务使用的简单函数拆成独立 Server，会增加进程、连接、认证和运维成本。是否使用 MCP，应由“是否需要跨边界复用与治理”决定，而不是由技术热度决定。

最终建议

• 单应用、少量内部函数：先用原生 Function Calling 或 Semantic Kernel Plugin。
• 需要 Agent 编排和企业应用集成：以 Semantic Kernel 为主。
• 需要跨客户端、跨语言和远程共享工具：把稳定能力做成 MCP Server。
• 复杂企业系统：Semantic Kernel 负责编排，MCP 负责连接，二者组合而不是二选一。

继续阅读

• MCP 和 Function Calling 有什么区别？真实项目选型、API Gateway 与组合架构
• MCP JSON-RPC Parse Error 排查：stdout、stdio 与 Tool list failed
• MCP Streamable HTTP 远程部署实战
• MCP 专题：协议、部署、安全与排障路线
• AI Agent 架构：从工具调用到生产级编排

专题入口 / MCP Hub

继续按 MCP 生产部署路径读，而不是堆 guide / tutorial

MCP 内容统一按协议理解、本地 Server、远程部署、OAuth、安全治理、stdio/JSON-RPC 排障和工具对比来承接，避免站内关键词互相抢。

进入 MCP 专题 → 查看安全治理清单 订阅更新