Warp 如何在 Claude 上构建自我改进的智能体

了解 Warp 如何设计出一种简单的开发模式，任何人都可以用它来打造能够自我改进的 AI 智能体。

在我们的系列文章中，我们聚焦初创企业如何借助 AI 变革所在行业。本文中，我们分享 Warp 如何将无状态的用户反馈转化为其智能体的自我改进闭环。

快速概览
公司名称	Warp
成立时间	2020 年
创始人	Zach Lloyd（CEO）
技术栈	Rust、Golang、GitHub Actions、内部智能体编排平台（Oz）、Claude Platform
发展数据	累计融资 7300 万美元。每月有 80 万开发者基于 Warp 进行开发。财富 500 强中有 56% 的公司使用 Warp。迄今为止，Warp 内已运行 1000 万次 Claude Code 会话，每周超过 40 万次。Warp Agent 累计对话量达 4000 万次。

智能体需要可靠且高效地处理重复性任务。如果第一轮提示词只能把任务做对 80%，就会给用户带来嘈杂、恼人的体验。Warp 在这方面吃过苦头，并以此为依据制定了产品策略，为全球近 100 万开发者打造了更优质的体验。

Warp 是一款 AI 驱动的终端和智能体开发环境，构建在 Claude 平台之上。该团队在内部代码审查智能体上遇到了这个“嘈杂体验”的问题。工程师们抱怨他们的智能体会发表无用的评论，产出低质量的输出。

团队最初尝试了一些权宜之计，比如根据观察到的代码审查失败案例手动重写提示词。这让输出更可用，但无法规模化。改进 AGENTS.md 等上下文文件也有帮助，但远非彻底的解决方案。

最终，他们意识到，真正的问题在于：无论反馈的目的是什么，给智能体的反馈通常会在会话结束时消失，从而从智能体循环中移除关键上下文。他们的解决方案是：一个基于 Agent Skills 的框架，用于打造自我改进的智能体，让反馈随时间不断累积，持续精炼和提升智能体的输出。

继续阅读，了解他们如何利用 Claude 平台上的技能（Skills）构建这一系统。

基于技能（Skills）的智能体自我改进循环

其核心技术是一个自我改进循环，采用技能，即基于文件的知识编码方式，将指令从原始提示词中剥离出来。Warp 演化出了一种由两个技能组成的自我改进智能体架构，并在其间引入人工反馈。

内部/基础技能承载功能性领域知识与指令。例如，当有 PR 被创建时，Warp 的代码智能体会依据该基础技能并结合上下文来执行代码审查。

针对智能体输出提供的人工反馈是自我改进循环中的关键组成部分。就代码审查而言，反馈可以简单到只是一个点赞，但反馈越具体明确，效果就越好。

“人类可以表示认可，‘这是一条有用且质量高的评论’，”Warp 创始人 Zach Lloyd 解释道，“但人类同样可以给出详细理由，说明某次代码审查为何不够好。像‘你建议重命名这个变量，但我们代码库的约定是这类全局变量采用这种特定的命名方式’这样的具体反馈，能告诉智能体下次该如何做对。”

外部/改进技能充当观察者智能体，它按计划定时运行，而非针对单个任务触发。它会汇总积累的人工反馈，将智能体此前给出的建议与人类的回应进行比对，然后对基础技能提出一处小而聚焦的修改。

由于技能是纯文本文件，智能体非常擅长更新它们。这些更新是可审查、可批准、可合并的，能够通过常规的 PR/代码审查流程流转；一旦合并，内部技能的下一次运行就会继承这一改进。

Warp 现在已将该模式应用于其整个开源代码库，分别设有专门的规格编写、审查和分诊智能体，每个智能体都带有自己的自我改进循环。

“基于文件的技能是一种为智能体编码知识的方式，无需将这些知识直接放入提示词中，而是让智能体在执行任务过程中随时查阅，”Zach 表示。“这个框架其实非常简单：有一个基础的领域特定技能，然后有一个改进者技能来优化该领域特定技能。这种简单性正是该方法的精妙之处。”

如何为智能体编写自我改进技能

以下是 Warp 团队在编写用于智能体循环的自我改进技能方面一些久经考验的实用建议：

写原则，而不是规则。“构建技能时，要像在指导一位聪明人那样，而不是像在给计算机编程，”Zach 说。“在技能中加入诸如‘寻找重复代码’这样的方向性指引，比详尽的变量命名规则能提供更好的指导。”
解释背后的原因。提供规则背后的逻辑，能让智能体对问题进行推理，而不是死板地遵循指令，这同样有助于更好的泛化。
让反馈的提供变得毫不费力。]在人们已经工作的场景中捕捉反馈，比如直接在 PR 或 issue 上评论。同时，让这个过程自动发生，无需额外的提交步骤。“低摩擦是保持信号流动的关键，”Zach 指出。“如果你把流程弄得太麻烦，你就得不到反馈，也就无法改进技能。”
保持技能小巧，并采用渐进式披露。 一个好的技能文件并不大；它引用资源文件和脚本，而不是一次性把所有内容都塞进上下文。
反馈质量重于数量，但数量也有帮助。来自资深工程师的少量、详细且领域特定的反馈，其价值可能超过大量草率的反馈，因为简单的好评/差评无法说明原因。“即使样本量相对较小，只要反馈来自对领域特定知识有深入了解的人，而这些知识是智能体本身无法获取的，你就能获得非常好的信号，”Zach 继续说道。“话虽如此，高质量信号的语料库越大越好。在 Warp，我们使用一个循环来管理我们整个开源仓库。我们有数百人参与贡献，并且我们正在进行数千次代码审查。”
在改进技能（improver skill）上多下功夫。在编写改进技能（即观察者智能体）上多花精力，其回报会超出即时智能体循环本身，因为改进技能在不同用例之间具有很高的可复用性。"除了领域特定知识组件之外，这是一种相当可复用的机制——代码审查智能体的改进技能与其他任何智能体的改进技能并没有太大区别。"

循环实战：Warp 的问题分类智能体

Warp 的问题分类智能体展示了自我改进智能体技能框架的实际应用。每当有人提交新的 GitHub issue 时，该模式就会被触发：一个 GitHub Action 启动智能体，分析 issue 的复杂度和可行性，分配标签，并建议修复方向。该分类智能体基于一个内部技能文件运行，其中包含关于每个标签含义以及如何在行动前研究代码库的领域知识。

在一个示例 issue 上，第一阶段的内部技能表现不错，但漏掉了一个标签——"ready to spec"（可开始编写规格），该标签表示贡献者可以针对该 issue 开始编写产品和技术规格。Warp 团队的一位维护者发现了这个缺口，并直接在 issue 上留下了反馈，恰好就在工作发生的地方。关键在于，他既解释了自己的期望，也说明了为什么有这样的期望：这种可操作的反馈便于智能体日后吸收。

外层改进技能在 Oz，Warp 的智能体编排平台中运行，作为一个定时执行的“更新分诊”智能体。该智能体通过 GitHub 认证，运行了技能附带的 Python 脚本以拉取带有反馈的最新 issue，将它们汇总为 JSON 文件，并读回上下文。附带脚本本身就是一种最佳实践；技能可以引用资源文件，而不必在每次运行时都编写新代码。

从那里开始，智能体识别了维护者评论中的具体反馈信号，并提出了能捕捉这些信号的最小改动。它开启了一个 PR，编辑内层技能，使其在 issue 描述了一个真实问题（即便确切的 UI 或 UX 形态尚未定义）时应用“ready to spec”标签。

由于整个更新就是一个技能文件，它走的是常规的代码审查流程。PR 到达时附有描述，说明哪些信号触发了改动以及改动了什么。由人类进行审查、批准并合并，下一次分诊技能运行便会继承新知识。这最后的人类步骤闭环了整个流程，并确保人对实际发生的变化保持掌控。

这正是 Warp 现在在其开源仓库中大规模运行的机制——在那里，规格编写智能体、审查智能体和分诊智能体各自携带自己的自我改进循环。

任何智能体，无论其任务是什么，只要从一开始就构建这样一个循环——捕捉人类反馈信号、将其转化为技能更新、把智能体从一次性助手扩展为能在整个组织中持续累积能力的系统——它就会随着时间推移不断变好。

来自 Warp 团队的最佳实践
你是否把技能与记忆混为一谈了？	技能是程序性的、稳定的——即“如何做某件事”，与运行无关，需要刻意修改。记忆则是智能体在推理时自动写入的，并且永远不会停止变化。
你需要一个改进循环，还是每个智能体各配一个？	折中方案：一个模板化的基础循环捕获各智能体之间的共性，再叠加领域特定的权重。少数几个改进器可以各自拥有一个循环；上百个改进器则应共享一个。
当反馈本身是错误的时候怎么办？	假设它一定会出错。不要让智能体盲目接受反馈——给它足够的上下文进行合理性检查，过滤哪些输入才值得采纳，并在过滤或最终审核阶段保留人工参与。
你的领域是可验证的吗？	先构建验证框架，再让智能体针对它进行调优：生成参考语料库，将输出与参考进行比对，修复，然后重复。
如果领域不可验证呢？	在存在黄金输出的地方，尽量依赖确定性评估。在必须使用人工反馈的地方，将其限制在领域专家范围内——不要敞开大门。
你如何知道整个系统正在改进？	跟踪人类已经在关注的全局指标——合并时间、贡献者数量、成本——并将它们反馈给改进型智能体。在部署上采取爬行-行走-奔跑的渐进策略。

观看完整网络研讨会，了解Warp如何利用Claude构建能够从团队反馈中学习并随时间自我改进的智能体的现场演示和深入讨论。

视频 · 前往原文观看