最近一段时间我身边的开发者圈子几乎被“Skill”这个词刷屏了。从Claude Code到Codex再到Trae这类集成开发环境更新日志里高频出现Skills功能社区里铺天盖地都是“skill推荐”“skill creator”“某某场景skill下载”热搜里甚至出现了“skill和agent的区别”这种直击灵魂的问题。我最初接触这个概念时也踩了不少弯路子以为它不过是提示词模板换了个名字直到实际把几个Skill部署进工作流才意识到这背后是一套全新的协作范式。这篇是整个“Skill 从入门到精通”系列的第一章我先不着急讲怎么安装、怎么写、怎么发布而是把最基础也最重要的事情说清楚Skill到底是什么它解决什么问题以及它在AI Agent内部是怎么工作的。如果你已经在用AI编程工具或Agent类产品但被“要不要用Skill”“什么时候用Skill”卡住这篇就是给你准备的。我会用跟同行聊天的方式把原理掰开揉碎讲然后带你拆一个真实的日志分析Skill。1. 先搞清楚一件事此Skill非彼Skill——AI圈的Skill到底指什么1.1 从Allegro脚本到Claude Code的Skill同名背后的三条技术脉络“Skill”这个词最大的坑在于同名概念太多。很多读者第一次搜“skill”的时候看到的结果五花八门——有“allegro skill”这种Cadence PCB设计工具的脚本语言有“数学建模skill”这种竞赛经验分享还有“PPT skill”“科研skill”这种泛职场技能总结。这些全都叫Skill但底层逻辑完全不同。我把目前在技术圈流窜的“Skill”分成了三条脉络特定领域脚本语言典型代表是Cadence Allegro的Skill语言。它是EDA电子设计自动化领域的一种解释型脚本语言用来扩展PCB设计软件的功能比如自动布局、批量修改封装。这类Skill本质上是一种遗留技术生态里的“宏脚本”和AI没有直接关系但因为它出现得早很多老工程师一听到Skill就会联想到这个。通用能力方法论比如“PPT skill”“科研skill”指的是一套可传授、可复用的做事情的方法属于知识管理范畴。AI Agent的Skill这条脉络是2024年底到2025年才火起来的。以Anthropic提出的Agent Skills为代表它把“提示词脚本参考文档工作流程”打包成一个结构化的文件目录让AI Agent能够在对话中按需加载、自主执行。Claude Code的Skill、Codex的Skill、Trae的Skill都是这条技术路线上的产物。第三条脉络才是本系列讨论的重点。但理解前两条脉络很重要因为它们在潜移默化中塑造了人们对“Skill”的期待有人希望它是能改系统代码的脚本有人希望它是能指导AI干活的说明书而AI Agent时代的Skill恰好同时吸收了这两者——它既有能力描述和行动指令又可以有可执行脚本最终变成一个“自带说明书的工具包”。1.2 为什么2025年前后Skill突然成了Agent圈的热词Skill并不是在2025年凭空出现的。在它之前AI圈已经经历过好几轮“套壳”运动先是提示词工程追求写出一段神奇的话让模型输出变好然后是RAG把外部知识塞进上下文再然后是Function Calling和Tool Use让模型可以调用外部工具。每一步都在解决同一个问题大模型长得再聪明它也是个“没有手、没有记忆、没有工作手册”的实习生。等到Agent的概念成熟之后问题就变了Agent是那个能自己拆任务、自己决定调用什么工具的“项目经理”但项目经理接到一个需求后靠什么来知道“我们团队处理日志分析有一套标准流程”靠什么知道“线上故障排查时要先看什么、再做什么”靠什么知道“每类错误码对应什么处理动作”答案就是Skill。Skill热的底层原因可以归结为三点可复用知识的封装需求、上下文的可控消费需求、行为结果的可预期需求。前两个我后面详细讲先说说行为可预期这点。纯靠提示词交互的时候同一个需求每次得到的处理路径可能千差万别模型今天按这个思路走明天可能换个思路这对需要稳定交付的工程场景是灾难。Skill通过把一套固定方法论固化下来把“不确定性”压缩到最小。这里也回应一个很多人的困惑为什么现在的Agent框架都在推Skill而不是继续优化System Prompt因为System Prompt是给Agent的“人格设定”不能无限膨胀而Skill是按需加载的“能力模块”只有在任务相关时才注入上下文。一个Agent可以拥有几十个Skill但一次对话中往往只需要激活两三个这样既不会把模型上下文撑爆又不会让指令之间互相干扰。2. Skills工作原理拆解Agent如何发现、加载并执行一个Skill2.1 Skill的最小可用结构描述、触发条件与执行体要理解Skill的工作原理先要从文件结构说起。目前主流Agent框架里的Skill虽然具体细节不同但核心范式高度一致。一个Skill通常就是一个目录里面至少包含一个SKILL.md文件这个文件是Skill的入口也是灵魂。SKILL.md里的关键字段有三个nameSkill的唯一标识相当于函数名。description描述这个Skill是干什么的、什么时候该用。这是Agent做“语义匹配”时的核心依据。instructions具体的执行指令相当于给Agent的操作手册通常分为多个步骤告诉Agent先做什么、再做什么、依据什么判断、最终输出什么格式。除了SKILL.md之外一个完整的Skill还可以有scripts/目录存放可执行脚本references/目录存放参考文档assets/目录存放模板或静态资源。我画个直观一点的结构感下面这个就是我在本地实测过的最简日志分析Skill目录log-analyzer/ ├── SKILL.md ├── scripts/ │ └── parse_log.py └── references/ └── common_error_codes.md很多人第一次看到这个结构就明白了这不就是个“带说明书的小项目”吗对可以这么理解。但关键在于SKILL.md不是给人看的而是给Agent看的人机接口。它的内容质量直接决定了Agent能不能正确选择并执行这个Skill。description字段尤为关键。它就像是Skill的“电梯演讲”Agent不会打开每个Skill细读它只扫描所有Skill的description然后判断当前任务和哪个Skill最匹配。因此description必须写明“什么时候用”和“解决什么问题”而不是夸功能强大。2.2 从“人肉复制提示词”到“Agent自主调度”一次完整的Skill调用链路当你向一个接入了Skill机制的Agent发出任务时背后实际发生了一整套可复现的调度流程。我以Claude Code这类命令行工具为例拆一遍第一步用户发出任务比如“帮我分析一下今天线上API服务的错误日志”。此时Agent先做意图识别它判断出这是一个日志分析类任务。第二步Agent扫描当前环境中可用的Skill列表。在Claude Code中它会去检查配置的Skills目录在Codex中也有类似的机制。这个扫描不是把所有Skill全文读入而是只读取每个Skill的description和name。第三步语义匹配。Agent根据任务描述和每个Skill的description计算相关度选中匹配度最高的一个或多个Skill。如果没有任何Skill匹配Agent就退回普通对话模式。第四步加载SKILL.md全文。被选中的Skill的SKILL.md内容注入当前上下文Agent开始“看到”这个Skill的使用说明。第五步按instructions执行。SKILL.md里的指令会引导Agent做一系列操作先读日志、识别格式、用parse_log.py脚本抽取结构化字段、对照common_error_codes.md给错误分层、最后用指定格式输出分析报告。第六步Agent在执行过程中可以按需调用scripts/下的脚本工具比如让Python脚本去解析日志文件然后把脚本输出拿回来继续推理。这一步和普通Tool调用是相同的机制。第七步输出最终结果并且在总结中说明自己使用了哪个Skill、得出了什么结论。很多好的Skill会要求Agent在回答末尾附上“分析链路摘要”方便人复核。这个链路最妙的是第二步到第四步Agent自主发现、按需加载。它意味着Skill不需要常驻上下文而是作为“可插拔模块”存在。这也解释了为什么Skill被设计成目录Markdown的形式而不是一段粗暴拼进System Prompt的话——它要兼顾“机器可索引”与“模型可理解”。2.3 Skill的上下文窗口策略为什么省Token成了刚需我上面提到了“按需加载”这个词背后藏着Skill设计里最实际的一个考量上下文窗口和Token成本。现在的大模型上下文窗口虽然越来越长——从4K到16K、128K、200K甚至1M——但长上下文不等于无限上下文。上下文越长推理延迟越高成本越贵而且模型在超长上下文里的注意力会分散容易出现“中间遗忘”的现象。把几十个Skill的全文都塞进上下文是不现实的。Skill的设计哲学是“懒加载”平时只占一个索引条目需要时才把正文捞进来。这种策略和操作系统里的内存分页思路很像——不把整个程序加载进内存而是用到了哪页才调入哪页。以我实际测试的经验来说一个包含10个Skill的Agent环境如果全部常驻上下文可能要消耗上万Token但采用按需加载之后普通对话时只占几百Token真正激活某个Skill时才会增加2K到5K Token的负载。对需要长期运行、大量交互的项目来说这个差距非常明显。另外省Token不只是省钱的问题更是为了给核心任务留出推理空间。比如一个数学建模任务中间过程可能要写大量公式推导、做数据可视化上下文空间本来就紧张如果还背上几个无关Skill的沉重包袱模型更容易在关键步骤上“偷工减料”。Skill的按需加载机制让模型能把有限的上下文资源集中花在刀刃上。3. Skill的亲戚们与Prompt、Tool、Agent、Workflow的边界到底在哪3.1 Skill与Prompt封装粒度不同先用最简单的说法Skill不是Prompt的替代品而是Prompt的容器。如果Prompt是一张菜谱写清楚了食材和步骤那么Skill就是“一个密封好的料理包”里面除了菜谱还有你需要的特殊厨具使用说明、常见老厨师经验笔记甚至还有预先称好的秘制调料包——也就是脚本和参考文档。传统提示词工程里把一段精心设计的方法论复制粘贴给大模型这段方法论能指导模型完成一次不错的任务。但Prompt有几个天然缺陷一是太长之后挤压上下文二是无法携带可执行代码三是无法进行独立版本管理。你很难对一个写在对话里的Prompt做单元测试、做diff、做回滚。Skill恰好补齐了这些短板。一个Skill的instructions部分可以写得比普通Prompt详细得多因为它只在需要时加载它还可以携带脚本让模型不仅能“想”还能“算”而且因为它本质上是文件系统里的目录天然支持Git版本管理、支持分享和复用。还有一个实操中的显著差异Prompt是用户准备好的而Skill是Agent自己主动选的。用户写Prompt是“你按我说的做”Skill机制是“你觉得这个任务该用什么方法就自己选一个合适的方法包”。前者依赖用户的经验后者把选择权部分交给了Agent。这也是为什么我会把Skill理解为“把经验工程化”的产物。3.2 Skill与Tool执行边界不同如果说Prompt让模型“会想”Tool让模型“能动手”那Skill就是“知道什么时候该想、什么时候该动、想完怎么动”的统筹层。Tool在Agent体系里通常指一个可执行的最小单元比如一个函数、一个API接口、一个Shell命令。它接受输入、返回输出模型决定是否调用它。当前主流的Function Calling机制和MCP模型上下文协议都是在解决工具接入的问题。Skill和Tool的边界在于Tool是被调用的Skill是指导怎么调用Tool的。一个Skill内部可以引用多个Tool也可以只靠instructions指导模型做思考和输出不调用任何外部工具。以日志分析Skill为例scripts/parse_log.py是Tool而SKILL.md是决定“什么时候调用这个脚本、脚本输出之后怎么继续分析”的Skill。所以界限很清楚工具回答“能做什么”Skill回答“怎么把一件事从头做到尾”。3.3 Skill与Agent从属关系与组合方式这是我在搜索里看到最频繁的一个问题“skill和agent的区别”。很多人把这两个概念混在一起可能是因为它们经常同时出现。我打个比方Agent是一个厨师Skill是厨师的拿手菜谱和配套工具包。厨师可以自主决定今天做什么菜、用什么菜谱、火候怎么控制——这是Agent的任务编排和决策能力菜谱和工具包让厨师能在具体任务上做得标准化——这是Skill提供的领域能力。Agent是“运行主体”它拥有对话能力、推理能力、任务循环能力、工具调度能力Skill本身没有自主权它是一套静态的规则和资源只有被Agent选中并使用时才产生作用。一个Agent可以持有很多Skill一个Skill也可以同时服务于多个Agent。在工程实践中这种从属关系很重要。你给Agent配置再多的SkillAgent本身的“判断力”不行Skill就发挥不出来反过来Agent很聪明但没有合适的Skill每次都要临场发挥稳定性就差。所以当你在社区看到“agent skill”这种组合词时它指的是“Agent可用的技能包”而不是Agent本身。留意一个反直觉的点Skill减少了Agent的自主性但这恰恰是它提升系统稳定性的原因。普通Agent接一个任务怎么做全凭模型当时的心情挂上Skill之后Agent的行为被“限定”在Skill定义的路线里。对于追求可复制、可交付结果的工程场景这种“受约束的Agent”反而更可靠。3.4 Skill与Workflow流程与技能的差异Workflow工作流这个词在自动化领域也有悠久历史。传统Workflow工具里节点和连线是提前定义好的数据沿固定路径流动分支条件也由人预先设定。比如一个数据管道可能是“读取→清洗→建模→展示”每一步都是固定的。Skill和Workflow的区别在于弹性空间。Workflow是刚性流程把步骤全部定死适合流程稳定、输入输出结构化的场景。Skill则更像一本“作战手册”它给出推荐的步骤和方法但允许Agent在执行中根据实际情况调整。Skill里的instructions是“指导原则”不是“铁律”。两者也可以嵌套使用一个Skill的内部可以包含一个固定流程的Workflow脚本一个大型Workflow的某个节点也可以调用一个Skill来完成任务。我在实践中的感受是工程型任务多多少少都要有Workflow把控而到需要“临场发挥”的知识型任务时Skill比Workflow更贴切。4. 实例解剖手拆一个“日志分析Skill”看内部设计4.1 为什么选日志分析作为解剖样本讲了一堆原理还是落地看看更直观。日志分析是社区里最常见的Skill场景之一热搜词里也有“日志分析skill”因为绝大多数开发者每天都在和日志打交道对这个场景的需求有体感。日志分析任务的典型特征是需求描述简单“看看今天为什么报错”但实际执行链路长步骤杂且极度依赖经验。传统做法是把经验写成长长的提示词每次粘贴或者写死一套脚本但遇到格式变化就抓瞎。这两种痛点正好都是Skill的用武之地。下面这个例子不是某个商业产品的完整代码而是我自己根据多个开源日志分析Skill的共性设计出的简化模板我把它的核心文件内部结构拆开讲帮助理解上面的工作原理。4.2 SKILL.md、scripts、references三层结构逐段解读先看SKILL.md的开头部分也就是Agent扫描阶段能看到的元信息--- name: log-analyzer description: 当用户需要分析应用日志、排查线上故障、统计错误码出现频率、定位异常原因时使用。适合处理文本格式日志、JSON格式日志和常见Web服务器访问日志。 --- # 日志分析技能 ## 使用场景 - 线上服务出现大量报错需要定位根因 - 日志量过大需要做聚合统计和趋势分析 - 需要区分已知错误和未知错误并评估影响范围 ## 执行步骤 1. 先确认日志格式调用 scripts/parse_log.py 识别并解析。 2. 按时间窗口聚合日志统计每类错误码的出现次数。 3. 对照 references/common_error_codes.md标记已知错误和处理建议。 4. 对于未知错误提取特征前缀、堆栈关键字和触发条件。 5. 输出结构化报告包含时间范围、总日志量、错误分布、Top 5错误详情、疑似根因、建议动作。这个description写得就比较规范它包含两个关键元素——触发动词分析日志、排查故障和目标对象应用日志、访问日志。Agent在语义匹配时靠这些实体词和动词就能建立相关性判断。再看scripts/parse_log.py。这个脚本解决的是“模型对异构日志格式的解析能力不足”的问题。模型虽然能读懂日志但当日志量达到几万行时让模型逐行读完不现实还可能超出上下文窗口。脚本的作用就是用确定性代码先做粗加工把日志变成结构化摘要再把摘要交给模型做后续推理。references/common_error_codes.md就是领域知识库了。它记录了这个团队已经遇到过的错误码、对应的处理流程、曾经踩过的坑。这部分内容不是每轮都要加载而是模型在第三步需要判定“已知错误”时才去查询。这种“不把所有参考文档一次性塞入而是按步骤按需读取”的设计在好Skill里非常常见。4.3 这个Skill在什么场景下会失灵拆一个Skill不能只看它好的一面还得知道它在什么场景下会坏。我在真实使用中遇到过几种失灵情况一是日志格式过于罕见parse_log.py解析失败返回了一堆无意义数据。这种情况下模型如果缺乏兜底逻辑就会开始“硬编”——照着不完整的数据强行编造结论。所以设计良好的日志分析Skill执行步骤里首要一条是“识别不出格式时先抽取原始日志片段做人工格式标注而不是直接放弃或乱猜”。二是日志量超过上下文窗口。虽然脚本已经做了聚合但当某个时间窗口内报错类型特别多、聚合结果依然很长时仍有超限风险。实操中的对策是分时段多次调用Skill分段分析再合并结论。三是description写得不够精准导致误触发。比如一个做“安全日志分析”的Skill和一个做“业务日志分析”的Skilldescription重叠度很高Agent可能选错。过度追求大而全的description反而会稀释匹配精度。5. 使用Skills的四个实战心法以及第一章自检清单5.1 心法一description的精修优先级高于instructions很多Skill作者花大力气写instructions的执行细节却草草写description这是舍本逐末。Agent能不能选中你的Skill完全不看instructions只看description。如果description写得模糊Agent在多个Skill间犹豫最后可能选了一个风马牛不相及的。我用一个判断标准把description读给自己听如果在十秒内能说出“这个Skill适用于什么场景、解决什么问题”那就是合格的。用“动词具体对象触发条件”的句式描述比形容词堆砌有效得多。5.2 心法二避免“一次性规则”污染Skill库我见过有人把一次性的小任务也封装成Skill比如“写一份关于本周团队周报的会议纪要”。这种一次性规则做成常驻Skill既占用了索引空间还会在Agent做语义匹配时产生噪声——它看到什么都觉得相关度尚可结果很多任务都被带偏了。判断一个内容适不适合做成Skill的标准很简单这个任务未来是否还会遇到是不是有一套可复用的方法论如果答案是“基本是重复劳动”那才值得封装如果只是处理一次特定事项直接在对话里说就够了。5.3 心法三不仅看结果还要看Agent的执行轨迹用带Skill机制的工具时别只关心最终输出对不对还要留意Agent选了哪个Skill、按什么顺序调用了哪些脚本。比如Claude Code和Codex的会话输出里会显示Skill的加载记录看到这些信息可以反过来校准description——如果Agent总在正确任务里选了其他Skill说明你的description表达方式和Agent的语义空间存在偏差需要调整措辞。5.4 心法四让Skill自带“已知限制”说明设计Skill时主动写明“这个Skill不适用于什么情况”能有效减少误用。比如日志分析Skill里写明“不支持二进制日志”数学建模Skill里写明“不适用于需要实时数据接入的预测任务”。这个“反向过滤”策略看似是在劝退实际上让Agent在低相关场景下更快排除这个选项提升匹配准确率。5.5 第一章自检清单学完这一章你可以拿下面几个问题自测一下。如果都能清晰回答说明基础已经扎实进入第二章学安装和创作时会更顺手能解释AI Agent语境下的Skill与Allegro脚本类Skill有什么区别。能说出SKILL.md三个核心字段是什么以及为什么description在Agent选择时最重要。能画出Agent调用一个Skill的完整链路说清楚按需加载发生在哪一步。能区分Skill与Prompt、Tool、Agent、Workflow的边界至少各给出一个不可混用的场景。能判断什么样的任务适合封装成Skill什么样的任务不适合。我自己在一路摸索下来最深的体会是Skill这件事本质上不是给AI加功能的而是逼迫人把脑海中那些“只可意会不可言传”的经验硬生生文档化、流程化、工具化。这个过程一开始会难受因为你会发现自己很多所谓的经验其实是模糊的、残缺的写作Skill的过程中会不断被自己问倒。但这个“被问倒”的过程恰恰是成长的开始。等你真正把一个Skill打磨到“Agent照着做就能稳定交付”的程度你就拥有了一个可以不断复制和扩展的数字化能力资产。这也是为什么我愿意认真写这个系列——Skill真正的杠杆不在模型而在把人类经验翻译成结构化指令的能力上。第一章就到这里后续我会继续深入Skill的具体创作方法、调试技巧以及不同平台Claude Code、Codex、Trae等的实现差异。 
长河君 · 2026/9/8 21:15:59 · 阅读 1.2k AI Agent的Skill是什么？一文讲透Skill原理、与Prompt/Tool/Agent的边界
最近一段时间我身边的开发者圈子几乎被“Skill”这个词刷屏了。从Claude Code到Codex再到Trae这类集成开发环境更新日志里高频出现Skills功能社区里铺天盖地都是“skill推荐”“skill creator”“某某场景skill下载”热搜里甚至出现了“skill和agent的区别”这种直击灵魂的问题。我最初接触这个概念时也踩了不少弯路子以为它不过是提示词模板换了个名字直到实际把几个Skill部署进工作流才意识到这背后是一套全新的协作范式。这篇是整个“Skill 从入门到精通”系列的第一章我先不着急讲怎么安装、怎么写、怎么发布而是把最基础也最重要的事情说清楚Skill到底是什么它解决什么问题以及它在AI Agent内部是怎么工作的。如果你已经在用AI编程工具或Agent类产品但被“要不要用Skill”“什么时候用Skill”卡住这篇就是给你准备的。我会用跟同行聊天的方式把原理掰开揉碎讲然后带你拆一个真实的日志分析Skill。1. 先搞清楚一件事此Skill非彼Skill——AI圈的Skill到底指什么1.1 从Allegro脚本到Claude Code的Skill同名背后的三条技术脉络“Skill”这个词最大的坑在于同名概念太多。很多读者第一次搜“skill”的时候看到的结果五花八门——有“allegro skill”这种Cadence PCB设计工具的脚本语言有“数学建模skill”这种竞赛经验分享还有“PPT skill”“科研skill”这种泛职场技能总结。这些全都叫Skill但底层逻辑完全不同。我把目前在技术圈流窜的“Skill”分成了三条脉络特定领域脚本语言典型代表是Cadence Allegro的Skill语言。它是EDA电子设计自动化领域的一种解释型脚本语言用来扩展PCB设计软件的功能比如自动布局、批量修改封装。这类Skill本质上是一种遗留技术生态里的“宏脚本”和AI没有直接关系但因为它出现得早很多老工程师一听到Skill就会联想到这个。通用能力方法论比如“PPT skill”“科研skill”指的是一套可传授、可复用的做事情的方法属于知识管理范畴。AI Agent的Skill这条脉络是2024年底到2025年才火起来的。以Anthropic提出的Agent Skills为代表它把“提示词脚本参考文档工作流程”打包成一个结构化的文件目录让AI Agent能够在对话中按需加载、自主执行。Claude Code的Skill、Codex的Skill、Trae的Skill都是这条技术路线上的产物。第三条脉络才是本系列讨论的重点。但理解前两条脉络很重要因为它们在潜移默化中塑造了人们对“Skill”的期待有人希望它是能改系统代码的脚本有人希望它是能指导AI干活的说明书而AI Agent时代的Skill恰好同时吸收了这两者——它既有能力描述和行动指令又可以有可执行脚本最终变成一个“自带说明书的工具包”。1.2 为什么2025年前后Skill突然成了Agent圈的热词Skill并不是在2025年凭空出现的。在它之前AI圈已经经历过好几轮“套壳”运动先是提示词工程追求写出一段神奇的话让模型输出变好然后是RAG把外部知识塞进上下文再然后是Function Calling和Tool Use让模型可以调用外部工具。每一步都在解决同一个问题大模型长得再聪明它也是个“没有手、没有记忆、没有工作手册”的实习生。等到Agent的概念成熟之后问题就变了Agent是那个能自己拆任务、自己决定调用什么工具的“项目经理”但项目经理接到一个需求后靠什么来知道“我们团队处理日志分析有一套标准流程”靠什么知道“线上故障排查时要先看什么、再做什么”靠什么知道“每类错误码对应什么处理动作”答案就是Skill。Skill热的底层原因可以归结为三点可复用知识的封装需求、上下文的可控消费需求、行为结果的可预期需求。前两个我后面详细讲先说说行为可预期这点。纯靠提示词交互的时候同一个需求每次得到的处理路径可能千差万别模型今天按这个思路走明天可能换个思路这对需要稳定交付的工程场景是灾难。Skill通过把一套固定方法论固化下来把“不确定性”压缩到最小。这里也回应一个很多人的困惑为什么现在的Agent框架都在推Skill而不是继续优化System Prompt因为System Prompt是给Agent的“人格设定”不能无限膨胀而Skill是按需加载的“能力模块”只有在任务相关时才注入上下文。一个Agent可以拥有几十个Skill但一次对话中往往只需要激活两三个这样既不会把模型上下文撑爆又不会让指令之间互相干扰。2. Skills工作原理拆解Agent如何发现、加载并执行一个Skill2.1 Skill的最小可用结构描述、触发条件与执行体要理解Skill的工作原理先要从文件结构说起。目前主流Agent框架里的Skill虽然具体细节不同但核心范式高度一致。一个Skill通常就是一个目录里面至少包含一个SKILL.md文件这个文件是Skill的入口也是灵魂。SKILL.md里的关键字段有三个nameSkill的唯一标识相当于函数名。description描述这个Skill是干什么的、什么时候该用。这是Agent做“语义匹配”时的核心依据。instructions具体的执行指令相当于给Agent的操作手册通常分为多个步骤告诉Agent先做什么、再做什么、依据什么判断、最终输出什么格式。除了SKILL.md之外一个完整的Skill还可以有scripts/目录存放可执行脚本references/目录存放参考文档assets/目录存放模板或静态资源。我画个直观一点的结构感下面这个就是我在本地实测过的最简日志分析Skill目录log-analyzer/ ├── SKILL.md ├── scripts/ │ └── parse_log.py └── references/ └── common_error_codes.md很多人第一次看到这个结构就明白了这不就是个“带说明书的小项目”吗对可以这么理解。但关键在于SKILL.md不是给人看的而是给Agent看的人机接口。它的内容质量直接决定了Agent能不能正确选择并执行这个Skill。description字段尤为关键。它就像是Skill的“电梯演讲”Agent不会打开每个Skill细读它只扫描所有Skill的description然后判断当前任务和哪个Skill最匹配。因此description必须写明“什么时候用”和“解决什么问题”而不是夸功能强大。2.2 从“人肉复制提示词”到“Agent自主调度”一次完整的Skill调用链路当你向一个接入了Skill机制的Agent发出任务时背后实际发生了一整套可复现的调度流程。我以Claude Code这类命令行工具为例拆一遍第一步用户发出任务比如“帮我分析一下今天线上API服务的错误日志”。此时Agent先做意图识别它判断出这是一个日志分析类任务。第二步Agent扫描当前环境中可用的Skill列表。在Claude Code中它会去检查配置的Skills目录在Codex中也有类似的机制。这个扫描不是把所有Skill全文读入而是只读取每个Skill的description和name。第三步语义匹配。Agent根据任务描述和每个Skill的description计算相关度选中匹配度最高的一个或多个Skill。如果没有任何Skill匹配Agent就退回普通对话模式。第四步加载SKILL.md全文。被选中的Skill的SKILL.md内容注入当前上下文Agent开始“看到”这个Skill的使用说明。第五步按instructions执行。SKILL.md里的指令会引导Agent做一系列操作先读日志、识别格式、用parse_log.py脚本抽取结构化字段、对照common_error_codes.md给错误分层、最后用指定格式输出分析报告。第六步Agent在执行过程中可以按需调用scripts/下的脚本工具比如让Python脚本去解析日志文件然后把脚本输出拿回来继续推理。这一步和普通Tool调用是相同的机制。第七步输出最终结果并且在总结中说明自己使用了哪个Skill、得出了什么结论。很多好的Skill会要求Agent在回答末尾附上“分析链路摘要”方便人复核。这个链路最妙的是第二步到第四步Agent自主发现、按需加载。它意味着Skill不需要常驻上下文而是作为“可插拔模块”存在。这也解释了为什么Skill被设计成目录Markdown的形式而不是一段粗暴拼进System Prompt的话——它要兼顾“机器可索引”与“模型可理解”。2.3 Skill的上下文窗口策略为什么省Token成了刚需我上面提到了“按需加载”这个词背后藏着Skill设计里最实际的一个考量上下文窗口和Token成本。现在的大模型上下文窗口虽然越来越长——从4K到16K、128K、200K甚至1M——但长上下文不等于无限上下文。上下文越长推理延迟越高成本越贵而且模型在超长上下文里的注意力会分散容易出现“中间遗忘”的现象。把几十个Skill的全文都塞进上下文是不现实的。Skill的设计哲学是“懒加载”平时只占一个索引条目需要时才把正文捞进来。这种策略和操作系统里的内存分页思路很像——不把整个程序加载进内存而是用到了哪页才调入哪页。以我实际测试的经验来说一个包含10个Skill的Agent环境如果全部常驻上下文可能要消耗上万Token但采用按需加载之后普通对话时只占几百Token真正激活某个Skill时才会增加2K到5K Token的负载。对需要长期运行、大量交互的项目来说这个差距非常明显。另外省Token不只是省钱的问题更是为了给核心任务留出推理空间。比如一个数学建模任务中间过程可能要写大量公式推导、做数据可视化上下文空间本来就紧张如果还背上几个无关Skill的沉重包袱模型更容易在关键步骤上“偷工减料”。Skill的按需加载机制让模型能把有限的上下文资源集中花在刀刃上。3. Skill的亲戚们与Prompt、Tool、Agent、Workflow的边界到底在哪3.1 Skill与Prompt封装粒度不同先用最简单的说法Skill不是Prompt的替代品而是Prompt的容器。如果Prompt是一张菜谱写清楚了食材和步骤那么Skill就是“一个密封好的料理包”里面除了菜谱还有你需要的特殊厨具使用说明、常见老厨师经验笔记甚至还有预先称好的秘制调料包——也就是脚本和参考文档。传统提示词工程里把一段精心设计的方法论复制粘贴给大模型这段方法论能指导模型完成一次不错的任务。但Prompt有几个天然缺陷一是太长之后挤压上下文二是无法携带可执行代码三是无法进行独立版本管理。你很难对一个写在对话里的Prompt做单元测试、做diff、做回滚。Skill恰好补齐了这些短板。一个Skill的instructions部分可以写得比普通Prompt详细得多因为它只在需要时加载它还可以携带脚本让模型不仅能“想”还能“算”而且因为它本质上是文件系统里的目录天然支持Git版本管理、支持分享和复用。还有一个实操中的显著差异Prompt是用户准备好的而Skill是Agent自己主动选的。用户写Prompt是“你按我说的做”Skill机制是“你觉得这个任务该用什么方法就自己选一个合适的方法包”。前者依赖用户的经验后者把选择权部分交给了Agent。这也是为什么我会把Skill理解为“把经验工程化”的产物。3.2 Skill与Tool执行边界不同如果说Prompt让模型“会想”Tool让模型“能动手”那Skill就是“知道什么时候该想、什么时候该动、想完怎么动”的统筹层。Tool在Agent体系里通常指一个可执行的最小单元比如一个函数、一个API接口、一个Shell命令。它接受输入、返回输出模型决定是否调用它。当前主流的Function Calling机制和MCP模型上下文协议都是在解决工具接入的问题。Skill和Tool的边界在于Tool是被调用的Skill是指导怎么调用Tool的。一个Skill内部可以引用多个Tool也可以只靠instructions指导模型做思考和输出不调用任何外部工具。以日志分析Skill为例scripts/parse_log.py是Tool而SKILL.md是决定“什么时候调用这个脚本、脚本输出之后怎么继续分析”的Skill。所以界限很清楚工具回答“能做什么”Skill回答“怎么把一件事从头做到尾”。3.3 Skill与Agent从属关系与组合方式这是我在搜索里看到最频繁的一个问题“skill和agent的区别”。很多人把这两个概念混在一起可能是因为它们经常同时出现。我打个比方Agent是一个厨师Skill是厨师的拿手菜谱和配套工具包。厨师可以自主决定今天做什么菜、用什么菜谱、火候怎么控制——这是Agent的任务编排和决策能力菜谱和工具包让厨师能在具体任务上做得标准化——这是Skill提供的领域能力。Agent是“运行主体”它拥有对话能力、推理能力、任务循环能力、工具调度能力Skill本身没有自主权它是一套静态的规则和资源只有被Agent选中并使用时才产生作用。一个Agent可以持有很多Skill一个Skill也可以同时服务于多个Agent。在工程实践中这种从属关系很重要。你给Agent配置再多的SkillAgent本身的“判断力”不行Skill就发挥不出来反过来Agent很聪明但没有合适的Skill每次都要临场发挥稳定性就差。所以当你在社区看到“agent skill”这种组合词时它指的是“Agent可用的技能包”而不是Agent本身。留意一个反直觉的点Skill减少了Agent的自主性但这恰恰是它提升系统稳定性的原因。普通Agent接一个任务怎么做全凭模型当时的心情挂上Skill之后Agent的行为被“限定”在Skill定义的路线里。对于追求可复制、可交付结果的工程场景这种“受约束的Agent”反而更可靠。3.4 Skill与Workflow流程与技能的差异Workflow工作流这个词在自动化领域也有悠久历史。传统Workflow工具里节点和连线是提前定义好的数据沿固定路径流动分支条件也由人预先设定。比如一个数据管道可能是“读取→清洗→建模→展示”每一步都是固定的。Skill和Workflow的区别在于弹性空间。Workflow是刚性流程把步骤全部定死适合流程稳定、输入输出结构化的场景。Skill则更像一本“作战手册”它给出推荐的步骤和方法但允许Agent在执行中根据实际情况调整。Skill里的instructions是“指导原则”不是“铁律”。两者也可以嵌套使用一个Skill的内部可以包含一个固定流程的Workflow脚本一个大型Workflow的某个节点也可以调用一个Skill来完成任务。我在实践中的感受是工程型任务多多少少都要有Workflow把控而到需要“临场发挥”的知识型任务时Skill比Workflow更贴切。4. 实例解剖手拆一个“日志分析Skill”看内部设计4.1 为什么选日志分析作为解剖样本讲了一堆原理还是落地看看更直观。日志分析是社区里最常见的Skill场景之一热搜词里也有“日志分析skill”因为绝大多数开发者每天都在和日志打交道对这个场景的需求有体感。日志分析任务的典型特征是需求描述简单“看看今天为什么报错”但实际执行链路长步骤杂且极度依赖经验。传统做法是把经验写成长长的提示词每次粘贴或者写死一套脚本但遇到格式变化就抓瞎。这两种痛点正好都是Skill的用武之地。下面这个例子不是某个商业产品的完整代码而是我自己根据多个开源日志分析Skill的共性设计出的简化模板我把它的核心文件内部结构拆开讲帮助理解上面的工作原理。4.2 SKILL.md、scripts、references三层结构逐段解读先看SKILL.md的开头部分也就是Agent扫描阶段能看到的元信息--- name: log-analyzer description: 当用户需要分析应用日志、排查线上故障、统计错误码出现频率、定位异常原因时使用。适合处理文本格式日志、JSON格式日志和常见Web服务器访问日志。 --- # 日志分析技能 ## 使用场景 - 线上服务出现大量报错需要定位根因 - 日志量过大需要做聚合统计和趋势分析 - 需要区分已知错误和未知错误并评估影响范围 ## 执行步骤 1. 先确认日志格式调用 scripts/parse_log.py 识别并解析。 2. 按时间窗口聚合日志统计每类错误码的出现次数。 3. 对照 references/common_error_codes.md标记已知错误和处理建议。 4. 对于未知错误提取特征前缀、堆栈关键字和触发条件。 5. 输出结构化报告包含时间范围、总日志量、错误分布、Top 5错误详情、疑似根因、建议动作。这个description写得就比较规范它包含两个关键元素——触发动词分析日志、排查故障和目标对象应用日志、访问日志。Agent在语义匹配时靠这些实体词和动词就能建立相关性判断。再看scripts/parse_log.py。这个脚本解决的是“模型对异构日志格式的解析能力不足”的问题。模型虽然能读懂日志但当日志量达到几万行时让模型逐行读完不现实还可能超出上下文窗口。脚本的作用就是用确定性代码先做粗加工把日志变成结构化摘要再把摘要交给模型做后续推理。references/common_error_codes.md就是领域知识库了。它记录了这个团队已经遇到过的错误码、对应的处理流程、曾经踩过的坑。这部分内容不是每轮都要加载而是模型在第三步需要判定“已知错误”时才去查询。这种“不把所有参考文档一次性塞入而是按步骤按需读取”的设计在好Skill里非常常见。4.3 这个Skill在什么场景下会失灵拆一个Skill不能只看它好的一面还得知道它在什么场景下会坏。我在真实使用中遇到过几种失灵情况一是日志格式过于罕见parse_log.py解析失败返回了一堆无意义数据。这种情况下模型如果缺乏兜底逻辑就会开始“硬编”——照着不完整的数据强行编造结论。所以设计良好的日志分析Skill执行步骤里首要一条是“识别不出格式时先抽取原始日志片段做人工格式标注而不是直接放弃或乱猜”。二是日志量超过上下文窗口。虽然脚本已经做了聚合但当某个时间窗口内报错类型特别多、聚合结果依然很长时仍有超限风险。实操中的对策是分时段多次调用Skill分段分析再合并结论。三是description写得不够精准导致误触发。比如一个做“安全日志分析”的Skill和一个做“业务日志分析”的Skilldescription重叠度很高Agent可能选错。过度追求大而全的description反而会稀释匹配精度。5. 使用Skills的四个实战心法以及第一章自检清单5.1 心法一description的精修优先级高于instructions很多Skill作者花大力气写instructions的执行细节却草草写description这是舍本逐末。Agent能不能选中你的Skill完全不看instructions只看description。如果description写得模糊Agent在多个Skill间犹豫最后可能选了一个风马牛不相及的。我用一个判断标准把description读给自己听如果在十秒内能说出“这个Skill适用于什么场景、解决什么问题”那就是合格的。用“动词具体对象触发条件”的句式描述比形容词堆砌有效得多。5.2 心法二避免“一次性规则”污染Skill库我见过有人把一次性的小任务也封装成Skill比如“写一份关于本周团队周报的会议纪要”。这种一次性规则做成常驻Skill既占用了索引空间还会在Agent做语义匹配时产生噪声——它看到什么都觉得相关度尚可结果很多任务都被带偏了。判断一个内容适不适合做成Skill的标准很简单这个任务未来是否还会遇到是不是有一套可复用的方法论如果答案是“基本是重复劳动”那才值得封装如果只是处理一次特定事项直接在对话里说就够了。5.3 心法三不仅看结果还要看Agent的执行轨迹用带Skill机制的工具时别只关心最终输出对不对还要留意Agent选了哪个Skill、按什么顺序调用了哪些脚本。比如Claude Code和Codex的会话输出里会显示Skill的加载记录看到这些信息可以反过来校准description——如果Agent总在正确任务里选了其他Skill说明你的description表达方式和Agent的语义空间存在偏差需要调整措辞。5.4 心法四让Skill自带“已知限制”说明设计Skill时主动写明“这个Skill不适用于什么情况”能有效减少误用。比如日志分析Skill里写明“不支持二进制日志”数学建模Skill里写明“不适用于需要实时数据接入的预测任务”。这个“反向过滤”策略看似是在劝退实际上让Agent在低相关场景下更快排除这个选项提升匹配准确率。5.5 第一章自检清单学完这一章你可以拿下面几个问题自测一下。如果都能清晰回答说明基础已经扎实进入第二章学安装和创作时会更顺手能解释AI Agent语境下的Skill与Allegro脚本类Skill有什么区别。能说出SKILL.md三个核心字段是什么以及为什么description在Agent选择时最重要。能画出Agent调用一个Skill的完整链路说清楚按需加载发生在哪一步。能区分Skill与Prompt、Tool、Agent、Workflow的边界至少各给出一个不可混用的场景。能判断什么样的任务适合封装成Skill什么样的任务不适合。我自己在一路摸索下来最深的体会是Skill这件事本质上不是给AI加功能的而是逼迫人把脑海中那些“只可意会不可言传”的经验硬生生文档化、流程化、工具化。这个过程一开始会难受因为你会发现自己很多所谓的经验其实是模糊的、残缺的写作Skill的过程中会不断被自己问倒。但这个“被问倒”的过程恰恰是成长的开始。等你真正把一个Skill打磨到“Agent照着做就能稳定交付”的程度你就拥有了一个可以不断复制和扩展的数字化能力资产。这也是为什么我愿意认真写这个系列——Skill真正的杠杆不在模型而在把人类经验翻译成结构化指令的能力上。第一章就到这里后续我会继续深入Skill的具体创作方法、调试技巧以及不同平台Claude Code、Codex、Trae等的实现差异。