一、开篇：Agent 的 Skill 写完就定了吗？
做 Agent 开发的人都知道，Skill（技能文档）是 Agent 的"做事手册"------告诉它遇到什么问题该怎么处理、调哪些工具、按什么步骤执行。
但 Skill 写完之后呢？
传统的做法是：人工维护。遇到新 case 就加一条规则，发现 old 规则不好用就删掉。问题是：
上下文腐化：长程任务里不断往 system prompt 里塞成功经验、纠错案例，token 膨胀到上万，关键指令的召回率反而下降。
经验遗忘：Agent 每次会话都要从零推理同一套多步流程，单次会话内学到的纠错策略，会话结束即丢失。
人工维护成本：每新增一个场景都要人工编写、测试、上线，闭环合不上。
于是问题来了：Skill 能不能自己变强？
二、Skill 的三种形态
在讨论"怎么进化"之前，先搞清楚 Skill 长什么样：
| 形态 | 表现 | 优势 | 代价 |
|---|---|---|---|
| 文本形态（skill.md） | markdown 存操作指南、决策规则、少样本示例 | 编辑代价低、可读性强、迭代快 | 表达力有限，依赖模型理解 |
| 可调用函数 | 函数 / 脚本 / API wrapper | 执行确定、可单元测试 | 生成与验证成本高 |
| 过程性脚本 | 成功轨迹压缩为 if-then 工作流 | 兼具可读与确定性 | 需要抽象泛化能力 |
关键洞察：文本形态的编辑成本最低，因此最有可能被放进一个高频迭代的优化循环里。如果被反复适配的对象其实是 Agent 的做事流程，那这份流程文档本身就应该是可训练的。
三、从经验到 Skill：Trace2Skill
最直觉的思路：Agent 跑了一堆任务，积累了大量执行轨迹，能不能从这些轨迹中提炼出 Skill？
做法
- 轨迹批量生成：用当前 Skill 跑一批目标任务，产生大量执行轨迹，按成功/失败分类
- 并行分析：调度多个分析 Agent，并行处理每条轨迹，生成修改补丁
- 无冲突整合：分层合并所有补丁，去重去矛盾，整合成一份新 Skill
训练信号
- 成功轨迹 → 归纳为通用策略
- 失败轨迹 → 提炼为避坑规则
类比
像从大量代码 review 中总结出 coding guidelines------不是看一条代码就写规范，而是看了一批之后提炼共性。
四、3 角色 Agent 协作：EvoSkill
Trace2Skill 是"批量归纳"，EvoSkill 则是"迭代进化"------让三个子 Agent 协作，像一个小型团队一样持续改进 Skill。
做法
csharp
执行者（Executor）→ 用当前 Skill 跑任务，产出轨迹
↓
提案者（Proposer）→ 分析轨迹，失败就定位根因，成功就总结模式
↓
搭建者（Builder）→ 根据提案，动手改 Skill 文档
↓
验证器 → 在 held-out 上验证，Pareto 前沿筛选关键设计
- 方向性：不是盲目修改，而是基于失败分析的定向改进
- 验证闭环：改完的 Skill 必须在 held-out 上验证，防止"越改越差"
实验效果
OfficeQA 精确匹配从 60.6% → 67.9%（+7.3），SealQA 从 26.6% → 38.7%（+12.1）
五、把 Skill 当参数训练：SkillOpt
这是最完整的方法，把 Skill 的优化过程类比为深度学习中的模型训练------Skill 文本就是"可训练的外部参数" 。
六大机制
| 机制 | 类比深度学习 | 做什么 |
|---|---|---|
| Rollout | 前向传播 | 当前 Skill 在训练集上跑轨迹 |
| Reflection | 反向传播/文本梯度 | 分析成功/失败，生成编辑提案 |
| Bounded Edits | 学习率 | 每步最多改几条，防止跳太远 |
| Validation Gate | 验证集 early stopping | held-out 上严格更优才接受 |
| Rejected-Edit Buffer | 负样本回放 | 被拒的编辑记录下来，避免重复 |
| Slow/Meta Update | 动量 Momentum | 跨 epoch 保留长期趋势 |
完整流程
sql
for each epoch:
打散训练集成 rollout batch
for each 优化步:
① Rollout：当前 Skill 生成轨迹
② Reflection：分析 minibatch，生成 add/replace/delete 编辑
③ Bounded Edits：排序，最多保留 L_t 条
④ Validation Gate：候选 Skill 在 held-out 上严格更优才接受
⑤ Rejected-Edit Buffer：被拒编辑写入 buffer
Slow/Meta Update：epoch 末，保留跨 epoch 的改进趋势实验效果
6 benchmark × 7 目标模型 × 3 执行 harness：
- GPT-5.5 六 benchmark 均值从 58.8 → 82.3（+23.5）
- 七个模型平均 +17.6
- 最终 Skill 只有 379--1,995 token，被接受编辑仅 1--4 条
六、多 Agent 协同进化：coEvoSkill
EvoSkill 是三个 Agent 协作，coEvoSkill 则是引入对抗机制------生成者和验证者互相竞争，推动 Skill 持续进化。
做法
bash
生成器 → 改 Skill
↕ 对抗
验证器 → 出题 + 诊断 + 升级测试
↓
真实环境 → pass/fail 反馈关键设计
- 生成器越想通过验证，改出的 Skill 就越好
- 验证器越严格，生成器的压力越大
- 类比 GAN：生成器和判别器互相提升
七、Skill + RL 融合：SkillRL
前面的方法只改 Skill 文本，SkillRL 则是一边训练模型权重，一边进化 Skill 库------两者互相促进。
做法
- RL 训练过程中，用奖励信号更新模型权重
- 同时从失败案例中蒸馏新知识，实时扩充 Skill 库
- Skill 库既是策略的输入，也是策略改进的产物
关键设计
- 递归共进化：策略提升 → 暴露深层问题 → 技能进化 → 策略再提升
- 双向蒸馏：成功轨迹归纳为通用策略，失败轨迹转化为避坑指南
递归演化机制
在 RL 训练过程中，系统定期评估性能，对低效任务类别触发新一轮分析，生成新技能并加入 Skill Bank，使后续策略训练能基于最新知识进行决策。
这种"策略提升 → 暴露深层问题 → 技能进化 → 策略再提升"的闭环，实现了 Skill 与模型能力的共同成长。
八、实践：Push 文案的完整进化过程
以上是方法论，下面用一个真实案例讲 SkillOpt 落地长什么样。
场景
为电商平台生成 Push 推送标题（多语种：英/西/葡/法/德/波/荷/意/乌/俄/日/韩/土/泰/阿）
三层 Reward 机制
L1：确定性合规（脚本自动检查）
- ≤36 字、无金额/百分比、无虚构销量、emoji ≤ 1、无最高级
L2：LLM 判官（带真实 CTR 锚点的成对评审）
CTR = Click-Through Rate（点击率），是线上真实投放后回收的数据。LLM 判官做 pairwise 评审时，参考这些真实 CTR 数据来判断，不是凭感觉打分。
java
Higher-CTR style (concrete / specific)：
Save extra this summer: Local+ deals | Win at your favorite sports 🏀
Lower-CTR style (generic / vague)：
Keep discovering great finds 🔥 | ✨ Smile, shop, repeatL3：微调项
- 细粒度修正，clip 到 ±0.05，防止大波动
门控规则
ini
合规否决：候选合规率低于当前 → reject
客观改进：合规或多样性上升 → accept
去噪判官：二者都持平 → K=3 票投票，胜率 ≥ 0.5 + deadband 才 accept10 轮进化过程
| 轮 | 动作 | 编辑内容 | 判官胜率 |
|---|---|---|---|
| 1 | reject | add: Avoid generic benefit-only phrases | 0.4583 |
| 2 | accept | add: Avoid generic temporal/seasonal announcements | 0.5833 |
| 3 | accept | add: When brief lacks specific category, anchor to usage scene | 0.5833 |
| 4 | accept | add: When brief lacks specific product noun, anchor to usage scene | 0.55 |
| 5 | accept | replace: → When brief category is generic benefit | 0.5833 |
| 6 | accept | replace: → When brief lacks specific product noun | 0.57 |
| 7 | reject | replace: → combine mechanic/threshold with HIGH-FREQUENCY | 0.4583 |
| 8 | reject | replace: → NEVER output generic status/temporal labels alone | 0.4167 |
| 9 | accept | replace: → When brief category is generic | 0.51 |
| 10 | accept | replace: → When brief category is generic (new-arrival) | 0.5833 |
结果：接受 7 次，拒绝 3 次。被拒的判官胜率 < 0.5，门控在按设计工作。
进化前后对比
Free-shipping（全场免邮）
| 语种 | 进化前 | 进化后 |
|---|---|---|
| en | Free shipping on everything | Your cart flies home, zero fee |
| es | Envío gratis en todo | Cero gastos de envío, sin mínimos |
| ja | 全品送料無料でお届け | 送料ゼロだから、気になる靴も服も迷わずそのままカートへ |
| ko | 전 품목 무료배송 | 뭘 사도 배송비 없이 |
| de | Alles versandkostenfrei | Deine Versandkosten? Geschenkt. |
Hot-selling（热销推荐）
| 语种 | 进化前 | 进化后 |
|---|---|---|
| en | Crowd favorites are here | Crowd favorites moving fast |
| de | Die Favoriten der Fans | Tausende können sich nicht irren |
| ru | Народные хиты | Тысячи покупателей не ошибаются |
新增的 Skill 规则（逐字来自部署的 Skill）
markdown
3. 优先点明品类词（如 sports/beauty/fashion）：数据中高CTR标题均以具体品类开头
4. 避免孤立使用通用优惠词（save/deal/free shipping），必须结合具体品类、场景或利益点
5. 当 brief 品类本身是通用利益词时，锚定使用场景而非品类名称九、过拟合怎么办？
Skill 自进化的过拟合是指：Skill 为了迎合当前训练集的特定 case，变得臃肿、发散，导致在新任务上反而变差。
五道防线
| 防线 | 机制 | 作用 |
|---|---|---|
| 有界编辑 | 每步最多改 L_t 条（cosine 衰减） | 限制每次"步幅"，防止大幅偏离 |
| 严格门控 | held-out 上严格更优才接受 | 训练集上改得好没用，必须在没见过的数据上也更好 |
| minibatch 反思 | 看一批轨迹的共性问题，不看单条 | 单条轨迹的问题可能是偶然的 |
| Rejected-Edit Buffer | 被拒的编辑记录下来 | 不会反复尝试同一个有害修改 |
| Slow/Meta Update | 跨 epoch 保留长期趋势 | 不被单个 batch 的噪声带偏 |
消融实验证明
| 组件 | SearchQA | Spreadsheet | LiveMath |
|---|---|---|---|
| 完整 SkillOpt | 87.1 | 77.5 | 61.3 |
| 去掉慢更新+meta | 86.3 | 55.0 | 59.7 |
去掉纪律类机制后，SpreadsheetBench 直接掉了 22.5 分------这就是过拟合的代价。
十、什么任务适合 Skill 自进化？
关键前提：需要可验证的反馈信号。
csharp
你的任务有明确的对错判断吗？
├── 有（代码/QA/工具调用/数据处理）
│ └── 直接用 SkillOpt / EvoSkill，效果很好
├── 部分有（文案/翻译/摘要）
│ └── 拆 reward 层：L1 硬规则 + L2 LLM 判官
└── 几乎没有（创意写作/开放对话）
└── 先做评测体系（LLM as Judge），再考虑自进化| 任务类型 | 适合度 | 原因 |
|---|---|---|
| 代码生成 | ★★★★★ | 跑一下就知道对不对 |
| QA 问答 | ★★★★★ | 和标准答案精确匹配 |
| 工具调用 | ★★★★★ | 参数对不对、结果对不对，脚本可验证 |
| 数据处理 | ★★★★☆ | 输出结果可自动校验 |
| 文案生成 | ★★★☆☆ | 需要拆 reward 层，LLM 判官辅助 |
| 创意写作 | ★☆☆☆☆ | 没有标准答案，验证困难 |
十一、总结：一张图看懂所有方法
不训模型，只改 Skill 文件（14种）
├── 轨迹生成: Trace2Skill, EvolveR, SAGE, Skill-Pro
├── 递归进化: Skill1, ARISE, EvoSkill, CoEvoSkills
├── 组织检索: SkillGraph, SkillOS, SkillOps
├── 生命周期: AutoSkill, MUSE-Autoskill
└── 文本优化: SkillOpt, SkillCoach
训模型 + 改 Skill（6种）
├── SkillRL, D2Skill, GiGPO
└── AgentEvolver, OPSD
训模型，不改 Skill（2种）
├── EvoAgentX（改 Prompt/拓扑/参数）
└── HyperAgents（改代码）核心思想：把 Skill 当成"可训练的外部参数"，用执行轨迹作为训练数据，用验证集作为门控，迭代优化。区别只在于优化的粒度和是否同时更新模型权重。
Skill 文件是"外部可训练参数"------能改 Skill 就改 Skill，改不动了才考虑后训练。SkillOpt 的实验也证明：只改文本（不训模型），6 个 benchmark 平均就能提升 +23.5 分。