Warp 如何用 Skill 实现 Self-Improving Agent 自动复盘？

最近 Anthropic 发了一篇案例，聊的是 Warp 的 Self-Improving Agent。实际上，这套东西就是在 Skill 层把 Agent 的“复盘”做成了 CI/CD，挺有参考价值：

Agent 每次工作完产生的用户反馈会被保留下来，另一个专门负责复盘的 Agent 会定期分析这些反馈，然后修改前一个 Agent 使用的 Skill 文件。修改后的提交需要经过 PR、Code Review 和人工合并。

这套思路本身不复杂，关键是 Warp 已经把它跑在了真实规模上：80 万月活开发者、Fortune 500 中 56% 使用 Warp，Warp 内累计运行过超过 1000 万次 Claude Code session。所以它的做法还是很有实际参考价值的。

起点：Code Review 为什么越用越烦？

Warp 最初遇到的问题，其实很多 Coding Agent 都会遇到。事情来自一个很普通的场景：Code Review。

Warp 内部有一个自动代码审查 Agent，每次有人提交代码，它会分析 PR 并留下评论。虽然现在 AI 能力已经很强，但长期使用下来，很多人都抱怨：

评论没有价值，建议不符合 Warp 自己的工程习惯；还有一些属于“技术上说得通，放到这个项目里没必要”。

比如下面这个典型例子：AI 总想给 packet 加一个判空操作，但业务上如果 packet 为空，恰恰应该直接暴露问题，因为那已经是 P0 级别的故障了。

而 Warp 最开始采用的解决方法也很常见：发现错误后，工程师手动修改 Prompt，把项目级知识写进 AGENTS.md，遇到新的特殊情况再补一条规则。

这些办法确实能改善结果，但问题在于维护方式。Agent 一天可能跑几百甚至几千次，用户反馈也在不断产生。如果每一次经验都要等人想起来再去修改 Prompt，整个学习过程很容易静默停止。

所以真正的问题是：

Agent 每天其实收到了大量训练价值很高的反馈，但这些反馈很多时候随着一次 session 结束就消失了。

例如 Agent 评论：

这个 global variable 应该改名。

用户反馈：

这里不用改，我们项目里这种 global variable 一直采用这种命名方式。

对当前这次 Code Review 来说，问题确实解决了；但下一次开启新 Agent session 时，这段经验没有被沉淀，另一个 Agent 还会提出完全相同的建议。Warp 把这种现象叫做“组织经验蒸发”。

执行与学习拆成两个循环

所以 Warp 后续增加了一个负责复盘的 Agent，并把系统拆成两类 Skill。

第一类叫 Base Skill / Inner Skill，负责真正干活，比如：

• triage-issue
• review-pr
• write-spec
• implementation

以代码审查为例，Warp 的 review-pr Skill 是一套完整的代码审查规范：

检查 correctness、security、error handling、performance，也会检查测试和注释质量；输出必须写入结构化的 review.json，inline comment 必须严格对应 PR diff 中真实存在的行，最后还要运行 validate_review_json.py 验证结果。

这类 Skill 可以理解成 Agent 当前掌握的“工作方法”。

第二类是 Improver Skill / Outer Skill，它隔一段时间出来检查过去一段时间里：

• Agent 当时做了什么
• 用户后来怎么评价
• 人类有没有重新修改标签
• 有没有明确纠正 Agent
• 哪些错误反复出现

然后把这些行为归纳成可以长期复用的经验，再修改 Base Skill。整个架构里实际存在两个不同时间尺度：

• 实时运行的是：Task → Base Agent → Result → Human Feedback
• 慢速运行的是：历史 Result + Human Feedback → Improver Agent → 修改 Base Skill

所以按照 Warp 的思路，主 Agent 根本不需要一边做任务一边考虑学习和沉淀问题，复盘 Agent 也不用参与每一次执行。执行和学习可以拆成两个独立的循环。

比如 Warp 的 Issue Triage Agent：有人提交一个 GitHub Issue 后，GitHub Action 会自动触发 Oz Agent，Agent 根据 triage-issue Skill 阅读 Issue、研究代码、判断复杂程度和可执行性，然后打标签。

其中一个案例里，Agent 基本判断正确，但少打了一个 ready-to-spec。这个标签代表问题已经描述清楚，可以开始写 Product Spec 和 Technical Spec。Warp maintainer 直接在 Issue 下告诉 Agent：

这个 Issue 应该进入 ready-to-spec，同时解释为什么。

一段时间后，Warp 的 update-triage Agent 会周期运行，通过附带的 Python 脚本扫描最近的 Issue，收集 maintainer 修改标签、重新打开 Issue、后续评论等反馈，然后生成结构化 JSON。

Agent 读取这些数据后，会统计重复出现的问题。如果发现多次类似 Issue 都被 maintainer 从 A 标签改成 B 标签，它就可能推断：

现有 triage Skill 对这一类 Issue 的判断规则存在系统性偏差。

然后它就会修改 .agents/skills/triage-issue-local/SKILL.md，创建一个 PR，等维护人员确认修改内容无误后直接 Merge。

给“学习”也加上 Guardrail

如果只是“模型读反馈，然后修改 Prompt”，这件事并不特别。Warp 真正有工程价值的细节在于：

它约束了 Agent 什么情况下允许学习、能够学习什么，以及学习结果如何上线。

比如 update-triage Skill 明确规定：

只有出现 repeated reviewer signals，才值得修改 Skill。

也就是说，maintainer 偶尔改错一个标签，不会形成新规则。它还明确要求：

A one-off maintainer override is not enough evidence.

如果证据不足，Agent 应该什么都不改。而且 Warp 的 Learned guidelines 还有类似限制：一段时间最多只能保留 15 条，达到上限后需要合并相似规则，或者删除证据最弱的规则。

Warp 还限制了 Agent 可以修改哪些文件。例如 Self-improvement Agent 只能修改：

.agents/skills/triage-issue-local/

特定情况下可以修改：

.github/issue-triage/*

但不能修改通用的 triage-issue/SKILL.md，也不能碰其他核心 Skill。执行结束后，系统还会通过 git diff 检查修改范围，只要 Agent 改到允许范围以外的文件，整次运行直接终止。

甚至连 Duplicate Issue 的学习，Warp 也单独拆成了一个 update-dedupe，只研究 GitHub 已经确认的 duplicate close event。普通评论里随口提一句“可能和 #123 类似”，不会成为学习信号，从而避免误判。

从单个 Agent 到 Agent Factory

这套 Skill 已经开始承担「组织长期知识」的角色，这还需要区分 Skill 和 Memory：

• Memory 更偏向运行中的上下文记忆，比如用户习惯、之前发生过什么、当前项目状态，例如「上一次这个用户不喜欢自动修改 lock file」。
• Skill 保存的是相对稳定的规则，比如「遇到这种任务，我们应该怎么做」，类似「进行依赖升级时，必须检查 lock file 是否产生与目标无关的大规模变化」。

前者描述一个事实，后者描述一种工作方法。

这套能力最终会从单个 Agent 扩展成 Agent Factory，比如 Triage、Spec、Implementation、Code Review、Verification、Monitoring：

• Issue 进来之后，Triage Agent 判断
• 需要设计的进入 Spec Agent
• 条件成熟后 Implementation Agent 写代码
• Review Agent 自动审查
• 某些 UI 场景调用 computer-use 子 Agent 去真正操作界面验证
• Human Review 完成后，另一个 improve-review-pr Agent 再从人类对自动 Review 的反馈中学习

也就是说，Agent 在生产软件，而软件生产过程本身又不断产生训练 Agent 工作方法的数据：

• 一次 code review 被人类 Reject，本身就成为下一轮 Review Skill 的潜在训练样本
• 一次 Issue 被 maintainer 重新打标签，也成为 Triage Skill 的训练信号
• 一次 Spec 被大幅修改，可以暴露 Spec Agent 对公司产品逻辑理解上的缺口

所以这种 Self-Improving Agent 并不复杂，难点在于如何有效、持续地迭代。真正磨人的是细节：哪些信号在你的业务上是合理的，哪些是噪声，怎么设计合理的 human-in-the-loop，以及如何贴合你所在组织和项目的形态。

参考仓库： https://github.com/warpdotdev/common-skills