一个 Skill 在演示里成功一次，只能证明它有可能工作，不能证明它稳定，更不能证明下一次修改让它变好了。
Warp 展示了一种更接近软件工程的做法：让 Agent 批量运行 Skill，用另一个 Observer Skill 检查结果、归纳失败，再提交对 Skill 文件的修改。目标不是获得一次漂亮输出，而是建立一个可以持续测量和改进的外循环。
Warp 的 Skill 优化外循环：批量运行、评估视觉与行为、测量 token，再生成改进建议
#内循环修任务，外循环修能力
示例中的目标 Skill 负责把可视化建站平台上的网站迁移为自托管代码。第一次迁移已经完成大部分工作，但下拉按钮缺少图标，视觉与交互没有完整复现。
针对这一个网站补上图标，属于内循环：发现具体缺陷，修复具体产物。Warp 更关心另一个问题：怎样修改迁移 Skill，让它以后面对其他网站时也更不容易犯同类错误？这就是外循环。
第一次网站迁移已经接近完成，但导航下拉按钮的图标没有正确复现
两者的区别在于优化对象不同：
- 内循环验证一次执行是否成功，修改当前任务的输出
- 外循环比较一批执行，修改产生这些输出的 Skill
如果没有这层区分，Agent 很容易把某个网站的偶然结构写进通用 Skill，表面上修复了评测样本，实际却降低了泛化能力。
#Observer Skill 如何工作
Warp 为迁移 Skill 配置了一个独立的 Observer Skill。它接收 N 个待迁移网站，对每个网站调用目标 Skill，构建生成结果，再通过浏览器和 Computer Use 比较迁移前后的行为与视觉表现。
Observer Skill 负责运行目标 Skill、比较视觉与交互、记录成本，并只保留有证据支持的改进
Observer 不只看最终页面是否能打开，还把执行结果整理成结构化数据，包括缺失元素、行为差异、视觉问题以及每次迁移消耗的 token。质量与成本被放进同一个评测过程：目标不是不惜代价追求像素一致，而是在维持质量的同时减少浪费。
积累多次运行后，Observer 使用强模型寻找跨案例失败模式，并生成对目标 Skill 的修改 diff。Skill 本质上是一组版本化文件，所以这个修改可以走普通 Pull Request 流程，由人检查后再进入下一轮。
Observer 从重复出现的迁移缺陷中生成可审查的 Skill 修改 diff
整个循环可以概括为：
- 在一批不同输入上运行目标 Skill
- 构建并检查每次输出
- 汇总质量、行为和成本数据
- 寻找重复出现的失败模式
- 生成 Skill 修改 diff
- 重新运行评测，确认修改是否真的带来改善
#评分器必须接触真实结果
这个案例的关键不是“再用一个 LLM 打分”，而是先让评分器接触可观察的执行证据。网站是否成功构建、按钮能否操作、页面是否出现视觉差异，都比让模型阅读最终回答后凭印象给分更可靠。
不同任务需要不同证据。代码 Skill 可以运行测试和静态检查；数据 Skill 可以验证行数、字段、公式与守恒关系；文档 Skill 可以检查结构、内容约束和渲染结果；GUI Skill 则需要结合界面状态与 Computer Use。
LLM Judge 更适合处理确定性检查覆盖不了的部分，例如审美、解释质量和失败模式归纳，而不是替代所有验证器。
#优化循环也需要停止条件
自动迭代并不意味着无限迭代。Warp 的 Observer 内置退出条件：当新一轮生成的修改越来越不重要，就停止继续消耗 token。
这也暴露了外循环的两个边界。第一，它依赖清晰的验证标准；如果“好”的定义模糊，Observer 只会把主观偏好包装成分数。第二，它可能找到局部最优：Skill 越来越适合当前样本，却未必更适合真实世界。
因此，可靠的评测集需要同时包含校准样本和从未参与修改的保留样本。每次更新不仅要检查平均分是否上升，还要检查旧能力有没有退化、成本有没有失控，以及提升是否只集中在少数案例。
#Skill 应该像生产代码一样演进
Warp 的方法把 Skill 从一次性提示词变成了可测试、可比较、可回滚的行为配置。执行轨迹提供证据，评分器把证据转成信号，改进 Agent 提出 diff，人类通过代码审查控制最终变更。
真正重要的不是“Agent 能修改自己的 Skill”，而是每次修改都必须回答三个问题：它在哪些真实任务上更好，是否牺牲了其他任务，以及为这点提升付出了多少成本。只有这三个问题都有可复现答案，自我改进才不是自我感觉良好。