最近，如何利用“循环”机制驱动Agent成为了圈内热议的话题。同时，一个关键问题也逐渐清晰：大家所讨论的loop，其具体含义究竟是什么？

虽然无法代表所有人的理解，但我可以分享一种非常实用的方法——借助Skills与云端Agent构建一种特别强大的循环形态：自我改进循环。

这套机制的核心思想非常直观：让Agent能够依据外部反馈，持续优化其自身Skills的质量。

下面所举的例子包含了一个人工反馈环节。但如果你拥有一个清晰且无需人工判断的目标，完全可以采用同样的方法接入自动评分器。

为了让讨论更加具体，我们假设有一个专门负责issue分诊的Skill——也就是将新提交的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会通过Oz调用一个云端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、外部反馈和版本控制结合起来之后，一个团队就可以将许多原本依赖人工经验积累的流程，转变为可复用、可审查、可持续优化的工程化闭环。