Loop Engineering 与 Skill 自我进化

核心关系

Loop: https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HNShNmqjgbMxnqVncBhGRbcTjsWAAJfIFxTCvPTJ&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzIxNDk1MDQxNA%3D%3D%26mid%3D2247484071%26idx%3D1%26sn%3Dab92f4f8eb8c101eb9d68cc57dce863a%26scene%3D21#wechat_redirect

Skill: https://mp.weixin.qq.com/mp/wappoc_appmsgcaptcha?poc_token=HOahNmqjHJcL5VzfYzmfhz6Au4IRnGItWY9Tyx2y&target_url=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzIxNDk1MDQxNA%3D%3D%26mid%3D2247484061%26idx%3D1%26sn%3D564038aa2fdfdccb36265788f50f9c51%26scene%3D21#wechat_redirect

Loop 和 Skill 是一对生产者---沉淀者的关系:

  • Loop 产出结果:每轮执行产生 Implementer 的方案、Verifier 的反馈、Orchestrator 的决策
  • Skill 沉淀知识:把多轮 Loop 中反复出现的模式、踩过的坑、有效的做法固化到 SKILL.md
  • Skill 反哺 Loop:下一次 Loop 启动时直接加载 Skill,Implementer 不再重复推导,Verifier 不再重复发现同类问题

没有 Skill 沉淀,Loop 每次都是从零开始;没有 Loop 反馈,Skill 永远是人工编写的静态文档。两者结合才形成自我进化闭环


为什么需要自我进化

静态 Skill 的三个问题:

  1. 滞后 --- 项目演进后,Skill 描述的约定与现实脱节
  2. 盲区 --- 人工编写者意识不到的隐性知识(如某个 API 的隐藏限制)只有 Loop 反复踩坑才能暴露
  3. 粒度错配 --- 人工写的 Skill 偏宏观,Loop 需要的是具体到"调用 X 接口前要先检查 Y"的微观规则

自我进化让 Skill 从人工文档 变成经验数据库


进化机制

进化的来源(数据信号)

信号源 类型 价值
Verifier 反复发现的同类错误 反模式 写入"不要做 X"
Implementer 多次摸索后的有效解 正模式 写入"遇到 Y 时用 Z 方案"
Orchestrator 多次回退的决策点 决策规则 写入"在 W 条件下走分支 A"
Human Gate 的拒绝理由 边界约束 写入"任何涉及 V 的修改需人工"

进化的触发条件

不是每轮 Loop 都更新 Skill,否则会噪声泛滥。常见触发:

  • 频次阈值:同一类问题被 Verifier 捕获 ≥ N 次
  • 回退阈值:某类任务被 Orchestrator 回退率 > 阈值
  • Human Gate 否决:人工拒绝且给出明确理由时强制更新
  • 定期归纳:每 N 轮 Loop 后跑一次 Skill 归纳 Agent

进化的执行者

关键约束 :更新 Skill 的不能是 Implementer 或 Verifier 自己,必须是独立的 Curator Agent(或人工评审)。否则会出现:

  • Implementer 把自己的偏好写进 Skill
  • Verifier 把自己的误判规则化

Curator 的职责:从 Loop 日志中提取候选模式 → 去重 → 评估通用性 → 写入 Skill(或提交 PR 给人工审核)。


Meta-Loop 架构

Loop Engineering 本身有一个外层 Loop------Skill 进化 Loop

复制代码
┌────────────────────────────────────────────────────┐
│  Inner Loop(任务执行)                              │
│  Triage → Implement → Verify → Gate → Done         │
│           ↓ 产生日志、决策、反馈                       │
└────────────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────────────┐
│  Outer Loop(Skill 进化)                            │
│  日志归集 → Curator 提取模式 → 评估通用性 →           │
│  更新 SKILL.md → 人工/自动审核 → 发布新版本           │
└────────────────────────────────────────────────────┘
                    ↓
              新 Skill 注入下一轮 Inner Loop

Inner Loop 是分钟级,Outer Loop 是天/周级。两者节奏不同,但闭环连续。


风险与约束

风险 应对
Skill 噪声膨胀(每轮都写入小修小补) 设置触发阈值,Curator 做去重和合并
Skill 与现实脱节(项目演进后旧规则过时) 给每条规则打时间戳,定期回扫验证
自我强化偏见(Verifier 误判被写入后永久错误) Curator 必须独立,关键更新走 Human Gate
跨项目污染(A 项目的 Skill 被错误应用到 B 项目) Skill 按项目隔离,明确适用范围
Skill 越来越长,token 成本反而上升 设 Skill 大小上限,超出时强制蒸馏

实施建议

起步阶段(先简单)

  1. 先把 Inner Loop 跑稳,确保 Verifier 日志结构化、可解析
  2. 手动归纳前几轮 Loop 的模式,验证哪些值得固化为 Skill
  3. 再写 Curator Agent,让它自动做之前手动做的事

避免过早自动化:Skill 进化机制本身复杂度高,没有足够 Loop 数据时强行上自动化只会引入噪声。先积累 100+ 轮 Loop 日志,看清模式分布,再决定 Curator 的提取规则。