自我改进的 Agent，关键是把反馈变成可合并的 Skill diff

一个代码评审 Agent 收到一次差评，下次会更好吗？

大多数情况下不会。因为反馈通常只停留在当前会话、当前 PR 或当前人的脑子里。下一次运行时，Agent 仍然只读到原来的提示词、原来的上下文和原来的规则。用户以为自己“教过它”，系统其实什么都没有学到。

Anthropic 在 How Warp builds self-improving agents on Claude 里讲的 Warp 案例，最有价值的不是“Agent 可以自我改进”这个口号，而是一条很朴素的工程判断：反馈只有变成可审查、可合并、可回滚的文件变更，才会进入组织能力。

原文解决的是反馈消失问题#

Warp 是一个 AI terminal 和 agentic development environment，内部 agent 基于 Claude Platform。原文提到，Warp 团队最初在代码评审 Agent 上遇到的问题很具体：Agent 会留下不够有用的评论，输出质量不稳定，工程师觉得它打扰多于帮助。

团队先尝试了两类常见补丁：人工观察失败案例后重写 prompt，以及改进类似 AGENTS.md 的上下文文件。这些方法能改善一部分输出，但不适合长期扩张。因为每次评审里的具体反馈，如果没有被系统性吸收，下一次运行仍然要重新犯相似错误。

Warp 最后的方案，是用两层 file-based skills 做自我改进闭环：

环节	运行节奏	职责	边界
Base skill	每次任务运行时读取	保存领域规则、评审原则和执行方法	不自己修改自己
Human feedback	出现在 PR、issue 或实际工作场景里	标记输出是否有用，并说明原因	不直接改生产行为
Improver skill	定期运行	汇总反馈，提出一个小的 Skill diff	不绕过人工评审
Review workflow	合并前触发	审查 diff、理由和影响范围	保留人类最终控制权

这个设计的关键，是把“Agent 做事”和“Agent 改善做事方式”拆开。执行者负责完成当前任务，改进者负责观察一段时间内的反馈，然后提出最小变更。中间隔着人的反馈和代码评审流程。

自我改进不是记忆，而是发布流程#

很多产品会把这件事误解成“给 Agent 加记忆”。但 Warp 案例里更接近产品资产的是 Skill，而不是会话记忆。

记忆适合保存容易变化的事实，例如用户偏好、最近一次任务状态、某个临时约定。Skill 更适合保存稳定的程序性知识：遇到某类 issue 应该怎么判断、代码评审时哪些评论有价值、什么条件下应该打上某个标签。

这两者的治理方式不同。记忆可以轻量、快速、频繁更新；Skill 一旦影响生产行为，就应该像一段代码一样被审查。它要有变更理由、关联反馈、预期影响、验证方式和回滚路径。

所以我会把自我改进 Agent 的产品定义改写成一句话：

不是让模型自动相信反馈，而是让系统把高质量反馈转成可发布的能力变更。

这里的“发布”不一定是线上部署，但一定包含版本、审查和责任边界。

反馈入口决定闭环能不能转起来#

原文反复强调低摩擦反馈：人应该在本来工作的地方留下反馈，而不是跳到另一个系统里填表。代码评审就留在 PR，issue 分诊就留在 issue。反馈离现场越近，越容易保留上下文，也越不容易变成事后补作业。

但低摩擦不等于只收 thumbs up/down。二元反馈能告诉系统“这条输出不行”，却很难告诉它“为什么不行”。Warp 的例子里，更有价值的是维护者说明期望和理由：某个 label 为什么应该被加上，某类评论为什么不符合团队约定。

我会把反馈对象拆成六个字段：

字段	作用
artifact_id	指向 Agent 当时生成的评论、标签或方案
task_context	保存任务类型、仓库位置、issue 或 PR 场景
human_judgment	有用、无用、缺失、风险高或需要人工接管
rationale	人为什么这样判断
expected_behavior	下次遇到相似场景时应该怎么做
reviewer_role	反馈来自维护者、领域专家、普通贡献者还是自动测试

这些字段不需要一开始就全部结构化。第一版可以从评论文本里提取，但产品上必须保留回链：每一个 Skill diff 都应该能追到原始反馈，而不是只留下“根据近期反馈优化了规则”这种空泛说明。

Issue triage 的例子说明了最小变更原则#

原文用 Warp 的 issue triage Agent 展示这条闭环。有人提交新 GitHub issue 后，GitHub Action 触发 Agent 分析复杂度和可行性、打标签，并建议修复方向。这个 triage Agent 运行时读取的是内层 Skill，里面保存了标签含义和代码库研究方法。

在一个样例里，Agent 的初次判断总体可用，但漏掉了 ready to spec 标签。这个标签表示问题已经足够真实，可以开始写产品和技术规格。维护者直接在 issue 里指出缺口，并说明为什么这个场景应该进入 spec 阶段。

随后，Warp 的外层 improver skill 在 Oz 编排平台中定期运行：它认证到 GitHub，调用 Skill 里附带的 Python 脚本拉取近期反馈，把结果整理成 JSON，再由 Agent 读回上下文。接着，improver 识别反馈信号，提出一个很小的改动：当 issue 描述了真实问题，即便 UI/UX 形态还没完全确定，也应该考虑打上 ready to spec。

这一步很重要。它没有把所有 triage 规则重写一遍，也没有因为一次反馈就让 Agent 未来无条件套用标签。它只把一个可解释、可审查、可合并的判断补进内层 Skill。

我会把 Skill diff 当成产品交付件#

如果要把 Warp 这套模式迁移到别的 AI 产品，我不会先做一个“自动学习平台”。我会先定义 Skill diff 的交付标准。

一个合格的 Skill diff 至少要回答五个问题：

问题	需要留下的证据
为什么改	关联的反馈样本、失败类型和影响范围
改了什么	具体文件 diff，而不是一段总结
为什么只改这些	排除更大改动的理由
怎么验证	回归样本、人工抽检或线上观察指标
如何撤回	版本号、负责人和回滚条件

这会把 Agent 的“学习”从黑箱变成一个普通团队能管理的发布单元。产品经理可以看影响范围，工程师可以看 diff，领域专家可以看规则是否符合实际工作，负责人可以决定是否合并。

这里也要防止另一个极端：不应该把所有反馈都自动写进 Skill。反馈可能错，反馈者可能只看到局部，甚至可能有人恶意引导。越靠近生产行为的知识，越需要过滤输入来源、保留证据，并在人或验证系统那里过一道闸。

最小可用版本可以很小#

第一版自我改进 Agent 不需要复杂平台。选择一个高频、可验证、反馈自然存在的任务就够了，比如 issue triage、代码评审、客服工单分类、销售线索初筛或数据报表解释。

我会按这个顺序做 MVP：

1. 写一个小的 base skill，只描述原则、边界和少量关键流程，不把所有规则塞进去。
2. 在现有工作流里收反馈，例如 PR 评论、issue 评论、工单备注或人工审核结果。
3. 每条反馈保留原始链接、Agent 输出、人的判断和理由。
4. 每天或每周运行 improver，只允许它提出一个原子 Skill diff。
5. 合并前跑最小回归集，至少覆盖已知成功样本、目标失败样本和高风险反例。
6. 用 skill_version 追踪线上结果，看任务通过率、人工接管率、返工率、成本和新失败类型。
7. 被拒绝的 diff 也要记录原因，避免下一轮重复提出同一类错误修复。

这个 MVP 的北极星指标不是“自动生成了多少规则”，而是单位人工反馈能带来多少稳定任务成功增量。如果反馈很多，但通过率没升、返工没降、专家还要花更多时间解释系统错误，闭环只是在制造新的维护成本。

产品边界：别把单团队案例写成通用规律#

Warp 的案例很有启发，但它不是一个公开 benchmark，也不是严格受控实验。原文给出了 Warp 的业务规模数字：例如 800K monthly developers、40M total Warp Agent conversations，以及 Claude Code 在 Warp 内的累计和每周会话量。这些数字说明场景有规模，不能证明自我改进闭环单独造成了增长。

同样，代码评审和 issue triage 都是开发者工作流里的任务。它们有天然优势：反馈场景明确、专家就在现场、变更可以走 PR、好坏相对容易讨论。把这套机制迁移到医疗、金融、法律、创意生成或客服场景时，反馈来源、错误成本、合规要求和验证方式都要重新设计。

我认为最稳妥的迁移原则是：先找可审查的工作流，再谈自我改进。 如果一个场景里没有原始证据、没有专家反馈、没有版本管理、没有验收方式，那么“自动学习”只会放大系统的不确定性。

最后的判断#

自我改进 Agent 不是让模型在对话里变得更听话，而是让组织把一次次人工判断沉淀到稳定的能力文件里。Base skill 承载当前做事方法，human feedback 提供现场信号，improver skill 把信号转成最小 diff，代码评审决定它是否进入下一次运行。

这条闭环朴素得有点不酷，但正因为朴素，它才像一个可以落地的产品系统。反馈不再消失，规则不再靠人记，改进不再绕过审查。Agent 的能力复利，最终不是来自更神秘的记忆，而是来自更清楚的发布纪律。

来源与边界#

• 事实来源是 Claude by Anthropic 于 2026 年 8 月 26 日发布的官方案例文章 How Warp builds self-improving agents on Claude，作者为 Michael Segner。
• 研究对象不是实验论文，而是 Warp 在 Claude Platform 上构建 self-improving agents 的公开工程实践。原文涉及代码评审 Agent、issue triage Agent、两层 Skill 架构、Oz 编排平台、GitHub Action、反馈拉取脚本和 Skill PR 审查流程。
• 原文列出的 Warp 规模数字用于说明案例背景，不应被解读为自我改进闭环造成业务增长的因果证据。
• 本文中的反馈字段、Skill diff 交付标准、MVP 路线和指标，是我面向 AI 产品落地做的产品化转译，不代表 Warp 或 Anthropic 的正式产品规范。