导读
Zach Lloyd（Warp 创始人，前Google Doc首席工程师）分享了如何用「内循环 + 外循环」架构让 AI Agent 持续改进自己的 Skills。内循环负责执行任务（如 Issue 分类），外循环定期审查执行记录、根据人类反馈修改 Skill 文件，形成自我改进的闭环。整套方案基于 GitHub Actions + 云端 Agent 实现，已用于 Warp 开源仓库的日常管理。
最近关于用「循环（loop）」来驱动 Agent 的讨论很多，但我觉得随之而来的一个问题是——「循环」到底是指什么？
我没法代表所有使用这个术语的人发言，但我想展示一种实践方法，利用 Skills 和云端 Agent 来实现一种特别强大的循环：自我改进循环。
这个概念的核心是：Agent 可以根据外部反馈，随时间推移提升自身 Skills 的质量。我的例子中包含了一个人类反馈步骤，但如果你的目标明确且不需要人类参与，同样可以用自动化评估器（automated grader）来实现。
为了说得具体些，假设这个 Skill 负责Issue 分诊（issue triage），将收到的 Issue 分为几类：可以实施（ready-to-implement）、重复（duplicate）、需要补充信息（needs-info）。同样的方法也适用于代码审查 Skill、Bug 修复 Skill、事故响应 Skill 等等。
以下是这个 Skill 的初版草案可能的样子：
你需要搭建以下几个循环：
内循环（inner agent loop）：这是你实际应用 Skill 的地方。对于 Issue 分诊，你可以手动运行，但更可能的做法是通过与任务追踪器的集成，在每次新建 Issue 时自动运行 Skill。与 Skill 的交互记录会被保存到某个地方：文件中、Agent 执行轨迹中，或者 Slack、GitHub 等外部系统的交互记录中。
外循环（outer agent loop）：这是一个按计划运行的 Agent，负责观察内循环中 Skill 的使用情况。对于 Issue 分诊器来说，这通常是一个云端 Agent，会拉取每次分诊 Agent 运行的记录。它的工作是审查内循环 Agent 的所有运行记录，并根据这些运行的表现来调整 Skill。由于 Skills 本质上就是文件，这意味着它应该根据过去运行中的用户反馈生成一个 diff 来改进 Skill。
接下来我用 Warp 和 Oz（我们的云端 Agent 平台）来演示具体实践，但实现方式有很多种。我们将使用 GitHub Issues 作为 Issue 追踪器。
这里有一个示例仓库，包含可以跟着操作的 Skills 和 GitHub Workflows。
第一步：搭建内循环
内循环使用一个 GitHub Action，在每次创建新 Issue 时触发运行。
这个 GitHub Action 通过 Oz（Warp 的云端 Agent 平台）调用一个云端 Agent。该云端 Agent 会同步仓库、从 GitHub 拉取 Issue 内容，然后尝试对其进行分类。具体的设置代码在下面链接的仓库中。
现在，每当一个新 Issue 进来，云端 Agent 就会运行内循环的分诊 Skill，并打上一个标签，表示有一个新的功能请求已经可以实施了。
第二步：搭建用于自我改进的外循环
假设人类审阅者不认同 Agent 的分类结果。作为审阅者，我把 Issue 从「可以实施」改为「需要补充信息」，并在讨论串中评论说明分类错误的原因——比如，对于是否要为这个新功能添加设置项还存在歧义。
这就是外循环变得有趣的地方。外循环 Agent 每天运行一次，检查所有已分诊的 Issue。当它运行时，会发现我手动调整了标签并给出了原因。
由于外循环 Agent 的 Skill 是通过编程 Agent 运行的，它会根据我提供的反馈生成一个 diff 来更新分诊 Skill。
一旦这个 diff 被合并，它就会反馈到驱动内循环 Agent 的 Skill 中，下一次 Agent 运行时，Skill 的表现就会更好。
很想知道这对大家是否有用。我们用自我改进循环来管理 Warp 的开源仓库，并把背后的框架提取出来供其他人采用。早期版本在这里。
