直接抛个结论Skill 这个词最近在 AI 圈子里火得不像话但你要是以为它是什么高深莫测的新算法那就想多了。它其实是一套很朴素的工程思路把大模型从“只会聊天”改造成“能动手办事”。我自己从最早被这个概念绕晕到后来亲手搭出十几个可用技能中间踩了不少坑今天这篇就把 Skill 的来龙去脉、内部结构、实操方法和常见问题一次性聊透。不管你是刚接触大模型应用的新手还是已经在折腾 Agent 的老鸟这篇文章都能给你一些能直接拿去用的东西。1. 先搞清楚 Skill 解决的是什么问题1.1 大模型看起来很聪明但“缺手缺脚”我最初接触大模型时的心态其实很简单它能写文案、能总结文档、能写代码感觉无所不能。但等我真的想让它“干点正事”时第一个问题就来了——让它帮我查一下今天北京的实时天气它只能告诉我“我无法获取实时信息”让它帮我查一下订单物流它只能给出一段礼貌的道歉。这不是模型不够聪明而是它天生就少了两样东西第一没有实时获取外部信息的能力第二没有操作外部系统、执行真实动作的能力。大模型本质上是一个基于历史文本训练出来的概率模型它的知识截止于训练数据它说不出来训练之后才发生的事也没法主动去调用你手机里的 App 或公司的内部接口。这就像你雇了一个知识渊博的顾问他能给你讲清楚各种理论但真要让他去仓库搬个箱子、给客户打个电话他动不了手。大家天天喊着要让大模型“落地”落地的前提就是你得给它安上“手”和“脚”而 Skill 就是现在主流的安装方式。1.2 Skill 的完整工作链路感知、决策、执行既然大模型缺手缺脚Skill 要做的就是把外部能力补上去。一条完整的 Skill 调用链路通常包含三个环节感知接收用户输入把“帮我看看北京明天会不会下雨”这样的自然语言变成系统能识别的结构化需求。决策大模型根据用户意图和 Skill 的描述信息判断“这个请求应该调用哪个技能”并且把参数从对话里抽取出来。执行真正去调用外部 API、运行代码或者触发工作流拿到结果后再交回给模型整理成自然语言回复。我之所以说“决策”这个环节容易被忽略是因为很多人第一次搭 Skill 时把所有精力都花在“写执行代码”上结果模型根本不知道该在什么时候调用它或者把参数传得乱七八糟。实际上决策是否准确很大程度上不取决于代码多复杂而取决于你对 Skill 的名字和描述写得够不够清楚。这块后面我会重点展开。1.3 知识库和 Skill一个负责“知道”一个负责“做到”有个问题我几乎在每个新手群裡都见过知识库和 Skill 到底有什么区别这俩确实容易混因为它们都能让模型回答得更好但作用维度完全不同。知识库解决的是“模型不知道”的问题。通过检索增强生成RAG把外部文档切块、向量化、存进数据库用户提问时先搜出相关内容再塞给模型做回答。它的核心是给模型补充背景知识让回答更准确、更贴合你的业务。Skill 解决的是“模型做不到”的问题。它的目标不是让模型“说对”而是让模型“办成”。用户要查天气你给它接天气 API用户要建工单你让它调工单系统。知识库喂的是“料”Skill 给的是“手”。我之前做过一个内部知识助手一开始只挂了知识库它能流畅回答员工手册里的各种问题但一碰到“帮我提交一个请假申请”就直接卡壳。后来给助手增加了一个“提交请假单”的 Skill调用 OA 系统的接口问题才彻底闭环。简单说想让你的应用更有“行动力”就上 Skill想让你的应用“懂得更多”就上知识库。两者可以共存但别搞混。2. Skill 的结构拆解一段描述、一堆参数、一段执行逻辑2.1 元信息给模型一张“找得准”的入场券任何一个 Skill第一步都是定义它的“元信息”也就是技能的名字和描述。你可能会觉得这有什么好讲的随便起个名不就行了但模型判断“该调用哪个技能”的时候靠的就是这些文本。我举个例子。你做了一个天气查询技能如果名字叫“test123”描述写成“一个查询天气的功能”模型看到用户说“北京明天冷不冷”它可能根本就不会联想到这个技能。但如果你把名字改成“get_weather”描述写成“查询全球任意城市当前或未来数日的天气包括温度、降水、风力等信息”模型就能很自然地把它和用户的提问对上号。这里有个很实用的技巧描述写完后可以默念三遍“如果我只看到这段描述能不能判断出这个技能什么时候该用、什么时候不该用”如果拿不准就继续补充触发场景比如“当用户询问出行建议、是否需要带伞、穿衣搭配时也可以参考本技能返回的天气数据”。描述不是写给用户看的是写给模型看的这一点务必时刻记住。2.2 参数清单把自然语言翻译成代码能吃的结构化数据Skill 要执行就不能只靠一句自然语言。比如“帮我看看北京明天的天气”你需要在后台把“北京”解析成城市编码“明天”解析成具体日期然后才能去请求气象 API。Skill 里的参数定义就是给大模型一张“如何转化”的说明书。常用 JSON Schema 来定义参数结构核心字段一般包括type参数类型比如 string 字符串、integer 整数、object 对象。properties包含各字段的详细定义每个字段都需要给类型、是否必填以及关键的一句描述。required必填字段列表。enum可选值范围比如天气单位是摄氏度还是华氏度提前锁死能避免很多解析错误。我贴一个实际使用过的天气技能参数定义你感受一下{ name: get_weather, description: 查询指定城市指定日期的天气信息包括气温、天气现象、风向风速等, parameters: { type: object, properties: { city: { type: string, description: 城市名称尽量使用标准中文名例如北京、上海、广州 }, date: { type: string, description: 要查询的日期格式为 YYYY-MM-DD默认为今天 }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位默认 celsius } }, required: [city] } }注意看我在每个字段的 description 里都写了比较充分的解释。这样做的目的很简单模型决策时要看这些描述才能从对话里准确地抽出参数。假如描述写得太简略比如只写“城市名”模型遇到“去上海出差那天怎么样”这种口语化提问时很有可能抽取失败。2.3 执行逻辑里面到底跑的是什么Skill 的“执行逻辑”最常见的三种形式我一个个说。第一种直接调外部 API。这是最典型的方式。比如查天气、查汇率、发短信、创建订单本质上都是给某个 HTTP 接口发请求接收返回值。Skill 里面存的是接口地址、请求方法、请求头、参数映射规则以及如何把返回结果的 JSON 转成用户能看懂的文字。第二种运行一段代码。有些需求不依赖外部服务比如数据清洗、格式转换、数学计算直接在技能里放一段 Python 或 JavaScript 就行。这种方式非常轻量特别适合在做内容处理类的应用时使用。第三种触发一个工作流。一些复杂任务涉及多个步骤或多个系统的协作你可以把 Skill 理解成“总开关”一旦被触发就启动一个预设的流程。比如“查客户逾期账单并发送提醒短信”这个动作涉及查询数据库、判断逾期状态、选择短信模版、调用短信通道把它编排成一个工作流再把入口封装成 Skill使用起来非常顺手。在执行逻辑这个环节我想特别提醒一点Skill 的边界要小。很多人恨不得一个 Skill 搞定所有事情结果把它搞得又大又重模型一触发就出各种幺蛾子。更好的实践是“一个 Skill 只做一件事”把多个技能串起来交给上层的智能体去编排。后面我还会专门聊这个问题。3. Skill 为什么火了从四个层面看3.1 从“建议型助手”到“执行型助手”的质变前两年大家做聊天机器人时关注点基本都在“话术像不像人”“回答专不专业”本质上还是一个“建议型助手”——你说你感冒了它建议你多喝热水你说想学编程它给你列个学习计划。这种助手有一个比较大的尴尬它的价值止步于“动嘴”。引入 Skill 之后AI 应用完成了一次明显的定位升级。它不再只是给建议而是真正能替你执行你说“帮我约明天下午三点的会议室”它直接调用会议室系统的接口把房间订好你说“把这份表格按金额从高到低排序再发给我邮箱”它能跑代码完成处理并发送邮件。从产品视角看这一步跨越非常关键。用户为“建议”付费的意愿跟为“结果”付费的意愿完全不是一个量级。这也是为什么各家平台最近都在大力推 Agent、推技能市场本质原因是“能干活”的应用才有可持续的商业价值。3.2 一次定义、到处复用Skill 成了团队的数字资产Skill 还有一个容易被忽视的价值复用性。我以前做项目时很多基础能力是散落在不同代码里的比如“查询天气”这个功能A 项目写一遍B 项目再写一遍每个项目的写法还不一样维护起来很痛苦。用 Skill 的方式把它沉淀下来之后情况完全变了。所有“查询天气”的逻辑就这一份谁要用谁引入。你甚至可以把它发布到团队内部的技能库里其他同事做任何需要天气信息的应用直接拖过去就能用不用关心底层是你用的哪个天气服务商。这个思路放到公司层面就是实打实的资产积累。你把业务里那些通用能力挨个包装成 Skill以后任何新项目启动等于站在一个现成的零件仓库上干活开发效率翻倍只是起步。3.3 比“重新训练”省钱比“提示词工程”稳定很多人可能会问想要模型完成特定任务为什么不直接写个长提示词或者干脆微调一个模型这里面的账我跟你算一算。长提示词确实能引导模型完成一些事但它的不稳定是出了名的。你把十几条指令塞在一起模型很可能抓不住重点或者在某个环节理解偏差而且每次请求都要把大段提示词送给模型token 成本并不低。微调模型的成本就更不用说了数据准备、算力开销、模型维护都不是一般团队能随便扛下来的。Skill 的思路是“让模型做决策让代码做执行”。决策部分只消耗少量 token执行部分走 API 或本地代码成本和稳定性都可控。我实测过同样一个“生成周报并发送邮件”的场景纯提示词方案不仅经常格式跑偏还偶尔会编造数据而改成 Skill 方案后格式由代码强制保证模型只需要把用户这周做了什么转成结构化摘要整个流程的质量明显稳定了许多。3.4 平台生态正在把它变成“标准件”还有一个不可忽略的助推因素各个大模型平台和应用平台都在主动推“技能化”。类似 ChatGPT 的插件机制出来后“让模型调用工具”就已经成了行业共识到后面 LangChain、Coze、Dify 这类工具又把这个模式逐渐标准化大家定义函数、绑定 API、给模型传工具清单的流程越来越一致。标准化的意义在于它大大降低了学习成本和迁移成本。你今天在一个平台上学会怎么搭 Skill换到另一个平台核心逻辑依然通用。生态里的技能市场也慢慢起来了有些别人做好的技能你稍微改改参数就能拿来用。Skill 能火不仅仅是技术原因更是因为它踩中了“基础设施标准化”这个节奏。4. 实操从零做一个“查天气” Skill4.1 需求分析与接口准备概念聊得再多不如亲手搭一个。我拿最经典的“查天气”来演示这个例子虽然简单但该涉及的环节一样不少。第一步先想清楚你到底要实现什么效果。用户说完“查一下上海明天的天气”你的应用能返回明天的气温、天气现象、风力这些信息这就够了。先别急着加“要不要带伞”“适不适合跑步”这些衍生判断第一步要把主链路跑通。第二步找一个能用的天气数据接口。我习惯用和风天气的 API注册后可以拿到一个免费额度返回的 JSON 里有温度、天气代码、风向等字段。你不需要专门买服务器也不需要准备数据库一个能发 HTTP 请求的环境就够。第三步准备好接口的调用方式。你需要知道自己要请求哪个 URL、需要哪些参数、返回结构是什么样的。这一步做扎实后面写执行逻辑会很顺。4.2 在平台上创建一个新技能现在的应用平台大多支持可视化的技能编辑以国内常见的智能体平台为例操作路径大致是进入项目空间找到“技能”或“插件”入口新建一个技能然后选择“使用 API”或者“自定义代码”。创建时需要填三样核心内容正好对应前面讲的元信息、参数定义和执行逻辑技能名称和描述根据 2.1 节的原则往具体里写。入参定义定义 city、date、unit 这些字段注意 city 用字符串、unit 用枚举。执行逻辑在代码区写入调用天气 API 的逻辑并在末尾把结果转成模型可读的文本。我用一段伪代码来说明后端逻辑长什么样方便你理解整体结构import requests from datetime import datetime def get_weather(city: str, date: str None, unit: str celsius): # 1. 城市名转城市ID实际项目中这里一般会调用地理编码接口 city_id geo_code(city) # 2. 请求天气服务商接口 resp requests.get( fhttps://api.example.com/v7/weather/forecast, params{location: city_id, date: date or datetime.now().strftime(%Y-%m-%d)} ) data resp.json() # 3. 把盘根错节的JSON整理成一句人话 temp data[daily][0][temp] text data[daily][0][text] wind data[daily][0][wind_dir] unit_label 摄氏度 if unit celsius else 华氏度 return f{city}{date}的天气是{text}气温约{temp}{unit_label}风向{wind}。这段代码不是完整的生产级实现但结构是对的先解析参数再请求外部接口最后把结构化的 JSON 转成自然语言。模型拿到这段返回文本后只需要做简单润色就能直接回复给用户你的应用就跑通了。4.3 参数设计的几个实操注意点参数设计这一步我把容易出问题的细节单独拎出来说。一是城市名的标准化。用户可能说“上海”“上海市”“SHANGHAI”甚至“魔都”但天气接口不一定认这些叫法。最稳妥的做法是加一道“地理编码”步骤先把用户给的城市文本送到一个地理编码接口换成一个标准的城市 ID再拿着 ID 去查天气。这一步虽然多消耗一次请求但能明显提高准确性。二是日期的模糊表达。“明天”“后天”“下周三”这些说法模型能理解但接口只认具体的“YYYY-MM-DD”。所以你要在参数设计里让模型先把自然语言转成格式化的日期或者在后端代码中处理相对日期。我建议前者因为模型对“明天”的解释通常很可靠。三是单位问题。不同用户习惯不同有人在摄氏度、华氏度之间来回切换你最好提供 unit 参数并在描述里写清楚默认值。别在代码里硬编码单位这是我在产品上线后被用户吐槽过最多次的细节。4.4 联调测试要看的几个关键点技能配置完成后别急着接进对话流先做一轮针对性测试。我会准备一组典型提问逐条跑一遍看效果重点观察这几个维度能不能触发问“上海今天多少度”看模型是否自动选中这个技能。参数抽得准不准看模型是不是正确把“上海”填进 city、“今天”填进 date。返回结果顺不顺最终给到用户的回答是否自然有没有把 JSON 原文直接漏出去。边界情况处理问一个冷门城市或者干脆不提供城市名看技能会不会报错。我实测过一版早期配置当时城市参数解析经常失败后来在描述里加了“尽量使用标准中文城市名比如北京、上海、广州”这句话之后成功率一下子就上去了。别看这句话简单模型读不读得懂你的参数很多时候就差在这些描述细节上。5. 从调试到上线我踩过的坑和排查思路5.1 模型死活不触发技能九成是描述写得像“废话”我见过最多的问题就是技能配好了但用起来一点反应都没有。用户明明问了相关的问题模型还是只靠自己的知识硬答。排查思路只有一条把技能名称和描述当作一个“独立判断题”再审一遍。如果描述本身写得太宽比如“一个天气查询工具”模型没有足够依据判断该不该用如果描述和用户问题用词差异太大比如描述里全是英文术语用户却用中文问模型也可能栽在匹配上。真正管用的写法是“场景列举式”。不只要写“查询天气”还要写“当用户询问明天是否适合出行、该穿什么衣服、会不会下雨时也要调用本技能获取天气情况”。描述里包含足够的触发场景和同义表达命中率马上不同。5.2 参数传错、类型不对、日期变成乱码技能能触发之后第二个高发区是参数。参数层面的问题通常一眼就能看出来因为你会看到代码报错或者后端收到一坨明显不对的数据。我归纳常见的三类参数问题必填缺失用户问“北京天气”没有说时间如果你把 date 设为必填模型就会强行从上下文里猜一个猜错了整个请求就废了。合理做法是改成可选参数后端默认取今天。类型不对用户明明只说了一个城市模型却传进来一个数组或者把日期传成了时间戳。解决办法是严格定义 JSON Schema 里的 type并加描述说“这是一个字符串不要使用数组格式”。语言混用用户说的是“魔都”模型原样传给后端后端不认识。前端先做一步“别名清洗”能很大程度上化解这个问题。5.3 返回结果不自然JSON 原文直接露给用户这个问题新手也常碰到。技能执行后拿到了天气接口的 JSON结果模型没有做任何加工直接把这些大括号、字段名甩给了用户。解决方式有两种。第一后端代码先把 JSON 转成一段很自然的文本把“温度”“天气现象”“风力”糅进一句话里模型拿到的是已经加工好的内容出错概率就低。第二如果确实需要让模型做二次总结那就在技能的输出说明里明确写一句“这是一段机器返回的原始文本不要原样输出请结合上下文改写成自然回答”。我个人的习惯是优先用第一种方案能“简单干净”就别让模型二次发挥。5.4 常见问题速查表我把日常调试过程中的高频问题整理成一张表方便你以后排查现象可能原因排查方向技能从不触发描述太笼统、触发场景没说清重写描述增加具体场景和同义表达偶尔触发、时灵时不灵用户问法超出技能描述范围收集失败样本迭代补充描述参数频繁抽取错误字段描述含糊、缺枚举值逐字段完善 description尽量给 enum调用后接口报错参数类型不匹配、缺鉴权头查看后端日志确认参数实际传值和请求结构返回结果乱糟糟没做文本格式化后端先转自然语言文本再交回模型请求响应太慢技能链路过长、多个串行调用检查是否在触发前做了不必要的预加载5.5 一个省心的发布习惯日志与版本管理Skill 这种模块出问题常常是运行一两天后才暴露的不是测一两轮就能看出来。我的建议是在技能后端里把每次调用的入参、出参、耗时、报错信息都打印到日志里。日志是你排查真相时最重要的依据尤其是当用户反馈“答案感觉不对”但你又复现不了的时候。另外我强烈建议给每个技能做版本管理。不要“改完直接冲线上”我吃过不少这方面的亏有一次为了修日期解析问题我把参数逻辑改了结果老版本的兼容场景反而被打破了线上用户的请求挂在数据库查询上足足折腾了两小时。现在我的习惯是每次修改都生成一个新版本先在测试环境跑完回归用例再决定是否切主版本。一套流程下来踩坑率明显低了很多。6. 进阶从单个 Skill 到复杂任务的编排6.1 一个任务同时需要多个 Skill怎么编排技能做多了之后你会发现单个技能往往撑不起一个完整任务。比如用户说“帮我查一下去杭州的高铁顺便看看杭州这几天下雨不”这就涉及“查票”和“查天气”两个技能甚至还要再叠加“计算日期范围”。这时候你不需要去写一个更大的“万能技能”更合理的做法是让上层智能体同时挂载多个技能让它根据用户指令自行决定调用顺序。有些场景还有先后依赖关系比如先查天气再给出行建议这时候就要在工作流里把两个技能串起来前一个的输出作为后一个的输入。我的经验是优先让语音层“动态决策”怎么调用多个技能只有当顺序完全固定时再考虑用固定工作流去串。6.2 技能多了之后怎么才能“找得对”等你把团队里的技能积累到几百个之后一个新的问题会冒出来模型怎么在几百个技能里快速选中正确的那一个每个技能的描述都直接塞给模型既不现实效果也差模型在长上下文里反而更容易“看走眼”。现在行业内比较流行的做法是引入“技能检索”把所有技能的名称和描述向量化用户提出请求后先通过向量相似度检索出 Top 5 或 Top 10 个候选技能只把这几个技能的完整描述交给模型去决策。简单说这就是给技能装了一个“目录”避免模型在大海里捞针。等你真的管理了几百个技能就会理解这一步有多必要。6.3 企业落地时别忘了安全和权限最后必须聊聊安全边界。Skill 一旦能执行真实操作它就不再是一个“聊天玩具”而是一个真实工作入口。想象一下如果你的智能体能调用“发送邮件”“创建订单”“删除文件”这类技能那就必须对权限做好管控。我常用的几个安全习惯分享给大家参考最小化授权每个技能只申请完成任务所需的最小权限不要用一个通用 key 打通所有服务。建立审计日志所有技能调用都要可追溯关键时刻能查出哪一次调用做了什么事。严格校验输入外部接口请求体里凡是涉及跳转地址、文件路径、代码执行的内容都做白名单或正则校验。分级审批涉及资金、隐私、重要数据变更的操作建议设计人工审批环节而不是让模型全权代办。这些不是空话。我看到过不少项目技能本身做得很好最后却在权限上翻了车这种事一次就够长记性了。关于 Skill我在实际项目里最大的体会是它本质上是“给模型立边界、给代码补能力”的工程思路而不是什么学不会的魔法。想入门就从做一个像天气查询这样的小技能开始把描述的功夫练到位把参数边界划清楚再把日志和版本管理养成习惯你会发现自己对大模型应用的掌控力明显提升了一个台阶。等你把这个流程跑顺了回头再看那些复杂的 Agent 应用拆开来看也无非是一个又一个边界清清楚楚的 Skill 在协同工作。