对于AI Agent开发者而言，尤其是在Claude或其他兼容MCP（Model Context Protocol）的平台上构建智能体时，一个核心问题经常浮现：某个特定功能究竟应该通过Skills还是MCP来实现？尽管这两种模式常被视为互为替代，但它们实际上解决的是不同类型的问题，并且大多数生产级别的智能体通常需要两者结合。
本文将提供一个清晰的决策规则，详细阐述这两种模式的定义，并指出在Agent开发中常见的反模式。
理解MCP与Skills
Model Context Protocol (MCP)： MCP是一种线协议，允许你的Agent通过JSON-RPC与一个MCP服务器通信。该服务器负责暴露各种工具、资源和提示。关键在于，MCP的运行时与Agent本身是分离的。这种设计使得MCP非常适合处理实时数据、有状态的操作、认证，以及任何需要实时连接到外部系统的交互。
Skills： 相比之下，Skills本质上是一个包含Markdown文件的文件夹。这些文件直接加载到Agent的上下文环境中，无需额外的运行时或协议。Agent将SKILL.md文件解读为一套指令或操作手册，并按照其中概述的步骤执行。Skills最适合封装程序性知识——例如操作指南或多步骤工作流——以Agent原生能够理解的格式。
简而言之，MCP负责建立与外部服务的动态连接，而Skills则作为Agent的静态内部操作手册。
核心决策规则
一个简单直接的规则可以指导我们的选择，并且在今年的多个Agent部署中都证明了其有效性：
- 处理实时数据或实时状态：选择MCP。 这适用于涉及数据库查询、第三方API交互、文件系统访问，以及任何需要通过网络请求获取或更新最新数据的操作。
- 处理可复用的程序性知识：选择Skills。 这包括Agent需要持续遵循的程序、约定或多步骤工作流。可以将其理解为将操作手册直接嵌入到Agent的上下文中。
- 两者皆需时：同时实施两者。 对于与复杂现实世界系统交互的工具来说，这种情况非常普遍，通常结合了实时交互和结构化的操作指导。
尽管这条规则看似不言自明，但在Agent开发中，持续遵循它仍然是一个常见的挑战。
案例分析：AgentGuard的混合实现
AgentGuard是一个用于AI Agent预算和速率限制的解决方案，它提供了一个极佳的示例来阐释MCP和Skills的协同作用。
Skills部分： AgentGuard的SDK作为Agent进程内（in-process）的组件运行。开发者安装该软件包后，用@guard(budget_usd=2.00)等装饰器修饰其Agent函数，该装饰器会在每次调用时在本地处理token计数和预算执行。由于此逻辑在Agent自身的进程内确定性地执行，不需要与外部实时系统交互，因此非常适合作为Skills来实现。一个SKILL.md文件可以指导Claude Code如何识别项目中对LLM API的使用，并应用带有合理默认值的装饰器——这体现了程序性知识。
MCP部分： 另一方面，AgentGuard仪表盘是一个独立的、分离的服务。它跟踪跨Agent运行的支出、触发警报，并允许设置组织范围的预算。Agent要与此仪表盘进行交互——例如查询每小时花费或检查用户是否超出限额——就需要与有状态的后端建立实时连接。这种实时、外部数据交互显然属于MCP的范畴。
这个例子表明，同一个产品可以巧妙地利用这两种模式，每种模式都完成了另一种模式无法有效处理的任务。
Agent开发中常见的反模式
在代码审查中，一个常见的反模式是将本应由MCP处理的API调用封装成Skills。例如，创建一个Skills，其中明确写着“步骤1：向api.example.com发送带有此payload的HTTP请求，步骤2：解析响应”，这从根本上误用了Skills模式。这种直接的API调用，特别是那些涉及外部端点和动态数据的调用，正是MCP旨在高效且健壮地处理的。
Skills旨在用于Agent内部、确定性的程序性指导，而不是作为实时、有状态的外部通信的包装器。