文章核心观点 - Anthropic公司推出的模型上下文协议在发布一周年之际，其发展现状与最初的宏大愿景形成巨大反差，行业接受度表面提升但实际关注度低迷，且其自身产品策略也在向名为Skills的新系统倾斜[1] - MCP协议旨在解决AI应用开发中重复造轮子的痛点，但其在工程落地中暴露出导致模型效率降低、成本激增、可靠性下降以及安全隐患等根本性缺陷[3][4][5][6][7] - MCP生态因门槛过低导致大量重复和低质量的工具涌现，增加了开发者的筛选成本，并存在广泛的安全漏洞[8][9] - Anthropic公司通过推出Skills系统并在技术上优化MCP调用方式，实质上是对MCP原始设计缺陷的修正，标志着其从试图统一世界的通用协议向更务实、定制化方案的转变[10][11] - 无论是MCP还是Skills，都是当前AI智力不足阶段的过渡性工程补丁，MCP的最终生态位可能将回归为处理长尾数据的基础设施，而非万能解决方案[12][13][14] MCP协议的发展现状与行业接受度 - MCP Registry目前收录了近2000个Server，比9月份刚上线时增长了407%[1] - OpenAI、Google、AWS、HuggingFace等主要行业参与者均已宣布接入MCP，使其在纸面上成为一个被行业接受的开放标准[1] - 尽管有官方数据支持和行业巨头背书，但MCP周年庆在社交媒体上几乎未引发讨论，关注度与发布时的轰动形成鲜明对比[1] MCP协议的设计初衷与核心承诺 - MCP协议旨在解决AI应用开发中，开发者需要为每个外部服务（如Google Drive、Slack）重复编写适配代码的痛点[3] - MCP承诺“一次开发、处处运行”，即服务提供商编写一个MCP Server后，可被Claude、Cursor等各种AI Agent直接使用，无需重复适配[3][4] - 发布初期，开发者社区反应热烈，GitHub上涌现大量MCP项目，覆盖查天气、看股票等多种功能[4] MCP协议在工程落地中的主要缺陷 - 上下文与成本问题：MCP调用需占用模型上下文窗口，工具定义、请求和结果均消耗Token，多次调用后上下文迅速膨胀，导致成本激增[4] - 例如，仅GitHub官方的MCP就定义了93个工具，消耗55000个Token；挂载20个MCP Server几轮对话后上下文就可能耗尽[4] - Anthropic承认，处理一份两小时会议文档可能额外消耗50000个Token，更大文档会导致工作流崩溃[5] - 模型性能下降：当加载过多MCP工具时，模型的注意力被稀释，可能导致推理错误，例如不信任工具返回的正确结果（如将-9误报为+9）[7] - 安全隐患：早期MCP权限设计粗放，例如文件系统MCP可能赋予AI读写整个磁盘的权限，曾导致代码库被误删等事故，引发企业安全部门的担忧[7] MCP生态面临的质量与安全问题 - 由于搭建MCP Server门槛极低（几十行代码），导致生态中充斥大量重复和低质量的工具，真正设计精良、维护活跃的很少[8] - 一项针对近1900个MCP Server的研究发现，大量存在凭证暴露、缺乏访问控制、CORS问题、资源管理不当、传输安全等问题，安全隐患普遍[8][9] - 生态的虚假繁荣反而增加了开发者筛选可用、可靠工具的成本，有时甚至高于自己开发一个[8] Anthropic的产品策略转向与技术修正 - Anthropic在其最新版Claude中，正用一套名为Skills的系统接管越来越多的工作（如生成PPT、处理Excel），MCP在官方文档中的位置被边缘化[1][10] - Skills的本质是将高频、经过验证的能力封装为精简预设，进行原生集成，这比通过通用协议调用更快、更稳、更节省Token[10] - Anthropic在技术博客中提出新思路：让Agent编写代码去调用MCP，而非直接暴露工具定义，据称这种方式能减少98.7%的Token消耗，这被视作对MCP原始设计缺陷的变相承认[10][11] 对AI工具协议发展阶段的宏观看法 - MCP和Skills，连同Prompt工程，都是当前为弥补AI智力不足而采取的确定性工程补丁[12][13] - 真正的超级智能可能无需此类协议，能够自主适配和获取信息[13] - MCP并未彻底失败，Anthropic仍在推进其企业级功能，IBM也宣布将贡献企业级资产，但其定位已从“万能协议”回归为“基础设施”，最终生态位可能是：高频能力由Skills处理，长尾数据由MCP连接[14] - MCP的最大贡献可能在于促使行业不再盲目堆砌工具，而是开始思考哪些接口才是真正重要的[14]