这两年做 AI Agent 相关的工作被问得最多的一个问题就是你项目里天天挂在嘴边的 Skill 到底是什么它和 Prompt 有什么本质区别为什么同一个模型挂了技能之后表现能差出一大截问的人里有刚入行的开发者也有带过不少项目的技术负责人。我每次都要从零开始解释后来干脆决定写一套系列文章把 Skill 的认知、原理、实操一条线讲透。这算第一章先解决“它是谁”和“它怎么工作”这两个最基础也最关键的问题。先说结论Skill 这个概念在 2025 年之后被各大 AI 平台反复提起Claude Code、Codex、各种开源 Agent 框架都在强调“可复用的技能包”。但很多人对 Skill 的理解还停留在“一个写好的 Prompt”或者“一段能跑的脚本”这两种理解都太窄了。Skill 真正厉害的地方在于它把模型能力、工具执行、外部数据三件事打包成了一个可以被 Agent 统一调用的整体模块。这篇文章我会从一个真实项目切入把 Skill 的认知框架搭起来再往下拆到执行链路和实操写法最后结合我实际踩过的坑给你一份可以直接照着做的入门指南。1. Skill 到底是什么先把这个概念说清楚1.1 从一次真实的对话卡壳说起我做客服自动化项目的时候遇到过一件特别典型的事。客户希望 AI 能直接回答用户关于退货政策的咨询模型确实能答但每次表述都不一样今天说三天退货期明天说七天。这还不是最麻烦的最麻烦的是它不会主动查订单系统用户问“我的单号 8888 可以退吗”模型就开始一本正经地编答案连订单存不存在都不知道。后来我引入 Skill 解决了这个问题。思路很简单把“查订单”这个动作封装成一个 Skill里面固定好话术模板、明确参数格式再挂上一个真正去调后端订单接口的脚本。模型接到类似问题时先判断“这属于查订单技能的处理范围”然后把单号提取出来交给 Skill 去执行Skill 把真实结果回传模型再基于真实数据组织自然语言回复。从此口径统一了订单数据也变成了真实的。这个例子基本把 Skill 的价值说清楚了它不是为了取代模型的推理能力而是把那些需要稳定、可复用、不能出错的动作从“模型临场发挥”变成“模块化执行”。模型负责理解和表达Skill 负责把事办准。1.2 Skill 和 Prompt、Agent、插件的界限在哪这是大家问得最多的问题社区里也老是吵。很多人把 Skill 当成“高级 Prompt”也有人把它和插件混为一谈还有人分不清 Agent 和 Skill 谁是上级。我习惯用一张表来说清楚概念核心是什么典型特征一句话理解Prompt指令文本没有独立执行逻辑只是引导模型是“说给模型听的话”Skill能力模块含描述、脚本、校验逻辑可复用是“让模型拿去用的能力包”Plugin外部工具集提供 API 或界面与模型相对独立是“工具本身”Agent自主决策体能拆任务、调 Skill、做判断是“雇来干活的角色”Skill 和 Prompt 的区别我常用一个比喻Prompt 是菜谱上写的字Skill 是后厨里备好的半成品菜包。菜谱写“红烧肉怎么做”模型看了会做但每次火候、咸淡全靠临场发挥菜包递给你拆袋下锅出品稳定。Skill 里面确实包含 Prompt 成分比如描述文件和调用说明但它的核心价值在于“执行逻辑被固化下来了”不再依赖模型每一次的随机发挥。Agent 和 Skill 的关系就更明确了Agent 是大脑加手脚Skill 是某个具体动作的肌肉记忆。Agent 负责分解目标、规划步骤、决定什么时候用什么技能Skill 只负责把它对应的那件事做对、做稳。你可以把 Skill 看成 Agent 能力栈里的最小可复用单元。1.3 Skill 在不同语境下的多重含义既然标题用了 Skill 这个词我觉得有必要坦白说一下行业里叫 Skill 的东西并不只有 AI Agent 这一种。比如 PCB 设计领域Cadence Allegro 有一门脚本语言就叫 Skill用来写菜单、做二次开发很多硬件工程师靠它把重复性的布线操作自动化。又比如求职面试和职场成长里常说的“软技能”“硬技能”英文也是 skill。甚至有些游戏和影视资源里也会用这个词做标签。我写这个系列主切 AI Agent 方向的 Skill因为现在大家最关心的确实是这个。但不管是哪种语境本质逻辑是相通的把复杂、重复、易错的工作封装成一个可以被反复调用的单元让它“一次设计处处复用”。你如果理解了这一层再看任何平台的 Skill 文档都会觉得似曾相识。2. Skill 的工作原理它是怎么被想起来的又是怎么跑起来的2.1 技能注册Agent 是怎么“知道”你有这么多 Skill 的先搞清楚一件事Agent 并不是每次运行都把所有 Skill 完整读进脑子里的。它维护的是一个“技能清单”也叫声明文件或注册表。当你给 Agent 挂载了 20 个 Skill它不会傻到把这 20 个 Skill 的全部脚本代码塞进上下文而是先把每个 Skill 的名称、描述、用途、触发条件、参数概要进行索引。这个过程特别像手机桌面。你手机里装了几十个 App但每次点亮屏幕时看到的只有图标和名称真正点击某个 App 才会加载完整界面。技能注册表就是那一屏图标属于元数据层等到 Skill 被真正调用时平台才会去读脚本文件、加载依赖、执行逻辑。这个设计非常关键。如果你违反它把 20 个 Skill 的完整源代码全部塞进上下文Token 消耗会飙升到离谱而且模型会被海量代码干扰根本分不清当前该用哪个。所以好的 Skill 设计描述信息一定要精准要让 Agent 在只看描述的情况下就能判断“这个场景该不该用我”。2.2 意图识别与 Skill 命中为什么有时候 Skill 会被“无视”大致的流程是这样用户发来请求Agent 先做一次预判把请求分成两类。一类是直接问答型模型靠自身知识就能回答不需要动用任何技能另一类是操作型比如“帮我查一下订单”“帮我画个图表”“把这个项目编译一下”这类请求会触发 Agent 去技能注册表里做匹配看有没有对应的 Skill。匹配的依据是“相关性打分”。每个 Skill 的描述会被语义化和当前请求、历史对话的语义做相似度计算同时还会结合一些规则比如用户明确提到某个工具名或者某个关键词触发了硬编码条件。打分最高的 Skill 才会被选中。这里有一个非常容易踩的坑Skill 描述写得太“虚”了。我以前见过一个日志分析 Skill描述写的是“帮助用户洞察数据深层价值提升可观测性”结果用户说“帮我看看这个 error 日志哪里有问题”的时候Agent 愣是没想起它。后来我把描述改成“分析 Nginx 错误日志提取 4xx/5xx 错误频率支持输入日志文件路径输出统计图表”命中率立刻上来了。记住描述是写给模型看的索引不是写给领导看的项目申报书。2.3 Skill 的执行链路从参数抽取到结果回填当 Skill 命中之后接下来会发生四件事我拆开讲。第一步是参数抽取。Agent 根据当前对话和历史上下文把 Skill 要求的入参从用户的话里抽出来。比如你的 Skill 需要一个日期范围参数用户说“看下这个月的数据”Agent 需要算出具体是 6 月 1 日到 6 月 30 日并填进去。这步非常考验模型的理解力所以 Skill 参数描述写得越明确Agent 抽取就越准。第二步是脚本执行。Skill 内部的核心逻辑开始运行可能是调用外部 API也可能是执行本地 Python 脚本、Shell 命令、读写文件、生成图片。这一步跟模型的推理已经解耦了也就是模型不参与具体执行过程只是等待返回结果。这是 Skill 稳定性的根源计算交给代码表达交给模型各干各的。第三步是结果回填。执行完的原始结果要按约定好的格式返回给 Agent常见的是 JSON 或者结构化文本。比如上面那个订单查询 Skill返回的结果长这样{ order_id: 8888, status: delivered, product: 无线耳机, returnable: true, return_deadline: 2025-07-03 }Agent 拿到这份 JSON 后再加上用户最初的提问生成最终的自然语言回复“您的订单 8888 已签收商品是无线耳机目前支持退货退货截止日期是 7 月 3 日。”这样既准确又有人味。第四步是状态清理。Skill 执行完临时文件、缓存数据、上下文片段都要清理干净否则下一次调用时可能残留脏数据。这个步骤经常被新手忽略但线上出问题往往就出在这里。2.4 上下文策略省 Token 的底层逻辑热搜里有个“codex 省 token 的 skill”很多人不理解Skill 不是用来扩展功能的吗怎么还能省 Token其实 Skill 省 Token 有三条路径。第一Skill 的描述被压缩进上下文而执行脚本不常驻。同一个 Skill 被调用 10 次脚本不会重复占据上下文只有执行结果会进来。这就像你把一个工具函数封装好之后每次调用只需要传参数不用把函数体抄一遍。第二Skill 内部可以做数据预处理。比如你想让它分析一个 1 万行的日志文件如果不走 Skill你得把这一万行全部塞给模型看模型看完头都大了。走了 Skill脚本先把日志聚合、滤掉无关行、只输出 TOP 10 的异常摘要模型看到的只是那几 KB 的摘要结果。这个差距是数量级的。第三稳定的 Skill 输出会减少模型的“试错成本”。模型自己折腾半天来回改好几轮 Prompt 才能跑通的事Skill 一次就出正确结果省下来的隐式 Token 往往比看到的还多。所以省 Token 不是靠偷工减料而是靠减少无效计算。3. 当前主流平台里 Skill 的落地形态3.1 Claude Code 与 Codex 的 Skill 实践我先聊大家最熟悉的两个工具Claude Code 和 Codex。它们是目前开发圈里讨论度最高的 AI 编程助手也都支持 Skill 或者说类似技能的机制。Codex 的 Skill 生态吸收了大量社区实践你可以把 Skill 理解成“任务模板 脚本”的组合在处理编程任务时特别有用。比如有人做了“自动化代码审查 Skill”它定义好审查维度包括安全检查、性能分析、可维护性评估每个维度用什么样的规则去扫最后输出固定格式的报告。套上这个 Skill 之后Codex 的审查结果非常稳定不会这次只讲安全、下次只讲格式。Claude Code 这边强调“对话式技能”它的 SKILL.md 机制大家应该经常见。一个 Skill 本质是一个文件夹里面放着 SKILL.md 描述文档再配上附属脚本、模板、资源文件。当对话进入相关场景时模型会读取这个 Skill 的文档然后按文档里描述的工作流去执行。我个人的体会是不管哪家平台Skill 的设计哲学都是相通的描述要精确、脚本要可靠、输出要有结构。平台之间的差异只是封装格式和调度细节你掌握了一套设计方法换平台只是换个壳。3.2 通用 Agent 框架中的 Skill 设计模式除了头部商业产品开源 Agent 框架里的 Skill 设计也很有看头。我在新项目里经常自己搭 Agent也研究过不少框架的 Tool 和 Skill 抽象总结下来无外乎三类模式。第一类是函数式模式。把 Skill 定义成一个函数输入输出都有明确的类型定义。优点是简单直接、调试方便适合处理单步、无状态的任务缺点是复杂状态不好管理如果 Skill 内部要维护多轮状态就有点吃力。第二类是声明式模式。Skill 由描述文件定义通过 DSL 描述参数、步骤、资源平台负责解析和调度。优点是跨平台复用性强写一次可以在多个框架里跑缺点是学习曲线稍高DSL 语法本身也需要维护。第三类是混合式模式。描述文件定义意图和参数执行层可以跑 Python 脚本、Shell 命令甚至调用容器。这是我最常用的模式既能精确控制模型看到什么又能享受脚本的灵活性。如果你打算在自己项目里做 Skill 体系我建议先定清楚三层接口层负责模型怎么调用你执行层负责你真正干什么活资源层负责需要哪些文件和依赖。接口层要稳定资源层要可移植执行层要有边界。3.3 Skill 的工程化边界什么东西不该放进 Skill这一点值得单独拿出来讲因为很多人一上来就玩命往 Skill 里塞东西最后搞成一个“四不像”既不适合模型调用也不好维护。不该放进 Skill 的有三类。第一类是需要高度主观判断、语境很强的事比如“帮我判断这个方案好不好”这种没有固定标准的活用 Skill 反而僵化不如让模型自由发挥。第二类是执行时间太长的任务Skill 调用通常有超时设计你放一个跑两小时的 ETL 进去Agent 等不起体验会很差。第三类是高度依赖长会话历史的流程Skill 更适合处理“拿到几个参数就能独立完成”的任务如果它每一步都要回顾前面二十轮对话那拆成 Skill 的收益就很低。一句话总结Skill 的边界就是“可复用的标准动作”。超过这个边界要么回归纯模型推理要么该上真正的 Agent 编排。4. 从 0 到 1 动手写一个 Skill完整实操4.1 准备阶段定义场景、输入和输出我拿一个具体的例子带你完整过一遍这来自我自己做过的一个数据分析项目“周报数据汇总 Skill”。使用场景是每周运营同学都会问同样的问题本周各渠道转化率怎么样和上周比变化大不大之前我用 Agent 直接回答模型每次都要现场查数据SQL 写得还不稳定一会儿格式错一会儿字段名对不上。动手之前我先做三件事。第一确定触发场景哪些话术会触发这个 Skill比如“本周转化率”“渠道对比”“环比变化”这类关键词都要覆盖。第二定义输入参数我定四个字段渠道名称可选默认全部、周起始日期、周结束日期、对比周起始日期可选默认上一周。第三定义输出格式要求返回包含渠道名、本周转化率、上周转化率、环比变化百分比的表格以及一段自动生成的总结。这一步看起来简单但非常关键。参数定义不清晰后续 Agent 抽取就会出错输出格式不明确结果就不可控。4.2 编写描述文件和核心脚本描述文件是给模型看的所以它必须是“模型友好型”的。我的 SKILL.md 大概长这样# 周报数据汇总 ## 功能 根据数据库中的用户行为数据计算并对比指定业务渠道本周与上周的转化率输出汇总表格和环比变化。 ## 触发场景 用户询问本周/本周期各渠道转化率、环比变化、数据波动原因分析等场景。 ## 输入参数 - channel: 渠道名称可选如 ios、android、h5 - week_start: 周起始日期格式 YYYY-MM-DD - week_end: 周结束日期格式 YYYY-MM-DD - compare_start: 对比起始日期可选 ## 执行流程 1. 解析用户需求把自然语言中的时间词换算成具体日期。 2. 调用 data_query.py传入参数。 3. 将返回值整理为表格文本。 ## 预期输出 渠道名、本周转化率、上周转化率、环比变化百分比以及一句总结。核心脚本 data_query.py 做的事情也简单读入参数、连数据库、跑一条带日期过滤的 SQL、把结果聚合成环比字段、输出 JSON。我贴一个简化版本供你参考import sys import json import datetime import sqlite3 def main(): params json.loads(sys.argv[1]) week_start params.get(week_start) week_end params.get(week_end) compare_start params.get(compare_start) channel params.get(channel) conn sqlite3.connect(analytics.db) cur conn.cursor() sql SELECT channel, COUNT(DISTINCT user_id) AS users, SUM(converted) AS conversions FROM events WHERE date BETWEEN ? AND ? args [week_start, week_end] if channel: sql AND channel ? args.append(channel) sql GROUP BY channel cur.execute(sql, args) this_week cur.fetchall() # 计算环比并输出 result [] for row in this_week: channel_name, users, conversions row conversion_rate round(conversions / users * 100, 2) if users else 0 result.append({ channel: channel_name, this_week_rate: conversion_rate, last_week_rate: 0.0, change_percent: 0.0 }) print(json.dumps({code: 0, data: result}, ensure_asciiFalse)) if __name__ __main__: main()实际项目里环比的计算会用另一段 SQL 查上一周期的数据再做差值百分比这里为了演示只保留了主流程。脚本写完之后要单独在命令行里跑一次确认入参、出参都对再交给模型去接。4.3 本地测试与回归调试写完一定要测试而且不要只在理想环境下测。我会自己扮演一个“说不清楚话的用户”输入“帮我看看这周 h5 怎么样了”看 Agent 能不能自动把“这周”换算成具体日期、能不能从“h5”这个缩写里识别出渠道名。测试时我会盯三个指标。第一是命中率连续测试 10 次看 Skill 被调用了几次低于 7 次就要考虑改写描述。第二是参数抽取正确率日期算对没渠道名映射对没这是最容易出错的一环。第三是输出稳定性同一份数据跑三次结果是不是一致。如果模型拿到结果后重新组织了语言导致表达不一致我会考虑让 Skill 的输出走固定模板把变量控制在数据本身而不是措辞。4.4 发布与管理版本、权限、命名Skill 的管理其实和代码仓库的管理很像。我给自己定了三条纪律。第一每个 Skill 都要有版本号脚本变更要记录 changelog。别觉得小题大做等你哪天改了逻辑老版本的效果对比不出来的时候就知道版本号有多重要了。第二上线前做一次“最小权限检查”Skill 里的脚本只能访问它完成任务所需的资源绝不给它任意路径的读写权限。第三命名用“动词 对象”的结构比如“查询订单”“生成周报”“分析日志”别用“数据分析助手”这种模糊的名字模型分不清你自己过两周也忘了它干嘛的。5. 高频问题与避坑指南5.1 我的 Skill 为什么总是不被调用这个问题我被问过太多次了排查思路我整理成了一个优先级列表。第一查描述。描述里如果全是笼统的能力介绍没有明确的触发场景模型就会“想不起来”。触发场景怎么写直接写用户会说的话比如“当用户问『为什么今天的销售收入下降了』时使用本技能”。这叫给模型一个锚点。第二查参数。参数定义不清晰模型不确定自己能不能满足输入要求就不会冒险调用。比如你要求必须传 device_id但用户只说“看下 Android 的数据”模型不知道从 Android 怎么映射到具体 ID可能就选择自己硬答。好的做法是给参数加默认值或者在描述里写明映射规则。第三查权限和挂载。有些平台的 Skill 需要显式启用或者对某些模型版本不可用。确认你的 Skill 在当前会话里真的挂载成功而不是写在配置文件里却没有被加载。5.2 Skill 越写越多管理不过来怎么办Skill 数量起来之后最尴尬的是“自己都不记得写了什么”。我现在的习惯是每加一个 Skill 就在索引文件里登记名称、用途、负责人、最近一次修改时间、依赖项。这个索引文件本身也做成一个 Skill专门回答“我有哪些能力可用”这个问题。这样当 Agent 的任务涉及多个技能时它可以通过索引做一次预筛选而不是挨个试。另外要定期清理。我一般每两个月做一次 review把三个月没被调用过的 Skill 标记为待定再放一个月没有调用就直接下线。别舍不得Skill 是工具不是收藏品。留着大量无人调用的 Skill只会增加每次意图匹配的干扰项反而降低命中率。5.3 社区里的优秀 Skill 都在解决什么问题从最近社区里流行的一些 Skill 方向能看出大家的真实痛点。有人做写代码相关的 Skill有人做 PPT 生成、日志分析、测试用例生成还有人做“去 AI 味的 Skill”专门把模型生成的文本改写得更像真人。这个“去 AI 味”听起来很玄其实也是标准动作的固化。拆掉“首先其次最后”这类连词打乱排比句式插入口语化表达这些规则写成 Skill 脚本后执行逻辑非常清晰。我试过几个效果立竿见影比在 Prompt 里说一百遍“请写得自然一点”都管用因为规则一旦固化成代码模型就没有发挥空间了输出自然稳定。这给了我们一个信号Skill 的疆界正在快速扩展从纯编程领域走向写作、设计、数据分析、电商运营等岗位。未来哪个岗位能把自己的高频重复工作抽象成 Skill谁就能在工具使用上领先别人一截。5.4 如何判断一个公开的 Skill 值不值得用最后聊一下怎么下载和使用别人的 Skill毕竟社区里公开的 Skill 越来越多但不是每个都值得往项目里引。我的判断标准是四条一看描述是否清晰描述写得乱的直接 pass二看依赖是否简单一个日志分析 Skill 如果要求你装好几个重量级依赖维护成本太高不如自己写个轻量的三看是否有测试示例能用一句真实用户话术展示输入输出的通常质量更高四看维护活跃度一个 Skill 半年没更新过的多半早已和最新接口脱节了。把公开 Skill 引入项目之后不要直接上线先在自己环境里跑一遍样例确认输出符合预期。我踩过不少次坑有的 Skill 看起来功能很全但脚本里藏着硬编码路径换个环境就崩溃。所有外部代码都要当作第三方依赖来对待先审查再使用。写完这一章我心里其实挺感慨的。Skill 这个概念乍一看很简单但真正理解它的人并不多。它解决的是“可复用、需稳定”的那部分问题不是让你把所有东西都技能化。我自己踩过的最大一个坑就是一上来把什么都封装成 Skill结果维护成本比收益还高。后来学会了先问自己三个问题这个动作我一个月会触发几次它出错我能接受吗它的输入输出能定义清楚吗三个都是肯定答案再动手封装。就拿今天这个周报 Skill 来说从前期的场景梳理、参数定义到描述文件、脚本编写再到测试和上线整套流程走下来你对 Agent 的工作方式会有完全不一样的理解。下一章我准备讲 Skill 的进阶设计包括多 Skill 协作、Skill 内部的错误处理与重试机制以及从个人 Skill 走向团队共享 Skill 的工程化经验。如果你正在用 Skill或者正准备入坑建议先照这篇文章把手头最重复的那个小动作封装起来试试跑通一个你就会理解它到底给工具使用体验带来了多大改变。
AI Agent中Skill是什么？与Prompt的区别及工作原理详解
这两年做 AI Agent 相关的工作被问得最多的一个问题就是你项目里天天挂在嘴边的 Skill 到底是什么它和 Prompt 有什么本质区别为什么同一个模型挂了技能之后表现能差出一大截问的人里有刚入行的开发者也有带过不少项目的技术负责人。我每次都要从零开始解释后来干脆决定写一套系列文章把 Skill 的认知、原理、实操一条线讲透。这算第一章先解决“它是谁”和“它怎么工作”这两个最基础也最关键的问题。先说结论Skill 这个概念在 2025 年之后被各大 AI 平台反复提起Claude Code、Codex、各种开源 Agent 框架都在强调“可复用的技能包”。但很多人对 Skill 的理解还停留在“一个写好的 Prompt”或者“一段能跑的脚本”这两种理解都太窄了。Skill 真正厉害的地方在于它把模型能力、工具执行、外部数据三件事打包成了一个可以被 Agent 统一调用的整体模块。这篇文章我会从一个真实项目切入把 Skill 的认知框架搭起来再往下拆到执行链路和实操写法最后结合我实际踩过的坑给你一份可以直接照着做的入门指南。1. Skill 到底是什么先把这个概念说清楚1.1 从一次真实的对话卡壳说起我做客服自动化项目的时候遇到过一件特别典型的事。客户希望 AI 能直接回答用户关于退货政策的咨询模型确实能答但每次表述都不一样今天说三天退货期明天说七天。这还不是最麻烦的最麻烦的是它不会主动查订单系统用户问“我的单号 8888 可以退吗”模型就开始一本正经地编答案连订单存不存在都不知道。后来我引入 Skill 解决了这个问题。思路很简单把“查订单”这个动作封装成一个 Skill里面固定好话术模板、明确参数格式再挂上一个真正去调后端订单接口的脚本。模型接到类似问题时先判断“这属于查订单技能的处理范围”然后把单号提取出来交给 Skill 去执行Skill 把真实结果回传模型再基于真实数据组织自然语言回复。从此口径统一了订单数据也变成了真实的。这个例子基本把 Skill 的价值说清楚了它不是为了取代模型的推理能力而是把那些需要稳定、可复用、不能出错的动作从“模型临场发挥”变成“模块化执行”。模型负责理解和表达Skill 负责把事办准。1.2 Skill 和 Prompt、Agent、插件的界限在哪这是大家问得最多的问题社区里也老是吵。很多人把 Skill 当成“高级 Prompt”也有人把它和插件混为一谈还有人分不清 Agent 和 Skill 谁是上级。我习惯用一张表来说清楚概念核心是什么典型特征一句话理解Prompt指令文本没有独立执行逻辑只是引导模型是“说给模型听的话”Skill能力模块含描述、脚本、校验逻辑可复用是“让模型拿去用的能力包”Plugin外部工具集提供 API 或界面与模型相对独立是“工具本身”Agent自主决策体能拆任务、调 Skill、做判断是“雇来干活的角色”Skill 和 Prompt 的区别我常用一个比喻Prompt 是菜谱上写的字Skill 是后厨里备好的半成品菜包。菜谱写“红烧肉怎么做”模型看了会做但每次火候、咸淡全靠临场发挥菜包递给你拆袋下锅出品稳定。Skill 里面确实包含 Prompt 成分比如描述文件和调用说明但它的核心价值在于“执行逻辑被固化下来了”不再依赖模型每一次的随机发挥。Agent 和 Skill 的关系就更明确了Agent 是大脑加手脚Skill 是某个具体动作的肌肉记忆。Agent 负责分解目标、规划步骤、决定什么时候用什么技能Skill 只负责把它对应的那件事做对、做稳。你可以把 Skill 看成 Agent 能力栈里的最小可复用单元。1.3 Skill 在不同语境下的多重含义既然标题用了 Skill 这个词我觉得有必要坦白说一下行业里叫 Skill 的东西并不只有 AI Agent 这一种。比如 PCB 设计领域Cadence Allegro 有一门脚本语言就叫 Skill用来写菜单、做二次开发很多硬件工程师靠它把重复性的布线操作自动化。又比如求职面试和职场成长里常说的“软技能”“硬技能”英文也是 skill。甚至有些游戏和影视资源里也会用这个词做标签。我写这个系列主切 AI Agent 方向的 Skill因为现在大家最关心的确实是这个。但不管是哪种语境本质逻辑是相通的把复杂、重复、易错的工作封装成一个可以被反复调用的单元让它“一次设计处处复用”。你如果理解了这一层再看任何平台的 Skill 文档都会觉得似曾相识。2. Skill 的工作原理它是怎么被想起来的又是怎么跑起来的2.1 技能注册Agent 是怎么“知道”你有这么多 Skill 的先搞清楚一件事Agent 并不是每次运行都把所有 Skill 完整读进脑子里的。它维护的是一个“技能清单”也叫声明文件或注册表。当你给 Agent 挂载了 20 个 Skill它不会傻到把这 20 个 Skill 的全部脚本代码塞进上下文而是先把每个 Skill 的名称、描述、用途、触发条件、参数概要进行索引。这个过程特别像手机桌面。你手机里装了几十个 App但每次点亮屏幕时看到的只有图标和名称真正点击某个 App 才会加载完整界面。技能注册表就是那一屏图标属于元数据层等到 Skill 被真正调用时平台才会去读脚本文件、加载依赖、执行逻辑。这个设计非常关键。如果你违反它把 20 个 Skill 的完整源代码全部塞进上下文Token 消耗会飙升到离谱而且模型会被海量代码干扰根本分不清当前该用哪个。所以好的 Skill 设计描述信息一定要精准要让 Agent 在只看描述的情况下就能判断“这个场景该不该用我”。2.2 意图识别与 Skill 命中为什么有时候 Skill 会被“无视”大致的流程是这样用户发来请求Agent 先做一次预判把请求分成两类。一类是直接问答型模型靠自身知识就能回答不需要动用任何技能另一类是操作型比如“帮我查一下订单”“帮我画个图表”“把这个项目编译一下”这类请求会触发 Agent 去技能注册表里做匹配看有没有对应的 Skill。匹配的依据是“相关性打分”。每个 Skill 的描述会被语义化和当前请求、历史对话的语义做相似度计算同时还会结合一些规则比如用户明确提到某个工具名或者某个关键词触发了硬编码条件。打分最高的 Skill 才会被选中。这里有一个非常容易踩的坑Skill 描述写得太“虚”了。我以前见过一个日志分析 Skill描述写的是“帮助用户洞察数据深层价值提升可观测性”结果用户说“帮我看看这个 error 日志哪里有问题”的时候Agent 愣是没想起它。后来我把描述改成“分析 Nginx 错误日志提取 4xx/5xx 错误频率支持输入日志文件路径输出统计图表”命中率立刻上来了。记住描述是写给模型看的索引不是写给领导看的项目申报书。2.3 Skill 的执行链路从参数抽取到结果回填当 Skill 命中之后接下来会发生四件事我拆开讲。第一步是参数抽取。Agent 根据当前对话和历史上下文把 Skill 要求的入参从用户的话里抽出来。比如你的 Skill 需要一个日期范围参数用户说“看下这个月的数据”Agent 需要算出具体是 6 月 1 日到 6 月 30 日并填进去。这步非常考验模型的理解力所以 Skill 参数描述写得越明确Agent 抽取就越准。第二步是脚本执行。Skill 内部的核心逻辑开始运行可能是调用外部 API也可能是执行本地 Python 脚本、Shell 命令、读写文件、生成图片。这一步跟模型的推理已经解耦了也就是模型不参与具体执行过程只是等待返回结果。这是 Skill 稳定性的根源计算交给代码表达交给模型各干各的。第三步是结果回填。执行完的原始结果要按约定好的格式返回给 Agent常见的是 JSON 或者结构化文本。比如上面那个订单查询 Skill返回的结果长这样{ order_id: 8888, status: delivered, product: 无线耳机, returnable: true, return_deadline: 2025-07-03 }Agent 拿到这份 JSON 后再加上用户最初的提问生成最终的自然语言回复“您的订单 8888 已签收商品是无线耳机目前支持退货退货截止日期是 7 月 3 日。”这样既准确又有人味。第四步是状态清理。Skill 执行完临时文件、缓存数据、上下文片段都要清理干净否则下一次调用时可能残留脏数据。这个步骤经常被新手忽略但线上出问题往往就出在这里。2.4 上下文策略省 Token 的底层逻辑热搜里有个“codex 省 token 的 skill”很多人不理解Skill 不是用来扩展功能的吗怎么还能省 Token其实 Skill 省 Token 有三条路径。第一Skill 的描述被压缩进上下文而执行脚本不常驻。同一个 Skill 被调用 10 次脚本不会重复占据上下文只有执行结果会进来。这就像你把一个工具函数封装好之后每次调用只需要传参数不用把函数体抄一遍。第二Skill 内部可以做数据预处理。比如你想让它分析一个 1 万行的日志文件如果不走 Skill你得把这一万行全部塞给模型看模型看完头都大了。走了 Skill脚本先把日志聚合、滤掉无关行、只输出 TOP 10 的异常摘要模型看到的只是那几 KB 的摘要结果。这个差距是数量级的。第三稳定的 Skill 输出会减少模型的“试错成本”。模型自己折腾半天来回改好几轮 Prompt 才能跑通的事Skill 一次就出正确结果省下来的隐式 Token 往往比看到的还多。所以省 Token 不是靠偷工减料而是靠减少无效计算。3. 当前主流平台里 Skill 的落地形态3.1 Claude Code 与 Codex 的 Skill 实践我先聊大家最熟悉的两个工具Claude Code 和 Codex。它们是目前开发圈里讨论度最高的 AI 编程助手也都支持 Skill 或者说类似技能的机制。Codex 的 Skill 生态吸收了大量社区实践你可以把 Skill 理解成“任务模板 脚本”的组合在处理编程任务时特别有用。比如有人做了“自动化代码审查 Skill”它定义好审查维度包括安全检查、性能分析、可维护性评估每个维度用什么样的规则去扫最后输出固定格式的报告。套上这个 Skill 之后Codex 的审查结果非常稳定不会这次只讲安全、下次只讲格式。Claude Code 这边强调“对话式技能”它的 SKILL.md 机制大家应该经常见。一个 Skill 本质是一个文件夹里面放着 SKILL.md 描述文档再配上附属脚本、模板、资源文件。当对话进入相关场景时模型会读取这个 Skill 的文档然后按文档里描述的工作流去执行。我个人的体会是不管哪家平台Skill 的设计哲学都是相通的描述要精确、脚本要可靠、输出要有结构。平台之间的差异只是封装格式和调度细节你掌握了一套设计方法换平台只是换个壳。3.2 通用 Agent 框架中的 Skill 设计模式除了头部商业产品开源 Agent 框架里的 Skill 设计也很有看头。我在新项目里经常自己搭 Agent也研究过不少框架的 Tool 和 Skill 抽象总结下来无外乎三类模式。第一类是函数式模式。把 Skill 定义成一个函数输入输出都有明确的类型定义。优点是简单直接、调试方便适合处理单步、无状态的任务缺点是复杂状态不好管理如果 Skill 内部要维护多轮状态就有点吃力。第二类是声明式模式。Skill 由描述文件定义通过 DSL 描述参数、步骤、资源平台负责解析和调度。优点是跨平台复用性强写一次可以在多个框架里跑缺点是学习曲线稍高DSL 语法本身也需要维护。第三类是混合式模式。描述文件定义意图和参数执行层可以跑 Python 脚本、Shell 命令甚至调用容器。这是我最常用的模式既能精确控制模型看到什么又能享受脚本的灵活性。如果你打算在自己项目里做 Skill 体系我建议先定清楚三层接口层负责模型怎么调用你执行层负责你真正干什么活资源层负责需要哪些文件和依赖。接口层要稳定资源层要可移植执行层要有边界。3.3 Skill 的工程化边界什么东西不该放进 Skill这一点值得单独拿出来讲因为很多人一上来就玩命往 Skill 里塞东西最后搞成一个“四不像”既不适合模型调用也不好维护。不该放进 Skill 的有三类。第一类是需要高度主观判断、语境很强的事比如“帮我判断这个方案好不好”这种没有固定标准的活用 Skill 反而僵化不如让模型自由发挥。第二类是执行时间太长的任务Skill 调用通常有超时设计你放一个跑两小时的 ETL 进去Agent 等不起体验会很差。第三类是高度依赖长会话历史的流程Skill 更适合处理“拿到几个参数就能独立完成”的任务如果它每一步都要回顾前面二十轮对话那拆成 Skill 的收益就很低。一句话总结Skill 的边界就是“可复用的标准动作”。超过这个边界要么回归纯模型推理要么该上真正的 Agent 编排。4. 从 0 到 1 动手写一个 Skill完整实操4.1 准备阶段定义场景、输入和输出我拿一个具体的例子带你完整过一遍这来自我自己做过的一个数据分析项目“周报数据汇总 Skill”。使用场景是每周运营同学都会问同样的问题本周各渠道转化率怎么样和上周比变化大不大之前我用 Agent 直接回答模型每次都要现场查数据SQL 写得还不稳定一会儿格式错一会儿字段名对不上。动手之前我先做三件事。第一确定触发场景哪些话术会触发这个 Skill比如“本周转化率”“渠道对比”“环比变化”这类关键词都要覆盖。第二定义输入参数我定四个字段渠道名称可选默认全部、周起始日期、周结束日期、对比周起始日期可选默认上一周。第三定义输出格式要求返回包含渠道名、本周转化率、上周转化率、环比变化百分比的表格以及一段自动生成的总结。这一步看起来简单但非常关键。参数定义不清晰后续 Agent 抽取就会出错输出格式不明确结果就不可控。4.2 编写描述文件和核心脚本描述文件是给模型看的所以它必须是“模型友好型”的。我的 SKILL.md 大概长这样# 周报数据汇总 ## 功能 根据数据库中的用户行为数据计算并对比指定业务渠道本周与上周的转化率输出汇总表格和环比变化。 ## 触发场景 用户询问本周/本周期各渠道转化率、环比变化、数据波动原因分析等场景。 ## 输入参数 - channel: 渠道名称可选如 ios、android、h5 - week_start: 周起始日期格式 YYYY-MM-DD - week_end: 周结束日期格式 YYYY-MM-DD - compare_start: 对比起始日期可选 ## 执行流程 1. 解析用户需求把自然语言中的时间词换算成具体日期。 2. 调用 data_query.py传入参数。 3. 将返回值整理为表格文本。 ## 预期输出 渠道名、本周转化率、上周转化率、环比变化百分比以及一句总结。核心脚本 data_query.py 做的事情也简单读入参数、连数据库、跑一条带日期过滤的 SQL、把结果聚合成环比字段、输出 JSON。我贴一个简化版本供你参考import sys import json import datetime import sqlite3 def main(): params json.loads(sys.argv[1]) week_start params.get(week_start) week_end params.get(week_end) compare_start params.get(compare_start) channel params.get(channel) conn sqlite3.connect(analytics.db) cur conn.cursor() sql SELECT channel, COUNT(DISTINCT user_id) AS users, SUM(converted) AS conversions FROM events WHERE date BETWEEN ? AND ? args [week_start, week_end] if channel: sql AND channel ? args.append(channel) sql GROUP BY channel cur.execute(sql, args) this_week cur.fetchall() # 计算环比并输出 result [] for row in this_week: channel_name, users, conversions row conversion_rate round(conversions / users * 100, 2) if users else 0 result.append({ channel: channel_name, this_week_rate: conversion_rate, last_week_rate: 0.0, change_percent: 0.0 }) print(json.dumps({code: 0, data: result}, ensure_asciiFalse)) if __name__ __main__: main()实际项目里环比的计算会用另一段 SQL 查上一周期的数据再做差值百分比这里为了演示只保留了主流程。脚本写完之后要单独在命令行里跑一次确认入参、出参都对再交给模型去接。4.3 本地测试与回归调试写完一定要测试而且不要只在理想环境下测。我会自己扮演一个“说不清楚话的用户”输入“帮我看看这周 h5 怎么样了”看 Agent 能不能自动把“这周”换算成具体日期、能不能从“h5”这个缩写里识别出渠道名。测试时我会盯三个指标。第一是命中率连续测试 10 次看 Skill 被调用了几次低于 7 次就要考虑改写描述。第二是参数抽取正确率日期算对没渠道名映射对没这是最容易出错的一环。第三是输出稳定性同一份数据跑三次结果是不是一致。如果模型拿到结果后重新组织了语言导致表达不一致我会考虑让 Skill 的输出走固定模板把变量控制在数据本身而不是措辞。4.4 发布与管理版本、权限、命名Skill 的管理其实和代码仓库的管理很像。我给自己定了三条纪律。第一每个 Skill 都要有版本号脚本变更要记录 changelog。别觉得小题大做等你哪天改了逻辑老版本的效果对比不出来的时候就知道版本号有多重要了。第二上线前做一次“最小权限检查”Skill 里的脚本只能访问它完成任务所需的资源绝不给它任意路径的读写权限。第三命名用“动词 对象”的结构比如“查询订单”“生成周报”“分析日志”别用“数据分析助手”这种模糊的名字模型分不清你自己过两周也忘了它干嘛的。5. 高频问题与避坑指南5.1 我的 Skill 为什么总是不被调用这个问题我被问过太多次了排查思路我整理成了一个优先级列表。第一查描述。描述里如果全是笼统的能力介绍没有明确的触发场景模型就会“想不起来”。触发场景怎么写直接写用户会说的话比如“当用户问『为什么今天的销售收入下降了』时使用本技能”。这叫给模型一个锚点。第二查参数。参数定义不清晰模型不确定自己能不能满足输入要求就不会冒险调用。比如你要求必须传 device_id但用户只说“看下 Android 的数据”模型不知道从 Android 怎么映射到具体 ID可能就选择自己硬答。好的做法是给参数加默认值或者在描述里写明映射规则。第三查权限和挂载。有些平台的 Skill 需要显式启用或者对某些模型版本不可用。确认你的 Skill 在当前会话里真的挂载成功而不是写在配置文件里却没有被加载。5.2 Skill 越写越多管理不过来怎么办Skill 数量起来之后最尴尬的是“自己都不记得写了什么”。我现在的习惯是每加一个 Skill 就在索引文件里登记名称、用途、负责人、最近一次修改时间、依赖项。这个索引文件本身也做成一个 Skill专门回答“我有哪些能力可用”这个问题。这样当 Agent 的任务涉及多个技能时它可以通过索引做一次预筛选而不是挨个试。另外要定期清理。我一般每两个月做一次 review把三个月没被调用过的 Skill 标记为待定再放一个月没有调用就直接下线。别舍不得Skill 是工具不是收藏品。留着大量无人调用的 Skill只会增加每次意图匹配的干扰项反而降低命中率。5.3 社区里的优秀 Skill 都在解决什么问题从最近社区里流行的一些 Skill 方向能看出大家的真实痛点。有人做写代码相关的 Skill有人做 PPT 生成、日志分析、测试用例生成还有人做“去 AI 味的 Skill”专门把模型生成的文本改写得更像真人。这个“去 AI 味”听起来很玄其实也是标准动作的固化。拆掉“首先其次最后”这类连词打乱排比句式插入口语化表达这些规则写成 Skill 脚本后执行逻辑非常清晰。我试过几个效果立竿见影比在 Prompt 里说一百遍“请写得自然一点”都管用因为规则一旦固化成代码模型就没有发挥空间了输出自然稳定。这给了我们一个信号Skill 的疆界正在快速扩展从纯编程领域走向写作、设计、数据分析、电商运营等岗位。未来哪个岗位能把自己的高频重复工作抽象成 Skill谁就能在工具使用上领先别人一截。5.4 如何判断一个公开的 Skill 值不值得用最后聊一下怎么下载和使用别人的 Skill毕竟社区里公开的 Skill 越来越多但不是每个都值得往项目里引。我的判断标准是四条一看描述是否清晰描述写得乱的直接 pass二看依赖是否简单一个日志分析 Skill 如果要求你装好几个重量级依赖维护成本太高不如自己写个轻量的三看是否有测试示例能用一句真实用户话术展示输入输出的通常质量更高四看维护活跃度一个 Skill 半年没更新过的多半早已和最新接口脱节了。把公开 Skill 引入项目之后不要直接上线先在自己环境里跑一遍样例确认输出符合预期。我踩过不少次坑有的 Skill 看起来功能很全但脚本里藏着硬编码路径换个环境就崩溃。所有外部代码都要当作第三方依赖来对待先审查再使用。写完这一章我心里其实挺感慨的。Skill 这个概念乍一看很简单但真正理解它的人并不多。它解决的是“可复用、需稳定”的那部分问题不是让你把所有东西都技能化。我自己踩过的最大一个坑就是一上来把什么都封装成 Skill结果维护成本比收益还高。后来学会了先问自己三个问题这个动作我一个月会触发几次它出错我能接受吗它的输入输出能定义清楚吗三个都是肯定答案再动手封装。就拿今天这个周报 Skill 来说从前期的场景梳理、参数定义到描述文件、脚本编写再到测试和上线整套流程走下来你对 Agent 的工作方式会有完全不一样的理解。下一章我准备讲 Skill 的进阶设计包括多 Skill 协作、Skill 内部的错误处理与重试机制以及从个人 Skill 走向团队共享 Skill 的工程化经验。如果你正在用 Skill或者正准备入坑建议先照这篇文章把手头最重复的那个小动作封装起来试试跑通一个你就会理解它到底给工具使用体验带来了多大改变。
