一版 Prompt 能把任务做对 80%，剩下 20% 才是真正消耗团队耐心的部分。Warp 内部跑着代码审查和 Issue 分流两类 Agent，它们不缺反馈入口：工程师能直接回复审查评论，维护者能在 Issue 里指出标签打错了。问题是这些反馈只活在当前 Session 里，Session 一结束就蒸发，下一次照样犯同样的错。
Warp 的解法是把改进对象锁定在 Skill 文件上，而不是模型参数。人类反馈经过分析转成 Skill 修改，走审核流程，再进入后续任务。整个过程不涉及调参，也不更新权重。
反馈为什么留不住
工程师说“这类全局变量在本仓库用另一套命名约定”，这句话本身很有价值。但 Agent 下次审查代码时根本读不到它，因为知识没有被写到任何持久位置。
手动改 Prompt 和 AGENTS.md 能救一时，救不了长期。改的人不同、频率不同、没人记录为什么改，几周后连当初为什么加这条规则都说不清。
Warp 把反馈纳入长期链路时有个偏好：要详细解释，说清哪里错、为什么错。只点个踩没有信息量，改进环节拿不到可执行的依据。
两个 Skill，两种节奏
架构本身不复杂：基础 Skill 加上改进 Skill，中间夹着人类反馈。
基础 Skill 保存某类任务的领域知识和执行指导。代码审查 Agent 在 PR 创建后，结合基础 Skill 和当前代码上下文做审查；Issue 分流 Agent 的基础 Skill 则记录不同标签的含义、判断前该怎么翻代码库。
改进 Skill 不碰具体 PR 或 Issue，它是个观察者，专门分析此前任务积累的人类反馈。两者运行频率完全不同：基础 Skill 随任务触发，改进 Skill 按计划定期跑，读一段时间内的反馈，对照 Agent 原先的建议和人类后续反应，提出范围尽量小的基础 Skill 修改。
这套拆分挡住了一个常见陷阱：收到一条反馈就立刻改正在使用的规范。基础 Skill 只管当前任务该怎么做，改进 Skill 只管整理经验和提更新，各司其职。
改进 Skill 还有复用价值。不同 Agent 的领域知识天差地别，但“读取反馈、比较差异、提出小边界修改”这个流程共性很强。与其给每个 Agent 重造一套改进机制，不如共用这一层。
文件形态把更新拉回 Git
双层架构解决了谁执行、谁改进，文件形态解决的是更新怎么管。Skill 以文件形式保存知识和执行指导，Agent 执行任务时按需读取，不用把所有知识硬塞进原始 Prompt。
一旦落到文件上，改进 Skill 提出的变化就是普通文件修改，整条更新链路可以直接套用团队熟悉的 Git 工作流。
修改经过审查、批准、合并，下一次基础 Skill 执行才会继承。哪些反馈触发了修改、文件改了什么、何时生效，全部走 Git 和 PR 已有的机制。Warp 已经把这种模式用在开源仓库的规格编写、代码审查和 Issue 分流 Agent 上，每个 Agent 各有自己的改进循环。
这里必须区分 Skill 和 Agent 记忆。Skill 是稳定的程序性知识，描述某类任务该怎么做，与单次运行无关，只能通过显式链路修改。记忆由 Agent 推理时自行写入，持续变化。所以这套架构不是把每条用户反馈直接灌进记忆，而是筛出值得长期保留的经验，固化到 Skill 里。
一个漏掉的标签怎么变成下版 Skill
Warp 用真实的 Issue 分流场景演示了全链路。GitHub 仓库出现新 Issue 后，GitHub Action 启动 Agent，它分析问题复杂度和可行性、打标签、建议后续方向。基础 Skill 里存着各标签的含义和判断前研究代码库的方法。
有一次 Agent 基本做对了，唯独漏掉 ready to spec 标签。这个标签表示 Issue 已经描述了一个实际问题，可以进入产品和技术规格构建阶段。
维护者直接在 Issue 里留言，解释自己期待什么。反馈没有进额外的评估系统，就留在工程师原本处理 Issue 的地方。随后运行在内部 Agent 调度平台 Oz 上的改进 Agent 按计划启动，触发 Skill 里预置的 Python 脚本，从 GitHub 拉取近期带反馈的 Issue，整理成 JSON 再读入上下文分析。
这里有个容易被忽略的工程细节：数据获取这类确定性操作交给 Skill 里写好的脚本，Agent 只负责理解反馈和改 Skill。实测这样更稳，能减少 Agent 每次执行时临时生成数据获取逻辑的随机性。
改进 Agent 拿到维护者反馈后，提出一个尽可能小的基础 Skill 修改：当 Issue 已经描述了一个实际问题，即便具体 UI 或 UX 形式还没完全确定，也应当添加 ready to spec 标签。接着它创建 PR 修改基础 Skill，说明哪些反馈触发了这次变化、具体改了什么。收尾仍由人审查、批准、合并，之后下一次 Issue 分流 Agent 才继承更新后的知识。
一条普通评论走完了完整转换：反馈 → Skill 修改 → PR → 人工审查 → 后续复用。一次 Session 里的纠偏，变成了后续 Agent 持续遵循的工作方法。
反馈质量、校验和人工兜底
回路能持续跑，不代表所有反馈都该进 Skill。
反馈质量要控。Warp 的建议是 Skill 编写原则并解释缘由，而不是无休止枚举越来越细的规范。人类反馈同理，越详细越好。单纯点赞或点踩只说明结果是否被接受，说不清哪里错、为什么错。一小批资深工程师的详细领域反馈，价值往往高于海量没有解释的二值信号。
Skill 本身要精简。用渐进式披露，让 Skill 引用资源文件和脚本，需要时再加载，别把全部领域材料一次性写进上下文。上下文塞满之后，Agent 的注意力会被稀释，这里有个坑，很多人以为知识写得越多越保险，实际相反。
人工审核是最后一道闸。Issue 分流样例里，改进 Agent 能提修改、能建 PR，但基础 Skill 只有在人批准合并之后才真正生效。
几个容易踩的判断问题
Skill 和记忆混了吗？Skill 偏程序性、稳定，描述“某件事该怎么做”，与单次运行无关，靠显式流程有意修改；记忆由 Agent 推理时自行写入，持续变化。混用会让不该固化的临时信息污染长期规范。
共用一个改进循环还是每个 Agent 一套？可以取中间方案：用模板化的基础改进循环承载共性，再叠加领域特定配置。Agent 数量少时分别维护也行，规模大了共享基础循环更划算。
人类反馈本身错了怎么办？默认错误反馈必然出现，不能让 Agent 无条件接受。要提供足够上下文做合理性检查，筛选哪些人的反馈有效，并在反馈筛选或最终审核阶段保留人工参与。
领域能不能客观验证？能就优先搭验证体系，再让 Agent 按验证结果迭代。建立参考资料集，把 Agent 输出和参考结果比对，按差异修改，重复校验。不能完全客观校验的，有基准参考输出的部分优先用确定性评测；必须依赖人工时，尽量限定为领域专家反馈，别无差别扩大来源。
系统是否真在变好？跟踪团队本来就在看的全局指标，比如合并耗时、贡献者数量、成本，把这些指标反馈给改进 Agent。上线用循序渐进的方式，从小边界验证逐步扩展。
这套方案不适合什么场景
如果任务本身没有稳定的领域知识，每次判断都依赖一次性上下文，那 Skill 文件会迅速膨胀成一堆互相矛盾的经验条目，改进循环反而制造噪音。
如果团队没有代码审查习惯，PR 流程形同虚设，那“反馈 → Skill 修改 → PR → 审核”这条链路会断在人工审核那一步，改进 Agent 提出的 PR 没人看，规范照样失控。
还有一种情况：反馈来源极度分散且缺乏领域专家，例如面向海量普通用户的 Agent。此时二值信号的占比会压倒详细解释，改进 Agent 拿到的输入质量不足以支撑小边界修改，强行跑只会让 Skill 漂移。
验证这套机制是否生效，可以看几个可观察信号：改进 Agent 提出的 PR 是否大多数被合并、合并后同类错误是否在后续任务中减少、基础 Skill 文件的体积是否保持克制。如果 PR 频繁被驳回或 Skill 越长越乱，先停下来检查反馈质量和审核环节，而不是加大改进 Agent 的运行频率。
