最近 MCP 火的一塌糊涂，似乎不拥抱就赶不上时代一样，然而我做了个服务测了下，似乎宣传>应用...
文章有点长，先说结论：
MCP 三个关键词：自动发现、标准化以及解耦合
MCP 是 For Agent 的产物，非 Agent 下似乎没什么用处，比如在工作流中使用
MCP 在应用上类似 dify/Coze 等的插件，然而成熟度还差一些
或许 MCP 更适合 Cursor/VS Code/Claude Desktop 等本地 IDE 集成的 Agent
结尾有所有参考文章、视频、项目的链接
最近公司培训，看到同事用 Cursor 借助 MCP 协议使用 Agent 调用第三方工具做 Red Teaming，觉得好玩于是测试了下（实际上只是看了下代码测了下流程，Cursor 的 Agent 模式是付费项目，我并不想花 20 刀就为“玩一下”）。
工作原理其实很简单：
似乎任何一个 Agent 应用都能干类似的事，MCP 并没有太大价值？
那我们再换一个问题，这次的问题不再是一个查询类问题，而是需要入参才能执行的一个任务。
MCP Server：明面上是服务端，然而更像一个功能汇聚服务...在里面去定义有哪些工具（函数）可以使用，以及参数是什么 MCP Client：和 MCP Server 交互的工具，在上图中内嵌在了 IDE 中
{
"mcpServers": {
"EnkryptAI-MCP": {
"command": "uv",
"args": [
"--directory",
"PATH/TO/enkryptai-mcp-server",
"run",
"src/mcp_server.py"
],
"env": {
"ENKRYPTAI_API_KEY": "YOUR ENKRYPTAI API KEY"
}
}
}
}
在上面的示例中，实际上 MCP Server 是由 MCP Client(Cursor) 来本地启动的，这要求 Client 和 Server 在同一台主机上（两者通过 stdio 通信），为了支持跨主机的通信，MCP 有另一个通信模式叫 SSE（Server-Sent Events）。
SSE 底层跑的还是 HTTP，只是上层有自己的通信规范，可以理解为造了个标准的 API。
再回到标题，如果要让 Dify 对接 MCP Server，其实只需要完成下面两件事：
在外部服务器部署支持 SSE 的 MCP Server
在 Dify 上安装支持 SSE 的 MCP Client（插件）
MCP Server 配置及启动
我参照一个 Weather 的 MCP SSE 项目，用 Github Copilot 将我司的 AI Security API 改成了 SSE 版本的 MCP Server，启动：
uv run src/mcp_server.py
INFO: Started server process [4093949]
INFO: Waiting for application startup.
INFO: Application startup complete.
INFO: Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)看到状态为 Running 且在监听端口之后，就可以在 Dify 中进行测试啦。
插件安装及配置
在 Dify 1.x 版本下，插件商店搜索 MCP，安装下列插件：
配置 MCP Server，参考配置如下，指一下 MCP Server 的 URL 即可：
{
"PANW-AI-Security": {
"url": "http://10.10.50.144:8080/sse"
}
}配置截图：
调用示例：
MCP 和 Dify Plugin 的对比
在写 SSE Server 的时候，发现有些理念和 Dify Plugin 有点类似，但又有些区别，分别用图片和文字描述下。
从功能上来说，最终目的是一样的，让大模型调用外部服务；
从架构上来说，如果要让大模型调用外部组件，插件可以一跳直达外部服务，而使用 MCP 则需要外挂一个 MCP Server 做中转。
如果再复杂一点，假如让 Agent 调用多个服务，这时候你会发现两个很像，只是 MCP 把能力集中在了外部，而在 Dify 下能力集中在插件中。
这或许这就是 MCP 的第三个价值：与应用解耦。
早期 Dify 的插件内置在发行版中，如果要更新、新增插件需要改动项目文件。Dify 1.0 之后可以把插件“外置”，通过 dify-plugin-daemon 来管理和运行，这实际上是一种解耦，只不过这些插件只适用于 Dify 生态，其他平台不能直接拿来使用。
如果使用 MCP 架构，理论上来说一套 MCP Server 可以给多个 AI 平台使用，没有太多的适配成本。另外如果要对服务进行更新，只需要更改 MCP Server 侧的代码即可，应用本身可以不用动。
说完了优点，再说说 MCP “弱”的地方。
1. 无处安放的 Key/Token
你会发现，在第一个 Cursor 的示例中，调用外部服务的 API Key 直接写在了配置文件的环境变量中，总感觉这类敏感信息需要有个安全的地方存放。
在做第二个 Dify SSE 对接的时候，Key 需要直接放在运行代码的地方，也就是 MCP Server 所在位置，查了很多文档，大家要么直接写在环境变量里，要么直接写在代码里...(说到这里，未来应该会有一些 MCP Manager 方案出来做这些事)
还有一种形式是放在 Client 侧，以 Header 或者 HTTP 请求参数的形式传递给 MCP Server，然而这部分并没有规范。另外，Client 侧如何妥善保存密钥也是个问题，无论 VS Code/Cursor 还是 Dify 的社区 MCP 插件，都是明文直接放在 JSON 中...
相比之下，Dify Plugin 的设计就很好，变量属性为 secret-input 时都会隐蔽保存。
2. 认证怎么做？
官方的一些示例中，会在 Server 设置一个 Key（如上面所说，无处安放），然后 Client 通过 Header 等形式传输同样的 Key 以达到认证的目的，这未免显得有点粗糙（官方有很多和认证相关的 issue，应该会补齐这部分功能）。
而在 Dify 下 Plugin 和 Dify 就是一体的，不需要考虑组件间的信任。
3. 安全隐患
因架构决定 MCP Server 侧的东西可以是动态的，如果有居心叵测之人修改/增加了 MCP Server 中的函数，模型又自动调用了这些模块，风险自不用我说。（已经有安全团队 Demo 通过 MCP tool 的 description、隐藏的提示词、虚假报错信息等诱导大模型执行特定操作...）
相比之下 Dify 的 Plugin 好歹会有官方验证，升级也需要用户干预，虽然不那么自动，但风险相对更小一些。(魔搭社区、smithery 等很多平台已经有成型的 MCP 商店了，有些还集成了安全扫描功能，一定程度上可以解决来源和安全问题)
4. MCP Server 管理及运行
在当前的实现下，通常一个 MCP Server 对应一个服务商的多个服务，如果一个 Agent 需要使用 20 个服务商的服务，那需要配置 20 个 MCP Server，不同 MCP Server 可能会有不同的依赖环境，不同的配置，不同的认证方式，这些还都是通过 json 文件去定义...
不确定官方会不会有一个集中式的管理、运行和接入服务，反正社区是有人在做了。
5. 在 Dify 下，仅能用于 Agent，不能应用于工作流。
虽说 Agent 是未来 AGI 的方向，但实际在应用时，工作流也有其优势，并不是所有场景都适合用 Agent 实现，而目前在工作流下 MCP 并没什么用。
引用一个 Anthropic 《Building effective agents》中的 Checklist：
你会发现日常 AI 应用中，很多时候并不需要用到 Agent，用 Agent 效果不一定更好，但 Token 肯定消耗更多(老黄狂喜)：
RAG 应用，做个知识检索，贴出结果和参考链接就 OK 了
联网检索，工作流+工具+LLM 也能做
要多功能，直接做成多个机器人就行了，不同机器人走不同的工作流，不需要 Agent 来判断用户想干什么再去选择不同的工具，用户自己会选
...
再看目前最亮眼的 Agent 应用，就是类似 Manus 一样的代码开发系统，满足上面的各种说明：
节省（程序员）成本；
足够复杂，需要自动试错和纠错；
只要开放接口，Agent 可以自己去运行慢慢调试
...
说到这里，似乎感觉 MCP 就像是 Anthropic 为了自家代码开发 Agent 打造的一样... 开发类 Agent 就是要调用很多工具，而标准化这些工具的调用，很能受益这类 Agent。
技术上来说，Dify 等平台其实可以做一个专用于 Workflow 的 MCP Client 插件，自动获取 MCP Server 的参数列表，然后将其变成表单供应用使用，不知道未来会不会有这样的东西出现。
感觉这次的分享可以到此结束了， 已 3k 余字，能看到这里的都是真爱。
对待新的事物，还是要冷静分析，感觉 MCP 还是有点过热了。和家人戏说，现在 MCP 生态就像卖装修建材的多(MCP Server)，但是修房子和买房子的不一定有这么大需求(Agent)。
