一个新 Issue 变成下一版 Skill：Warp 的双层架构构建“自进化”Agent 机制

正文：

一版 Prompt 即使能把任务做对 80%，剩下的问题仍可能让 Agent 变得很难用。Warp 的内部代码审查 Agent 就遇到了这个问题。手动修改 Prompt 和 AGENTS.md 虽然能够改善输出，却难以持续，更深层的问题在于，工程师已经明确指出 Agent 哪里做错了，但这些反馈会随着 Session 结束而失去作用。Warp 因此设计了一套基于 Skill 的改进闭环，并将其称为“自改进 Agent”。需要明确下，这里的改进对象是 Skill 文件，人类反馈经过分析后被转化为 Skill 修改，再经过审核进入后续任务，不涉及模型训练或参数更新。

一次反馈如何进入下一次 Agent 执行

代码审查、Issue 分流这类 Agent，本身并不缺少反馈入口。工程师可以直接回复 Agent 的审查评论，维护者可以在 Issue 中指出标签分错了，用户也可以告诉 Agent 哪项建议不符合团队约定。

现实困难在于“Agent 收到了反馈”和“以后会按照这条反馈工作”之间，还需要一个经验沉淀机制。如 Agent 在代码审查中建议修改某个变量名，工程师告诉它，这类全局变量在当前代码库中采用另一套命名约定。如果这条领域知识只存在于当前 Session，下一次审查仍然可能遇到同样的问题。

因此 Warp 把人类反馈纳入 Agent 的长期改进流程。反馈可以只是简单的点赞，但团队更看重具体解释，包括哪里有问题、为什么有问题，以及团队实际采用什么规则。这类反馈能够为后续 Skill 修改提供更明确的依据。

双层 Skill 拆开任务执行与规则改进

Warp 的核心架构很简单，由两个 Skill 和中间的人类反馈组成。

第一层是基础 Skill。它保存某类 Agent 完成任务需要的领域知识和执行指导。代码审查 Agent 在 PR 创建后，会结合基础 Skill 和当前代码上下文完成审查；Issue 分流 Agent 的基础 Skill 则会保存不同标签的含义，以及判断 Issue 前应该怎样查看代码库。

第二层是改进 Skill。它不处理具体 PR 或 Issue，而是作为观察者分析此前任务产生的人类反馈。两层 Skill 运行在不同节奏上。基础 Skill 随任务触发，改进 Skill 按计划定期运行，读取一段时间内积累的反馈，对比 Agent 原先的建议与人类后续反应，再提出范围尽量小、目标明确的基础 Skill 修改。

两条执行链因此具有不同的运行频率。

任务执行

PR / Issue
    ↓
基础 Skill + 当前上下文
    ↓
Agent 执行
    ↓
输出结果
    ↓
工程师原位反馈


异步改进

一段时间内积累的反馈
    ↓
改进 Skill 定期运行
    ↓
比较 Agent 输出与人类反馈
    ↓
提出基础 Skill 修改
    ↓
PR / 人工审核
    ↓
后续任务使用新版 Skill

这种拆分避免了每收到一条反馈就立即改变正在使用的规则。基础 Skill 维护当前任务应该遵循的工作方法，改进 Skill 专门负责整理经验和提出更新。

Warp 还指出，改进 Skill 本身具有一定复用性。不同 Agent 使用的领域知识各不相同，但读取反馈、比较差异并提出小范围修改的基本过程存在较多共性。因此，相比每个 Agent 都重新设计完整改进机制，这一层具有更大的复用空间。

Skill 文件让改进重新进入 Git 工作流

双层架构解决了谁执行、谁负责改进的问题，Skill 的文件形态则进一步解决了更新如何管理的问题。Warp 将 Skill 设计成基于文件保存的知识和工作指导。Agent 可以在执行任务时按需读取这些内容，不需要把全部知识直接写入原始 Prompt。

文件化带来的直接结果是，改进 Skill 提出的变化能够成为普通的文件修改。整个更新过程也就可以继续沿用开发团队熟悉的 Git 工作流。

人类反馈
   ↓
Skill 修改
   ↓
PR
   ↓
代码审查
   ↓
批准并合并
   ↓
下一次 Agent 使用新版 Skill

这些更新可以经过审查、批准和合并。修改完成合并以后，下一次基础 Skill 执行才会继承这次变化。从工程角度看，人类对 Agent 的反馈最终被转换成了一次可查看、可审核、可合并的 Skill 文件变更。哪些反馈触发了修改、文件具体发生了什么变化、什么时候正式生效，都可以继续沿用 Git 和 PR 已有的版本管理与审核机制。

Warp 已经把这种模式用于其开源仓库中的规格编写、代码审查和 Issue 分流 Agent，并为不同 Agent 建立各自的改进循环。

不过，这里还需要区分 Skill 与 Agent 记忆。Skill 更接近稳定的程序性知识，描述某类任务应该怎样完成，与单次运行无关，并通过显式流程修改；记忆则由 Agent 在推理过程中自动写入，并持续变化。因此，这套架构并不是把每一条用户反馈直接写进 Agent 的记忆，而是筛选值得长期保留的经验，再将其固化到 Skill 中。

一个 Issue 如何变成下一版 Skill

Warp 用一个真实的 Issue 分流 Agent 展示了整条链路。当 GitHub 仓库中出现新 Issue 后，GitHub Action 会启动 Agent。它会分析问题的复杂度和可行性、添加相应标签，并建议后续处理方向。负责这一任务的基础 Skill 保存了不同标签的含义，以及 Agent 在做判断前应该怎样研究代码库。

一次运行中，Agent 基本完成了任务，但漏掉了 ready to spec 标签。这个标签表示 Issue 已经描述了一个实际问题，可以开始进入产品和技术规格设计阶段。

Warp 的维护者发现遗漏后，直接在 Issue 中留下反馈，并解释自己期待什么，以及为什么应该这样判断。反馈没有进入额外的评估系统，而是直接留在工程师原本处理 Issue 的地方。随后，运行在 Warp 内部 Agent 编排平台 Oz 上的改进 Agent 按计划启动。它调用 Skill 中预置的 Python 脚本，从 GitHub 拉取近期带有反馈的 Issue，将信息整理成 JSON，再读入上下文进行分析。

有个细节很重要：数据获取这类相对确定的操作由 Skill 中已经准备好的脚本完成，Agent 主要处理反馈理解和 Skill 修改。尽管没有把这一点单独总结成架构原则，但从实现方式来看，这种分工减少了 Agent 每次执行时临时生成数据获取逻辑的需要。

拿到维护者的反馈以后，改进 Agent 提出了一个尽可能小的基础 Skill 修改。当 Issue 已经描述了一个实际问题，即使具体 UI 或 UX 形式还没有完全确定，也应该添加 ready to spec 标签。接着，它创建了修改基础 Skill 的 PR，并说明哪些反馈触发了此次变化，以及具体修改了什么。最后仍然由人完成审查、批准和合并。完成这一步以后，下一次 Issue 分流 Agent 才会继承更新后的领域知识。

一条普通的维护者评论就这样经历了完整的转换过程：反馈 → Skill 修改 → PR → 人工审核 → 后续复用。一次 Session 中的纠偏，由此变成了后续 Agent 可以继续遵循的工作方法。

“自改进”仍然需要反馈质量、验证与人工控制

这套闭环能够持续运行，不代表所有反馈都应该直接进入 Skill。

首先要控制反馈质量。Warp 建议 Skill 编写原则并解释原因，而不是不断枚举越来越细的规则。相应地，人类反馈也越具体越好。单纯点赞或点踩只能说明结果是否被接受，却无法告诉改进 Agent 哪里错了、为什么错。一小批来自资深工程师的详细领域反馈，有时比大量缺乏解释的二值信号更有价值。

Skill 本身也需要保持精简。Warp 建议采用渐进式披露，让 Skill 引用资源文件和脚本，需要时再加载相关信息，而不是把所有领域材料一次性写进上下文。

人工审核则为真正发生的更新保留了最后一道控制。Issue 分流案例中，改进 Agent 可以提出修改并创建 PR，但基础 Skill 只有在人完成审核和合并以后才真正改变。

对于能够客观验证结果的任务，Warp 还建议优先建立验证框架，让 Agent 输出可以与参考结果比较，再依据验证结果继续改进。无法完全自动验证的领域，可以尽量使用确定性评测和参考结果；必须依赖人工判断的部分，则更适合使用真正了解领域规则的专家反馈。

因此，Warp 的“自改进”并不是一条“收到反馈后自动修改 Agent”的简单循环，而是一套包含反馈筛选、Skill 更新和人工审核的受控改进流程。对于结果可以客观验证的任务，还可以进一步加入自动验证机制。整套模式最终可以压缩成四个环节：反馈 → Skill 更新 → 审核 → 后续复用。

Warp 解决的是一个非常具体的工程问题。原本只在一次 Session 中有效的人类纠偏，如何持续转化为可版本化、可审核，并能够进入后续任务的 Agent 工作方法。

标签： #Warp #Agent #Skill #Claude #Agent工程 #代码审查 #GitHub #开发者工具 #自改进Agent #AI工程