dotey 解读 Warp 自进化 Skill：从自身反编译/写作 Skill 实践看六条工程原则
- ID: cb36a738
- 原文链接: https://x.com/dotey/status/2093538110311178430
- 作者: dotey
- 日期: 2026-08-29
- 分类: agents
- 来源类型: x_post
- 标签: self-improving-agents, skills, code-review, feedback-loop, agent-loop
- 质量评分: 4/5
- 抓取时间: 2026-08-29T23:47:00+08:00
中文导读
dotey 解读 Anthropic 官博《How Warp builds self-improving agents on Claude》并结合自身实践：Warp 用基础 Skill 做代码审查、改进 Skill 定期收集人类工程师在 PR 里的评论（尤其是对 Agent 审查结果的异议）自动更新审查 Skill，修改走人审合并后下个会话自动继承。关键在反馈零摩擦（人只需自然写评论，无需额外提交步骤）与不让 Agent 盲目接受反馈（给合理性检查上下文、限制谁的反馈有权影响更新、人审兜底；有标准答案的领域靠基准验证，无标准答案的领域只收领域专家反馈）。他自己的对比：反编译 Skill 因有"能否编译过"的明确成功标准而自进化有效，写作 Skill 因缺统一标准经常负优化。附六条原则：写原则不写死规则、解释为什么、反馈零摩擦、Skill 精简+渐进披露、反馈质量大于数量、改进 Skill 的 Skill 可跨域复用
原文摘录（节选）
摘录来源：Obsidian 归档笔记
---
source: x.com/dotey/status/2093538110311178430
author: @dotey
date: 2026-08-29
fetched_at: 2026-08-29
tags: [self-improving-agent, skill, code-review, agent-loop]
---
# dotey 对 Warp《How Warp builds self-improving agents on Claude》的解读与自身经验
> 原文链接：https://x.com/dotey/status/2093538110311178430
> 引用文章：https://www.anthropic.com/news/warp-self-improving-agents-on-claude （透过 t.co/CsyjaGY8TC）
Claude 新的一篇博文《How Warp builds self-improving agents on Claude》 https://t.co/CsyjaGY8TC ，看了后还是挺有收获，它解决的是 Skill 的进化问题。
这个问题我以前也研究过，我写了一个反编译 JS 代码的 Skill（https://t.co/y6kA8TDnZ3），每次 Agent 反编译的时候遇到新的场景解决了就自己更新自己的 Skill，效果还不错，能一直优化，就是 Skill 文件越来越大。
我还研究过写作的自我进化 Skill，那个就一言难尽，因为它其实没有自己统一的标准，经常负优化，越写越糟糕。
说回来 Warp 这个，Warp 是一个挺有名的终端工具，内部尝试借助 AI 做 Code Review。一开始让 Agent review 代码，效果并不理想，主要问题体现在 Agent 不了解你的项目，不知道你的团队规范，不知道历史经验教训，就算你指出来问题它下次还记不住。简单来说就是没有记忆。
初期他们采取了很多补救措施：
- 手动根据失败案例改系统提示词
- 完善项目的 AGENTS.md 文件（有意思的是这篇文章是 Claude 发的，但是用的是 AGENTS.md 而不是 CLAUDE.md，我记得 Claude 默认不支持 AGENTS.md 的😅）
但效果并不理想，一方面它依赖于人主动去做，成本较高；另一方面团队成员在 Code Review 时人工在 PR 写的高质量评论完全没用上。
所以他们搞了个解决方案，一个基础 Skill 负责做代码审查，一个改进 Skill 负责定期收集人类工程师在代码审查时的评论，尤其是对 Agent 审查结果的评论，根据人类工程师的评论去更新代码审查的 Skill。
换句话说，它不是依赖于模型自己去改进自己，而是 Agent 根据人类对模型结果的标注（人类对代码审查的评论），去改进技能。
只不过它把这个事做的摩擦力极低，不需要人手工去收集整理评论，不需要填写调查问卷，人只要自然的去代码下写评论，后面的事情都是 Agent 自动完成。
这可能正是 Agent 的最佳实践方案之一：人负责高纬度的标注、评论、反馈这些事情，Agent 去做执行的工作，Agent 根据人类的反馈去改进 Skill。
除此之外，他们还总结了一些最佳实践：
1. 写原则，不要写死规则。
编写 skill 时，要像在指导一个聪明人，而不是在给计算机编程。在 Skill 中写“寻找重复代码”，比列出详尽的变量命名规则更有效。
2. 解释为什么。
说明规则背后的理由，能让智能体针对问题进行推理，而不是机械执行僵化指令，也因此更容易举一反三。
3. 让反馈没有摩擦毫不费力。
在人们原本工作的地方收集反馈，例如直接评论 PR 或 issue。同时让收集过程自动发生，不要增加额外的提交步骤。低摩擦才能让信号持续流动。如果反馈太麻烦，你就收不到反馈，也就无法改进 Skill。
4. 保持 Skill 精简，并使用渐进式披露。
优秀的 skill 文件不会很庞大；它会引用资源文件和脚本，而不是一次性把所有内容都塞进上下文。
5. 反馈质量大于数量，但数量也有帮助。
一位资深工程师给出的少量、详细且与领域相关的反馈，可能比大量草率反馈更有价值，因为简单的赞成／反对并不能说明“为什么”。
即使样本量相对较小，只要反馈来自掌握领域知识的人，而且足够详细，你也能得到非常好的信号——这些知识是智能体通过其他方式根本无法获得的。话虽如此，优质信号的语料越多，效果越好。
6. 做好改进 Skill 的 Skill，可以用来改进其他 Skill。
把改进 Skill（也就是前面提到的一个代码审查 Skill 一个改进 Skill）做好，收益不只限于眼前这套 Agent 循环，因为改进 Skill 在不同用例之间具有很高的复用性。除了领域专用知识这一部分，它其实是一套相当通用、可复用的机制。代码审查 Agent 的改进 skill，也可以应用到其他 Skill 的改进上。
可能有人会担心：如果反馈本身是错的呢？
Warp 的做法是永远不让 Agent 盲目接受反馈。给它足够的上下文来做基本的合理性检查，限制谁的反馈有权影响技能更新（不是所有人的意见都同等重要），最后始终保留人在循环中审核改动。
对于那些有明确标准答案的领域，比如代码是否通过了测试、部署是否成功，可以先建一个验证基准，让 Agent 自己对着基准跑。没有标准答案的领域，比如代码风格、文档质量，就靠领域专家的判断，不要开放给所有人随意反馈。
---
# 补充（Xudong 8-28 已覆盖过同一篇 Warp 文章的核心架构，但 dotey 这条线对自进化 Skill 实践踩坑的描写更具体，可以并看）
本文由 daily-intake-evening 流水线于 2026-08-29 归档；摘录为原文节选，全文见原文链接。