一版 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 如何变成下一版 SkillWarp 用一个真实的 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 引用资源文件和脚本需要时再加载相关信息而不是把所有领域材料一次性写进上下文。关键问题Warp 团队的自改进 Skill 实践建议是否混淆了 Skill 与记忆Skill 更偏程序性、稳定的知识描述“某件事应该怎么做”与单次运行无关并通过显式流程有意修改。记忆则由 Agent 在推理过程中自动写入并持续变化。应该共用一个改进循环还是每个 Agent 各自一套可以取中间方案。用一套模板化的基础改进循环承载不同 Agent 之间的共性再叠加领域特定的配置。Agent 数量较少时可以分别维护规模扩大后更适合共享基础循环。如果人类反馈本身是错的怎么办默认错误反馈一定会出现。 不要让 Agent 无条件接受反馈。应提供足够上下文进行合理性检查筛选哪些人的反馈有效并在反馈筛选或最终审核阶段保留人工参与。任务所在领域可以客观验证吗如果可以优先搭建验证框架再让 Agent 根据验证结果迭代。可以建立参考数据集将 Agent 输出与参考结果比较根据差异修改再重复验证。如果任务无法完全客观验证呢有标准参考输出的部分优先使用确定性评测。必须依赖人工反馈时应尽量限定为领域专家反馈不要无差别扩大反馈来源。如何判断整个系统是否真的在变好跟踪团队本来就在关注的全局指标例如合并耗时、贡献者数量和成本并将这些指标反馈给改进 Agent。部署时采用循序渐进的方式从小范围验证逐步扩大。人工审核则为真正发生的更新保留了最后一道控制。Issue 分流案例中改进 Agent 可以提出修改并创建 PR但基础 Skill 只有在人完成审核和合并以后才真正改变。对于能够客观验证结果的任务Warp 还建议优先建立验证框架让 Agent 输出可以与参考结果比较再依据验证结果继续改进。无法完全自动验证的领域可以尽量使用确定性评测和参考结果必须依赖人工判断的部分则更适合使用真正了解领域规则的专家反馈。因此Warp 的“自改进”并不是一条“收到反馈后自动修改 Agent”的简单循环而是一套包含反馈筛选、Skill 更新和人工审核的受控改进流程。对于结果可以客观验证的任务还可以进一步加入自动验证机制。整套模式最终可以压缩成四个环节反馈 → Skill 更新 → 审核 → 后续复用。Warp 解决的是一个非常具体的工程问题。原本只在一次 Session 中有效的人类纠偏如何持续转化为可版本化、可审核并能够进入后续任务的 Agent 工作方法。