随风
随着大模型的飞速发展，大模型对于现实世界的交互也有了长足的进步，Langchain成为打响这一战役的第一枪，其使用提示词的方式率先使得大模型得以与现实世界交互，随后OpenAi推出了具有代表意义的Function Calling技术，这项技术使得模型可以“调用”外部函数，它成为了模型与外界交互的新选择，随后智能体技术得到了巨大的发展，Agently和Promptulate等智能体框架飞速发展，使其成为2024年AI应用的宠儿。随后Dify和Coze等智能体应用也应运而生，它们的特点都是针对AI的不稳定性质，对其使用人工编排的WorkFlow即工作流替代，使其成为企业落地的首选。按照这个发展趋势，统一的智能体或者框架类似web世界的各种框架应当得到巨大发展，极大减少人们开发AI应用的成本。
然而故事却在2025年发生了巨大的变化，智能体框架不再成为大家落地AI应用讨论最多的点，业界开始着眼于工具调用统一协议这个问题，于是mcp协议开始走向大众视野，一时间各种营销号开始疯狂鼓吹mcp能够实现的各种强大功能。然而很多人却没有理解mcp的本质。MCP 是一个开放协议，它为应用程序向 LLM 提供上下文的方式进行了标准化。你可以将 MCP 想象成 AI 应用程序的 USB-C 接口。就像 USB-C 为设备连接各种外设和配件提供了标准化的方式一样，MCP 为 AI 模型连接各种数据源和工具提供了标准化的接口。
MCP协议的飞速发展，衍生出了各种MCP服务提供者，其后形成了MCP市场生态，这极大的丰富了AI应用的能力边界。而后MCP协议开始进军传统的物联网行业，开始成为控制万物的新协议，著名的开源项目小智AI就全面拥抱了MCP协议，使得其可以轻松扩展各种丰富有趣的功能。然而MCP协议获得巨大成功的同时却又由于自身设计的局限，对其进一步发展产生了限制，比如MCP协议的服务端，其设计初期MCP服务器运行多在本地，用于给克劳德客户端使用，然而对于云服务提供的开发者来讲却出现了一些困难。SSE协议的不稳定，随后虽然有stremable http的替代但是至今未形成强大的生态。小智不得不破坏了一些MCP规范来获得远程服务端的支持，小智AI具体方案是将MCP服务端视为客户端，创造了一个新的管道链路层，这种办法虽然能够解决当下的问题，然而属实是不够优雅，需要开发者重新适配，造成了当今大家都是MCP协议却无法互通的尴尬局面，多少与Type C有些类似了。
MCP协议作为通用的协议，其始终也未能解决工具编写依赖精巧提示词设计的问题，这也不是MCP协议该解决的问题，更让人头疼的是MCP混乱的服务器命名和工具设计，导致其稳定性堪忧，在生产环境上无法有效运用的问题，在AIOT领域虽然其动态发现，动态注册的优势十分明显，但其却无法较好解决跨设备控制，以及更复杂的设备控制场景，究其原因还是因为其设计之初并没有考虑AIOT的应用场景，因此我觉得MCP协议作为智能体能力扩展本身意义非凡，但应用于AIOT领域则需要等待时间的验证。
很久没有写过这么长的随笔了，感谢大家看到这里，欢迎关注我们社区公众号，我们下期不见不散。
