本文深入解析微软SkillLens论文揭示如何从Agent执行日志中自动发现模式、抽取通用Skill。通过分析成功与失败轨迹SkillLens构建中间层Mode提炼可迁移行为模式并验证Skill的实际效用。文章强调实测验证的重要性并探讨SkillLens与SkillOpt的协同作用旨在帮助读者理解大模型如何从经验中学习并持续改进。上周写了一篇关于微软的 SkillOpt 学习文章主要解决「已有的 Skill 怎么越改越好」上线前用离线评测集把 seed skill 训成 best 再上线上线后靠夜间热更新跟着真实反馈持续迭代感谢兴趣同学可以前去阅读。除了 SkillOpt 论文微软还同时还发表了另一篇 Skill 相关的论文 SkillLens 主要解决「Skill 怎么从 Agent 执行经验里长出来」核心思想是从 Agent 的日常执行日志经验中自动发现模式、抽取 Skill再验证 Skill 是否真的有用。常见的实现方式就是人工把成熟业务流程整理成 SOP再让 LLM 根据 SOP 生成 Skill。这篇论文认为 Agent 在真实环境里每天执行大量任务这些执行轨迹本身有些也能抽取成一些提效且通用的 Skills 。例如一个 Agent 连续执行了 1000 个任务其中 800 个成功、200 个失败。这 1000 条轨迹里可能藏着大量值得沉淀的经验成功任务中有哪些可迁移的操作模式失败任务中有哪些应该避免的行为多条不同轨迹背后是不是存在同一个通用规律哪些经验只是单题细节哪些经验值得写进 Skill抽出来的 Skill 给 Agent 使用之后到底有没有真正提升效果一、SkillLens 解决的核心问题把整个问题简单理解成一条流水线这里有三个关键的对象对象是什么TrajectoryAgent 做过什么执行日志Mode从大量执行中总结出了什么模式可沉淀的信息Skill把这些模式写成 Agent 执行时可以照做的 Skill所以 SkillLens 实际上做了一次日常 Agent 执行的信息总结抽象论文的核心把整条链路拆成三个阶段经验生成执行出轨迹、技能提取轨迹提炼成 Skill、技能消费注入 Agent 验证效果Mode 中间层处理日志轨迹直觉上有执行轨迹了让 LLM 直接总结成 Skill 似乎顺理成章。但日常系统中 Trajectory 太细太多直接进行总结效果并不理想。假设一条处理退货订单的成功轨迹收到退货申请 → 核对订单号 → 确认在退款窗口内 → 校验商品状态 → 发起退款 → 完成直接总结会得到「收到退货先核对订单号确认在窗口内就退款」——它描述的是这一单怎么做不是这一类任务应该怎么做。真正有价值的经验是退款前先校验订单是否在退款窗口内超窗订单转人工处理不直接发起退款。所以 Trajectory 和 Skill 之间必须有一个中间层——Mode。二、Skill 的提炼过程1 第一步把执行日志统一成 Trajectory不同 Agent、不同 benchmark 的日志格式完全不同项目先把原始日志统一成标准 TrajectoryTrajectorySet 是经验池Trajectory 是一次任务执行Step 是一次交互谁说了什么、调了什么工具、环境返回了什么。统一的 schema 长这样还是那个退货订单的例子{ id: traj-20260815-042, task_name: 退货订单退款处理, agent: gpt-5.4, outcome: resolved, reward: 1.0, final_answer: 退款已发起, steps: [ {role: user, content: 处理订单 ORD-88231 的退货退款}, {role: agent, content: 先查订单核对是否在退款窗口内, tool_calls: [{name: query_order, arguments: {order_id: ORD-88231}}]}, {role: tool, content: , observation: 下单 2026-08-02退款窗口 14 天已签收在窗口内}, {role: agent, content: 在窗口内校验商品状态后发起退款, tool_calls: [{name: refund, arguments: {order_id: ORD-88231, amount: 299.0}}]}, {role: tool, content: , observation: 退款成功单号 RF-209913} ] }每个 Step 就四样东西role谁、content说了什么、tool_calls调了什么工具、observation环境返回了什么。这个结构对我们落地很有参考性——未来自己的 Agent 留痕时把日志统一落成这种格式后面 Map-Reduce 就能直接消费。其中最重要的设计是过程在steps价值信号在outcome——因为后面要按成败走不同的抽取逻辑成功轨迹 → Success Mode应该做什么 失败轨迹 → Failure Mode应该避免什么成功和失败不是同一种信息成功轨迹「先检查候选动作 → 再执行 → 成功」失败轨迹「没检查候选动作 → 自己生成 action → 失败」——拼起来才是完整知识应该做 不要做。2 Map单条轨迹提炼模式一条轨迹对应一次模型调用完全可并行。每条轨迹最多抽 3 个模式发给模型的 prompt 核心就这几句Map 阶段的 prompt每条轨迹调用一次分析这条轨迹提取可迁移的行为模式。成功轨迹这个 Agent 做对了什么其他 Agent 面对类似任务也应该这么做失败轨迹面对类似任务Agent 应该避免做什么模式要求通用、可操作、有效、不绑单题最多提取 3 个模式没有值得抽的就返回空「模式」的四条标准——通用性换道题也能用、可操作性能照着做、有效性不是废话、不绑单题没有一次性细节——正反例放在一起看标准反例正例通用性只适用于这一道题换一类任务也能用可操作性空泛的口号具体的动作步骤有效性正确但没有用的废话能真正改变做法的规律不绑单题带着具体订单号、报错码不出现一次性细节比如一条成功轨迹里Agent 每一步都严格从环境给出的 admissible actions 中选择go to desk 1、take apple 1。抽出来的 Mode 长这样{ type: success, pattern: only-use-admissible-actions, description: 每步只从环境提供的 admissible actions 中选择动作不要自行构造命令。, source_trajectory_ids: [T1, T2] }它已经不是一道题的答案而是一个可迁移的行为模式。Map 的设计取向抽出来的模式数量少没关系单题细节一条都不能混进来。3 Reduce分层合并200 条轨迹抽出几百个模式后必然大量重复「先看允许动作」「确认可用 action」「不要自造 action」「只从候选动作选择」 ↓ 「在每一步决策前检查环境提供的合法动作集合只从候选动作中选择 不要构造环境未提供的动作。」Reduce 每 10 个模式集合并成 1 个逐层归并直到只剩 1 个。合并 prompt 的核心是五条规则Reduce 阶段的 prompt每组合并调用一次把多组模式合并成一组去重描述同一行为的模式合成一条更强的泛化提升抽象层级覆盖更多场景保持类型成功/失败模式分开合并绝不互转保持质量丢掉模糊低价值的模式优先级太多时只留最重要、最通用的其中「保持类型」最重要——成功模式只和成功模式合并失败模式只和失败模式合并一路归并到最后仍是「成功模式集 失败模式集」两组。还有一种情况成功模式和失败模式看起来矛盾。比如成功轨迹里「直接退款成功了」失败轨迹里「直接退款被驳回」——两个模式方向相反。这个设计有意思的地方在于没有专门的矛盾消解环节论文刻意把 Trace2Skill 的冲突消解机制剥离了矛盾靠后面两层兜合成阶段用「决策标准」调和Final 把两极性写进同一份 Skill 时必须写「何时适用」的决策条件。矛盾被改写成带触发条件的规则「在退款窗口内直接退款超窗订单转人工」——两个模式不是互相否定而是各自带上了适用边界最终靠实测裁决写出来的 Skill 对不对回到第三章的 baseline 对比矛盾处理得好不好由 Δ 说话多个具体经验 → 一个通用规律矛盾的解法是条件化不是仲裁。4 Final模式写成 Skill合并完的模式还不能直接用。最后一步通过工具调用写入 SkillStoreadd_skill/update_skill/delete_skill完事调finish_extraction产出一份标准格式的 Skillname、description、body核心、可选的references/scripts。比如仓库里已有navigation-strategy新发现的模式是「不要重复探索已经确认过的房间」——模型会判断这不是新 Skill而是 update 进navigation-strategy。单次抽取就是一个增量构建 Skill 仓库的过程。合成要求浓缩成一句正反两面都要该做什么 该避免什么、必须写清「何时适用」的决策标准每句都可执行没有套话。两个容易被忽略的设计Skill 数量和长度是硬约束论文实验限定最多 1 份 Skill、每份不超过 3000 字符。超出限制时工具直接返回错误模型压缩或合并内容后重试。最终产出的就是一份 Skill所有模式都装进它的 body 里抽取方式分 Sequential 和 Parallel 两种Sequential 是一条轨迹接一条轨迹地分析、边分析边改 Skill直观但没法并行先写进去的内容会影响后面的判断Parallel 是论文主方法——所有轨迹并行抽模式Map再统一合并成 SkillReduce。差别一句话Sequential 是一个 Agent 从头干到尾Parallel 是把活拆开多个 Agent 并行干完再汇总5 Skill 的两种注入方式按 Skill 数量走两种注入方式单 Skill正文直接内联进 target 的 system prompt注明 “optional aid, not a mandatory procedure”多 Skill渐进披露——先 list_skills 看名字和描述再 view_skill 读正文需要时 read_skill_file 读附件消费阶段用的是只读的 SkillProvider和提取阶段可写的 SkillStore 分开。这个读写分离有一个重要意义评测时 Agent 不能一边使用 Skill一边偷偷修改 Skill——否则说不清是原来的 Skill 有用还是它执行中自己改出来的有用。三、用实测验证 Skill 的真实价值这是整个项目最狠的地方它不信「看起来合理」只信实测。1 验证方式同一批任务跑两遍同一任务分布上跑两遍无 Skill 的 baseline和有 Skill 的对比。无 Skill 有 Skill baseline with Skill │ │ ▼ ▼ score₁ score₂score₂ score₁才说明抽出来的 Skill 有正向作用。论文在 5 个领域 × 6 个目标模型 × 5 个提取器上做满矩阵跑 3 次取平均——这一步把「我觉得这个 Skill 写得不错」变成了「这个 Skill 在实际任务上确实提升了表现」。2 论文提到的几个风险点风险点 1平均有用但不保证。 75% 的组合有提升但 25% 的组合是负迁移——注入 Skill 反而变差。「平均增益为正」掩盖了巨大风险。风险点 2任务做得好的模型不一定抽得好。 在 SpreadsheetBench 上轻量的 Gemini-3.1-Flash-Lite 抽取质量最高而基线最强的 GPT-5.4 垫底。执行和提取是两个独立的能力选提取器不是选最强的模型。风险点 3读起来好的 Skill往往用起来更差。 让 LLM 当裁判对两份 Skill 二选一「哪个更好」判准率只有 46.4%——和瞎猜一样。更离谱的是两份 Skill 实际差距越大判对率越低差距 ≥5pp 时只剩 15.8%。文本的表面可信度与真实效用完全脱钩。3 真正决定效用的两件事经验池的成败比例。 固定提取器用成功率 100% / 75% / 50% / 25% / 0% 五种经验池各抽一份 Skill全失败池总是最差——成功轨迹是基础它们提供正向信号而不是只指示「要避免什么」最优比例因领域而异——有些探索型任务里失败偏重的池反而表现最好失败轨迹暴露了无效动作和死胡同负向信号特别值钱具体补救而非泛泛建议。 好 Skill 点出具体失败机制并给出可执行对策「宿主引擎不计算公式字符串要用 Python 算好静态值再写回」差 Skill 只有过程级口号「编码前先确认契约」——合理但挡不住真实的失败模式。4 把这个发现做成改进meta-skill既然「看着好」不靠谱那就用实测筛出真正预测效用的判据。论文用高差距 Skill 配对自动归纳出 7 个候选维度逐个验证哪个真的和效用对齐最后筛出 3 个维度含义Failure Mechanism Encoding说明为什么失败而不只是「失败了」Actionable Specificity步骤级程序引用领域对象和工具High-Risk Action Blacklist明确禁止具体的有害执行效果立竿见影同一个 LLM 裁判带着这三维打分判准率从 46.4% 升到 73.8%把这三维写成 meta-skill 塞进提取器的 system prompt9 组实验全部提升平均 1.55pp。而对照组很讽刺直接问 LLM「好 Skill 长什么样」得到的是清晰、完整、简洁、结构好……7 个表面维度——用这套标准引导提取反而有害平均 −0.59pp。评判 Skill 的标准只能从效用里挖出来不能凭直觉写。四、SkillLens 与 SkillOpt一个造一个改到这里两篇论文的分工就清楚了SkillLensSkillOpt核心问题经验怎么变成 SkillSkill 怎么变得更好中间表示Mode成功/失败模式Patch / Edit核心机制Map → Reduce → SynthesisExecute → Reflect → Edit → Validate验证有/无 Skill 对比Validation Gate产物SkillSetBest Skill一句话SkillLens 是「从经验中造 Skill」SkillOpt 是「把已有 Skill 越训越好」。1 一个造 Skill一个改 SkillSkillLens 造 SkillSkillOpt 改 Skill输入当前 Skill 失败任务输出验证通过的 Best Skill——解决「已有 Skill 怎么越改越好」。它的改法是手术式的只针对失败题提有界 patch → 验证集门控 → 变好才 accept没变好就 reject。业务变了不是拿新轨迹重新蒸馏一份替换——那样可能把原来有效的规则一起改掉。2 两套机制可以结合这也是 SkillLens 最值得落地到业务系统的地方SkillLens 负责发现「应该学什么」SkillOpt 负责决定「怎么安全地写回现有 Skill」——经验发现 有界更新 自动验证串成一条完整的 Skill 生命周期Agent 执行产生经验 → 经验沉淀为 Skill → Skill 帮助 Agent 执行 → 新执行继续产生经验 → Skill 再次演进 ↺从「人工写 Skill」走向「Agent 从自己的经验中持续学习 Skill」。最后2026 年一晃已经过半AI 大模型的热潮不仅没有降温反而持续升温金融行业用大模型做风控、医疗依靠 AI 解析影像电商、制造、教育各行各业都在把 AI 融入日常业务。曾经热闹的 “百模大战”早就告别单纯比拼模型参数正式进入落地应用时代。现在企业疯狂紧缺一类人才懂业务、懂 AI、能做出可上线项目的大模型开发工程师岗位缺口大薪资待遇十分可观。风口再好不如手握高薪 offer 实在。行情火热普通人、程序员该怎样从零入门大模型抓住这波机会今天整理好【2026 最新版】AI 大模型全套免费学习资源覆盖零基础入门、项目实战、理论知识、大厂面试从基础一路进阶。所有资料分类归档没有多余杂料无套路免费分享给想要入局 AI 赛道的程序员与零基础小白扫码免费领取全部内容1、大模型系统化完整学习路线2、大模型经典书籍文档3、AI 大模型最新行业研究报告4、企业级实战项目 完整配套源码5、大厂大模型面试真题汇总6、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 从零开始学大模型：微软SkillLens论文深度解析 | 新手必收藏！
本文深入解析微软SkillLens论文揭示如何从Agent执行日志中自动发现模式、抽取通用Skill。通过分析成功与失败轨迹SkillLens构建中间层Mode提炼可迁移行为模式并验证Skill的实际效用。文章强调实测验证的重要性并探讨SkillLens与SkillOpt的协同作用旨在帮助读者理解大模型如何从经验中学习并持续改进。上周写了一篇关于微软的 SkillOpt 学习文章主要解决「已有的 Skill 怎么越改越好」上线前用离线评测集把 seed skill 训成 best 再上线上线后靠夜间热更新跟着真实反馈持续迭代感谢兴趣同学可以前去阅读。除了 SkillOpt 论文微软还同时还发表了另一篇 Skill 相关的论文 SkillLens 主要解决「Skill 怎么从 Agent 执行经验里长出来」核心思想是从 Agent 的日常执行日志经验中自动发现模式、抽取 Skill再验证 Skill 是否真的有用。常见的实现方式就是人工把成熟业务流程整理成 SOP再让 LLM 根据 SOP 生成 Skill。这篇论文认为 Agent 在真实环境里每天执行大量任务这些执行轨迹本身有些也能抽取成一些提效且通用的 Skills 。例如一个 Agent 连续执行了 1000 个任务其中 800 个成功、200 个失败。这 1000 条轨迹里可能藏着大量值得沉淀的经验成功任务中有哪些可迁移的操作模式失败任务中有哪些应该避免的行为多条不同轨迹背后是不是存在同一个通用规律哪些经验只是单题细节哪些经验值得写进 Skill抽出来的 Skill 给 Agent 使用之后到底有没有真正提升效果一、SkillLens 解决的核心问题把整个问题简单理解成一条流水线这里有三个关键的对象对象是什么TrajectoryAgent 做过什么执行日志Mode从大量执行中总结出了什么模式可沉淀的信息Skill把这些模式写成 Agent 执行时可以照做的 Skill所以 SkillLens 实际上做了一次日常 Agent 执行的信息总结抽象论文的核心把整条链路拆成三个阶段经验生成执行出轨迹、技能提取轨迹提炼成 Skill、技能消费注入 Agent 验证效果Mode 中间层处理日志轨迹直觉上有执行轨迹了让 LLM 直接总结成 Skill 似乎顺理成章。但日常系统中 Trajectory 太细太多直接进行总结效果并不理想。假设一条处理退货订单的成功轨迹收到退货申请 → 核对订单号 → 确认在退款窗口内 → 校验商品状态 → 发起退款 → 完成直接总结会得到「收到退货先核对订单号确认在窗口内就退款」——它描述的是这一单怎么做不是这一类任务应该怎么做。真正有价值的经验是退款前先校验订单是否在退款窗口内超窗订单转人工处理不直接发起退款。所以 Trajectory 和 Skill 之间必须有一个中间层——Mode。二、Skill 的提炼过程1 第一步把执行日志统一成 Trajectory不同 Agent、不同 benchmark 的日志格式完全不同项目先把原始日志统一成标准 TrajectoryTrajectorySet 是经验池Trajectory 是一次任务执行Step 是一次交互谁说了什么、调了什么工具、环境返回了什么。统一的 schema 长这样还是那个退货订单的例子{ id: traj-20260815-042, task_name: 退货订单退款处理, agent: gpt-5.4, outcome: resolved, reward: 1.0, final_answer: 退款已发起, steps: [ {role: user, content: 处理订单 ORD-88231 的退货退款}, {role: agent, content: 先查订单核对是否在退款窗口内, tool_calls: [{name: query_order, arguments: {order_id: ORD-88231}}]}, {role: tool, content: , observation: 下单 2026-08-02退款窗口 14 天已签收在窗口内}, {role: agent, content: 在窗口内校验商品状态后发起退款, tool_calls: [{name: refund, arguments: {order_id: ORD-88231, amount: 299.0}}]}, {role: tool, content: , observation: 退款成功单号 RF-209913} ] }每个 Step 就四样东西role谁、content说了什么、tool_calls调了什么工具、observation环境返回了什么。这个结构对我们落地很有参考性——未来自己的 Agent 留痕时把日志统一落成这种格式后面 Map-Reduce 就能直接消费。其中最重要的设计是过程在steps价值信号在outcome——因为后面要按成败走不同的抽取逻辑成功轨迹 → Success Mode应该做什么 失败轨迹 → Failure Mode应该避免什么成功和失败不是同一种信息成功轨迹「先检查候选动作 → 再执行 → 成功」失败轨迹「没检查候选动作 → 自己生成 action → 失败」——拼起来才是完整知识应该做 不要做。2 Map单条轨迹提炼模式一条轨迹对应一次模型调用完全可并行。每条轨迹最多抽 3 个模式发给模型的 prompt 核心就这几句Map 阶段的 prompt每条轨迹调用一次分析这条轨迹提取可迁移的行为模式。成功轨迹这个 Agent 做对了什么其他 Agent 面对类似任务也应该这么做失败轨迹面对类似任务Agent 应该避免做什么模式要求通用、可操作、有效、不绑单题最多提取 3 个模式没有值得抽的就返回空「模式」的四条标准——通用性换道题也能用、可操作性能照着做、有效性不是废话、不绑单题没有一次性细节——正反例放在一起看标准反例正例通用性只适用于这一道题换一类任务也能用可操作性空泛的口号具体的动作步骤有效性正确但没有用的废话能真正改变做法的规律不绑单题带着具体订单号、报错码不出现一次性细节比如一条成功轨迹里Agent 每一步都严格从环境给出的 admissible actions 中选择go to desk 1、take apple 1。抽出来的 Mode 长这样{ type: success, pattern: only-use-admissible-actions, description: 每步只从环境提供的 admissible actions 中选择动作不要自行构造命令。, source_trajectory_ids: [T1, T2] }它已经不是一道题的答案而是一个可迁移的行为模式。Map 的设计取向抽出来的模式数量少没关系单题细节一条都不能混进来。3 Reduce分层合并200 条轨迹抽出几百个模式后必然大量重复「先看允许动作」「确认可用 action」「不要自造 action」「只从候选动作选择」 ↓ 「在每一步决策前检查环境提供的合法动作集合只从候选动作中选择 不要构造环境未提供的动作。」Reduce 每 10 个模式集合并成 1 个逐层归并直到只剩 1 个。合并 prompt 的核心是五条规则Reduce 阶段的 prompt每组合并调用一次把多组模式合并成一组去重描述同一行为的模式合成一条更强的泛化提升抽象层级覆盖更多场景保持类型成功/失败模式分开合并绝不互转保持质量丢掉模糊低价值的模式优先级太多时只留最重要、最通用的其中「保持类型」最重要——成功模式只和成功模式合并失败模式只和失败模式合并一路归并到最后仍是「成功模式集 失败模式集」两组。还有一种情况成功模式和失败模式看起来矛盾。比如成功轨迹里「直接退款成功了」失败轨迹里「直接退款被驳回」——两个模式方向相反。这个设计有意思的地方在于没有专门的矛盾消解环节论文刻意把 Trace2Skill 的冲突消解机制剥离了矛盾靠后面两层兜合成阶段用「决策标准」调和Final 把两极性写进同一份 Skill 时必须写「何时适用」的决策条件。矛盾被改写成带触发条件的规则「在退款窗口内直接退款超窗订单转人工」——两个模式不是互相否定而是各自带上了适用边界最终靠实测裁决写出来的 Skill 对不对回到第三章的 baseline 对比矛盾处理得好不好由 Δ 说话多个具体经验 → 一个通用规律矛盾的解法是条件化不是仲裁。4 Final模式写成 Skill合并完的模式还不能直接用。最后一步通过工具调用写入 SkillStoreadd_skill/update_skill/delete_skill完事调finish_extraction产出一份标准格式的 Skillname、description、body核心、可选的references/scripts。比如仓库里已有navigation-strategy新发现的模式是「不要重复探索已经确认过的房间」——模型会判断这不是新 Skill而是 update 进navigation-strategy。单次抽取就是一个增量构建 Skill 仓库的过程。合成要求浓缩成一句正反两面都要该做什么 该避免什么、必须写清「何时适用」的决策标准每句都可执行没有套话。两个容易被忽略的设计Skill 数量和长度是硬约束论文实验限定最多 1 份 Skill、每份不超过 3000 字符。超出限制时工具直接返回错误模型压缩或合并内容后重试。最终产出的就是一份 Skill所有模式都装进它的 body 里抽取方式分 Sequential 和 Parallel 两种Sequential 是一条轨迹接一条轨迹地分析、边分析边改 Skill直观但没法并行先写进去的内容会影响后面的判断Parallel 是论文主方法——所有轨迹并行抽模式Map再统一合并成 SkillReduce。差别一句话Sequential 是一个 Agent 从头干到尾Parallel 是把活拆开多个 Agent 并行干完再汇总5 Skill 的两种注入方式按 Skill 数量走两种注入方式单 Skill正文直接内联进 target 的 system prompt注明 “optional aid, not a mandatory procedure”多 Skill渐进披露——先 list_skills 看名字和描述再 view_skill 读正文需要时 read_skill_file 读附件消费阶段用的是只读的 SkillProvider和提取阶段可写的 SkillStore 分开。这个读写分离有一个重要意义评测时 Agent 不能一边使用 Skill一边偷偷修改 Skill——否则说不清是原来的 Skill 有用还是它执行中自己改出来的有用。三、用实测验证 Skill 的真实价值这是整个项目最狠的地方它不信「看起来合理」只信实测。1 验证方式同一批任务跑两遍同一任务分布上跑两遍无 Skill 的 baseline和有 Skill 的对比。无 Skill 有 Skill baseline with Skill │ │ ▼ ▼ score₁ score₂score₂ score₁才说明抽出来的 Skill 有正向作用。论文在 5 个领域 × 6 个目标模型 × 5 个提取器上做满矩阵跑 3 次取平均——这一步把「我觉得这个 Skill 写得不错」变成了「这个 Skill 在实际任务上确实提升了表现」。2 论文提到的几个风险点风险点 1平均有用但不保证。 75% 的组合有提升但 25% 的组合是负迁移——注入 Skill 反而变差。「平均增益为正」掩盖了巨大风险。风险点 2任务做得好的模型不一定抽得好。 在 SpreadsheetBench 上轻量的 Gemini-3.1-Flash-Lite 抽取质量最高而基线最强的 GPT-5.4 垫底。执行和提取是两个独立的能力选提取器不是选最强的模型。风险点 3读起来好的 Skill往往用起来更差。 让 LLM 当裁判对两份 Skill 二选一「哪个更好」判准率只有 46.4%——和瞎猜一样。更离谱的是两份 Skill 实际差距越大判对率越低差距 ≥5pp 时只剩 15.8%。文本的表面可信度与真实效用完全脱钩。3 真正决定效用的两件事经验池的成败比例。 固定提取器用成功率 100% / 75% / 50% / 25% / 0% 五种经验池各抽一份 Skill全失败池总是最差——成功轨迹是基础它们提供正向信号而不是只指示「要避免什么」最优比例因领域而异——有些探索型任务里失败偏重的池反而表现最好失败轨迹暴露了无效动作和死胡同负向信号特别值钱具体补救而非泛泛建议。 好 Skill 点出具体失败机制并给出可执行对策「宿主引擎不计算公式字符串要用 Python 算好静态值再写回」差 Skill 只有过程级口号「编码前先确认契约」——合理但挡不住真实的失败模式。4 把这个发现做成改进meta-skill既然「看着好」不靠谱那就用实测筛出真正预测效用的判据。论文用高差距 Skill 配对自动归纳出 7 个候选维度逐个验证哪个真的和效用对齐最后筛出 3 个维度含义Failure Mechanism Encoding说明为什么失败而不只是「失败了」Actionable Specificity步骤级程序引用领域对象和工具High-Risk Action Blacklist明确禁止具体的有害执行效果立竿见影同一个 LLM 裁判带着这三维打分判准率从 46.4% 升到 73.8%把这三维写成 meta-skill 塞进提取器的 system prompt9 组实验全部提升平均 1.55pp。而对照组很讽刺直接问 LLM「好 Skill 长什么样」得到的是清晰、完整、简洁、结构好……7 个表面维度——用这套标准引导提取反而有害平均 −0.59pp。评判 Skill 的标准只能从效用里挖出来不能凭直觉写。四、SkillLens 与 SkillOpt一个造一个改到这里两篇论文的分工就清楚了SkillLensSkillOpt核心问题经验怎么变成 SkillSkill 怎么变得更好中间表示Mode成功/失败模式Patch / Edit核心机制Map → Reduce → SynthesisExecute → Reflect → Edit → Validate验证有/无 Skill 对比Validation Gate产物SkillSetBest Skill一句话SkillLens 是「从经验中造 Skill」SkillOpt 是「把已有 Skill 越训越好」。1 一个造 Skill一个改 SkillSkillLens 造 SkillSkillOpt 改 Skill输入当前 Skill 失败任务输出验证通过的 Best Skill——解决「已有 Skill 怎么越改越好」。它的改法是手术式的只针对失败题提有界 patch → 验证集门控 → 变好才 accept没变好就 reject。业务变了不是拿新轨迹重新蒸馏一份替换——那样可能把原来有效的规则一起改掉。2 两套机制可以结合这也是 SkillLens 最值得落地到业务系统的地方SkillLens 负责发现「应该学什么」SkillOpt 负责决定「怎么安全地写回现有 Skill」——经验发现 有界更新 自动验证串成一条完整的 Skill 生命周期Agent 执行产生经验 → 经验沉淀为 Skill → Skill 帮助 Agent 执行 → 新执行继续产生经验 → Skill 再次演进 ↺从「人工写 Skill」走向「Agent 从自己的经验中持续学习 Skill」。最后2026 年一晃已经过半AI 大模型的热潮不仅没有降温反而持续升温金融行业用大模型做风控、医疗依靠 AI 解析影像电商、制造、教育各行各业都在把 AI 融入日常业务。曾经热闹的 “百模大战”早就告别单纯比拼模型参数正式进入落地应用时代。现在企业疯狂紧缺一类人才懂业务、懂 AI、能做出可上线项目的大模型开发工程师岗位缺口大薪资待遇十分可观。风口再好不如手握高薪 offer 实在。行情火热普通人、程序员该怎样从零入门大模型抓住这波机会今天整理好【2026 最新版】AI 大模型全套免费学习资源覆盖零基础入门、项目实战、理论知识、大厂面试从基础一路进阶。所有资料分类归档没有多余杂料无套路免费分享给想要入局 AI 赛道的程序员与零基础小白扫码免费领取全部内容1、大模型系统化完整学习路线2、大模型经典书籍文档3、AI 大模型最新行业研究报告4、企业级实战项目 完整配套源码5、大厂大模型面试真题汇总6、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】