转译：
了解 Warp 如何摸索出一套简单的开发模式，任何人都可以用它来打造会自我改进的智能体。
译自 Anthropic 官方博客
原标题：How Warp builds self-improving agents on Claude
作者：Michael Segner ｜ 原文发布：2026年8月26日
在我们的创业案例系列里，我们会介绍创业公司如何用 AI 改写所在行业。本文分享 Warp 如何把一次性、无法沉淀的用户反馈，变成智能体的自我改进闭环。
速览 | |
|---|---|
名称 | Warp |
成立 | 2020 |
创始人 | Zach Lloyd（CEO） |
技术栈 | Rust、Golang、GitHub Actions、内部智能体编排平台 Oz、Claude 平台 |
增长 | 已融资 7300 万美元。每月有 80 万开发者在 Warp 上构建。财富 500 强中有 56% 在用 Warp。迄今已在 Warp 内跑过 1000 万次 Claude Code 会话，每周超过 40 万次。Warp Agent 对话累计 4000 万次。 |
智能体要把反复出现的任务做稳、做对。第一版提示词哪怕能把任务做对 80%，对用户来说也可能又吵又烦。Warp 吃过这个亏，也据此调整了产品策略，让全球近 100 万开发者用上了更好的体验。
Warp 是一款 AI 驱动的终端和智能体化开发环境，构建在 Claude 平台（Claude Platform）之上。团队内部的代码评审智能体就撞上了这种「吵闹体验」：工程师抱怨它爱留没用的评论，产出质量也低。
一开始他们用权宜之计，比如根据观察到的评审翻车案例，手工改提示词。输出是好用了一些，但扩不了规模。把 AGENTS.md 这类上下文文件写得更好，也有帮助，但远远谈不上彻底修好。
他们最终意识到，真正的问题在于：无论智能体干什么，给它的反馈通常会随会话结束而消失，关键上下文就这样从智能体循环里被抽走了。他们的解法：基于 Agent Skills（给智能体用的技能文件）搭一套框架，让智能体会自我改进——反馈随时间累积，持续打磨、提升产出。
接着往下看，他们是如何用技能，在 Claude 平台上把这件事做出来的。
建在技能之上的智能体自我改进闭环
核心手法是用 技能（Skills） 做自我改进闭环。技能是把知识编码成文件，让指令不必塞进原始提示词。Warp 演进出来的自我改进架构由两项技能组成，中间夹着人类反馈。
内层/基础技能 装着领域知识和操作指令。比如有人开了 PR（拉取请求），Warp 的代码智能体就会带着这项基础技能和上下文去跑，给出评审。
人类反馈 是闭环里的关键一环。代码评审里，简单到点个赞也行，但写得越具体越好。
「人可以确认：这条评论又好又有用。」Warp 创始人 Zach Lloyd 解释，「也可以详细说明这次代码评审为什么不好。比如『你建议重命名这个变量，但我们代码库的约定是，这类全局变量要用这种命名』——这就告诉智能体下次该怎么做对。」
外层/改进技能 扮演观察者智能体，按计划跑，而不是每个任务都跑一次。它拉取积累下来的人类反馈，把智能体当时的建议和人的反应对照，然后给基础技能提一处小而准的修改。
技能就是普通文件，智能体特别擅长改它们。这些改动可审、可批、可合并，能走正常的 PR / 代码评审流程；一旦合并，内层技能下一次运行就会继承这次改进。
Warp 现在把这套模式跑在整个开源仓库上：规格撰写、评审、分诊各有独立智能体，每套都带着自己的自我改进闭环。
「基于文件的技能，是给智能体编码知识的一种方式，不用把知识直接写进提示词，智能体干活时自己去查就行。」Zach 说，「框架其实非常简单：一边是领域相关的基础技能，一边是去打磨这项基础技能的改进技能。这种简单，正是这套方法的漂亮之处。」
怎么给智能体写会自我改进的技能
下面是 Warp 团队写自我改进技能、搭智能体闭环时验证过的经验：
写原则，别写死规则。 「写技能时，要像在指导一个聪明人，而不是在给电脑编程。」Zach 说。「技能里写『去找重复代码』，往往比穷尽变量命名规则更能指路。」
把为什么讲清楚。 把规则背后的理由写上，智能体就能对着问题推理，而不是死跟指令，泛化也会更好。
让反馈给得毫不费力。 在人本来就干活的地方采集，比如直接在 PR 或 Issue 上评论。而且要自动发生，别再加一道提交步骤。「摩擦力低，信号才会持续进来。」Zach 指出。「弄得太麻烦，你就收不到反馈，技能也改不好。」
技能要小，并用渐进式披露。 一份好技能 文件并不大；它引用资源文件和脚本，而不是一次把所有东西倒进上下文。渐进式披露（progressive disclosure），就是先给目录，用到再加载细节。
反馈质量重于数量，但量也有用。 资深工程师给的一小段详细、领域相关的反馈，往往比大量敷衍反馈更值钱，因为赞/踩这种二元信号不说为什么。「哪怕样本量不大，只要是人围绕领域知识给出的非常具体的反馈，信号就会很强——这些知识智能体本来无从获得。」Zach 接着说。「话虽如此，高质量信号的语料越大越好。在 Warp，我们用这套闭环管整个开源仓库。有几百人在贡献，我们在做成千上万次代码评审。」
多花力气写改进技能。 把改进技能（观察者智能体）写扎实，收益会超出当前这一条智能体闭环，因为改进技能在不同场景里很好复用。「去掉领域知识那一块，这套机制相当通用——代码评审智能体的改进技能，和其他智能体的改进技能差不了太多。」
闭环实战：Warp 的 Issue 分诊智能体
Warp 的 Issue 分诊智能体 演示了这套会自我改进的技能框架。只要有人新提 GitHub Issue，模式就会被触发：GitHub Action 拉起一个智能体，分析 Issue 的复杂度和可行性，打标签，并建议修复方向。这个分诊智能体靠一份内层技能文件运行，里面装着每个标签是什么意思、动手前该怎么检索代码库。
在一个样例 Issue 上，第一阶段的内层技能做得不错，但漏了一个标签：ready to spec（可以开始写产品和技术规格）。这个标签表示贡献者可以开始针对该 Issue 写产品和规格了。Warp 团队的一位维护者发现了缺口，直接在 Issue 上留了反馈——正是工作发生的地方。关键是，他既写了自己期望什么，也写了为什么这样期望：这种可执行的反馈，智能体之后很容易吸收。
外层改进技能跑在 Oz，Warp 的智能体编排平台 上，是一个定时的「update triage」（更新分诊）智能体。它登录 GitHub，运行技能捆绑的 Python 脚本，拉取最近带反馈的 Issue，汇总成 JSON 文件，再读回上下文。捆绑脚本本身就是最佳实践：技能可以引用资源文件，而不必每次运行都现写代码。
接着，智能体从维护者评论里识别出具体反馈信号，提出能抓住这些信号的最小改动。它开了一个 PR，改内层技能：当 Issue 描述的是一个真实问题，即使具体 UI 或 UX 形态还没定，也打上 "ready to spec" 标签。
因为整次更新就是一份技能文件，它走正常的代码评审流程。PR 带来的说明会写清哪些信号促成了这次改动、改了什么。人审、人批、人合并，下一次分诊技能运行就会继承新知识。最后这一步人类把关，闭环才算合上，真正改了什么，始终由人说了算。
这就是 Warp 现在在开源仓库上规模化运行的同一套机制。规格撰写智能体、评审智能体、分诊智能体，各自带着自己的自我改进闭环。
任何智能体，无论任务是什么，只要从一开始就内置这样一套闭环——捕获人类反馈信号，变成技能更新——就会随时间变强，从一次性助手长成能在整个组织里复利增长的系统。
Warp 团队的最佳实践 | |
|---|---|
你是不是把技能和记忆混为一谈了？ | 技能是程序性的、稳定的——「怎么做 X」，跟单次运行无关，改动是有意为之。记忆是智能体在推理时自动写入的，而且一直在变。 |
到底要一套改进闭环，还是每个智能体一套？ | 折中：用模板化的基础闭环抓住各智能体的共性，再叠领域相关的权重。改进器就那么几个，可以各管一套；要是上百个，就该共享。 |
反馈是错的怎么办？ | 假定它会错。别让智能体盲目接受反馈——给它上下文去做合理性检查，过滤谁的意见算数，并在过滤或终审阶段把人留在环内。 |
你的领域可验证吗？ | 先把验证套件建好，再让智能体对着它调：生成参照语料，拿产出跟参照比，修好，再来一轮。 |
如果领域不可验证呢？ | 能对着黄金标准输出做确定性评测的地方，就尽量用。必须用人类反馈时，只开放给领域专家——别把闸门全打开。 |
怎么知道整套系统在变好？ | 跟踪人本来就会盯的全局指标——合并耗时、贡献者数量、成本——再喂回改进智能体。部署按爬、走、跑推进。 |
观看完整网络研讨会，看现场演示，并更深入讨论 Warp 如何用 Claude 打造能从团队反馈中学习、自我改进的智能体。
今天就开始用 Claude 平台 构建。