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

本文是对官方文章「How Warp builds self-improving agents on Claude」的中文要点摘要，完整内容以原文为准：https://claude.com/blog/how-warp-builds-self-improving-agents-on-claude

Warp 是谁

Warp 是一家成立于 2020 年的公司（CEO Zach Lloyd，累计融资 $73M），做的是构建在 Claude Platform 之上的 AI 驱动终端与 agent 开发环境。目前月活开发者约 80 万，财富 500 强企业中有 56% 在使用，累计跑过 1000 万次 Claude Code 会话，近期周活跃达 40 万+ 会话，agent 对话总量超过 4000 万次。

问题：反馈在会话结束时就消失了

Warp 最初为代码审查等 agent 写的第一版提示词能解决大部分任务，但也带来「噪音体验」——比如给出不实用的注释、输出质量参差。团队最早的应对方式是人工根据观察到的失败案例重写 prompt，或不断打磨 AGENTS.md 之类的上下文文件。但这条路走不远：每次会话结束，人类给出的具体反馈也随之丢失，agent 循环里最关键的背景信息没有被留存下来。

解决方案：基于 Agent Skills 的自我改进架构

Warp 的做法是把 Skill 分成两层：

• 内层/基础 Skill：存放具体的功能性知识和执行指令，比如「PR 打开时如何做代码审查」，以文件形式保存，而不是散落在一次性 prompt 里。
• 人类反馈：分为简单反馈（点赞/点踩）和详细反馈（说明具体改进理由，例如「你建议重命名变量，但我们代码库里这类全局变量有约定的命名习惯」）。
• 外层/改进 Skill（Improver Skill）：作为一个「观察者」agent，按固定计划运行（而非跟着每个任务触发），持续汇总人类反馈、对比 agent 的历史输出，然后针对基础 Skill 提出「小的、聚焦的编辑」。

关键在于：Skill 本质是纯文件，agent 很擅长修改文件，所产生的更新可以像普通代码改动一样走 PR/代码审查流程，由人审核、批准、合并后生效。

实际案例：issue 分类 agent

Warp 在自家那个开源仓库里跑着若干各自独立的 agent（spec 编写、代码审查、issue 分类等），每个都配了自己的自我改进循环。以 issue 分类 agent 为例：

1. GitHub Action 在新 issue 出现时触发分析；
2. 内层 Skill 评估复杂度、可行性，打标签、给出修复方向建议；
3. 维护者直接在 issue 下留言反馈，说明预期和理由；
4. 外层 improver Skill 在 Warp 的 agent 编排平台 Oz 上按计划运行，拉取近期带反馈的 issue，汇总成结构化数据，识别反馈信号，提出最小化的编辑建议；
5. 人工审查、批准、合并，下一次运行时 agent 就继承了这份新知识。

实例：第一版分类漏掉了「ready to spec」标签，维护者指出后，improver agent 提出对应编辑，经 PR 合并后问题得到解决。

写自我改进 Skill 的实践建议

• 讲原则而非堆规则：像指导一个聪明的人，而不是编程一台计算机——「去找重复代码」比一长串变量命名细则更有效。
• 解释「为什么」：给出规则背后的理由，让 agent 能推理而不是机械套用。
• 反馈要无摩擦：在人们已经在用的地方（PR、issue 评论）直接采集反馈，不要求额外提交步骤。
• Skill 要精简、渐进式加载：不要把所有东西都塞进上下文，善用引用的资源文件和脚本。
• 反馈质量优先于数量：资深工程师给出的、有领域背景的详细反馈，价值高于大量简单点赞点踩；不过高质量反馈库越大越好。
• 重点投入 improver Skill 本身：因为它在不同用例之间高度可复用，投资它的回报是倍增的。

几点常见问题

• Skills 和 Memory 的区别：Skill 存放的是相对稳定的「怎么做」知识，改动需要人工审核；Memory 则是自动持续写入、不断变化的记录。
• 一个 improver 循环还是多个：Warp 采取折中方案——用模板化的基础循环覆盖共性部分，少数场景各自拥有专属的 improver。
• 错误反馈怎么办：不能无条件接受反馈，需要给 agent 足够背景去甄别谁的输入更可信，并始终保留人在环节中的审核。
• 衡量整体系统是否变好：跟踪已有的业务指标（如合并耗时、贡献者数量、成本），把这些反馈回 improver agent。