简介：智能体技能（Agent Skill）是把任务知识、参数规则、执行逻辑与结果规范封装成可复用“能力单元”的应用层设计模式，而模型上下文协议（MCP）是连接大模型与外部工具的数据交换标准。本文从定义、组成、工作方式、生态机制四个维度分析 Agent Skill 热度低于 MCP 的原因，并给出二者协同使用的选型建议。
智能体技能（Agent Skill）并不是一个新的通信协议，也不是某一个固定产品，而是一类面向智能体运行时的能力封装单元。它将“完成某一类任务所需的描述信息、触发条件、输入参数、执行逻辑、输出格式和异常处理”打包成一个整体，让智能体在需要时能够调用它。
这个定义包含几个关键点：
从业务视角看，Agent Skill 像是一份“岗位操作手册”：手册里写清楚了什么条件可以触发、需要哪些材料、按什么步骤处理、最终要交付什么格式。从技术视角看，它是一个“函数 + 元数据 + 策略”的组合。从使用者视角看，它是智能体能力列表中的一项，用户不需要关心技能内部实现了什么协议。
MCP 常被用来指代“模型上下文协议（Model Context Protocol）”，它是连接模型应用与外部工具、数据源、服务系统的一种标准化交互协议。
MCP 解决的是“模型如何访问外部能力”的问题，而不是“某个任务怎么做”的问题。它定义了客户端、服务端、传输方式、工具发现、调用格式和权限边界。通过统一协议，一个模型应用可以接入多种外部服务，一个外部服务也可以被多种模型应用复用。
所以，Agent Skill 和 MCP 并不在同一层：
很多讨论把两者放在一起比较，其实是在比较“能力”和“连接方式”。这个错位本身，就是“为什么 Agent Skill 没有 MCP 火爆”的第一个原因：两者不是一个维度的事物，无法真正地用“热度”对等比较。
一个完整的 Agent Skill 通常包含以下几个模块：
包括技能名称、ID、版本、描述、可见范围、依赖条件。元信息最重要的作用是帮助智能体在规划阶段判断“这个技能适不适合当前任务”。描述写得越准确，智能体越不容易误用。
说明该技能适用于哪些场景，不适用于哪些场景。例如“查询行政区划”可以明确说明“用于校验省市区名称和编码，不用于计算地理距离”。这能有效减少模型幻觉或误调用。
定义调用技能需要的参数，通常使用结构化描述，例如字段类型、是否必填、取值范围、默认值。清晰参数约束是技能可靠性的基础。
这是技能真正干活的部分。它可以是一段本地代码、一个内部函数，也可以是调用外部服务。执行逻辑应包含重试、超时、降级和错误处理。
定义返回给智能体的结果格式，例如结构化 JSON、状态码、错误信息。规范输出的价值在于，智能体可以继续基于结果进行推理和回答。
一些技能会附带少量 few-shot 示例，帮助模型理解调用方式。例如“用户说武昌区在哪，实际应返回湖北省武汉市武昌区”。
下面是一个简化示意：
{"skill": "行政区划校验","description": "校验用户输入的地点名称与官方行政区划是否一致","input": {"location": "string","includeYear": "number"},"output": {"code": "string","name": "string","level": "string"},"executor": "调用官方区划数据服务，完成标准化与边界匹配"}
MCP 的抽象结构通常可以概括为：
MCP 的核心价值是“互操作性”：它让工具提供方只需要实现一种标准连接方式，就能让多个模型应用直接使用。这种“一次接入、多处可用”的机制，是它迅速形成生态的重要原因。
当用户提出请求后，智能体首先进行任务规划，判断需要完成哪些步骤，然后从已有技能列表中选择合适技能。选择技能后，智能体按照输入契约填充参数，调用技能执行逻辑，再读取输出，结合上下文生成最终答案。
这个过程可以概括为：
用户请求 → 智能体规划 → 匹配技能 → 参数校验 → 执行 → 返回结果 → 生成回答
Agent Skill 的成败取决于“技能边界是否清晰”和“执行结果是否可信”。它更像是智能体内的“私有的业务能力沉淀”。
MCP 的工作流程更偏向系统集成：
模型应用 → MCP 客户端 → 传输层 → MCP 服务端 → 外部服务
模型应用通过客户端发现服务端提供的能力，调用对应工具或资源，服务端完成实际操作并返回结果。整个过程可以跨进程、跨网络、跨系统。
举例来说，如果要做一个地点地址自动填充功能，可以用 MCP 连接官方地名信息平台，提供查询接口；再在智能体内部封装一个“行政区划校验技能”，负责提取用户输入中的地名关键词、决定是否调用接口、比对编码、处理异常，最终输出标准行政区划。这里 MCP 负责“连接数据”，Agent Skill 负责“完成任务”。
MCP 是一个有明确规范、版本、传输模型和客户端服务端角色的协议。它给开发者一种“接入行业标准”的确定性。
Agent Skill 没有一个统一标准。不同智能体框架对“技能”的定义各不相同：有的把技能当作提示词，有的把它当作工具集合，有的把它当作一个可安装的插件。“技能”这个词本身太通用，含义被稀释后，就很难形成统一的技术共识。
MCP 具有明显的网络效应：外部系统实现一个 MCP 服务端，可以被所有支持该协议的模型应用复用；模型应用接入 MCP 客户端，就可以访问大量已有服务端。每增加一个服务端，整个生态的价值都会提升。
Agent Skill 通常绑定在某个具体的智能体或业务系统内。一个技能写得再好，也很难直接拿到另一个智能体上运行。没有跨系统复用，就难以产生“接入即连接”的传播力。
MCP 解决的是“连接问题”：模型怎么调用工具、怎么访问数据、怎么突破自身的知识边界。这是几乎所有智能体应用都要面对的第一道门槛，因此关注度天然很高。
Agent Skill 解决的是“任务质量问题”：同一个工具已经连通了，如何让智能体在具体业务里不出错、不跑偏、返回结果更规范。这是一个更深入、也更分散的问题。在智能体还未大规模落地之前，任务质量优化往往还不是最紧迫的话题。
MCP 是一个专有名词，搜索、讨论、版本追踪都很容易形成集中热度。Agent Skill 则更像一个通用描述，不同企业、不同社区都可以按自己的方式解释它。当一个概念没有一个明确、可判定、可测试的定义时，它就会缺少被广泛传播的抓手。
MCP 作为协议层，天然适合由模型厂商、云厂商、软件服务商共同推动，因为协议能降低集成成本，让更多系统连接起来。Agent Skill 离业务更近，往往需要结合具体领域做深度定制，很难形成一种“统一运动”。这不是说 Agent Skill 不重要，而是它在产业中的位置决定了它不会像协议层那样喧闹。
在这些场景中，Agent Skill 的价值是“把经验沉淀为能力”。它可以让智能体从“能聊”变成“能干”。
在成熟架构中，Agent Skill 和 MCP 可以协同工作。MCP 负责打通系统与数据，Agent Skill 负责把下游能力组织成智能体可理解、可执行的“任务模块”。智能体先用技能决定“做什么”，再通过 MCP 解决“怎么连”。
一个比较务实的判断标准是：如果你的能力只需要在当前智能体内使用，先做 Agent Skill；如果这个能力需要被多个应用或第三方复用，再把它封装成 MCP 服务。不要让“追热度”驱动架构设计，而是让复用的真实需求决定是否使用协议。
使用 Agent Skill 时，要特别注意权限控制。技能一旦被调用，就拥有了执行能力，如果没有做好用户身份校验、操作审计和数据权限隔离，可能会带来误操作或越权风险。输入参数校验、返回结果校验、异常兜底流程都不可省略。
使用 MCP 时，要关注协议版本兼容性、服务发现方式、认证凭据管理、传输链路加密、调用频率限制和监控告警。协议本身不负责业务安全，真正的安全边界仍然需要业务系统自己实现。
另外，不要为了使用协议而使用协议。一个简单的本地计算、一个固定查询，直接封装成函数或工具调用即可。只有需要跨系统共享、动态发现或多人生态协作时，通过 MCP 接入才有长期价值。
Agent Skill 并不是不如 MCP，而是两者处在不同层级。Agent Skill 是构建一个“好用、可靠、懂业务”的智能体所必需的能力封装模式；MCP 是构建“开放、可连接、可复用”的智能体生态所需的基础协议。
MCP 的火爆，本质上是行业对“连接”问题的集中回应；Agent Skill 的低热，则是因为“任务质量”仍处于分散实践中。随着更多智能体走向真实业务场景，Agent Skill 的重要性会逐步凸显。最终，成熟架构不是让两者二选一，而是让 MCP 成为通向外部能力的管道，让 Agent Skill 成为沉淀业务经验的容器。