关于 MCP（Model Context Protocol）的思考

03 Apr 2025

在与 GPT-4o 的对话中，我们探讨了 MCP（Model Context Protocol）的设计初衷及其在实际应用中的演变。以下是对话的核心观点总结：

MCP 的初衷：数据“注入”协议

MCP 最初的设计目标是作为模型与外部上下文数据之间的桥梁。它的核心是让模型能够“看到”并“理解”外部系统的数据。典型的应用场景包括：

• 从 CRM / ERP / 数据库中提取用户上下文、产品信息、日志等；
• 在对话中动态提供模型无法预知但很重要的上下文数据；
• 以结构化、标准化的方式嵌入外部知识或状态信息，辅助推理。

在这些场景中，数据的流向是从外部系统到 MCP，再到模型。

实际使用中的新模式：MCP 被反向利用

在一些项目中，如 playwright-mcp，模型通过 MCP 向外部发送“命令式结构”，由 MCP 调用 Playwright 来操作浏览器。这种用法反转了数据流向：

• 流向变成了从模型到 MCP，再到外部系统（如 Playwright）；
• 模型不再是被动接收上下文，而是主动发出指令；
• MCP 从“上下文供给器”变成了“任务执行代理”或“API driver”。

这种用法更像是工具协议或 Agent Action Protocol，偏离了 MCP 的命名和原始范式。

为什么会这样演化？

这种“反向使用”现象的背后有几个原因：

1. MCP 本身定义灵活，没有强制限制数据流向，因此可以反过来用；
2. 开发者习惯复用现成协议框架，不想重复造轮子；
3. Agent 越来越流行，尤其是在 LangChain、AutoGPT、OpenAI Function Calling 等框架影响下，大家开始习惯“模型发出指令→工具执行→返回结果”的范式；
4. Playwright 等工具，本来就非常适合被当成 Agent 执行器的“手脚”。

总结

• MCP 的初衷是让大模型访问外部数据，这一观点是正确的；
• 现在有些 MCP 被当作工具协议来用，方向反了，这一观点也是正确的；
• 这种用法在形式上确实偏离了原始设计目标，尽管从“让模型更有能力”的角度看，是一种自然演进。

如果你对 MCP 的演变有更多的想法，欢迎一起探讨！