本文作者：meng shao（@shao__meng）。版权归作者所有，未经授权禁止转载。
Claude 官方博客最新发布了一篇博客
How Warp builds self-improving agents on Claude
https://claude.com/blog/how-warp-builds-self-improving-agents-on-claude
源于 Warp 团队发现的一个痛点：
一次性提示词只能完成任务的 80%，剩下的 20% 错误会持续制造噪音，让用户厌烦。
以内部代码评审 Agent 为例：工程师抱怨 Agent 评论无用、输出质量低。Warp 最初尝试了两种"打补丁"式方案——手动改提示词、优化 AGENTS.md 上下文文件——都有效但不可扩展。
Warp 团队认为到：无论 Agent 做什么任务，人类反馈在会话结束后就消失了，关键上下文被从 Agent 循环中移除。Agent 因此永远无法"长记性"。
核心方案：基于 Skills 的双层自我改进循环
Warp 的架构非常简洁，由两个 Skill + 中间的人类反馈构成：
为什么这个设计成立？ 因为 Skill 本质上是纯文本文件——Agent 极其擅长编辑文件；修改可以走正常的 PR/Code Review 流程，可审查、可批准、可合并，人类始终掌握最终控制权。
实战案例：Issue 分诊 Agent
Warp 的 GitHub Issue 分诊 Agent 完整演示了这个循环：
- 触发：有人提交新 Issue → GitHub Action 唤起 Agent，分析复杂度与可行性、打标签、建议修复方向。
- 出错：某次 Agent 漏打了 ready to spec 标签（表示贡献者可以开始写产品/技术规格）。
- 反馈：维护者直接在 Issue 下留言纠正——关键是他既说明了期望什么，也解释了为什么。
- 改进：外层 Improver Skill 在 Warp 的编排平台 Oz 上定时运行，通过 Skill 自带的 Python 脚本拉取带反馈的 Issue，汇总成 JSON，识别反馈信号，提出最小化修改。
- 闭环：自动提交一个修改内层 Skill 的 PR（附带说明"哪个信号触发了此改动"），人类评审合并后，下次分诊即继承新知识。
Warp 已将此模式推广到整个开源仓库：写规格、代码评审、Issue 分诊三类 Agent 各自携带独立的自我改进循环。
Warp 团队的六条实践经验
| 原则 | 要点 |
|---|---|
| **写原则，不写规则** | 像指导聪明人，而非编程机器。"寻找重复代码"比穷举变量命名规则更有效 |
| **解释"为什么"** | 给出规则背后的理由，Agent 才能推理和泛化，而非死板执行 |
| **让反馈零摩擦** | 在人们已有的工作场景中捕获反馈（直接评论 PR/Issue），自动化、无额外提交步骤。"低摩擦才能保持信号流动" |
| **Skill 保持小、渐进披露** | 引用资源文件和脚本，而非把所有内容一次性塞进上下文 |
| **反馈质量 > 数量（但数量也有用）** | 资深工程师一条详细的领域反馈，胜过大量泛泛的点赞/点踩——二元反馈说不出"为什么" |
| **重点投入 Improver Skill** | 它高度可复用：代码评审 Agent 的改进器与其他 Agent 的改进器差别不大 |关键概念辨析与风控
1. Skill ≠ Memory（不要混淆）
- Skill：程序性、稳定的知识——"如何做 X"，与单次运行无关，刻意地被修改。
- Memory：Agent 推理时自动写入，持续变动。
混淆二者会导致知识体系失控。
2. 反馈可能是错的——必须假设它会是错的
- 不让 Agent 盲目接受反馈；
- 提供上下文让其做合理性检查；
- 过滤"谁的反馈算数"；
- 在过滤或终审环节保留人类。
3. 领域可验证性决定策略
- 可验证：先建验证工具链（参考语料 → 对比输出 → 修复 → 重复），让 Agent 对着它调优。
- 不可验证：尽可能用黄金输出做确定性评估；必须用人时，只开放给领域专家，不要广开反馈之门。
4. 如何知道整个系统在变好？ 追踪人类本来就在看的全局指标——合并耗时、贡献者数量、成本——并把这些指标回喂给 Improver Agent。部署上走"爬—走—跑"的渐进路线。
5. 改进器的粒度：一个模板化的基础循环捕捉各 Agent 的共性，再叠加领域特定的权重。几个 Agent 可以各自拥有改进器，一百个 Agent 应该共享。
