Skill-MAS 读后：你的技能系统离「自动进化」还差几步

arXiv 2606.18837 告诉我们：Meta-agent 的编排能力可以写成一份可自动进化的技能文本。 而我们手上已经有 56 个 skill、一套 compound-system、若干个 agent 框架——这张牌怎么打。

---

TL;DR

• Skill-MAS 的核心洞见：组织多 Agent 这件事本身，可以写成一份技能文件（Meta-Skill），然后通过多轨迹执行 + 选择性反思 + 对比诊断，自动迭代这份技能。
• 这和我们已有的高度吻合——skills + compound-system + Baby Harness 本身就是这个架构的原型。差距在于我们缺少系统性迭代闭环。
• 五件可以马上做的事：多轨迹执行、不确定性感知、对比诊断、抽象性 gate、多轮保留最优。
• 最大的提醒：论文依赖 ground-truth labels，我们得走自监督路线才能在生产环境跑起来。

---

1. 一条验证了我们直觉的论文

最近看到 Skill-MAS（arXiv 2606.18837，HKUST-GZ + Ant Group），第一反应是：这把我们正在做的事情理论化了。

半年来我们一直在做一件事：把 Agent 的"做事方式"提炼成可复用的技能文本（SKILL.md），然后用 compound-system 在任务结束后反思、记录教训。这个想法的自然延伸是——不仅 sub-agent 的执行技能可以进化，Meta-agent 怎么组织协作的"元能力"，同样可以写成技能、自动迭代。

Skill-MAS 的答案正是如此。它把 Meta-agent 的编排能力抽象成一份三类模块的 Meta-Skill：

Task Decomposition     → "任务怎么拆"
Agent Engineering      → "谁来做"
Workflow Orchestration → "工作流怎么连"

然后在验证集上反复执行 → 反思 → 改写这份技能。关键是不改模型参数——只改文本。

这和我们"技能即代码"的理念完全一致。而且它证明了几个我们一直相信但没验证的假设：

• 技能在不同 LLM 之间可迁移（同任务换模型仍有显著提升）
• 技能在不同任务之间可迁移（同模型换任务提升同样可观）
• 技能拆成模块定位故障更准（三个模块，出问题知道改哪）

---

2. 我们已经有了什么

来盘点一下手头的资产和 Skill-MAS 的对应：

关键发现：我们有了素材（skills）和反思引擎（compound-system），但缺少连接它们的迭代闭环。 Skill-MAS 恰好提供了这个闭环的标准接口。

---

3. 五件可以立刻吸收的设计

3.1 多轨迹执行：从点估计到分布估计

我们现在的执行策略是一次定生死：一个任务跑一遍，成功就成功，失败就失败。但一个 skill 好不好，一次执行说明不了问题——可能只是随机波动。

Skill-MAS 对同一个任务采样 K=5 次，然后算两个统计量：

uncertainty = 分数标准差  → 规则是否模糊
difficulty  = 负平均分    → 任务是否真的难

高 uncertainty 意味着 skill 的规则不够明确——有时候猜对、有时候猜错。高 difficulty 意味着任务确实需要更强的能力。两个都高 = 最值得优化的对象。

我们可以做的：在 compound-system 的验证环节，对边界任务自动跑 3~5 次，计算标准差。如果同一个 prompt 在不同运行中表现差异较大，说明 skill 的规则需要细化，而不是能力不够。

3.2 选择性反思：精力花在刀刃上

我们的 compound-system 对所有任务一视同仁反思。但实际经验告诉我们：有些失败值得深入复盘，有些只是噪声。

Skill-MAS 的做法是用 elbow truncation（二阶差分找自然截断点）从 N 个任务中选出 少量高优先级 的任务做深度反思维修，而不是平均用力。

公式很简单：

p_i = 0.5 * normalize(u_i) + 0.5 * normalize(d_i)

按 p_i 排序，在 priority curve 的"拐点"处截断。拐点之后的任务价值递减。

我们可以做的：在 gate-4 代码审查后，计算本次改动的"不确定性"（测试不稳定度）和"难度"（代码复杂度/问题复现率），决定是否需要 compound-system 深度反思，还是快速过。

3.3 对比诊断：让好轨迹和差轨迹对话

compound-system 的反思目前是叙述性的——"这次做错了什么"。但 Skill-MAS 用了一个更强大的方法：对比高分组和低分组的执行轨迹。

对同一个人任务，把 K 次运行的轨迹按分数分成两组（高于中位数 vs 低于中位数），让 LLM 对比两组轨迹的分叉点——在哪个决策步骤上开始出现分歧。

Phase 1: 任务内对比
  高分轨迹 vs 低分轨迹
  → 找到分叉点
  → 提取成功因素
  → 诊断失败根因

Phase 2: 跨任务综合
  合并多个任务的发现
  → 识别系统性模式（好模式和坏模式）
  → 产出 evidence package

我们可以做的：compound-system 反思的入口从"描述问题"改为"对比分析"。对同类的多次失败，先收集数据，再对比分析，再写结论。

3.4 抽象性 Gate：禁止单题补丁

论文里一个我强烈认同的设计约束：每个技能修改必须抽象为通用编排原则，不能写成单题补丁。

这意味着：如果系统在处理 Task-A 时失败了，你把修复写成"对 Task-A 做 X"，检查不过。你必须写成"当任务类型是 X 时，先做 Y 再做 Z"——把特例提升为原则。

我们可以做的：在技能编辑流程（gate-3 后的技能更新）中加一个 check：新写的规则是否包含具体任务名/数据集名？如果是，打回重写。只有抽象的编排原则才能进技能。

3.5 多轮保留最优：改不坏才叫进化

Skill-MAS 每次迭代后保留上一版技能，R 轮结束后在验证集上选最优版本作为最终版本。这看起来简单，但我们对技能的修改通常是"单向门"——改了就没有回头路。

我们可以做的：在技能更新流程中加入git分支管理。每次自动进化创建一个分支，保留所有历史版本，最终选验证集最优版本合并回 main。这样即使某次进化出了问题，也不污染已经稳定的技能。

---

4. 一个值得警惕的限制

论文坦诚了一个关键局限：选择性和反思依赖 ground-truth labels。

具体来说，priority score 的计算需要知道每个任务的标准答案，才能算出 difficulty = -mean(score)。而在真实的生产环境中，大部分任务是没有 ground-truth 的。

论文对此的缓解方案比较弱（"未来可以用 LLM-as-judge"）。我们在 ai-evaluation skill 中已经积累了 LLM-as-judge 的实践，这条路是通的，但需要谨慎设计：

• 关键风险：self-fulfilling prophecy——用 LLM 评价 LLM，评价标准可能和模型盲点一致
• 我们的应对：多维度打分（正确性 + 效率 + 可维护性）+ 少量人工标注做 calibration

---

5. 我们的下一步路线图

综合 Skill-MAS 的启发和我们已有的资产，这是我想推进的方向：

Phase 1（现在就做）
├── 多轨迹采样：compound-system 中加 K-run 模式，输出 variance
└── 对比诊断：反思流程从"描述问题"改为"对比好/坏轨迹"

Phase 2（短中期）
├── 选择性反思：根据 uncertainty + difficulty 优先级排序
├── 抽象性 gate：技能编辑加规则抽象检查
└── 迭代保留：技能更新走 git branch，选最优合并

Phase 3（长期）
├── self-supervised evaluation：LLM-as-judge 替代 ground-truth
├── 跨 session 的 Meta-Skill 持久化
└── 技能更新自动 MR → review → merge 流水线

---

6. 写在最后

Skill-MAS 验证了一个我们相信已久的直觉：Agent 的编排能力是可以被写成文本、自动进化、跨模型迁移的。

它不是又一个需要 GPU 和训练数据的框架。它的核心升级是在"理解层"——把元认知从隐式的（模型参数/搜索算法）变成显式的（结构化技能文本）。显式的才能被检查、被修改、被复用。

而我们恰好已经有了 56 个 skill、一套 compound-system、一个 Baby Harness。牌已经在手上了，缺的是一套规则来打。

如果你也在做 Agent skills 相关的系统和实践，欢迎一起聊。

---

参考：Lin, Yang, Qin. "Skill-MAS: Evolving Meta-Skill for Automatic Multi-Agent Systems." arXiv:2606.18837, June 2026.