Claude 技术文章：Warp 怎么让 Agent 自己越用越聪明？答案藏在一个双层 Skill 结构里。

Warp 做 AI 终端，他们内部的代码审查 Agent 碰到了经典问题：初版 prompt 大概能完成 80% 的任务，剩下的 20% 产生的错误评论让用户体验很差。团队手动改 prompt、改 AGENTS.md，效果有限——因为人类对 Agent 的反馈，会话一结束就丢了。

他们的解法很简洁：用 Claude Platform 的 Agent Skills 做了个自改进循环。

1. 双层 Skill 架构

Inner skill（基础层）：存功能性的领域知识和指令。比如代码审查 Agent 根据它来做 PR review。

Outer skill（改进层）：一个 observer Agent，不按任务触发，而是定时运行。它拉取累积的人类反馈数据，对比 Agent 做了什么和人类怎么回应，然后提议一条针对 base skill 的小修改。

因为 skills 就是普通文件，Agent 更新它们特别顺手。改动走正常 PR 流程，人审、approve、merge，下一个周期的 inner skill 就继承了改进。

2. Issue Triage 实战案例

Warp 的 triage Agent 给新 GitHub Issue 打标签。第一次跑漏了一个 "ready to spec" 标签——意味着贡献者可以开始做产品和技术规格书。维护者直接在 issue 上留了反馈，说清楚预期什么、为什么这么想。

outer improver 定期跑起来，从 issue 评论区提取了这个信号，生成了一条最小改动，提了 PR 把判断条件加到 inner skill 里。人审 merge 之后，下次 triage 就懂了。

3. 设计原则：写 skill 不是写 code

Warp 创始人的建议："当你在教一个聪明的人，而不是编程一台机器。" 与其列一堆硬规则，不如给方向——"Look for repeated code" 比枚举所有命名规则更管用。解释 why，让 Agent 能推理而不只是执行。

反馈必须极低摩擦：直接在 PR 上评、在 issue 上评，不要额外提交步骤。反馈质量远比数量重要，一条资深工程师的详细解释 > 十个点赞。improver skill 本身高度可复用，代码审查的 improver 和其他场景的 improver 差别不大。

4. 最佳实践清单

文章最后总结了几条关键教训：

1）别把 skill 和记忆混为一谈。 Skill 是过程性知识——"怎么做 X"，跨 session 稳定，人为主动改。记忆是 Agent 推理时自动写入、永不停止变化的东西。两者机制完全不同。

2）一个 improver loop 够用还是每个 Agent 需要一个？ 折中方案：模板化的 base loop 覆盖共性，叠加领域特异性权重。几个 improver 各自管一个没问题，上百个就该共享。

3）如果人类给了错误反馈怎么办？假设一定会发生。 不要让 Agent 照单全收——给它上下文做 sanity check，过滤谁的意见才算数，要么在过滤阶段、要么在最终 review 阶段保持人在回路。

4）你的领域能不能验证？ 能的话先搭验证 harness，再让 Agent 对着调优：生成参考语料 → 对比输出 → 修复 → 重来。不能验证的话就用确定性 evals 对齐 golden output；用到人工反馈时只限领域专家，别开闸放水。

5）你怎么知道整个系统在变好？ 跟踪人类已经在看的全球指标：合并时间、贡献者数量、成本——把它们喂回给 improver Agent。部署策略要 crawl-walk-run，别一步到位。

5. 本质

Warp 把这个模式跑通了整个开源仓库——spec writing、review、triage，每个 Agent 都有独立自改进循环。目前跑了 1000 万 + Claude Code session，4000 万 + Agent 对话量。

Claude 出了 Agent Skills，Warp 第一个把它做成生产级模式。如果你们也在做 Agent product，这个双层 skill loop 的架构值得参考——简单，可验证，迭代快。

原文：claude.com/blog/how-warp-builds-self-improving-agents-on-claude

how i ai 程序员