天才娜娜ln最近很多人在搜“扣子创建skill”，也有不少朋友在社群里问我，扣子里的技能（Skill）和插件、工作流到底是不是一回事？为什么我照着教程建了技能，智能体却怎么都不调用？这些问题其实都指向同一个核心：你对Skill的理解还停留在“填个表单”的层面。
我在扣子上试了很多次，踩了不少坑之后，逐渐摸清了Skill的定位、边界和正确的打开方式。这篇就结合我自己的实际操作，把创建Skill的完整流程、脚本写法和那些文档里不会明说的经验一次讲清楚。不管你是刚接触扣子的小白，还是已经建过几个工作流的老玩家，这篇都能帮你少走弯路。
1. 先分清一个事：扣子里的Skill到底是什么
先说结论：Skill在扣子里是一个“可以被智能体按需调用的能力单元”，它本质上就是一套“触发条件 + 调用协议 + 返回结果”的组合。很多人在这一步就绕晕了，因为扣子同时还有“插件”和“工作流”两个相似概念，三者的边界一旦模糊，后面全乱套。
1.1 从“技能和插件到底啥区别”说起
我在各个技术群里看到最多的提问就是“Skill和Plugin有什么区别”。这俩在早期确实很像——都是给智能体加工具。但实际用下来，你会发现它们侧重点完全不同。
插件更像一个“封装好的现成工具箱”，比如扣子插件商店里的搜索插件、图片识别插件，你装上去就能用，内部逻辑是黑盒，你不太需要关心它怎么实现。而Skill更像是“你自己定义的一套API契约”，你告诉智能体：当用户想查快递时，去请求这个快递查询接口，把返回的数据解析成用户能看懂的话。你可以完全控制接口地址、参数格式、返回结构，甚至可以在中间加一段脚本做数据清洗。
所以我的理解是：插件是别人做好给你用的，Skill是你自己定义给智能体用的。技能可以引用插件，但插件的核心能力不是让你自定义协议。
1.2 Skill和Workflow：一个偏单点动作，一个偏流程编排
另一个高频误区是拿Skill和工作流对比。经常有人说“我直接用工作流不就行了，创建的技能好像也就是个工作流”。
这句话对了一半。工作流的核心是“多步骤串联”，比如“先获取用户输入的网址 -> 抓取正文 -> 用大模型总结 -> 输出摘要”，这是流程编排。而Skill的核心是“一个可以被自然语言触发的外部能力”，它通常对应一个相对独立的动作，比如“查天气”“算税费”“发邮件”。
但两者确实有交集：你可以把工作流整个打包成一个技能暴露给智能体。这也是扣子平台非常实用的一个玩法——先在工作流里把所有逻辑编排好，再把工作流“技能化”，让智能体在对话中自动调用。反过来，Skill内部也可以不直接写API，而是指向一个工作流。所以你可以理解为：Skill是“接口”，工作流是“实现”，两者不是对立关系，而是层次关系。
1.3 Agent Skill和MCP的区别，一句话说清
热搜里还有一条特别扎眼：“agent skill和mcp有什么区别”。这个也确实值得单独讲讲。
MCP（Model Context Protocol）是一个标准化的“模型-工具通信协议”，它解决的是“大模型如何统一地发现和调用各种工具”的问题。而Agent Skill更偏“一种可复用的能力描述单元”，它包含了工具的调用方式、参数说明、使用场景描述等。
放到扣子场景里，你可以这么理解：扣子原生的Skill创建方式，本质上是让智能体通过一套“OpenAPI风格”的协议定义来理解你的工具，这很像MCP的思路；但Agent Skill往往还包含“在什么场景下用、怎么用更好”的语义信息，而不仅仅是接口定义。实际开发中，两者不是非此即彼，很多平台正在互相借鉴融合。你在扣子创建技能时，只需要记住一条：你写的描述越清楚，智能体才越知道什么时候调用它。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 创建一个真实Skill的全流程：以“查快递”为例
说再多概念都不如动手建一个。我这边用一个最典型的例子来走一遍全流程——创建一个“查快递”技能。选这个例子是因为它的逻辑足够清晰：用户提供快递单号，智能体调快递查询API，返回物流轨迹。
2.1 先想清楚这个Skill要解决什么
创建任何技能之前，第一件事不是打开控制台，而是先在纸上写清楚两件事：输入是什么，输出是什么。
我的输入是“快递单号”，输出是“快递公司 + 物流轨迹列表”。如果你使用的快递查询API需要“快递公司编码 + 快递单号”才能查