让 Agent 完成一次任务并不难，难的是让它在第十次遇到类似任务时，不再重复前九次犯过的错。
Warp 在内部代码审查 Agent 上碰到了这个问题。Agent 能完成大约八成工作，却经常留下无用评论或低质量建议。团队先手动改 prompt，也补充了 AGENTS.md 等上下文文件，输出有所改善，但每次会话结束后，工程师对结果的反馈仍然随之消失。Agent 下一次运行时，并不知道团队曾经纠正过什么。
Warp 最终把问题从“怎样写出一个更好的 prompt”，改写成“怎样让有效反馈进入一个长期、可审计的更新循环”。答案是一套由两个技能和人类反馈组成的自我改进架构。
#两个技能，中间放人
这套循环的内部是 base skill ，也就是执行任务的领域技能。它保存稳定的流程知识和判断原则。代码审查 Agent 收到 PR 后，会读取这个技能以及项目上下文，再生成审查意见。
中间是人类反馈。它可以只是一次肯定，但越具体越有价值。与其说“这条评论不好”，更有效的反馈是：“你建议重命名这个变量，但本仓库的全局变量遵循另一套命名约定。”后者不仅给出结论，还补充了 Agent 原本无法知道的领域原因。
外部则是 improver skill 。它不是每次任务都运行，而是作为观察者定时启动：收集一段时间内的反馈，对照 Agent 当时的输出与人的反应，找出能够复用的信号，然后只对 base skill 提出一项小而集中的修改。
于是完整链路变成：
- base skill 指导 Agent 执行真实任务；
- 人在原本的工作界面中留下具体反馈；
- improver skill 定时读取这些反馈并寻找重复模式；
- Agent 提交对 base skill 的小幅修改；
- 人类审查、批准并合并；
- 下一次任务自动继承已经验证的新知识。
关键在第五步。技能是普通文件，因此每次改进都可以进入已有的 Git 和 PR 流程：能看 diff，能讨论原因，能拒绝错误修改，也能在出问题时回滚。所谓“自我改进”并没有绕过工程治理，而是把学习过程也变成了工程制品。
#技能不是记忆
Warp 特别区分了 skills 与 memory。
记忆通常由 Agent 在推理过程中自动写入，内容持续变化，记录的是某次运行中发生过什么。技能保存的则是相对稳定、跨任务复用的程序性知识，也就是“怎样完成某类工作”。它不会因为一次反馈就立即变化，而是经过筛选、验证和人工合并后才更新。
这个差别决定了系统的风险边界。如果把所有反馈直接写进记忆，错误意见、偶然偏好甚至恶意输入都可能进入下一次推理；如果把反馈先转化成一个可评审的技能 diff，团队就能检查它是否真的具有普适性。
所以这套系统不是让 Agent 无限制吸收一切，而是把反馈变成候选知识，再通过工程流程决定什么值得留下。
#真实案例：Issue 分诊 Agent 漏了一个标签
Warp 开源了一个 GitHub Issue 分诊示例。每当新 Issue 创建，GitHub Actions 会启动 Agent，分析问题复杂度和可行性、分配标签，并建议下一步处理方向。执行时，它会读取一个描述标签含义以及代码库调查方法的 base skill。
在一次运行中，Agent 的整体判断正确，却漏掉了 ready to spec 标签。这个标签表示问题已经足够真实，可以开始编写产品和技术规格，即使最终 UI 或 UX 方案还没有确定。
维护者直接在 Issue 中指出了遗漏，并解释为何这个问题已经达到进入规格阶段的条件。反馈没有被复制到另一个专用系统，而是留在团队原本工作的地方。
之后，运行在 Warp 编排平台 Oz 上的 improver skill 定时启动。它通过技能附带的 Python 脚本拉取近期带反馈的 Issue，将信号整理成 JSON，再结合上下文判断需要修改什么。最终，它没有重写整个分诊逻辑，只提交了一个最小 PR：当 Issue 描述了真实问题、但具体界面形态尚未确定时，也应该应用 ready to spec。
人类审查并合并后，下一次分诊自然获得了这条新判断。反馈从一次性的评论，变成了可复用的组织知识。
#写自我改进技能的六条经验
Warp 把实践经验总结成几条很克制的原则。
#写原则，不要穷举规则
技能应当像是在指导一个聪明同事，而不是给传统程序编写完整条件表。“寻找重复代码”往往比列出所有变量命名方式更能跨场景泛化。
#解释为什么
只写结论会让 Agent 机械套用；补充规则背后的理由，才能让它在相邻但不完全相同的问题中作出判断。
#让反馈发生在工作现场
最好的反馈入口是 PR、Issue 等团队本来就在使用的位置，不要再要求填写额外表单。摩擦越低，信号才越可能持续流动。
#技能要小，并使用渐进式披露
主技能文件不应该塞进所有知识。详细参考、脚本和资源可以拆成外部文件，需要时再读取。这样既节省上下文，也更容易审查改动究竟影响了什么。
#反馈质量高于数量
一次来自领域专家、包含具体原因的反馈，可能比大量赞踩更有用。二元评价只能说明结果受欢迎与否，却不能告诉 Agent 下次应该怎样做。高质量信号足够多时，收益仍会继续累积。
#把更多精力放在 improver skill 上
领域技能各不相同，但“怎样收集反馈、过滤噪声、寻找可复用模式并提出最小修改”具有很强的共性。一套成熟的改进技能可以被多个 Agent 复用，不必为每个 Agent 从头发明学习机制。
#错误反馈必须被假设为常态
反馈闭环最危险的误区，是默认反馈都正确。Warp 的建议恰恰相反：先假设反馈中会包含错误、局部偏好和噪声。
因此，improver 不能盲目接受每条意见。它需要足够的上下文做合理性检查，需要明确哪些人的输入可以作为领域信号，并在过滤或最终合并阶段保留人工控制。如果 Agent 数量不多，可以为不同领域设置独立 improver；规模扩大后，则应共享通用模板，只叠加少量领域权重。
对于可验证的领域，应先建设验证工具，再让 Agent 围绕它迭代：准备参考语料，对比实际输出，修正后重新运行。无法完全验证的领域，则尽可能使用确定性评测和黄金样本；确实需要主观判断时，只引入领域专家反馈，而不是向所有输入开放学习权限。
#不能只看局部输出，还要看系统指标
单次任务质量提高，不代表整个系统真的在变好。Warp 建议继续追踪团队原本就关心的全局指标，例如合并时间、贡献者数量和运行成本，并把这些结果反馈给改进 Agent。
这也要求部署节奏从小到大：先让循环处理一个范围清楚、容易验证的任务，观察修改是否稳定；再逐步扩展到更多 Agent 和更复杂的工作流。Warp 已经把这种模式用于整个开源仓库，让规格编写、代码审查和 Issue 分诊 Agent 分别拥有自己的改进循环。
这套方法最值得借鉴的地方，不是它让 Agent 看起来更“自主”，而是它把原本会在会话结束后消失的人类判断，变成了版本化、可验证、能够在组织内部持续复利的运行知识。