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

Warp 的内部代码审查 agent 一度产出大量低质量评论，团队手工改 prompt、完善上下文文件都没能规模化解决。他们最终的答案是：用两个 Agent Skill 加上人工反馈，组成一个自我改进的循环。这篇文章来自 Anthropic 官方博客，Warp 创始人 Zach Lloyd 详细拆解了这个模式，任何团队都可以照着做。

背景

Warp 是 AI 驱动的终端和 agent 开发环境，2020 年成立，累计融资 7300 万美元，月活开发者 80 万，56% 的财富 500 强在用。他们跑了累计 1000 万次 Claude Code 会话（每周 40 万次以上）、总计 4000 万次 Warp Agent 对话，技术栈横跨 Rust、Golang、GitHub Actions 和内部 agent 编排平台 Oz。

问题出在他们的代码审查 agent 身上：评论质量低、噪音多。团队先是手工改写 prompt，又完善 AGENTS.md 之类的上下文文件，都无法规模化。根本原因在于：会话结束后反馈就消失了，关键上下文脱离了 agent 的循环。解决方案是基于 Agent Skills 的框架，让反馈随时间复利、持续改进 agent 的输出。

基于 skills 的自我改进循环

核心架构由两层 skill 加中间的人工反馈组成：

内层 skill（基础 skill） 承载功能性领域知识，比如 PR 打开时代码审查 agent 据此执行审查。

人工反馈 是整个循环的关键。反馈可以简单到一个点赞，但越具体越有价值。Zach Lloyd 举例说，人既可以肯定某条评论有用，也可以详细说明这次审查为什么不好、命名规范应该怎么遵循——让 agent 知道下次怎么做对。

外层 skill（improver skill） 是一个按计划运行（而非按任务运行）的观察者 agent。它汇总累积的反馈，对比 agent 的建议与人类的回应，然后对基础 skill 提出小而聚焦的修改。

skill 是纯文件，而 agent 极其擅长更新文件。修改走正常的 PR 代码审查流程，合并之后，下次运行就自动继承了改进。Warp 在整个开源仓库上运行这个模式，spec 撰写、代码审查、issue 分诊三类 agent 各自带一个改进循环。Zach Lloyd 的说法是：基于文件的 skill 是一种为 agent 编码知识的方式，不必把这些知识直接塞进 prompt。这个框架的美妙之处正在于它的简单。

编写自我改进 skill 的技巧

Warp 总结了六条实战经验：

写原则，别写规则。 把 skill 当成在指导一个聪明人，而不是在给计算机编程序。"Look for repeated code"（留意重复代码）这类方向性指导，优于穷举式的命名规则清单。

解释原因。 给出理由让 agent 能推理问题本身，而非僵硬执行指令，泛化表现会好得多。

让反馈零门槛。 反馈要在人们本来就在工作的地方自动捕获——PR 评论、issue 评论。Zach 强调，低摩擦是让信号持续流动的前提；门槛太高，你就收不到反馈，也就改不了 skill。

skill 保持小，渐进披露。 好的 skill 文件会引用资源文件和脚本，而不是把所有内容一次性塞满上下文。

反馈质量重于数量（但数量也有益）。 资深工程师少量详尽的领域反馈，胜过大量敷衍的反馈。Zach 的观察是：相对小的样本量也能拿到很好的信号；当然高质量语料越大越好——Warp 有数百名贡献者、数千次代码审查。

在 improver skill 上多投入。 它在各个用例之间高度可复用——代码审查 agent 的 improver 和其他 agent 的 improver 差别不大，打磨好一个，处处受益。

实例：issue 分诊 agent

看一个完整运转的例子。新的 GitHub issue 出现时，GitHub Action 启动分诊 agent：分析问题的复杂度和可行性、打标签、建议修复方向。内层 skill 里包含各个标签的含义，以及「先研究代码库再下判断」这类领域知识。

有一次，内层 skill 漏掉了 "ready to spec" 标签——这个标签表示该 issue 可以开始撰写产品或技术 spec 了。维护者直接在 issue 下留言反馈，既说明了期望，也说明了原因。

外层的 improver 在 Oz 里作为定时的 "update triage" agent 运行：认证 GitHub，运行 skill 自带的 Python 脚本拉取近期带反馈的 issue，汇总成 JSON 读回上下文——这个捆绑脚本本身就是一种最佳实践。agent 识别出反馈信号后，提出一处最小修改并开出 PR：让内层 skill 在 issue 描述了真实问题（即便 UI/UX 形态还没定）时也打上该标签。PR 描述了触发信号和改动内容，人工审核合并后，下次运行就继承了新知识——人在闭环的终点保持掌控。

Warp 已经在开源仓库规模化运行同样的机制：spec、审查、分诊各有自己的循环。任何 agent，只要内置这种「捕获人类反馈、转化为 skill 更新」的循环，都能随时间变强，并在整个组织中产生复利。

最佳实践问答

skills 和 memory 有什么区别？ skills 是程序性的、稳定的：「如何做 X」，跨运行不变，只有刻意修改才变。memory 则由 agent 在推理时自动写入，永不停变。两者解决的问题不同。

一个还是多个 improver 循环？ 折中方案：模板化的基础循环覆盖共性，再叠加领域权重。几个 agent 各配一个 improver 合理；上百个 agent 应该共享。

反馈错了怎么办？ 默认反馈就是会错的。不要让 agent 盲目接受：给它上下文去校验、过滤反馈来源，并在过滤或终审环节保留人工。

领域可验证时怎么调优？ 先建验证 harness，让 agent 对着它调优——生成参考语料、对比、修复、重复。

领域不可验证时呢？ 尽量用对 golden outputs 的确定性评估；必须用人工反馈时，只限领域专家。

怎么知道系统真的在改进？ 追踪人类本来就在看的全局指标——合并时间、贡献者数量、成本——并把这些指标回灌给 improver agent。部署节奏走「爬、走、跑」。

本文翻译转载自 Anthropic 官方博客 How Warp builds self-improving agents on Claude，作者 Michael Segner，发布于 2026 年 8 月 26 日。完整 webinar 见 anthropic.com/webinars/how-warp-builds-self-improving-agents-on-claude。