技能加上MCP：工具提供操作手段，技能则教授工作流程
MCP展示各项功能；技能包则提供工作流程与规范，让智能体清楚该按何种顺序调用哪些工具，以及何时需要寻求批准。
注意：此处提出的“技能优于MCP”理念仍处于试验阶段且仍在发展之中。其目的是探索发展方向，而非确立最终的MCP标准。
MCP使得智能体能够通过统一的协议访问外部系统，而无需为每个智能体单独进行集成。仅有功能并不足以保证效果：仅仅能够使用某工具并不意味着就能很好地运用它。技能正好弥补了这一缺陷。那些仅满足于“部署了MCP服务器”的团队，往往会发现他们的智能体虽然能够调用各种功能，但在压力之下仍会做出错误选择。
MCP为智能体赋予能力
应将MCP视为连接层。服务器可以提供诸如create_customer、get_order、send_email、create_invoice和search_documents之类的工具。智能体则通过统一的架构来发现并调用这些工具。
即使给一个智能体五十种工具，它仍需决定该调用哪些工具、按什么顺序调用、首先收集哪些信息、在API出错时如何应对、何时寻求人工帮助以及什么该拒绝。MCP提供的是功能能力，而操作知识则需由其他东西来提供。没有这些知识，工具列表就如同彩票——有时正确，常常浪费资源，偶尔还会造成危害。
这就是Skills发挥作用的地方
Skill将可重复使用的指令、上下文和工作流程打包在一起，从而使智能体能够完成具体任务。它不仅仅用于暴露：
create_invoice
send_email
get_customer
可以定义诸如处理客户账单这样的技能，其执行流程包括：查找客户、检查账单状态、验证金额、生成发票、请求审批、发送发票以及确认接收。MCP工具负责执行具体操作，而该技能则负责为这些操作提供逻辑顺序与决策依据。此外，该技能还能记录失败处理方案：遇到409状态码时应如何操作、何时需要升级处理，以及哪些字段具有权威性。
Skill与MCP结合使用比单独使用更强大
MCP代表智能体能够执行的功能，而Skill则指其执行方式。随着可用工具数量的增加，这种区分愈发重要。企业级智能体可能需要接入CRM、Stripe、GitHub、Slack、Drive、内部API以及各类数据库，MCP能够统一呈现所有这些功能。然而数百种独立的工具往往会导致选择过载，反而影响工作效率。Skill则通过将决策范围限定在特定任务所需的工具组合内，并在底层仍使用标准化的工具调用方式，来解决这一问题。
工具激增带来的问题
一台服务器上配备一百种工具，就已经让模型负担了大量的描述、参数和关联信息。若使用五台服务器，则这些数据量会进一步增加。难道每一步都需要加载所有功能吗？通常并非如此。应当在适当的时间使用合适的功能。技能系统负责优化这种选择：不是“这里有五百种工具——自行想办法”，而是“这是任务，以下是所需的功能及操作指南”。当无关的工具在技能将其调用之前保持离线状态时，上下文窗口和注意力机制都能从中受益。
技能系统还能实现约束编码
某个工具的简介可能会写“创建退款”。而某种技能在触发退款功能之前，可能需要先验证订单、查阅政策、确认金额，并在超过特定阈值时寻求批准。这些步骤对于可能产生的副作用至关重要：删除操作、退款处理、邮件发送、生产环境变更、部署操作以及账户修改等。没有规则约束的访问是不完整的，防护机制应当与工作流程一同存在，而非仅存在于模型永远无法查看的遥远政策文档中。
MCP与Skills并非竞争对手
更合理的组合是Skills + MCP，而非Skills与MCP之间的对立关系。二者处于不同的层级：
Agent
↓
Skill
↓
MCP
↓
Tools / APIs / Systems
Skill负责描述工作流程，MCP则标准化接口，实际操作由底层系统完成。随着生态系统的成熟，这一架构仍在发展之中，值得持续关注。那些将二者视为非此即彼的争论其实忽视了它们之间的互补性。
更大的变革
智能体调用 API 并非新鲜事。目前的趋势是向动态发现及面向目标的组合方式转变。MCP 解决的是连接性问题，而 Skills 则解决执行问题。随着智能体规模的扩大，教导它们何时、为何以及如何使用工具，其重要性不亚于增加更多端点。仅有连接性而无执行知识会导致错误的决策；仅有执行知识而没有连接性则无法接入实际系统。
实践中的构建方法
自研的技术栈仍然需要处理身份认证、托管服务、测试、监控、版本控制、使用情况追踪以及协议更新等问题。而那些能够将 OpenAPI 规范转化为包含工具、资源、提示语和技能的 MCP 服务器，并提供分析功能及注册列表的管理平台，可以承担这些繁琐的工作，让产品团队能够专注于智能体的行为实现。无论采用何种托管方式，这一理念始终成立：MCP 为智能体提供操作能力；技能则教会它们如何运用这些能力。可以先将一种高风险的工作流技能与一小套工具结合使用，统计错误工具的使用率，然后再有计划地扩大覆盖范围。
选择技能而非单纯工具集的团队入门检查清单
- 列出所有 MCP 工具，并标注其副作用风险等级（读取、写入、资金相关、不可逆等）。
- 在公开全部工具目录之前，先为最常用的支持或计费工作流编写一个技能。
这些措施能够在最终标准确定之前，确保实验性技能层的可靠性。