如何为你的 Skill 构建自我改进循环

如何为你的 Skill 构建自我改进循环 如何为你的 Skill 构建自我改进循环 Modified June 17 triage issue Skill 初稿 完整 triage issue Skill：https://github.com/warpdotdev demos/issue triage loop/blob/main/.agents/skills/triage issue/SKILL.md 你需要搭好下面这两层循环： 1. 内层智能体循环：这里是真正应用 Skill 的地方。以 Issue 分流为例，你可以手动运行它；更常见的做法是把它接入任务跟踪系统，让每次有新 Issue 创建时自动运行这个 Skill。与 Skill 的交互记录会保存在某个地方：文件、智能体轨迹，或者 Slack、GitHub 这类外部系统里的交互记录。 2. 外层智能体循环：这是一个按计划运行的智能体，用来观察内层循环如何使用 Skill。对 Issue 分流器来说，它很可能是一个云端智能体，会拉取每一次分流智能体运行时留下的记录。它的职责是查看内层智能体的所有运行结果，并根据这些运行表现调整 Skill。由于 Skill 本质上只是文件，这意味着它应该基于过去运行中的用户反馈，生成一份变更差异来改进 Skill。 我会用 Warp 和我们的云端智能体平台 Oz 演示实际做法，但实现方式有很多种。这里我们会用 GitHub Issues 作为问题跟踪系统。 这里有一个示例仓库，里面包含可以跟着操作的 Skill 和 GitHub 工作流。 第 1 步：搭建内层智能体循环 内层智能体循环使用一个 GitHub Action，每当有新 Issue 创建时就运行。 内层智能体循环 完整 GitHub Action：https://github.com/warpdotdev demos/issue triage loop/blob/main/.github/workflows/triage new issues.yml 这个 GitHub Action 会通过 Warp 的云端智能体平台 Oz 调用一个云端智能体。这个云端智能体将同步仓库，读取 GitHub 里的 Issue 内容，然后尝试给它分类。如何搭建这部分的代码，在下面链接的仓库里可以看到。 现在，当一个新 Issue 进来时，云端智能体会运行内层循环的分流 Skill，并打上标签，表示这是一个可以开始实现的新功能请求。 新 Issue 自动分流 第 2 步：搭建用于自我改进的外层循环 不过，假设人工审查者并不同意智能体分配的标签。作为查看智能体标签的人，我把 Issue 从“待实施”改成“需要补充信息”，并在线程里添加一条评论，说明它为什么被误分类，比如：我们是否应该为这个新功能增加一个设置项，这一点还存在歧义。 人工反馈修正标签 这就是外层循环变得有意思的地方。外层循环智能体每天运行一次，查看所有已经被分流过的 Issue；当它运行时，会发现我手动调整了标签，并给出了原因。 外层循环读取反馈 完整 improve triage issue Skill：https://github.com/warpdotdev demos/issue triage loop/blob/main/.agents/skills/improve triage skill/SKILL.md 由于外层循环的智能体 Skill 是通过编码智能体运行的，它会接收我提供的反馈，并生成一份变更差异，用来更新分流 Skill。 生成 Skill 改进变更 一旦这份变更合并，它就会反馈到驱动内层循环智能体的 Skill 里。下一次智能体运行这个 Skill 时，效果应该会更好。 改进反馈回内层循环 很想知道这对大家有没有帮助。我们用自我改进循环来管理 Warp 的开源仓库，并把背后的框架抽取出来，方便其他人采用：早期版本在这里。 Oz Oz 早期版本在这里 完整 triage issue Skill：https://github.com/warpdotdev demos/issue triage loop/blob/main/.agents/skills/triage issue/SKILL.md 你需要搭好下面这两层循环： 1. 内层智能体循环：这里是真正应用 Skill 的地方。以 Issue 分流为例，你可以手动运行它；更常见的做法是把它接入任务跟踪系统，让每次有新 Issue 创建时自动运行这个 Skill。与 Skill 的交互记录会保存在某个地方：文件、智能体轨迹，或者 Slack、GitHub 这类外部系统里的交互记录。 2. 外层智能体循环：这是一个按计划运行的智能体，用来观察内层循环如何使用 Skill。对 Issue 分流器来说，它很可能是一个云端智能体，会拉取每一次分流智能体运行时留下的记录。它的职责是查看内层智能体的所有运行结果，并根据这些运行表现调整 Skill。由于 Skill 本质上只是文件，这意味着它应该基于过去运行中的用户反馈，生成一份变更差异来改进 Skill。 我会用 Warp 和我们的云端智能体平台 Oz 演示实际做法，但实现方式有很多种。这里我们会用 GitHub Issues 作为问题跟踪系统。 Oz 这里有一个示例仓库，里面包含可以跟着操作的 Skill 和 GitHub 工作流。 这里有一个示例仓库 第 1 步：搭建内层智能体循环 内层智能体循环使用一个 GitHub Action，每当有新 Issue 创建时就运行。 完整 GitHub Action：https://github.com/warpdotdev demos/issue triage loop/blob/main/.github/workflows/triage new issues.yml 这个 GitHub Action 会通过 Warp 的云端智能体平台 Oz 调用一个云端智能体。这个云端智能体将同步仓库，读取 GitHub 里的 Issue 内容，然后尝试给它分类。如何搭建这部分的代码，在下面链接的仓库里可以看到。 Oz 现在，当一个新 Issue 进来时，云端智能体会运行内层循环的分流 Skill，并打上标签，表示这是一个可以开始实现的新功能请求。 第 2 步：搭建用于自我改进的外层循环 不过，假设人工审查者并不同意智能体分配的标签。作为查看智能体标签的人，我把 Issue 从“待实施”改成“需要补充信息”，并在线程里添加一条评论，说明它为什么被误分类，比如：我们是否应该为这个新功能增加一个设置项，这一点还存在歧义。 这就是外层循环变得有意思的地方。外层循环智能体每天运行一次，查看所有已经被分流过的 Issue；当它运行时，会发现我手动调整了标签，并给出了原因。 完整 improve triage issue Skill：https://github.com/warpdotdev demos/issue triage loop/blob/main/.agents/skills/improve triage skill/SKILL.md 由于外层循环的智能体 Skill 是通过编码智能体运行的，它会接收我提供的反馈，并生成一份变更差异，用来更新分流 Skill。 一旦这份变更合并，它就会反馈到驱动内层循环智能体的 Skill 里。下一次智能体运行这个 Skill 时，效果应该会更好。 很想知道这对大家有没有帮助。我们用自我改进循环来管理 Warp 的开源仓库，并把背后的框架抽取出来，方便其他人采用：早期版本在这里。 早期版本在这里 原帖链接：https://x.com/zachlloydtweets/status/2066908445425496348 原帖链接：https://x.com/zachlloydtweets/status/2066908445425496348 最近大家对用“循环”驱动智能体讨论很多，同时也伴随着一点疑问：“循环到底是什么？” 我不能代表所有使用这个词的人，但我想展示一种实际做法：用 Skill 和云端智能体，构建一种特别强大的循环，也就是自我改进循环。 它的核心是：智能体可以根据外部反馈，逐步提升自己 Skill 的质量。我的例子里包含一个人工反馈步骤；但如果你有一个不需要人工参与的明确目标，可以使用同样的方法，借助自动评分器来实现。 为了说得更具体，假设这个 Skill 用来做 Issue 分流，把新提交的问题分到几个类别里：待实施、重复问题、需要补充信息。这个思路同样适用于代码审查 Skill、Bug修复 Skill、事故响应 Skill，等等。 这个 Skill 的第一版可能长这样：