梦溪笔记 · Mengxi Notes · AGENTS

Warp 如何让 agent
自我改进 ——
两层 skill 与人类反馈闭环

Anthropic 案例研究：Warp 把 Claude 驱动的代码 review agent 从「80% 凑合的 prompt」进化成「会自我刷新的 skill 文件」。 核心是内层 base skill + 外层 improver skill，中间卡一道人类反馈。

原文 Anthropic · How Warp builds self-improving agents 作者 Michael Segner 长度 ~ 7 min 阅读 李梦溪 2026.08.28
01 · 初始方案

重写 prompt

每次出错就人工修补 prompt。能用，但一长就崩——人记不住几百条 prompt 规则。

02 · 改良方案

完善 AGENTS.md

把上下文塞进 AGENTS.md 文件。比 prompt 好，但还是静态——不会从反馈里学。

03 · 真正方案

Skill 文件 + Improver

把知识编码进文件，再用一个 observer agent 定期读反馈、改 skill。反馈闭环。

§ 01 · 起点

一次 80% 准确率的 prompt
是不够的——反馈消失了。

Warp 的代码 review agent 一开始只能用「80% 对、20% 错」的 prompt 撑场面。 工程师被 agent 的「无意义评论」反复折磨。 改 prompt 是给症状打补丁，真正缺的是：反馈机制。

原话

「Agents need to handle recurring tasks reliably and effectively.」

Warp 团队的第一反应是 stopgap solution——根据出错的 review 反推，去人工重写 prompt。能用，但不 scale。

再后来试着扩充 AGENTS.md 这样的上下文文件——也只解决了一部分。

The real issue was that feedback to an agent, no matter what its purpose, typically disappears when the session ends, removing critical context from the agentic loop.
80%
first-pass prompt 的天花板
400K+
每周 Warp 里跑的 Claude Code session
~ 1M
受影响的开发者
0
传统 agent 里「会话结束」就消失的反馈

§ 02 · 关键架构

两层 skill，内层做事，
外层改文件。

Warp 的核心抽象只有一个：Skill 是一种「文件形式编码的知识」，不进 prompt， agent 在需要时去读。Skill 文件本身可以被另一个 agent 改—— 这就让改进 skill 本身变成一个 agent 任务。

INNER · BASE SKILL AGENT code review / triage skill.md "如何做代码 review" domain knowledge + rules ↑ 每任务触发 「PR opened」 HUMAN FEEDBACK thumbs up + 具体评论 "这个评论好/不好，因为 ..." OUTER · IMPROVER SKILL OBSERVER scheduled · not per-task pull feedback → diff 提议一行小改 smallest edit · merge-able PR ↓ opens PR on base skill "edit skill.md · code review" ↓ FEEDBACK ACCUMULATES IN GITHUB ISSUE / PR ↓
INNER AGENT — 每任务执行（review / triage / spec） BASE SKILL — 领域知识 + 规则的文件 HUMAN FEEDBACK — 在 PR / issue 上自然留下 IMPROVER AGENT — 定期跑，提 PR 改 skill

§ 03 · 闭环

反馈不消失，
它会变成下一次的 skill 改动。

因为 skill 是普通文件，agent 改起来就像写代码—— 可以走标准的 PR / review / merge 流程。 一旦合并，下一次内层 agent 启动就直接继承改进。 这就是为什么 Warp 的 review 质量会随时间越变越好。

The self-improvement loop, in five moves

每一步都对得上一个 agent 或一个 GitHub 操作
TRIGGER PR opened 01 · EVENT INNER review 02 · RUN HUMAN comment 03 · FEEDBACK IMPROVER summarize + diff 04 · SCHEDULED MERGE skill.md+ 05 · INHERIT ↑ NEXT RUN INHERITS THE IMPROVEMENT
01 · EVENT

触发

GitHub Action 监听事件——PR、issue、spec——决定哪个内层 agent 启动。

02 · RUN

执行

内层 agent 读 base skill，对当前任务做 review / triage / spec。

03 · FEEDBACK

反馈

人类在 PR 或 issue 里直接评论——thumbs up 或具体原因。

04 · IMPROVE

改进

外层 improver 周期跑——拉反馈、总结成 JSON、提议一行改动。

05 · MERGE

合并

人类 review PR、approve、merge。下一次内层 agent 自动继承。

§ 04 · 一个具体的循环

Triage agent 的「漏掉一个 label」，
是怎么被修复的。

Warp 给自家开源仓库跑了一个 issue triage agent—— 新 issue 一来，agent 读 skill、打 label、给方向。 第一次跑漏了一个 ready to spec label。维护者在 issue 里直接留了一句反馈， 三天后这个改动进了 skill。

CASE · ISSUE TRIAGE AGENT

五步，从「漏 label」到「skill 改一行」

01
GitHub Action 触发 — 有人新开 issue；agent 拉取 issue 内容分析复杂度。
02
Inner skill 执行 — 读 triage.md，给 label、写方向。漏了 ready to spec。
03
维护者反馈 — 在 issue 评论：「应该加 ready to spec，因为这个 issue 在描述一个真实问题。」
04
Improver 周期跑 — 拉含反馈的近期 issue，summarize 成 JSON，读回 context。
05
开 PR 改 skill — 提议最小一行改动。人类 review、merge。下次 triage 自动生效。
Oz · Warp 的 agent 编排平台 · 周期任务在这里跑
triage.md · diff + 1 LINE 
12# Label an issue based on what it describes.
13- Add `bug` for reproducible defects.
14- Add `feature` for net-new capability.
15- Add `docs` for documentation-only.
16+ Add `ready to spec` when the issue describes a real,
17+   articulable problem even if UX/UI shape is undefined.
18- Add `needs-investigation` if root cause unclear.
19

§ 05 · 写 skill 的六条

Warp 团队的六条经验，
给任何想自己写 skill 的人。

Improver 是不是工作得好，80% 取决于 base skill 写得好不好。 Warp 的写法很反直觉——他们把它当作教一个聪明人，不是在写一段代码。

01

写原则，不写规则

与其写「变量名必须 snake_case」，不如写「注意重复代码」。指令型比穷举型更可泛化。

"Construct the skill as though you're instructing a smart person."
02

解释为什么

给规则背后的 rationale，让 agent 能在新场景下推理——而不是死板地复制规则。

03

让反馈零阻力

捕获反馈要发生在人已经在工作的地方——PR 评论、issue 评论——别让人额外提交。

"Low friction is what keeps signal flowing."
04

skill 要小，渐进展开

好的 skill 不长——它引用资源文件和脚本，而不是把所有上下文都塞进 prompt。

05

反馈的质量 > 数量

资深工程师的几条详细反馈 > 一百条「👍/👎」。但量大也帮助——两者都重要。

06

把更多功夫花在 improver

Outer improver skill 是跨场景可复用的——review、triage、spec 都可以共享。值得多花时间打磨。

"Improver skills are very reusable across different use cases."

§ 06 · 开始之前，先回答

把 improver 套到你的 agent 之前，
这五个问题决定能不能跑通。

Warp 列了五个最常踩的坑——每个都是「听起来明显，做起来才发现是另一回事」。

Q · 01

你把 skill 和 memory 混了吗？

Skill 是程序性的、稳定的——「怎么做 X」，跨任务不变，主动改。Memory 是 agent 推理时自己写的，永远在变。

Skill ≠ Memory · 一定分开
Q · 02

一个 improver，还是每个 agent 一个？

折中：模板化的 base loop 共享结构，agent-specific 的权重覆盖在上面。少量 improver 各管一个；一百个共享一个。

meet in the middle
Q · 03

反馈错的时候怎么办？

假设反馈会错。让 agent 有 sanity-check 的 context，过滤谁的声音算数，关键步骤留人 review。

assume feedback will be wrong
Q · 04

你的领域能被验证吗？

能的话，先建 verification harness 再让 agent 调。建一个 reference corpus、对比输出、修复、循环。不能的话，靠 deterministic eval + golden output。

verification harness first
Q · 05

你怎么知道整个系统在变好？

盯人已经在盯的全局指标——merge 时间、贡献者数量、成本。把这些指标再喂回 improver agent。部署走 crawl-walk-run。

track global metrics humans already eyeball

§ 07 · 余响

任何 agent——不管做什么任务——
只要一开始就在它里面建一个这样的 loop，
把人类反馈信号收下，转成 skill 改动，
它就会从「一次性帮手」
进化成能在组织里复利的系统。

How Warp builds self-improving agents on Claude · Michael Segner · Anthropic · 2026.08.26