如何为你的 Skills 构建一个自我改进循环

最近，围绕如何用“循环”来驱动 Agent，出现了很多讨论。与此同时，大家也开始产生一个疑问：所谓的 loop，到底指的是什么？

我无法代表所有使用这个术语的人，但我想展示一种非常实用的方法：使用 Skills 和云端 Agent，构建一种特别强大的循环形态，也就是自我改进循环。

所谓自我改进循环，核心思想是：Agent 可以根据外部反馈，持续提升自身 Skills 的质量。

我下面举的例子包含一个人工反馈环节。但如果你有一个清晰目标，并且这个目标不需要人工判断，也可以用同样的方法接入自动评分器。

为了让问题更具体，我们假设有一个 Skill 专门做 issue 分诊，也就是把新进来的 issue 分成几个类别：

待实现

重复问题

需要补充信息

同样的思路，也适用于代码审查 Skill、Bug 修复 Skill、事故响应 Skill 等场景。

一个初版 Skill 大概会是这样：

完整的 triage-issue Skill

你需要做的，是搭建下面两个循环。

内层 Agent 循环：真正执行 Skill

内层 Agent 循环负责实际应用这个 Skill。

以 issue 分诊为例，你可以手动运行它。更常见的方式是，把它和任务跟踪系统集成起来，让它在每次有新 issue 提交时自动运行。

Skill 的每一次交互都会被记录下来。记录位置可以是一个文件，也可以是 Agent trace，或者 Slack、GitHub 这类外部系统中的一次交互。

外层 Agent 循环：观察并改进 Skill

外层 Agent 循环，是一个按计划运行的 Agent。它会观察内层循环中 Skill 的使用情况。

对于 issue 分诊器来说，这通常会是一个云端 Agent。它会拉取每一次 Triage Agent 运行的记录，分析这些运行结果，并根据表现调整它所使用的 Skill。

因为 Skills 本质上就是文件，所以这个 Agent 要做的事情，就是根据过去运行中的用户反馈，为 Skill 生成一个改进 diff。

下面我会用 Warp 和 Oz 来展示这个过程。Oz 是我们的云端 Agent 平台。不过，实现这套机制的方法并不只有这一种。

在这个例子中，我们会使用 GitHub Issues 作为 issue 跟踪系统。

这里有一个示例仓库，里面包含 Skills 和 GitHub workflows，可以跟着操作。

第一步：搭建内层 Agent 循环

内层 Agent 循环使用一个 GitHub Action，在每次有新 issue 创建时运行。

完整的 GitHub Action

这个 GitHub Action 会通过 Oz 调用一个云端 Agent，也就是 Warp 的云端 Agent 平台。

这个云端 Agent 会同步仓库，读取 GitHub 中的 issue 内容，然后尝试对它进行分类。具体如何配置，示例仓库中有对应代码。

这样一来，当一个新 issue 进入系统时，云端 Agent 就会运行内层循环中的 triage Skill，并给这个 issue 打上一个标签，例如表示这是一个已经准备好实现的新功能需求。

第二步：搭建用于自我改进的外层循环

接下来，假设人工审核者不同意 Agent 的判断。

作为查看 Agent 自动分配标签的人，我把这个 issue 从“ready to implement”改成了“needs info”，并在线程中添加了一条评论，说明它为什么被误分类。

比如，这个 issue 之所以不能直接进入实现阶段，是因为我们还不确定是否应该为这个新功能增加一个设置项。

这时，外层循环就变得有价值了。

外层循环 Agent 每天运行一次，查看所有已经完成分诊的 issues。当它运行时，就会发现我手动修改了标签，并且给出了修改原因。

完整的 improve-triage-issue Skill

由于外层循环 Agent 的 Skill 是通过 coding agent 运行的，它会读取我提供的反馈，并生成一个 diff，用来更新 triage Skill。

一旦这个 diff 被合并，它就会反向进入驱动内层循环 Agent 的 Skill 中。

下一次 Agent 再运行这个 Skill 时，它的分诊效果就应该会变得更好。

这套机制的关键价值

这套机制真正有意思的地方在于，它不只是让 Agent 执行任务，而是让 Agent 根据真实反馈持续修正自己的工作方式。

传统自动化通常是一次性写好规则，然后反复运行。

但自我改进循环的逻辑不同：

先让 Skill 执行任务

再记录它的执行结果

然后收集人工或自动反馈

接着由另一个 Agent 分析这些反馈

最后生成对 Skill 本身的改进

这样，Skill 就不再是一个静态脚本，而会逐渐变成一个可以演化的工作系统。

内层循环和外层循环的区别

理解这套方法时，最重要的是区分内层循环和外层循环。

内层循环关注的是执行。

它负责处理具体任务，比如给 issue 分类、做代码审查、修复 Bug、响应事故等。

外层循环关注的是改进。

它不直接处理业务任务，而是观察内层循环的表现，判断 Skill 哪里做得不好，并根据反馈提出修改方案。

也就是说：

内层循环解决问题。

外层循环改进解决问题的方法。

这也是为什么它被称为自我改进循环。

人工反馈和自动评分器

在这个例子中，反馈来自人工审核者。

比如，人工把 Agent 打错的标签改掉，并补充原因。

但如果你的目标足够明确，也可以不依赖人工，而是使用自动评分器。

例如：

代码审查 Skill 可以根据测试是否通过、静态扫描结果、是否引入新缺陷来评估。

Bug 修复 Skill 可以根据复现用例是否通过来评估。

文档生成 Skill 可以根据格式完整性、字段覆盖率、链接有效性来评估。

事故响应 Skill 可以根据是否识别根因、是否生成后续行动项来评估。

只要能把“表现好不好”变成可观察的反馈信号，就可以放进这个自我改进循环里。

为什么 Skills 很适合做这件事

Skills 很适合构建自我改进循环，原因很简单：Skills 本质上就是文件。

这意味着它们可以被读取、比较、修改、提交和合并。

从工程化角度看，一个 Skill 的改进过程和代码改进过程非常接近：

观察运行结果

发现问题

修改文件

生成 diff

发起合并

进入下一轮运行

这让 Agent 不只是执行工具，而可以参与到工具自身的迭代过程中。

一个完整闭环大概是什么样

把整个流程串起来，就是这样：

第一，有一个 Skill 负责具体任务，比如 issue 分诊。

第二，每当新的 issue 创建时，GitHub Action 自动触发云端 Agent。

第三，云端 Agent 调用这个 Skill，对 issue 进行分类并打标签。

第四，人工审核者查看结果，如果不认同，就修改标签并写下原因。

第五，外层 Agent 每天定时运行，拉取这些被修改过的结果和人工反馈。

第六，外层 Agent 分析反馈，判断 Skill 中哪些规则、示例或判断逻辑需要调整。

第七，外层 Agent 生成一个 diff，更新 Skill 文件。

第八，diff 被审核并合并。

第九，下一次内层 Agent 运行时，就会使用改进后的 Skill。

这就是一个完整的自我改进循环。

适合使用自我改进循环的场景

这种方法特别适合那些会重复发生、并且有明确反馈信号的工作。

比如：

Issue 分诊

代码审查

Bug 修复

事故响应

客服工单分类

安全告警分析

文档质量检查

PR 描述生成

需求澄清

知识库整理

这些任务有一个共同特点：一开始很难把规则写得完美，但可以通过大量真实案例不断校正。

自我改进循环的价值，正是把这些校正过程系统化。

不适合的场景

当然，并不是所有任务都适合做自我改进循环。

如果任务很少重复，搭建循环的成本可能不划算。

如果没有清晰的反馈信号，Agent 也很难判断该如何改进。

如果任务高度依赖主观判断，且没有稳定标准，那么自动改进也可能引入噪声。

因此，更适合优先选择那些：

高频出现

结果可评估

反馈可记录

规则可沉淀

改进能复用

的任务来做。

从小规模开始

如果要落地这套机制，不需要一开始就做得很复杂。

可以从一个非常小的 Skill 开始。

比如，只做三分类：

可以直接实现

重复问题

需要补充信息

然后只记录两类反馈：

人工是否修改了标签

人工为什么修改

再让外层 Agent 每天或每周分析这些反馈，并提出 Skill 修改建议。

一开始不一定要让 Agent 自动合并修改。

更稳妥的方式是：

Agent 生成 diff

人类 review

确认后合并

这样既能形成改进循环，又能控制风险。

最后的想法

我很想知道，这套方法对大家是否有帮助。

我们自己正在用自我改进循环来管理 Warp 的开源仓库，并且把背后的框架抽象出来，希望其他人也能采用。

对我来说，这种模式最重要的启发是：

Agent 不应该只是一次性执行任务的工具。

它也可以成为一个持续观察、持续学习、持续改进的系统。

当 Skills、云端 Agent、外部反馈和版本控制结合起来之后，一个团队就可以把很多原本靠人工经验积累的流程，变成可以复用、可以审查、可以持续优化的工程化闭环。