凌晨一点多点我正准备关电脑结果群里先炸了——扣子2.0发布了。我翻了一圈讨论发现大家反应最激烈的不是模型能力又涨了多少而是Skills这个功能的门槛变化。老实说这个反应一点不夸张。过去你想让一个AI智能体学会一项别人没做过的新能力得写代码、调接口、整理OpenAPI规范、处理鉴权这一整套流程跑下来基本就把普通人三个字劝退了。而这次更新的核心动作恰好是把写代码才能做应用这件事压成了说清楚需求就能做应用。这篇文章就围绕扣子2.0的Skills聊聊门槛到底降在哪、普通人怎么上手搓出第一个Skill、以及怎么把几个Skill拼成一个能真正干活的超级应用。1. 深夜更新的扣子2.0Skills这一步棋为什么让那么多人坐不住1.1 先对个暗号到底什么是Skill很多刚接触AI智能体的朋友一听到Skills这个词就默认它是某个编程概念其实没那么玄乎。如果把一个Agent比作一个厨师那模型本身是大脑负责看菜谱、做决策而Skill就是案板上的一把刀、一口锅、一个烤箱。没有这些工具厨师再聪明也只能对着食材干讲做法做不出一道真菜。落到技术层面一个Skill就是一个被封装好的、可被Agent调用的能力单元。它可能是一个纯函数、一次外部API请求、一段固定的处理流程甚至是一个已经配好的子工作流。关键在于Agent本身并不会天生知道怎么调用它而是通过Skill携带的描述信息来判断什么情况下该用我、该往里面填什么参数。这解释了为什么Skills在扣子2.0里被单独拎出来重点讲它本质上决定了智能体到底有没有手脚。以前大家做的很多智能体看着能对答如流但一遇到要查实时数据、算具体数字、操作第三方服务就哑火了根源就是手脚太少、太钝。而这次更新把给智能体装手脚的流程简化了自然就成了整个发布里含金量最高的部分。1.2 这次更新真正动刀的地方我认真对比了旧版本的插件/技能开发方式和2.0流出的Skill创建入口发现核心变化其实就三处。第一处创建方式从写代码变成了写需求。旧时代的做法是你先写好一个插件的OpenAPI描述文件告诉平台我有哪些接口、每个接口接收什么参数、返回什么结构然后还要自己实现接口背后的逻辑。现在变成你直接用大白话描述我需要一个技能它能根据我给的股票代码返回最近五天的收盘价平台帮你把参数骨架、函数雏形、描述模板一次性生成出来你要做的只是把真正干活的部分补上。第二处参数配置从给字段名变成了给含义。说白了普通人写参数时最怕的不是不知道有这个字段而是不知道字段名怎么写、类型是string还是number、要不要required。2.0的编辑界面把这些都变成了可视化选项并在旁边给了贴近业务的提示比如这个参数是给模型看的请写清楚它代表什么。第三处也是我最看重的一处对描述质量的引导变强了。因为Agent完全靠描述来决定什么时候调用Skill所以一段写得好不好的描述直接影响Skill的命中率。新版本里无论创建还是编辑Skill都会把触发说明放在显眼位置等于官方也意识到了门槛降低之后真正难的不再是写功能而是让功能被正确使用。用一张表来对比会非常直观对比项旧插件/技能方式2.0 Skill方式创建入口需写OpenAPI代码自然语言描述可视化配置参数定义手写JSON Schema界面录入自动生成鉴权处理自己写Token逻辑提供标准化接入位测试调试自己造数据发请求内置测试面板直接跑目标用户有编程经验的开发者懂业务但不会写码的人门槛确实是被打下来了但我要先泼一盆冷水门槛降低不等于不需要动脑。以前动手现在动嘴而把需求说清楚这件事本来就是很多项目的隐形难点。2. 门槛究竟降在哪从写代码的插件到说需求就能建的Skill2.1 旧时代的插件开发流程为什么能劝退一堆人为了讲清楚这次改变的价值我得先带着大家走一遍旧流程你就知道过去一个普通人要做插件得经历多少磨难。第一步先得确定功能边界——你想让智能体多出哪只手。这个还算简单。第二步就卡人了你要把接口描述写成一份标准的OpenAPI/YAML文档。字段名不能错、缩进不能乱、type要写对稍微有一个地方不对导入直接失败。紧接着第三步你要么自己写一段后端代码挂在服务器上要么找一个现成的第三方API还得处理Token、签名、密钥。第四步参数映射。前端用户输入是一套叫法接口要的又是另一套叫法你要做一层转换。第五步发布测试。如果返回结果结构不对整个Skill在Agent手里就像坏掉的手不报错也不干活你只能一遍遍猜。我见过一位做产品运营的朋友明明业务思路特别清楚想做一个根据商品链接提取优惠信息的能力结果死在了YAML校验上三天没跑通最后放弃。回头复盘他缺的根本不是业务理解而是几个技术语法细节。这就是旧流程最残忍的地方它用技术细节筛人而不是用思路筛人。2.2 2.0时代的Skill创建流程到底是怎样的新版流程在我看来相当于把过去那个劝退漏斗的每一层都加宽了。操作路径大概是进入Skill创建页先写一句功能描述比如输入一个商品链接提取该商品的标题、价格、优惠券信息和库存状态。平台会根据这句话生成一个基础的参数框架你在这个框架上做微调定义输入字段链接地址、输出字段标题、价格等。接着选择实现方式如果不会写代码可以用可视化节点来组装或者直接填一个现成API的请求地址和鉴权方式如果会写代码也可以选择代码函数模式平台给一段带着TODO注释的模板。最后进入测试面板输入测试数据看返回。通过之后发布把Skill挂到你的Agent上。整个过程中最值得玩味的是平台自动生成参数框架这一步。它本质上是一种脚手架思想先根据你的自然语言描述猜测这个功能大概需要哪些输入输出再让你改。哪怕猜得只有七成准普通人也只需要做选择题而不是做填空题。这套思路很像从手工造车变成给你底盘和发动机、让你装座椅——你不用发明只需要理解和组装。2.3 关键点Skill的好坏取决于描述而不是代码我做了这么久的智能体项目有句话想放在最前面在Skills体系里代码只是实现描述才是灵魂。因为Agent不会看你的代码逻辑它只读你的描述然后决定这个需求该不该叫这个Skill来处理。一段烂描述长什么样这是一个用于处理文本的技能。——等于没说。Agent根本不知道它能处理什么文本、什么场景该叫它、参数要怎么填。一段好描述长什么样当用户要求总结一篇英文技术文章或者需要把中文内容翻译成英文时调用此技能。输入参数为待处理文本回复时请保留原文中的专有名词。——这样Agent就能在遇到具体场景时精准地把它捞出来。一个Skill的描述应该包含三样东西触发条件什么场景下被调用、输入说明每个参数的含义和格式、输出说明返回内容长什么样。2.0里给出的编辑引导也基本围绕这三样展开。我建议大家把写描述当成写给一个没见过面的同事的工作交接说明越具体越好宁可啰嗦不要模糊。为了让大家有个直观印象我给一个典型的Skill参数结构示例{ skill_name: article_summarizer, description: 当用户提供一个网页链接或一段长文本并要求生成摘要、提炼要点或快速了解内容时使用。, input: { text: { type: string, description: 需要总结的原文内容或网页URL, required: true }, max_points: { type: integer, description: 希望提炼几个要点默认5个, required: false } }, output: { summary: string一段150字以内的中文摘要, key_points: array要点列表 } }注意看框里没有一行怎么实现的代码逻辑但对Agent来说这些信息已经足够了。3. 普通人手搓第一个Skill一次完整的上手实录3.1 选一个不太大也不太小的第一个目标很多第一次上手的人最容易犯的错是目标定得太宏伟上来就想做一个全能AI管家。真要这么干你会在配置了七八个技能、互相纠缠不清之后彻底失去耐心。我的建议是第一个Skill选一个具体、高频、输入输出清楚的小任务。比如根据关键词返回近三天的科技新闻标题列表或者输入一段中文把它改写得更口语化并给出理由。这类任务有几个共性你清楚知道输入是什么也清楚知道期望的输出长什么样即使平台生成的脚手架不完全对你也有能力手动修正—因为业务逻辑本身不复杂。如果实在不知道选什么有一个百试百灵的选题方法回想一下你最近一周有哪件小破事是反复让AI帮你做的。让它解释某个概念让它写一段小红书文案让它算一笔账把这些事挑一件就是你的第一个Skill。3.2 在控制台里一步步建Skill实测操作路径我按自己实际操作的顺序把步骤和容易忽略的细节整理如下。这里不涉及具体界面截图因为平台更新很快但逻辑基本不变。第一步新建Skill起一个动词开头的名字。比如查询天气生成海报文案翻译术语表。名字的作用是给Agent一个快速理解你功能范围的锚点动词对象的结构最不容易产生歧义。第二步用自然语言写功能描述。这里不要写得像广告词而是要像给API写注释。比如本技能接收城市名和日期返回该城市当天的天气状况、气温区间和降水概率数据来源为第三方天气服务。一个朴实但准确的描述比一句智能天气助手出行必备有用得多。第三步调整参数。平台根据描述给出一组参数猜测你逐一看过去把类型选对、把是否必填标对、把字段说明写清楚。这里有个技巧给Agent看的字段说明里尽量包含格式示例。比如日期格式为YYYY-MM-DD如2025-03-18。因为Agent帮用户填参数时如果不知道格式要求很容易填出明天或3月18号这样的模糊值。第四步选择实现方式。能调现成API就调API填上请求地址、请求方式和鉴权信息没有现成API就写函数或者用可视化节点拼几步逻辑。第一次做强烈建议优先选平台提供的模板或别人做好的公开能力列表先跑通再说深度定制。第五步填好给Agent的调用说明。这就是2.0特别强调的触发描述内容是什么需求下调用我、调用时需要注意什么。比如天气查询的说明可以写当用户询问某地今天/明天/未来几天的天气时调用。若用户只给了城市没给日期默认查今天。第六步进测试面板用真实用例跑三遍。第一遍用一个标准的、完整的输入第二遍用一个缺参数的输入看它会不会报错提示第三遍用一个明显超出业务范围的输入比如天气Skill被问到明天股市涨不涨看它能不能正确拒绝。第七步发布并绑定到Agent。发布之后你需要在Agent的设置里把这个Skill勾选启用。有同学在这里栽过跟头Skill建好了但没往Agent上挂结果对话里怎么调都不生效误以为是平台Bug。3.3 第一次测试最容易翻车的三个地方实测中翻车点其实很集中我先列出来你们遇到时心里有数。第一参数命名和顺序问题。平台自动生成的参数名有时会带中文或空格某些实现方式下容易出现解析异常。处理办法很简单参数名统一用英文字母加下划线如city_name、query_date避免用中文或短横线。第二返回结构没按约定来。Skill的输出会交给Agent进行二次加工如果你的返回内容和你在输出说明里写的不一致Agent就会一脸茫然。解决办法是测试之后回头把输出说明和实际返回统一起来。第三时间和时区问题。问天气的、问航班状态的、问营业时间的全都逃不开时区。如果你的Skill内部调用的是UTC时间戳但用户问的是北京时间不转换就直接报。这里建议所有和日期时间相关的字段在参数说明里明确标注时区。4. 把三五个Skill拼成超级应用编排思路与架构取舍4.1 超级应用的真相不是一个大机器人而是一组小能力的组合很多人提到超级应用总觉得是一个包罗万象的巨型机器人什么都会。实际操作过就会明白真正能落地的好应用都是一个小脑瓜子带着一群小工具。你自己定制的那部分智能体就是小脑瓜子你一个个建出来的Skill就是那群小工具。每一个Skill只负责一件具体的事而Agent负责调度、拼装、表达。这种架构最大的好处是可维护。某个Skill出了问题你只需要单独进到那个Skill里去修不会牵一发动全身。另一个好处是可复制——你花了三天做的查快递物流Skill换到任何一个新Agent上都能复用不用重写。从这个角度看Skills其实在慢慢变成一种个人资产。4.2 三个可以照抄的组装方案光讲原理容易飘我直接给三个实际可抄的方案你们按自己的场景替换即可。方案一文章解读助手。Skill组件抓取网页正文、生成摘要、提取专有名词、检索自己的知识库。用户丢一个链接进来Agent先调抓取Skill拿到正文再调摘要Skill生成概述接着调提取Skill把关键术语抓出来最后和知识库里已有的相关内容做对比产出这篇讲什么和你之前关注的内容有什么关系的综合回答。这套方案特别适合做研究、追行业动态的人。方案二旅行规划助手。Skill组件航班搜索、酒店比价、天气查询、汇率换算、路线规划。用户说下周三从北京去上海玩三天Agent会依次查航班、查酒店、查当地天气再用汇率和路线Skill兜底生成一份带预算的行程单。注意这类方案严重依赖外部数据源的质量如果某个数据源不稳定会直接影响整体体验所以在调度层面要设置好失败退路。方案三小生意经营助手。Skill组件记账录入收支、算利润汇总当周毛利、生成推广文案、定时出日报。这套不需要接太多外部API很多逻辑用函数就能实现非常适合做电商或小门店的人。每天到点自动把营业数据整理成日报推给你月底一键算出各产品线的利润分布这几个Skill组合起来比单纯让AI聊闲天有用得多。三个方案的共性可以总结为一张表应用方向核心Skill组成关键外部依赖适合人群文章解读抓取、摘要、术语提取、知识库网页可访问性研究者、媒体人旅行规划航班、酒店、天气、汇率、路线多个第三方数据源旅行爱好者小生意经营记账、利润、文案、定时日报数据录入规范电商、个体经营者4.3 什么时候让Agent自己编排什么时候用工作流硬编排这是我在实操中花了最多时间摸索的问题也是很多人把应用做到一半开始卡壳的根源。让Agent自己编排意思是你的Agent里挂了八个Skill它根据用户对话现场决定第一步调谁、第二步调谁需要几步。优点是极其灵活用户的说辞飘忽不定也能应对缺点是不可控心情不好时它可能跳过某些步骤。用工作流硬编排则是把固定路径写死先做A再根据A的结果判断走B还是C最后输出D。优点是稳定可靠适合业务流程固定的场景缺点是用户一旦说了计划外的话整个链路容易僵住。我的取舍标准是这样的如果整个流程超过三步且每一步之间都有强依赖下一步必须用到上一步的结果用工作流硬编排如果流程短、依赖弱、全靠临场发挥就让Agent自己编排。还有一个进阶玩法叫混合模式把包含强依赖的多步操作封装成一个Skill让Agent调用这个Skill等于把一小段固定流程重新变回一个灵活积木。这个思路是当前性价比最高的架构方式。5. 我在实测中踩过的坑Skill调用的隐藏陷阱与应对办法5.1 描述写得烂Agent就是不调用它这是所有坑里的第一名。我做过一个实验同一个Skill只改描述不改功能把描述从天气查询工具改成当用户询问某城市未来天气预报、降雨概率、穿衣建议时调用此技能查询实时天气数据并返回气温区间和降水概率参数城市名与日期必填。改完之后的调用次数翻了将近四倍。为什么差别这么大因为Agent在处理用户需求时做的本质上是意图匹配。描述给了它足够的触发信号它才敢放心用。你要是把Skill从没被调用过先别急着怀疑功能回头看看描述里有没有写出触发条件和输入格式要求。我见过太多人把大量精力花在调代码上结果问题出在描述少了一句当用户提到XX时调用。5.2 外部API不稳定Skill就成了定时炸弹任何一个接了第三方API的Skill都等于把命运交到了外部服务手里。我在实测中就遇到过某个查快递的接口平时好好的一到晚上高峰期就超时另一个查汇率的数据源偶尔会返回格式异常的字段。应对办法我总结成四条。第一Skill内部一定要做超时处理宁可返回暂时查不到也不让用户无限等待。第二对关键返回字段做防御性校验字段缺失时给出降级回答而不是裸露报错。第三尽量给每个外部数据源配一个备用源主源挂了自动切备用。第四在Agent的对话设置里给Skill调用失败预设兜底话术别让用户看到冰冷的报错原文。你可能觉得这些细节很琐碎但用户评价一个应用靠不靠谱往往就取决于这种边缘情况的处理。5.3 参数从人输入变成Agent自己填之后问题全暴露了这是Skill体系特有的坑写代码时根本遇不到。传统程序里参数是人填的人自然知道日期要按YYYY-MM-DD写。但Skill是Agent替人填参数它会把明天下周一最近三天这类模糊口语直接塞进字段里如果你的字段说明里没写格式示例它就会自由发挥。解决办法是在参数说明里尽可能给出示例约束兜底规则。比如date查询日期格式YYYY-MM-DD若用户未提供具体日期默认使用今天用户说明天时请先换算成具体日期再填入。这句话看着是写给字段的其实是写给Agent看的操作说明书。参数描述写得好Agent填参数的准确率会肉眼可见地提升。5.4 密钥、费用和日志别等问题发生了才去管Skills第一次把外部API接入这件事普及到了普通人面前但也带来一个隐患很多人不知道密钥应该存在哪、调用它是要花钱的、失败时是完全没有日志可查的。我的习惯是Skill里涉及外部API的密钥一律放进平台提供的环境变量或密钥管理位绝不从代码里直接读取更不要随手写在描述里。费用控制方面凡是调用收费API的Skill都设置调用上限和告警阈值。日志方面尽量给每个Skill开启调用记录出问题的时候能回看Agent到底传了什么参数、API回了什么结果。这些事一开始就配好以后能省大量排查时间。6. 说点掏心窝的话Skills降门槛之后普通人真正要拼的是什么我自己比较确信的一点是Skills门槛降下来以后这个赛道的竞争重点已经从会不会写代码转移到了能不能把需求想清楚、把边界划明白、把质量兜住。这其实是普通人的机会因为这三件事更考验的是你对你所在领域的理解而不是编程技巧。如果你是个懂业务但不会代码的人我的建议非常直接先花一个晚上从身边最重复的那件小事里挑一个做你的第一个Skill然后把它挂到一个测试Agent上连续用三天记录它在哪里表现好、在哪里犯蠢接着围绕它增加第二个、第三个Skill最后再考虑用工作流把固定路径固化下来。这个过程不需要你一次性搞懂所有概念只需要你不停地在定义能力—试用—发现失败—修正这个循环里打转。最后分享一个小技巧给Skill命名和写描述时尽量保持动词业务对象的格式并且把版本号标进备注里。过一两周你就会发现Skills真正值钱的地方不在于单个功能而在于你积累的这套能力库能随着使用不断迭代、跨Agent复用。工具的门槛降下来了剩下的比拼就看你愿不愿意持续打磨了。 
长河君 · 2026/10/19 3:17:55 · 阅读 1.2k 扣子2.0 Skills实测：普通人零代码搭建AI智能体技能全攻略
凌晨一点多点我正准备关电脑结果群里先炸了——扣子2.0发布了。我翻了一圈讨论发现大家反应最激烈的不是模型能力又涨了多少而是Skills这个功能的门槛变化。老实说这个反应一点不夸张。过去你想让一个AI智能体学会一项别人没做过的新能力得写代码、调接口、整理OpenAPI规范、处理鉴权这一整套流程跑下来基本就把普通人三个字劝退了。而这次更新的核心动作恰好是把写代码才能做应用这件事压成了说清楚需求就能做应用。这篇文章就围绕扣子2.0的Skills聊聊门槛到底降在哪、普通人怎么上手搓出第一个Skill、以及怎么把几个Skill拼成一个能真正干活的超级应用。1. 深夜更新的扣子2.0Skills这一步棋为什么让那么多人坐不住1.1 先对个暗号到底什么是Skill很多刚接触AI智能体的朋友一听到Skills这个词就默认它是某个编程概念其实没那么玄乎。如果把一个Agent比作一个厨师那模型本身是大脑负责看菜谱、做决策而Skill就是案板上的一把刀、一口锅、一个烤箱。没有这些工具厨师再聪明也只能对着食材干讲做法做不出一道真菜。落到技术层面一个Skill就是一个被封装好的、可被Agent调用的能力单元。它可能是一个纯函数、一次外部API请求、一段固定的处理流程甚至是一个已经配好的子工作流。关键在于Agent本身并不会天生知道怎么调用它而是通过Skill携带的描述信息来判断什么情况下该用我、该往里面填什么参数。这解释了为什么Skills在扣子2.0里被单独拎出来重点讲它本质上决定了智能体到底有没有手脚。以前大家做的很多智能体看着能对答如流但一遇到要查实时数据、算具体数字、操作第三方服务就哑火了根源就是手脚太少、太钝。而这次更新把给智能体装手脚的流程简化了自然就成了整个发布里含金量最高的部分。1.2 这次更新真正动刀的地方我认真对比了旧版本的插件/技能开发方式和2.0流出的Skill创建入口发现核心变化其实就三处。第一处创建方式从写代码变成了写需求。旧时代的做法是你先写好一个插件的OpenAPI描述文件告诉平台我有哪些接口、每个接口接收什么参数、返回什么结构然后还要自己实现接口背后的逻辑。现在变成你直接用大白话描述我需要一个技能它能根据我给的股票代码返回最近五天的收盘价平台帮你把参数骨架、函数雏形、描述模板一次性生成出来你要做的只是把真正干活的部分补上。第二处参数配置从给字段名变成了给含义。说白了普通人写参数时最怕的不是不知道有这个字段而是不知道字段名怎么写、类型是string还是number、要不要required。2.0的编辑界面把这些都变成了可视化选项并在旁边给了贴近业务的提示比如这个参数是给模型看的请写清楚它代表什么。第三处也是我最看重的一处对描述质量的引导变强了。因为Agent完全靠描述来决定什么时候调用Skill所以一段写得好不好的描述直接影响Skill的命中率。新版本里无论创建还是编辑Skill都会把触发说明放在显眼位置等于官方也意识到了门槛降低之后真正难的不再是写功能而是让功能被正确使用。用一张表来对比会非常直观对比项旧插件/技能方式2.0 Skill方式创建入口需写OpenAPI代码自然语言描述可视化配置参数定义手写JSON Schema界面录入自动生成鉴权处理自己写Token逻辑提供标准化接入位测试调试自己造数据发请求内置测试面板直接跑目标用户有编程经验的开发者懂业务但不会写码的人门槛确实是被打下来了但我要先泼一盆冷水门槛降低不等于不需要动脑。以前动手现在动嘴而把需求说清楚这件事本来就是很多项目的隐形难点。2. 门槛究竟降在哪从写代码的插件到说需求就能建的Skill2.1 旧时代的插件开发流程为什么能劝退一堆人为了讲清楚这次改变的价值我得先带着大家走一遍旧流程你就知道过去一个普通人要做插件得经历多少磨难。第一步先得确定功能边界——你想让智能体多出哪只手。这个还算简单。第二步就卡人了你要把接口描述写成一份标准的OpenAPI/YAML文档。字段名不能错、缩进不能乱、type要写对稍微有一个地方不对导入直接失败。紧接着第三步你要么自己写一段后端代码挂在服务器上要么找一个现成的第三方API还得处理Token、签名、密钥。第四步参数映射。前端用户输入是一套叫法接口要的又是另一套叫法你要做一层转换。第五步发布测试。如果返回结果结构不对整个Skill在Agent手里就像坏掉的手不报错也不干活你只能一遍遍猜。我见过一位做产品运营的朋友明明业务思路特别清楚想做一个根据商品链接提取优惠信息的能力结果死在了YAML校验上三天没跑通最后放弃。回头复盘他缺的根本不是业务理解而是几个技术语法细节。这就是旧流程最残忍的地方它用技术细节筛人而不是用思路筛人。2.2 2.0时代的Skill创建流程到底是怎样的新版流程在我看来相当于把过去那个劝退漏斗的每一层都加宽了。操作路径大概是进入Skill创建页先写一句功能描述比如输入一个商品链接提取该商品的标题、价格、优惠券信息和库存状态。平台会根据这句话生成一个基础的参数框架你在这个框架上做微调定义输入字段链接地址、输出字段标题、价格等。接着选择实现方式如果不会写代码可以用可视化节点来组装或者直接填一个现成API的请求地址和鉴权方式如果会写代码也可以选择代码函数模式平台给一段带着TODO注释的模板。最后进入测试面板输入测试数据看返回。通过之后发布把Skill挂到你的Agent上。整个过程中最值得玩味的是平台自动生成参数框架这一步。它本质上是一种脚手架思想先根据你的自然语言描述猜测这个功能大概需要哪些输入输出再让你改。哪怕猜得只有七成准普通人也只需要做选择题而不是做填空题。这套思路很像从手工造车变成给你底盘和发动机、让你装座椅——你不用发明只需要理解和组装。2.3 关键点Skill的好坏取决于描述而不是代码我做了这么久的智能体项目有句话想放在最前面在Skills体系里代码只是实现描述才是灵魂。因为Agent不会看你的代码逻辑它只读你的描述然后决定这个需求该不该叫这个Skill来处理。一段烂描述长什么样这是一个用于处理文本的技能。——等于没说。Agent根本不知道它能处理什么文本、什么场景该叫它、参数要怎么填。一段好描述长什么样当用户要求总结一篇英文技术文章或者需要把中文内容翻译成英文时调用此技能。输入参数为待处理文本回复时请保留原文中的专有名词。——这样Agent就能在遇到具体场景时精准地把它捞出来。一个Skill的描述应该包含三样东西触发条件什么场景下被调用、输入说明每个参数的含义和格式、输出说明返回内容长什么样。2.0里给出的编辑引导也基本围绕这三样展开。我建议大家把写描述当成写给一个没见过面的同事的工作交接说明越具体越好宁可啰嗦不要模糊。为了让大家有个直观印象我给一个典型的Skill参数结构示例{ skill_name: article_summarizer, description: 当用户提供一个网页链接或一段长文本并要求生成摘要、提炼要点或快速了解内容时使用。, input: { text: { type: string, description: 需要总结的原文内容或网页URL, required: true }, max_points: { type: integer, description: 希望提炼几个要点默认5个, required: false } }, output: { summary: string一段150字以内的中文摘要, key_points: array要点列表 } }注意看框里没有一行怎么实现的代码逻辑但对Agent来说这些信息已经足够了。3. 普通人手搓第一个Skill一次完整的上手实录3.1 选一个不太大也不太小的第一个目标很多第一次上手的人最容易犯的错是目标定得太宏伟上来就想做一个全能AI管家。真要这么干你会在配置了七八个技能、互相纠缠不清之后彻底失去耐心。我的建议是第一个Skill选一个具体、高频、输入输出清楚的小任务。比如根据关键词返回近三天的科技新闻标题列表或者输入一段中文把它改写得更口语化并给出理由。这类任务有几个共性你清楚知道输入是什么也清楚知道期望的输出长什么样即使平台生成的脚手架不完全对你也有能力手动修正—因为业务逻辑本身不复杂。如果实在不知道选什么有一个百试百灵的选题方法回想一下你最近一周有哪件小破事是反复让AI帮你做的。让它解释某个概念让它写一段小红书文案让它算一笔账把这些事挑一件就是你的第一个Skill。3.2 在控制台里一步步建Skill实测操作路径我按自己实际操作的顺序把步骤和容易忽略的细节整理如下。这里不涉及具体界面截图因为平台更新很快但逻辑基本不变。第一步新建Skill起一个动词开头的名字。比如查询天气生成海报文案翻译术语表。名字的作用是给Agent一个快速理解你功能范围的锚点动词对象的结构最不容易产生歧义。第二步用自然语言写功能描述。这里不要写得像广告词而是要像给API写注释。比如本技能接收城市名和日期返回该城市当天的天气状况、气温区间和降水概率数据来源为第三方天气服务。一个朴实但准确的描述比一句智能天气助手出行必备有用得多。第三步调整参数。平台根据描述给出一组参数猜测你逐一看过去把类型选对、把是否必填标对、把字段说明写清楚。这里有个技巧给Agent看的字段说明里尽量包含格式示例。比如日期格式为YYYY-MM-DD如2025-03-18。因为Agent帮用户填参数时如果不知道格式要求很容易填出明天或3月18号这样的模糊值。第四步选择实现方式。能调现成API就调API填上请求地址、请求方式和鉴权信息没有现成API就写函数或者用可视化节点拼几步逻辑。第一次做强烈建议优先选平台提供的模板或别人做好的公开能力列表先跑通再说深度定制。第五步填好给Agent的调用说明。这就是2.0特别强调的触发描述内容是什么需求下调用我、调用时需要注意什么。比如天气查询的说明可以写当用户询问某地今天/明天/未来几天的天气时调用。若用户只给了城市没给日期默认查今天。第六步进测试面板用真实用例跑三遍。第一遍用一个标准的、完整的输入第二遍用一个缺参数的输入看它会不会报错提示第三遍用一个明显超出业务范围的输入比如天气Skill被问到明天股市涨不涨看它能不能正确拒绝。第七步发布并绑定到Agent。发布之后你需要在Agent的设置里把这个Skill勾选启用。有同学在这里栽过跟头Skill建好了但没往Agent上挂结果对话里怎么调都不生效误以为是平台Bug。3.3 第一次测试最容易翻车的三个地方实测中翻车点其实很集中我先列出来你们遇到时心里有数。第一参数命名和顺序问题。平台自动生成的参数名有时会带中文或空格某些实现方式下容易出现解析异常。处理办法很简单参数名统一用英文字母加下划线如city_name、query_date避免用中文或短横线。第二返回结构没按约定来。Skill的输出会交给Agent进行二次加工如果你的返回内容和你在输出说明里写的不一致Agent就会一脸茫然。解决办法是测试之后回头把输出说明和实际返回统一起来。第三时间和时区问题。问天气的、问航班状态的、问营业时间的全都逃不开时区。如果你的Skill内部调用的是UTC时间戳但用户问的是北京时间不转换就直接报。这里建议所有和日期时间相关的字段在参数说明里明确标注时区。4. 把三五个Skill拼成超级应用编排思路与架构取舍4.1 超级应用的真相不是一个大机器人而是一组小能力的组合很多人提到超级应用总觉得是一个包罗万象的巨型机器人什么都会。实际操作过就会明白真正能落地的好应用都是一个小脑瓜子带着一群小工具。你自己定制的那部分智能体就是小脑瓜子你一个个建出来的Skill就是那群小工具。每一个Skill只负责一件具体的事而Agent负责调度、拼装、表达。这种架构最大的好处是可维护。某个Skill出了问题你只需要单独进到那个Skill里去修不会牵一发动全身。另一个好处是可复制——你花了三天做的查快递物流Skill换到任何一个新Agent上都能复用不用重写。从这个角度看Skills其实在慢慢变成一种个人资产。4.2 三个可以照抄的组装方案光讲原理容易飘我直接给三个实际可抄的方案你们按自己的场景替换即可。方案一文章解读助手。Skill组件抓取网页正文、生成摘要、提取专有名词、检索自己的知识库。用户丢一个链接进来Agent先调抓取Skill拿到正文再调摘要Skill生成概述接着调提取Skill把关键术语抓出来最后和知识库里已有的相关内容做对比产出这篇讲什么和你之前关注的内容有什么关系的综合回答。这套方案特别适合做研究、追行业动态的人。方案二旅行规划助手。Skill组件航班搜索、酒店比价、天气查询、汇率换算、路线规划。用户说下周三从北京去上海玩三天Agent会依次查航班、查酒店、查当地天气再用汇率和路线Skill兜底生成一份带预算的行程单。注意这类方案严重依赖外部数据源的质量如果某个数据源不稳定会直接影响整体体验所以在调度层面要设置好失败退路。方案三小生意经营助手。Skill组件记账录入收支、算利润汇总当周毛利、生成推广文案、定时出日报。这套不需要接太多外部API很多逻辑用函数就能实现非常适合做电商或小门店的人。每天到点自动把营业数据整理成日报推给你月底一键算出各产品线的利润分布这几个Skill组合起来比单纯让AI聊闲天有用得多。三个方案的共性可以总结为一张表应用方向核心Skill组成关键外部依赖适合人群文章解读抓取、摘要、术语提取、知识库网页可访问性研究者、媒体人旅行规划航班、酒店、天气、汇率、路线多个第三方数据源旅行爱好者小生意经营记账、利润、文案、定时日报数据录入规范电商、个体经营者4.3 什么时候让Agent自己编排什么时候用工作流硬编排这是我在实操中花了最多时间摸索的问题也是很多人把应用做到一半开始卡壳的根源。让Agent自己编排意思是你的Agent里挂了八个Skill它根据用户对话现场决定第一步调谁、第二步调谁需要几步。优点是极其灵活用户的说辞飘忽不定也能应对缺点是不可控心情不好时它可能跳过某些步骤。用工作流硬编排则是把固定路径写死先做A再根据A的结果判断走B还是C最后输出D。优点是稳定可靠适合业务流程固定的场景缺点是用户一旦说了计划外的话整个链路容易僵住。我的取舍标准是这样的如果整个流程超过三步且每一步之间都有强依赖下一步必须用到上一步的结果用工作流硬编排如果流程短、依赖弱、全靠临场发挥就让Agent自己编排。还有一个进阶玩法叫混合模式把包含强依赖的多步操作封装成一个Skill让Agent调用这个Skill等于把一小段固定流程重新变回一个灵活积木。这个思路是当前性价比最高的架构方式。5. 我在实测中踩过的坑Skill调用的隐藏陷阱与应对办法5.1 描述写得烂Agent就是不调用它这是所有坑里的第一名。我做过一个实验同一个Skill只改描述不改功能把描述从天气查询工具改成当用户询问某城市未来天气预报、降雨概率、穿衣建议时调用此技能查询实时天气数据并返回气温区间和降水概率参数城市名与日期必填。改完之后的调用次数翻了将近四倍。为什么差别这么大因为Agent在处理用户需求时做的本质上是意图匹配。描述给了它足够的触发信号它才敢放心用。你要是把Skill从没被调用过先别急着怀疑功能回头看看描述里有没有写出触发条件和输入格式要求。我见过太多人把大量精力花在调代码上结果问题出在描述少了一句当用户提到XX时调用。5.2 外部API不稳定Skill就成了定时炸弹任何一个接了第三方API的Skill都等于把命运交到了外部服务手里。我在实测中就遇到过某个查快递的接口平时好好的一到晚上高峰期就超时另一个查汇率的数据源偶尔会返回格式异常的字段。应对办法我总结成四条。第一Skill内部一定要做超时处理宁可返回暂时查不到也不让用户无限等待。第二对关键返回字段做防御性校验字段缺失时给出降级回答而不是裸露报错。第三尽量给每个外部数据源配一个备用源主源挂了自动切备用。第四在Agent的对话设置里给Skill调用失败预设兜底话术别让用户看到冰冷的报错原文。你可能觉得这些细节很琐碎但用户评价一个应用靠不靠谱往往就取决于这种边缘情况的处理。5.3 参数从人输入变成Agent自己填之后问题全暴露了这是Skill体系特有的坑写代码时根本遇不到。传统程序里参数是人填的人自然知道日期要按YYYY-MM-DD写。但Skill是Agent替人填参数它会把明天下周一最近三天这类模糊口语直接塞进字段里如果你的字段说明里没写格式示例它就会自由发挥。解决办法是在参数说明里尽可能给出示例约束兜底规则。比如date查询日期格式YYYY-MM-DD若用户未提供具体日期默认使用今天用户说明天时请先换算成具体日期再填入。这句话看着是写给字段的其实是写给Agent看的操作说明书。参数描述写得好Agent填参数的准确率会肉眼可见地提升。5.4 密钥、费用和日志别等问题发生了才去管Skills第一次把外部API接入这件事普及到了普通人面前但也带来一个隐患很多人不知道密钥应该存在哪、调用它是要花钱的、失败时是完全没有日志可查的。我的习惯是Skill里涉及外部API的密钥一律放进平台提供的环境变量或密钥管理位绝不从代码里直接读取更不要随手写在描述里。费用控制方面凡是调用收费API的Skill都设置调用上限和告警阈值。日志方面尽量给每个Skill开启调用记录出问题的时候能回看Agent到底传了什么参数、API回了什么结果。这些事一开始就配好以后能省大量排查时间。6. 说点掏心窝的话Skills降门槛之后普通人真正要拼的是什么我自己比较确信的一点是Skills门槛降下来以后这个赛道的竞争重点已经从会不会写代码转移到了能不能把需求想清楚、把边界划明白、把质量兜住。这其实是普通人的机会因为这三件事更考验的是你对你所在领域的理解而不是编程技巧。如果你是个懂业务但不会代码的人我的建议非常直接先花一个晚上从身边最重复的那件小事里挑一个做你的第一个Skill然后把它挂到一个测试Agent上连续用三天记录它在哪里表现好、在哪里犯蠢接着围绕它增加第二个、第三个Skill最后再考虑用工作流把固定路径固化下来。这个过程不需要你一次性搞懂所有概念只需要你不停地在定义能力—试用—发现失败—修正这个循环里打转。最后分享一个小技巧给Skill命名和写描述时尽量保持动词业务对象的格式并且把版本号标进备注里。过一两周你就会发现Skills真正值钱的地方不在于单个功能而在于你积累的这套能力库能随着使用不断迭代、跨Agent复用。工具的门槛降下来了剩下的比拼就看你愿不愿意持续打磨了。