最近大家聊了很多用“循环（loops）”来驱动 agents 的做法，但我感觉这也带来了一点疑问：所谓 loop 到底是什么？
我不能替所有使用这个词的人发言，但我想用 Skills 和 cloud agents 展示一种很实用的做法：自我改进循环。这是一类特别有用的 loop。
它的核心想法是：agent 可以根据外部反馈，随着时间推移不断提高自己 Skills 的质量。我的例子里有一个人类反馈步骤；但如果你的目标很清楚，不需要人参与，同样的方法也可以配一个自动 grader 来用。
为了说得具体一点，假设这个 Skill 负责 issue triage，把新进来的 issues 分到几个桶里：ready-to-implement、duplicate、needs-info。这个方法同样可以用于 code review Skill、bug fixing Skill、incident response Skill，等等。
第一版 Skill 大概会长这样：
你需要做的是搭起下面这几层 loops：
- 内层 agent loop：这里是真正应用 Skill 的地方。以 issue triage 为例，你可以手动运行它；更常见的做法是接入你的任务追踪系统，每当新 issue 被提交时就运行这个 Skill。与 Skill 的交互会被记录在某个地方：文件里、agent trace 里，或者 Slack、Github 这类外部系统的一次 interaction 里。
- 外层 agent loop：这是一个按计划运行的 agent，用来观察内层 loop 对 Skill 的使用情况。对于 issue triager 来说，它很可能是一个 cloud agent，会拉取每一次 Triage agent 运行的记录。它的工作是查看内层 agent 的所有运行结果，并根据这些运行表现调整对应的 Skill。由于 Skills 本质上只是文件，这意味着它应该根据过去运行中的用户反馈，生成一个 diff 来改进这个 Skill。
我会用 Warp 和我们的 cloud agent 平台 Oz 展示实际怎么做，不过能实现这件事的方法有很多。这里我们会用 Github Issues 作为 issue tracker。
这里有一个示例 repo，里面有可以跟着操作的 Skills 和 GitHub workflows。
第 1 步：搭建内层 agent loop
内层 agent loop 使用一个 Github action，在每个新 issue 创建时运行。
这个 Github action 会通过 Warp 的 cloud agent 平台 Oz 调用一个 cloud agent。这个 cloud agent 会同步 repo，拉取 Github 里的 issue 内容，然后尝试对它分类。如何设置这些内容，代码都在下面链接的 repo 里。
现在，当一个新 issue 进来时，cloud agent 会运行内层 loop 的 triaging skill，并打上一个 label，表示这个新 feature request 已经 ready to implement。
第 2 步：搭建用于自我改进的外层 loop
不过，假设人类 reviewer 并不同意 agent 的分配。作为查看 agent 所打 labels 的人，我把这个 issue 从“ready to implement”改成“needs info”，并在线程里加了一条评论，说明为什么它被分错了：比如，因为我们是否应该为这个新功能增加一个 setting 还存在歧义。
这就是外层 loop 开始变得有意思的地方。外层 loop agent 每天运行一次，查看所有已经被 triaged 的 issues；运行时，它会发现我手动调整了 label，并给出了原因。
由于外层 loop agent 的 Skill 是通过 coding agent 运行的，它会接收我提供的反馈，并生成一个 diff 来更新 triage Skill。
一旦这个 diff 被 merge，它就会反馈回驱动内层 loop agent 的 Skill；下一次 agent 运行时，这个 Skill 应该就会表现得更好。
很想知道这对大家有没有用。我们用 self-improvement loops 管理 Warp 的开源仓库，也把背后的框架抽了出来，方便其他人采用。早期版本在这里。