Zach Lloyd (@zachlloydtweets)
2026-06-16
D
原文
---
title: "如何为你的 Skills 构建自我改进循环"
author: "Zach Lloyd (@zachlloydtweets)"
source_url: "https://x.com/zachlloydtweets/status/2066908445425496348"
published_at: "2026-06-16T15:39:09.000Z"
fetched_at: "2026-06-18T23:58:37Z"
updated_at: "2026-06-18T23:58:51Z"
language: "zh"
review_status: "draft"
---
# 如何为你的 Skills 构建自我改进循环
最近大家聊了很多用“循环（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 大概会长这样：
[*完整 triage-issue Skill*](https://github.com/warpdotdev-demos/issue-triage-loop/blob/main/.agents/skills/triage-issue/SKILL.md)
你需要做的是搭起下面这几层 loops：
1. **内层 agent loop**：这里是真正应用 Skill 的地方。以 issue triage 为例，你可以手动运行它；更常见的做法是接入你的任务追踪系统，每当新 issue 被提交时就运行这个 Skill。与 Skill 的交互会被记录在某个地方：文件里、agent trace 里，或者 Slack、Github 这类外部系统的一次 interaction 里。
2. **外层 agent loop**：这是一个按计划运行的 agent，用来观察内层 loop 对 Skill 的使用情况。对于 issue triager 来说，它很可能是一个 cloud agent，会拉取每一次 Triage agent 运行的记录。它的工作是查看内层 agent 的所有运行结果，并根据这些运行表现调整对应的 Skill。由于 Skills 本质上只是文件，这意味着它应该根据过去运行中的用户反馈，生成一个 diff 来改进这个 Skill。
我会用 Warp 和我们的 cloud agent 平台 [Oz](http://oz.dev/) 展示实际怎么做，不过能实现这件事的方法有很多。这里我们会用 Github Issues 作为 issue tracker。
[这里有一个示例 repo](https://github.com/warpdotdev-demos/issue-triage-loop)，里面有可以跟着操作的 Skills 和 GitHub workflows。
### 第 1 步：搭建内层 agent loop
内层 agent loop 使用一个 Github action，在每个新 issue 创建时运行。
[*完整 GitHub Action*](https://github.com/warpdotdev-demos/issue-triage-loop/blob/main/.github/workflows/triage-new-issues.yml)
这个 Github action 会通过 Warp 的 cloud agent 平台 [Oz](https://oz.dev) 调用一个 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，并给出了原因。
[*完整 improve-triage-issue Skill*](https://github.com/warpdotdev-demos/issue-triage-loop/blob/main/.agents/skills/improve-triage-skill/SKILL.md)
由于外层 loop agent 的 Skill 是通过 coding agent 运行的，它会接收我提供的反馈，并生成一个 diff 来更新 triage Skill。
一旦这个 diff 被 merge，它就会反馈回驱动内层 loop agent 的 Skill；下一次 agent 运行时，这个 Skill 应该就会表现得更好。
很想知道这对大家有没有用。我们用 self-improvement loops 管理 Warp 的开源仓库，也把背后的框架抽了出来，方便其他人采用。[早期版本在这里](https://github.com/warpdotdev/oz-for-oss)。