1. 从skills这个模糊词说起它到底指什么第一次看到skills这个标题加上一堆热搜词里混着 Agent Skills、Google Cloud、GKE、Genkit、codex skills、claude agent skills 这些词我脑子里第一反应是这大概率不是在讲人类技能提升那套东西而是在讲智能体能力扩展机制——也就是给 AI Agent 挂载可复用能力模块的那套体系。为什么这么判断因为热搜词里出现了agent skills测试agent tool agent skillsskills开发skills安装包下载skills下载平台有哪些这类明显带工程属性的词。如果是讲人类软技能不会有人问安装包下载和下载平台有哪些。这些词暴露了真实需求大家想找的是怎么给 Agent 装技能、去哪找现成的技能包、怎么自己写一个技能。所以这篇内容我按Agent Skills 能力扩展体系来写。它解决的问题很具体一个通用大模型或者一个 Agent 框架默认能力是有限的你不可能指望它天生就会查你公司的数据库、会按你团队的规范写周报、会调用你内部那套部署流程。Skills 就是把这些具体场景下的具体做法封装成可插拔的模块让 Agent 在需要的时候加载进来用。适合谁看三类人一是刚接触 Agent 开发、被skills这个词绕晕的新手二是已经在用某个 Agent 平台、想搞清楚技能加载机制的中级开发者三是想自己写技能包、做内部工具沉淀的团队技术负责人。不管你是哪类核心逻辑是通的——技能的本质是把隐性经验变成显性可调用单元。我先把一个容易混淆的点讲清楚Skills 和 Tools工具不是一回事。Tools 通常指单个函数调用比如查天气是一个 tool而 Skills 往往是一组能力知识流程的打包比如处理客户退款这个 skill里面可能包含查订单、判断退款条件、生成退款单、发通知这一串动作还附带什么情况下不能退的规则知识。热搜词里agent tool agent skills把这两个词放一起说明很多人在这上面犯迷糊。提示如果你只想要一个函数调用写 Tool如果你要沉淀一套遇到这类事该怎么做的完整经验写 Skill。选错了会导致后期维护成本翻倍。2. Agent Skills 的加载机制为什么安装这个词很关键热搜里反复出现安装下载平台安装包这其实点出了 Skills 体系最核心的一个设计技能是可分发、可安装的。这跟传统写死在代码里的功能有本质区别。传统做法是你要给程序加个功能改代码、重新部署。Skills 的做法是技能以独立包的形式存在Agent 运行时按需加载。这带来三个直接好处。第一解耦——技能作者和 Agent 开发者可以是两拨人前者懂业务后者懂框架。第二复用——一个写好的周报生成技能全公司所有 Agent 都能装。第三热更新——改技能不用动主程序。那安装到底装了什么拆开看一个 Skill 包通常包含这几样东西元数据manifest技能名、版本、描述、触发条件。这是 Agent 判断什么时候该用这个技能的依据。指令/提示词instructions告诉模型这个技能该怎么执行步骤是什么注意什么。资源文件resources可能包含模板、参考文档、示例数据。可执行代码可选需要真正调外部接口时挂的脚本或函数。我实测下来最容易出问题的就是元数据里的触发条件。写得太宽Agent 动不动就加载这个技能浪费上下文还容易误触发写得太窄该用的时候用不上。这个度怎么把握后面第 4 节会专门讲。再说下载平台。热搜问skills下载平台有哪些说明生态里已经出现了技能市场/仓库的概念。这类平台的价值在于发现和信任——你能搜到别人写的技能也能看到它被多少人用过、评分如何。但我要泼盆冷水现成技能包不能拿来就用。原因很简单技能里往往嵌了作者自己的假设比如假设你的数据格式是某种结构换个环境就崩。正确姿势是下载 → 读源码 → 改适配 → 再装。注意安装第三方技能包前务必检查它有没有可执行代码、代码里访问了什么外部地址。技能包本质上是能影响 Agent 行为的配置代码来源不明的包风险很高。3. 从零写一个 Skill我踩过的四个坑光讲概念没意思直接上我写第一个 Skill 的完整过程。当时的需求是让 Agent 能按我们团队的规范把一堆零散的 commit 记录整理成一份周报。3.1 坑一把技能写成了万能提示词我第一版写得很随意大意是你是一个周报助手请根据 commit 记录生成周报。结果 Agent 每次输出的格式都不一样有时候用表格有时候用列表有时候还自己加评论。问题出在哪我把 Skill 当成了提示词而不是流程规范。正确的写法是把怎么做拆成明确步骤并且把输出格式用模板固定死。改完之后大概是这样# 周报生成技能 ## 触发条件 当用户提供 commit 记录并要求生成周报时启用。 ## 执行步骤 1. 按类型归类 commitfeat / fix / refactor / docs / chore 2. 每类内部按模块聚合合并同类项 3. 忽略 chore 类中纯格式调整的条目 4. 按下方模板输出不得增删章节 ## 输出模板 ### 本周完成 - [模块] 具体事项 ### 进行中 - [模块] 具体事项 ### 风险与阻塞 - 无 / 具体描述这个改动带来的差别是巨大的。技能的价值不在于告诉模型要做什么而在于把模糊要求变成确定性流程。这也是为什么热搜里有人问codex写论文的skills——写论文这种任务如果没有技能把流程固化模型每次发挥都不一样。3.2 坑二触发条件写得太宽第二版上线后我发现 Agent 在用户只是随口提一句这周干了啥的时候也会加载周报技能然后强行输出一份格式化的周报显得很生硬。这就是触发条件太宽。我的修正思路是触发条件要同时满足意图和输入形态两个维度。光有意图不够还得看用户是不是真的给了 commit 记录这类结构化输入。改完之后误触发率明显下降。这里有个经验触发条件宁可稍微严一点也不要太宽。因为漏触发的时候用户可以手动指定用周报技能但误触发会污染正常对话体验更差。3.3 坑三技能之间互相打架写到第三个技能的时候出问题了。我有个代码审查技能和一个提交信息规范技能两者都会在用户提交代码相关内容时触发结果 Agent 有时候两个都加载输出里一半在讲审查意见一半在讲提交格式很乱。解决办法是给技能加优先级和互斥声明。在元数据里标明本技能与 X 技能互斥同时命中时优先本技能。这个机制不是所有平台都原生支持如果不支持就得在技能描述里用自然语言写清楚边界。3.4 坑四忘了处理技能执行失败最隐蔽的坑。技能执行到一半比如要调一个外部接口拿数据接口挂了Agent 会怎么办我第一版没写失败处理结果 Agent 要么卡住要么编造数据往下走。这是最危险的——编造数据比报错严重得多。后来我在每个技能里都加了一段异常处理## 异常处理 - 若数据获取失败明确告知用户XX 数据获取失败不得编造 - 若输入格式不符合预期列出期望格式并请用户补充 - 任何情况下不得跳过步骤 2 直接输出结果这四条坑踩下来我最大的体会是写 Skill 的难度不在于技术而在于把你自己脑子里那套理所当然的流程完整地、无歧义地写出来。你以为的常识模型不知道。4. 技能触发条件的调优一个可复现的排查链路触发条件这块值得单独拎出来讲因为它是最容易出问题、又最难排查的部分。我把自己调优的过程完整还原一遍你可以照着复现。4.1 先建立该触发/不该触发的测试集别凭感觉调。我建了一个小测试集大概 20 条输入分成四类类别说明期望行为正例-明确明确要求用该技能必须触发正例-隐含意图明确但没点名技能应该触发负例-相似话题相关但不需要该技能不应触发负例-无关完全无关不应触发这个表看着简单但它是排查的基础。没有它你改完触发条件根本不知道是变好了还是变坏了。4.2 逐条跑记录误触发和漏触发跑完 20 条把不符合预期的挑出来。我当时的分布是正例-隐含漏触发 3 条负例-相似误触发 4 条。这两类问题的修法完全相反——漏触发要放宽误触发要收紧所以必须分开处理。4.3 漏触发补充同义表达而不是放宽阈值漏触发的时候新手容易直接把触发条件写得很泛。正确做法是枚举用户可能的各种说法。比如生成周报这个意图用户可能说整理一下这周的活写个周总结汇总下 commit。把这些同义表达补进触发条件比放宽整体阈值精准得多。4.4 误触发加排除条件误触发往往是因为话题相关。比如用户说这个 commit 信息写得不好话题是 commit但意图是评价不是生成周报。这时候要加排除条件当用户意图是评价、询问、讨论而非生成时不触发。4.5 回归测试确认没有按下葫芦浮起瓢改完再跑一遍全部 20 条。我遇到过改了漏触发结果误触发变多的情况所以每次改动都要全量回归不能只看你改的那几条。这套流程跑下来我的技能触发准确率从大概 70% 提到了 90% 以上。剩下的 10% 大多是边界情况靠用户手动指定技能来兜底就够了。提示测试集要持续维护。每次发现线上有新的误触发/漏触发案例就补一条进测试集这样你的技能会越用越准。5. 技能生态里的现实问题下载、版本与安全热搜里skills下载平台有哪些skills安装包下载skills大全这些词反映的是大家对现成技能的渴求。但生态早期坑比机会多。我把几个现实问题摊开讲。5.1 现成技能包的水土不服我下载过几个社区技能包直接装上去能用的不到一半。原因集中在两点一是依赖外部服务技能里写死了某个 API 地址你环境里没有就废了二是假设了特定数据格式作者的输入格式和你的不一样。所以我的习惯是下载的技能包先当参考实现读不当成品用。读它的结构、它的触发条件写法、它的异常处理然后按自己环境重写。这样既学到了别人的思路又避免了适配的坑。5.2 版本管理技能也会过期技能不是写完就完了。你的业务变了、模型升级了、依赖的接口改了技能都得跟着更新。我建议给技能也做版本号并且在元数据里写清楚适配的模型版本/框架版本。更麻烦的是技能之间的版本依赖。A 技能依赖 B 技能的输出格式B 技能一升级改了格式A 就崩了。这个问题在技能数量少的时候不明显一旦超过十个就会集中爆发。我的做法是把技能间的接口输入输出格式单独文档化改接口必须同步改文档并通知所有依赖方。5.3 安全技能是能改 Agent 行为的东西这点必须强调。技能包里的指令会直接影响 Agent 的行为可执行代码更是能访问外部资源。所以来源不明的技能包先读全部内容再决定装不装带可执行代码的技能检查它访问了哪些地址、读了哪些文件涉及敏感操作的技能比如能改数据库、能发消息加人工确认环节我见过有人图省事直接装了个来路不明的技能结果那个技能里嵌了把用户输入转发到某地址的指令。虽然最后没造成实际损失但想想就后怕。5.4 别迷信技能大全热搜里skills大全这种词很诱人好像装一堆技能 Agent 就无所不能了。实际上技能不是越多越好。技能多了触发冲突的概率上升上下文占用增加Agent 反而变笨。我的经验是一个 Agent 常驻技能控制在 5 到 8 个其余按需加载。常用的精雕细琢不常用的做成可选。6. 把技能用出价值三个我验证过的场景讲完机制和坑最后落到这东西到底能干嘛。我分享三个自己跑通、并且确实省了时间的场景。6.1 场景一把团队规范变成技能每个团队都有一堆不成文的规矩提交信息怎么写、代码怎么审、文档放哪。这些规矩以前靠口口相传新人上手慢。我把它们写成了技能Agent 在相关场景自动加载相当于给每个新人配了个随身老员工。这个场景的价值在于把隐性知识显性化而且是一次投入长期受益。6.2 场景二把重复的分析流程固化我经常要做一类分析拉数据、清洗、按几个维度看、出结论。以前每次都要重新跟模型描述一遍流程还经常漏步骤。写成技能后一句话触发流程固定输出格式统一。这类流程固定但每次数据不同的任务是技能的最佳适用场景。6.3 场景三给 Agent 加领域知识通用模型对垂直领域往往一知半解。我把某个领域的术语表、常见问题、判断规则打包成技能Agent 在处理相关问题时加载回答质量明显提升。这比每次在对话里贴一堆背景资料高效得多。这三个场景有个共同点都是重复发生 有固定套路 需要特定知识的任务。反过来一次性的、高度依赖临场判断的任务写技能反而累赘。6.4 一个反直觉的体会我一开始以为技能写得越详细越好后来发现过度详细的技能反而限制模型的发挥。有些步骤模型本来能自己处理好你写死了它反而不会变通了。所以我现在写技能的原则是流程和格式写死具体执行留活口。该确定的确定该灵活的灵活这个度得靠实践找。7. 关于技能开发我最后想说的几句实在话技能这套东西说到底是把人的经验翻译成机器能执行的规范。翻译得好Agent 就像个靠谱的助手翻译得差就是个添乱的。我做了这么久最深的体会是写技能的时间八成花在想清楚流程上两成花在写下来上。如果你发现自己写技能很快但效果不好多半是流程本身就没想清楚。另外别被热搜里那些花哨的词带偏。superpower skills自动挖洞skills听着很酷但技能的核心永远是解决一个具体的、重复出现的问题。从你手头最烦的那件重复劳动开始写第一个技能比研究一百个概念都有用。至于生态现在确实还早下载平台、版本管理、安全审核这些都不成熟。但这也意味着现在入场的人有机会定义标准。如果你所在的团队有大量重复的 Agent 使用场景早点把技能体系搭起来后面会省很多事。我个人的建议是先别追求技能大全先把你最高频的那个场景做成一个能稳定触发的技能跑通写-装-调-用整个闭环。这个闭环跑通了剩下的都是复制粘贴加微调。技能这东西用起来比学起来重要得多。