Warp 如何在 Claude 上构建自我改进的 Agent

原文：How Warp builds self-improving agents on Claude

Anthropic 创业公司系列，本文转述自官方博客与同名 Webinar

本文是 Anthropic「创业公司如何用 AI 改造行业」系列的一篇：Warp 把无状态的用户反馈，变成了 Agent 的自我改进闭环。

快速档案

项目	内容
公司	Warp
创立	2020 年
创始人	Zach Lloyd（CEO）
技术栈	Rust、Golang、GitHub Actions、内部 Agent 编排平台 Oz、Claude Platform
规模	融资 7300 万美元；每月 80 万开发者使用；56% 的财富 500 强公司在用；累计运行 1000 万次 Claude Code 会话（每周 40 万+）；Warp Agent 对话总量 4000 万次

问题：反馈会随着会话一起消失

Agent 要可靠地处理重复性任务。一个首跑只对 80% 的提示词，给用户带来的体验是嘈杂而恼人的——Warp 的内部代码评审 Agent 就撞上了这个问题：工程师抱怨它净给出没用的评论，输出质量不稳。

团队最初用土办法：观察到评审翻车后手动改提示词。输出确实更好了，但没法规模化；完善 AGENTS.md 这类上下文文件也有帮助，但远不是彻底解法。

他们最终意识到，真正的问题是：给 Agent 的反馈，无论 Agent 是干什么用的，通常在会话结束时就地蒸发，关键上下文从此脱离了 Agent 循环。他们的解法，是一个基于 Agent Skills 的框架——让反馈随时间复利，持续打磨 Agent 的输出。

核心机制：建立在技能之上的自改进循环

核心技术是用 skills 搭建自改进循环。skills 是知识文件化的编码，把指令从原始提示词里挪出去。Warp 演化出的架构由两个技能组成，中间隔着人类反馈：

Warp 的自改进循环

内层/基础技能承载功能性的领域知识与指令。比如 PR 打开时，Warp 的代码 Agent 就带着这套基础技能和上下文去执行评审。

人类反馈是自改进循环的关键部件。代码评审场景里，一个点赞就够了，但越具体越好。Zach Lloyd 解释道：人类可以简单确认「这条评论不错、有用」，也可以给出详细原因——「你建议重命名这个变量，但我们代码库的约定是这类全局变量用这种命名方式」——这类具体反馈直接教会 Agent 下次怎么做对。

外层/改进技能是一个观察者 Agent，按计划周期运行而非每任务一次。它把积累的人类反馈拉出来，对比 Agent 当时建议了什么、人类实际怎么回应，然后对基础技能提出一次小而聚焦的修改。

因为技能就是普通文件，Agent 更新它们得心应手。这些修改可评审、可批准、可合并，走的是正常的 PR / 代码评审流程；一旦合并，内层技能的下一次运行就自动继承了这次改进。

Warp 现在把这套模式跑在整个开源仓库上：写规格、做评审、做分诊的 Agent 各自带着自己的自改进循环。

「文件化技能就是在为 Agent 编码知识，而不必把这些知识直接塞进提示词——Agent 干活时自己查就行了，」Zach 总结道，「这套框架其实非常简单：一个领域基础技能，加上一个打磨它的改进技能。简单正是这套方法的美妙之处。」

怎么写好自我改进的技能

Warp 团队沉淀的几条实战经验：

写原则，不写规则。 「把技能当成在指导一个聪明人，而不是在给计算机编程。『寻找重复代码』这样的方向性指引，比穷举变量命名规则有效得多。」
解释为什么。 给出规则背后的理由，Agent 就能对问题进行推理而不是死板执行，泛化能力更好。
让反馈顺手到不用想。 在人们已经工作的地方捕获反馈——比如直接在 PR 或 issue 上评论——并且全自动、无额外提交步骤。「低摩擦才有持续的信号。摩擦太大，你既拿不到反馈，也改进不了技能。」
技能要小，用好渐进式披露。 好的技能文件不大；它引用资源文件和脚本，而不是把所有东西一次性倒进上下文。
反馈质量 > 数量，但数量也重要。 一小份资深工程师的详细领域反馈，价值可能超过一堆不走心的点赞/点踩——因为二元反馈说不出「为什么」。不过高质量信号的语料越大越好：Warp 用这套循环管理整个开源仓库，数百人贡献、数千次代码评审。
在改进技能上多花力气。 改进技能（观察者 Agent）的投入产出比极高，因为它跨用例高度可复用——「除了领域知识部分，这套机制相当通用：代码评审 Agent 的改进技能，和任何其他 Agent 的改进技能差别不大。」

实战：Warp 的 issue 分诊 Agent

Warp 的 issue 分诊 Agent 是这套框架的公开演示。有人提交新 GitHub issue 时，GitHub Action 触发 Agent 分析复杂度与可行性、打标签、给出修复方向建议。分诊 Agent 的内层技能文件里，写着每个标签的含义和动手前如何调研代码库。

一个样例 issue 上，第一版内层技能干得不错，但漏打了一个标签——ready to spec（表示贡献者可以开始对着这个 issue 写产品与技术规格）。Warp 的维护者发现了这个缺口，直接在 issue 上留了反馈——就在工作发生的地方。关键在于，他把「期望什么」和「为什么期望」都讲清楚了：这种反馈 Agent 之后最容易吸收。

外层改进技能跑在 Oz（Warp 的 Agent 编排平台）里，是一个定时运行的「更新分诊」Agent。它认证 GitHub，运行技能自带的 Python 脚本拉取近期带反馈的 issue，汇总成 JSON 文件再读回上下文。技能自带脚本本身就是一条最佳实践：技能应该引用资源文件，而不是每次运行都现写代码。

接着，Agent 从维护者评论里识别出具体的反馈信号，提出捕捉这些信号的最小修改：向内层技能发起一个 PR，规定「当 issue 描述了真实问题、但具体 UI/UX 形态未定时，打 ready to spec 标签」。

因为整个更新就是技能文件，它走正常的代码评审流程：PR 附带说明，写清是哪些信号触发了修改、改了什么。人类评审、批准、合并，分诊技能的下一次运行就继承了新知识。最后这步人类把关闭环，保证了「什么能改」始终有人控制。

Warp 如今在自己的开源仓库上规模化运行着同一机制：写规格的、评审的、分诊的 Agent 各带各的自改进循环。

任何 Agent，无论任务是什么，只要从一开始就内建这样的循环——捕获人类反馈信号、把它们变成技能更新——就能随时间变好，从一次性助手成长为在整个组织里复利的能力系统。

Warp 团队的最佳实践清单

问题	建议
你是不是把技能和记忆搞混了？	技能是程序性且稳定的——「怎么做 X」，与运行无关，有意修改。记忆是 Agent 在推理时自动写入、永不停止变化的。
一个改进循环，还是每个 Agent 一个？	折中：模板化的基础循环捕捉各 Agent 的共性，再叠加领域专属权重。几个 Agent 可以各有一个改进器；上百个就该共享了。
反馈是错的怎么办？	默认它会错。别让 Agent 盲目接受反馈——给它做合理性校验的上下文，过滤谁的输入算数，在过滤或终审环节保留人类。
你的领域能验证吗？	先建验证基座，再让 Agent 对着它调优：生成参考语料、对比输出与参考、修复、重复。
领域不可验证呢？	凡有黄金输出就用确定性评估；必须用人类反馈时，限制在领域专家——别放开闸门。
怎么知道整个系统在变好？	追踪人类本来就在看的全局指标——合并时间、贡献者数、成本——并把它们喂回改进 Agent。部署节奏走爬-走-跑。

完整演示与深入讨论见 Anthropic 官方 Webinar。