作者更倾向于使用MCP而非Skills，认为MCP更适合当前需求，而Skills存在一些使用上的不便。文章探讨了两者的优缺点，强调应根据具体场景选择合适的工具。

我依然偏爱MCP而非技能——论AI服务集成的正确架构选择

核心观点：在AI领域推崇"技能"(Skills)作为大语言模型(LLM)能力扩展标准的浪潮中，作者David Mohl坚定支持更优越的模型上下文协议(MCP)。本文通过实际使用场景对比，揭示了技能体系的固有缺陷，并提出了二者协同的理想架构方案。

争议背景

当前AI社区出现"MCP已死，技能当立"的论调，主张通过SKILL.md文件标准化LLM能力扩展。但作为深度AI工具使用者（日常依赖Claude、ChatGPT等管理Notion笔记、邮件等），作者指出这种趋势存在根本性误区。

MCP的架构优势

MCP本质是API抽象层，其核心价值在于： - 零安装远程调用：通过URL连接即可使用服务 - 无缝更新：服务端更新自动同步到所有客户端 - 安全认证：内置OAuth等标准化认证流程 - 跨平台性：支持从手机到网页的全终端访问 - 沙箱保护：避免LLM直接获得本地执行权限 - 智能发现：按需加载工具接口，节省上下文窗口

技能体系的致命缺陷

当技能需要依赖CLI时会产生系列问题： 1. 环境限制：多数Web版AI工具无法执行本地CLI 2. 部署混乱：需要管理二进制包、NPM模块等分发渠道 3. 密钥危机：缺乏安全的凭证管理机制 4. 生态割裂：各平台技能安装方式不统一 5. 上下文膨胀：需加载整个技能文档而非特定接口

最佳实践方案

作者提出架构选择黄金法则： - MCP适用场景：服务连接（如日历管理、浏览器控制） - 典型案例：Google应提供mcp.google.com/calendar而非gcal CLI - 开发工具应原生集成MCP（如Xcode、Hopper调试器）

• 技能适用场景：纯知识传递
  • 工具使用教学（如curl命令规范）
  • 工作流标准化（企业内部术语）
  • 文件处理规范（如PDF操作指南）

术语革新建议

作者提出更精准的命名方案： - Connector：替代MCP，强调服务连接 - LLM_MANUAL.md：替代技能，明确知识文档定位

实践案例

作者展示了自己的项目如何践行这一理念： - mcp-server-devonthink：为DEVONthink提供干净接口 - Microfn和Kikuyo：云原生MCP服务 - MCP Nest：将本地MCP隧道至云端

协同模式创新

最具启发性的是"技能+MCP"组合模式： 1. MCP处理实际服务连接 2. 技能文档记录使用技巧（如日期格式要求） 3. Claude等AI自动将经验沉淀为技能 这种组合既保持接口标准化，又避免重复踩坑。

行业呼吁

作者担忧MCP被边缘化将导致： - 服务集成退回CLI时代 - 丧失跨平台一致性优势 - 增加安全隐患

文末推广的MCP Nest项目，正是为解决本地MCP远程访问难题而生，体现了作者对架构理念的实践坚持。

（注：原文中的社交媒体分享链接、导航菜单等非核心内容已精简，保留技术论证主线及关键示例）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

支持MCP的观点

1. MCP适合企业级和标准化场景

   • "MCP makes a lot of sense for enterprise... Defines auth and interfaces naturally" (grensley)
   • "MCP is better for restricted environments... solves distinct problem sets" (woeirua)

2. MCP的可靠性与安全性

   • "Remote MCPs are secure... solves delivery and update issues" (baq)
   • 工具推荐："protomcp.io helps test MCP servers" (michaelashley29)

支持Skills/CLI的观点

1. 灵活性与低开销

   • "CLI is cheaper in tokens... I understand what's going on" (qalmakka)
   • "Skills allow progressive discovery... MCP pollutes context" (jauntywundrkind, bijowo1676)

2. 本地开发优势

   • "I want agents to use existing CLI tooling... no need for extra layer" (plandis)
   • "LLMs compose CLI tools naturally, unlike MCP" (jauntywundrkind)

中立/互补性观点

1. 两者适用不同场景

   • "Skills for knowledge, MCP for services" (tpoacher)
   • "MCP=infrastructure, Skills=orchestration" (alierfan)

2. 实际混合使用案例

   • "Use both: skill描述数据，MCP执行查询" (Xenoamorphous)
   • "MCP-CLI桥接两者" (senordevnyc)

争议与待改进问题

• MCP的局限性：连接超时、上下文污染（ghm2199, bijowo1676）
• Skills的不足：依赖环境、忽略指令（imron, lewisjoe）
• 未来改进方向：Skills需依赖管理钩子（simianwords）

关键分歧点在于：
- 企业用户倾向MCP（标准化），开发者偏好CLI（灵活性）
- 技术实现上，MCP的协议开销与Skills的环境依赖成为主要权衡因素