跳转到内容
Jason's Study

MIND-Skill — 用归纳和演绎双 agent 抽 skill 并保证质量

待复核

是什么

Section titled “是什么”

MIND-Skill 是一套用两个 agent 配合抽取 skill 并保证质量的方法：归纳 agent 看一堆成功轨迹猜出”潜在 skill”，演绎 agent 拿这条 skill 反过来重建轨迹验证它能不能 work，三条 loss + TextGrad 把不靠谱的 skill 筛掉。日常类比：归纳 agent 是带学徒的师傅”我看你做了 5 次类似的活儿，总结出一个套路是这样”；演绎 agent 是徒弟”我按这个套路再做一遍，看能不能复现你之前的活儿”。两人对得上才入库。

旧路线（voyager / 大量后续工作）抽 skill 是单边——成功一次就把”过程描述”存进库。问题是：一次成功不代表 skill 通用，运气成分大；存进去之后没人验证，下次复用时才暴露问题。MIND-Skill 把”假设—验证”做成显式的 loop，每条入库的 skill 都通过了”反过来用它能重建一条新轨迹”这个测试。

三条 loss 分别是：（1）reconstruction loss——演绎 agent 用 skill 重建原轨迹的相似度；（2）outcome loss——重建轨迹是否完成原任务；（3）rubric loss——一个 LLM-as-judge 给 skill 描述写得好不好打分。三条反馈经 textgrad 汇总后，主要更新归纳 agent 的 prompt，再生成更好的 skill；演绎 agent 的 prompt 保持 frozen，避免它自己补洞掩盖 skill 缺陷。

为什么重要

Section titled “为什么重要”

不理解 MIND-Skill，下面这些事都没法解释：

  • 为什么 2026 年 skill agent 论文集体往”质量保证”方向走——大家发现 skill 库膨胀但效果不涨
  • 为什么”多 agent 配对验证”是当下流行模式——单一 agent 自己评自己有偏
  • 为什么 TextGrad 这种”对文本反传梯度”的工具在 skill 库维护中成主力
  • 为什么 reconstruction + outcome + rubric 三 loss 比单 outcome 更稳——单看完成度容易学到”shortcut skill”
  • 为什么要把演绎 agent 冻住——否则它自己补洞，你分不清是 skill 好还是模型强

核心要点

Section titled “核心要点”

MIND-Skill 拆成 三步：

  1. 归纳 agent：给它 N 条成功轨迹，让它输出一条候选 skill 描述。类比：师傅看 5 个徒弟交活，写出一份 SOP “做这类活儿大致这么走”。

  2. 演绎 agent + 三 loss：演绎 agent 只拿 skill + 任务说明（看不到原轨迹），在环境里跑 ReAct 重建轨迹。三条 loss 分别检查：（a）和原成功轨迹过程是否对齐 —— reconstruction（b）新轨迹能不能完成任务 —— outcome（c）skill 文本写得清不清楚 —— rubric。

  3. TextGrad 优化归纳 prompt：不像普通 RL 更新模型权重，TextGrad 把三 loss 的文字反馈写回归纳 agent 的 prompt；下一轮用新 prompt 再抽 skill。演绎侧保持 frozen，所以重建变好只能归功于 skill 变好。

三步咬合：归纳生成假设、演绎做对照实验、TextGrad 改进归纳策略。

这个流程把 agent skill 库从”日记本”变成”实验记录”——每条 skill 都标着”我用什么数据怎么验证过”。

实践案例

Section titled “实践案例”

案例 1：归纳错了被演绎挡住

Section titled “案例 1：归纳错了被演绎挡住”

5 条成功轨迹都是”关闭浏览器弹窗 → 点击搜索 → 提交”。归纳 agent 写出 skill：

任务：完成搜索
步骤：1. 关闭弹窗 2. 点击搜索 3. 提交

演绎 agent 跑 5 个新搜索任务，其中 3 个没有弹窗。演绎 agent 找不到弹窗就僵住——outcome loss 高。归纳侧根据反馈把 skill 修为：

任务：完成搜索
步骤：1. 如有弹窗先关闭 2. 点击搜索 3. 提交

下一轮演绎跑通，入库。“如有”这个条件来自三 loss 反馈驱动的归纳修订。

这个例子展示闭环的实际作用：演绎侧冻住，重建失败只能怪 skill；归纳侧根据反馈改描述，再试一轮。

案例 2：rubric 拦掉描述太模糊的 skill

Section titled “案例 2：rubric 拦掉描述太模糊的 skill”

归纳 agent 写出 skill：“登录账户”。outcome 和 reconstruction 都过——演绎 agent 也能登录。但 rubric LLM-as-judge 给 4/10：写得太泛、参数（用户名、密码）没说明、失败处理没写。

归纳侧修订后变成：“登录账户：输入 username + password → 点 login → 若返回 captcha 调 captcha-solver”。rubric 给 8/10，入库。

rubric 阻止”过简描述”灌入库——这是 markdown skill 库膨胀的根因之一。

案例 3：reconstruction loss 揪出 shortcut

Section titled “案例 3：reconstruction loss 揪出 shortcut”

某条 skill 在 outcome 上过了——演绎 agent 完成了任务，但 reconstruction loss 高——重建的轨迹和原成功轨迹差很多。检查发现演绎 agent 走了一条完全不同的路完成任务（用 keyboard shortcut 而非 click），说明这条 skill 描述没抓住”原始解法的本质”，可能在严格环境下不能复用。

归纳侧根据反馈把 skill 修得更具体——“用鼠标点击的方式 …”，reconstruction 上升后入库。

reconstruction 这条 loss 是 MIND-Skill 区别于纯 outcome 验证的关键，它在乎”过程对不对”，不只在乎”结果对不对”。

踩过的坑

Section titled “踩过的坑”
  1. 归纳 agent 易过度泛化：轨迹里的实例细节被写成万能 SOP，什么都说等于什么都没说；rubric loss 专门压抽象层级。
  2. 别让演绎 agent 也一起被优化：论文把演绎 prompt 冻住；若演绎侧也会”自学补洞”，reconstruction 信号就脏了。跨模型（如 Qwen 归纳 + 更强模型辅助）是可选设定，不是必须 GPT-4+Claude。
  3. TextGrad 要小步迭代：一次 reconstruction 高就大改归纳 prompt，容易把对的部分也改坏；论文按任务迭代多轮并保留 best-so-far skill。
  4. 三 loss 缺一不可：消融显示去掉 reconstruction 对难任务伤害最大，去掉 rubric 伤泛化；单看 outcome 不够。
  5. 验证预算大：每条候选 skill 要在活环境里演绎重建，调用贵；预算不够就只能少迭代，质量门变松。

论文在 AppWorld（交互编码 agent）和 BFCL-v3（多轮 function calling）上评估：相对 Skill-extract / ACE / Trace2Skill 等基线，TGC/SGC 与准确率整体更高，且 skill 更紧凑。

适用 vs 不适用场景

Section titled “适用 vs 不适用场景”

适用：

  • skill 库要长期维护，质量比盲目堆条目更重要
  • 有可重复执行的环境（演绎 agent 能按 skill 真跑一遍）
  • 舍得付验证预算：每条 skill 多轮重建 + 三 loss

不适用：

  • 没有成功轨迹可归纳（cold start）
  • 环境不可复现 / 随机性极高——reconstruction 与 outcome 噪声大
  • 极简原型、验证开销高于收益（先手工写几条 skill 更划算）
  • 只想”抽完就存”、不愿冻住演绎侧做对照实验

历史小故事（可跳过）

Section titled “历史小故事（可跳过）”
  • 2023：voyager 把 skill 攒成可复用代码，无显式质量验证
  • 2024 上半年：Reflexion 系列把”反思”引入 agent，但只反思单 trajectory 不反思 skill 库
  • 2024 下半年：TextGrad 论文发布——把”对自然语言文本算梯度” 这件事工程化
  • 2025：multi-agent debate / verifier 论文火，“双 agent 配对” 成方法学
  • 2026 年初：MIND-Skill 把这两个想法合在一起——双 agent + TextGrad + 三 loss
  • 同期：skill-as-pseudocode / effiskill / skill-sd-self-distillation 各从不同维度做 skill 质量保证
  • 预测：未来一年”skill 库 GC + skill 质量度量”会成为 agent 工程化标配

MIND-Skill 把”假设—验证”这个科学方法的最小循环搬进了 agent skill 抽取。

每条入库的 skill 都带有 trace：用了哪些验证轨迹、loss 收敛曲线、最终描述版本号。事后 debug 起来比 markdown 库直接好用。

学到什么

Section titled “学到什么”
  1. skill 抽取必须有验证闭环：写完不试就入库等于把垃圾灌进库
  2. 冻住演绎侧：让重建失败能归因到 skill，而不是演绎 agent 自己变聪明
  3. 三 loss 比单 loss 稳：过程对齐 + 结果正确 + 文档质量缺一不可
  4. TextGrad 优化的是归纳 prompt：不动 LLM 权重，也能迭代改进 skill 生成策略
  5. 入库前多花算力，入库后少踩坑：紧凑、可复用的 skill 比膨胀的 markdown 库更省推理 token

延伸阅读

Section titled “延伸阅读”

关联

Section titled “关联”
  • voyager —— skill 库奠基；MIND-Skill 给它加了质量门
  • skill-as-pseudocode —— 同期 skill 工作；改表示形式
  • effiskill —— 同期 skill 工作；代码效率
  • webxskill —— Web agent skill；纯代码表示
  • textgrad —— 文本梯度基础设施；MIND-Skill 的核心工具
  • react —— agent 标准循环；演绎 agent 是 ReAct loop 实例
  • skill-pro-nonparametric-ppo —— 同期不动权重学 skill 的另一路线
  • reflexion —— 单 agent 反思；MIND-Skill 把反思扩展到双 agent 配对验证
  • self-evolving-agents-survey —— self-evolving 综述；MIND-Skill 是其下 skill 质量保证流派

反向链接

Section titled “反向链接”
  • clawtrace-cost-aware —— ClawTrace — 把 agent 每步操作的”成本账”先算清再蒸馏
  • effiskill —— EffiSkill — 把代码效率优化经验抽成两层 skill 库
  • mmskills-multimodal —— MMSkills — 把视觉 agent 的”操作经验”做成多模态卡片
  • skill-as-pseudocode —— Skill-as-Pseudocode — 把 agent 笔记本写成可校验的伪代码
  • skill-pro-nonparametric-ppo —— Skill-Pro — 不动权重学可复用 skill 的非参数 PPO
  • skill-sd-self-distillation —— Skill-SD — 用 agent 自己抽出的 skill 当 dynamic teacher 自蒸馏
  • webxskill —— WebXSkill — 给 Web agent 的可执行 skill 是参数化代码 + URL 图索引