热捧Skills批判MCP问题不在协议而在你未改变思维

AI圈最近有个有趣现象：Skills被热捧，MCP被各种唱衰。社交媒体上到处是“MCP协议要凉了”的声音，开发者纷纷转向Skills。

Skills怎么来的，有什么用，怎么开发，可以看作者之前文章：Anthropic 为什么推出 Skills？它会革谁的命！文中把MCP与Skills的恩怨讲得明明白白。

但开发者Philipp Schmid直接撰文开怼：你们搞错了重点。并给出了构建MCP Server的最佳实践。

MCP背锅，Skills躺赢？

MCP协议发布一年来，企业级部署已经上线，集成在运行，但结果令人失望。这种对比让很多人得出结论：MCP设计有问题，Skills才是未来。

但作者的观点很犀利：协议没问题，是你的服务器设计烂。

大多数开发者把MCP服务器当成REST API的简单封装。这种思路的根本问题在于，REST API是为人类开发者设计的，而MCP是给Agent用的界面。两种用户，需要完全不同的设计原则，不要把REST API思维硬套MCP。

人类开发者 vs Agent：设计差异一目了然

人类开发者可以一次性阅读文档，然后组合多个API端点完成复杂任务。但Agent每次调用都需要重新解析工具描述，多次往返通信会显著降低效率。

订单跟踪的实战对比

假设你在构建一个订单跟踪Agent。

糟糕的MCP设计会暴露三个工具：

这强制Agent进行三次往返调用，在对话历史中存储所有中间结果。

优秀的MCP设计只暴露一个工具：track_latest_order(email)。在服务器端完成所有协调工作，返回“订单#12345已通过FedEx发货，周四到达”。同样结果，一次调用，面向结果。

图中对比显示：不良设计需要3次往返才能完成订单跟踪，而良好设计只需1次。这个差距在每天数千次调用的生产环境中会被放大。

六个实用设计原则

1. 结果导向，而非操作导向

别把底层API操作直接暴露为工具。设计时要思考：Agent想要达成什么目标？然后围绕这个目标设计工具。在服务器代码中完成编排，而不是在LLM的上下文窗口中。

2. 参数扁平化

避免复杂的嵌套字典或配置对象：

3. 文档即指令

工具的描述文档不是给人类看的注释，而是给Agent的操作指南。要明确说明：

• 何时使用该工具（“当用户询问订单状态时使用”）
• 如何格式化参数（“邮箱必须小写”）
• 期望返回什么（“返回订单ID和当前状态”）

错误信息也要设计成可操作的提示。不要抛出Python异常，而是返回有用的字符串：“未找到用户。请尝试用邮箱地址搜索。”Agent会将错误视为观察结果，并使用你的指令在下一轮中自我纠正。

4. 精心筛选工具

Agent在严格的上下文约束下运行。每个工具描述、每个响应负载、每个错误信息，都在上下文窗口中竞争空间。

• 每个服务器5-15个工具
• 一个服务器，一个职责
• 删除未使用的工具
• 按角色分割（管理员/用户）

5. 命名要有发现性

使用{服务}_{操作}_{资源}的命名模式，如slack_send_message、linear_list_issues、sentry_get_error_details。避免通用的create_issue或send_message这类容易冲突的名称。

你的MCP服务器会与其他服务器一起运行。如果GitHub和Jira都有create_issue，Agent只能猜测使用哪个。

6. 分页处理大数据

永远不要一次性返回数百条记录：

• 支持limit参数（默认20-50条）
• 返回has_more、next_offset、total_count等元数据
• 永远不要将所有结果加载到内存中

Skills vs MCP：根本不是竞争关系

很多讨论把Skills和MCP放在对立面，但这完全是误解。

Skills解决的是“什么时候用什么工具”的问题：

• 渐进式加载（启动时只看元数据，触发时才读指令）
• 工作流指导（告诉Agent在特定场景下的操作步骤）
• 本地执行（通过bash等通用工具提供功能）

MCP解决的是“怎么可靠地调用工具”的问题：

• 标准化接口
• 参数验证
• 类型化响应
• 错误处理

它们根本不冲突。在企业环境中，MCP服务器暴露各团队的服务能力，Skills教Agent如何组合这些能力完成具体工作流。

Gmail实战：两种设计的天壤之别

传统REST思维（糟糕）：

# 读邮件要2个工具   理解复杂嵌套
def messages_list(query: str, max_results: int) -> dict
def messages_get(message_id: str, format: str) -> dict
# 发邮件要构造base64编码的MIME
def messages_send(message: {"raw": str}) -> dict

Agent优先设计：

# 简单直接
def gmail_search(query: str, limit: int = 10) -> list
def gmail_read(message_id: str) -> dict
def gmail_send(to: List[str], subject: str, body: str) -> dict

核心问题：你在为谁设计界面？

作者的核心观点很清楚：MCP是Agent的用户界面，不是基础设施。

当你构建MCP服务器时，问自己：

• 这个工具是为了完成什么目标？
• Agent能一次性获得所需信息吗？
• 参数设计是否清晰无歧义？
• 错误信息能帮助Agent自我纠正吗？

Skills热度高是因为它从一开始就是为Agent设计的。MCP被批评是因为大家把它当REST API包装器。

但如果你真正理解了用户是谁，MCP服务器一样可以设计得很优秀。问题不在协议，在设计思维。

企业级的认证、限流、重试、审计——这些生产环境的硬需求，最终还是要在服务器层面解决。协议只是载体，服务器设计才是关键。

写在最后

当前AI的火爆吸引了太多目光，任何一个新概念被提出，都会迎来大众的追捧和过度炒作。过去MCP如此，现在Skills也是如此。这种现象背后，反映的是行业对“银弹”的渴望，和对落地产生真实价值的焦虑。

但现实是，AI工程技术会随着模型性能的提升快速迭代，周边生态也在快速发展。每隔几个月就会有新的框架、新的协议、新的最佳实践出现。在这种快速变化的环境中，不关注实际成效，盲目追逐新概念往往得不偿失。

真正重要的是如何将每一个理念做扎实。无论是MCP还是Skills，核心都在于理解用户需求，设计合理的抽象，解决实际问题。如果只是浅尝辄止，跟风炒作，到最后都会沦为一个个鸡肋的概念。看起来很美，用起来很鸡肋，最终被下一波热潮淹没。

技术的价值不在于概念的新颖，而在于实现的质量。与其纠结要用哪个新出的技术，不如先把基础做好，从“第一性原理”出发，把握发展脉络：理解你的用户是谁，他们要解决什么问题，你的设计能否真正帮到他们。这个思路，适用于MCP，也适用于Skills，更适用于未来会出现的任何新技术。