过去三个月我几乎把所有业余时间都砸进了 Agent Skill 的调教里。起因很直接团队里的智能体每次跑完复杂任务后我都会翻它的执行日志。整理会议纪要给参会者发邮件这种需求它第一遍跑了 23 步第二遍缩到 14 步第三遍因为提问措辞变化又绕了个大弯。模型本身不笨差的是沉淀机制——每次这次做对了什么都没有被留下来。Skill 这个概念恰好在这个节骨眼上进入了我的工作流。再往后Claude Code 的 SKILL.md、Codex 的 skill 体系、社区的 Skill Creator、各种 agent skill 分享站一下把技能这个词推成了 Agent 圈的高频词。随之而来的问题也很有意思Skill 能自己变强吗如果能它是靠轨迹归纳变强还是靠文本空间优化变强这篇文章我会结合自己做技能系统、维护技能库、踩了一堆坑之后的理解把这条进化路径拆开讲清楚。1. Skill 突然成为底座它解决的其实是一个记忆与复用问题1.1 从 Prompt 到 Skill跨越的是可组合性Prompt 是一段给模型的指令但它本质上是一次性的。一个写得再好的 Prompt换一个任务场景、换一套上下文往往就要重写。Skill 试图解决的问题比提示技巧更底层能不能把模型在执行任务过程中积累的最佳路径、边界条件、错误处理方式打包成一个可以被再次调用的资产我在本地维护过一个小型 Prompt 集合最开始只有五六个后来膨胀到四五十个。再后来我自己都分不清哪个 Prompt 适用于哪个场景。把这个教训说穿了就是把提示词做成了文件但没有做结构化它本质上依然是一堆文本。Skill 的差别在于它多了三层结构元信息层名字、描述、适用条件、不适用条件这层决定了什么时候该调用它。主体层操作步骤、判断规则、代码片段、禁止事项这层决定了它执行时怎么干活。配套层脚本、示例、测试用例、资源文件这层决定了它能不能被验证和迭代。有了这三层Agent 才能在运行阶段对技能做语义检索和自动选择而不是靠人从四五十个 Prompt 文件里手动想起来该用哪一个。很多做 Agent 的同行一开始都觉得 skill 无非是个 Markdown 文件写几条指令进去就行。但用一段时间后就会发现真正需要被沉淀的不是那几句提示而是这条技能在什么场景下被调用、执行时需要哪些判断、失败了该怎么回退这一整套轨迹。1.2 技能生态爆发背后的信号Agent 在向技能经济演进这个词可能听着有点大但你看一下最近的社区动态几乎每个主流 Agent 框架都在搞自己的技能体系分享站里挤满了各类 skill 包数学建模 skill、日志分析 skill、测试用例 skill、PPT skill、drawio 流程图 skill、browser skill甚至有人拿去 AI 味的 skill来改文案。大家开始像沉淀代码库一样沉淀技能文件这本身就是一个明显的风向标Agent 应用不再满足于现场发挥而是转向预演加复用。从我接触到的团队来看凡是 Agent 落地效果不稳定的几乎都有一个通病——没有沉淀技能的机制。用户每次提问模型都从零开始规划执行链路完成得快慢完全取决于当次上下文和模型心情。而沉淀了技能库的团队任务执行一次比一次平滑因为每一步都被提前打磨过。技能经济这个词听着遥远但你只把它当成执行资产的复用市场来理解就能看清楚它为什么重要。2. 轨迹归纳让技能从别人写好的规则变成自己长出来的能力2.1 轨迹归纳的四步采样、切片、抽象、收敛轨迹归纳简单说就是让 Agent 从自己的执行日志中总结规律。完整流程可以拆成四步采样收集同一类任务的执行轨迹成功和失败的都要越多越好。切片把一次完整执行切成一连串状态转移比如输入是什么 → 模型判读 → 调用哪个工具 → 拿到什么结果 → 下一步决策。抽象把切片中跟具体数据强绑定的部分替换成变量把重复劳动高度相关的部分提炼成固定步骤。收敛把多条轨迹合并成一份稳定的操作流程同时保留异常分支的处理方式。有一段时间我在做一个日志分析类 Agent。最开始完全没有 skill它只能靠模型现场发挥去读日志、找关键词、输出报告。结果同一个问题今天这么查、明天那么查关键信息经常漏。后来我把二十多条成功轨迹拉出来做切片发现它们其实稳定地走同一条路先按时间窗口切分日志再按错误级别过滤然后把高频错误摘要最后生成 Markdown 报告。我把这个流程抽象成带两个输入参数error_keywords、time_window的 skill 文件之后每次调用几乎都是同一套动作反而再也没漏过关键结果。2.2 什么时候值得归纳什么时候不值得这是我从拼命写技能到克制写技能转变的拐点。归纳轨迹是有成本的采样、清洗、抽象、验证都要时间如果一条技能只是为了少写两句话完全不值得。我给自己定了一个经验线同类型任务在真实场景中重复出现 3 次以上才值得去做轨迹归纳。次数低于 3 次用一次性提示词更划算。反过来如果一条轨迹已经反复出现却没有被沉淀成技能那就是在慢性浪费每一次调用的 token 和稳定性。这是我见过最多的隐性浪费团队天天骂模型不稳定却没人把稳定出现的成功轨迹提炼成技能。2.3 从真实日志中提炼技能的手工实践实践层面我强烈建议至少手工归纳一次完整的技能不要一上来就搞全自动。具体做法是把 Agent 的运行日志导出标出成功的几段和失败的几段逐段写注释。你要特别留意三种情况哪一步本来可以更快完成但模型绕了远路。哪一步是模型随机应变恰好蒙对的。哪一步靠人兜底才成功模型自己根本不会。这些注释就是抽象的最佳素材。我当时用的工具一点也不高级一个日志目录加一个表格文件。表格里每行是一条轨迹列分别是任务描述、关键步骤、工具调用、失败点、最终结果。归纳完成后再把表格内容转写成 SKILL.md 正文。说实话这种方式很笨但它能让你对轨迹归纳这四个字产生真正的体感后面做自动化时心里才有底。3. 文本空间优化技能的命中率比数量更重要3.1 为什么文本空间优化会成为第二个关键步骤一个很反直觉的事实当技能数量超过 20 个之后Agent 选错技能的概率会明显上升。这不是模型变笨了而是技能的查找方式出了问题。大部分人维护技能的方式是全文塞进系统提示词或者靠文件名猜技能一多上下文装不下猜也猜不准。文本空间优化就是把技能从纯文本文件变成一段可被语义检索的文本向量让 Agent 在执行任务前先根据当前用户的指令判断最相关的技能只把命中的那几条加载进上下文。这一步看似不起眼实际上决定了一个技能库能不能规模化。我见过不少团队有几百个技能文件但使用率不到一成核心原因就是检索做得太差。3.2 技能描述、Embedding 选取和检索策略文本空间优化操心的核心是三件事一是描述要对齐用户语言。很多 skill 描述写得太内部比如提供数据分析聚合算法模型库但用户在真实场景里说的是帮我算一下这个活动的转化率两者在向量空间里距离很远检索自然命中不了。我在写每个技能描述时会强制要求自己至少写出三种常见提问方式然后让 LLM 把描述扩展成一段自然语言再进 embedding。二是 Embedding 模型要稳定。我踩过的一个坑是前期用通用中文向量模型后期换了多语言模型却没有重新嵌入技能库导致部分技能检索效果飘忽。后来我把嵌入模型固定写进技能库配置每次更新技能后统一重嵌入一遍。这个细节看起来小埋下的雷却非常大。三是混合检索比纯向量更稳。技能库本质上是长尾分布热门技能靠向量召回就够了冷门技能往往需要稀疏检索比如 BM25靠关键词捞回来。我现在用的方案是向量召回和关键词召回各取一批结果再做加权融合实测比单靠向量好不少。3.3 一个结合测试用例技能的真实例子我之前整理过一个测试用例生成 skill一开始的描述只有一句话根据需求生成测试用例。这个描述太泛导致每次用户问帮我查一下这个 bug或分析一下模块覆盖率它都会冒出来抢占上下文。后来我把描述改成了带触发条件的版本当用户提供功能需求、接口文档或变更日志并期望输出可执行的测试用例时使用不适用于缺陷复现与覆盖率分析。同时在元信息里把 when_not_to_use 也写清楚。文本空间优化不是玄学本质上就是把技能的语义边界摆正让它待在应该待的角落需要时能被找到不需要时不要出来捣乱。4. 自己变强的三个层次版本迭代、自动蒸馏、运行时反馈4.1 第一个层次人在回路上的手工迭代大部分技能变强靠的是人工复盘加改写。每次技能在真实场景里翻车我都会把失败日志找出来对比技能文件里写的内容看是某一步指令不够明确还是分支条件覆盖不全然后手动更新版本号。这个层次虽然朴素但最稳因为每一步都有人的判断兜底。对个人开发者和小团队来说这个阶段已经能解决 80% 的问题。4.2 第二个层次用 LLM 做技能蒸馏和自动合并当轨迹样本足够多以后可以把归纳这件事交给 LLM 来做。我试过的一种做法是把最近 50 条成功轨迹的关键片段发给一个大模型让它提取共性、生成新版本的技能内容再由人工只做一次审核。这样做有个明显的好处模型能发现人眼容易忽略的隐性模式比如某些工具调用顺序的成功率更高。但这里有个必须说清楚的陷阱自动蒸馏出来的技能往往过度泛化或者把某次特定场景的偶然成功当成普遍规律。所以我的经验是自动蒸馏只负责生成草稿不能直接进入技能库必须经过一轮回归验证。4.3 第三个层次运行时反馈闭环再往前走一步就是把反馈机制直接嵌到 Agent 的运行回路里。技能每次被调用后记录调用参数、执行时长、是否成功、输出质量评分定期汇总成一份技能健康度报告。分数长期偏低的技能自动降权或进入待优化队列分数稳定偏高的技能获得更高检索权重。这样技能库就从静态文件目录变成了一个有反馈循环的动态系统。我实际搭过这个闭环之后的最大感受是自动进化仓库不是目的让每一份执行数据都被有效地流回技能仓库才是自己变强的真正含义。4.4 我的结论会变强但有明确的边界回到标题里的问题Skill 能自己变强吗我的答案是能但只能在反馈信号的约束下变强。如果没有轨迹记录没有成功的判定标准没有回归测试所谓自进化就只是一次又一次地用同样的错误方法生成新版本然后把墙撞得更响。真正的自己变强来自一套建设良好的反馈回路而不是模型本身的神秘力量。这也是我为什么在给别人分享技能经验时总要提醒一句不要迷信会自进化的 Skill这种说法要把注意力放在你让什么信号返回来指导进化上。5. 一套可落地的 Skill 生长式工作流目录、元信息与评估方案5.1 目录结构、SKILL.md 元信息和加载策略这里贴一个我目前在用的目录结构它不复杂但很适合中小型技能库skills/ 数据分析/ analytics/ SKILL.md scripts/analyze.py tests/test_analytics.md 测试用例/ case_generator/ SKILL.md examples/input_output.md 日志分析/ log_analyzer/ SKILL.md scripts/parse_logs.py每个技能目录下的 SKILL.md 我都用统一的前置元信息name技能短名必须唯一。description3 到 5 句自然语言描述覆盖常见触发问法。version语义化版本号。tags领域标签用于关键词召回。when_to_use / when_not_to_use明确适用边界。dependencies需要的模型能力或脚本依赖。加载策略上我不再把所有技能一股脑塞进上下文。Agent 启动时先加载所有技能的元信息占用很小也就是几百个 token根据用户指令做一次语义检索只把 top 3 的完整技能内容加载进去。这样的设计即使技能库涨到几百个单次任务的上下文压力也基本恒定。5.2 一套技能评估与打分方案给技能打分我一直用下面这套贴近实际效果的指标指标含义我常用的通过线检索命中率用户指令触发该技能的比例不低于 80%执行完成率技能被调用后能完整跑完的比例不低于 70%输出可用率输出结果无需人工大改的比例不低于 50%单次调用成本平均 token 消耗相对基线下降然后我会让另一个模型也可以是人给输出质量打 1 到 5 分。关键在于技能版本必须和基线做对比。基线就是不用这个技能直接让模型发挥的结果。只要技能版本比基线分数高成本还不涨才允许合入主库。这一个简单的对照实验能挡住绝大多数的烂 skill。5.3 小团队和个人开发者如何低成本跑通闭环如果只有一个人这套流程可以精简成三样东西一个 Git 仓库、一个日志目录、一个定时脚本。Git 仓库负责版本管理日志目录保存每次调用的轨迹定时脚本每天晚上把当天的轨迹做一次简单的成功率统计加失败关键词提取第二天早上由你决定要不要更新某个技能。我不建议一上来就上一套重型工作流比如把自动蒸馏、自动合并、向量库重排一次性全配齐。先手工跑两周把感觉跑出来再逐步自动化。很多人失败的起点就是把简单问题复杂化。6. 我踩过的坑Skill 整合中最容易翻车的五个地方6.1 过度抽象想覆盖所有场景的技能哪个场景都做不好我最早写过一个通用文档处理 skill想把 PDF、Word、Excel 全部包进去结果它在任何一类文档上都表现平庸还经常在应该用其他专用技能时抢占上下文。后来我把它拆成三个独立技能每个只管一类文档整体效果立刻上了一个台阶。这条教训值多少钱值一次重构的成本。现在我看到任何宣称万能的技能包都会先打个问号。真正好用的技能描述里一定写清了边界。6.2 上下文污染技能越多反而拖垮主任务技能化的失败往往不是没命中而是误命中。一个和当前任务无关的技能被检索出来加载进上下文之后模型会不自觉地把技能里那些不相关规则拿过来用导致主任务跑偏。解决办法有两个一是给每个技能写清楚 when_not_to_use二是做检索时把元信息里的边界条件也纳入过滤逻辑。6.3 描述写作陷阱检索不到的技能等于不存在我见过太多描述写得一塌糊涂的技能比如只说处理数据高冷得像什么内部接口文档。我建议写完描述后自己站在用户视角提几个真实问题然后跑一遍检索看目标技能是不是排在第一页。如果不在说明是描述的问题和技能内容本身无关需要重写。6.4 自动进化缺少护栏回归验证是技能库的底牌我在自动蒸馏上翻过最大的车是没有做回归验证就让模型生成的技能版本合入主库结果它把几个成功率较高的旧版本行为改没了连续两天线上效果下降。后来我加了一条硬性规定任何自动生成的技能版本必须先在历史轨迹集上跑一遍回归得分不低于旧版本才能合入。这条规定救了我很多次。没有护栏的自动进化本质上是拿仓库稳定性去赌模型的随机发挥。6.5 版本混乱和多 Agent 复用问题最后补一个容易忽略但非常现实的坑。技能文件一多靠文件名区分版本很快会失控。我和同事共享一个技能库时约定每个技能目录里必须带 CHANGELOG版本号严格按语义化规则递增合入前必须经过 review。否则你会发现A 改了一个技能B 的 Agent 用的是旧的缓存版本两边行为对不上排查起来非常痛苦。说到这我补一个最近的体会现在看到网上被反复转发的 skill 包我不会直接套用而是先看它有没有明确的触发条件和边界再放到自己的轨迹样本上跑一遍。原因很简单——技能的价值不在文件本身有多漂亮而在于它能不能在真实执行轨迹里被反复证明好用。技能会随反馈回路变强但前提是你愿意把反馈回路建起来。这可能是这一整套进化故事里最朴素也最关键的一步。
Agent Skill如何自己变强：从轨迹归纳到反馈闭环的进化路径
过去三个月我几乎把所有业余时间都砸进了 Agent Skill 的调教里。起因很直接团队里的智能体每次跑完复杂任务后我都会翻它的执行日志。整理会议纪要给参会者发邮件这种需求它第一遍跑了 23 步第二遍缩到 14 步第三遍因为提问措辞变化又绕了个大弯。模型本身不笨差的是沉淀机制——每次这次做对了什么都没有被留下来。Skill 这个概念恰好在这个节骨眼上进入了我的工作流。再往后Claude Code 的 SKILL.md、Codex 的 skill 体系、社区的 Skill Creator、各种 agent skill 分享站一下把技能这个词推成了 Agent 圈的高频词。随之而来的问题也很有意思Skill 能自己变强吗如果能它是靠轨迹归纳变强还是靠文本空间优化变强这篇文章我会结合自己做技能系统、维护技能库、踩了一堆坑之后的理解把这条进化路径拆开讲清楚。1. Skill 突然成为底座它解决的其实是一个记忆与复用问题1.1 从 Prompt 到 Skill跨越的是可组合性Prompt 是一段给模型的指令但它本质上是一次性的。一个写得再好的 Prompt换一个任务场景、换一套上下文往往就要重写。Skill 试图解决的问题比提示技巧更底层能不能把模型在执行任务过程中积累的最佳路径、边界条件、错误处理方式打包成一个可以被再次调用的资产我在本地维护过一个小型 Prompt 集合最开始只有五六个后来膨胀到四五十个。再后来我自己都分不清哪个 Prompt 适用于哪个场景。把这个教训说穿了就是把提示词做成了文件但没有做结构化它本质上依然是一堆文本。Skill 的差别在于它多了三层结构元信息层名字、描述、适用条件、不适用条件这层决定了什么时候该调用它。主体层操作步骤、判断规则、代码片段、禁止事项这层决定了它执行时怎么干活。配套层脚本、示例、测试用例、资源文件这层决定了它能不能被验证和迭代。有了这三层Agent 才能在运行阶段对技能做语义检索和自动选择而不是靠人从四五十个 Prompt 文件里手动想起来该用哪一个。很多做 Agent 的同行一开始都觉得 skill 无非是个 Markdown 文件写几条指令进去就行。但用一段时间后就会发现真正需要被沉淀的不是那几句提示而是这条技能在什么场景下被调用、执行时需要哪些判断、失败了该怎么回退这一整套轨迹。1.2 技能生态爆发背后的信号Agent 在向技能经济演进这个词可能听着有点大但你看一下最近的社区动态几乎每个主流 Agent 框架都在搞自己的技能体系分享站里挤满了各类 skill 包数学建模 skill、日志分析 skill、测试用例 skill、PPT skill、drawio 流程图 skill、browser skill甚至有人拿去 AI 味的 skill来改文案。大家开始像沉淀代码库一样沉淀技能文件这本身就是一个明显的风向标Agent 应用不再满足于现场发挥而是转向预演加复用。从我接触到的团队来看凡是 Agent 落地效果不稳定的几乎都有一个通病——没有沉淀技能的机制。用户每次提问模型都从零开始规划执行链路完成得快慢完全取决于当次上下文和模型心情。而沉淀了技能库的团队任务执行一次比一次平滑因为每一步都被提前打磨过。技能经济这个词听着遥远但你只把它当成执行资产的复用市场来理解就能看清楚它为什么重要。2. 轨迹归纳让技能从别人写好的规则变成自己长出来的能力2.1 轨迹归纳的四步采样、切片、抽象、收敛轨迹归纳简单说就是让 Agent 从自己的执行日志中总结规律。完整流程可以拆成四步采样收集同一类任务的执行轨迹成功和失败的都要越多越好。切片把一次完整执行切成一连串状态转移比如输入是什么 → 模型判读 → 调用哪个工具 → 拿到什么结果 → 下一步决策。抽象把切片中跟具体数据强绑定的部分替换成变量把重复劳动高度相关的部分提炼成固定步骤。收敛把多条轨迹合并成一份稳定的操作流程同时保留异常分支的处理方式。有一段时间我在做一个日志分析类 Agent。最开始完全没有 skill它只能靠模型现场发挥去读日志、找关键词、输出报告。结果同一个问题今天这么查、明天那么查关键信息经常漏。后来我把二十多条成功轨迹拉出来做切片发现它们其实稳定地走同一条路先按时间窗口切分日志再按错误级别过滤然后把高频错误摘要最后生成 Markdown 报告。我把这个流程抽象成带两个输入参数error_keywords、time_window的 skill 文件之后每次调用几乎都是同一套动作反而再也没漏过关键结果。2.2 什么时候值得归纳什么时候不值得这是我从拼命写技能到克制写技能转变的拐点。归纳轨迹是有成本的采样、清洗、抽象、验证都要时间如果一条技能只是为了少写两句话完全不值得。我给自己定了一个经验线同类型任务在真实场景中重复出现 3 次以上才值得去做轨迹归纳。次数低于 3 次用一次性提示词更划算。反过来如果一条轨迹已经反复出现却没有被沉淀成技能那就是在慢性浪费每一次调用的 token 和稳定性。这是我见过最多的隐性浪费团队天天骂模型不稳定却没人把稳定出现的成功轨迹提炼成技能。2.3 从真实日志中提炼技能的手工实践实践层面我强烈建议至少手工归纳一次完整的技能不要一上来就搞全自动。具体做法是把 Agent 的运行日志导出标出成功的几段和失败的几段逐段写注释。你要特别留意三种情况哪一步本来可以更快完成但模型绕了远路。哪一步是模型随机应变恰好蒙对的。哪一步靠人兜底才成功模型自己根本不会。这些注释就是抽象的最佳素材。我当时用的工具一点也不高级一个日志目录加一个表格文件。表格里每行是一条轨迹列分别是任务描述、关键步骤、工具调用、失败点、最终结果。归纳完成后再把表格内容转写成 SKILL.md 正文。说实话这种方式很笨但它能让你对轨迹归纳这四个字产生真正的体感后面做自动化时心里才有底。3. 文本空间优化技能的命中率比数量更重要3.1 为什么文本空间优化会成为第二个关键步骤一个很反直觉的事实当技能数量超过 20 个之后Agent 选错技能的概率会明显上升。这不是模型变笨了而是技能的查找方式出了问题。大部分人维护技能的方式是全文塞进系统提示词或者靠文件名猜技能一多上下文装不下猜也猜不准。文本空间优化就是把技能从纯文本文件变成一段可被语义检索的文本向量让 Agent 在执行任务前先根据当前用户的指令判断最相关的技能只把命中的那几条加载进上下文。这一步看似不起眼实际上决定了一个技能库能不能规模化。我见过不少团队有几百个技能文件但使用率不到一成核心原因就是检索做得太差。3.2 技能描述、Embedding 选取和检索策略文本空间优化操心的核心是三件事一是描述要对齐用户语言。很多 skill 描述写得太内部比如提供数据分析聚合算法模型库但用户在真实场景里说的是帮我算一下这个活动的转化率两者在向量空间里距离很远检索自然命中不了。我在写每个技能描述时会强制要求自己至少写出三种常见提问方式然后让 LLM 把描述扩展成一段自然语言再进 embedding。二是 Embedding 模型要稳定。我踩过的一个坑是前期用通用中文向量模型后期换了多语言模型却没有重新嵌入技能库导致部分技能检索效果飘忽。后来我把嵌入模型固定写进技能库配置每次更新技能后统一重嵌入一遍。这个细节看起来小埋下的雷却非常大。三是混合检索比纯向量更稳。技能库本质上是长尾分布热门技能靠向量召回就够了冷门技能往往需要稀疏检索比如 BM25靠关键词捞回来。我现在用的方案是向量召回和关键词召回各取一批结果再做加权融合实测比单靠向量好不少。3.3 一个结合测试用例技能的真实例子我之前整理过一个测试用例生成 skill一开始的描述只有一句话根据需求生成测试用例。这个描述太泛导致每次用户问帮我查一下这个 bug或分析一下模块覆盖率它都会冒出来抢占上下文。后来我把描述改成了带触发条件的版本当用户提供功能需求、接口文档或变更日志并期望输出可执行的测试用例时使用不适用于缺陷复现与覆盖率分析。同时在元信息里把 when_not_to_use 也写清楚。文本空间优化不是玄学本质上就是把技能的语义边界摆正让它待在应该待的角落需要时能被找到不需要时不要出来捣乱。4. 自己变强的三个层次版本迭代、自动蒸馏、运行时反馈4.1 第一个层次人在回路上的手工迭代大部分技能变强靠的是人工复盘加改写。每次技能在真实场景里翻车我都会把失败日志找出来对比技能文件里写的内容看是某一步指令不够明确还是分支条件覆盖不全然后手动更新版本号。这个层次虽然朴素但最稳因为每一步都有人的判断兜底。对个人开发者和小团队来说这个阶段已经能解决 80% 的问题。4.2 第二个层次用 LLM 做技能蒸馏和自动合并当轨迹样本足够多以后可以把归纳这件事交给 LLM 来做。我试过的一种做法是把最近 50 条成功轨迹的关键片段发给一个大模型让它提取共性、生成新版本的技能内容再由人工只做一次审核。这样做有个明显的好处模型能发现人眼容易忽略的隐性模式比如某些工具调用顺序的成功率更高。但这里有个必须说清楚的陷阱自动蒸馏出来的技能往往过度泛化或者把某次特定场景的偶然成功当成普遍规律。所以我的经验是自动蒸馏只负责生成草稿不能直接进入技能库必须经过一轮回归验证。4.3 第三个层次运行时反馈闭环再往前走一步就是把反馈机制直接嵌到 Agent 的运行回路里。技能每次被调用后记录调用参数、执行时长、是否成功、输出质量评分定期汇总成一份技能健康度报告。分数长期偏低的技能自动降权或进入待优化队列分数稳定偏高的技能获得更高检索权重。这样技能库就从静态文件目录变成了一个有反馈循环的动态系统。我实际搭过这个闭环之后的最大感受是自动进化仓库不是目的让每一份执行数据都被有效地流回技能仓库才是自己变强的真正含义。4.4 我的结论会变强但有明确的边界回到标题里的问题Skill 能自己变强吗我的答案是能但只能在反馈信号的约束下变强。如果没有轨迹记录没有成功的判定标准没有回归测试所谓自进化就只是一次又一次地用同样的错误方法生成新版本然后把墙撞得更响。真正的自己变强来自一套建设良好的反馈回路而不是模型本身的神秘力量。这也是我为什么在给别人分享技能经验时总要提醒一句不要迷信会自进化的 Skill这种说法要把注意力放在你让什么信号返回来指导进化上。5. 一套可落地的 Skill 生长式工作流目录、元信息与评估方案5.1 目录结构、SKILL.md 元信息和加载策略这里贴一个我目前在用的目录结构它不复杂但很适合中小型技能库skills/ 数据分析/ analytics/ SKILL.md scripts/analyze.py tests/test_analytics.md 测试用例/ case_generator/ SKILL.md examples/input_output.md 日志分析/ log_analyzer/ SKILL.md scripts/parse_logs.py每个技能目录下的 SKILL.md 我都用统一的前置元信息name技能短名必须唯一。description3 到 5 句自然语言描述覆盖常见触发问法。version语义化版本号。tags领域标签用于关键词召回。when_to_use / when_not_to_use明确适用边界。dependencies需要的模型能力或脚本依赖。加载策略上我不再把所有技能一股脑塞进上下文。Agent 启动时先加载所有技能的元信息占用很小也就是几百个 token根据用户指令做一次语义检索只把 top 3 的完整技能内容加载进去。这样的设计即使技能库涨到几百个单次任务的上下文压力也基本恒定。5.2 一套技能评估与打分方案给技能打分我一直用下面这套贴近实际效果的指标指标含义我常用的通过线检索命中率用户指令触发该技能的比例不低于 80%执行完成率技能被调用后能完整跑完的比例不低于 70%输出可用率输出结果无需人工大改的比例不低于 50%单次调用成本平均 token 消耗相对基线下降然后我会让另一个模型也可以是人给输出质量打 1 到 5 分。关键在于技能版本必须和基线做对比。基线就是不用这个技能直接让模型发挥的结果。只要技能版本比基线分数高成本还不涨才允许合入主库。这一个简单的对照实验能挡住绝大多数的烂 skill。5.3 小团队和个人开发者如何低成本跑通闭环如果只有一个人这套流程可以精简成三样东西一个 Git 仓库、一个日志目录、一个定时脚本。Git 仓库负责版本管理日志目录保存每次调用的轨迹定时脚本每天晚上把当天的轨迹做一次简单的成功率统计加失败关键词提取第二天早上由你决定要不要更新某个技能。我不建议一上来就上一套重型工作流比如把自动蒸馏、自动合并、向量库重排一次性全配齐。先手工跑两周把感觉跑出来再逐步自动化。很多人失败的起点就是把简单问题复杂化。6. 我踩过的坑Skill 整合中最容易翻车的五个地方6.1 过度抽象想覆盖所有场景的技能哪个场景都做不好我最早写过一个通用文档处理 skill想把 PDF、Word、Excel 全部包进去结果它在任何一类文档上都表现平庸还经常在应该用其他专用技能时抢占上下文。后来我把它拆成三个独立技能每个只管一类文档整体效果立刻上了一个台阶。这条教训值多少钱值一次重构的成本。现在我看到任何宣称万能的技能包都会先打个问号。真正好用的技能描述里一定写清了边界。6.2 上下文污染技能越多反而拖垮主任务技能化的失败往往不是没命中而是误命中。一个和当前任务无关的技能被检索出来加载进上下文之后模型会不自觉地把技能里那些不相关规则拿过来用导致主任务跑偏。解决办法有两个一是给每个技能写清楚 when_not_to_use二是做检索时把元信息里的边界条件也纳入过滤逻辑。6.3 描述写作陷阱检索不到的技能等于不存在我见过太多描述写得一塌糊涂的技能比如只说处理数据高冷得像什么内部接口文档。我建议写完描述后自己站在用户视角提几个真实问题然后跑一遍检索看目标技能是不是排在第一页。如果不在说明是描述的问题和技能内容本身无关需要重写。6.4 自动进化缺少护栏回归验证是技能库的底牌我在自动蒸馏上翻过最大的车是没有做回归验证就让模型生成的技能版本合入主库结果它把几个成功率较高的旧版本行为改没了连续两天线上效果下降。后来我加了一条硬性规定任何自动生成的技能版本必须先在历史轨迹集上跑一遍回归得分不低于旧版本才能合入。这条规定救了我很多次。没有护栏的自动进化本质上是拿仓库稳定性去赌模型的随机发挥。6.5 版本混乱和多 Agent 复用问题最后补一个容易忽略但非常现实的坑。技能文件一多靠文件名区分版本很快会失控。我和同事共享一个技能库时约定每个技能目录里必须带 CHANGELOG版本号严格按语义化规则递增合入前必须经过 review。否则你会发现A 改了一个技能B 的 Agent 用的是旧的缓存版本两边行为对不上排查起来非常痛苦。说到这我补一个最近的体会现在看到网上被反复转发的 skill 包我不会直接套用而是先看它有没有明确的触发条件和边界再放到自己的轨迹样本上跑一遍。原因很简单——技能的价值不在文件本身有多漂亮而在于它能不能在真实执行轨迹里被反复证明好用。技能会随反馈回路变强但前提是你愿意把反馈回路建起来。这可能是这一整套进化故事里最朴素也最关键的一步。
