作为正在把AI Agent推向生产环境的开发者，你大概率遇到过这样的真实卡点：为一个明确的业务需求写好一个Skill——比如把一个搭建在Framer或Webflow上的营销站完整迁移到Vercel自托管代码。Skill跑完后，页面结构、内容、导航基本对得上，但下拉菜单的切换图标突然消失了，视觉上像被砍掉了一块。手动翻页检查、补图标、验证交互，单次任务还能扛，任务一多，这种“80分就交卷”的Skill就会反复在生产环境翻车。

近日Warp创始人Zach Lloyd用自己的播客站talkingslop.ai做了个完整演示。他先用/replatform-site Skill把no-code站点迁移到talking-slop.vercel.app，初始结果已经非常接近原站，但依然留下了明显的视觉缺陷。问题不在于Skill写得不够详细，而在于一次性编写的Skill缺少持续施压的外部反馈机制。

他没有停留在单次修复，而是构建了一个外层observer循环，让Skill本身具备自我进化的能力。这套做法把“写一次Skill”升级成了“Skill持续逼近最优解”的系统。

起初我以为只要把prompt写得足够细致、边界条件列得足够全，Skill就能稳定工作。后来看到这个案例才意识到，Skill更像一段需要持续编译和测试的代码，真正的杠杆在于外部观察者能否用客观证据持续施压。

这就像给一个新入职的工程师配备一位永远在线的资深导师。导师不只看单次作业结果，而是用“自动视觉检查工具”批量审阅多份输出，找出反复出现的共性问题（比如图标资源迁移遗漏），然后修订任务清单，让下次执行自动规避同类错误。

另一个更贴近工程的类比是持续集成流水线：代码写完不是靠开发者自己反复调试，而是让自动化测试套件（在这里由computer use承担视觉与行为验证）持续运行，并把失败证据反哺成对代码本身的精准修改建议。

observer Skill的核心机制拆解

整个系统分为内层Skill和外层observer两层。

内层/replatform-site负责具体迁移工作：站点盘点、内容与资产提取、框架脚手架生成（默认Next.js App Router静态导出或Astro）、资源本地化、动态功能重定向（表单转Formspree、搜索转Pagefind等）、部署配置生成，最后本地验证构建与渲染一致性。

外层replatforming-observer则负责“评判与进化”。它接收一批示例站点作为输入，调用内层Skill完成迁移，构建并启动生成站点，然后通过child agent的computer use能力：

• 在干净浏览器环境中加载原站与生成站
• 捕获全页及视口截图
• 执行关键交互并记录行为差异
• 用计算机视觉对比构图、排版、颜色、响应式表现、内容覆盖度

同时记录视觉质量分（0-100）、端到端延迟、token消耗、构建时长等结构化指标。所有结果以统一artifact schema输出，便于后续模型进行模式识别。

SOTA模型根据这些证据诊断失败模式（参考内置的failure taxonomy，将问题归类为示例特有、provider/framework通用、工作流失效或效率问题），只提出最小化、可泛化的diff，而不是针对单个站点的硬编码修复。diff被记录为DIF（Differential Improvement Flow）记录，包含证据、预期影响、回归风险和通过门禁。

更新后会立即重新跑基准测试，只有同时满足“构建成功、无阻塞回归、视觉质量不下降或提升、token/延迟回归不超过15%且有质量理由”等门禁的diff才会被保留。否则回滚。

这个过程可以迭代多次，直到触发退出条件：diff变得仅 cosmetic 或示例特有、质量提升进入平台期（连续迭代≤2分）、相同模式反复出现却无新进展、或成本已稳定在可接受区间。

伪代码层面的observer核心流程（逻辑重构版）

# observer Skill 核心自改进循环（伪代码 + 中文关键注释）
def observer_self_improvement(sites, inner_skill_path, max_dif=3):
    workspace = create_isolated_workspace()  # 每个站点独立环境，避免污染
    history = []
    
    for iteration in range(max_dif):
        results = []
        for site in sites:
            # 1. 执行内层Skill
            migrated = run_inner_skill(inner_skill_path, site_url=site)
            built = build_and_preview(migrated)  # 构建并启动预览
            
            # 2. Computer Use 客观评估
            eval_result = computer_use_compare(
                original_url=site,
                generated_url=built.preview_url,
                viewports=["desktop", "mobile"],
                checks=["visual_similarity", "interaction", "asset_integrity"]
            )
            # eval_result 包含视觉分、行为差异、截图路径、token消耗等结构化数据
            
            results.append({
                "site": site,
                "eval": eval_result,
                "artifacts": save_screenshots_and_transcripts(eval_result)
            })
        
        # 3. 合成分析 + 生成最小化diff
        synthesis = sota_model.analyze_with_taxonomy(
            results, 
            failure_taxonomy_path="references/failure-taxonomy.md"
        )
        dif = generate_minimal_generalizable_diff(synthesis)  # 只改通用指令，不硬编码站点
        
        # 4. 门禁验证
        if apply_and_validate_dif(dif, results):  # 重新跑基准，检查回归
            history.append(dif)
            update_inner_skill(inner_skill_path, dif)
        else:
            record_no_change(dif, reason="regression_or_no_gain")
        
        if should_exit(synthesis, history):  # 质量平台期、diff无意义、成本稳定
            break
    
    return generate_final_report(history)  # 包含收敛证据和最终Skill版本

这段流程的关键在于“结构化证据 + 最小化泛化diff + 严格门禁”，而不是让模型随意改prompt。

一次性Skill vs 带observer循环的权衡矩阵

为什么这种外层循环比单纯堆prompt更有长期价值

它把一次性的工程努力转化成了可复用的系统能力。内层Skill解决具体问题，外层observer解决“如何让解决问题的能力持续变强”。当你把这个模式应用到其他有明确验收标准的Skill上（代码生成、数据清洗、UI组件生成等），整个Agent团队就具备了元学习能力。

当然它不是万能的。computer use虽然能提供客观视觉证据，但成本和速度都高于纯文本评估；系统仍可能在局部最优中停滞；退出条件设计不当容易浪费token。这些都需要在实际落地时根据任务特性和预算做权衡。

在生产环境真正落地前必须做好的三件事

先确认任务是否具备稳定、可量化的验收标准——没有清晰的“通过/失败”信号，observer就无从施压。
其次把observer自身也当作一个需要版本控制和门禁保护的产物，避免它为了优化而引入新风险。
最后从小规模开始：先用3-5个代表性站点跑通一轮完整DIF，验证门禁和退出逻辑，再逐步扩大语料。

这种自我改进循环的本质，是把Agent从“会执行指令的工具”推向“能在真实反馈中持续进化的系统”。对个人开发者而言，掌握这种元能力，就能在AI工具快速迭代的浪潮中，始终保持对生产系统的掌控力，而不是永远追着下一个更好prompt跑。

在你当前的Agent项目里，哪些Skill已经有了清晰的验证维度？不妨挑其中一个，先设计一个最小可行的observer循环跑起来，看看它能把Skill迭代到什么程度。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。