Warp 用两个文件型 skill 造出自我改进的 agent 循环：内层 skill 干活，外层 skill 定期吸收人类反馈、提出小步修改，走 PR 评审合并后，下一次运行自动变好。
*在我们的系列文章中，我们聚焦那些正用 AI 重塑行业的创业公司。这篇文章里，我们分享 Warp 如何把"会话结束即消失"的用户反馈，变成 agent 的自我改进闭环。*
| 快速一览 | |
|---|---|
| 名称 | Warp |
| 成立时间 | 2020 |
| 创始人 | Zach Lloyd（CEO） |
| 技术栈 | Rust、Golang、GitHub Actions、内部 agent 编排平台（Oz）、Claude Platform |
| 增长 | 融资 $73M。每月 80 万开发者基于 Warp 构建。财富 500 强中 56% 使用 Warp。至今已有 1000 万次 Claude Code 会话运行在 Warp 内，每周超过 40 万次。Warp Agent 累计对话 4000 万次。 |
Agent 需要可靠、高效地处理重复性任务。一个首版提示词能答对 80% 的任务，就可能给用户带来嘈杂、恼人的体验。Warp 切身体会到了这一点，并把它带进了产品策略，为全球近 100 万开发者创造了更优的体验。
Warp 是一个 AI 驱动的终端与 agent 化开发环境，构建在 Claude Platform 之上。团队在内部代码评审 agent 上遇到了这个"嘈杂体验"问题。工程师抱怨 agent 的评论没有帮助，输出质量低下。
团队最初尝试了权宜之计，比如根据观察到的评审失败手动重写提示词。这让输出更可用，却无法规模化。改进 AGENTS.md 这类上下文文件也有帮助，但远非完整解法。
最终他们意识到，真正的问题在于：无论用途如何，给 agent 的反馈通常会在会话结束时消失，把关键上下文从 agent 循环中剥离。他们的解决方案：一个基于 Agent Skills 的框架，用来创建自我改进的 agent——反馈随时间复利累积，不断细化和增强 agent 的输出。
继续读下去，看看他们如何在 Claude Platform 之上用 skills 构建了这套体系。
基于 skills 的 agent 自我改进循环
核心技巧是一个基于 skills 的自我改进循环。Skill 是把知识编码成文件的方式，让指令不塞进原始提示词里。Warp 演化出一套自我改进的 agent 架构：由两个 skill 组成，中间夹着人类反馈。
内层/基础 skill 承载功能性的领域知识与指令。例如，每次打开一个 PR，Warp 的代码 agent 就基于这个基础 skill 和上下文执行，产出它的评审。
对人类输出的人类反馈是自我改进循环的关键组件。对代码评审来说，反馈可以简单到点个赞，但越明确越好。
Warp 创始人 Zach Lloyd 解释说："人可以肯定地说'这是一条不错、有用的评论'，也可以详细说明一次代码评审为什么不好。比如'你建议重命名这个变量，但我们代码库的约定是，这类全局变量用这种特定的命名上下文'——这些细节会告诉 agent 下次该怎么做对。"
外层/改进 skill 扮演观察者 agent 的角色，它按计划运行，而不是每个任务都跑。它拉取累积的人类反馈，对比 agent 的建议和人类的回应，然后对基础 skill 提出一处小而聚焦的修改。
因为 skill 就是普通文件，agent 非常擅长更新它们。这些更新可审查、可批准、可合并，能走常规的 PR/代码评审流程；一旦合并，内层 skill 的下一次运行就会继承这个改进。
Warp 现在把这一模式运行在它的整个开源仓库上，分别有 spec 编写 agent、评审 agent 和分流 agent，每个都带着自己的自我改进循环。
Zach 说："文件型 skill 是一种为 agent 编码知识的方式，不必把知识直接写进提示词里，agent 在干活的过程中查一下就能拿到。"他接着说，"这套框架其实非常简单：有一个承载具体领域的 base skill，还有一个改进它的 improver skill。这种简单正是这个方案的美妙之处。"
如何为 agent 编写自我改进的 skill
以下是 Warp 团队编写 agent 循环自我改进 skill 的几条久经验证的技巧：
- 写原则，不写规则。 Zach 说："编写 skill 时，要像在指导一个聪明人，而不是在给计算机编程。在 skill 里写'寻找重复代码'这样的方向，比穷举变量命名规则更能提供好的指引。"
- 解释为什么。 给出规则背后的理由，让 agent 能推理问题本身，而不是机械地执行死指令，这也让泛化能力更好。
- 让反馈随手可给。 在人们本来就在工作的地方采集反馈，比如直接在 PR 或 issue 上评论。而且要做到自动发生，无需额外的提交步骤。Zach 说："低摩擦才能让信号持续流动。如果门槛太高，你得不到反馈，也就没法改进 skill。"
- 保持 skill 小而精，使用渐进式披露。 一个好的 skill 文件并不大；它引用资源文件和脚本，而不是把所有东西一次性倒进上下文。
- 反馈质量 > 数量，但数量也有帮助。 一位资深工程师给出的少量、具体、领域相关的反馈，可能比大量敷衍的反馈更有价值，因为二元的点赞/点踩说明不了*为什么*。Zach 继续说："即使样本量相对较小，只要反馈来自掌握领域知识的人、足够具体——而这些知识 agent 本来无从获取——你就能得到非常好的信号。话虽如此，高质量信号语料越大越好。在 Warp，我们用一个循环管理整个开源仓库，有几百人参与贡献，我们每天做几千次代码评审。"
- 在 improver skill 上多下功夫。 在编写 improver skill（观察者 agent）上多投入，回报会超出当下的 agent 循环本身，因为 improver skill 在各种用例之间高度可复用。Zach 说："除了领域知识组件之外，这套机制相当通用——代码评审 agent 的 improver skill，和其他任何 agent 的 improver skill 差别并不大。"
循环实战：Warp 的 issue 分流 agent
Warp 的 issue 分流 agent 展示了这套自我改进 agent skill 框架。每当有人提交新的 GitHub issue，模式就会被触发：一个 GitHub Action 唤起一个 agent，分析 issue 的复杂度和可行性，打上标签，并对修复方向提出建议。这个分流 agent 运行在一个内层 skill 文件之上，里面装着领域知识：每个标签的含义，以及行动之前如何调研代码库。
在一个示例 issue 上，第一阶段的 inner skill 干得不错，但漏掉了一个标签——ready to spec，它表示贡献者可以开始针对该 issue 编写产品和技术的 spec。Warp 团队的一位维护者发现了这个缺口，直接在该 issue 上留下了反馈——就在工作发生的地方。关键是，他既说明了期望什么，也解释了为什么期望：这样的反馈可执行，agent 之后很容易吸收。
外层 improver skill 运行在 Oz——Warp 的 agent 编排平台 上，作为一个按计划执行的"更新分流"agent。它通过 GitHub 认证，运行随 skill 捆绑的 Python 脚本拉取近期带有反馈的 issue，把摘要汇总成 JSON 文件，再读回上下文。捆绑脚本本身就是一个最佳实践：skill 可以引用资源文件，而不是每次运行都写新代码。
接下来，agent 识别出维护者评论中的具体反馈信号，提出能捕捉这些信号的最小编辑。它开启了一个 PR 修改 inner skill：当一个 issue 描述的是真实问题、即使具体 UI 或 UX 形态尚未确定时，也应用 ready to spec 标签。
由于整个更新就是一个 skill 文件，它走的是常规代码评审流程。PR 带着一段描述到达：说明哪些信号促成了这次改动、改动了什么。人类审查、批准、合并，分流 skill 的下一次运行就继承了新知识。这最后一步人类操作闭合了整个循环，也让真正发生变化的内容保持在人的掌控之中。
这正是 Warp 现在在其开源仓库中规模化运行的机制：spec 编写 agent、评审 agent 和分流 agent，各自带着自己的自我改进循环。
任何 agent，无论任务是什么，只要从一开始就给它构建这样的循环——捕获人类反馈信号、把它们变成 skill 更新、让 agent 从一次性助手成长为能在整个组织内复利累积的完备系统——它都会随时间变得越来越好。
*观看完整网络研讨会*，里面有现场演示和对 Warp 如何用 Claude 构建自我改进 agent 的更深入讨论。
今天就开始用 Claude Platform 构建吧。